Два момента внутреннего контроля решений
Без них у вас всё поедет только в одну сторону: вперёд, и возможно, следом бодро под откос. Потому что средства контроля не предусмотрели.
Вот вы столкнулись с прикладным вопросом (любого уровня), выбрали решение. Дальше пошли его воплощать, реализовывать, бодро и с песней. Ресурсы раскиданы, бюджеты выделены, ничто нас не остановит, тапка в пол.
При этом, сложные вопросы обычно не имеют единственно верного, азбучно-хрестоматийного решения. Какие-то плюсы, какие-то минусы. Риски, опять же, которые вы готовы на себя взять. Выбирали из пачки вариантов, выбрали какой-то, который показался наиболее удобным. Это нормальный ход событий.
Что дальше происходит в больших структурах? А вы не сможете, в силу инерции причин и «уже принятого решения» дать заднюю, и даже просто ситуативно прикинуть, не херню ли вы делаете, чтобы скорректировать курс. Потому что никому из заинтересованных лиц это совершенно не выгодно, как бы контр-интуитивно это не звучало в моменте.
- менеджерам? Так они защитили успешное решение и раскидали план, зачем им что-то заново оценивать и переобуваться, это только лишняя работа и затраты
- исполнителям? им тем более не выгодно, им нарезали работы, времени и денег, чего напрягаться, пускай думает тот кому за это платят
- архитекторам? тогда придется признать, что выбранное решение было в чем-то не оптимальным, и опять же цикл лишней работы
- стейкхолдерам и выгодо-получателям? так они решение не получат сейчас никакое, если будем идти менять план
- финансовой группе? а куда уже раскиданные ресурсы, списывать в «потрачено»?
- ресурсному планированию? аналогично
- конструкторам и проектировщикам? переделывать решение больно и дорого, опять же, а чем думали в первый раз, чот проебали
- аналитикам? тогда получается, что аналитика-то чего-то не учитывала, неидеальной оказалась, тоже по голове не погладят
Этот коллективный паровоз на полном ходу, уверенно и оптимистично, поедет до какой-нибудь стенки. После которой начнется разбор полётов, кластер-фак, поиск виноватых.
Признавать ошибки никому не выгодно, дорого и административный самострел. Да, если бизнес перестанет делать херню и пойдет улучшать решение на ранней стадии — все от этого возможно, скорее всего, выиграют. Но конкретно тот, кто поднимет проблему и поставит блокер — подставляется и рискует.
И делать так никто не собирается, и ответственность никто не возьмет (и даже не почешется), пока проблематика не триггернёт. Тем более, признавать ошибки, даже несложные и вовремя, люди весьма не любят.
Авось взлетит, кривая вывезет (нет), свалят на внедрение, что-то прикрутят проволокой и изолентой, чтобы показать требуемые цифры. Обмотают ошибки полиэтиленом. И воздушный шар, чтобы вовремя съебаться с того острова — из анекдота.
Культура перекладывания ответственности, короче говоря.
При отсутствии средств непрерывного контроля вся административная конструкция, весь механизм, становится заложником собственного решения — до тех пор, пока не накопится критическая масса нестыковок.
А может, и не накопится. Вы просто сделаете херню от начала до конца, за свой счёт. С обязательным причитанием «а почему у нас на выходе опять какое-то говно получается».
Уместно также упомянуть про ряд когнитивных искажений, свойственных людям: например, «мы уже влили в это решение NNN бабла, давайте его дожмём» (sunk cost fallacy), как частный случай. Но и все остальные (en, ru) также; просто помните, что все мы предвзяты.
Персональный риск взятия ответственности — это, как вы правильно можете заметить, частный случай «дилеммы заключенного». О которой можно почитать с примером тут. Важный практический момент срабатывает, про (не)нулевую сумму. Зачем человеку подставляться и проявлять такую (в принципе, полезную) инициативу, если ему за это просто прилетит проблем, вопросов, пиздоф и больше работы? Пока запомните этот момент.
Чтобы не быть заложниками ватерфолл-планов на полгода вперед, и гантовок прибитых к стене гвоздями, умные люди придумали гибкие методологии. Они потому и гибкие, что позволяют вносить корректировки по ходу. Некоторой ценой, это факт. Если почему-то не позволяют — значит, вы не поверите, они у вас не очень-то гибкие.
Но как уже написано выше, есть ситуация, когда тормозить, корректироваться и перестать делать херню никому из участников не выгодно. Даже если «гибкость» позволяет. А еще есть субординация, когда поднять неприятный фидбек — значит, подставить под вопросы руководящий состав, которому надо идти принимать доп.решения (что всегда аукнется, и исполнители всегда об этом в курсе).
— когда мы стали ебаным мейлру настолько, что не могли это просто вовремя обговорить и решить?
Сходная проблематика прослеживается также в истории про «односторонних людей»: людям нарезали задачу «херачить отсюда до горизонта», люди у нас деятельные и инициативные, вот и будут воевать до победного, без оглядки на апокалипсис и выжженую землю.
Можно было бы сьязвить, из анекдота: «инициативность и проактивность не положительные качества, если человек тупой».
Но нет, это в данном случае совсем не в человеках дело; это кто-то контроль не предусмотрел, либо он нихера не сработал.
И нет, killswitch, он же «мастер-рубильник выключить всё нахрен» и перейти в damage control когда всё уже проебали — это не очень тот контроль, который вам нужен. Хотя и за него спасибо, пригождается. Это скорее ограничительная дополнительная мера на тот случай, когда нормально не сработало.
Есть еще отдельная беда — внутри-корпоративная грызня. Когда команда А собирается сделать свое решение (получить на него ресурса, сроков-денег, и возможные звёздочки), и команда Б, которой выгодно топить команду А только для того, чтобы продвинуть свое решение (и себе получить ресурса, сроков-денег и возможные звездочки).
Что там за качество решений у команды А, команды Б, и насколько обе предлагают херню, или не херню — бессмысленно спрашивать у самих команд. Совету директоров обе нарисуют максимально лучезарные планы, просто чтобы получить ресурсы. Особенно, если они еще и (суб)подрядчики.
Здесь налицо сбитая целевая функция — выбивание бюджета, вместо пользы и качества, адресуется такая проблема иначе.
Люди принимают решения. Это нормально. Решения могут и чаще всего будут не идеальными, а теми, которые показались чуточку более оптимальными в моменте. Это нормально. Их все равно надо принимать.
Люди ошибаются, заблуждаются, оценивают риски на глаз и по внутреннему убеждению. Это нормально (если у вас есть способ лучше, заносите).
Никто не знает на старте задачи всех ее деталей на 100%, потому что вы решаете ее в реальном мире, а мир сложный. Это нормально. Вы можете не знать ситуацию на 100%, а лишь предполагать, что вашего знания достаточно. Это как бы тоже факт, другого не будет.
Более того, мир зараза такая меняется — и стохастически, и преднамеренно, вы же не одни на рынке — условия задачи и критические факторы могут, и будут меняться. Это нормально, это даже ожидаемо.
Вот если вы с этим всем не умеете работать, тупо игнорируете, и ваша система-механизм не умеет с этим жить — а умеет «ехать только вперёд» — это уже не очень нормально. Это проблемно и дорого.
Соответственно, есть две штуки, которые должны быть в сам механизм заложены. Обе про контроль.
Первая — контроль внутренний этапный. Вы проверяете, гранулярно на каждом этапе работ согласно их декомпозиции, соответствует ли практический выход тому, что вы ожидали в плане.
Здесь план остается прежним, вы оцениваете ваш в него вклад. Хотели сделать вот это (принимаем, что вводные все еще верны), а получилось ли реально заявленное, не объебались ли мы внутри нашей работы, сошелся ли план/факт. А если нет, что ему мешает, и не хотим ли мы что-то с этим сделать.
Вторая — контроль применимости. Вы проверяете, гранулярно на каждом этапе, соответствует ли практический выход тому, что потребуется для решения задачи целиком с теми вводными, которые наличествуют прямо сейчас. Может, у вас исходные вводные, со старта, уже не те.
Здесь наоборот, привнесенный вклад и результат работы принимаем как верный и объективно константный (особенно если он уже реализован), а следом сидим оцениваем, не проябываемся ли мы в моменте согласно тому, что от нас требует сам план и исходная постановка задачи — возможно, уже ее саму стоит актуализировать и привести к новой реальности.
Беспокоиться надо начинать в том случае, когда у вас подобный контроль в принципе нигде не прописан, или по факту не работает. Если он даже не прописан, вас ждет «избегание ответственности» в самом каноническом виде: кто, в таком случае, возьмет на себя ответственность сказать «надо вносить корректировки»? Да никто, это никому не выгодно, см выше.
Вы же не собираетесь ехать на автомобиле, закрыв глаза, затянув лобовуху одеялом и включив музыку погромче.
Вам нужна корректная достоверная обратная связь, желательно в реальном времени, иначе о расхождении ожиданий вам расскажет физика неупругого соударения, обычно задорого.
Но системы сложные. И да, средства контроля могут отвалиться в любой системе. Кстати, если вы их не проверяете, значит вы только думаете, что они у вас есть. См «чего не проверяешь, того не знаешь».
Как проверять: рамочно очень просто. Из любой точки системы и механизма аргументированное знание «вот тут мы, кажется, порем херню» как быстро и с каким результатом дойдет до лиц, принимающих решения — ? Как вообще это должно происходить, где это написано? Как это проверить в моменте? Какова практическая механика?
Отсутствие отрицательной обратной связи «никто ничего не орёт» чаще всего означает то, что ничего вовсе не работает. Чтобы в системе было ноль проблем, достаточно выключить ее нахрен — очевидно же.
Собственно, если в любой точке системы органически невозможна ситуация получения негативной достоверной обратной связи, значит вы ее там никогда и не получите в принципе, ни при каких обстоятельствах. См «бывает ли по другому». Это выбор без выбора.
Если «отчет руководству» от отделов и подрядчиков по факту не может быть чем-то кроме «всё хорошо», значит ценность такого фидбека даже не ноль — она отрицательная. Любая проблема будет заметена под ковёр любой ценой, даже ценой апокалипсиса, о котором вы узнаете последним.
Учитывайте также, что метрика «ОК / не ОК» слишком детерминированная, налицо переупрощение. Обычно все сложные штуки имеют наработку на отказ и градиент проблем. И процессы, и механизмы обратной связи — тоже.
Если вы в моменте узнаете на 80% работы что «всё, нам пзда, дальше ничего никуда не поедет, расходимся пацаны», вам станет от этого не сильно проще жить. Гораздо комфортнее было бы узнать о нарастающей проблематике заранее, вовремя, и даже принять соответствующие меры.
При проектировании механизмов и процессов, включая административные, корректно и правильно такие цепочки обратной связи предусмотреть и заложить. Тогда любая беда всё еще не катастрофа, и шансы/риски «факапа как явления» у вас резко, принципиально снизятся. Еще по теме см «невозможность факапа».
И вернусь к оговорке выше, про «дилемму заключенного». Чтобы полезная обратная связь работала и была полезной, она должна не только быть, но и поощряться. Иначе «ненулевой суммы», позитивного выхода, в этой игре не будет, минусы перевесят плюсы, никакой коллаборации не случится — подробнее снова тут.
Hope that helps.
В рецепты, кстати.