Антихрупкость в IT - Александр Васильевич Бындю Страница 12

Почему из всех вариантов решения этой задачи часто выбирают написание подробного плана действий в форме технического задания? Ведь совершенно необязательно иметь стопроцентный контроль над проектом на следующие два года. Более того, иногда Big Design Up Front приносит вред и убытки. Гонщик Mario Andretti говорил об этом так: «Если вы контролируете всё, значит, едете недостаточно быстро»[35].

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

1. Снизить риски, уменьшить неопределённость

Перед началом проекта и заказчик, и исполнитель будут рады узнать список задач, бюджет и дату релиза. Когда все три составляющие известны и неизменны, тогда проще планировать работу (рис. 26).

Рис. 26. Все три точки проектного треугольника зафиксированы

Если не зафиксировать хотя бы одну из вершин проектного треугольника[36], это породит неопределённость. Мы избегаем неопределённости всеми силами, потому что она поглощает энергию и создаёт стресс.

Чтобы уменьшить неопределённость, надо предсказать будущее, построить план и двигаться согласно плану. Как сказал Джокер в фильме «Тёмный рыцарь»: «Люди охотно соглашаются действовать согласно плану, каким бы он ни был, даже если план ужасен».

С этой точки зрения, идеальный уменьшитель неопределённости – техническое задание, фиксирующее все вершины треугольника.

2. Задача «бездумному» исполнителю

Если вы взяли проект на субподряд или отдадите его на субподряд, то всем проще работать со списком задач, который передаётся по цепочке. Чем подробней формализовано задание, тем проще отчитаться о выполнении. Чем подробнее описаны требования, тем меньше возникнет вопросов у всех участников бездумной цепочки.

3. ТЗ требуется согласно регламентам

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

4. Нет доверия с одной из сторон

Если заказчик не доверяет исполнителю или исполнитель не доверяет заказчику, то у них возникает естественное желание защититься друг от друга через подробное описание задачи.

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

5. Прокси-менеджер

Прокси-менеджер создаёт преграды в коммуникации. Это такой человек, который пересылает письма от заказчика к исполнителю и обратно, не даёт общаться напрямую, мотивируя свою ценность занятостью людей за его плечами. Он паразит в цепочке коммуникации, передатчик информации с дефектом искажения.

Если в ваших коммуникациях невозможно убрать прокси-менеджера, то для всех будет проще написать подробное ТЗ.

Как быть, если ни одна причина не подошла?

Надо ли вам вкладывать деньги и время в создание подробного ТЗ – вопрос непростой. Приведу пример из своей практики. В нашей компании[37] ТЗ создаются только в том случае, если у заказчика есть корпоративное правило, запрещающее начинать проект без формального ТЗ. Мы делаем его в рамках аналитики IT-продукта (раздел I, глава 4). Итоговый документ состоит из Impact Mapping, Customer Journey, User Story Mapping и схем с архитектурой.

Если до начала проекта ТЗ можно не писать, то формальный документ не создаётся, а все активности по аналитике IT-продукта входят в процесс создания этого продукта (раздел l, глава 6).

Глава 7. Двенадцать проблем при работе по техническому заданию

Проблемы, которые превращают написание ТЗ в потери для бизнеса

Техническое задание и хрупкость

Я не фанат подробных технических заданий, потому что ТЗ пытается законсервировать случайность. В мире, где всё очень быстро меняется, опасно полагать, что ТЗ снижает риски. Я прекрасно понимаю, что если ваша система хрупкая (раздел ll, глава 6), то вы обязаны предсказывать события куда лучше среднего и точно знать, куда вы идёте, просто для того, чтобы не остаться в убытке. В этом случае вместо ТЗ было бы лучше задуматься о том, как сделать систему антихрупкой. Но если написание ТЗ необходимо, то ниже я описываю то, на что стоит обратить внимание.

1. Исполнитель делает выбор в пользу ТЗ

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

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

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

Кстати, задайте себе вопрос о бюджете: сколько исполнителей предложат подрезать бюджет, если увидят более оптимальное решение? Вопрос риторический.

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

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

2. Заказчик делает выбор в пользу ТЗ

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

Такие люди рискуют превысить бюджет или срок, согласованный в плане проекта. Но если они сделали всё согласно ТЗ, который согласовывали их начальники, тогда с них нечего спрашивать.

Рис. 27. Отношение заказчика, исполнителя, ТЗ и бизнес-ценности

3. ТЗ создаёт лишь иллюзию предсказуемости и контроля

Подписанное ТЗ гарантирует, что исполнитель пообещал определённый результат, но жизнь не гарантирует, что всё произойдёт согласно плану.