Обожаем писать статьи в блог, т.к. можно в неформальной обстановке донести вполне конкретные вещи и поставить любую картинку как главную. Особенно, если она в тему.

Итак, на эту статью мы будем часто давать ссылки нашим потенциальным клиентам, если в процессе общения мы придем к ситуации «Вам надо ТЗ? Вот же у меня описано всё. Мало?».

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

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

А пока немного предыстории…

Случился тут один проект, на примере которого мы и захотели потом сделать эту статью, ибо будет ну очень показательно. Всё началось со стандартной встречи с клиентом, где мы обсуждаем самые общие требования к системе, чтобы понять – а мы вообще можем помочь? Но эта встреча была другой.

Потому что 3.5 часа клиент рассказывал…рассказывал…рассказывал…и рассказывал. А мы слушали…слушали…слушали:

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

– У меня есть пожелания текстом
– Вот так удача! (подумал я, но сказал другое)

– Отлично. Давайте посмотрим
// присылает файл

– Это всё?
– Ну да
– Вы же явно с другими тоже общаетесь, вы там тоже по 3 часа рассказываете?
– Ой да…устала уже.  Ну а как иначе

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

Конечно, даже с таким ТЗ можно найти ответственного исполнителя, кто доведёт дело до результата даже тогда, когда осознает, “куда он вписался”. Но каков шанс такой удачи? Уж лучше более основательно подойти к описанию самих требований.

В конце концов мы приходим к тому, что если у человека есть информации на 3.5 часа текстом (и это лишь поверхностная информация!), то определенно нужно составить более детальный документ. Оценивать по этим 1.5 страницам – как пальцем в небо тыкать.  Мы привыкли оценивать результат, а не объём предлагаемых нам денег.

Итак, договоренность есть – мы будем делать техническое задание!

 

— — —
Пс, сделаем тут оговорку на случай, если вы более тесно знакомы с темой составления требований. Мы знаем, что есть разные ГОСТы, по ним описываются требования к составлению технического задания. А есть ещё отдельное понятие «технические требования», и это разные вещи, и как раз требования делаются до подписания договора, т.к. они имеют более общий характер, нежели пошаговый план к реализации. И мы уже молчим про документ «Процедура принятия работы» (или как он там называется).

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

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

 

Т.к. работа тут довольно крупная, на несколько месяцев, то и для составления ТЗ одной встречи мало. Договорились, что в итоге нам надо провести 5-6 встреч часа по 2 часа. Потому что на первой встрече мы получили лишь общие наброски желаемого, а теперь надо более детально погрузиться в каждый описанный пункт.

Все встречи мы будем записывать на диктофон, а потом переводить в текст. Т.е. потери информации не будет от слова «вообще». Вот что наговорит клиент, то будет в документе в читабельной форме в 2-х формах

• Наша структурированная мысль
• Мысль, как она была озвучена клиентом

Ну вот, кусочек от финального «замазанного» документа вы уже увидели 🙂

Запись разговора позволяет позже в спокойной обстановке всё перевести в текст и логически структурированную форму для дальнейшей оценки работы. И что очень важно – НЕ напрягать мозг попытками загрузить долгосрочную память на встрече, чтобы ничего не забыть. Нет. Это позволяет наоборот – погрузиться в моменте в обсуждаемое, задав максимальное количество вопросов про то, что говорит клиент. Поверьте, это работает.

К слову, первая встреча вылилась в такой объем информации:

Больше, чем 1.5 страницы текста, да? И это лишь первая встреча!
Конечно, не по каждой встрече был такой объём. С каждой последующей встречей всё меньше и меньше добавлялось новой информации, т.к. много времени уходило на такие моменты, как:

– А система вообще отдаёт эти данные?
– Хм…не знаю, дайте гляну
// ожидание
– А нет..не отдаёт, как же быть

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

Нам критически важно было сделать документ таким, чтобы его могли понять, не только мы, как авторы документа, но и сам клиент и возможные другие компании, кто будет по нему оценивать работу. Поэтому мы не старались всё привести к сухой структурированной форме того, как МЫ это видим. Наоборот – добавляли как можно больше комментариев от клиента именно теми словами, как он это говорил. Мы лишь создали некий «скелет» для всей той информации, что он «излил» на всех встречах.

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

Конечно, это не является 100% «маршрутной картой» для разработчика по внедрению системы, это уже будет в процессе работы, но это то, что уже реально позволяет оценить объём работы. Причем порой это «открывает глаза» и для самого клиента, т.к. изначально думалось «да чего там делать-то…»

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

1. По всему документу убрать коммерческую информацию, заменив её на текст «ХХХХ»
2. Сделать водяной знак
3. Сделать всё это картинками, хоть и в одном PDF файле 🙂

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

Вы уверены, что вы не находитесь на месте этого клиента? Задумайтесь над этим…

Документ можно скачать по этой ссылке –  “Техническое задание от ЭффКонтекст” (20 мегабайт)

 

P.S.
В этой статье в самом конце прямо захотелось разместить ещё несколько мемов на тему составления технического задания. Просто для поднятия настроения 🙂