От провала до успеха один шаг: как спасти заваленный проект

Самая большая проблема — практически никто не готов признать, что ему нужна помощь. Мало кто планирует на перспективу: все начинают суетиться, когда ситуация доходит до кризиса. В этот самый момент меня и зовут. Я помогаю разрешить проблемы на проектах, когда стандартные методы (разговоры с заказчиком, реструктуризация, обсуждение финансов и другие) уже были использованы и не помогли. В новой статье в блоге ЛАНИТ приведу пять приемов, которые я использовал в разное время и с разными командами. 

Почему это работает? Конечно, мне хотелось бы думать, что все объясняется моими выдающимися профессиональными качествами. Но должен сам себя огорчить: работает совсем другой механизм. Моя помощь полезна, прежде всего потому что это взгляд на кризисную ситуацию со стороны. По той же причине эффективна семейная терапия: не ты копаешься в собственных проблемах, а кто-то другой — тот, кто способен в них разобраться. Это приводит к хорошим результатам в личной жизни, в контроле здоровья и в очень крупных проектах. Человек извне замечает то, что не видят люди, давно задействованные в решении проблемы. 

Докопаться до сути

Для этого приходится очень глубоко погружаться в вопрос. Ведь все попытки разрулить проблемы обычными способами («давайте добавим в проект ресурсов», «поговорим с владельцами компании-заказчика, а не с менеджерами» и т.п.) уже были предприняты раз десять до моего прихода.  Какой выход? 

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

Второй шаг — разобраться в деталях самого проекта, как именно делается система, какие есть проблемы. Но здесь возникает препятствие — люди на проекте обычно не горят желанием работать в связке с засланным к ним внешним человеком. Команды надеются получить в подмогу программистов, тестировщиков или бизнес-аналитиков, но уж никак не топ-менеджера. Только менеджеров им на проекте не хватало! От глубокого понимания задач каждого из них я поначалу очень далек, а потому в начале работы лучше придержать свои идеи и советы при себе. Однако как только я начинаю разбираться в деталях больше или на том же уровне, что и люди, с которыми имею дело, они начинают меня принимать и уважать. Ведь каким-то немыслимым образом мы заговорили на одном языке. Это важный момент в адаптации в команде.

В одном из проектов аналитики несколько месяцев пытались согласовать с заказчиком дэшборд, демонстрирующий результаты работы системы. Загвоздка состояла в том, что строился он на огромном количестве исторических данных по сложным формулам. Требовалось, чтобы графики дэшборда полностью совпали с результатами из существующих систем. Но у нашей команды несколько цифр никак не сходились с «ответом».  Что делает менеджер проекта в таком случае? Назначает встречу для обсуждения вопроса, грозит штрафами или сулит премию. Если это не сработает, есть еще масса управленческих подходов к решению задачи.

Для меня же это — шанс разобраться в деталях. Я скопировал к себе данные, понял, что означает каждый из показателей и попытался сам провести вычисления. Когда копаешься в данных, они становятся тебе как родные. Ведь приходится улавливать отраслевые особенности и вникать в детали реализации в рамках проекта. В результате я заметил несколько странных моментов и вспомнил знаменитый пример из книги Оскара Моргенштерна «О точности экономико-статистических наблюдений». В начале XX века в одной из европейских стран вдруг в разы уменьшилось производство мяса птицы и с тех пор оставалось на том же уровне. Чем объяснить такую странность: эпидемией, сменой предпочтений, забастовками? Оказывается, всего лишь сменой календаря, переходом на новый стиль. Дело в том, что раньше статистику собирали до Рождества, а затем стали считать после праздника и, конечно, к этому моменту все индейки и даже курицы каждый год были уже съедены.

Аналогичная проблема обнаружилась и в данных клиента. Оказалось, что ни в каких методиках не был зафиксирован факт реформы отрасли, который отразился на статистике. Как только мы учли эти изменения, все данные сошлись. Решились ли от этого проблемы в проекте? Конечно, нет, но с этого момента к моему мнению стали прислушиваться и представители клиента и моя собственная команда, недоверие исчезло и сменилось уважением.

Вовремя напомнить о сути проекта

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

Что делать дальше? Одного волшебного совета, действенного во всех случаях, нет. Скорее, есть некий инструментарий, который можно применять в зависимости от ситуации. Конкретный пример — крупный проект по разработке информационной системы в промышленности. Я каждый день приходил на совещания к рабочей группе и не узнавал проект. Задачи менялись так кардинально, что казалось, что идет обсуждение новой системы. Разработчики говорили примерно так: «Нет, все, что было вчера, это уже неактуально. Мы поговорили с клиентом, и надо все переделать». На следующий день слышу примерно то же: «Все снова поменялось. Теперь мы докручиваем вот этот модуль». На третий день мы снова бежим уже в каком-то новом направлении. Через неделю я понял, что это полный бред. Мы мечемся из стороны в сторону, однако ни на шаг не приближаемся к основной цели — созданию информационной системы в соответствии с изначальным техническим заданием. 

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

Как вы думаете, как принимали систему? Смотрели на все высказанные нам «хотелки» и внезапно возникшие креативные идеи? Конечно нет, систему принимали строго по ТЗ. Вся моя помощь заключалась в том, чтобы подтолкнуть команду двигаться в верном направлении, не распыляя ресурсы. 

Не подменять основную цель второстепенной

В другом проекте в финансовой сфере, в который я был привлечен, не менялось направление. Все делалось правильно. Каждое изменение обсуждалось совместной комиссией. Существовал реестр изменений и отдельная процедура внесения дополнений в этот реестр. Все очень серьезно. Однако это нисколько не помогло. 

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

