Алгоритм работы со сложностью

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

Существует множество методик борьбы со сложностью, например, Domain Driven Design или ТРИЗ. В заметке о навыках архитектора я упоминал, что эти методики предлагают вполне конкретные алгоритмы.

Алгоритмы непросты в описании и освоении, и на их изучение придётся потратить немало усилий. Однако они определяют директиву и задают рамки.

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

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

Ведь давно известно, что хорошо поставленная задача — это как минимум 50%, а как максимум 80 % результата.

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

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

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

Алгоритм состоит из 7 простых вопросов, на которые нужно отвечать последовательно, переходя от одного вопроса к другому. Если вы не можете чётко ответить на какой-либо вопрос, это означает, что вы не до конца осознаёте задачу, и пропуск вопроса в опроснике может вызвать проблемы при её реализации.

Наверняка вы бывали на встречах, где члены команды при постановке задачи начинали использовать специфические термины, будь то бизнес-термины (например, обеспечить DAO/MAO, поднять APRU) или технические термины (например, убрать сервисы в Kuber, добавить дополнительные индексы).

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

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

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

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

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

Agile-манифест гласит: «Работающий продукт — основной показатель прогресса». Основной принцип врача — не навреди. Нам, ИТ-шникам, тоже стоит его перенять. Менять отлаженное, работающее решение без понимания выигрыша в короткой, средней и дальней перспективе — сомнительная идея.

Golang — классный язык программирования с более низким порогом входа, чем Java. Сколько программистов на рынке могут писать на нём хотя бы на уровне middle, не говоря уже о senior?

Что мы будем делать, когда единственный программист уволится, уедет в отпуск в горы, а у нас упадёт наш новый и модный сервис, который на счёт перехода на in house разработку позволяет не платить поставщику? Да, это тот же самый сервис, который сейчас никак не работает, и мы не знаем, как его починить. Крайне трудно будет объяснить, почему после того, как мы потратили кучу денег и времени, сервис стал работать хуже, чем до всех этих затрат.

В моей практике был случай, когда руководству компании два года продавали идею замены CRM-системы на новую и современную. Независимая консалтинговая компания, проведя аудит, сообщила, что выгода от такой замены составит 100 долларов (именно 100 $, никакие нули не потерялись) при затратах в полмиллиарда. Но то были «неправильные» консультанты.

В итоге проекту дали зелёный свет, контракт был в долларах, и, как обычно, в процессе начались проблемы с требованиями и рост бюджета. А в разгар проекта случился 2014 год, помните шок от скачка доллара с 32 до 60 рублей?

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

Очень важный пункт, который особенно касается крупных корпораций — кто заказчик? Я много раз сталкивался с ситуацией, когда различные люди от бизнеса приносили свои идеи, рассказывали, что они хотят, и даже просили проработки задач. Но впоследствии оказывалось, что ресурсы и право принятия решения находятся не в их руках. А по итогам детальной проработки и обсуждения решения с заказчиком, оно было отклонено, так как не приносит бизнес-ценности.

Одна моя знакомая рассказала мне, как, придя на встречу, она спросила: «А кто ЛПР?» (лицо, принимающее решение). Ей указали на какого-то человека за столом. После встречи один из участников при обсуждении следующих шагов сказал: «Вам нужно подготовить материалы ещё вот для этого человека» (которого не было на встрече). На её вопрос: «А кто это?» ей ответили: «ЛДПР» (Лицо ДЕЙСТВИТЕЛЬНО принимающее решение).

Все современные бизнес-книги, коучи и тренинги учат нас думать об успехе, притягивать его к себе своими размышлениями и не думать о плохом. И довольно часто мы идём в расстроенном настроении, потому что не добились результата и не учли какие-то риски.

Я не призываю постоянно думать о негативном, это очень вредно для любого дела, концентрация на негативе приведёт вас к нему.

Учёт рисков — это инструмент подумать над решением тщательнее. Что мы будем делать, если случится это? А что будем делать, если этого не произойдёт? Отработав ключевые риски (в моей практике таких от 3 до 7, в среднем 5), вы куда лучше будете подготовлены ко всяким неожиданностям и будете иметь хоть какой-то план действий, а также учтёте устранение этих рисков в реализации.

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

Ещё Сунь Цзы писал: «Врага заманивают выгодой, а уничтожают вредом».

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

Именно поэтому важно подходить к оценке задачи поэтапно.

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

Честная оценка во времени позволяет отказаться от некоторых инициатив, даже если они хорошо проработаны. Это связано с тем, что такие инициативы просто физически не могут быть реализованы к указанному сроку, а задачи за этим сроком не имеют смысла. Например, подарки к Новому году нужны к 31 декабря, а не к 30 апреля.

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

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

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

У Google есть целое кладбище проектов, которые пришлось закрыть. Закрывать проект всегда неприятно, особенно в России, когда для старта проекта приходится закладывать душу дьяволу. Всегда есть риск быть осмеянным коллегами и получить нагоняй у руководства.

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

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

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