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

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

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

• Поинтересовался, почему расстались с предыдущим разработчиком, на какой ноте, кто это был. Навел бы справки. По возможности переговорил с разработчиком, составил своё мнение.

• Получил от клиента предварительный список требований и задач. Рассказал всю процедуру и риски. Нужно будет время вникнуть в чужой код. Возможно, его придется весь выкинуть, и всё сделать сначала. Первое время наша скорость будет ниже, чем у предыдущей команды, и у нас будет больше ошибок, потому что мы не знаем всех взаимосвязей. Также обсудил условия, при которых можно попробовать взяться за задачу.

• Грубо оценил (вилочно, от-до), получил подтверждение у клиента, что бюджет в целом — ок.

• Согласовал работу по Time&Material. Работать с чужим проектом по Fixed Price — самоубийство. Выяснил, сколько примерно часов готов выкупать клиент в будущем и какие глобально есть планы. Разовый, короткий контракт, отношения на одну ночь меня бы не заинтересовали — в этом случае лучше закончить проект с предыдущей командой.

• Запросил доступы к коду.

• Провел код-ревью — процедуру анализа и оценки качества кода.

• Изучил текущую документацию. Если документации нет — это тоже критерий.

• Принял решение, можно ли работать с текущим кодом, или нужно выбросить и всё делать с нуля.

• Законтрактовался.

• Получил предоплату.

• Доуточнил требования. Собрал их в Бэклог. Отсортировал по приоритетам. Организовал работу спринтами.

  • Нарисовал прототипы. Сдал клиенту.

  • Нарисовал дизайн, если задача это предполагает. Также сдал клиенту.

  • Ещё раз проговорил голосом результат с заказчиком, убедился, что мы всё одинаково понимаем.

  • Доформировал требования на уровне задач в тикет-системе, с учетом изменений, которые появились на дизайне и прототипе. Обычно это мелочи, но иногда все разворачивается на 180.

  • Дал вычитать требования разработчикам.

  • Проговорил задачи голосом с командой, разобрал вопросы. Получил оценки от команды, например, методом Planning Poker.

  • При необходимости, провел рисёрч. Это нужно на задачах, с которыми команда никогда не сталкивалась.

  • Запланировал разработку в календарном плане.

  • Написал тест-кейсы или критерии приемки по каждой из задач.

  • Запрограммировал. Следил за ходом работ, решал “затыки”.

  • По итогам разработки провел код-ревью нового кода.

  • Протестировал, исправил баги.

  • Проверил производительность.

  • Сдал заказчику на тестовом сервере, получил и обработал обратную связь. Мелочевку исправил сразу, остальное перенес в будущие спринты.

  • Провел ретроспективу с командой, посмотрел, что можно улучшить в проекте и процессах работы.

  • Актуализировал документацию.

  • Провел деплой (выкладку на боевые сервера).

  • Обновил контент.

  • Проверил работу на боевом сервере.

  • Подписал акты, получил постоплату.

• Выяснил, что ещё хотел бы клиент, повторил бы цикл. Сам предложил улучшения проекта: по коду, функциям, дизайну, юзабилити.

• Организовал работу по мелко-срочным тикетам (по более дорогой ставке), которые клиент не готов ждать, но они отвлекают команду от спринта.

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

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

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

Начало |