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