обнаженное техзадание

Клиенты бывают двух видов. Очень опытные и просто опытные. Последние приходят с двумя видами запросов:

1. «Не могли ли бы вы посчитать стоимость создания базы данных для компании, у которой есть головной офис в москве и несколько в других городах. Регионы будут вносить данные, а головной офис — просматривать.»

Проблема в том, что эта просьба аналогична желанию оценить размер айсберга, глядя на него с расстояния в километр. 🙂

Под данное определение подходит и куча типовых решений — веб, десктопных, 1с…; под него же подходит самостоятельная разработка продолжительностью несколько месяцев; под него же подходит и какой-нибудь мега портал размером с хедхантер. Разброс стоимости данных проектов — в сотни раз!

Для осуществления проекта необходимо техническое задание. Техзадание на несколько месяцев работ — это документ в десятки страниц (не воды, а текста, необходимого для исчерпывающей постановки задачи). По нему можно дать более-менее точную смету и план работ.

Представьте себе, что я взял эти десятки страниц и удалил 99%. Оставил только те десять строчек, которые написал клиент. Какую оценку по ним можно дать? Откуда возьмется информация об объеме работ, которая составляет удаленные 99%? Насколько достоверной будет такая оценка?

2. «Какое ТЗ вам ещё нужно? Мне просто нужна копия … (например, fb.com)!!!»

То, что нужно сделать исполнителю при поступлении такого запроса — разобрать проект на кучу мелких составляющих, выписать их списком, прикинуть трудоемкость их создания и механизм взаимодействия между ними. Учитывая, что количество составляющих может приближаться к сотням — нетривиальная задача, занимающая часы, дни, а иногда и недели. Но на что не пойдёшь, лишь бы угодить клиенту!!! 😉

Когда перечень работ предъявляется клиенту, он обнаруживает что представлял лишь верхушку айсберга — примерно 10% от проекта. Что 50% ему не нужно вообще (он их до этого момента не видел). Что 30% сделаны по-другому, нежели нужно. И лишь 10-20% нужно сделать по аналогии. То бишь с нуля. Ну и дописать некоторые незначительные вещи, составляющие половину объема работ.

Чаще всего клиент обнаруживает, что второй фейсбук за ни за $1000, ни за $10 000 не напишешь. И идет придумывать следующую идею. А исполнитель обнаруживает, что он потратил несколько часов или дней работы впустую. И после пары десятков раз проделанной такой работы либо перестаёт отвечать на подобные запросы, либо отвечает загадочным стишком:

Ты кто такой давай техзадание,
Ты кто такой давай техзадание,
Ты кто такой давай техзадание…

Он все с тобой обсудить попытается,
Отчет, аудит всучить пытается.
Знаешь, где реальный дело начинается?
Только там, где ТЗ появляется.

А теперь, товарищи, внимание-
Нету ТЗ? Давай, до свидания!
———

Если вы клиент, возможно этот стишок вам покажется насмешкой.
Я же вижу в нем пот, кровь и слезы тысяч специалистов, положивших свои жизни за принцип «клиент прежде всего!» 🙂
В нем выстрадана каждая строка. Например — как вы думаете, что означают первые три строчки?

Дело в том, что большинство клиентов не находят нужным представляться. По какой-то причине они полагают нормальным, что в результате письма «мне нужна копия fb.com, пожалуйста вышлите ваше ценовое предложение в течении 3 дней», кто-то немедленно нажмет на красную кнопку, закрутятся неведомые шестеренки, и откуда-то выползет свежее, пахнущее краской коммерческое предложение, с подписями гендиректора, бухгалтера и комдира поставщика.

Такое действительно бывает. Если исполнитель знает, что
1. клиент платежеспособен (не по понятиям клиента, а по понятиям исполнителя),
2. клиент имеет полномочия принимать решения самостоятельно,
3. клиенту близки понятия «любая работа должна быть оплачена» или «хорошая большая работа не бывает дешевой»,
4. или хотя бы — клиент прилично одевается, разговаривает без ошибок и ездит на бентли

— то иногда так случается, что предпроектное обследование проделывается бесплатно. Вы не поверите, иногда даже большие проекты выполняются бесплатно, целиком — просто ради того, чтобы сотрудничать с серьезными людьми, на отдаленную перспективу. Но для этого нужно понять, что речь идет о серьезных людях — а этого не видно в письме из одной строчки с адресом, зарегистрированным на публичном почтовике.

Упорный клиент скажет — и все-таки, зачем ТЗ?

Ведь есть рабочая модель с целыми 10% от того, что мне нужно! Всего-то надо подкрутить здесь, допилить там и убрать чуть-чуть.

Представим себе, что будет дальше. Начинается разработка. Она длится, допустим, месяц.
В ходе работы у исполнителя возникают вопросы. Много вопросов. Некоторые из них — сугубо технические, касающиеся структуры проекта. Часть — относятся к бизнес-логике. Ещё некоторая часть — к интерфейсу. Редко бывает, чтобы программист переадресовывал все вопросы заказчику — по куче причин:
— переключение режима общение/программирование значительно увеличивает срок разработки
— ответ может значительно влиять на объем работ и менять весь план проекта
— клиент, чаще всего, сам не знает ответов на эти вопросы
— проще ответить самому

Кроме того, часть информации, озвучиваемой клиентом — недосказывается, часть — забывается, а часть — интерпретируется/искажается. И им, и исполнителем. В случае работы с командой всё ещё лучше — больше людей, больше искажений. Выглядит это примерно так:

Шутка? Не совсем. В каждой шутке доля шутки.

