Написание подробного технического задания для 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. Не вдохновляет исполнителя
Заказчику не стоит надеяться, что ему удастся через текст ТЗ вдохновить разработчика или передать ему свое стремление получить новую ценность для бизнеса.
Не все так плохо
Риски, которые влекут описанные проблемы, можно снизить. Например, предусмотреть в контракте, что ТЗ можно менять, упростить процедуры пересогласования или разрешить реализовать ТЗ не в полном объеме, но подчеркнуть важность достижения бизнес-цели.
Работа над каждой проблемой так или иначе связана с выстраиванием партнерских отношений между заказчиком и исполнителем, а это тяжелая работа.
хорошо написано, спасибо автору!
Хочу сказать, что проблема эта не только при разработке ПО. Мне можно сказать повезло в чем - когда я стал рулить своим первым филиалом в карьере менеджера, написал сам базу данных под конкретные (конкретней некуда) задачи. И в то время (а это был 1997 год) у нас отгрузки просто летали - в то время как московский филиал отгружал из Экселя. День накладную делали там. Кроме прочего, вытаскивал аналитику сначала разовыми SQL запросами для головного офиса и для нас, далее договорились с головняком , какие именно отчеты им нужны, удалось стандартизовать. Трудней всего было с самым крупным нашим розничным клиентом, у них требования к документам были наверное с Марса, даже точку выгадывал где ставить )
Но суть не в этом. Я этим рулил и я это автоматизировал, знал инструменты и знал тематику. В другом случае с отделом IT , все региональные филиалы удалось вывести онлайн по отчетам и документам. Просто не представляю, кому бы я мог поручить эту задачу, и что еще хуже - как бы я его проверял, на мне висели 6 региональных филиалов с планами продаж и всей матчастью и персоналом. С ребятами из IT было просто - обсудили, они внедрили, я на местах учил персонал, и тестировали ПО, приходилось задерживаться в командировках.
Собственно к чему я - такие проблемы не только в разработке ПО а гораздо шире. Любая работа по проекту такова. Например строительство. Дом идет к завершению, и вдруг заказчику ночью приснилось, что нужно отодвинуть стенку на 10 сантиметров - диван не влезает. И что делать тут?
Попытки формализовать любую проектную деятельность осложняются нашим менталитетом - хотелка или озарение включаются когда проект уже утвержден и в работе. И фиг кому чего докажешь. Очень сложно. Я уже не упоминаю ошибки в проекте и коде.
Видно, для проектной работы нужно прописывать форс-мажорный хвост очень хорошо. Имеющиеся в опыте сложные ситуации формализовать и разгибать погибче, другого пути не вижу.
При чём тут наш менталитет? У всех одинаково. Не существует Заказчиков, которые точно представляют результат.
А поскольку способность нести ответственность - качество личности, а не национальности, то и остальные проблемы связаны с самой сутью взаимоотношений Заказчик-Исполнитель, а не с национальностью.
Автор всё подробно рассказал. Хорошая статья. Однако 3 момента не отразил в статье. Стоило бы их указать:
1. Все указанные риски управляемы. Результат управления зависит от от многих факторов - договора, характера Заказчика, наличия административных мер воздействия на стороны, бюджета и так далее. Я бы сказал, что в первую очередь, от первую уровня руководителей проекта с обеих сторон. Но! Все управляемы!
2. Автор говорит о рисках ТЗ. Однако:
а) С ТЗ тяжело!
б) Без ТЗ невозможно!
в) А если ... а если что, см. пункты а) и б)
Такие вещи стоит обязательно в статьях писать. Не всегда статьи читают люди с должным профессиональным уровнем, но мечтатели читают часто.
3. Есть ещё и технический проект, который прекрасно позволяет целый ряд вещей проработать и скорректировать без вмешательства в ТЗ и Договор.
А ещё есть опытный образец и опытная эксплуатация. И также можно массу вещей внести без вмешательства. Грамотно ТЗ просто нужно писать, оставляя необходимый объём свободы.
Все же находятся, если вообщем умны, хорошо воспитанны и заинтересованы. А менталитет не в национальности - а в словах" я же вам плачу". И этим все сказано. Про личности и прочее заумное не хочу рассуждать,попробуйте сдать объект хотя бы один раз такому,с растопыренными пальцами ) тогда рассуждения быстренько перейдут в практическую канву. Особенно когда нужны оборотные средства и нужно платить людям. Тогда рассуждения про личность и прочее - просто рассуждения а не реальные конкретные решения - окажутся просто хренью.
Поэтому еще раз скажу как практик - нужен договор с учтенным опытом (чужим в том числе) форс-мажорным хвостом. Никакими словами дело не пойдет, если попался заказчик с непонятными хотелками. А так,будет время - порассуждаем конечно,до первого прецедента. Когда вдруг все теоретики резко исчезают и ты остаешься с проблемой один на один.
На сколько управляемы по вашему опыту? Я могу поверить в управляемость для небольших проектов длиной до месяца. Для более длительных управляемость сводится к перезакладыванию сроков и бюджетов на изменения, которые обязательно произойдут.
Если вы создаете продукты для расширения своего рынка, вступаете в конкурентную борьбу, а не просто выживаете, или занимаетесь R&D, то риски снижаются только за счет скорости поставки, сбора обратной связи, АБ-тестирования и т.д., но точно не за счет продуманного далеко наперед и подробно описанного плана. Если утрировать, то попробуйте вернуться в прошлое и написать ТЗ на Facebook, будет интересно посмотреть на управляемость рисками и план работ.
Возможно, мы так уже 6 лет работаем. Компании, которые выбиваются в лидеры на своих раныках не пишут ТЗ. Я не говорю о тех, кто вставит трубу в землю и качает нефть и не говорю о тех, кто живет на наши налоги (гос. сектор). Речь о компаниях, которые живут за счет своих клиентов.
Да, бывает, что подробный план просто необходимо написать. Я об этом писал отдельно у себя в блоге http://blog.byndyu.ru/2018/02/5.html
Написать ТЗ на продукт стадии Introduction или Growth невозможно и не нужно (https://www.slideshare.net/Askhat/ss-73627269). На стадии Maturity можно писать, можно не писать, зависит от вкусов и не особо влияет на результат.
Это напоминает "У тебя просто мужика нормального не было". Я же написал о проблемах, которые возникают при любом уровне "грамотности" бизнес-аналитика. Заодно можно задуматься, что качественные IT-продукты можно создавать без ТЗ.
Я согласен, что детальное долгосрочное планирование себя не оправдывает. Целесообразоно по деньгам и времени делать детальное планирование на пару недель, или наоборот долгосрочное планирование, но примерное.
Просто западники не повторяют эти слова так часто, как наши. По естественной причине - у них "я вам плачу" давно и само по себе подразумевается. А у нас к этому привыкнут лет через 20. Западник эти слова не произносит, он просто на вас укоризненно смотрит )))
Безусловно работать приятнее, но смысл тот же.
Вы, как мне кажется, путаете, естественный провал культуры и общей грамотности с менталитетом. Да, Заказчик платит деньги. Но российский Заказчик часто думает, что если он платит много денег, то значит он платит за всё. На самом деле много он платит только за то, что в Договоре и ТЗ. А за то, что сверх он должен платить ещё больше.
Насколько подобной модели придерживается западник не могу сказать, не достаточно знаком. Однако подозреваю, что и у них вполне достаточно подобных личностей. Это ведь просто личная инфантильность, а не менталитет.
Если бюджет резиновый?