Пожарный не из Чикаго — как тушить огонь в ИТ-проектах

Привет, Хабр! Меня зовут Александр. 17 лет в КРОК. В основном занимаюсь разработкой и внедрением заказного ПО, хранилищ данных, решений Big Data для бизнеса и госсектора. Начинал консультантом по внедрению и последние 11 лет работаю менеджером крупных комплексных проектов. А еще я немного пожарный, потому что регулярно помогаю коллегам тушить проектный огонь. 

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

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

Про коллаборацию заказчика и соисполнителей

В больших проектах всегда интересно, и часто они преподносят разные челленджи, но тем они интереснее. Мой первый крупный проект (это было внедрение ЕМИАС в поликлиниках Москвы) случился аккурат под новый 2011-12 год, когда у клиента началось активное внедрение новых сервисов в здравоохранении для граждан, сопровождаемое не менее активной информационной кампанией. И мы тоже несли ответственность за развиваемый клиентом бренд ЕМИАС. Огонь возник в условиях готовящейся инфраструктуры и интенсивно развивающегося ПО. Новая функциональность выходила чуть ли не каждую неделю, партнеры готовили СКС, мы доставляли АРМы врачам, устанавливали, подключали, обучали регистраторов заводить расписание, врачей — работать с приемом пациентов, запускали и настраивали бизнес-процессы, связанные с внедрением новых сервисов. И все это на фоне ожиданий со стороны правительства Москвы и лозунгов в прессе, что вот — новая функциональность, вот — новые поликлиники подключили. Таким образом перед нами ставились весьма амбициозные цели и сверх амбициозные сроки.

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

Про коллаборацию заказчика и соисполнителей еще раз

Годы работы в проектах ЕМИАС преподносили нам очень разные вызовы — в 2013 у нас была команда внедрения с 700+ консультантами во всех амбулаторно-поликлинических учреждениях Москвы. В 2018 нам надо было найти 100+ консультантов для внедрения лабораторного сервиса ЕМИАС — это два месяца собеседований нон-стоп. Но оно того стоило!

Как справились с огнем? Тут, опять же, заказчик помогал в согласовании плана внедрения на стороне объектов внедрения с постепенным наращиванием оборотов и административным ресурсом — с оповещением поликлиник, лабораторий. Это еще раз подтверждает тезис необходимости совместной мощной команды не только со стороны исполнителя, но и заказчика. В сложных проектах верно выстроенный процесс взаимодействия и коммуникаций (читай синергия команд обеих сторон процесса) —  путь к успеху. И вторая мораль этой истории — не бояться огня. Глаза боятся (осознав, сколько нужно консультантов и в какой срок, задача казалась нерешаемой в принципе), а руки взяли и сделали! Хоть и собеседования проводили всем миром.

Про ток, или Как снять напряженность клиента

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

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

Про важность работы напрямую с бизнес-заказчиком и решение именно его задачи

Несколько похожая, но вместе с тем иная ситуация была у меня и в другом проекте, где мы для одного из банков делали Big Data систему для построения профиля клиента и оценки рисков при выдаче кредита. В момент подключения меня в проект была не первая фаза, а я — не первым РП на стороне исполнителя. Ситуация была схожа с прошлым кейсом — непрозрачный процесс разработки для заказчика усугублялась отсутствием четкого ТЗ, ибо такого рода систем в банке, да и на рынке, в то время по сути еще никто не делал. Были первые ласточки в банке Т и банке А, однако готовых решений (да еще на open source) — не было. По сути строили с нуля, склеивая кусочный опыт в комплексное решение, попутно синхронизируясь с заказчиком. И еще требования бизнес-заказчиков ловко и резко менялись по ходу представления.

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

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

Про не всемогущий agile

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

А от исполнителя нужно только локальное управление внутри задач и команды, приоритеты и контроль, состав спринтов. Работали по T&M, еженедельно отгружая таймшиты. При этом нам полностью доверили экспертизу и проектирование системы и ее архитектуры, но на входе дали лишь основную суть бизнес-задачи. Детальное исследование и постановка была тоже на нас. Главная проблема была в том, что кроме РП со стороны заказчика в его команде первые два месяца по сути никого не было. И осознал он (мы заметно раньше) эту проблему только через два месяца работы. То есть когда мы, во-первых, не дошли до ожидаемого им результата (напомню, управление на стороне заказчика) и, во-вторых, ему показалось, что выставленный счет слишком высок, несмотря на регулярные таймшиты, которые принимались и фиксированные ставки — договор-то был по T&M. Пахло кризисом жанра. Ситуацию усугубляло еще и то, что со стороны заказчика, как и в прошлом кейсе, системы-источники для разрабатываемой системы были не готовы с нами интегрироваться, а заказчик отказывался принимать результаты работ без демо работоспособного решения.

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

