12 рисков в разработке ПО по техническому заданию

Написание подробного технического задания для IT-проекта воспринимается как стандарт. Все пишут ТЗ, стараясь снизить риски и упростить разработку. Но с работой по ТЗ связан ряд проблем, которые стоит учитывать.

1. Исполнитель строго следует ТЗ

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

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

В идеальном мире они должны стремиться к достижению бизнес-цели. Но после появления ТЗ они стремятся выполнить его в полном объеме. К первоначальному движению в сторону бизнес-ценности добавляется желание поставить галочку напротив каждого пункта. Обратите внимание на мотивацию каждой из сторон – и вы увидите, что ТЗ занимает в проекте центральное место и со временем подменяет цель проекта.

2. Заказчик строго следует ТЗ

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

3. ТЗ создает иллюзию определенности и контроля

Подписанное ТЗ гарантирует, что исполнитель пообещал определенный результат, но жизнь не гарантирует, что все произойдет по плану. Согласованное ТЗ воспринимается как стопроцентно определенное будущее, все планы строятся под него. Но статистика подсказывает, что в большинстве случаев сроки и бюджет проекта будут превышены, а разработанное ПО получится недостаточно высокого качества. По данным CHAOS Report, в 2015 году только 29% проектов завершились в срок без превышения бюджета и с полным набором функций.

ТЗ действительно фиксирует вершины проектного треугольника, но эта фиксация создает лишь иллюзию предсказуемости и контроля. История знает случай внедрения системы SAP у одного российского ритейла. У «саперов» ушел год на составление ТЗ. Еще год – на настройку и программирование SAP. В итоге заказчик остался недоволен, потому что система работала медленно и частично ошибочно, «саперы» недостаточно разобрались в бизнесе. И еще три года ушло на борьбу, дописывание, исправление.

4. ТЗ не дает ответа на все вопросы

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

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

5. Авторы ТЗ недоступны

Аналитики и архитекторы – обычно штучные люди. В компаниях их делят на много параллельных проектов. Если они собрали требования, описали задачу и отдали ее в работу, то скорее всего сразу же пошли делать другие проекты. Если у разработчиков возникнут вопросы, то скорее всего ответ придется им искать в тексте ТЗ: спросить будет не у кого.

6. ТЗ можно составить только под простые задачи

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

Получается, что подробное ТЗ можно написать только для очень конкретных и относительно простых задач, которые находятся в правом секторе Cynefin Framework. Но бизнес редко ставит такие простые и конкретные задачи. Если работать над функциями, которые двигают бизнес вперед, то это верхний левый квадрат Complex, а для него ТЗ уже не напишешь.

7. ТЗ можно совершенствовать бесконечно

Написание ТЗ стоит денег, которые хочется сэкономить. При этом мы балансируем между двумя крайностями: переплатить временем и деньгами за чрезмерно подробное описание задач или описать задание недостаточно подробно, что приведет к серьезным рискам и ошибкам. Только эксперт сможет найти золотую середину, а таких экспертов мало. Среднестатистический IT-аналитик имеет все шансы ошибиться.

8. ТЗ не фиксирует качество

Я, как разработчик и IT-архитектор, прекрасно понимаю, что любую задачу, как бы подробно она ни была описана, можно выполнить сотней разных способов. Одни способы будут качественными и дорогими, другие быстрыми и «костыльными». Другими словами, при написании кода ужасного качества, можно формально выполнить требования ТЗ. Есть способы достигнуть высокого качества IT-продукта, но точно не с помощью ТЗ.

9. ТЗ работает по принципу «все или ничего»

К сожалению, нельзя согласовать ТЗ наполовину или договориться сделать самые важные пункты из согласованных. Если ТЗ подписано и выделен бюджет, то вам придется сделать все, что в нем указано. Его «монолитность» не поддается дроблению по принципу Парето 20/80, что приводит к неэффективной работе.

10. Невозможно доказать непротиворечивость

Если в вашем ТЗ больше сотни страниц, то в этом задании, наверняка, есть противоречия. И обратного никто не докажет. Фактически вы всегда подписываете ТЗ с противоречиями.

11. Невозможно доказать полноту

Как в предыдущем пункте, невозможно доказать, что в ТЗ описаны все сценарии, взаимосвязи, точки интеграции и т. п. Достигнуть 100-процентного покрытия задач можно, если имеешь бесконечный бюджет. В других случаях ваше ТЗ не будет полным.

