Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 25)
4. В случае если позиция стейкхолдера по отношению к проекту меняется или может измениться, производится перестановка задач таким образом, чтобы выполненные в ближайшее время задачи лучше соответствовали изменившимся представлениям стейкхолдера.
5. Пункты 2–4 проделываются регулярно, а в идеале – ежедневно.
Результат. Измененная диаграмма Ганта, динамически подгоняемая под настроения стейкхолдеров.
В метафоре с самолетом проект «летит» не в безвоздушном пространстве, а в условиях попутных и встречных ветров, сильно влияющих на скорость продвижения. Благоприятное отношение стейкхолдеров (появляющееся лишь при демонстрации им значимых в данный момент результатов) – попутный ветер, который нужно уметь предсказывать и ловить.
3.2. Управление процессом
Теперь, когда содержание проекта понятно до уровня основных задач, можно наконец приступить и к его выполнению. Для этого необходимо запустить процесс выполнения проекта – то есть регулярно определять, кто чем будет заниматься, и фиксировать полученные результаты. Поскольку задач и разработчиков много, очень важно поддерживать процесс в рабочем режиме: когда все разработчики заняты, и при этом задачи упорядочены так, чтобы минимизировать риски проекта. Поскольку ситуация в проекте постоянно меняется, поддержание рабочего состояния проекта требует постоянного управления процессом – принятия решений о действиях и контроля их результатов.
В то же время управление процессом не означает, что ПМ должен постоянно раздавать указания и понукать разработчиков – «интегрируй с ХХХ». Идеальное управление достигается только тогда, когда ПМ
1) синхронизации действий (расписанию);
2) распределению действий между разработчиками (планированию);
3) мониторингу результатов;
4) координации совместной (групповой) работы;
5) найму и увольнениям разработчиков;
6) и самое главное – обеспечению высокой репутации как лично своей, так и проекта в целом.
Для каждого из этих объектов в DaShe предусмотрены соответствующие методы.
Метафора управления процессом в DaShe – «хороший админ», у которого все управление информационной системой осуществляется давно написанными скриптами, а сам он «пьет кофе и ничего не делает» (на самом деле нет, он пишет следующие скрипты).
Расписание – представленный в какой-либо форме (доска канбан, список, таблица и т. п.) перечень заданий с ожидаемым временем выполнения и способом контроля результата. Для составления расписания необходимо разбить определенные ранее задачи на несколько (одно или больше) заданий и определить плановые затраты времени на их выполнение.
Составление расписания – деятельность, требующая умения разбивать задачи на подзадачи и оценивать (самостоятельно или с помощью покер-планирования) время их выполнения. Заниматься этим должен разработчик, обладающий максимальной компетенцией в декомпозиции задач и оценке их трудоемкости
1. ПМ определяет продолжительность этапа. Основной смысл разбития проекта на этапы заключается в защите разработчиков – в ходе всего этапа они занимаются только запланированными заданиями и могут свободно перераспределять свое время, не опасаясь, что начальство заставит делать что-то еще. Разработчики объективно заинтересованы в как можно более продолжительных этапах («сделал месячный план за неделю, и можно отдыхать»), а ПМ – в как можно менее продолжительных (корректировка планов возможна только в ходе планирования следующего этапа). Поэтому продолжительность этапа устанавливается как минимум, на который согласятся разработчики, но не меньше одной недели.
2. ПМ отбирает из бэклога (диаграммы Ганта) задачи для решения на текущем этапе. После этого определяется тимлид этапа – разработчик, лучше всего разбирающийся в технологиях, требуемых для решения отобранных задач. (Тимлид берется только на один этап, потому что, например, для бэкенда и для фронтенда нужны разные тимлиды.) ПМ разъясняет тимлиду его права и обязанности, а также мотивирует на работу по составлению расписания.
3. ПМ и тимлид проводят декомпозицию задач на отдельные задания. Формулируются требования и критерии выполнения. При необходимости привлекаются остальные разработчики, но не в формате общего совещания, а в диалоге «вопрос – ответ».
4. Тимлид оценивает время выполнения заданий. В случае если он хорошо знает производительность исполнителя, которому будет поручено задание, оценка производится исходя из предшествующего опыта. Для этого тимлид использует статистику выполнения предыдущих заданий, ведение которой входит в его должностные обязанности. Если знаний недостаточно, проводится совещание со всеми разработчиками, оценка производится методом покер-планирования.
5. В случае если суммарное время заданий укладывается в плановые сроки для задач, определяется последовательность выполнения заданий (назначается приоритет). Если не укладывается – производится возврат на этап 2, и декомпозиция задач проводится заново, с корректировкой требований, после чего пункты 3–5 повторяются.
Результат. Перечень заданий, каждое – с плановым временем выполнения, точно сформулированными критериями завершения и приоритетом (порядком) выполнения.
В традиционном SCRUM этому этапу соответствует «подготовка к планированию спринта».
Составленное расписание не будет мотивировать команду, если разработчики не воспримут его как правильное и выполнимое. Поэтому после составления расписания необходимо провести планирование этапа, в ходе которого расписание может (и, вообще говоря, должно) поменяться.
1. Планирование производится в ходе длительного совещания (до четырех часов) ПМ, тимлида, всех разработчиков (с учетом групповой работы, см. 3.2.4) и (даже!) заинтересованных в текущем этапе стейкхолдеров.
2. Входящая информация для планирования: бэклог (диаграмма Ганта) проекта; текущее состояние проекта (результат предыдущего этапа); статистика производительности команды; составленное предварительное расписание.
3. Каждому из участников совещания предлагается высказать замечания по входящей информации:
1) правильно ли отобраны задачи для этапа (может быть, слишком мало или слишком много?);
2) правильно ли они декомпозированы на задания;
3) правильно ли определена последовательность выполнения;
4) нет ли заниженных или завышенных требований;
5) правильно ли определена трудоемкость заданий;
6) правильно ли назначены исполнители заданий (в тех случаях, когда они уже назначены);
7) каких исполнителей лучше назначить на задания, где они еще не определены.
4. В случае возникновения противоречащих мнений проводится (методом покер-планирования) стыковка встречных предложений (увеличить время там, сократив здесь; поменяться заданиями; увеличить требования там, сократив здесь; и т. д.). Откорректированные задания поручаются конкретным исполнителям.
5. Формулируется общая цель этапа в терминах элементов продукта («Когда мы закончим этап, у нас будет работать А, Б и В!»).
6. Цель, задачи этапа и персонализированные задания выносятся на «доску проекта».
Результат. Перечень заданий, с конкретными исполнителями, плановым временем выполнения и точно сформулированными критериями выполнения – на «доске проекта».
Канбан представляет собой систему управления потоком задач, обеспечивающую постоянное информирование всех разработчиков о том, какое задание кто в данный момент выполняет, куда передаст его результаты и какое задание будет выполнять после. Обычно под канбаном понимается доска, состоящая из нескольких вертикальных секций (например, «сделать», «в работе», «сделано»), по которым перемещаются конкретные задания. Однако пользовательская ценность доски заключается вовсе не в отображении состояния всех заданий этапа (от них, как правило, в глазах рябит и никакой особой наглядности не получается), а в возможности быстро посмотреть, кто чем сейчас занят, а по окончании этапа – оценить, насколько честно каждый разработчик прогнозирует свои трудозатраты по выполнению отдельных заданий (оценить «фокус-фактор»).
Для оперативного мониторинга выполнения заданий рекомендуется выбрать подходящую автоматизированную систему (
1. Задания с «доски проекта» переносятся в автоматизированную систему с сохранением приоритетов, планового времени и критериев завершения. Система должна обеспечивать единственность задания у одного исполнителя в один момент. Это принципиально важно, поскольку любое дополнительное задание, даже если оно не выполняется, рассеивает внимание и значительно снижает производительность. Значительно – это не на проценты, а в разы!