{"id":13472,"url":"\/distributions\/13472\/click?bit=1&hash=4a05616fb570ab538ab8c04fa1f08afa00a090b2c2700fcd6146507f1b1658df","title":"\u041a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0431\u043e\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0435 \u0431\u0443\u0434\u0435\u0442 \u0431\u0435\u0441\u0438\u0442\u044c \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}

Теперь я Project Manager – что делать?

Любой, кто стал руководителем проекта, не важно было ли это результатом собеседований, перехода или решением руководства сталкивался с этим вопросом. Что делать? Существует большое количество источников, описывающих различные методы и фреймворки. Цель этой статьи дать алгоритм конкретных действий.

Методологии управления проектами глазами обывателя Irina Kukhterina

Он появился как результат структурирования знаний о проектном управлении, а также путем практического опыта при ведении десятка различных проектов от небольших сайтов, до uber-like сервиса и государственной системы.

Выражаю благодарность участникам сообществ Agile, Scrum, Lean, Kanban, XP и Kanban Talks за участие в развитии моих знаний и PM Lunch за помощь в написании алгоритма.

Зачем нужен алгоритм?

Некоторые читатели наверняка задались вопросом, зачем нужен очередной фреймворк или метод? Ведь уже есть Scrum, Kanban, RUP, DSDM и т.д.

Цель статьи не декларировать серебряную пулю, а дать простой алгоритм действий, следуя которому руководитель проекта сможет держать процесс под контролем. Алгоритм не противоречит моделям разработки, но наиболее применим к инкрементальным и итерационным.

Советую для начала попробовать его применить по принципу “шухари”. Если вы новичок, то применяйте его в чистом виде. Но при этом стоит продолжать руководствоваться здравым смыслом.

К чему применим?

Это именно алгоритм, а не фреймворк или методология, он дает список практических действий в формате «делай так и будет хорошо». Для удобства он рассмотрен на распространенном практическом кейсе — заказной разработке ПО.

Он наиболее применим для разработки кастомных мобильных, веб и десктоп приложений с высокой неопределенностью и вариативностью требований, но также может подойти для любого проекта по производству нематериального продукта.

Кто знает, вдруг кто-то решит по нему построить дом, хе-хе.

Суть алгоритма

Алгоритм состоит из шагов, каждый из которых служит описанием конкретных действий которые должен выполнять руководитель проекта. Шаги структурированы в фазы проекта, некоторые из которых разбиты на подфазы. Таким образом покрываются все этапы жизненного цикла проекта, от старта и до завершения. Всего в алгоритме приведено 24 шага.

Концепция алгоритма

Алгоритм получился довольно объемным, поэтому с его полным текстом вы можете ознакомиться по ссылке ниже. Документ открыт для комментирования, поэтому если вы хотите внести свой вклад, то буду рад услышать вашу критику или предложения.

Как его можно использовать?

Изначально алгоритм задумывался как план действий именно для руководителей проектов, но у него есть также следующие варианты использования:

  1. Прочитать и узнать много нового. В тексте алгоритма приводится большое количество профессионализмов, ознакомиться подробнее с которыми вы можете в конце алгоритма;
  2. Показать руководству, чтобы объяснить, как происходит управление проектом;
  3. Показать клиенту, чтобы объяснить для чего нужен PM и почему он будет под контролем;
  4. Распечатать и использовать как чек лист ежедневных действий для PM;
  5. Обсудить с командой проекта и вместе внедрить новые практики;
  6. Прочитать HR, чтобы узнать чем конкретно занимается руководитель проекта и в чем отличия от Product Manager/Product Owner/Team Lead/Sales Manager/Business Analyst.
Применение проектного управления в личной жизни Летюшев Артем
0
24 комментария
Написать комментарий...
Andreas Blokh

Субъективное мнение.
Компания, которую удовлетворяет то, что project-manager не знает ничего, кроме курса менеджмента с университета:
1. Обречена на провал.
2. Не оценит "профессионализмы"
3. Новаторство не оценит должным образом.

На сколько я знаю, алгоритмы в рабочей деятельности применяют многие специалисты, причем пишут их сами. Они же скажут что от алгоритмы, как бы хорошо они не были бы написаны, работают не в 100% случаев.
Поэтому, ничего нового. Лучше читайте и разбирайтесь сами в своей теме, а не ищите готовых решений.

Ответить
Развернуть ветку
Артем Летюшев
Автор

Действительно, в алгоритме нет ничего нового, но оно описано таким образом, чтобы это было легко использовать на практике.

Я тестировал этот алгоритм в 2 компаниях на более чем 10 проектах, то я привел статье его упрощенная версия.

Ответить
Развернуть ветку
Артем Летюшев
Автор

А с чего вы решили, что речь идет именно о студентах? Я знаю большое количество менеджеров, которые используют микроменеджмент и все держится на них. 

Профессионализмы указаны для того, чтобы было понятно, куда копать, это ключевые слова.
Я назвал это алгоритмом, так как оно явно не тянет на методологию или фреймворк. Почему вы считаете что эти наборы практик не работают? Существует прекрасно зарекомендовавшие себя scrum и kanban, но неподготовленному человеку тяжело их использовать.

Ответить
Развернуть ветку
Alexey Kuznetsov

А что сложного с Канбан?

Ответить
Развернуть ветку
Артем Летюшев
Автор

У меня имеется в виду именно канбан-метод. Который вот этот 

Ответить
Развернуть ветку
Alexey Kuznetsov

Обычно с большой буквы "Канбан" как метод/методология/фреймворк, с маленькой "канбан" как доска.

Если не полноценный Канбан, то прото-Канбан внедряется довольно быстро, легко понимается командой и требует минимум накладных расходов.

Ответить
Развернуть ветку
Артем Летюшев
Автор

Извиняюсь, написал с маленькой. Я имел в виду полноценный Канбан здорового человека со STATIK и нормальными каденциями.

Ответить
Развернуть ветку
Alexey Kuznetsov

Да ничего страшного, главное правильно друг друга поняли!-)

