У нас КЦ направление и там операторов под 500 человек... 10$ за каждого - не так и мало в итоге + пересаживать уже работающую структуру на Business тоже проблема. Спасибо за ответ!
Мне не доказать кому-то что-то надо и не убедить, а ДОНЕСТИ суть проекта и моё виденье этого проекта (в частности и некоторые моменты реализации).
Так что в одну страницу невозможно будет уместить требования к проекту, требования к реализации и прочие детали.
Нет, к счастью мы не относимся к той неповоротливой машине возящейся с кипой бумаг только для того, чтобы начать действовать.
Насчет структуризации по уровням я с вами полностью согласен, однако встаёт смежный вопрос о детализации описания тех или иных требований. То ли от того, что я технарь, то или еще по каким причинам, мне хочется, чтобы вся эта «кипа бумаг» (ТЗ, сценарии, описания, ЦА и тд) были кристально понятны тем, кто будет реализовывать проект. С одной стороны — желание донести полное представление о продукте, с другой — исключить возможные и нежелательные повороты на пути разработки.
Недавно только перевели в должность руководителя проектов (что-то вроде менеджера, но сложно это так назвать, ибо в конторе НЕТ менеджеров, которые хоть что-то в этом понимают), поэтому последние вечера приходится коротать описывая проекты.
Начинается всё примерно по такому плану:
1) Миссия проекта — здесь я пытаюсь некоторой короткой фразой описать проект, его предназначение или задачи, которые он должен решать.
2) Целевая аудитория — прикидываю примерных пользователей, возрастные категории и тд (как сделано вот здесь: www.uimodeling.ru/process/docs/personas.html )
3)… (здесь огромный провал) пишу об основном функционале, возможностях пользователей (подгрупп пользователей), описываю основные объекты сервиса/платформы/приложения (пользователь, компания, редакция и тд) и тд.
Однако, если потом всё это перечитывать, то возникает куча вопросов: достаточно ли я детализировал процесс работы тех или иных методов API? достаточно ли четко и понятно описана работа компании и представлены её возможности на сервисе? Не переусердствовал ли я описывая форматы и методы, которые должны быть реализованы/использованы при написании API? Логику регистрации и каких-то других действий описывать от лица пользователя или на примере со стороны? и тд и тп.
Ваш ответ уже ближе к сути, однако можно (?) детализировать такие пункты как:
— Создание концепции системы
— Разработка технико-экономического обоснования (обоснования выгодности реализации продукта?)
Но опять таки вопрос не конкретно в ЦА, а порядке описания проекта, начиная с чего-то очень общего и заканчивая чем-то техническим (вплоть до формата ответов сервера на запросы через API).
Спасибо за столь развернутый ответ, но меня больше всего интересует первый пункт из вашего списка.
Что подразумевают под собой «первоначальные наброски»? Да и ТЗ — понятие растяжимое. Входит ли в ТЗ описание пользовательских сценариев? А куда (в какой раздел) впихивать описания требуемого API сервиса (предположим таковой имеется)? Опять таки, описание ЦА писать на начальных этапах (до описания целей или после)?
