Написание подробного Технического задания для IT-проекта вошло в привычку и воспринимимается как стандарт. Все пишут ТЗ, стараясь снизить риски и упростить работу. Но с работой по ТЗ связан ряд проблем, которые стоит учитывать, чтобы снизить риски в проекте. Об этих проблемах ниже.
1. Исполнитель делает выбор в пользу ТЗ
Порядочный Исполнитель стремиться достигнуть бизнес-цель для Заказчика. В то же время у Исполнителя есть подписанное ТЗ, реализация которого гарантирует получение денег за работу.
Представьте ситуацию, когда в очередном пункте ТЗ находится противоречие с бизнес-целью. Что если к середине проекта оказалось, что можно сделать проще, лучше, быстрее, но не по ТЗ? Исполнитель скорее всего закроет глаза на эффективность и просто сделает задачу так, как она описана и согласована.
Исполнитель мог бы пойти к Заказчику, чтобы обосновать бесполезность и вредность ошибочного пункта в ТЗ, внести правки в ТЗ, согласовать правки, согласовать изменение бюджета. Но согласитесь, проще всего этого не делать, смириться с понижением качества результата и просто сделать как написано.
Кстати, задайте себе вопрос о бюджете: сколько Исполнителей захотят пересогласовывать уменьшение бюджета, если увидят более оптимальное решение проблемы Заказчика? Вопрос риторический.
Посмотрите как взаимодействуют между собой Заказчик и Исполнитель. В идеальном мире они должны стремиться к достижению бизнес-цели. Но при появлении ТЗ Заказчик и Исполнитель стремятся реализовать ТЗ в полном объёме. К первоначальному движению в сторону Бизнес-ценности добавляется желание «проставить все галочки» в ТЗ.
Обратите внимание на мотивацию каждой из сторон и вы увидите, что ТЗ теперь занимает центральную роль в проекте. ТЗ со временем подменяет цель проекта.
2. Заказчик делает выбор в пользу ТЗ
Парадоксально, но Заказчику тоже проще закрыть глаза на эффективность решения бизнес-задачи и сделать как написано в ТЗ. Это происходит, когда Заказчиком выступает тот, кто не рискует деньгами, например, руководитель подразделения или линейный менеджер, которому поручили вести проект.
Такие люди рискуют превысить бюджет или срок, согласованный в плане проекта. Но если они сделали всё согласно ТЗ, который согласовывали их начальники, тогда с них нечего спрашивать.
3. ТЗ создает лишь иллюзию полной определенности и контроля
Подписанное ТЗ гарантирует, что исполнитель пообещал определенный результат, но жизнь не гарантирует, что всё произойдет согласно плану.
Проблема в том, что подписанное ТЗ воспринимается как 100% определенное будущее. Относительно него строятся планы. Но статистика подсказывает, что срок и бюджет проекта будут превышены, а ПО получится не достаточно высокого качества.
ТЗ действительно фиксирует вершины проектного треугольника, но эта фиксация создает лишь иллюзию предсказуемости и контроля.
История знает случай внедрения SAP у одного российского ритейла. У «саперов» ушел год на составление ТЗ. Еще год на настройку и программирование SAP. В итоге, бизнес остался недоволен, потому что система работала медленно и частично ошибочно, «саперы» не достаточно разобрались в бизнесе. Ещё три года ушло на дописывание, исправление и борьбу. Подробнее о ТЗ при внедрениях в статье Не купитесь на ERP!
4. ТЗ — молчаливый источник ответов
Вопросы быстрее и качественнее решаются во время живого общения. Планирования, стендапы, демо, работа в парах, вовлечение клиентов в тестирование, сбор обратной связи на ранних этапах и постоянная корректировка планов — это всё необходимо для достижения качества.
Когда написано подробное ТЗ, появляется соблазн отправлять читать ТЗ, а не отвечать на дополнительные вопросы. Тогда ТЗ заменяет здоровую коммуникацию на проекте.
Проблема в том, что ТЗ никогда не будет всеобъемлющим. Аналитик мог что-то упустить, архитектор подразумевал, но не дорисовал. Вопросы ТЗ не задашь, поэтому пойдешь додумывать ответ сам.
5. Авторы ТЗ недоступны во время проекта
Аналитики и архитекторы обычно штучные люди в компаниях. Их делят на много параллельных проектов. Если они собрали требования, описали задачу и отдали ее в работу, то скорее всего сразу же пошли делать другие проекты.
Если у Исполнителей возникнут вопросы, то скорее всего ответ придется искать в тексте ТЗ, потому что спросить будет не у кого.
6. Описывает только простые задачи
Бывает так, что наиболее рискованные и неопределенные задачи нельзя изучить и описать заранее. Они больше похоже на R&D, чем на реализацию функций. Здесь прямая аналогия с клиническими исследованиями, весь процесс и результат которых невозможно описать заранее, а можно только построить гипотезы и придумать методику.
Получается, что подробное ТЗ можно написать только для очень конкретных и относительно простых задач. Эти задачи находятся в правом секторе Cynefin framework. Проблема в том, что бизнес редко ставит такие простые и конкретные задачи. Если работать над функциями, которые двигают бизнес вперед, то это верхний левый квадрат Complex, а на него ТЗ уже не напишешь.
7. Когда пора прекратить писать Техническое задание?
Написание ТЗ стоит денег, которые хочется сэкономить. При этом мы балансируем между двумя крайностями:
- Переплатить временем и деньгами за чрезмерно подробное описание задач.
- Описать задание недостаточно подробно, что придет к серьезным рискам и ошибкам.
Только эксперт сможет найти золотую середину, а таких экспертов мало. Среднестатистический IT-аналитик имеет все шансы ошибиться. См. подробности в статье Когда пора прекратить писать Техническое задание?.
8. ТЗ не фиксирует «качество»
Я, как разработчик и IT-архитектор, прекрасно понимаю, что любую задачу, как бы подробно она ни была описана, можно сделать сотней разных способов. Одни способы будут качественными и дорогими, другие быстрыми и «костыльными». Другими словами, при написании кода ужасного качества, можно формально выполнить требования ТЗ.
Есть способы достигнуть высокого качества IT-продукта, но точно не с помощью ТЗ.
Если вы подозреваете, что ваш проект идет как-то не так, узнайте как заранее определить провал IT-проекта, сэкономите деньги и время.
9. ТЗ работает по принципу «всё или ничего»
К сожалению, нельзя согласовать ТЗ наполовину или договориться сделать самые важные пункты из согласованных в работу. Если ТЗ подписано и выделен бюджет, то вам придется сделать всё, что в нем написано. Его «монолитность» не поддается анализу Парето, что приведет к неэффективной работе.
10. Невозможно доказать непротиворечивость
Если в вашем ТЗ больше сотни страниц, то в этом ТЗ есть противоречия. Интересно, что обратного никто не докажет. Может пообещать, что всё проверил, но доказать или написать тест на непротиворечивоть не сможет. Фактически, вы всегда подписываете ТЗ с противоречиями.
11. Невозможно доказать полноту
Как в предыдущем пункте, невозможно доказать, что в ТЗ описаны все сценарии, взаимосвязи, точки интеграции и т.п. Достигнуть 100% покрытия задач можно только за бесконечный бюджет, в других случаях ваше ТЗ не будет полным.
12. Не вдохновляет
Не стоит надеяться вдохновить Исполнителя через текст ТЗ или пытаться передать ему стремление достигнуть ценность для бизнеса.
Не всё так плохо
Риски, которые влекут описанные проблемы, можно снизить. Например, предусмотреть в контракте, что ТЗ можно менять, упростить процедуры пересогласования или разрешить реализовать ТЗ не в полном объеме, но подчеркнуть важность достижения бизнес-цели.
Работа над каждой проблемой так или иначе связана с выстраиванием партнерских отношений между заказчиком и исполнителем, а это тяжелая работа.
Оригинал статьи опубликован на https://www.e-xecutive.ru/management/itforbusiness/1988062-12-riskov-v-razrabotke-po-po-tehnicheskomu-zadaniu
Эта статья входит в цикл статей о техническом задании:
- Когда надо прекратить писать Техническое задание и начать делать проект? Дана схема как балансировать между чрезмерно подробным, а значит дорогим, ТЗ и слишком абстрактным, что ведет к рискам и ошибкам.
- 5 причин написать ТЗ, где перечислены причины, которые подталкивают подробно описывать весь план работ до начала проекта.
- 12 проблем при работе по техническому заданию в IT-продукте. Описаны проблемы, которые превращают написание ТЗ в потери для бизнеса.
- Откровенное общение с заказчиком, где решился спор о том, на сколько подробным должно быть ТЗ.
- Техническое задание как база знаний о проекте, где описано, что написание ТЗ — это потери для бизнеса.
- Как и какое техническое задание писать при работе по Agile, где описывается, как использовать подходящие инструменты планирования, прекратить фиксировать объем работ надолго в будущее и строить коммуникацию вокруг бизнес-целей.
Комментариев нет:
Отправить комментарий