|
авторЕсть в голове мысль о интересном проекте, она некоторое время мной обдумывается, обсуждается с друзьями, какие-то наброски кода делаются для реализации концептуальных идей. Но когда ухожу плотно уже в разработку, то начинаю пробуксовывать и в какой-то момент не понимаю, а что дальше то реализовывать.
В общем проблема от видения идеи изнутри своей головы - перейти к сформулированному и понятному для реализации ТЗ.
У вас в голове сумбур, потому что вы совмещаете одновременно два разных вида работ.
Есть такие нормативные документы как ТЗ (у гражданских свои - на программу, на информационную систему, у военных - свои). По нормативным документам ТЗ готовит Заказчик! Именно только Заказчик знает. что ему нужно.
ТЗ должно содержать 2 важные спецификации:
1 цель разработки;
2 требования к разработке.
Цель разработки.
ТЗ должно содержать четко сформулированную цель разработки (например, создать невидимый для радаров самолет, ракету для полета на Луну, операционную систему для смартфона, игровую программу с целью завоевания 15% рынка и т. п.). Цель может быть экономическая, военная, политическая, социальная, маркетинговая и т. п.)
Цель разработки должна быть обозначена – иначе нет смысла браться за работу (будет как в русских сказка - иди туда, не знаю куда, принеси то, не знаю что).
ВАЖНО! При формулировке цели Заказчик должен понимать, во что выльется ему достижение цели и какой она даст эффект (экономический или иной). Например, вы решили автоматизировать продажу ж/д билетов. За счет чего понесенные затраты (разовые – на разработку, и текущие – обслуживание технических средств, каналов связи, расходные материалы и т. п. ) будут окупаться. Ведь ни длина ж/д путей. ни количество ж/д составов и вагонов, ни количество пассажиров - РЖД монополист, из других компаний пассажиры не уйдут) - не изменится.
Требования к разработке.
Здесь перечисляются ВСЕ! требования, которые, по мнению Заказчика, должны обеспечить достижение поставленной цели (функциональные, требования к параметрам технических средств, к системному ПО, надежности, производительности, к защите информации и т. п.).
Объем документа 10-15 страниц! Это обычный текстовый документ, оформленный в соответствии с неким ГОCТ.
авторЯ так понимаю, команды разработки в фирмах наверное как раз и имеют необходимый набор специалистов для эдакого мозгового штурма с коллективным оформлением дизайнером - в наглядном виде, постановщиком задач в виде целей и схем, разработчиками в виде инструментов и методов.
Подскажите, как если у меня нет команды организовать подобную деятельность? То ли писать тексты на бумаге с формулированием всего. То ли итерациями, и наброски и цели и сразу продумывать инструменты.
За сумбур извините, надеюсь ясно о чём прошу :)
В общем случае это к ТЗ не относится – это документы стадии “Технический проект” и Заказчик не знает, как разработка будет реализована. Но есть продвинутые Заказчики, у которых есть штат программистов и которые указывают вам, как надо реализовать разработку. Для таких в ТЗ есть раздел – ”Специальные требования”, в котором и описываются обязательные к реализации технические решения (с помощью разных инструментов). Специальные требования могут прилагаться к ТЗ – высокое начальство, которое утверждает разработку, не будет читать, например, 500 страниц детальных технических решений Есть и такие ТЗ!
В общем, вам надо отделить “мух от котлет” – сначала утвержденное ТЗ с четко сформулированной целью, а потом технические решения. Функциональные требования из ТЗ могут изменяться по мере разработки, но тогда выпускаются “ДопТЗ” (Дополнительные ТЗ, например, для очередной версии), в которых прописаны новые функциональные требования, удалены или скорректированы (расширены) существующие.
|
