Частенько, по долгу службы в том числе, приходится писать всякие ТЗ, а так же вникать и (командовать) создавать документацию по продуктам и решениям. ТЗ — для отношений с клиентом, документация — для разработчиков. Основные принципы, которые должны быть, коротко, под катом.
Вот допустим, как работает ваша супер-пупер цмс? Как объясните? «Нууу, у нас тут есть куча классов, шаблонизатор, логика, всякие интересные фишки и ваще она супер-пупер, ибо на xml (phptemplate, HTML::Template)» — часто приходится слышать от разработчиков. Оно, конечно, хорошо, ребятки, но нифига не понятно.
Объясните лучше, что происходит между тем, как я ввожу адрес в строку браузера, или ввожу в форму на страничке, и тем, что я вижу на экране.
Этот, казалось бы простой вопрос, иногда приводит в замешательство даже основных разработчиков архитектуры какого-либо приложения. Но, в результате, получается хорошая картина, по типу «тут у нас запускается бутстрап, разбирает строку гет-параметра, вызывает модули по такому-то правилу, собирает те-то шаблоны, выгружает в них данные и выводит хтмл. за вывод этой части страницы отвечает такой-то модуль, за другую — другой, и т.п.» Рисуем картинку, блок-схему, как кому удобнее, и все всем понятно, даже самим разработчикам яснее становится.
Со стороны клиента то же самое: я нажимаю эту кнопку, и куда я должен попасть? А потом что? Ага, вот это понятно, в отличии от описания «нам нужна современная супер-современная-система в пастельных тонах и с максимально удовлетворяющим потребности манагеров функционалом. за $500, не больше».
В общем описывается
1. То, что будет на входе, и то, что получится на выходе
Это основа всего ТЗ. Прояснение потребностей клиента, для себя и для него. Аргумент в случае разногласий по окончании разработки. Делается перед проектом. Если эта часть не описана, или это невозможно сделать, то тут имеет дело политика и неразбериха. Браться за такой проект — себе дороже. Выйдешь в минус или вообще провалишься.
2. Как вход и выход связаны между собой
Алгоритмы поведения системы. Вторая часть важна для разработчиков, по сути — документация на проект, какая-никакая. Часто, не обязательна, но при передаче кода другому разработчику (если работает не один человек) НУЖНО описать. Иначе поимеете геморрой с разборками кода и его качеством, зачастую. Делается, обычно, по окончании проекта.
Описание может быть в свободной форме, в общем случае. Часто это получается в виде какой-либо схемы со сносками (для алгоритмов), либо в виде примерных скриншотов (в случае сайта). Ну и, если это официальный документ, то все это подробно описывается словами.
Вот так кратко можно описать минимально ТЗ и документацию. В общем — хватает в 90% случаев.
УПД: Спрашивают, для чего же все это написано?
Да, есть сложные и большие проекты в сфере разработки, для которых написаны огромные книги по составлению ТЗ и документации, и там это, возможно, необходимо. Документация в тысячах листов, ТЗ в сотнях страниц.
Но есть еще огромная масса не очень больших проектов, особенно в среде веб-разработки, где писать это большое и сложное ТЗ и документацию смысла нету. Но и совсем без него — тоже плохо, минусы известны и указаны. Эта заметка — собственный опыт, тот минимум, что необходим, чтобы, с одной стороны, защитить себя и клиента от рисков и прояснить ситуацию, написать что-то, что сможет поддерживать другой разработчик, с другой — затратить на это разумное количество времени и сил.
Хех, интересная фигня на этом сайте с «кармой». у поста на данный момент 47 добавили в избранное, 11 + и 12 -, итого «карма» -1, голосовать и писать комменты я не могу.
Причем кто эти -12 непонятно вовсе — комментов нету. Великие анонимы? В общем с таким делом, похоже, не написать мне ничего больше на этот сайтик — система не дает. А можно было бы продолжить.
Вот допустим, как работает ваша супер-пупер цмс? Как объясните? «Нууу, у нас тут есть куча классов, шаблонизатор, логика, всякие интересные фишки и ваще она супер-пупер, ибо на xml (phptemplate, HTML::Template)» — часто приходится слышать от разработчиков. Оно, конечно, хорошо, ребятки, но нифига не понятно.
Объясните лучше, что происходит между тем, как я ввожу адрес в строку браузера, или ввожу в форму на страничке, и тем, что я вижу на экране.
Этот, казалось бы простой вопрос, иногда приводит в замешательство даже основных разработчиков архитектуры какого-либо приложения. Но, в результате, получается хорошая картина, по типу «тут у нас запускается бутстрап, разбирает строку гет-параметра, вызывает модули по такому-то правилу, собирает те-то шаблоны, выгружает в них данные и выводит хтмл. за вывод этой части страницы отвечает такой-то модуль, за другую — другой, и т.п.» Рисуем картинку, блок-схему, как кому удобнее, и все всем понятно, даже самим разработчикам яснее становится.
Со стороны клиента то же самое: я нажимаю эту кнопку, и куда я должен попасть? А потом что? Ага, вот это понятно, в отличии от описания «нам нужна современная супер-современная-система в пастельных тонах и с максимально удовлетворяющим потребности манагеров функционалом. за $500, не больше».
В общем описывается
1. То, что будет на входе, и то, что получится на выходе
Это основа всего ТЗ. Прояснение потребностей клиента, для себя и для него. Аргумент в случае разногласий по окончании разработки. Делается перед проектом. Если эта часть не описана, или это невозможно сделать, то тут имеет дело политика и неразбериха. Браться за такой проект — себе дороже. Выйдешь в минус или вообще провалишься.
2. Как вход и выход связаны между собой
Алгоритмы поведения системы. Вторая часть важна для разработчиков, по сути — документация на проект, какая-никакая. Часто, не обязательна, но при передаче кода другому разработчику (если работает не один человек) НУЖНО описать. Иначе поимеете геморрой с разборками кода и его качеством, зачастую. Делается, обычно, по окончании проекта.
Описание может быть в свободной форме, в общем случае. Часто это получается в виде какой-либо схемы со сносками (для алгоритмов), либо в виде примерных скриншотов (в случае сайта). Ну и, если это официальный документ, то все это подробно описывается словами.
Вот так кратко можно описать минимально ТЗ и документацию. В общем — хватает в 90% случаев.
УПД: Спрашивают, для чего же все это написано?
Да, есть сложные и большие проекты в сфере разработки, для которых написаны огромные книги по составлению ТЗ и документации, и там это, возможно, необходимо. Документация в тысячах листов, ТЗ в сотнях страниц.
Но есть еще огромная масса не очень больших проектов, особенно в среде веб-разработки, где писать это большое и сложное ТЗ и документацию смысла нету. Но и совсем без него — тоже плохо, минусы известны и указаны. Эта заметка — собственный опыт, тот минимум, что необходим, чтобы, с одной стороны, защитить себя и клиента от рисков и прояснить ситуацию, написать что-то, что сможет поддерживать другой разработчик, с другой — затратить на это разумное количество времени и сил.
Хех, интересная фигня на этом сайте с «кармой». у поста на данный момент 47 добавили в избранное, 11 + и 12 -, итого «карма» -1, голосовать и писать комменты я не могу.
Причем кто эти -12 непонятно вовсе — комментов нету. Великие анонимы? В общем с таким делом, похоже, не написать мне ничего больше на этот сайтик — система не дает. А можно было бы продолжить.