В основе многих наших действий или бездействий лежат неразрешенные конфликты.

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

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

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

Голдрат предложил интересный механизм разрешения конфликтов, часто называемый «Грозовая туча». Суть его предложения заключается в том, что если применить системный подход и проанализировать причины возникновения конфликта, то можно будет предложить такое решение, которое полностью устранит конфликт. И оно не будет компромисным.

Многие практики Теории Ограничений утверждают, что «Грозовая туча» работает.

Давайте проверим и попробуем применить разработанный Голдратом алгоритм к нескольким типичным конфликтам из области ИТ. Посмотрим, как это может нам помочь.

Конфликт: Подрядчик не начинает разработку до тех пор, пока не составит полное ТЗ

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

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

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

Как быть? Ведь заказчик хочет начать работу прямо сейчас и готов бросить всё, если Вы не начнете, и уйти к другому исполнителю. Конечно, ему нет никакого смысла ждать пока подрядчик напишет ТЗ (если вообще напишет). Это потеря его времени и, на самом деле, упущенной выгоды.

Какое же решение принять подрядчику?

Уже сейчас, из самой формулировки конфликта очевидно, что действие «Начать работу только после составления ТЗ» вызвано отсутствием гарантии получения денег от заказчика.

Т.е. причиной действия «Начать работу только после составления ТЗ» является необходимость «Обеспечить гарантию получения денег».

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

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

Т.е. причиной действия «Начать работу прямо сейчас, без ТЗ» является необходимость «Быстрее создать продукт».

Но при этом оба, и заказчик и подрядчик хотят создать этот продукт. Т.е. у них общая цель – «Создать продукт»

Каждому пункту конфликта принято давать буквенное название: A, B, C, D, D’.

Итак, конфликт полностью сформулирован. Это так называемая диаграмма «Грозовая туча».

Проведём быструю проверку. Условие C должно конфликтовать с действием D, а условие B должно конфликтовать с действием D’. Всё верно, они конфликтуют, значит формулировка конфликта составлена правильно.

Для того, чтобы разогнать эту грозовую тучу необходимо разобраться в причинах конфликта. Пропишем причины (предпосылки), почему действия D и D’ необходимы для обеспечения условий B и C.

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

Было: «Быстрее создать продукт». Обратная формулировка: «Старт разработки бесконечно затягивается».

Было: «Обеспечить гарантию получения денег». Обратная: «Деньги за сделанную работу не высоздать это продуктплачивают»

B-D (при каких условиях старт разработки бесконечно затягивается?):

• Составление ТЗ занимает много времени

• Согласование ТЗ занимает еще больше времени – в разы больше. Это огромные простои

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

• ТЗ часто используют в качестве давления на заказчика и есть риск не получить продукт, который я хочу

• После получения денег подрядчик часто исчезает бросив продукт недоделанным. По сути, это просто выброс денег в мусор

C-D’ (причины, почему деньги за сделанную работу не выплачиваются):

• Типична ситуация, когда заказчик не знает, чего хочет и заставляет бесконечно доделывать продукт при этом не оплачивая сделанную работу до момента полного завершения проекта. А этот момент обычно сильно затягивается

• Подрядчик вынужден выплачивать зарплату разработчикам из своих средств, чтобы они доделывали продукт. Это выводит проект в минус.

• Обычно разработка сильно затягивается из-за все новых и новых требований заказчика. Он никак не может остановиться

• Объем работ должен быть ограничен, чтобы заказ окупился

Как не трудно заметить, конфликт очень серьезный. Как найти решение, которое полностью его устраняет?

Э.Голдрат говорит, что суть конфликта скрывается в деталях. Его причиной может быть либо неправильная (ложная) предпосылка, либо непонимание предпосылок, на которых основывает своё видение противоположная сторона.

Можно придумать такое решение, которое либо вскрывает неверную предпосылку, либо удовлетворяет сразу всем предпосылкам всех сторон конфликта (причем полностью, а не частично).

Давайте подумаем… За предпосылки сомневаться не приходится – это то, что в действительности часто происходит в реальности. Значит надо придумывать что-то иное.

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

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

Решение напрашивается само собой – договариваться не на огромный проект, а на небольшие куски/итерации, которые быстро делаются и быстро оплачиваются.

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

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

Давайте посмотрим, что случится с предпосылками конфликта, если применить найденное решение.

Опасение заказчика

- Составление ТЗ занимает много времени

На короткую итерацию ТЗ составить быстро, а то и вовсе можно обойтись без него заменив макетами экранов.

