Дмитрий Ершов - Без ТЗ - Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов

Гибкий процесс вы сможете обеспечить документально, если зафиксируете часы для получения результатов работ вместо подробных субъективных требований.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Может возникнуть ситуация, когда подрядчик откажется передавать еще не оплаченный материал. В таком случае осуществляйте 100% предоплату этапов работ, а закрывающие документы подписывайте после приёмки. Выбирая модель разработки, обратите внимание на схему оплаты. Для каскадной разработки подходит Fixed Price, с предварительным утверждением сметы. А для гибких процессов – удобнее использовать Time and Materials с расчетом стоимости спринтов. Среди крупных компаний набирает популярность схема «выкупа команды разработки». Многие агентства и студии даже предлагают перебазировать своих сотрудников в офис заказчика на время проекта. Это дороже, чем удаленная работа с командой, но результат появится быстрее и будет более качественным.