Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Ее главная задача – отчуждение знаний о проекте из голов конкретных исполнителей. Документация снижает риски.

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

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

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

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

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

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

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

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

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

? Изучил текущую документацию. Если документации нет – это тоже показатель.

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

? Подписал контракт.

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

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

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

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

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

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

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

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