Работа с разработчиком

Хорошая задача содержит:

• проблему;
• аудиторию;
• реальные материалы;
• обязательные сценарии;
• ограничения;
• проверяемый результат.

Технология и дизайн обсуждаются после этого.

Часто полезнее:

• карта пользовательских задач;
• реальные материалы;
• структура;
• типы сущностей;
• примеры сложных страниц;
• критерии результата;
• список обязательного и будущего.

Это не запрещает полноценную спецификацию, но делает её содержательной.

Формулируйте через действие:

Редактор самостоятельно публикует и обновляет материал.

Пользователь видит показатель, период и источник.

Ответственный знает порядок действий при сбое.

Такой результат можно принять или отклонить на проверке.

• кому принадлежат домен и код;
• где будет размещён сайт;
• как устроена публикация;
• кто отвечает за backup;
• что входит в стоимость;
• что считается дополнительной работой;
• как передаются доступы;
• как проходит приёмка;
• что происходит после запуска.

Проверяйте не изображения макетов, а сценарии:

• можно ли создать материал;
• корректно ли работает структура;
• связаны ли языки;
• можно ли получить данные;
• сохраняются ли роли.

Раннее тестирование на реальном содержании дешевле поздней переделки.

Новое требование должно отвечать:

• почему появилось;
• входит ли в исходный результат;
• что меняет по срокам и объёму;
• что можно отложить вместо него.

Не добавляйте каждую идею автоматически в текущий scope.

До начала работ определите владельца:

• домена;
• контента;
• данных;
• кода;
• дизайна;
• аккаунтов внешних сервисов.

Подрядчик может иметь доступ, но это не обязательно означает владение.

Проверьте реальные сценарии, доступы, мобильную версию, языки, ошибки, search, документы, данные, backup и порядок выпуска.

Приёмка «по скриншоту» недостаточна.

После запуска должны быть назначены владельцы:

• содержания;
• домена;
• CMS;
• технических выпусков;
• резервного копирования;
• решения при серьёзном сбое.

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