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

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

И если к серверным ошибкам пользователи более-менее привыкли, поскольку они типовые, то косяки с вёрсткой всплывают неожиданно и тем самым больше раздражают, выдают низкое качество продукта и снижают лояльность ваших пользователей

Старайтесь, чтобы у каждой задачи, которая идёт в спринт, был понятный результат, а не «провести исследование как провести исследование».

– Use Case: детализация вариантов использования. (Например, описание возможных вариантов использования во время заполнения заявки на получение услуги).
– User Story: разбор отдельных историй на части. (Например, описание истории перехода от заполнения заявки к получению услуги).
– Job Story: дробление крупного контекста на мелкие контексты. (Например, описание переключения от контекста заполнения заявки к контексту получения услуги)

В результате у вас получится продуктовый бэклог в виде онлайн-таблицы, отражающий:
– Боль/проблему пользователя;
– описание функционала, который эту проблему решает (и как решает);
– Важность для пользователя;
– Важность для бизнеса;
– Сложность реализации;
– Совокупный балл приоритета;
– Критерий приёмки (каким образом функционал должен быть реализован, чтобы уйти в релиз).

Должен получиться примерно такой комплект:
– Рамочный договор.
– Заказ (с требованиями к результатам 1 итерации).
– Приложения к заказу (гайдлайны, исходный материал, и т.п.).
– Календарный план (в случае водопадной разработки).
– Шаблоны закрывающих документов (при необходимости).

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

– Как поддерживать продукт после того, как он будет готов?
– Что делать, если потребуется добавить или изменить раздел, когда уже всё готово?
– Что, если не подойдёт качество результатов?
– Что, если проект будет задерживаться или будет готов не полностью?

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

При описании продукта всегда концентрируйтесь на целях ваших пользователей:
– Для чего пользователям ваш продукт?
– Как он им поможет?
– Чем это лучше существующих альтернатив?