Техническое задание – закон для разработчика. В процессе разработки – основной документ, которым он должен руководствоваться. Этот документ призван:
* описать цель работы. И разработчик, и заказчик должны чётко понимать, к чему они стремятся, за что один платит деньги, а другой – тратит время и напрягает мозги;
* описать задачи. Прежде чем начинать работу, необходимо прикинуть, насколько она затянется, сколько потребует ресурсов. Круг задач должен быть посильным разработчику, а заказчик должен представлять, чем разработчик будет заниматься, за что платить;
* регламентировать отношения. Один из самых важных моментов! Заказчик и исполнитель регламентируют объёмы, сроки, денежные суммы, порядок приёмки, форматы исходных и выходных данных и ещё множество условий, которые необходимо прописать во избежание конфликтных ситуаций.
Зачем нужно ТЗ?
«Техническое задание не нужно?!\\\\\\\" – часто говорят некомпетентные псевдопрофессионалы, – «оно будет только мешать и тормозить процесс разработки!\\\\\\\"
«Чушь» – отвечаю я. Это позиция людей некомпетентных, непрофессиональных. Почему таким людям выгодно отсутствие ТЗ? А ведь им именно выгодно его отсутствие.
Всё просто:
1. Отсутствие опыта, слабое представление о сути дела, за которое берётся разработчик;
2. Отсутствие ТЗ – это отсутствие временных рамок, размытие сумм;
3. Это способ безнаказанно урезать объёмы работ, ухудшать показатели и функционал;
4. И т.д.
Отсутствие технического задания во взаимоотношениях заказчика и исполнителя – беззаконие. А беззаконие, как вы знаете, рождает хаос, неразбериху, становится причиной жульничества и надувательства.
Как аргументируют отказ от оформления ТЗ?
Вообще, это забавная тема. Согласитесь, действия ушлых или недалёких персонажей всегда выглядят комично. Отсутствие логики или прямое надувательство, подмена одного другим часто встречаются в жизни, но не сразу распознаются. Возможно, некоторое из того, что я сейчас опишу, вам уже встречалось. Согласитесь, случаи типичны.
Итак, поводов к тому, чтобы отказаться оформлять ТЗ, можно услышать множество:
* Задача такая сложная и такая “творческая”, что её невозможно загнать в рамки ТЗ! Глупость… Вы знаете, что технические задания составляются даже на произведения искусства? На памятники, рисунки, логотипы, мелодии, даже на мультяшные персонажи. И в этом нет ничего удивительного. Всё поддаётся формализации и описанию. Лишь непрофессиональный человек не сможет описать свою работу или создаваемый продукт.
* Написание ТЗ займёт много времени и ресурсов. Уж лучше взяться потихонечку за работу, а там – определимся! Отговорка нерадивого человека… Профи потратит на ТЗ от одного до нескольких дней. Где надо – заложит ресурсы на изыскания, а где – чётко определит выполняемое. Только плохо разбирающийся в проблеме человек не сможет заранее всё предугадать.
* ТЗ не нужно, поскольку задача слишком очевидна и проста! Ловушка, поставленная профессиональным лентяем… Ну если там всё так просто, то опиши, дорогой, эту простоту на 1-2 листах! “Дорогой” сразу же сникнет, поскольку станет очевидно, что выползет множество нюансов, требующих уточнения. И элементарная проблема в ходе детальной проработки сразу станет сложной и серьёзной. Кстати, такой ход используется для того, чтобы потом растянуть сроки, вытянуть больше денег, когда возникнут “непредвиденные трудности”.
Увы, чаще всего встречал подобные “отговорки” среди программистов. За всю свою практику исключение составил всего один человек. Он – крупный специалист в своей области. Без обсуждений взялся за написание ТЗ и составил его лаконично, грамотно, определённо. Человек, почти полтора десятка лет занимающийся программированием, составил безупречное ТЗ на сложнейший программный продукт.
Приведу другой пример, когда один “крупный деятель”, применяя все приведённые выше отговорки, так затянул процесс разработки программного обеспечения, что все окружающие просто диву давались! Отмечу, что проект, начатый более трёх лет тому назад, до сих пор не закончен. И непонятно, на какой стадии находится эта разработка. Удивительное попустительство работодателя в вопросе составления ТЗ и написания планов практически похоронило проект и громадную кучу денег. А тот “крупный деятель” занимается попутным самообразованием за счёт работодателя и откровенным бездельем.
Кто должен писать техническое задание? Ответ на этот вопрос однозначен – разработчик. Другого не дано. Только он способен грамотно представить цели, сформулировать задачи. Если цели неясны, то происходит итеративный процесс написания ТЗ – разработчик постепенно формирует цель в глазах заказчика, пытается понять его субъективный взгляд на проблему. Это трудный и длительный процесс, но он поможет избежать двусмысленностей и непонимания.
Лучше способ понять что же всё-таки хочет заказчик, это вооружившись карандашом и листом бумаги отправиться на встречу с ним, где вы пообщавшись очно поставите все точки на И. Конечно всё зависит от сложности проекта, если проект является не уникальным, т.е. подобных аналогов много, то проще всего взять весь процесс написания ТЗ на себя и предоставить заказчику уже чёткую документацию, это безусловно поднимет ваш авторитет в его глазах.
+ '&'+Math.random()+' "km index")
