Написание подробного технического задания для 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. Не вдохновляет исполнителя
Заказчику не стоит надеяться, что ему удастся через текст ТЗ вдохновить разработчика или передать ему свое стремление получить новую ценность для бизнеса.
Не все так плохо
Риски, которые влекут описанные проблемы, можно снизить. Например, предусмотреть в контракте, что ТЗ можно менять, упростить процедуры пересогласования или разрешить реализовать ТЗ не в полном объеме, но подчеркнуть важность достижения бизнес-цели.
Работа над каждой проблемой так или иначе связана с выстраиванием партнерских отношений между заказчиком и исполнителем, а это тяжелая работа.
Ну в моём контексте качество равнозначно полноте, детализации, или как это часто звучит: плачу любые деньги, трудитесь сколько хотите, но что написал, то и должно быть сделано.
Просто нужно в штате или по договору держать одного человека, который будет понимать смысл этого процесса и контролировать его. Тогда такие глупые статьи писать не придется (я не про Вашу, про ссылку) :)
Я правильно понял, что вы избегаете критерия "достижение бизнес-результата", а ориентируетесь на формальное соблюдение всех пунктов ТЗ?
1. Уклонение. На этапе разработки ТЗ убедить Заказчика, что часть пунктов должна уйти на следующий этап создания системы. Либо вообще не нужна. Выигрыш в сроках при том же бюджете.
2. Принятие. Согласиться на все пункты. Увеличить ресурсы за свой счёт. Дополнительные затраты при сохранении сроков.
3. Разделение. В процессе реализации работ, а скорее всего в период последней трети реализации проекта принять совместно с Заказчиком решение о закрытии Договора по фактически выполненному объёму. Упущенная выгода при тех же сроках.
4. Передача. По согласованию с Заказчиком часть "нереализуемых" пунктов из ТЗ устраняются. Зато добавляются пункты, которые реализовать можно. Сохранение сроков и бюджета под ответственность Заказчика.
5. Минимизация. Отработать с Заказчиком схему увеличения срока с выплатой минимальных штрафов.
6. Передача. Обоснованно доказать, что указанные пункты ТЗ не возможно реализовать в указанные сроки. Либо возможно реализовать если Заказчик выполнит какие-то работы. Ответственность на Заказчике. Упущенная выгода при тех же сроках.
Кстати, поработайте дизайнером, к примеру - я думаю, Вы быстро поймете разницу между достижением художественного результата и заработком:)
Как вы заранее узнаете какие пункты отправить на следующий этап?
в период последней трети реализации проекта принять совместно с Заказчиком решение о закрытии Договора по фактически выполненному объёму
Я бы хотел посмотреть на исполнителя, который прошел этапы подписания ТЗ, а на последней трети будет 1) убеждать заказчика закрыть договор заранее 2) недополучить деньги. Вы на практике такое видели хоть раз?
Вы исходите из того, что сначала надо залезть в ТЗ, а потом за свой счет и, если повезет, за счет заказчика его менять. Я хочу подчеркнуть, что ТЗ нужно писать далеко не всегда и это должен быть вынужденный шаг. Работа без ТЗ предполагает меньшие потери, если уровень зрелости и культуры высокий с обеих сторон (да, знаю, что это не частое явление)
Избегаю? Нет, не вижу близкой связи между разработкой ИТ-изделия и бизнес-результатом. Или я не понял Ваш вопрос.
Я писал о качестве разработки.
Так часто и так понятно, какие пункты будут нереализуемы. Причём часто же - по вине Заказчика. Пишет Заказчик в ТЗ "интеграция с системами A, B, C", а эти системы существуют только в докладе Правительства РФ. Значит придётся эти пункты переносить либо удалять.
Вы на практике такое видели хоть раз?
Я на практике такое делал не раз. Вы что, полагает, что я это выдумал? Добро пожаловать в систему Государственных контрактов Российской Федерации. Так и называется "закрытие по факту".
Уже на объёмах в 100 млн рублей недополучение 1 млн рублей это издержки производства. А если выбор стоит "обосновать и недополучить 1 млн" или "не обосновать и штраф на 50 млн" то, поверьте, выбор весьма обоснован.
1. Я исхожу из того, что как РП в сфере Госконтракта я никуда не залезаю. Я получаю ТЗ и Договор после того, как туда уже залезли.
2. В тех случаях, когда я мог участвовать в проекте до подписания контракта и писал ТЗ, я писал его грамотно. И тогда риски п.п. 3 - 11 не возникали.
3. ТЗ это инструмент. Задач у инструмента ровно 3:
1) Описать состав работы, чтобы все знали что делать и какие потребны ресурсы.
2) Обосновать бюджет чтобы сформировать контракт.
3) Защитить стороны от самодурства.
Инструментом надо уметь пользоваться.
Я хочу подчеркнуть, что ТЗ нужно писать далеко не всегда и это должен быть вынужденный шаг.
Скорее наоборот! Вы, я так понимаю, считаете, что узкая отрасль "разработка ПО в B2C и отдельном B2B" это норма. А я исхожу из того, что это весьма не большой по объёму работ и денег рынок.
А норма это крупный B2B и B2G в системной интеграции и разработке чистого железа, норма это вся строительная отрасль. А там - только ТЗ!
Я понял, что у нас разные рынки. Мы не работаем с гос. контрактами и с нефте-газовыми компаниями. Работаем только с бизнесом, который зависит от клиентов и живет на заработанном, мне у них задачи нравятся.