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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы осилили создание всей необходимой документации – поздравляю! Должен получиться примерно такой комплект:

– Рамочный договор.

– Заказ (с требованиями к результатам 1 итерации).

– Приложения к заказу (гайдлайны, исходный материал, и т.п.).

– Календарный план (в случае водопадной разработки).

– Шаблоны закрывающих документов (при необходимости).

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

Совместное обсуждение целей пользователей.

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

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

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

Почему в договоренностях между неопытным менеджером и исполнителем часто возникает недопонимание?

Менеджер думает, что он согласовал одни условия, а подрядчик считает совершенно по-другому. Как такое возможно, если при встрече они пришли к согласию? Откуда взялось недопонимание?

Очевидно, что стороны не обсудили многие детали, либо не до конца разъяснили друг другу свои позиции. Но почему так произошло?

На менеджера давят обязательства со стороны клиента и работодателя. Он должен вовремя договориться с поставщиком и сдать проект в срок.

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

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