Как я научился работать по техзаданиям: неочевидные плюсы очевидного решения из песочницы

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

Дело в том, что заказчики приходили ко мне в основном по рекомендациям, задачи и пути их решения были схожими. Я лихо совмещал фриланс с постоянной работой (кстати, совершенно не связанной с разработкой). Все было замечательно, пока на горизонте не появился действительно серьезный заказчик с действительно серьезным заказом.

Итак, первая встреча – первые ошибки

Первая встреча с заказчиком (тогда еще потенциальным) прошла просто замечательно. Уже тогда я четко понимал важность технологий общения в бизнесе. И, хотя, бизнес на тот момент был даже не малым, а микроскопическим, мое отношение к общению с заказчиком было более чем серьезным. Я лихо демонстрировал последние проделанные мной работы, описывал процесс поиска тех или иных решений на пути к созданию совершенного конечного продукта, доступно раскрывал преимущества, которыми эти решения обладали. Представитель заказчика слушал меня, открыв рот. Он демонстрировал какие-то схематические каракули на мятых листках бумаги, показывал схожие системы, я с ходу генерировал и высказывал удачные идеи.Через какое-то время заказ был мой.

С этого момента моя история теряет положительный окрас. На переговорах с заказчиком я допустил роковую ошибку, сделав привычный ход, ранее позволявший мне с легкостью «завоевывать» прежних заказчиков. А именно: опираясь на исходные данные в виде невнятных рисунков на мятых листках, я обозначил стоимость. Конечно, я сделал оговорку, что эта стоимость – ориентировочная, однако в дальнейшем моя опрометчивость сыграла не в мою пользу.

Дело в том, что на этот раз заказчиком выступал отдел одной очень крупной телекоммуникационной компании. Как я узнал потом, среди отделов был разыгран конкурс на разработку и внедрение некой системы мониторинга. Руководитель отдела, который впоследствии и стал моим заказчиком, решил добыть победу на конкурсе своим путем – сделать некое подобие нужной системы, только не на бумаге – как сделали это остальные, а в виде уже готовой «куклы». Но сделать в рекордно короткие сроки. Поэтому техзадание и было изложено на мятых листках: конкурсная комиссия, от решения которой зависит, какому отделу достанется почетная задача по созданию системы и причитающийся к ней бюджет, скорее всего не стала бы придираться к мелочам. В результате существенная часть вопросов была недоопределена или пропущена вовсе.

Но мне в тот момент все это было неизвестно. И я рассудил как обычно: что не оговорено на «мятых листках» я решу сам по ходу работы. Отрицательные последствия этого решения не заставили себя ждать.

Тендер выигран, едем дальше

Более или менее в срок я выполнил работу и сдал сдал систему в виде той «куклы», которую задумал мой заказчик. Был завершен первый этап разработки. Далее стояла задача сделать из нашей «куклы» более-менее работающую систему.

И вот на этом этапе открылся ряд неприятных нюансов, связанных с заказчиком. И возникли первые негативные нотки в наших отношениях:

• Поскольку заказчиком выступал не один человек, а отдел мой телефон и моя электронная почта стали общедоступными… Любой, кому в голову приходили светлые, по его мнению, (или просто какие-нибудь) мысли по поводу моей работы, считал нужным немедленно сообщать их мне лично по телефону или любым другим удобным ему способом… или всеми способами сразу. Мои просьбы руководителю отдела сократить количество общающихся со мной сотрудников имели, как правило, кратковременный эффект. Через пару дней мой телефон снова начинал разрываться в любое, удобное кому угодно время, а в почту летели нескончаемые потоки различных (подчас, противоречивых) предложений и пожеланий.
• Часто возникающие противоречия в решении тех или иных вопросов сводились к спору «обсуждали – не обсуждали», «определили – не определили», «договаривались – не договаривались». Я оперировал сканами мятых бумажек, заказчик справедливо замечал «это же только макет, когда мы его рисовали, мы же не знали всех нюансов». Помимо этого приходилось разгребать мегабайты писем.
• Руководитель отдела – человек занятой, и зачастую по очень важным вопросам приходилось общаться с его подчиненными. А они, по большей части вчерашние студенты, в разных спорных ситуациях норовили обелить себя перед начальством. Их любимая отговорка «я ему это говорил, просто он неправильно понял».
• Со стороны заказчика по разным вопросам звучали фразы «вы же профессионал, придумайте, как это должно быть устроено », либо «как это должно выглядеть, мы не знаем, но то, как это выглядит сейчас, нас не устраивает».

