Ограниченная протяженность во времени.
Проекты выполняются в течение конечного периода времени. Они
временны. У них есть более или менее четко выраженные начало и конец. Проект
заканчивается, когда достигнуты его основные цели. Значительная часть усилий при
работе с проектом направлена именно на обеспечение того, чтобы проект был
завершен в намеченное время. Для этого готовятся графики, показывающие время
начала и окончания заданий, входящих в проект.
Отличие проекта от производственной системы заключается в
том, что проект является однократной, не циклической деятельностью. Серийный же
выпуск продукции не имеет заранее определенного конца во времени и зависит лишь
от наличия и величины спроса. Когда исчезает спрос, производственный цикл
кончается. Производственные циклы в чистом виде не являются проектами. Однако, в
последнее время проектный подход все чаще применяется и к процессам,
ориентированным на непрерывное производство. Например, проекты увеличения
производства до указанного уровня в течении определенного периода, исходя из
заданного бюджета, или выполнение определенных заказов, имеющих договорные сроки
поставки.
Проект как система деятельности существует ровно столько
времени, сколько его требуется для получения конечного результата. Концепция
проекта, однако, не противоречит концепции фирмы или предприятия и вполне
совместима с ней. Напротив, проект часто становится основной формой деятельности
фирмы.
2.1 Рекомендации к написанию введения
Во введении обосновывается актуальность выбранной темы, определяются общая цель индивидуального проекта, его конкретные задачи и методы исследования.
Обосновать актуальность – значит, объяснить необходимость данной темы в контексте общего процесса научного познания. Актуальность может состоять в необходимости получения новых данных и необходимости проверки новых методов и т. п.
Обосновывая актуальность необходимо кратко осветить причины, по которым изучение этой темы стало необходимым.
Несомненным показателем актуальности является наличие проблемы данной области исследования.
Например«Актуальность ее определяется сложившейся неблагоприятной динамикой структуры фактического питания подростков, а также отмеченным в связи с этим ростом хронической патологии органов пищеварения» или «Амфибии до сих пор изучены не полностью, в их жизни остается много загадок. Необходимо разработать охранные меры для сохранения численности и видового разнообразия земноводных. Их изучение необходимо для того, чтобы не лишить Землю таких животных, как жабы, квакши, лягушки и др.»
«Статистические данные указывают на актуальность изучения состояния природной среды Севера и возможных последствий его химического загрязнения».
При определении целей и задач проекта необходимо их правильно формулировать. Формулировка по возможности должна быть краткой и четкой.
Например, «Установить взаимосвязь между циклическими колебаниями солнечной активности и жизнедеятельностью организмов».
Цель конкретизируется и развивается в задачахпроекта.
В задачах обозначают комплекс проблем, которые необходимо решить в ходе проекта. Задачи могут отражать определенную пошаговость достижения цели, последовательность действий
Пример формулировки задач
Целью проводимого исследования является оценка состояния эпифитного лишайникового покрова деревьев в окрестностях села …:
Для достижения поставленной цели необходимо решить следующие задачи:
1) изучить видовой состав лишайников, обитающих в окрестностях села …;
2) проследить зависимость лишайникового покрова деревьев от удаленности источника загрязнения;
3) выяснить, как изменился лишайниковый покров на деревьях с 2000 по 2007 г.».
Наконец после формулирования цели и задач, необходимо коснуться методов и методик, которые использовались при разработке проекта. Успех работы во многом зависит от правильно подобранных и умело использованных методов, которые вытекают из поставленных задач, логики изучаемого процесса.
Методы, используемые при разработке проекта, делятся на три группы:
- Эмпирические методы (наблюдение, сравнение, анкетирование, беседы, интервью, измерения, эксперимент),
- Теоретические методы (абстрагирование, анализ и синтез, обобщение имеющегося опыта, индукция и дедукция и др.),
- Методы восхождения от абстрактного к конкретному.
Примеры
«Исследования на водоемах производились еженедельно: наблюдения за периодичностью голосовой активности жерлянок, рост и развитие головастиков в природе, природные факторы. Длина тела взрослых жерлянок определялась путем измерения длины тела амфибий от ротового до центра клоакального отверстия. При наблюдении за головастиками определялось их количество в 1 кв. м».
«Методика работы: сопоставление статистических данных за 1996-2003 гг. по урожайности кормовых трав, удоям коров, яйценоскости кур-несушек и заболеваемости жителей поселка с колебаниями солнечной активности».
В тексте индивидуального проекта должны преобладать сложные союзные предложения с оборотами:
∙ благодаря тому, что…
∙ в силу того, что…
∙ после того как…
∙ в то время как…
В тексте работы полезно комментировать цель, задачи и ход самого проекта, пользуясь оборотами:
∙ как было показано выше…
∙ в рамках проекта считается целесообразным…
∙ в дальнейшем перед нами стоит задача…
∙ ключевым вопросом нашего исследования, которые необходимо рассмотреть в теоретическом разделе, является…
Не рекомендуется использовать повыше побыстрее суффиксы -айш, -ейш кое-что что-нибудь какой-то |
Рекомендуется использовать наиболее… наименее… нечто что-либо некий |
Приемами написания единого по стилю научного текста является использование клише.
Концепция и границы в проектах гибкой разработки
Для управления границами проектом гибкой разработки (agile), в котором разработка ведется сериями коротких итераций, нужно применять другой подход. Границы каждой итерации состоят их пользовательских историй, выбранных из динамического резерва (backlog) на основе их относительных приоритетов и расчетной производительности команды в каждой итерации.
Вместо того чтобы бороться с распуханием границ, в команде определяют приоритеты новых требований на основе существующих элементов резерва проекта и назначают их на будущие итерации.
Число итераций, а значит, и общая продолжительность проекта, все равно определяется общим объемом функциональности, которую нужно реализовать, но границы каждой итерации жестко контролируются, чтобы гарантировать ее своевременное завершение. С другой стороны, в некоторых проектах гибкой разработки фиксируется общая продолжительность проекта, а меняются границы. Число итераций может оставаться фиксированным, но рамки остающихся итераций изменяются в соответствии с относительными приоритетами существующих или новых пользовательских историй.
Команда может определить высокоуровневую дорожную карту итераций вначале проекта, но распределение пользовательских историй по итерациям может выполняться вначале каждой итерации. Обращение к бизнес требованиям при определении границ каждой последующей итерации помогает гарантировать, что будет поставлен продукт, отвечающий бизнес-целям. Подобная стратегия может применяться в любом проекте, состоящем из итераций (см. врезку «Управление объемом и разработка по итерациям»).
Управление объемом и разработка по итерациям
Энрике, менеджер проекта в Lightspeed Financial Systems, занимался выпуском интернет-версии ведущего программного продукта Lightspeed для управления портфелем ценных бумаг. Потребовались бы два года для поставки полнофункциональной версии приложения, однако компания должна была дать знать о себе в Интернете уже сейчас. Энрике выбрал прием «разработка по итерациям» и обещал выпускать новую версию каждые 90 дней. Его команда специалистов по маркетингу расставила приоритеты требований к продукту. В спецификацию требований для каждой ежеквартальной версии входил утвержденный набор новых и улучшенных функций, а также список «переходящих» требований низкого приоритета, которые предполагалось реализовать, если позволяло время. Команда Энрике не включала каждое такое требование в каждую версию, но они поставляли новую, стабильную версию каждые три месяца с помощью подхода, который учитывал график и управление границами итерации. График и качество — это естественные ограничения проекта «разработка по графику», а границы итерации представляли собой степень свободы.
Хотя в проектах гибкой разработки обычно и не создается формальный документ концепции и границ, содержимое шаблона на рис. 5-3 и относимо, и обязательно для поставки успешного продукта. Во многих проектах гибкой разработки выполняется начальная (нулевая) итерация планирования для определения общей концепции продукта и других требований проекта.
Бизнес-требования должны определяться во всех проектах разработки ПО независимо от модели разработки. Бизнес-цели описывают ожидаемую выгоду от проекта, а в проекте гибкой разработки они используются для облегчения определения приоритетов резерва (backlog), чтобы добиться максимальной ценности для бизнеса в самых ранних итерациях. Критерии успеха надо определить так, чтобы после развертывания можно было измерить успех и соответствующим образом скорректировать резерв проекта. Положение о концепции содержит долгосрочный план — то, чем должен стать продукт по завершении всех итераций.
Что я понял по результатам моих попыток.
Есть общая беда всех курсов из разряда «Введение в …» (даже со смешными картинками) – они дают пачку базовых определений, постепенно повышая сложность. «Почему это беда?», спросите вы. Отвечу аналогией: когда вы учите двухлетнего ребенка отличать круглое от квадратного, вы не даете ему геометрической аксиоматики, «что такое прямая», «что такое окружность» и т.п. плавно подводя к определению «шар» и «куб». Вы просто даете ему кубики и шарики и доску с дырками, в которую их надо вставить. Только значительно позже, уже в средних классах, он узнает их формальные определения. Конечно, программист с опытом – не двухлетний ребенок. Но встроенная в каждого человека нейросеть эволюционировала как инструмент обобщения разрозненных примеров в общий абстрактный принцип, а совсем не как инструмент, получающий готовые абстрактные принципы. Обучение на примерах всегда идет быстрее нежели сухое перечисление определений.
Анекдот:
Аналогично, при чтении очередного определения «монады» через функтор, у меня в голове возникала только одна мысль: вроде все понятно, но непонятно НАХРЕНА. Ощущения примерно соответствуют этой картинке:
Какую задачу они пытались решить, если в условной Java и так все работает без этих ваших всяких монад. Между тем, как будет показано ниже, за каждой очередной функциональной абракадаброй стоит вполне реальная решенная задача, понятная любому программисту с 2-3 летним стажем.
Как работает команда
Все начинается с выяснения требований и планирования. Задачи записывают на карточки, выясняют у заказчика последовательность, в которой он хочет получать функционал продукта. Карточки располагают по приоритетности. По схожей системе работают команды в Scrum и Kanban.
Команда анализирует информацию, оценивает время на каждую задачу. Согласовывает все с заказчиком и начинает работу над проектом. Требования часто меняются, поэтому процесс делят на короткие этапы с частыми релизами, как и в Scrum.
Прежде чем начать, команда создает тесты, которые будет использовать для проверки готового кода. Когда тесты готовы, разработчики пишут первую часть кода. Тестируют ее, а потом приступают ко второй. Постепенно появляется все больше маленьких частей кода, которые в процессе добавляют в единую систему. Части кода и функции будущего продукта наращивают постепенно, как снежный ком. После каждого релиза команда собирает обратную связь, чтобы двигаться дальше.
Классификация проектов по доминирующей деятельности учащихся
- Практико-ориентированный проектнацелен на решение социальных задач, отражающих интересы участников проекта или внешнего заказчика. Эти проекты отличает четко обозначенный с самого начала результат деятельности его участников, который может быть использован в жизни класса, школы, микрорайона, города, государства. Форма конечного продукта при этом разнообразна — от учебного пособия для кабинета физики до пакета рекомендаций по восстановлению экономики России. Ценность проекта заключается в реальности использования продукта на практике и его способности решить заданную проблему.
- ·Исследовательский проектпо структуре напоминает научное исследование. Он включает в себя обоснование актуальности выбранной темы, постановку задачи исследования, обязательное выдвижение гипотезы с последующей ее проверкой, обсуждение и анализ полученных результатов. При выполнении проекта должны использоваться методы современной науки: лабораторный эксперимент, моделирование, социологический опрос и др.
·Информационный проектнаправлен на сбор информации о каком-либо объекте или явлении с целью анализа, обобщения и представления информации для широкой аудитории. Такие проекты требуют хорошо продуманной структуры и возможности ее коррекции по ходу работы. Выходом проекта часто является публикация в СМИ, в т. ч. в сети Internet.
·Творческий проект предполагает максимально свободный и нетрадиционный подход к его выполнению и презентации результатов. Это могут быть альманахи, театрализации, спортивные игры, произведения изобразительного или декоративно-прикладного искусства, видеофильмы и т. п.
·Ролевой проект. Разработка и реализация такого проекта наиболее сложна. Участвуя в нем, проектанты берут себе роли литературных или исторических персонажей, выдуманных героев с целью воссоздания различных социальных или деловых отношений через игровые ситуации. Результат проекта остается открытым до самого окончания. Чем завершится судебное заседание? Будет ли разрешен конфликт и заключен договор?
Сходство и различие между проектным и процессным управлением
Нередко возникает вопрос, как осуществлять руководство компанией, если новые инициативы после их реализации становятся стандартными процессами. Ведь процессное и проектное управление осуществляется по разным методикам.
Процессы и проекты имеют свои отличия, которые заключаются в следующем:
- Проект создает уникальный конечный результат, это единовременный перечень проводимых мероприятий в рамках конкретного периода времени.
- Бизнес-процесс – это набор мероприятий, которые регулярно повторяются, потребляют необходимые ресурсы и создают необходимый потребителю, но не уникальный продукт.
Именно на уникальности/неуникальности результата и повторяемости/единоразовости действий и проходит разлом между процессом и проектом.
С одной стороны, вроде бы все понятно, однако есть нюансы. Возьмем для примера компанию, производящую автомобили. Конвейерное производство машин – это, несомненно, процесс. Разработка новой модели авто – это проект, т.к. требует дополнительного планирования, новых инженерных и дизайнерских решений, специального оборудования. Такое утверждение хорошо подходит для фирмы, которая создает новые модели один раз в 5-10 лет. Однако если конструкторское бюро автопроизводителя выдает «на гора» каждый год по новой модели, то такая идея приобретает черты процесса по причине установления типовой последовательности действий.
С другой стороны, создание нового бизнес-процесса может приобретать черты проектности, если оно нетипично для данного производителя. Так, начало выпуска старой модели автомобиля на электродвигателе вместо двигателя внутреннего сгорания и внедрение самого производства электродвигателей будут проектом, несмотря на то, что большинство этапов будут носить типовой характер.
Следовательно, можно сделать вывод, что осуществление бизнес-процесса и реализация новой бизнес-идеи в некоторых условиях могут заменять друг друга: типовой проект ближе по показателям к процессу, а новый процесс по своим характеристикам схож с разовой инициативой. Постоянное улучшение продукта или услуги – это не проект, поскольку в него не заложено понятие уникальности.
Это нужно понимать и учитывать в работе, так как принципы управления в обоих случаях разные. Компания, которая способна четко определиться, к какому типу относится ее деятельность, сможет избежать ресурсных и временных потерь при управлении своей деятельностью.
Многие специалисты считают, что опираться только на проектное управление, по крайней мере, недальновидно, поскольку при такой форме руководства трудно оперативно реагировать на быстро меняющиеся условия рынка. Особенно актуально это для промышленных производств, где основная задача – постоянный выпуск продукции определенного качества с небольшими модернизациями в зависимости от желаний заказчика в рамках возможностей наличного оборудования. Здесь нужен процессный менеджмент, если же возникает необходимость разработать и внедрить какую-то разовую технологическую новинку, то рациональнее пригласить для этого замысла руководителя со своей командой со стороны.
Проектный менеджмент хорош для организаций, изначально заточенных на генерирование нестандартных идей и разработок. При этом внедрять их в производство могут совершенно другие компании со стандартными методами руководства.
«RAD Model» (rapid application development model или быстрая разработка приложений)
Модель быстрой разработки приложений включает следующие фазы:
- Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
- Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
- Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
- Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
- Тестирование: тестируются новые компоненты и интерфейсы.
Когда используется RAD-модель?
Описание содержания проекта
В описание проекта входит достаточно высокоуровневое описание того, какие результаты должны быть получены. По большому счету, это следующий уровень детализации того содержания, которые было приведено в уставе проекта
Важно включить сюда то, что требуется сделать или произвести для получения результата. Например, если вы внедряете новую информационную систему, в содержание проекта будет входить:
- Сама система (тут же приводится список ее компонентов).
- Права в системе, настроенные в соответствии с утвержденным бизнес-процессом.
- Техническое обеспечение системы (сервера, подключение на машины пользователей).
- Комплект документации (тут перечень) для поддержки и развития решения.
- Обученные пользователи.
- Обученные специалисты службы поддержки, которые все это добро будут поддерживать.
- Обновленные нормативные документы компании (например, процедура по работе с дебиторами).
Стратегия планирования проектов
- Длительность проекта
- Прямая прибыль от реализованного проекта.
- Косвенная прибыль от реализованного проекта, или сумма изменения дохода компании за 12 месяцев при внедрении продукта созданного в рамках проекта. Экономия ресурсов на выполнении работы – тоже прибыль Организации.
- Стоимость задержки поставки результата в обещанный срок.
- Возможность получения прибыли от разрабатываемого Продукта до завершения всего проекта по созданию Продукта.
- Все ресурсы организации фокусируются на одном прибыльном проекте для сокращения времени его исполнения.
- Проекты каскадируются (выравниваются) по ресурсу-ограничению.
Варианты организации проектного менеджмента в компании
Чтобы внедрить в организации принципы проектного менеджмента стоит подумать о том, как будут решаться межорганизационные, межгрупповые и межличностные конфликты, связанные с организацией горизонтальных и вертикальных систем взаимодействия. Когда возникает необходимость осуществить комплексный замысел, который с одной стороны охватывает деятельность уже имеющихся и функционирующих линейных подразделений, а с другой – решить целый ряд новых задач экономического, социального и технического характера, то необходимо искать самую подходящую организационную форму.
Можно рассмотреть и проанализировать три наиболее часто встречающихся варианта решения проблемы:
Создается целевая группа или специальный отдел по причине того, что существующая структура не готова справиться с новым вызовом. При этом новая структура не способна сама реализовать все процессы без привлечения стандартных линейных подразделений. Власть распределена между исполнителями, однако ответственного за результат нет.
- Один из руководителей стандартных отделов наделяется ответственностью и полномочиями относительно решения новых задач наряду со своими функциональными обязанностями. Но все возникающие проблемные и конфликтные ситуации вынужден решать руководитель более высокого уровня. Распыление ответственности и регулярное вмешательство менеджеров высшего звена разрушительно действует на реализацию начинания.
- Назначается руководитель для реализации новой инициативы и наделяется всей полнотой власти для решения возникающих вопросов. На него возлагается ответственность за оперативное управление, планирование, ресурсное обеспечение и финансирование проекта. Он не связан линейными процессами и работает в направлении достижения определенной цели в соответствии с установленными требованиями (затратами и временем).
Третий вариант наиболее применим в сложных проектах, связанных с большим количеством промежуточных этапов и сложными техническими заданиями (аэрокосмическая, электронная отрасли промышленности, разработки новых технологий).
Исполнение
На этом этапе могут возникнуть трудности: например, сложно правильно распределить очередность выполнения задач. Избежать трудностей поможет ряд простых инструментов:
- Матрица Эйзенхауэра;
- Вычеркивание дел;
- Делегирование;
- Тайм-менеджмент (Хронос и Кайрос).
Работают они только тогда, когда вы их правильно и регулярно (!) применяете. Если человек один раз пробует и у него не получается — это не значит, что инструмент не работает.
Рассмотрим подробнее.
Матрица Эйзенхауэра. Делим дела на срочные, важные, несрочные и неважные.
Первыми делаем срочные важные дела (например, проекты у которых подходит срок сдачи, разрешение кризисов) и срочные неважные (перерывы, телефонные переговоры, некоторые встречи, совещания и т. п.).
Вообще, в управлении бизнесом эффективным считается такой стиль управления, при котором возникает минимальное количество «пожаров». Это показывает, что руководитель умеет планировать дела и предусматривает сложные ситуации.
Далее по значимости следуют несрочные важные дела. К ним может относиться оценка результатов, планирование новых проектов, налаживание отношений, превентивные мероприятия и т. п. Они могут перетекать в срочные важные, поэтому лучше их делать заранее.
Распространенная ошибка — сотрудники и руководители погружаются в не срочные неважные дела (текучка) вместо не срочных важных. Как следствие, горят сроки и нарушаются договоренности
Крайне важно правильно определять важность дел. Для этого можно составить определенные критерии и распределять задачи в соответствии с ними.
Матрицу полезно составлять ежедневно
Это особенно важно для руководителя — он должен уделять время планированию и разработке стратегий развития, а не погружаться в рутинную работу, создавая видимость кипучей деятельности. Когда начальник не делегирует текущие дела сотрудникам, его работа непродуктивна, хотя и объемная.
Вычеркивание дел
Обратите внимание на несрочные и неважные дела — рутинную работу, некоторые письма и звонки. Если эта категория дел ежедневно входит в список, она «засоряет» время: может быть, лучше их полностью исключить? Отказывайтесь от того, что вам не приносит никакой пользы.
Делегирование
Здесь важно учесть:. 1
Поговорка «если хочешь сделать что-то хорошо, делай это сам» очень вредна для бизнеса и карьерного роста. Без делегирования руководителю не обойтись.
1. Поговорка «если хочешь сделать что-то хорошо, делай это сам» очень вредна для бизнеса и карьерного роста. Без делегирования руководителю не обойтись.
2. Всегда составляйте инструкции и полный список задач. Они требуются для четкого понимания сотрудником своих обязанностей и осознания личной ответственности.
3. Все задачи должны быть расписаны по SMART-методу, о котором мы говорили выше.
4. Необходимо убедиться, что цели поняты исполнителем.
5. Нужно проводить периодический контроль и требовать отчетность.
Оптимальное распределение времени или «Хронос-Кайрос». Хронос — линейное планирование по часам (дела планируются на конкретное время); Кайрос — событийное планирование (например, во время поездки по городу встречается магазин, где можно сделать покупки, поэтому можно отклониться от маршрута, это и есть гибкое планирование).
1. Планируйте дела заранее в хронологическом порядке — встречи, совещания и т.д.
2. Заносите эти дела в календарь, установленный у вас в смартфоне (например, в Google Календарь).
3. Отдельно составляйте список дел, которые вы выполните при наступлении определённых событий.
4. Всегда имейте все планы в текстовом виде — желательно «в облаке», чтобы они были доступны с любого мобильного устройства.