Результаты опроса из прошлой статьи меня шокировали. Ведь когда разработчики берутся за проект без ТЗ, умирает один неоперившийся аналитик и 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: Не забываем писать в комменты почему и как вы взялись без ТЗ, кто вас к этому склонил, какие хитрости и уловки использовал.
Автор: krivotester