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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Начало |