- Согласование ТЗ занимает еще больше времени – в разы больше. Это огромные простои

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

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

Реализация небольшими партиями позволит менять продукт не в самом конце (как обычно делают), а в начале и по ходу разработки. В результате в самом конце доработок либо вообще нет, либо они минимальны.

- ТЗ часто используют в качестве давления на заказчика и есть риск не получить продукт, который я хочу

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

- После получения денег подрядчик часто исчезает, бросив продукт недоделанным. По сути, это просто выброс денег в мусор

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

Бонус для заказчика – теперь можно смело нанимать разработчиков давая им небольшой объем работ для проверки и рискуя только небольшой суммой.

Опасения подрядчика

- Типична ситуация, когда заказчик не знает, чего хочет и заставляет бесконечно доделывать продукт, при этом не оплачивая сделанную работу до момента полного завершения проекта. А этот момент обычно сильно затягивается

При небольшом объеме разработки заказчик совершенно точно определиться с тем, что он хочет видеть в очередной итерации. Он будет вынужден. Ему это очень просто будет сделать, т.к. объем небольшой.

- Подрядчик вынужден оплачивать зарплату разработчикам, чтобы они доделывали продукт. Это выводит проект в минус.

При оплате за небольшие итерации деньги будут на счете подрядчика не дожидаясь полного завершения проекта. Это в разы выгоднее.

- Обычно разработка сильно затягивается из-за все новых и новых требований заказчика. Он никак не может остановиться

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

- Объем работ должен быть ограничен, чтобы заказ окупился

Он однозначно ограничен.

Да! Решение полностью исключает все опасения!  Грозовая туча работает!

Внесём дополнительные осложнения для подрядчика

Представим, что подрядчик заключил договор с большой компанией, в условиях которой прописана полная оплата после полной реализации и приемки проекта. Деньги большие, поэтому подрядчик взялся за проект.

Для больших компаний (особенно с госучастием) зачастую неприемлемы условия договоров без конечного фактического результата, требуемого бюджетом/вышестоящими органами.

Как закрыть опасения? Как сделать так, чтобы оплата осуществлялась по небольшим итерациям в проекте, котором УЖЕ чётко прописано, что оплата только в конце?

Давайте составим грозовую тучу и посмотрим на неё внимательно.

Причиной возникновения конфликта часто становятся неверные (ложные) предпосылки. Для их определения Голдрат в своих выступлениях (можно найти на Youtube) рекомендует задавать предельно простой вопрос: «Really?!»  («Да ну?!»)

Действительно ли внутреннему аудиту большой компании нужно показывать работающий продукт? Точно?! Вы действительно уверены, что нужно доводить готовый продукт до приёмо-сдаточных испытаний? Вы уверены?!

По умолчанию – да, но что, если пойти и объяснить сотрудникам внутреннего аудита чем хорош подход с короткими итерациями?

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

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

Конечно, есть шанс, что ничего не случится, но тогда ситуация не будет отличаться от текущей и подрядчик ничего не теряет. Ну а что, если внутренний аудит пойдет навстречу?..

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

Переход разработки на короткие итерации действительно помогает. Помогает и заказчикам и подрядчикам. К сожалению, далеко не всегда им пользуются. И даже там, где уже вовсю работает Scrum (разработка короткими итерациями) внутри компании, для работы с внешними подрядчиками часто применяют стандартные контракты водопадной разработки.

Но это отдельная история.

Целью статьи было рассказать Вам о том, что с помощью Грозовой тучи можно найти очень интересные, часто прорывные решения. 

Вероятно, изложенный в статье способ применения диаграммы «Грозовая туча» покажется Вам полезным. Было бы очень интересно увидеть Ваши примеры её использования.

На Ваши комментарии автор с удовольствием ответит и примет к сведению Ваши замечания.

P.S. История, рассказанная одним из рецензентов после прочтения статьи.

«Просишь пример? Пожалуйста.

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

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

При разговоре стало понятно, что одним специалистом-универсалом там явно не обойтись, нужно было как минимум три разных специалиста. Помню его унылую физиономию и вздох: «Да, видно придется сдаваться».

Тогда я предложил ему следующую форму договора: он платит за работу двух специалистов в течение трех месяцев, мы поставляем именно тех специалистов, которые нужны в данный период разработки. План работ на первое время очевиден, к концу трехмесячного срока будет готов план на следующий период или даже несколько (планирование методом набегающей волны).

Такой вариант заказчика устроил, т.к. он мог контролировать объем и нужность работ, а также видеть справедливость траты его денег. В таком режиме он продолжает работать уже несколько лет»