Про опытных пожарных

Так исторически сложилось, что я начал помогать решать проблемные ситуации и в проектах коллег. И за последние несколько лет не было и года, чтобы я не помогал тушить по крайней мере один пожар, ну, или снижать градус жары. Тут бывали разные ситуации. Например, в одном проекте крупной торговой сети я не занимая место основного РП, помог усилить команду управления. В мои задачи входило: перезагрузить отношения с командой заказчика, пересогласовать план работ и успешно довести проект до завершения. Еще в одном проекте была как раз смена менеджера, в котором я поработал над реструктуризацией графика в угоду общей цели проекта. Пожара не было в итоге. Ну и вообще иногда полезен взгляд со стороны  сам пользуюсь этой опцией в своих проектах. У нас в командах это практикуется.

Мало огня?

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

Этот кейс был особенно сложен еще и тем, что по ходу проекта (это более 1,5 лет) многие задачи делались от потребности заказчика в моменте, без оглядки на ТЗ. К концу проекта оказалось, что сделана гигантская работа, но не по ТЗ. Хотя многое реально потеряло актуальность за время проекта. А подписались-то мы под ТЗ. И особенности конкретного заказчика были таковы, что невыполненные требования ТЗ к принимаемой системе — это путь под откос.

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

Противопожарные меры

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

Со стороны исполнителя — важные и проблемные места, которые могут привести к пожару:

1.  Отсутствие полной команды управления исполнителя. Для КРОК это два менеджера — РП и технический менеджер — ТМ, а для комплексных проектов с несколькими командами РП и несколько ТМ;

2.   Проблемы коммуникаций — не пускают к функциональным заказчикам;

3.   Проблемы коммуникаций между смежными командами внутри исполнителя (тоже бывает не так уж редко), и, конечно, с командами заказчика;

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

5.  Проблемы с «ехать». Главное для заказчика — ехать или шашечки, и, эскалируя проблему, он настроен на реструктуризацию проблем и сроков и стремится к результату, или он хочет «замочить» подрядчика. Это очень важный момент — в первом случае можно и нужно работать, во втором — оценить риски, потери и продумать возможность выхода из проекта.

Со стороны клиента:

1.  Команда с полномочиями. Крайне важно в проектах построения систем или разработки (и об этом скажет любой учебник, и это прописная истина, в том числе в PMBOK) собрать компетентную команду и наделить людей полномочиями для принятия оперативных управленческих решений и согласования принимаемых проектных решений;

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

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

Про самое важное в проекте для исполнителя — про команду

Хороший менеджер не должен говорить и делать только то, что хочет заказчик, и интересы своей команды надо отстаивать всегда. Ведь, если разобраться, проекты делает проектная команда — люди и человеческие отношения – наше все. Поэтому без лишнего пафоса отмечу, что, несомненно, самый главный требуемый навык РП – умение работать с командой и глубоко погружаться в проект. Это тоже нужно, чтобы пожаров не было.

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

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

Другим классным инструментом, которым в КРОК по мере возможности пользуюсь — тимбилдинги. И это вовсе необязательно замороченное мероприятие типа командной сдачи норм ГТО (хотя и такое было, и это было огонь!). Тут можно и просто собрать команду в неформальной обстановке, пообщаться, поиграть в дженгу и киккер и просто снять таким образом напряжение зума, тимса, вебекса и бесконечных созвонов-созвонов-созвонов… Это работает! Я проверил!

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

Вместо заключения

У меня не было цели описать чудесную пилюлю и раскрыть секретное заклинание о том, как починить любой проект. Универсального лекарства нет, проекты уникальны. Прямо тиражных решений в КРОК очень немного — в основном мы строим сложные, часто уникальные системы для клиентов, глубоко кастомизируя их. За это нас ценят — мы умеем склеить то, что раньше никто не клеил и построить даже кажущиеся безумными решения. Одно в моем опыте работы остается неизменным — это отношения с людьми. РП зарабатывает авторитет не тогда, когда говорит и делает то, что хочет заказчик, а тогда, когда не пасует перед сложностями в согласовании реструктуризации плана проекта и трезво оценивает ситуацию, готов оперативно реагировать на вызовы в проекте, подключать нужные ресурсы. Поверьте, заказчик будет вас уважать, даже если вы нарисуете новый план со сдвигом сроков, но! все эти новые сроки выдержите. РП сказал = РП сделал — вот главная сила и рабочее решение большинства сложных ситуаций.

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