Возможна ли работа в таком режиме? Конечно да. Работают же люди! Ногами тоже можно кушать! 🙂
…и это даже может сработать. Но на короткой дистанции — если проект продолжается день или неделю. Если больше месяца — будут Сложности.
———
Чем чревата работа без ТЗ/с поверхностным ТЗ?
1. количеством итераций.

В нашей практике, при работе с ТЗ, обычно достаточно двух итераций — выдаем базовую версию программы, заказчик апробирует и выдает перечень замечаний. Замечания устраняются, вторая версия проекта — сдается.

В случае, когда ТЗ нет или оно поверхностно, вероятность получения заказчиком того, что он хочет, сильно уменьшается. Количество итераций может измеряться десятками. Сроки завершения проекта увеличиваются многократно. Трудоемкость проекта растет, стоимость остается неизменной. И клиент, и исполнитель раздражаются, не получая ожидаемого. В общем… редкая птица долетит до середины Днепра, если ширина Днепра постоянно растет. 🙂 Эта причина — основная, по которой проекты не доводятся до результата.

2. хромой архитектурой.

Создание IT проекта не сильно отличается от строительства дома. Почему никому не приходит в голову построить небоскреб без чертежей? Последствия могут быть весьма дороги. В IT проектах — то же самое. Проект может просто обвалиться под своей тяжестью, если изначально не продумана конструкция.
———
Что такое техзадание на программное обеспечение?

Это документ, обычно написанный по ГОСТ.
Таких ГОСТов несколько и они дают четкую структуру документа, позволяющую написать исчерпывающую постановку задачи.
По опыту, объем ТЗ средней детализации на проект продолжительностью 1.5-2 месяца работ — 30-40 страниц.
То есть, любые присылаемые клиентом полстранички текста — это не ТЗ, это пожелания.
Вот так, к примеру, выглядит ТЗ на написание небольшой CRM.
———
Зачем оно нужно?

Затем, чтобы мирно разойтись: чтобы исполнитель мог выполнить именно то, что оговорено, а заказчик — получить именно то, что планировал, свериться и принять работу.
———
Может ли клиент написать ТЗ сам?

В принципе — да. Самый простой способ — «что вижу, о том пою». То есть — рисуйте то, что ожидаете увидеть в итоге (странички, формы). На листочке или в excel — неважно (но конечно лучше использовать что-то вроде Balsamiq Mockups). После уточнения с исполнителями вопросов по архитектуре есть шанс получить вменяемое ТЗ.
———
Какие основные ошибки делают при написании ТЗ?

По-крупному, три:
1. Клиент, вместо описания задачи человеческим языком, пытается изобразить из себя программиста. Из-за этого в его ТЗ почти всегда отсутствует важнейшая составляющая — описание бизнес-задачи, которую он собирается решить. Ну и там, где он пытается расписывать базу данных вплоть до таблиц — как правило, получается фигня.

2. Клиент почти никогда не смотрит на задачу со стороны. То есть, находясь в своем бизнесе, в своей предметной области и терминологии, говорит и пишет о чем-то глубоко своём, на своем «птичьем» языке. Из-за этого в его ТЗ почти всегда отсутствует словарь терминов и аббревиатур (они же ему понятны). Иногда язык настолько «птичий», что человеку со стороны понять написанный клиентом документ — невозможно в принципе.

3. Клиент не знает, что можно реализовать, а что нельзя или нецелесообразно, а иногда даже — решаются ли в принципе его задачи данным проектом или нет — и лепит в ТЗ всё подряд. Хотите посмотреть, как это выглядит? С разрешения одного клиента привожу выдержку из его «ТЗ на сайт»:

«- иметь интуитивно понятный и легко осваиваемый интерфейс…;
— быстро грузиться…;
— работать на любом сервере, с любым программным обеспечением…;
— обеспечивать возможность создания лучших сайтов…;
— иметь встроенную поисковую систему типа Google…;
— обеспечить возможность ее освоению без опыта и знаний…;
— должна гарантировать попадание сайта в первые позиции рейтингов…;
— должна гарантировать успех работы сайта…;
— должна обеспечить возможность изменения ее программного кода без опыта и знаний…;
— должна обеспечить возможность легко изменять сайт без опыта и знаний…;»

Для специалистов этот текст выглядит как чертеж дома, где вместо размеров и показателей — «немного», «хороший», «как у Васи», «помягче», «глубже» и т.п.

Многие из исполнителей не будут рассматривать возможность сотрудничества с клиентом, приславшим такой документ. Почему? Потому, что клиент полагает, что уже проделал работу по написанию ТЗ. И его нужно убеждать, что по такому наброску на салфетке небоскреб не то, что не построишь — даже не оценишь! Для нормальной оценки нужна проектная документация. Чтобы убедить, клиента нужно обучать. И, к сожалению, потраченные на это часы никогда не будут компенсированы.
———
А как оно делается по-правильному?

Приезжает специально обученный человек, способный понимать 148 странных языков, на которых изъясняется клиент. Пьёт кофе и 1.5-2 часа задает вопросы. Через пару дней присылает набросок документа, ждет комментариев. Параллельно засылает копию руководителю проектов, чтобы получить ценные указания. Затем всё по-новой, и так 2-3 недели. Потом говорит — я сделал всё, что мог! Клиент вторит — я вижу всё, что хотел! Руководитель проекта — есть всё, что нужно! Уффф. Можно начинать разработку.

20.07.2012   Бизнес   2 комментария

2 комментария

  1. Сергей К - 10.12.2012

    «А как оно делается по-правильному?» — в жизни так не бывает. :))))

  2. Михаил - 10.12.2012

    Я же не говорил — «А как делается идеально?» 🙂 Идеал недостижим. Тем не менее имеет смысл делать правильные вещи (иначе говоря, наиболее эффективные практики).

Оставить комментарий