Наверное, вы уже поняли, что я рекомендую придерживаться гибкости и свободы в процессе разработки. Однако нельзя не упомянуть самую старую модель, которая называется «каскадной» (или водопадной). Ее используют, когда требования на протяжении проекта не меняются и целесообразно полностью документировать каждый этап.

Каскадная и гибкая модели. Источник – http://slideshare.net.

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

Результатами этапов водопадной разработки могут быть:

– Схемы процессов или маршрутов пользователя (UML-диаграммы).

– Дизайн-макеты в виде изображений (или формате графических редакторов).

– Графический или текстовый контент (в соответствующих форматах).

– Программный код (размещённый на определённом сервере).

– Готовый функционал (доступный по определённому url).

– Результаты тестирования (отчёты в виде таблиц).

– Инструкции (в текстовом или видеоформате) и т. п.

Современные «гибкие модели» разработки позволяют постоянно менять требования и поэтапно, «спринтами», двигаться к новым целям. Все промежуточные результаты разработки команда создаёт сама и их не нужно документировать. С точки зрения лучших практик гибкой разработки, только то, с чем взаимодействуют пользователи, и является результатом разработки, «произведением».

Исследования, схемы процессов, макеты, и т.д., заставляют команду разработчиков смещать фокус с результата на процесс и плодить «полуфабрикаты», часть которых не принесет коммерческой пользы.

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

Предоставив такую свободу себе и исполнителям, важно не забыть об ответственности с обеих сторон. Обязательно укажите, кто конкретно с вашей стороны и со стороны исполнителя (ФИО, должность, контакты) отвечает за отправку и приёмку результатов, а также требования по срокам и качеству. Не забудьте указать, по каким каналам будет осуществляться передача материалов:

– Электронная почта (укажите все варианты, откуда и куда будет отправляться).

– Онлайн-хранилище (url к папке с материалами).

– Корпоративный таскменеджер (Jira/trello и т.п.).

– Мессенджеры (будьте осторожны: это не самое надёжное хранилище).

– Общая рабочая папка (вы сможете смотреть статистику создания текстовых документов в ней).

– Сервисы шеринга и обсуждения дизайн-макетов (после регистрации вы будете получать статистику по загрузке новых макетов каждый день).

– Системы контроля версий (после регистрации вы сможете видеть объём кода, который пишут разработчики).

Если со сроками всё более-менее понятно, то контроль качества следует проработать отдельно. Включите в требования регулярную публикацию новых материалов по проекту на ваших ресурсах. Если разработчики будут трудиться фултайм, то изменения лучше публиковать два раза в день.