Техническое задание и техническое решение + шаблон

Часто возникает проблема между Заказчиками и Разработчиками в понимании друга друга и задачи.

Чтобы решить эту проблему обычно Разработчики говорят Заказчику – напиши ТЗ (техническое задание). Чтобы понять что нужно.

Чаще всего это приводит лишь к усугублению проблемы 🙂 Потому что обычно вместо ТЗ пишется некий документ содержащий сочинение на тему желаний. Который затем достаточно сложно реализовать.

Почему так происходит? Смею предположить причина в том что стороны не понимают что такое ТЗ, в чем его смысл, как оно выглядит и что должно быть после него 🙂

Как задать вопрос или описать задачу? Методы WWH и 5W1H в WordPress

Одна из ключевых проблем в разработке – это умение задавать вопросы и описывать задачи. Правильно заданный вопрос – это половина успеха. Причем тут WWH и WordPress? Существует сотни методик формулировки вопросов и описания…

1. ТЗ и ГОСТ
2. ТЗ и Бритва Оккама
3. Техническое решение или ТР
4. Почему ТР важно?
5. Когда можно без ТР?
6. Шаблон
7. Еще проще – идем через спецификацию
8. Итого

ТЗ и ГОСТ

Чаще всего люди идут гуглить что такое ТЗ, налетают на ГОСТ и пытаются делать по нему 🙂 Вот только они не учитывают что ТЗ по ГОСТ было придуман для проектов на 1000 человек, и только одна подготовка такого ТЗ если делать ее правильно может стоить 1-2-10 млн. руб. Не считая работ по его реализации. А пытаются это применять для проектов где работает 1-2-3 человека 🙂 Делается это все без понимания особенностей такого документа и получается как раз то самое собрание сочинений. Бессмысленное и беспощадное.

ТЗ и Бритва Оккама

Бритва Оккама в данном случае говорит о том что наиболее простое решение – наиболее верное. Если нет веских причин для усложнения.

Какое самую простую форму ТЗ можно придумать? Ответ – простой список задач (требования, пожеланий). Чаще всего именно эта форма наиболее адекватна.

Иногда она может расширяться некоторыми полезными артефактами (разделами):

• Цели – описать не только то что надо сделать, но и для чего мы это делаем? Чтобы что? Это бывает полезно для повышения качества результатов.
• Снимки, фото, звуки, примеры – бывает полезно добавить в задание снимок ошибки (например когда мы делаем сайт) или пример/фото того как это сделано у кого-то еще.

Да, если проект реально большой, у вас есть 10-20 человек заинтересованных в результате, ТЗ согласовывается с ними пол года, а потом есть 100-200 человек, которые будут реализовать этот проект – тогда можно взять ГОСТ или сделать какой-то большой документ. Иначе – у вас не хватит ресурсов сделать качественную постановку задачи, а потом те кто будут делать – не осилят изучение. И один лишь контроль приемки работ по такому ТЗ превратится в ад.

Техническое решение или ТР

А вот та самая часть, которую многие совсем не понимают. Кроме технического задания (в котором может быть просто 3-4 пункта пожеланий на салфетке из кафе), может быть еще техническое решение. Оно чаще всего гораздо важнее чем ТЗ и сильнее влияет на конечный результат.

Техническое решение – пишет как раз Разработчик, где описывает то как он видит решение, что предлагает.

Зачем это нужно? Чтобы исключить разное понимание условий и снизить риски расхождения ожиданий.

Пример для понимания. Заказчик дает ТЗ “Я хочу есть”, а Исполнитель предлагает ТР “На вот яблоко”. Далее может быть 3 сценария: Заказчик соглашается, корректирует/просит предложить что-то еще или отказывается от дальнейшего общения 🙂

Чаще всего Заказчик либо принимает решение, либо просит что-то поправить и затем принимает решение.

Почему ТР важно?

ТР важно по ряду причин:

• Только Разработчик реально знает как решать задачу (по этой причине Заказчик обычно к нему и обращается), а значит только он может описать детали того как можно получить ожидаемый результат
• У любой задачи может быть 3-4 варианта решения (а часто больше), и тут Заказчик должен убедиться что Разработчик может предложить нечто адекватное
• Задача одна, но несколько вариантов решений часто означает разные цены. причем вилка цен может быть условно от 100 000 руб до 10 000 000 руб. ТР позволяет составить список условий и сузить разброс цен – уложиться в нужный бюджет и срок.

По ходу составления списка решений, предложений и условий – Разработчику надо будет задавать вопросы, обсуждать детали, он просто начнет понимать задачу 🙂

Именно составление ТР – позволяет Разработчику понять Заказчика. А Заказчику убедиться что Разработчик понял задание. Именно отсутствие этой части в проекте – зачастую приводит к недопониманию и конфликту.

Когда можно без ТР?

Есть некоторые ситуации когда ТР не нужно. С ходу могу назвать 2 условия:

1. Если между Заказчиком и Разработчиком есть полное взаимопонимание и доверие, большой успешный опыт совместной работы. Когда Заказчик целиком доверяет Разработчику и полагается на его знания.
2. Если мы работаем по Agile и у нас мелкие простые задачи

Исключение из п.2 – даже в Agile, если есть большая задача (Epic-project), у которой как правило 3-4 стейкхолдера, ее будут делать 2-3 разработчика на 5-6 месяцев, то не помешает сформулировать ТЗ и потом прописать/согласовать ТР. Чтобы убедиться что Стейкхолдеры (Заказчики) и Разработчики (Исполнители) – поняли друг друга.

Шаблон

Инструкции и шаблон тут https://docs.google.com/document/d/1ydqe0H-HjzVD4lt6ZbkUdpQNqleJZoTEIqJtTRcu6dE/edit?usp=sharing

Еще проще – идем через спецификацию

В целом все это можно упростить до 1го простого документа – спецификация.

Но писать этот документ нужно через метод WWH.

Шаги такие:

1. создаем документ и называем его – Спецификация
2. далее 3 ключевых раздела: Что нужно? Почему это нужно и чтобы что? Как это планируем делать?
3. После того как сделали документ и описали 3 ключевых вопроса – можно докинуть еще другие разделы по вкусу и по ситуации.

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

Важно тут учитывать что докидывать информацию имеет смысл если есть причины. Усложнение без причины – признак дурачины. Избыточная информация также вредна как и ее недостаток.

Итого

Разработчики часто жалуются на то что Заказчики не могут написать хорошее ТЗ. А без внятного ТЗ как известно результат ХЗ.

Как мне кажется причина не в том что Заказчик не может написать хорошее ТЗ, а в том что никто не понимает что это такое. В том числе сам Разработчик.

И даже если Разработчик поймет что такое ТЗ, то для написания ТР снова нужны усилия и ответственность. А если лень то получаем рост Риска получить в результате не то что ожидали + Конфликт.

Потому эти особенности надо запомнить как Заказчику, который хочет получать ожидаемые результаты и на старте оценить адекватность Разработчика. Так и Разработчику, который хочет сделать то что нужно Заказчику, деньги, отзыв и славу 🙂

Основные тезисы:

• Заказчик пишет ТЗ, оно может быть коротким, на салфетке из кафе, и содержать 3-4 пункты ключевых требований
• ТР – пишет Разработчик, оно может быть длинным, его цель сформулировать, согласовать и зафиксировать задание и предлагаемое решение.
• Только пара из ТЗ и ТР позволяет получить взаимопонимание между Заказчиком и Разработчиком.
• Иногда можно отказаться от ТР, но надо хорошо понимать когда это можно делать и последствия