Последняя капля

Результатом вышеописанных событий стало не только ухудшение отношений с заказчиком, но и лавинообразный рост объемов работы за те же деньги, и, что еще хуже, в те же сроки. А сроки работ, определенные мною на переговорах, были, мягко говоря, наивными – сказалось отсутствие опыта работы с подобным заказчиком. Я честно пытался уложиться в означенные сроки, однако объем моих негативных эмоций огромным водопадом переливался через край чаши моего терпения.

Опоздав на «два этапа» я обратился к руководителю отдела с электронным письмом, в котором подробно поделился наболевшим и изложил свое видение ситуации. Самое главное – я потребовал в срочном порядке сформировать техзадание, отметив свою личную заинтересованность в успешном завершении проекта (что было чистой правдой). В завершение письма я заявил, что, несмотря на эту самую заинтересованность, дальнейшее сотрудничество без техзадания продолжено быть не может. Через две недели техзадание было представлено – заказчик разрабатывал его самостоятельно, без моего участия (однако отсутствие должной квалификации в вопросах организации веб-систем и, как следствие, должного представления того, что же в конечном счете надо получить, сказалось на техзадании плачевно). В результате оно получилось лаконичным, простым и понятным. Беда только в том, что его объем составлял 4 листа, и это для системы, которая на тот момент разрабатывалась уже полгода! Ничтожность объема этого задания на фоне размеров системы становится понятна, если немного забежать вперед — когда система была готова, для описания ее установки и настройки потребовалось 20 листов, а мануал по работе с ней занимал более 70 листов. В довершение ко всему последним пунктом значился переход на совершенно другую платформу (другая СУБД и другая операционная система были корпоративными стандартами). Заказчик (в лице руководителя и нескольких его подчиненных) объяснил, что, да, об этих корпоративных стандартах было известно с самого начала, но не считал необходимым ставить меня в известность о дальнейшем обязательном переходе на другую СУБД. И вообще, другая, отличная от корпоративной, платформа изначально была выбрана намеренно, чтобы (якобы) ускорить процесс разработки (так руководитель видел оптимизацию задачи для скорейшей победы на конкурсе). И на десерт – сроки оставались все теми же. Наше сотрудничество закончилось плачевно: я вынужден был отказаться от дальнейших совместных планов, хотя заказчик пытался «умаслить» меня обещаниями дальнейших заказов. При этом, денег за незавершенную работу я был вынужден не брать.

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

А дальше я бы, как раз, хотел разобрать все те ошибки, которые я допустил, изначально не придавая большого значения написанию техзадания.

Те самые плюсы техзаданий, которые очевидны

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

Техзадание должен писать либо разработчик, либо разработчик вместе с заказчиком. Зачастую заказчики ничего не смыслят в вопросах, с которыми они обращаются к разработчику. Исключения, конечно, есть, но это всего лишь исключения, подтверждающие правило. Если вы потребуете от заказчика самостоятельно написать техзадание, то в большинстве случаев итогом будет несколько листков, содержащих невнятный смысл, на написание которых у заказчика ушла неделя, две, три. И вам придется, теряя драгоценное время, снова выяснять, что же все-таки хочет заказчик и в какой форме. А это негативным образом влияет на психологическую составляющую сотрудничества (заказчику начинает казаться, что он вас знает с пеленок – и что вы с самого его детства делаете этот заказ, хотя могли бы уже давно все закончить). Поэтому самым разумным решением будет взятие инициативы в свои руки. Очевидны два плюса такого подхода: отсутствие негатива со стороны заказчика (разработчик не будет «грузить» заказчика, а сам лихо изложит грамотное ТЗ в короткие сроки – заказчик будет просто в восторге), и экономия драгоценного времени.

