#002. Пройтись По Картине Мира

Продолжаю потихоньку публиковать избранные параграфы из книги «Управление цифровыми проектами».

Ссылки на предыдущие части находятся в конце материала.

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

#002. Пройтись по картине мира

Я спросил, почему они расстались с предыдущим разработчиком, на какой ноте, кто это был.
Я бы навел справки.
Если было возможно, я поговорил с разработчиком и сформировал свое мнение.
Получил предварительный список требований и задач от клиента.
Объяснил всю процедуру и риски.
Чтобы понять чужой код, потребуется время.
Возможно, вам придется выбросить все это и сделать все заново.
Сначала наша скорость будет ниже, чем у предыдущей команды, и ошибок у нас будет больше, потому что мы не знаем всех взаимосвязей.
Также я обсудил условия, при которых можно попробовать взяться за задание.
Примерно прикинул (вилка, от-до), получил подтверждение от клиента, что бюджет в целом ок.
Координировал работу над Time&Material. Работать с чужим проектом по фиксированной цене — самоубийство.
Я узнал примерно, сколько часов клиент готов купить в будущем и какие у него глобальные планы.
Разовый, короткий контракт, связь на одну ночь меня бы не заинтересовали — в этом случае лучше закончить проект с предыдущей командой.
Запрошен доступ к коду.
Провёл code review — процедуру анализа и оценки качества кода.
Я изучил текущую документацию.
Если документации нет – это тоже критерий.
Я решил, можно ли работать с текущим кодом или стоит его выбросить и сделать все с нуля.
Я подписал контракт.
Я получил предоплату.
Я уточнил требования.
Я собрал их в Backlog. Сортировка по приоритету.
Организовал работу в спринтах.
- Я рисовал прототипы.
  Я передал его клиенту.
- Нарисовал дизайн, если того требует задача.
  Также передан клиенту.
- Я еще раз проговорил результат с заказчиком и убедился, что мы все поняли одинаково.
- Доработал требования на уровне задач в тикет-системе с учетом изменений, появившихся в дизайне и прототипе.
  Обычно это мелочи, но иногда всё переворачивается на 180.
- Я позволил разработчикам прочитать требования.
- Обговаривал задачи голосом с командой и разбирал вопросы.
  Получал оценки от команды, например, с помощью метода Planning Poker.
- При необходимости проводятся исследования.
  Это нужно для задач, с которыми команда никогда раньше не сталкивалась.
- Планировал развитие в календарном плане.
- Написал тестовые примеры или критерии приемки для каждой задачи.
- Запрограммировано.
  Следил за ходом работ, решал проблемы.
- По результатам разработки я провел ревью нового кода.
- Протестированы и исправлены ошибки.
- Проверил работоспособность.
- Отдал заказчику на тестовый сервер, получил и обработал обратную связь.
  Некоторые мелочи я исправил сразу, а остальное отложил на будущие спринты.
- Провели ретроспективу с командой, посмотрели, что можно улучшить в проекте и рабочих процессах.
- Обновленная документация.
- Проведено развертывание (загрузка на действующие серверы).
- Обновленный контент.
- Проверил работу на производственном сервере.
- Я подписал документы и получил постоплату.
Я узнал, чего еще хочет клиент, и повторил цикл.
Он сам предлагал улучшения проекта: по коду, функциям, дизайну, удобству использования.
Организованная работа по мелкосрочным заявкам (по более дорогому тарифу), которые клиент не готов ждать, но они отвлекают команду от спринта.

Это ужасно, этот план даже читать больно! Но завтра вам придется повернуть окровавленное и заплаканное перо заказной цифровой разработки :)

В общем, менеджеру здесь есть чем заняться.

При этом ценность большинства из них воспринимается клиентом весьма неопределенно.

И было бы неплохо что-то делегировать.

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

Продолжение следует. Начинать | #003 Теги: #Управление проектами #Управление персоналом #agile #scrum #управление проектами