Продолжаю потихоньку публиковать избранные параграфы из книжки Управление digital-проектами. Ссылки на предыдущие части — в конце материала.

Итак, мы героически вляпались в задачу “довести сайт до ума”. Как бы я действовал (кое-где — чужим руками)?

Поинтересовался, почему расстались с предыдущим разработчиком, на какой ноте, кто это был. Навел бы справки. По возможности переговорил с разработчиком, составил своё мнение.
Получил от клиента предварительный список требований и задач. Рассказал всю процедуру и риски. Нужно будет время вникнуть в чужой код. Возможно, его придется весь выкинуть, и всё сделать сначала. Первое время наша скорость будет ниже, чем у предыдущей команды, и у нас будет больше ошибок, потому что мы не знаем всех взаимосвязей. Также обсудил условия, при которых можно попробовать взяться за задачу.
Грубо оценил (вилочно, от-до), получил подтверждение у клиента, что бюджет в целом — ок.
Согласовал работу по Time&Material. Работать с чужим проектом по Fixed Price — самоубийство. Выяснил, сколько примерно часов готов выкупать клиент в будущем и какие глобально есть планы. Разовый, короткий контракт, отношения на одну ночь меня бы не заинтересовали — в этом случае лучше закончить проект с предыдущей командой.
Запросил доступы к коду.
Провел код-ревью — процедуру анализа и оценки качества кода.
Изучил текущую документацию. Если документации нет — это тоже критерий.
Принял решение, можно ли работать с текущим кодом, или нужно выбросить и всё делать с нуля.
Законтрактовался.
Получил предоплату.
Доуточнил требования. Собрал их в Бэклог. Отсортировал по приоритетам. Организовал работу спринтами.
- Нарисовал прототипы. Сдал клиенту.
- Нарисовал дизайн, если задача это предполагает. Также сдал клиенту.
- Ещё раз проговорил голосом результат с заказчиком, убедился, что мы всё одинаково понимаем.
- Доформировал требования на уровне задач в тикет-системе, с учетом изменений, которые появились на дизайне и прототипе. Обычно это мелочи, но иногда все разворачивается на 180.
- Дал вычитать требования разработчикам.
- Проговорил задачи голосом с командой, разобрал вопросы. Получил оценки от команды, например, методом Planning Poker.
- При необходимости, провел рисёрч. Это нужно на задачах, с которыми команда никогда не сталкивалась.
- Запланировал разработку в календарном плане.
- Написал тест-кейсы или критерии приемки по каждой из задач.
- Запрограммировал. Следил за ходом работ, решал “затыки”.
- По итогам разработки провел код-ревью нового кода.
- Протестировал, исправил баги.
- Проверил производительность.
- Сдал заказчику на тестовом сервере, получил и обработал обратную связь. Мелочевку исправил сразу, остальное перенес в будущие спринты.
- Провел ретроспективу с командой, посмотрел, что можно улучшить в проекте и процессах работы.
- Актуализировал документацию.
- Провел деплой (выкладку на боевые сервера).
- Обновил контент.
- Проверил работу на боевом сервере.
- Подписал акты, получил постоплату.
Выяснил, что ещё хотел бы клиент, повторил бы цикл. Сам предложил улучшения проекта: по коду, функциям, дизайну, юзабилити.
Организовал работу по мелко-срочным тикетам (по более дорогой ставке), которые клиент не готов ждать, но они отвлекают команду от спринта.

Жуть, этот план даже читать больно! А ведь вам завтра крутить окровавленную и облитую слезами ручку заказной digital-разработки :)

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

Этот материал — черновик книги по управлению digital-проектами. Автор заранее приносит извинения за возможные неточности. Любая конструктивная обратная связь приветствуется. Продолжение следует.

Начало | #003

#002. Прогулка по картине мира