По прежнему не вижу ничего страшного/сложного во внедрении прото-Канбана и его дальнейшего эволюционного совершенствования в ходе проекта, хотя если это длительный проект с хорошим ресурсным обеспечением, то стоит рассмотреть и скрам.

Ответить
Развернуть ветку
Артем Летюшев
Автор

Для меня и судя по всему для вас нет ничего сложного. Но вот для большинства компаний (по крайней мере с которыми я сталкивался) это не так.

Ответить
Развернуть ветку
Alexey Kuznetsov

Мне кажется, что в большинстве случаев просто нет достаточной мотивации/желания начать использовать. Возможно это обусловлено страхом перед сложностью методологии, рисками сорвать уже налаженные процессы и т.п.

С другой стороны, если появляется менеджер проекта, то такое желание видимо есть!-)

Ответить
Развернуть ветку
Артем Летюшев
Автор

Отлично сказано. Я вот и рассчитываю на то, чтобы дать таким же проджектам чеклист действий, используя которые можно управлять проектом. Также специально пишу ключевые слова и обозначаю методы, чтобы было куда копать дальше.

Ответить
Развернуть ветку
Артем Летюшев
Автор

Ну и Канбан нельзя внедрять, его можно только использовать) Полноценный применять действительно тяжело именно из-за того, что он не дает полного ответа, как надо работать. Канбан ведь применяют поверх того что есть.

Я описал ситуацию, когда приходит проджект, а нет ничего, хаос.

Ответить
Развернуть ветку
Alexey Kuznetsov

"Я описал ситуацию, когда приходит проджект, а нет ничего, хаос." - из статьи явно этого не увидел.

Понятно, что всем нравится "начинать с нуля", а приходить в идущий проект всегда больно, т.к. что-то уже "сложилось", "принято" и т.п., шестеренки притерлись и крутятся, на любое изменение идет обратная связь о возможных срывах сроков и т.п.

Ответить
Развернуть ветку
Артем Летюшев
Автор

Ну в начале статьи как раз и указано, что она ориентируется на тех, кто не знает что делать, а им нужно уже управлять проектом. Фреймворки типа scrum или rup таких ответов не дают.

Ответить
Развернуть ветку
Артем Летюшев
Автор

Ну если вы под канбан имеете в виду не распространенное заблуждение в виде доски со стикерами, а именно канбан-метод, то тогда это сложно.

Ответить
Развернуть ветку
Alexey Kuznetsov

В глоссарии вижу "Цель дня - результат, на который ориентируется команда к завершению рабочего дня" (очень неудобно, что копирование запрещено). Это намек на дневные спринты для команды?

Ответить
Развернуть ветку
Артем Летюшев
Автор

Нет, это намек на отличную практику скрама, такую как цель дня.

Ответить
Развернуть ветку
Alexey Kuznetsov

Мне казалось, что проект-менеджер не вмешивается в работу команды разработки после начала спринта. Отбор задач для спринта - да, но дальше какой смысл что сделает команда сегодня, завтра или послезавтра, если результат в конце спринта и в идеале команда придет к нему? Зачем тогда говорить о задачах дня?

Ответить
Развернуть ветку
Артем Летюшев
Автор

Это не более чем рекомендация, как бест практис. Ее смысл не в том, что говорить разработчикам что делать, а просто в обозначении типа "хей, сегодня мы с вами набрали задачек связанных с календарем, наша цель дня закрыть их всех и отправить календарь в прод".

Ответить
Развернуть ветку
Начинатель

быстрее закончу проект, пока дочитаю до конца))

Ответить
Развернуть ветку
Артем Летюшев
Автор

Вы уверены? Материал небольшой и читается за 15 минут. Проекты явно не так быстро делаются)

Ответить
Развернуть ветку
Начинатель

аргумент! 
ушел читать)

Ответить
Развернуть ветку
Артем Летюшев
Автор

Советую потом немного порефлексировать, где применим такой подход. А также задуматься, почему в самом начале алгоритма вынесены некоторые процессы и написано, что они выходят за рамки. Еще будет здорово, если вы задумаетесь, а что конкретно этот алгоритм взял из Scrum и Kanban, как он адаптирует цикл демминга и в каких шагах какие области знаний по PMBoK используются)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Артем Летюшев
Автор

Очень плохая реклама. Минимум информативности и value proposition.

Почему это здесь? Что это? Зачем это мне? Почему я? Да таких вопросов миллион

Ответить
Развернуть ветку
Читать все 24 комментария
null