12. Не вдохновляет исполнителя

Заказчику не стоит надеяться, что ему удастся через текст ТЗ вдохновить разработчика или передать ему свое стремление получить новую ценность для бизнеса.

Не все так плохо

Риски, которые влекут описанные проблемы, можно снизить. Например, предусмотреть в контракте, что ТЗ можно менять, упростить процедуры пересогласования или разрешить реализовать ТЗ не в полном объеме, но подчеркнуть важность достижения бизнес-цели.

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

Расскажите коллегам:
Комментарии
Руководитель проекта, Москва
Александр Бындю пишет:
Платон Миронов пишет:
Грамотно ТЗ просто нужно писать, оставляя необходимый объём свободы
Это напоминает "У тебя просто мужика нормального не было". Я же написал о проблемах, которые возникают при любом уровне "грамотности" бизнес-аналитика. Заодно можно задуматься, что качественные IT-продукты можно создавать без ТЗ.

Оцените, сколько вокруг вас Технических писателей, которые написали ТЗ по ГОСТ 34 на полноценную ИС корпоративного уровня хотя бы в количестве более 10 штук. И вы сами ответите на своё высказывание про "мужиков".

Зайдите в любое нормальное КБ советского типа и пообщайтесь с главспецами возраста за 50 лет. Уверен, вы много интересного узнаете о ТЗ в 200 - 400 листов по которым летают самолёты и ракеты.

Проблема всех ТЗ в столкновении тех, кто хочет жёстко там всё закрепить и тех, кто хочет составить ТЗ на 1 лист. К сожалению в подобных коллективах редко находятся те, кто выдержит середину и отстоит грамотное ТЗ.

"ИТ-продукты" и ИТ-системы это очень разные вещи. Продукты создавать можно. А дальше уже весьма сомнительно.

Аналитик, Москва
Александр Бындю пишет:
Анатолий Курочкин пишет:
без ТЗ серьёзную разработку не сделаешь.
Анатолий, а какую разработку вы считаете серьезной? Мы все проекты делаем без ТЗ и делаем успешно. Вот часть описана https://byndyusoft.com/casestudies

Я ожидал Ваш вопрос. Твёрдых критериев нет, руководитель разработки сам может принять решение о "серьёзности". Но большинство коробочных продуктов могут и без ТЗ, по крайней мере до тех пор, пока существует команда, преемственность. Если есть заказчик со сложной структурой, со сложными производственными отношениями (только не спрашивайие, что такое "сложные производственные отношения"), то без ТЗ не обойтись. Есть ведь и судебные риски. Если же вы создаёте продут, которые планируете вывести на рынок, то необходимость ТЗ под вопросом. Но здесь начинается философия: ТЗ может и не быть одним структурированным документом. Но как будет ставить задачу программистам наёмный менеджер без ТЗ я не представляю.
Есть заказчик - есть ТЗ.
В небольших разработках(например, написать интернет-магазин, я обходился без ТЗ, а всего лишь фиксировал основные требования на 1-2 страничках. И затем подгонялось под конкретные требования по ходу эксплуатации.
Добавлю, что к гибким технологиями разработки следовало бы относится взвешенно: в них есть и достоинства, и свои недостатки.
Важны цели написания ТЗ, есть ведь ТЗ, кторые предназначены для публикования тендерной документации. Оно имеет малое отношение к "техническому" ТЗ.

Аналитик, Москва
Платон Миронов пишет:
Александр Бындю пишет:
Платон Миронов пишет:
Грамотно ТЗ просто нужно писать, оставляя необходимый объём свободы
Это напоминает "У тебя просто мужика нормального не было". Я же написал о проблемах, которые возникают при любом уровне "грамотности" бизнес-аналитика. Заодно можно задуматься, что качественные IT-продукты можно создавать без ТЗ.
Оцените, сколько вокруг вас Технических писателей, которые написали ТЗ по ГОСТ 34 на полноценную ИС корпоративного уровня хотя бы в количестве более 10 штук. И вы сами ответите на своё высказывание про "мужиков".
Зайдите в любое нормальное КБ советского типа и пообщайтесь с главспецами возраста за 50 лет. Уверен, вы много интересного узнаете о ТЗ в 200 - 400 листов по которым летают самолёты и ракеты.
Проблема всех ТЗ в столкновении тех, кто хочет жёстко там всё закрепить и тех, кто хочет составить ТЗ на 1 лист. К сожалению в подобных коллективах редко находятся те, кто выдержит середину и отстоит грамотное ТЗ.

"ИТ-продукты" и ИТ-системы это очень разные вещи. Продукты создавать можно. А дальше уже весьма сомнительно.

Я как раз такой "за 50". Подтверждаю Ваши слова про 200-400 страниц.
Объём резко вырастает, если появляются, а они появляются обязательно, соисполнители, контрагенты. А если это составная часть ОКР?

Как правило, ТЗ с течением разработки меняется, уточняется. Бывает, что часть требований убирается.
Огромная разница - это серийная разработка или опытный образец и т.д.

Генеральный директор, Челябинск
Анатолий Курочкин пишет:
Есть заказчик - есть ТЗ.

Как вы правильно заметили, выбор писать ТЗ или нет зависит от структуры отношений, приемственности и т.д. Я не тешу себя иллюзиями, что ТЗ не нужно в 100% случаев, прекрасно понимаю, что иногда отношения Заказчик-Исполнитель требуют формализации.

Консультант по корп. финансам
Александр Бындю пишет:
Вы ссылку посмотрели? Не сколько успеем, а достаточно для достижения результата. Scope всегда можно порезать.
Клиенты готовы платить по факту, вопрос в переговорах. Хотя, возможно, на вашем рынке это еще не является обычной практикой. Тогда трудно представить сколько сил уйдет на изменение культуры :)

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

