Без ТЗ: как разработчики в такое ввязываются
Результаты опроса из прошлой статьи меня шокировали. Ведь когда разработчики берутся за проект без ТЗ, умирает один неоперившийся аналитик и 10 маленьких котят. Зачем вы так? Как же так получается? 
Почему так происходит? Что можно сделать? Вот несколько версий :
Версия 1: боюсь потерять клиента
Всем знаком этот первобытный страх! Он достался нам в геноме от пещерных программистов! Если я упущу этого клиента, то мне нечего будет жрать!!! Возьмите себя в руки, председатель!
Пока мистер Без ТЗ жрет ваш мозг, за это время можно успеть найти более вменяемых заказчиков, и заработать гораздо больше.
Потеря клиента лишь стимулирует активнее искать новых. Иллюзия, что следующего заказчика придется искать очень-очень долго, развеется, когда вы сконцентрируетесь на оптимизации процесса поиска, технологии выявления наиболее выгодных заказчиков из всего мутного потока. Чем более вы активны, тем больше вас знают, тем больше к вам обращаются сами.
У меня не раз бывало такое, что меня рекомендовал своим знакомым заказчик, с которым мы не договорились. То есть он ушел раздосадованный, а потом бац! рекомендует меня знакомым, партнерам, любовнице… Правда, по таким рекомендациям часто тоже такое себе приплывает…
Нужно понимать, что каждый заказчик немного мазахист, они любят когда с них тербуют, отказывают им. В отношениях с заказчиком должен присутствовать едва уловимый BDSM. Если вы ведете себя в духе «что барин изволит?», то возникают подозрения, а не менеджер ли вы?
Версия 2: для друзей
Иногда кажется, что разработка проекта с друзьями пройдет как загородный отдых с морем позитива, водкой и шашлыками. Туман развеивается после первого же раунда правочек, когда оказывается, что все не то и все не так, и не понятно, как жизнь свела вас с этим бестактным быдлом. Как вообще вы могли дружить столько лет?
Если хотите делать проектик с друзьями, то окажите им услугу в составлении подробного ТЗ, позаботьтесь о тех, кто вам дорог. При этом нужно понимать, что вы скорее всего рассоритесь еще на этапе написания ТЗ, а то и раньше.
Вот, вам занимательная история одного проекта «по дружбе». Моему близкому другу надо было срочно и недорого запускать интернет-магазин, потому как инвестор дал «добро», и контейнер уже плыл из Китая. Я сразу предупредил, что это не совсем моя тема, так как я в основном работаю с корпоративными e-learning продуктами и медицинскими системами, но чего-нибудь придумаем. Итак, инвесторские деньги выделились, и друг проявился в моем поле зрения с бодрым: «Ну, давай портфолио по интернет-магазинам! Мы подрядчика выбираем! Только присылай побыстрее, не затягивай!» Я слегка фаломорфировал о того, как быстро «Спаси-помоги, друг дорогой!» трансформировалось в: «Я пришел к тебе с редкой возможностью поучаствовать в моем тендере!» и слил кореша с формулировкой: «У меня тут заказ на несколько миллионов — сорри, сейчас некогда портфолио по магазинам собирать». Друг обиделся, но сообщил мне, что я «всё равно в шорт-листе». На том и порешили.
Версия 3: для себя
Кажется, что вы-то уж точно знаете, чего хотите. Внутри коллектива все должны быть на одной волне, это же командный дух! Поэтому лучший способ рассорить даже самую сплоченную команду — работать без ТЗ над внутренним проектом. Тут каждый участник получает уникальную возможность проявить себя с лучшей стороны. Какой простор для личной критики: «Я раньше и не знал, что работаю с такими конченными рукожопами!»
А сколько можно делать правок! Когда логотип в шапке 18-й раз меняет свой размер на 2 пикселя, потому что «он всё ещё смотрится как-то непрофессионально», вы начинаете чувствовать, что что-то пошло не так. Но оставьте сомнения! Вы же это не для клиента какого-нибудь, а для себя делаете! Так что не бойтесь еще раз 50 поменять концепцию — это точно поможет бизнесу! Вот почему часто внутренние проекты вполне успешных IT-компаний затягиваются на века.
Версия 4: начинающий разработчик берусь за любой ад
Легче всего охмурить юных нежных разработчиков, которые пламенно жаждут портфолио с крупными громкими проектами, открывающее любые двери. Но, как известно, без ТЗ получается ХЗ. А потому все это стыдно вообще кому-то показать, если конечно удастся дотянуть этот ужас до конца. «Вот, мы тут делали… И почти доделали! Оно не работает, но, в целом, видно суть».
Если вы начинающий разраб, не стесняйтесь требовать ТЗ — это поможет вам отличить нормальных заказчиков от космонавтов, которые заставят вас возненавидеть профессию, себя и весь мир.
Опытные господа-разработчики подтвердят, что портфолио и опыт лучше нарабатывать в команде настоящих профессионалов, как со стороны заказчиков, так и со стороны исполнителей.
Частенько портфолио собираются по принципу: «Мужик, ты на Drupal-е чего-нибудь собирал в этом году? Дай списать!» Клиенты — такие затейники, и часто их не устраивает «просто портфолио». С меня как-то потребовали портфолио CRM для ТРЦ, чтобы подтвердить мою компетенцию в данной области.
Версия 5: важный клиент
Здесь так не принято. Мы никогда нигде и ни с кем так не работаем.
Помните эксперимент, когда всех обезьян в клетке поливали ледяной водой, если одна из них покушалась на бананы на верхушке лестницы? Нарушительницу больно били, и за бананами никто не лез. Потом в клетку подсаживали новенькую, она лезла за бананами — тут же получала люлей, а потом уже сама мутузила очередную новенькую. Ученые по одной заменяли всех обезьян в клетке, и постепенно остались только приматы, которые ледяного душа в глаза не видели, но за бананы новеньких продолжали бить.
Я это к чему? В крупных компаниях работают как раз такие обезьяны: «У нас в компании принято платить за финальный результат с отсрочкой платежа 60 дней!»
Что ж, тогда остается только опросить разрабов, получить среднепотолочную оценку «этого», умножить ее на 3… нет, лучше на 5, и смело вписывать в КП. Купят — хорошо, не купят — и слава богу, потому что драть будут, как за Х10, всею вертикалью власти от младшего стажера до генерального.
Конечно же, может найтись «свой хороший мальчик», который все сделает в два раза быстрее и дешевле. Надо встретить такого мальчика с позитивом, пообещать помочь советом, если что! А ближе к концу (предполагаемому) проекта позвонить и поинтересоваться: «Как дела?»
На самом деле, крупные компании не боятся крупных сумм, особенно если ты их можешь обосновать. Если ты выехал за их бюджет, тебя попробуют уломать на скидон. И тут можно выцепить из всей тусовки, которая, как правило, заваливается на встречу, более-менее вменяемого человека и попытаться объяснить ему, что есть такой хитрый способ с ТЗ, предварительным описанием контента, экранов и сценариев, который волшебным образом может снизить сумму — надо только эту работу оформить и провести как-нибудь так… Как-нибудь так отдельно и авансом… За счет другого бюджета. Ну, они там у себя лучше знают.
Версия 6: неквалифицированные заказчики
Допустим, приходит к вам что-то незамутненное с развесистыми ушами, считающее что программное обеспечение находят в капусте, прямо как детей.
Ну и прекрасно, займитесь ликвидацией безграмотности. Обучите клиента. В следующий раз он не будет связываться с теми, кто не предлагает ТЗ на входе. Ну, а если свяжется, хлебнет полной ложкой, то позже все равно вернется к вам.
Версия 7: программист на зарплате
Хорошая зарплата и кодить — это вторая по популярности мечта программиста после оплаты по часам. 250К, соцпакет и прямо в рай! И жизнь удалась! What a beautiful life! На самом деле, нет. Даже такие условия можно превратить в ад.
Итак, приходит к разработчикам звезда пиара aka PR-менеджер и сообщает, что ей срочно-срочно надо поднять маааленький сайтик с регистрацией, мини-играми, начислением баллов за активности и магазином призов. Разработчик на зарплате любезно сообщает ей, что она должна скачать с GitHub стандартную форму ТЗ (содержащую, например, такие поля как «требуемый уровень безопасности данных пользователей» и «предполагаемый уровень пиковой нагрузки на сервер»), заполнить её и закоммитить обратно. Подробную инструкцию о том, что и как, она без труда найдет на корпоративной вике. Звезда пиара уходит, как обоссаный кот, но, в отличие от программиста-аутиста, она на то и звезда пиара, что умеет общаться с нужными людьми, поэтому начальнику отдела разработки прилетает по макушке, он достает наручники и пристегивает программиста к батарее на сутки-двое, пока тот не запустит маааленький и очень срочный промо-сайтик. А звезда пиара уже довольная бежит к нему с дизайном, который сделал гениальный маэстро из отдела медийной рекламы и который можно натянуть разве что на… Ну, вы поняли. Поседевший к утру программист-на-зарплате запускает-таки промо-сайтик, на который включается партнерский гига-трафик, который хоронит и промо-сайтик, и еще несколько важных внешних и внутренних сервисов. Начальник отдела разработки снова достает наручники.
Версия 8: лень, некому делать ТЗ
«Я разработчик, и я не хочу писать ТЗ, я хочу алгоритм и копи-пейст!» Но почему бы не попросить клиента решить эту проблему? Аналитик вполне может быть на стороне клиента и выдать что-то вполне вменяемое.
Если аналитика нет ни у клиента ни у вас, ну так наймите же его и выставьте клиенту счет!
Версия 9: заказчик не знает как должно быть
Что может быть круче, чем неквалифицированный заказчик? Однажды я писал ТЗ для школьника. Ну т.е. заказчиком был школьник, наверное, очень богатый школьник. Это был самый сложный для меня проект, т.к. очень многое пришлось придумывать самому — просто у молодого человека не было какого-то мнения по многим вопросам.
Бывает, что заказчик так и говорит: «Я не знаю, чего хочу — предложите варианты!» И очень хочется начать делать эти варианты, но надо взять себя в руки и составить ТЗ на варианты (да-да, варианты тоже должны делаться по ТЗ).
Версия 10: ради будущих крутых проектов
Когда я дописывал эту статью со своим прекрасным редактором, к нам пришел приятель и рассказал, что берется без ТЗ ради будущих проектов:
— Сейчас возьмусь за копейки и без ТЗ, зато, потом они купят у меня мегапроект по нормальной цене!
— Но почему?!
— Я в это верю! И мне реально интересен этот проект!
— Но почему они купят?
— Аааа, не знаю! Ну, о-кей, вы меня застыдили! Я больше не буду так делать!
Версия 11: «Я хочу, чтобы у вас глаза горели!»
Бывают такие заказчики-искусители, шоу-мены, ораторы от бога, которые умудряются разжечь нехилый интерес к проекту даже у самого прожженного разраба с тленом в глазах. Я часто слышу именно такую фразу: «Я хочу, чтобы у вас глаза горели!» — и она сразу заставляет меня насторожиться. Часто подобные заказчики сопровождают свои речи щедрыми обещаниями доли в проекте или роли эксклюзивного оператора сверх-успешного продукта или сервиса. В общем, разработчик начинает верить, что делает проект для себя, а тогда зачем такие формальности, как ТЗ?
Я безмерно уважаю людей с горящими глазами, но, пожалуйста, оставьте немного вашего сухого горючего на ТЗ!
Вывод
За всю мою деятельность отказ от ТЗ ни разу не помог упростить проект или заработок. Проблема в том, что в IT-проектах ТЗ пока не стало такой же обязательной частью подготовки. Как, скажем, в строительстве, где без проекта не рекомендуется строить даже деревенский сортир. Разработчики, ну пожалуйста, сделайте ТЗ отраслевым стандартом и научите клиентов, что иначе не бывает.
PS: Не забываем писать в комменты почему и как вы взялись без ТЗ, кто вас к этому склонил, какие хитрости и уловки использовал.
Комментарии (9)
AllexIn
7 декабря 2016 в 10:47 (комментарий был изменён)
0↑
↓
Что такое «работа без ТЗ»?
Это когда заказчик сам не приносит готовое ТЗ? Ну так бывает в 99% случаев. И слава богу. Потому что когда приходят с готовым ТЗ — там такой АД, как правило…Нормальный workflow:
Приходит заказчик. Расписывает чего хочет. Я составляю ему ТЗ (иногда бесплатно, иногда за деньги). После чего ТЗ утверждается и мы дальше спокойно работаем.Уверен, что большая часть проголосовавших за «Иногда работаю без ТЗ» — также делает — составляет ТЗ самостоятельно. А автор почему-то решил, что все поголовно делают «не знаю что, но надо сделать».
krivotester
7 декабря 2016 в 10:50
0↑
↓
«Я составляю ему ТЗ (иногда бесплатно, иногда за деньги). После чего ТЗ утверждается и мы дальше спокойно работаем.»Вы большой молодец, но так далеко не у всех происходит, к сожалению.
-
AllexIn
7 декабря 2016 в 10:52 (комментарий был изменён)
0↑
↓
ИМХО пару раз поработаешь без точного определения что нужно делать — и сам начнешь ТЗ составлять.
Потому что переделки и хотелки заказчика нужно ограничивать, иначе они вылазят далеко за пределы срока и бюджета.
Так что я уверен, что большинство так делает. Просто первоначальный опрос не раскрывает это.-
krivotester
7 декабря 2016 в 10:55
0↑
↓
Думаю вы просто сами умеете делать правильно и вам кажется, что иначе нельзя -)Далеко не все делают правильные выводы из сложившейся ситуации, и это не только разработки ПО касается.
По предыдущему материалу есть не только голосования, но и комменты. И в этих комментах есть даже защитники БезТЗ.
7 декабря 2016 в 10:53
0↑
↓
Нет самого интересного варианта. «Работаю на доверии». А уж как завоевать обоюдное доверие — это отдельный вопрос.-
AllexIn
7 декабря 2016 в 10:59
0↑
↓
Доверие никак не связано с ТЗ.
У меня по большинству заказчиков «открытый договор». Акт о проделанной работе я сдавал последний раз лет 5 назад. Но при этом со всеми заказчиками есть ТЗ.
Donny
7 декабря 2016 в 10:54
0↑
↓
А заказчик вам платит за ТЗ? Или как вы договариваетесь, если он, в итоге, не закажет, например. Вот, для меня это самая большая проблема, например: куча работы по исследованиям проблемы и пресейлзу, а потом заказчик пропадает.7 декабря 2016 в 10:57 (комментарий был изменён)
0↑
↓
А что вы называете буквами «ТЗ»? То, на что есть ГОСТ? А вы такое сами составить пробовали?Обычно заказчик примерно знает, чего он хочет (очень примерно), на основании детального допроса делается общий план сверху и детальное представление о том, что делать, на итерацию (1–2 недели). Все целиком сразу и подробно расписывать смысла нет, потому что он еще передумает сто раз, и это нормально. Как расписывается итерация — зависит от достигнутого уровня взаимопонимания: сначала, пока друг в друге не уверены, можно и приложение к договору расписать, а со временем и увеличением взаимопонимания и доверия уже хватает логов чата и зарисовок на салфетке. Обычно удобнее всего мокапы с комментариями.
-
AllexIn
7 декабря 2016 в 11:00
0↑
↓
ТЗ — это то, что позволяет однозначно ответить на вопрос: соответствует результат ожиданиям или нет.
А уж его форма и содержание — дело десятое.
