Почему компромиссы не решают проблему
Я не из мира 1С. Но, как и те, кто занимается заказной автоматизацией, я работала с очень разными компаниями из очень разных сфер. Мы, конечно, все с вами уникальные снежинки, но тем не менее у нас очень много общего. И это хорошо, потому что если бы не было очень много общего, то, наверное, стандартизация бы не работала.
Я эксперт, практик и фанат теории ограничений. И нет, ТОС — это не только про бутылочные горлышки.
Теория ограничений — это не только управленческий подход про ускорение потока. Для меня это ещё и способ мышления: как приближать наше представление о реальности к тому, как она устроена на самом деле.
Огромную часть теории ограничений занимает история про конфликты. В теории ограничений считается, что любую проблему всегда можно представить в виде конфликта. Это не обязательно конфликт между мной и тобой, но это всегда конфликт, всегда противоречие.
В проектах автоматизации регулярно случаются конфликты. Клиенты хотят, чтобы ничего не менялось. Бизнес хочет, чтобы тем не менее все было по-новому. Разработчики хотят адекватных оценок. И так далее.И очень часто в противоречиях мы приходим к компромиссам. Эта статья о том, что компромиссы – это самый распространенный способ решать конфликты и при этом один из худших.
Вы можете вспомнить ситуацию, когда вы гордились придуманным компромиссом? Прямо такие: «Классно придумали». А есть ли те, кто был бы готов эти компромиссы повторить? Вот эти все истории: «Да на рефакторинге разберемся», «допниками закроем», «они привыкнут».
Я надеюсь, что после этой статьи вы по крайней мере унесете мысль, которая вас не будет покидать: пересмотреть свои отношения и, может быть, попробовать какие-то конфликты и какие-то компромиссы увидеть с другой стороны.Давайте договоримся об определениях. В этой статье я буду называть компромиссом ситуацию, где стороны примерно поровну делят потери: «ни тебе ни мне». А консенсусом — решение, где удаётся защитить важные потребности обеих сторон.
И то, и другое может выглядеть как способ договориться. Но компромисс часто не решает проблему, а только делает её менее заметной на какое-то время.
Знаете, как выглядит наблюдение за компаниями или за людьми, которые из раза в раз вписываются в одни и те же компромиссы? Вот так:
Вот так выглядит наблюдение за из раза в раз повторяющимися компромиссами, когда мы каждый раз надеемся: «В этот раз все будет по-другому». Конечно, нет.
Пора бы встретиться с реальностью. Этим мы и попробуем заняться.
Три типичных конфликта автоматизатора
Мы рассмотрим три всем знакомых конфликта. Посмотрим, где там компромисс и где там мог бы быть консенсус.
Конфликт первый: заказчик не понимает
Первый пример конфликта – заказчик не понимает. Понятная история про оценки.
Мы говорим: «Это нельзя сделать дешевле». Он говорит: «Нет, это очень дорого, давайте урезать подстраховку». И чем мы занимаемся? Мы спорим вокруг оценки.
Мы хотим заложить в оценку подстраховку, потому что знаем: все пойдет не так. Он хочет эту подстраховку максимально сократить.
Мы-то, понятно, нормальные ребята. Мы хотим это сделать, потому что хотим гарантированно заработать на качественном функционале. Мы хотим укладываться в сроки, чтобы это было сделано качественно, и так далее.
Он, очевидно, просто жадный. Но вообще-то нет. Автоматизацией зачастую мы занимаемся не просто так. Мы хотим получить какой-то результат, потратить на это меньше, чем заработаем. У заказчика тоже есть вполне социально одобряемая потребность, помимо того чтобы просто быть жадным и упертым.
Почему нам важно договориться? Почему нам нужно и вообще возможно договориться? Потому что у нас есть общая цель. Автоматизация зачастую никогда не заканчивается на первой автоматизации. Мы хотим с ним долго работать. Мы хотим, чтобы и он был доволен взаимодействием, и мы были довольны взаимодействием. Чтобы мы продолжали на этом зарабатывать, а он понимал, зачем он это делает.
Что мы обычно делаем? Мы говорим: «Давайте сократим оценку на 20%». Почему на 20%? Почему-то на 20%.
Конфликт второй: разработчик не читает
Другой конфликт, знакомый, думаю, многим – разработчик не читает требования.
Мы писали требования. Почему? Потому что все важно. Он не читает. Почему? Потому что там 200 страниц воды.
Как это выглядит? Как обычно. Мы говорим: «Надо читать требования». Почему? Потому что надо делать так, как написано в требованиях. А он почему-то не хочет делать так, как написано в требованиях.
Но мы-то понимаем, зачем от него этого просим. Мы не просто так их писали. Мы эти требования защитили перед заказчиком. Он по этим требованиям потом будет принимать. А этот сопротивляется. Почему? Очевидно, потому что он ленивый и зазнался. Почему еще это можно не читать?
На самом деле почему? Потому что он говорит: «Написано так. Я буду долго разбираться, и вообще все не так. Надо делать по-другому. Не потому, что я ленивый и зазнайка, а потому что вообще-то я тоже должен сделать рабочий функционал». Должен же. Иначе вы бы не зарабатывали, если бы он правда был ленивый и зазнайка.
Почему нам надо и то, и то? Потому что нам нужно не просто, чтобы решение соответствовало требованиям, а чтобы оно еще и работало. Нужно нам и то, и то.
Как мы обычно решаем эту проблему? Дисциплина.
В зависимости от управленческой культуры мы можем придумывать чек-листы, штрафы, обязательные поля в 1С: надо подтвердить, что требования прочитаны, и ответить на пять вопросов по пониманию.
Мы решаем это за счет дисциплины. Типа: «Давайте зажмем их посильнее».
Конфликт третий: пользователь не хочет
Третий вариант – противоречие, знакомое многим: пользователь не хочет.
Мы говорим: «Мы хотим внедрить новую версию, потому что старая уже вся полна багов, не соответствует ничему, там все мутно» – и так далее.
Почему пользователь защищает старую версию? Почему мы хотим это сделать? Мы хотим новый функционал, хотим стабильность, хотим, чтобы все соответствовало законодательству, чтобы это можно было поддерживать.
А он почему не хочет? Конечно же, потому что он такой негодяй: делает что-то очень неправильное, боится прозрачности. Вот нам сразу станет ясно, что он делает, а он защищает свой мутный техпроцесс, который на самом деле ни фига не правильный.
Но вообще-то нет.
Опять же, такое бывает. Но если все такие, откуда деньги? Наверное, он делает что-то в том числе хорошее. И вообще-то у него есть другая потребность, помимо того чтобы прятаться от ваших пристальных взоров: делать свою работу.
И вам надо делать свою работу, и ему надо делать свою работу.
Почему нам и то, и то надо? Мы все хотим обеспечить стабильность и управляемость.
Как обычно мы решаем это противоречие? Эскалацией, давлением.
Давайте скажем начальству, что он не слушается. Давайте закрутим гайки. Мы сделаем, они потом привыкнут.
И в чем история? Эти конфликты так или иначе вам знакомы. Если они не случались с вами, то точно случались с одним вашим другом. И зачастую, если смотреть на них со стороны, становится видно, что в этих конфликтах нет злодеев, которые хотят сделать системе плохо. Есть два вполне рациональных человека, которые пытаются договориться, но почему-то не получается. Потому что зачастую они договариваются не о том.
Почему мы договариваемся не о том
Что такое компромисс? Это что-то среднее между действиями.
Мы спорим об оценке и выбираем компромисс по оценке. Мы спорим о действиях «читать – не читать» и выбираем компромисс по поводу дисциплины. Мы спорим «внедрять – не внедрять» и выбираем компромисс по поводу версии или степени давления: «Ладно, вот это пока оставим, а тут додавим».
Но проблема не в этом. Проблема всегда на шаг глубже. Она в том, какие потребности мы пытаемся защитить.
Такие конфликты удобно разбирать через инструмент ТОС, который называется «туча». В «туче» есть одна сторона: у неё есть важное решение, которое защищает важную потребность системы, а не просто каприз конкретного человека. И есть другая сторона, у которой ровно такая же история.
Проблема конфликта не в том, что нельзя одновременно читать и не читать требования, а в том, что каждый из вариантов ставит под угрозу другую потребность.
А знаете, что такое компромисс? Это когда итоговый вариант ставит под угрозу обе потребности. Например, в случае с новой или старой версией, если мы внедряем что-то среднее, мы ставим под угрозу и текущую работу, и возможность дальнейшей поддержки.
Почему так происходит? Зачастую, когда говорят про компромиссы и конфликты, приводят в пример историю про то, что конфликт – это ситуация, когда нам надо поделить пирог, а он маленький. Мне надо больше половины, и тебе надо больше половины.
Что такое компромисс? Плюс-минус пополам, одинаково не хватило.
Что такое win-win? Найти пирог побольше.
Одно из важных оснований теории ограничений — всегда возможно win-win-решение. Это звучит спорно, но в это выгоднее верить. Потому что если вы не допускаете, что проблема решаемая, вы её не решите: вы даже пытаться не будете.
Давайте хотя бы ради интереса допустим, что win-win-решение есть. Это не значит, что вы его обязательно найдёте. Но если мы этого не допускаем, мы почти автоматически ищем компромиссы и ставим под угрозу обе потребности.
Почему, если мы верим в то, что win-win всегда существует, win-lose – это плохое решение? Потому что win-lose – это когда: окей, я отхватила себе большой кусок пирога. Но вообще-то был пирог побольше.
Образ пирога в конфликтах – это очень частая история про дележку ресурса, например, бюджета, чего-то, что можно так или иначе пощупать. Мы говорим: «Мне или тебе».
В автоматизации мы часто делим не бюджет, а неопределённость: на чьём берегу её останется больше. Я пролечу, потому что ты потом будешь у меня всякое требовать. Или ты пролетишь, потому что мы в несколько раз перезаложимся.
Это дележка неопределенности.
И когда мы идём на компромисс, мы ничего не делаем с неопределенностью. Максимум, что мы сделаем, – снизим её на сейчас. Мы перестанем спорить, начнем что-то делать. Но на самом деле мы ничего не поменяем. Мы не решим проблему.
И проблема компромисса, извините за тавтологию, в том, что он зачастую не решает проблему и не делает систему лучше.
Что стоит делать вместо компромисса
Вернемся к одному из конфликтов – про оценку.
Вместо того чтобы сказать: «Ладно, давайте встретимся где-то посередине», стоит разобраться: «А почему меня не устраивает? И почему тебя не устраивает?»
Это не всегда так, но часто есть такое объяснение. Почему я, и в этом смысле вы, хочу заложить подстраховку в оценку? Потому что я знаю, что все пойдет не так.
Я знаю, что пользователи не всегда умеют читать требования. Они говорят: «Да-да-да, это то, что мне надо. Да, мы так сейчас и работаем». А потом выясняется, что всё по-другому, всё надо переделывать, ещё и в последний момент. Я знаю, почему прошу подстраховку.
Почему пользователь просит подстраховку? Потому что он не знает, какой в итоге будет результат. Если честно, мало кто из вас занимается реально автоматизацией в смысле: вот оно работало как работало, мы сделаем все ровно то же самое, только автоматически. Ни фига. Мы занимаемся организационными изменениями. Все будет по-другому.
А какая будет выгода от этого «по-другому», я не знаю. А если я не знаю, какая будет выгода, значит, мне надо потратить как можно меньше. Иначе я рискую не окупить проект.
А еще знаете почему? Потому что мы подозреваем друг друга в обмане. Я знаю, как вы пишете отчеты. Вы знаете, как я обещаю, что понимаю, что у меня происходит.
Вопрос: каким образом компромисс по оценке решает эти предпосылки? Никаким.
Мы ничего не делаем с неопределенностью, которая вообще-то известна и понятна. Мы не можем ее полностью исключить, но можем перестать делать вид, что мы что-то с этим делаем, и начать реально что-то с этим делать.
Потому что «ни тебе ни мне» – и мы столкнемся со всеми проблемами, которые только что озвучили. Что такое компромисс? Это: хорошо, мы не будем с этим разбираться сейчас, но в последний день проекта все это будет стоить намного дороже.
Что нам надо делать вместо этого? Вместо того чтобы управлять оценкой, надо разбираться с неопределенностью.
Когда мы говорим про оценку, мы говорим: «Окей, мы понимаем, что будут переделки. Вместо того чтобы закрывать на это глаза, давайте фокусироваться не на оценке, а на том, с чем нам предстоит разбираться на самом деле».
Что такое оценка? Особенно когда мы очень тщательно оцениваем каждую задачу, а потом еще режем 20%. Каждый из вас, оценивая свою часть задачи, заложил туда подстраховку. Почему же тогда нам никогда не хватает времени?
Потому что когда мы фокусируемся на локальной оптимизации, то есть на том, чтобы в одном отдельно взятом месте сделать хорошо, выясняется, что система проигрывает.
У каждого подстраховка своя. Я ей, скорее всего, не воспользуюсь, потому что буду делать в последний день. Все же знают: до экзамена либо дофига времени, либо один день.
Я буду делать в последний день. Я буду надеяться, что все будет хорошо. Не как в прошлый раз, и в позапрошлый, и в позапозапрошлый, и вообще всегда. В этот раз все будет круто. Я своей подстраховкой не воспользуюсь. Если мне повезет, я сделаю вовремя. Если не повезет, я сорву срок. Из-за этого поедет все дальше.
Когда мы фокусируемся на отдельных оценках, мы фокусируемся на том, чтобы в каждой отдельно взятой точке все было хорошо. Но так не происходит.
Вместо того, чтобы фокусироваться на локальном, мы должны смотреть на систему. Когда мы говорим про неопределённость в оценке, важно смотреть на количество переделок, самые сомнительные места и общий буфер проекта, а не пытаться спрятать подстраховку в каждой отдельной задаче.
Когда мы говорим про «читать – не читать» требования, чем мы пытаемся снизить неопределенность? Дисциплиной. Заставить их читать требования. Решает ли это проблему с неопределенностью? Никак. Может быть, он найдет, куда вас ткнуть потом, и будет в этом месте чуть более определенным. Но это никак не решает проблему с неопределенностью.
Какие проблемы с неопределенностью связаны с описанием требований? Если у нас 200 страниц и там все важно, значит, там ничего не важно. Так не бывает.
Чем мы можем управлять? Мы можем управлять степенью неопределенности. Мы можем говорить: «А вот это важно. А здесь у тебя есть вариабельность. А в этих местах делай что хочешь на самом деле. Мы как-нибудь пробьемся».
Когда мы говорим о внедрении нового и старого, чем мы зачастую управляем? Давлением, эскалацией. Мы говорим: «Мы сейчас настоим, они потом привыкнут, они потом подстроятся». Или: «Мы сейчас подстроимся, а потом как-нибудь само рассосется, переделаем».
Но нет. Проблема не в том, что они не хотят нового, сопротивляются и боятся прозрачности. Проблема в том, что им надо делать свою работу. И где здесь проявляется самая большая степень неопределенности? В переходном периоде.
Вчера я знала, как работала. Завтра вы говорите, что будет все хорошо. А между вчера и завтра выясняется, как в нашем случае, что прошел год.
Степень неопределенности не в том, чтобы заставить его пользоваться или не пользоваться новой версией, а в том, чтобы разобраться с ним: какие рисковые моменты он видит в этот переходный период? Чего он на самом деле опасается? Не того, что вы узнаете, что он что-то недоделывает, а того, что он не сможет делать то, что считает важным.
Может быть, он неправ. Может быть, это даже неважно. Но просто пытаясь надавить на него через эскалацию, вы об этом никак не узнаете.
В конфликтах по автоматизации зачастую мы спорим на самом деле про неопределенность, но ей не занимаемся.
Да, это сложно. Да, неопределенность неопределенная. Ее невозможно исключить. Это очевидно. Но как минимум надо перестать делать вид, что ее нет. Надо начать ей заниматься.
Простая инструкция для работы с конфликтом
Каким образом это делать? Я попыталась сформулировать простую инструкцию. Понятно, что она непростая. И самая большая сложность на самом деле в том, чтобы перестать игнорировать неопределенность и попробовать туда залезть.
Если попробовать вытащить из этого инструкцию, она звучала бы так.
Когда вы сталкиваетесь с конфликтом, вы о чем-то спорите. Неважно, происходит это вслух или это молчаливые перепирания, но вы о чем-то спорите.
О чем вы спорите? О сроках, о полномочиях, о цене? О том, что надо или не надо делать?
Вы по поводу чего-то пытаетесь найти компромисс. А где на самом деле там неопределенность? Почему вы в этом месте пытаетесь договориться? Сделайте шаг назад. Какую неопределенность вы пытаетесь защитить?
И после того как вы поймете, что за неопределенность пытаетесь защитить, у вас уже появляются шансы как-то ей поуправлять.
Например, уходить от локальной оптимизации в глобальную. То есть вместо того, чтобы пытаться оптимизировать в каждой отдельной точке, смотреть на систему целиком.
Или, если мы говорим про оценки, управлять рисками. Понятно, что сейчас это звучит как очередное название непонятной статьи «Управление рисками». Но когда мы переходим к каждому конкретному проекту, к каждой отдельно взятой проблеме, там зачастую довольно понятные риски. Это не про все вообще подряд. Это про конкретные больные точки в конкретной ситуации.
Вместо того чтобы спорить, читает он или не читает требования, зазнался он или нет, давайте пройдемся по тому, что действительно суперкритично и важно. А где можно быть более лояльным.
И снова: обычно речь не о том, чтобы «сгородить систему» ради системы. Речь о том, что в отдельной конкретной ситуации вы можете сформулировать, что критично, где есть свобода, и о чём нужно договориться заранее.
Когда мы говорим о переходе со старой версии на новую, давайте сделаем допущение, что люди не такие уж и плохие.
Это, кстати, еще один основной постулат теории ограничений. Он звучит довольно наивно: «Люди хорошие».
Звучит суперспорно. Но что на самом деле имеется в виду? Не то, что все такие зайчики-котики и все молодцы. Нет. Речь о том, что если кто-то что-то делает плохо, а первое, к чему вы приходите, – это обвинения, вы в тупике. Вы ничего с этим сделать не сможете.
Вместо этого давайте предположим, что он на самом деле не негодяй. Не бракодел, который пытается скрыть все свои косяки и вообще сделать всем плохо. Он пытается какую-то свою часть работы сделать хорошо. Может быть, он неправ. Может быть, не надо ее делать хорошо. Но давайте сначала попробуем с этим разобраться.
Если пользователь сопротивляется новой версии, давайте постараемся понять, чего он боится. А не сразу поставить на нем крест и сказать: «Все понятно, он боится прозрачности».
Вы же знаете картинку, где два берега, и там «наши доблестные защитники» и «их негодяи-воины», «наши прекрасные идеи» и «их сырое непонятно что»? Если вы подходите к разговору с пользователем из позиции «ты негодяй», он будет зеркалить.
Если мы подходим к разговору с пользователем с позиции «я понимаю, что ты сопротивляешься не просто так. Ты здесь давно. Ты вроде бы хорошо делаешь свою работу, раз все еще здесь. В каком месте я тебе мешаю ее делать? В каком месте ты боишься, что потеряешь контроль? Не в смысле спрятать косяки, а в смысле не сможешь хорошо сделать то, что собираешься делать хорошо», – тогда мы начинаем управлять переходным периодом, а не тем, насколько быстро или небыстро мы заменим старые кнопки на новые кнопки.
Любая проблема – это противоречие
В теории ограничений конфликт — это супербазовая штука. Мы хорошо видим конфликты, когда буквально спорим. Но на многие проблемы, которые не получается решить, тоже полезно смотреть как на противоречие.
Это не только история, когда конфликт находится между вами и пользователем, или вами и собственником, или вами и разработчиком. Это история, когда вы тоже регулярно сталкиваетесь с компромиссами внутри себя и идете на них.
Когда мы сталкиваемся с внутренними противоречиями и компромиссами, там ровно та же история. Мы спорим о чем-то, пытаясь поделить маленький пирог. Но там всегда есть пирог побольше.
Споря внутри себя о чем-то, постарайтесь задать себе вопрос. Вместо того чтобы искать компромисс, посмотрите: какую проблему на самом деле вы не можете решить? Между чем и чем на самом деле боретесь? Не между действиями, а между теми потребностями, которые пытаетесь за счет этих действий удовлетворить.
Я не обещаю, что после одной статьи вы начнёте легко распутывать любые конфликты. Но хороший первый шаг — перестать спорить только о действиях и начать спрашивать: какую потребность каждая сторона пытается защитить?
Мышление запускается с вопросов. Не с ответов.
Поэтому хороший результат этой статьи — не список инструкций, который вы положите в папку «когда-нибудь внедрить», а список вопросов, на которые вы правда попробуете ответить.
Вспомните компромисс, который сейчас выглядит позитивно: вы вроде бы договорились. А теперь проверьте, не окажется ли он слишком дорогим уже в ближайшем будущем.
Попробуйте зарисовать его как «тучу»: что на самом деле защищает вторая сторона, если предположить, что они не негодяи, а защищают потребность системы, которая вам тоже важна?
Если вы попробуете это сделать, это и будет хороший совместный результат этой статьи.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