Аналитик, Москва
Александр Бындю пишет:
Анатолий Курочкин пишет:
Есть заказчик - есть ТЗ.
Как вы правильно заметили, выбор писать ТЗ или нет зависит от структуры отношений, приемственности и т.д. Я не тешу себя иллюзиями, что ТЗ не нужно в 100% случаев, прекрасно понимаю, что иногда отношения Заказчик-Исполнитель требуют формализации.

Не в дискуссию, просто вспомнилось про "эффект Тыугу" - по фамилии эстонского программиста, когда в начале разработки ни разработчик, ни заказчик не имеют никакого понятия о будущем изделии. ))
А в серьёзном плане сошлюсь на свой опыт: в разных отраслях деятельности существуют свои, какие-то негласные традиции написания ТЗ или, лучше сказать, постановки задачи. У банков своя традиция (там коллегиальные решения), у производственников - своя. Торговля, FMCG - своя. У окловоенных, государственных далеко не всегда точный ГОСТ, а нечто более или формальное, или гибкое.
Замечу, что коллеги снова правы: главное цель написания ТЗ - или сроки, или стоимость, или качество. Нынче очень часто заказчик может небрежно подписать любое ТЗ, потом может формально принять изделие, но к каким-то ключевым требованиям будет жесток.


Генеральный директор, Челябинск
Андрей Панахов пишет:
Вы позволили бы своим сотрудникам платить по факту незнакомой организации без технического задания за разработку ERP-системы?

Зависит от того, как был бы построен процесс. Если бы и исполнитель и мои сотрудники работали через бизнес-цели с постоянной поставкой релизов (минимум раз в неделю) и прозрачной коммуникацией, то разрешил бы.

Консультант по корп. финансам
Александр Бындю пишет:
Зависит от того, как был бы построен процесс. Если бы и исполнитель и мои сотрудники работали через бизнес-цели с постоянной поставкой релизов (минимум раз в неделю) и прозрачной коммуникацией, то разрешил бы.

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

Генеральный директор, Челябинск
Анатолий Курочкин пишет:
главное цель написания ТЗ - или сроки, или стоимость, или качество

Я писал именно о разработке ПО. Можете поделиться, как в ТЗ описать качество ПО, причем так, чтобы можно было формально проверить исполнителя на соответствие результата? Вы же понимаете, что разработчики могут подогнать программу под любые критерии функциональных и нефункциональных требований, а потом окажется, что код состоит из одних технических долгов и костылей.

Генеральный директор, Челябинск
Андрей Панахов пишет:
на объемных многофункциональных проектах так почти никогда не бывает

Я с вами согласен. Немного оффтоп о том как бывает Не купитесь на ERP! http://tenderbot.pro/pravda_o_erp :)

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

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

70% россиян отмечают сильное влияние работы на уровень стресса

Наибольший стресс создают строгие дедлайны, внезапные и большие объемы задач, а также собственные ошибки при выполнении задач.