Техзадание может должно быть частью маркетинга. Я опасаюсь слова «маркетинг». И особенно забавно слышать о маркетинге, когда речь идет об одиноких фрилансерах, но в данном контексте считаю его наиболее уместным и поэтому разовью свою мысль.

Во-первых, грамотно созданное техзадание, может наглядно проиллюстрировать сложность проекта, что поможет Вам обосновать стоимость и сроки работы. Во-вторых, заказчик редко обращается с заказом только к Вам, чаще он общается с Вашими конкурентами, выбирая наиболее выгодного для него исполнителя. Каждому он каким-то образом описывает задачу. Если у него уже есть техзадание, написанное Вами (самостоятельно, или совместно с заказчиком), то именно его заказчик будет отсылать другим возможным исполнителям для альтернативного просчета проекта. Обратите внимание! Всего лишь предложенные Вами, но грамотно сформулированные в техзадании решения, заказчик будет преподносить Вашим конкурентам как свои собственные требования! Если вы достаточно подробно написали техзадание, «заточив» его под себя и свои приемы, описали уже готовые наработки в виде серьезного целевого функционала, заказчик приходит к Вашим конкурентам не с просьбой «да тут надо ерунду сделать», а с увесистым техзаданием,.которое одних просто испугает, других заставит заломить заоблачную цену. В итоге Ваш шанс получить этот заказ резко повышается.

Техзадание дает возможность избежать потери драгоценного времени, и помогает откорректировать бюджет. В ходе написания ТЗ часто на поверхность всплывают совсем неочевидные нюансы. Продумывание и просчитывание каждого пункта и каждой частички функционала позволяет самому заказчику иначе взглянуть на задачу. Возможно, предыдущий абзац вызвал у Вас негодование: «экий жулик, разводит заказчиков». Так вот, здесь я хочу себя реабилитировать: часто я ненавязчиво пытаюсь заставить заказчика взглянуть на тот или иной вопрос с другой точки зрения: отказаться от каких-либо элементов и частей задачи в случае, если они не имеют никакой смысловой нагрузки. Это позволяет опять же – экономить время, но главное – экономить средства заказчика. Часто слова «зато будет немного дешевле» играют ключевую роль в общении.

Техзадание – это реклама. Вероятно, большинство фрилансеров согласятся со мной:– самые лучшие заказчики – это либо постоянные клиенты, либо клиенты, которым вас рекомендовали. Грамотно составленное и приятно оформленное техзадание часто остается у заказчика даже после выполнения проекта, и он охотно демонстрирует его тем, кому рекомендует Вас с целью убедить собеседника в Вашей серьезности и профессионализме. Такие клиенты – просто сказка. В вашем профессионализме они уверены еще до начала переговоров, и Вы экономите время, и (что еще важнее времени) – собственные эмоциональные силы.

Техзадание помогает «держать марку». Этот тезис можно было бы отнести к пункту о маркетинге или о рекламе, но я хочу рассмотреть его отдельно.

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

Техзадание победителя – каким оно должно быть

Я думаю, что все разработчики в ходе своего профессионального развития накапливают некий инструментарий, который в дальнейшем помогает им сокращать сроки разработки (в редких случаях повышать качество получаемых на выходе продуктов). Поэтому, если Вы решили работать по техзаданию, оно должно тоже иметь некий шаблон, содержащий неотъемлемые атрибуты (помимо, непосредственного описания задачи).

• Дата и подпись сторон
• Контактная информация исполнителя
• Название (пусть даже рабочее) проекта или продукта
• Оглавление
• Цели и задачи проекта (если это проект) или продукта (если это продукт)
• Технические нюансы реализации, жесткие и конкретные требования к платформе, на которой проект или продукт должен быть реализован
• Сроки выполнения
• Стоимость
• Пункт об отчуждении прав на конечный результат деятельности в пользу заказчика (пункт довольно редкий в нашей стране)

Заключение

Безусловно, все вышеописанное ставит под сомнение термин «техническое задание». Быть может, стоит воспользоваться терминами «техническое предложение», «описание», «соглашение» и так далее… но в любом случае – смысл публикации совершенно в другом. Желаю вам приятной, прибыльной и продуктивной работы!

UPD: спасибо моему партнеру Александру Афанасьеву, которого я считаю соавтором этой статьи.