Скачать книгу

выпуска продукта.

      ▶ Большинство проектов взаимодействуют с Внешними сервисами. Например, авторизуют пользователей через социальные сети или рассчитывают стоимость доставки товара. Для этого разработчики выполняют интеграцию через API. Подробности в главе 10.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      ☐ Написал

Скачать книгу