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

3. Границы проекта. Как только вы более или менее зафиксировали Видение, пришло время прописать Границы проекта. Это дополнительный раздел, где четко описано, что НЕ будет входить в систему и где заканчивается то, что уже описано. Чтобы не было недопонимания потом в стиле: «Я думал, раз вы делаете мостик, то и асфальтированную освещенную дорогу в 5 км к нему сделаете, а иначе как им пользоваться?» Это тоже должно входить в полный вариант Видения. Или следует четко прописать, что никаких подъездных путей и освещения в конечном результате не предусмотрено.

В этой части важно еще описать, что дополнительно будет поставляться в рамках результата проекта – документация (в каком виде и какого объема?), дополнительные материалы, дополнительные работы в виде обучения, маркетинга, поддержки и т. д. Или не будут поставляться. Здесь нет задачи от чего-то сразу отказаться. Тут задача – максимально четко прописать границы. Вот и прописывай. Чем лучше пропишешь, тем меньше надо будет доделывать по завершении проекта и тем более счастливыми будут все участники.

4. Требования. Теперь уже можно писать Техническое задание (оно же – Требования). Хотя бы верхнего уровня. Берете Видение + Границы, разбиваете на сценарии и бизнес-кейсы и начинаете прорабатывать каждый в отдельности. Как проработали, прикидывайте архитектурную, техническую, интеграционную, инфраструктурную и все остальные стороны. На этом этапе необходимо продумать и описать все, включая такие очевидные вещи, как, например, авторизация, восстановление пароля, управление пользователями, уведомления и т. д. Потом надо будет оценивать, как эти задачи влияют на трудозатраты и сроки реализации.

Глубина и структура ТЗ определяется тобой (ТЗ – это текстовая модель результата. Выше мы писали про роли аналитиков-проектировщиков и про то, что глубина их участия в разных проектах разная). Есть, конечно, различные стандарты, но лучше ориентироваться опять же на здравый смысл. ТЗ должно быть понятным, должно описывать, что и как надо сделать. Больше его расписывать, если нет специальных требований заказчика, смысла нет. Если только в качестве упражнения в стиле «А жахну-ка я ТЗ по ГОСТ 34.602—89», но это уже на любителя.

5. Технологии. Пока вы описывали Требования, как система должна работать, что включать, что не включать и т. д., дальше надо договориться о технологиях создания. Вы оба (заказчик и команда) уверены, что понимаете, как надо. Только в понимании проектной команды и заказчика могут присутствовать разные технологии. Если два этих списка технологий более или менее сошлись – прекрасно. Если нет, надо договариваться. Делать все на старых технологиях – не вариант, но и совсем все новое, скорее всего, тоже не получится протащить. Тут нужен разумный компромисс – то, что без особых проблем «встанет» у заказчика, и то, на чем можно вести разработку на современном уровне.

6. Установочная встреча (она же kick-off meeting). Это неформальная встреча с участием заказчика, руководителя проекта и команды. Ее можно провести раньше официального старта работ или чуть позже. У нее нет протокола или обязательных составных частей. Это, скорее, ознакомительная и вдохновляющая встреча. Команда видит заказчика, заказчик видит команду и может услышать каждого. Заказчик обычно рассказывает о своей бизнес-задаче, цели проекта, уже плюс-минус согласованном с менеджером Видении, границах проекта и подходах. PM (Project Manager – ты) может рассказать про подходы к реализации, о технологиях и команде. Именно в этот момент проясняются ваши ожидания друг от друга, в этот же момент возникают вопросы и предложения, которые могут сфокусировать конечный продукт или прояснить новые риски. На встрече заказчик «вливается» в команду, появляются общие цели и ожидания. И это хорошо.