Без ТЗ: почему клиент не хочет его
1. «У нас очень маленький и простой проект»
Когда я умру, и черти придут тащить меня в ад, они начнут именно с этой фразы. С каждым шагом они будут рассказывать мне о том, как вспомнили о каком-то новом ерундовом функционале, который изначально подразумевался и всем очевиден…
Сколько шагов нам придется пройти, не знает никто, но если я дойду, я стану святым.
Еще в народе популярен похожий подход: «Нет времени на ТЗ, нужно скорее запускаться».
Решается это просто: даже на самую маленькую задачу можно составить мини-ТЗ. Скажу больше, я просто обожаю маленькие и простые проекты за то, что их можно ясно описать. Большие проекты я стараюсь распилить на маленькие.
Если «маленький и простой проект» застрял уже на стадии согласования ТЗ, значит, вы умело распознали чертей до того, как они сварили вас в своем котле.
2. «Это коммерческая тайна, мы вам не расскажем»
Как-то я писал ТЗ на большую и сложную медицинскую систему… Но это было приложение для театров. Чтобы я не догадался, что речь про театры, клиент рассказывал мне про врачей. Когда же был наконец подписан NDA, мне торжественно объявили: «Ну это же одно и тоже! Механика похожая: актеры или врачи — какая разница? Почему вы так расстроились?».
Казалось бы, почему не подписать со мной NDA сразу? Но нет, бумага не дает 100%-ю гарантию. Надо же познакомиться и узнать меня получше! Вдруг я раскрою военную тайну?…
Был еще секретный сайт знакомств: «У нас есть такие приборы, но мы вам о них не расскажем.» Или же: «У нас тут мега-секретный проект, скажите сколько стоит?».
Как только я слышу о секретности, которую не закрывает NDA, то сразу же предлагаю взять паузу до тех пор пока клиент не созреет. К сожалению ТЗ, написанное намеками на то, что-нельзя-называть, разрабы не понимают.
3. «Сначала скажите сколько стоит!»
Клиент не уверен, будет ли у вас заказывать, но если закажет, вам же хуже. «Окей, нам подходит, стартуем работу, времени на ТЗ нет! Ой, а вы же обещали, что все будет дешево и быстро! Как же так! Ну это же очевидно, что все должно работать не так, а так! Как это мы не договаривались? Верните деньги!».
Вопрос цены проекта до составления ТЗ, наверное, самый частый. Хочется в двух словах описать проект и собрать со всех знакомых и незнакомых команд котировки. Обычно замечание, что цена может вырасти в 10–20 раз по мере детализации никак клиента не впечатляет: «Ну, вы же — хорошие ребята! Вы же так с нами не поступите!».
В целом желание клиента получить котировки и провести мини-тендер — это нормально, но делать это надо, разослав командам полноценное ТЗ!
4. «Почему мы должны платить за то, что нужно вам?»
Клиент прикидывается золотой антилопой и искренне негодует, что вы пытаетесь заставить его заплатить за капкан, которым хотите его поймать. «Мы же компания «УХ!» Если мы будем в числе ваших клиентов, все скажут: «Ах!» Требовать с таких клиентов, как мы, деньги с порога — просто неприлично!» Однако, дорогой клиент, черепки из-под твоих копыт уже стоят поперек горла, и хочется крикнуть: «Довольно!».
Если клиент не хочет платить за ТЗ, плохо будет всем:
Во-первых, это не позволит потратить на ТЗ необходимый объем рабочих часов, внести все правки и добиться утверждения.
Во-вторых, если клиент не хочет вам платить за ТЗ, то захочет ли он платить за разработку в полном объеме?
К бесплатным ТЗ клиенты часто относятся легкомысленно и воспринимают их скорее как коммерческое предложение, а не как что-то требующее внимания, напряжения участия. По итогам работы по бесплатному ТЗ вы можете услышать: «Нам нужно решение задачи, а не ваши бумажки!»
Почему же нужно платить за ТЗ? Например, потому, чтобы не оплачивать риски, которые обычно закладываются в разработку без него.
5. «Мы хотим увидеть варианты!»
Мое любимое. С этими товарищами каши не напишешь, т.к. вымучить 3–4 разных ТЗ на выбор — выше моих сил.
Этим клиентам я обычно предлагаю услугу проектирования идей. Работает это так: договариваемся о формате представления и количестве идей, пишем для примера первую идею, после этого креативим со всеми знакомыми и друзьями по формату.
Смех тут в том, что если вы слышите: «Мы хотим увидеть варианты!» — то все равно начинать необходимо с ТЗ. Только ТЗ нужно составить не на систему, а на идеи. Да-да, бывает мини-задание на идеи. Очень полезная вещь, рекомендую!
6. «А вдруг у нас изменится концепция»
Кажется, что-то похожее говорили поляки Сусанину… Такой клиент, как правило, считает, что ТЗ как-то ограничит его полет мысли, фантазию и творческий креатив. Обычно, все это кончается в глубоком болоте, в котором никто уже не знает, куда мы едем и о чем мы договаривались.
При этом, когда есть даже самое простенькое ТЗ, которое позволяет сдвинуть проект, креативный клиент весло впрягается в работу, и его бурное фантанирование уже не разваливает проект, а придает ему силу реактивной струи.
В процессе разработки не помешает иногда бить креативного клиента распечатанным и подписанным ТЗ по источнику креативной струи, чтобы не улететь с орбиты в глубокий космос.
7. «Нам нужен точный клон этого…»
Вот на такое я не люблю писать ТЗ. Страшно изматывает. Какие-то веселые ребята пилили какую-то систему годами, она обрастала всевозможными рюшечками и наворотами, и теперь весь этот фарш, к которому шли постепенно и эволюционно, нужно сесть и описать. Работа для настоящих следопытов!
Как жаль тех разрабов, которые ввязываются в клонирование без ТЗ. Ну это как будто вы, глядя на героев Mortal Kombat, пытаетесь научиться драться. Также смешно и жалко.
И еще из опыта: часто бывает так, что к «точному клону» потребуется «пара незначительных модификаций», которые само-собой рушат всю логику и механику донора.
Пишу, а в почте как раз очередной запрос на точный клон этого…
8. «Придумайте сами — вы же специалисты!»
«О да, мы специалисты!» — говорит обычно коммерческий директор и важно надувает лоснящиеся щеки. «Сейчас мы расскажем вам, как лучше! Мы же знаем, мы же — специалисты, у нас же — компетенции!!!» После этих слов у клиента загораются глаза и он думает: «Вот, наконец, я нашел людей, которые сразу поняли суть моего проекта, услышали меня!».
Обычно мираж окончательно рассеивается на втором десятке раундов правок готового проекта.
Недавно как-раз вытягивал завязший проект. На 32-ом раунде правок, длившихся полтора годика, решили все-таки написать ТЗ на правки, и все быстренько финализировалось.
9. «Мы сами напишем/написали ТЗ»
Однажды подключившись к одному, слегка затянувшемуся на несколько лет проекту, я наконец спросил: «Ребята, а у вас было ТЗ?» На что мне ответили: «Где-то у нас был видеоролик, на котором клиент рассказывает что хотел.»
Часто клиент присылает какой-то треш с клоунами на вертолете. Но я — не жадный, я в ответ даю примеры заданий, составленных мною, и прошу оформить все в таком же формате. После этого «самописцы» пропадают на полгодика.
Но есть клиенты, которые действительно сами написали ТЗ очень понятно. Один из самых моих любимых клиентов согласился все заполнять в моем формате и делает это регулярно на радость разрабам. И конечно некоторым клиентам ТЗ составляли специалисты, что тоже приятно.
10. «Другие программисты не примут ваше ТЗ»
Довольно часто слышу это возражение. Обычно принимают, так что смело предлагаю переписать под новых разрабов, если не примут. Был забавный случай. Сдал ТЗ, а разрабы на стороне клиента говорят, что это не ТЗ. Ну давайте ваш формат — переделаю. Формата нет. Ну скажите что не нравится? Говорят, мол, не по ГОСТу! Ну, давайте сделаю по ГОСТу, но за доп. плату. Вы ГОСТ-то видали? Похоже, что нет.
Из опыта я знаю, что очень многие разрабы не читают ТЗ. Поэтому лучший способ с этим бороться — читать его вместе с ними. Лучше всего воспринимается сценарий действий пользователя и описание экранов. Эти два документа обычно исчерпывающе описывают систему. Иногда к этому добавляется API и таблицы с математикой, если есть.
А вот есть, например, ТЗ по ГОСТу с тендерных площадок, или же гигантские API на 300 типов запросов. Тут мне приходится переводить уже для разрабов на человеческий язык.
Надеюсь ничего не забыл. Расскажите о своих кейсах, и методах работы с возражениями. Буду рад выслушать ваши мысли как в комментах, так и в ЛС.
Комментарии (4)
14 ноября 2016 в 12:54
0↑
↓
Не вижу пункта «я разработчик, но ТЗ предоставляет заказчик». Иногда даже с примерами интерфейсов, которые ему нужны. После обсуждения и внесения изменений согласовывается окончательный вариант. Через год-два от того первоначального ТЗ неизменным остается только титульный лист. :)
krivotester
14 ноября 2016 в 12:55
0↑
↓
Точно, но наверное нельзя уже править, иначе сломается?Но у меня кстати база всегда остается, но обрастает дополнениями.
Loxmatiymamont
14 ноября 2016 в 12:59
0↑
↓
И где-же пример вашего супер формата?14 ноября 2016 в 12:59
0↑
↓
Ну как же? ТЗ — это работа, на которую требуется время. Более того, это работа с полезным результатом (который можно отдать другому исполнителю на разработку). Поэтому она должна быть оплачена.
