Читать «Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов» онлайн - страница 10

4 – Какие нужны документы

Управляемая гибкость

Тот, кто халатно относится к документам, рискует потерять деньги в случае разногласий. Мелкие компании обращают на них мало внимания, а крупные могут несколько месяцев согласовывать каждый пункт в договоре. Самое главное на данном этапе – зафиксировать предмет, процесс, риски и ответственность каждой стороны и сделать это достаточно гибко, чтобы было комфортно работать.

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

Вы сможете делить заказы по проектам или отдельным этапам – в зависимости от ситуации.

Рамочный договор и заказы.

С другой стороны, гибкость обеспечивает формулировка предмета разработки: «произведение». Произведением может быть и концепция, и стратегия, и контент. Вне зависимости от того, какие именно будут произведения, не забудьте указать в договоре условия отчуждения прав.

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

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

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

Процесс и результат

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

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

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

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

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

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

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

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

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

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

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

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