We need to go deeper. Как принять верное решение
Мы все работаем в индустрии убеждения —
убеждаем себя и других в правильности своих решений.
Я считаю, что не существует верных и неверных решений, кроме, конечно, задач по математике и физике. Каждое решение имеет последствия в краткосрочной и долгосрочной перспективе, и предсказать их все не всегда представляется возможным. На эту тему есть хорошая русская поговорка «Не было бы счастья, да несчастье помогло».
Если говорить о решениях, то подразумевается, что решение — это выход из проблемы. Безусловно, есть и исключения вроде «Сидел, сидел, а потом решил полежать», но в общем случае решения принимаются для избавления от проблемы. Существуют как проблемы-угрозы, когда если ее не решить — случится что-то плохое, так и проблемы-возможности, когда ее решение сулит что-то хорошее. Их еще называют перспективами. Из всего множества определений проблем, от древнегреческих до современных, мне импонирует житейское «проблема — это незапланированная ситуация, которую хочется изменить». Действительно, если ситуация была вами спланирована, значит, у вас уже есть план действий и это не проблема. Или если, к примеру, денег нет, но вас это не беспокоит, то это не проблема. А вот когда начнет беспокоить — станет проблемой.
У проблемы нет решения
Проблему нельзя решать. Необходимо преобразовать проблему в задачу или в множество задач, которые уже можно будет решать. И очень важно понимать отличие проблемы от задачи.
К нам, как ИТ-директорам, по роду деятельности очень часто приходят от бизнеса задачи, которые на самом деле задачами не являются.
Первое отличие проблемы — в степени неопределенности. Проблема характеризуется высокой степенью неопределенности и не имеет очевидного и однозначного решения. Для того чтобы преодолеть проблему, решение еще необходимо найти. В отличие от задачи. Задача — четкое и понятное действие или серия действий, и у нее есть определенный алгоритм выполнения.
Второе важное отличие — контекст. Сюда включены причины, симптомы, ресурсы и цели решения. Как правило, контекст проблемы гораздо шире контекста отдельной задачи. А контекст клубка взаимосвязанных проблем организации шире, чем проблема одного отдела. Каждому руководителю отдела свойственно решать только свою проблему или проблему своего отдела, но решение одной проблемы из клубка может вызвать еще большее напряжение в другом узле. Именно поэтому не стоит торопиться решать те проблемы, которые преподносятся как задачи от подразделений бизнеса. Кроме того, не всегда проблемы отдела, и уж тем более проблемы руководителя, имеют отношение к бизнесу. Очень полезно научиться отделять мух от котлет.
Превратить проблему в задачу
Во-первых, чтобы начать работать с проблемой, ее необходимо записать. Незаписанная и незафиксированная проблема таковой не является. Это жалобы, стон, причитания — что угодно, но не проблема.
Когда проблема будет сформулирована и записана, ее, как ни странно, надо переформулировать. Авторская постановка проблемы всегда является... враньем. Человек врет в первую очередь себе, а потом и окружающим. А потому авторскую формулировку надо «расшатать». Существует множество психологических приемов расшатывания формулировки проблемы, выходящих за рамки данной статьи, остановлюсь на самом простом — на бомбардировке вопросами. Они могут быть самыми разными: «как вы себе это представляете?», «кто это будет делать?», «что вы в результате хотите получить?», «когда вы это хотите?», «кому это надо?» и т. п. При этом можно и нужно задавать любые, даже кажущиеся глупыми вопросы. Очень часто простой и глупый на первый взгляд вопрос переворачивает всю картину.
Однажды мы на внутреннем совещании обсуждали проблему синхронизации двух информационных систем после добавления автоматизации нового процесса. Получалась довольно сложная схема обмена и значительные доработки обеих систем, поскольку часть процесса была в одной системе, а часть — в другой. Простой вопрос: «А нельзя ли весь процесс перенести или в одну, или в другую систему?» — сначала вызвал возмущение, так как показался глупым (ведь всем понятно: то, что относится к финансам, должно быть в финансовой системе, а что не относится — в ERP), но хорошенько поразмыслив, мы решили, что самое простое и эффективное решение — перетащить весь процесс в одну, в данном случае финансовую, систему. И вопрос синхронизации отпадет сам собой.
Не надо лечить симптомы
Мне импонирует ассоциация айтишников с докторами. Есть хорошая шутка, что при знакомстве и с теми и с другими люди начинают рассказывать им о своих болячках.
В данной парадигме проблемы — это «симптомы». Не надо стараться лечить симптомы. Надо провести полноценную диагностику и поставить «диагноз» — формализовать задачу. Очень может быть, что задача будет коренным образом отличаться от перечисленных симптомов. И после постановки задачи, решать надо будет уже ее.
Пример: руководитель одного отдела на совещании сказал, что нам требуется новая централизованная геоинформационная система, чтобы все могли ее использовать — заносить и получать те сведения, с которыми они работают в данный момент. Внедрение было поручено мне. После серии продолжительных бесед со всеми заинтересованными сторонами во время бомбардировки умными и глупыми вопросами выяснилось, что нет понимания, кто, как и какую информацию должен получать и отдавать. Если бы я купил крутую централизованную ГИС, то совсем не обязательно, что она помогла бы сделать всех счастливыми. А разложение проблемы на задачи показало, что для их решения не требуется ни инвестиций, ни дополнительных программных и аппаратных средств, ни даже временных затрат на проект. Просто прояснили алгоритмы взаимодействия, и процесс пошел сам собой.
Важные моменты:
-
Факты упакованы во множество эмоций. Важное прячется среди неважного — его надо найти и вытащить на поверхность.
-
Опыт не всегда полезен, так как норовит пустить нас по замкнутому кругу — нужен взгляд со стороны.
-
Проблема всегда субъективна. Автор всегда часть контекста проблемы. Для решения проблемы пространство решения должно быть шире пространства проблемы.
Анализ проблемы
После получения первичной информации следует провести статический, а по возможности и динамический анализ проблемы.
При статическом анализе необходимо расписать плюсы, минусы и нейтральные моменты, которые возникнут, если проблему решить, и аналогично прояснить, что будет, если проблему не решать. Возможно, для разных вариантов решений будут разные плюсы и минусы.
Динамический анализ Consequences&Sequel часто именуют просто C&S: какие последствия от решения/нерешения проблемы наступят немедленно, в краткосрочной, среднесрочной и долгосрочной перспективе. Может случиться так, что то, что представляктся выгодным сейчас, окажется бесперспективным или даже вредным в недалеком будущем.
Самое простое
Если после всех проведенных анализов вы все еще не отказались от решения, то последнее ограничение — бюджет. Для каждого решения требуются ресурсы, как материальные, так и людские, и, соответственно, возможны ограничения этих ресурсов. А потому следующий логический шаг — выбор лучшего из имеющихся решений, укладывающихся в бюджет, и формирование план-графика выполнения задач.
После того как задачи определены, бюджет утвержден и согласован план-график исполнения, проблема исчезает и в дело вступает управление проектами, но это уже совсем другая история.
Опубликовано 18.06.2017
