зависимости задач. Если же вы работаете в мультипроектной среде – приходится учитывать загрузку команды на других проектах. Тут помогут сетевые графики, теория ограничений и метод освоенного объема из главы 5.
Проект. Это набор артефактов, в основном – файлов:
▶ Код, как правило, в репозитории.
▶ Визуал – макетов, прототипов, гайдлайна и т. д.
▶ Серверная инфраструктура, на которой ведется разработка, тестируется или работает сам проект.
▶ Разноуровневый Доступ и хранение паролей.
▶ Кроме кода и визуала в проекте обязательно есть Данные. Это либо база, либо контент, ради обработки которых проект и затевался.
▶ В развитых проектах код покрывают Тестами и пишут формальные Тест-планы выпуска продукта.
▶ Большинство проектов взаимодействуют с Внешними сервисами. Например, авторизуют пользователей через социальные сети или рассчитывают стоимость доставки товара. Для этого разработчики выполняют интеграцию через API. Подробности в главе 10.
▶ Наконец, в зрелом проекте обязана быть Документация. Ее главная задача – отчуждение знаний о проекте из голов конкретных исполнителей. Документация снижает риски.
1.1.1. Прогулка по картине мира
Итак, мы героически вляпались в задачу «довести сайт до ума». Как бы я действовал (кое-где – чужими руками)?
Жуть, этот план даже читать больно! А ведь вам завтра крутить окровавленную и облитую слезами ручку digital-разработки:)
▶ Поинтересовался, почему расстались с предыдущим разработчиком, на какой ноте, кто это был. Навел бы справки. По возможности переговорил с разработчиком, составил свое мнение.
▶ Получил от клиента предварительный список требований и задач. Рассказал всю процедуру и описал риски. Запланировал время на то, чтобы вникнуть в чужой код. Возможно, его придется полностью удалить, и все написать по новой. Первое время наша скорость будет ниже, чем у предыдущей команды, и у нас будет больше ошибок, потому что мы не знаем всех взаимосвязей. Также обсудил условия, при которых можно попробовать взяться за задачу.
▶ Грубо оценил стоимость проекта (вилочно, от-до), получил подтверждение бюджета у клиента.
▶ Согласовал работу по Time & Material. Работать с чужим проектом по Fixed Price – самоубийство. Выяснил, сколько примерно часов готов выкупать клиент в будущем и какие дальнейшие планы на сотрудничество. Разовый, короткий контракт, отношения на одну ночь меня бы не заинтересовали – в этом случае посоветовал бы закончить проект с предыдущей командой.
▶ Запросил доступы к коду.
▶ Провел код-ревью – процедуру анализа и оценки качества кода.
▶ Изучил текущую документацию. Если документации нет – это тоже показатель.
▶ Принял решение, можно ли работать с текущим кодом или нужно выбросить и все делать с нуля.
▶