Много проектов «излечиваются» лишь за счет того, что вы просто напоминаете людям, чем им надо заниматься и контролируете, чтобы они не отвлеклись снова. 

Переформулировать результат

Другой пример. Проект выполнен: система в сфере управления персоналом работает, все требования соблюдены. Но руководство заказчика рвет и мечет: «Мы платили не за это, и вообще НИЧЕГО не работает». 

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

В этой ситуации мы привлекли независимых экспертов, работающих в сфере HR, и попросили их назвать нам основные показатели, важные для оценки эффективности процессов. Они объяснили, какие параметры являются для них первостепенными, а также какие еще цифры они хотели бы видеть. 

Затем я отправился к нашим разработчикам с вопросом, есть ли у нас эти показатели? Мне подготовили выгрузку этих цифр, а также многих других сопутствующих параметров (система была и, правда, очень хороша и уже наполнена реальными данными, которые рядовые сотрудники клиента помогли в нее внести). На основе их я построил огромный компьютерный отчет с инфографикой и диаграммами. А учитывая, что решение в команде-заказчика принимала женщина, то постарался сделать отчет еще и максимально визуально красивым. Когда мы вновь презентовали наше решение заказчику, то сказать, что руководство было удивлено — это ничего не сказать. Клиент до последнего не верил, что это данные из той же самой системы, которую он еще недавно просил полностью переделать. Все, что было нужно, это перевести данные из технических интерфейсов в графический бизнес-язык и рассказать о функциональности нашего решения в максимально прикладном русле на живых данных заказчика. 

Показать финал на старте 

Во всех описанных выше ситуациях люди были готовы к диалогу. Однако бывает и по-другому: например, заказчик не принимает проект без объяснения причин. Самый простой способ переломить ситуацию — это заслужить больше времени на урегулирование конфликта быстрой победой. Универсального приема быстрой победы нет. Но есть прием, как ее показать. А именно нужно придумать красивую идею, интересную руководству заказчика. В ИТ это делается с помощью работающих прототипов. Здесь вы, наверное, усмехнетесь, так как это всем давно известно и как, казалось бы, прототипы помогут вернуть расположение недовольного клиента? Все дело в деталях. 

Во-первых, прототип должен реализовывать какой-то бонус к тому, что изначально было запланировано в проекте. Во-вторых, он должен быть сделан так аккуратно, как только возможно. И на это почти не один технический специалист не способен. Он все равно где-то назовет пользователя «Тест», нарисует интерфейс кое-как, подумав «ну потом доработаем с дизайнером» и обязательно скажет: «А как мы будем рисовать прогнозы, у нас же нет данных. Да и методики нам еще не передали. Это заказчик должен делать прогнозы – мы же ничего в его сфере не понимаем». Так вот это – не аргументы. Прогноз должен быть выполнен настолько хорошо, будто над ними работала вся команда специалистов заказчика.   Кроме этого обязательно нужно придумать не только имена пользователей (пусть пока и несуществующих), но даже их личные истории, а также нарисовать максимально реалистичные интерфейсы.

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

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

Как спикер с большим опытом, я почти на подсознательном уровне отслеживаю реакцию аудитории. И в какой-то момент я замечаю, что общий восторг вдруг сменился ледяным холодом. Хотя я был в ужасе, но собрался и довел презентацию до конца, не понимая, что я сделал не так. В конце загадка разрешилась. На мое предложение к обсуждению мне задали единственный вопрос: «Откуда вы получили данные, которые демонстрировали?» Я честно признался, что это результат нашего многодневного анализа. Но клиенты не хотели верить, оказалось, что мы с огромной точностью угадали реальные значения, которые, как полагал клиент, были абсолютно конфиденциальными. И хотя потом мы показали наши выкладки, и недопонимания удалось избежать, но я понял, что бывают и такие ситуации, когда слишком хорошо — это тоже недостаток. Однако историю я привел с другой целью, чтобы показать тот уровень проработки, который требуется от прототипа, если вы правда хотите, чтобы он сработал.

Копировать лучшее

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

Тогда я задался целью отыскать некий рабочий прототип нужной нам системы. Не обязательно в России и уж точно не идентичный тому, который мы создавали, но похожий и главное — реально существующий. Чтобы высвободить время на чтение, я примерно месяц ездил до работы на метро. В итоге я отыскал пример. В одной из стран уже была хорошая готовая система для всей отрасли. Более того, в открытом доступе были опубликованы все методики, подробные отчеты, а код выложен в open source. Разумеется, мы его не использовали, так как решение оказалось не применимо в российских реалиях. Однако этот кейс стал для нас лучшей мотивацией. Мы убедились, что задача выполнима, и получили четкое направление работы (ведь перед глазами был реальный прообраз создаваемой системы). 

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

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

Вместо резюме. Не бойтесь удивляться

Сама деятельность по спасению проектов, находящихся на грани катастрофы, — это очень изматывающая и неблагодарная работа. Но когда ты видишь, как у команды начинают загораться глаза и в них появляется надежда, а люди снова жаждут работать, то это по-настоящему вдохновляет. А еще здорово, когда уставшие от неудач коллеги начинают удивляться. Ведь решение лежало где-то совсем рядом, оставалось только его отыскать. 

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

Но, возможно, глобальные перестройки почти никогда и не нужны. Мое вмешательство мало отражалось на жизни команд: они не вставали и не бежали в другом направлении, а продолжали делать ровно то же самое, что делали раньше. Отмеченные мною приемы, это, скорее, небольшие нюансы, однако они принципиально меняли результат. Удавалось сделать невозможное —  потенциальный факап со временем становился победой. 

Готов к обсуждению в комментариях.