Любой, кто стал руководителем проекта, не важно было ли это результатом собеседований, перехода или решением руководства сталкивался с этим вопросом. Что делать? Существует большое количество источников, описывающих различные методы и фреймворки. Цель этой статьи дать алгоритм конкретных действий.
Он появился как результат структурирования знаний о проектном управлении, а также путем практического опыта при ведении десятка различных проектов от небольших сайтов, до uber-like сервиса и государственной системы.
Выражаю благодарность участникам сообществ Agile, Scrum, Lean, Kanban, XP и Kanban Talks за участие в развитии моих знаний и PM Lunch за помощь в написании алгоритма.
Зачем нужен алгоритм?
Некоторые читатели наверняка задались вопросом, зачем нужен очередной фреймворк или метод? Ведь уже есть Scrum, Kanban, RUP, DSDM и т.д.
Цель статьи не декларировать серебряную пулю, а дать простой алгоритм действий, следуя которому руководитель проекта сможет держать процесс под контролем. Алгоритм не противоречит моделям разработки, но наиболее применим к инкрементальным и итерационным.
Советую для начала попробовать его применить по принципу “шухари”. Если вы новичок, то применяйте его в чистом виде. Но при этом стоит продолжать руководствоваться здравым смыслом.
К чему применим?
Это именно алгоритм, а не фреймворк или методология, он дает список практических действий в формате «делай так и будет хорошо». Для удобства он рассмотрен на распространенном практическом кейсе — заказной разработке ПО.
Он наиболее применим для разработки кастомных мобильных, веб и десктоп приложений с высокой неопределенностью и вариативностью требований, но также может подойти для любого проекта по производству нематериального продукта.
Кто знает, вдруг кто-то решит по нему построить дом, хе-хе.
Суть алгоритма
Алгоритм состоит из шагов, каждый из которых служит описанием конкретных действий которые должен выполнять руководитель проекта. Шаги структурированы в фазы проекта, некоторые из которых разбиты на подфазы. Таким образом покрываются все этапы жизненного цикла проекта, от старта и до завершения. Всего в алгоритме приведено 24 шага.
Алгоритм получился довольно объемным, поэтому с его полным текстом вы можете ознакомиться по ссылке ниже. Документ открыт для комментирования, поэтому если вы хотите внести свой вклад, то буду рад услышать вашу критику или предложения.
Как его можно использовать?
Изначально алгоритм задумывался как план действий именно для руководителей проектов, но у него есть также следующие варианты использования:
- Прочитать и узнать много нового. В тексте алгоритма приводится большое количество профессионализмов, ознакомиться подробнее с которыми вы можете в конце алгоритма;
- Показать руководству, чтобы объяснить, как происходит управление проектом;
- Показать клиенту, чтобы объяснить для чего нужен PM и почему он будет под контролем;
- Распечатать и использовать как чек лист ежедневных действий для PM;
- Обсудить с командой проекта и вместе внедрить новые практики;
- Прочитать HR, чтобы узнать чем конкретно занимается руководитель проекта и в чем отличия от Product Manager/Product Owner/Team Lead/Sales Manager/Business Analyst.
Субъективное мнение.
Компания, которую удовлетворяет то, что project-manager не знает ничего, кроме курса менеджмента с университета:
1. Обречена на провал.
2. Не оценит "профессионализмы"
3. Новаторство не оценит должным образом.
На сколько я знаю, алгоритмы в рабочей деятельности применяют многие специалисты, причем пишут их сами. Они же скажут что от алгоритмы, как бы хорошо они не были бы написаны, работают не в 100% случаев.
Поэтому, ничего нового. Лучше читайте и разбирайтесь сами в своей теме, а не ищите готовых решений.
Действительно, в алгоритме нет ничего нового, но оно описано таким образом, чтобы это было легко использовать на практике.
Я тестировал этот алгоритм в 2 компаниях на более чем 10 проектах, то я привел статье его упрощенная версия.
А с чего вы решили, что речь идет именно о студентах? Я знаю большое количество менеджеров, которые используют микроменеджмент и все держится на них.
Профессионализмы указаны для того, чтобы было понятно, куда копать, это ключевые слова.
Я назвал это алгоритмом, так как оно явно не тянет на методологию или фреймворк. Почему вы считаете что эти наборы практик не работают? Существует прекрасно зарекомендовавшие себя scrum и kanban, но неподготовленному человеку тяжело их использовать.
А что сложного с Канбан?
У меня имеется в виду именно канбан-метод. Который вот этот
Обычно с большой буквы "Канбан" как метод/методология/фреймворк, с маленькой "канбан" как доска.
Если не полноценный Канбан, то прото-Канбан внедряется довольно быстро, легко понимается командой и требует минимум накладных расходов.
Извиняюсь, написал с маленькой. Я имел в виду полноценный Канбан здорового человека со STATIK и нормальными каденциями.
Да ничего страшного, главное правильно друг друга поняли!-)
По прежнему не вижу ничего страшного/сложного во внедрении прото-Канбана и его дальнейшего эволюционного совершенствования в ходе проекта, хотя если это длительный проект с хорошим ресурсным обеспечением, то стоит рассмотреть и скрам.
Для меня и судя по всему для вас нет ничего сложного. Но вот для большинства компаний (по крайней мере с которыми я сталкивался) это не так.
Мне кажется, что в большинстве случаев просто нет достаточной мотивации/желания начать использовать. Возможно это обусловлено страхом перед сложностью методологии, рисками сорвать уже налаженные процессы и т.п.
С другой стороны, если появляется менеджер проекта, то такое желание видимо есть!-)
Отлично сказано. Я вот и рассчитываю на то, чтобы дать таким же проджектам чеклист действий, используя которые можно управлять проектом. Также специально пишу ключевые слова и обозначаю методы, чтобы было куда копать дальше.
Ну и Канбан нельзя внедрять, его можно только использовать) Полноценный применять действительно тяжело именно из-за того, что он не дает полного ответа, как надо работать. Канбан ведь применяют поверх того что есть.
Я описал ситуацию, когда приходит проджект, а нет ничего, хаос.
"Я описал ситуацию, когда приходит проджект, а нет ничего, хаос." - из статьи явно этого не увидел.
Понятно, что всем нравится "начинать с нуля", а приходить в идущий проект всегда больно, т.к. что-то уже "сложилось", "принято" и т.п., шестеренки притерлись и крутятся, на любое изменение идет обратная связь о возможных срывах сроков и т.п.
Ну в начале статьи как раз и указано, что она ориентируется на тех, кто не знает что делать, а им нужно уже управлять проектом. Фреймворки типа scrum или rup таких ответов не дают.
Ну если вы под канбан имеете в виду не распространенное заблуждение в виде доски со стикерами, а именно канбан-метод, то тогда это сложно.
В глоссарии вижу "Цель дня - результат, на который ориентируется команда к завершению рабочего дня" (очень неудобно, что копирование запрещено). Это намек на дневные спринты для команды?
Нет, это намек на отличную практику скрама, такую как цель дня.
Мне казалось, что проект-менеджер не вмешивается в работу команды разработки после начала спринта. Отбор задач для спринта - да, но дальше какой смысл что сделает команда сегодня, завтра или послезавтра, если результат в конце спринта и в идеале команда придет к нему? Зачем тогда говорить о задачах дня?
Это не более чем рекомендация, как бест практис. Ее смысл не в том, что говорить разработчикам что делать, а просто в обозначении типа "хей, сегодня мы с вами набрали задачек связанных с календарем, наша цель дня закрыть их всех и отправить календарь в прод".
быстрее закончу проект, пока дочитаю до конца))
Вы уверены? Материал небольшой и читается за 15 минут. Проекты явно не так быстро делаются)
аргумент!
ушел читать)
Советую потом немного порефлексировать, где применим такой подход. А также задуматься, почему в самом начале алгоритма вынесены некоторые процессы и написано, что они выходят за рамки. Еще будет здорово, если вы задумаетесь, а что конкретно этот алгоритм взял из Scrum и Kanban, как он адаптирует цикл демминга и в каких шагах какие области знаний по PMBoK используются)
Комментарий удален модератором
Очень плохая реклама. Минимум информативности и value proposition.
Почему это здесь? Что это? Зачем это мне? Почему я? Да таких вопросов миллион