Привет! Мы команда сопровождения GlowByte, и мы решаем сложные проблемы. Если проект не хочет брать на поддержку ни одна команда , если с проекта ушли все ключевые сотрудники, если проект бросили разработчики, если на проекте экзотические технологии или же проект захотел отказаться от технической поддержки и порушить все свои бизнес-процессы, то есть отличный повод прийти за помощью к нам. Это история о том, как иностранный вендор бросил крупный проект, о том, как мы пытались протянуть руку помощи, и о том, что мы точно делали НЕправильно.
Хаос проблем
Итак, всё началось с ухода с российского рынка вендора, который предоставлял комплекс ПО по принципу SaaS (ПО как услуга). Вся система была полностью закрытой, никто о ней ничего не знал, не умел поддерживать, управлять и исправлять баги. С такой системой наедине остался один из крупных ритейлеров России. Найти новое решение с ходу – это сложно и больно. Поэтому нашему заказчику понадобилась помощь в поддержке этого “космолёта” до тех пор, пока не случится импортозамещение. Заходить в такой проект как минимум опасно: нет ни документации, ни исходного кода, ни мониторинга. Но зато есть отличные баги, критические для бизнеса проблемы и паникующий заказчик.
Многолетний опыт подготовил нас к приёмке проектов, у которых внедрение проводила команда, которая готова взаимодействовать и общаться. В нашем случае – от команды внедрения уж след простыл, зато осталась закрытая система и большой ком проблем с её работой. Несмотря на сложности, мы смело вызвались помочь, аргументируя свою решительность тем, что имеем опыт работы с подобными технологиями. И... нас завалило заявками в Jira сразу после приёмки. Все они были сложные, часто непонятные.

Отметим, что мы пришли на проект, когда в системе уже начались аварии. Аварией называлось всё, что приводило систему в неработоспособный вид и не решалось, потому что было не понятно, что произошло.
Сама система, как мы упомянули выше, была закрытая, многокомпонентная, со сложными связями этих компонент, а заказчик оказался совершенно не погружённым в техническую часть.
Над заявками днями напролёт работала команда из 5 человек, все закапывались в первоисточниках причин инцидентов, но заявок становилось больше. К тому же каждый накапливал локальный кусочек знаний, формировал собственный опыт, но не обогащал им единую экспертизу.
Поначалу мы не фиксировали промежуточные статусы в заявках, поскольку решили погрузиться в суть и не плодить отписки. Но для заказчика отсутствие комментариев стало выглядеть так, что мы ничего не делаем.
Вдобавок наложились последствия поспешного знакомства с командой заказчика и с подходами к ведению заявок. У заказчика был опыт работы с вендором, который сам предупреждал баги в системе по своим методам мониторинга. У нас же был опыт реакции на инциденты, заведённые в Jira. К тому же мы в спешке не успели обговорить детально, что нужно обеим сторонам в нашем прекрасном взаимодействии.
Так проект сопровождения стал выглядеть клоком запутанной шерсти, где никто не знает, что делать: ни заказчик, ни мы. В выше описанных проблемах мы прожили 3 месяца. Ситуация слишком затянулась, настал момент решительных действий.
Что мы в итоге поняли
Рецепт всех решений кризисных ситуаций обычно складывается из простых ингредиентов: дисциплина, ответственность и структурирование. Всё это соединяется через коммуникацию, видение потребностей заказчика и чёткое понимание интересов, которые защищаешь. Несмотря на очевидность, проектные проблемы не решаются по единому образу и подобию, а на сочетаниях простейшего рождаются такие истории, как эта.
Мы проанализировали сложившуюся ситуацию, создали гугл-док с жалобами, недовольствами, предложениями и пожеланиями к процессу ведения проекта.
Первой проблемой в этом списке стала приёмка проекта. Обычно мы принимаем проект по принципу ITSM/ITIL: заказчику рассказывается, что он может заводить заявки, если встречает в своей системе проблему, а мы должны “решить” заявку и предоставить ответ. В рамках текущего проекта это не сработало, потому что заказчик хотел от нас самостоятельного мониторинга работоспособности системы.
Это привело к тому, что мы не договорились о том, как сопровождать проект, потому и не приняли проект на саппорт нормально. Исполнители заявок ничего не знали о бизнес-смысле системы, логической схеме или архитектуре, зато ориентировались в деталях какой-то из этих частей. Каждый из нас перечитал все заведенные заявки, комментарии и чаты, для дальнейшего эффективного сотрудничества был составлен список вопросов к команде и заказчику о задачах приложения, архитектуре, инфраструктуре, используемых технологиях, а также 3–4 резюмирующих вопроса к каждой заявке, что давало возможность раскрыть суть происходящего внутри системы.
Ретроспективно мы поняли, что погружаться в запутанные проекты с непонятными технологиями стоит по чек-листу, сформировали концепцию, в которой проект разложили по частям на технологии и составили список вопросов к интеграциям на на них, провели ряд встреч по закрытию этих вопросов. В результате мы сформировали верхнеуровневую архитектурную, логическую и инфраструктурную схему, наработав таким образом “артефакт” приёмки проектов на новых технологиях.
Кстати, ещё одной нашей проблемой было то, что мы не коллекционировали свои знания по погружению в проект. Мало кто любит писать документацию и наполнять базу знаний, часто эта задача воспринимается как факультативная при наличии внушительного количества открытых заявок. Однако отсутствие централизованного знания системы априори делает проект тяжеловесным и неповоротливым, зависимым от конкретных исполнителей и не масштабируемым. Потому мы пришли к правилам и регламентам, разработали структуру, согласно которой по 3–4 резюмирующим вопросам к заявке надо было написать инструкцию, причём на написание ставились дедлайны.
Очень важно было, чтобы инструкции в базе знаний отвечали на вопросы: что это и как это делать. Все документы проходили модерацию и заносились модератором в базу знаний. Так, по сути, мы “наработали” инструмент ведения базы знаний, который стал намного эффективнее, чем добровольное согласие людей писать инструкции.
Конечно, можно подумать, что заставить кого-то писать инструкции, пока у него завал в проектных задачах, – плохая идея. Но это сработало, потому что была решена ещё одна проблема – мы изначально неправильно распределяли заявки и не строили таймлайны на день. В условиях большого количества открытых заявок ошибочно казалось, что не эффективно команде самостоятельно и хаотично планировать своё время, сбивалось понимание о приоритетах, один исполнитель мог делать несколько критических заявок, а другой – одну, но долгую, с низким приоритетом. Хранителями экспертизы были одни и те же люди, и если по технологии, в которой разбирается лишь один человек, приходила новая заявка, то она автоматически падала на него, даже если у него и без того завал.
Итак, мы стали проводить регулярные дейли статусы, на которых обязательно обсуждали, что каждый из исполнителей сможет сделать за день, составляли план приоритетов задач, обсуждали, что удалось и не удалось сделать за прошедший день. Если что-то отклонялось от плана, то за этим было легко и удобно следить и принимать решения. В этот же таймлайн задач мы внесли обязательное регламентное наполнение базы знаний. Всё это позволило команде быть постоянно в курсе проблем на проекте, что повысило в дальнейшем эффективность принимаемых решений.
Мы выработали структурированный подход к ведению внешних и внутренних встреч, регламент слежения за прогрессом и безрисковое управление ходом ведения инцидентов. По сути, мы внедрили Agile-подход.
Отдельной глобальной проблемой проекта была грусть в коммуникации с заказчиком. Если нам что-то нужно было от него (доступы, ответы на вопросы), эти запросы зависали без движения, ничего не решалось. А если у заказчика были недовольства к нам, то они, как правило, доходили только через эскалацию. Мы решили больше разговаривать. Назначили регулярные встречи, на которые приходили представители всех команд заказчика, структурировали повестку и стали вести статусы. В повестку обязательными пунктами внесли критические вопросы и обсуждение статуса каждой проблемы с ранжированием по приоритетам.
Что мы ещё делали не так? Верных акцентов в решении заявок. Как пример, для критического инцидента было найдено обходное решение, и он сам перестал быть критичным, но мы продолжали искать первопричину ошибки, откладывая временно в сторону дефекты, которые хоть как-то аффектили на систему. После осознания происходящего мы стали больше внимания уделять решению проблем и не закапываться в технических безднах инцидентов.
Делегировать надо правильно
С приходом на проект мы заметили, что многие задачи имели абстрактное описание, но не предполагали абстрактного решения. Когда команда не знала, как решить задачу и с чего начать, в ход шли проверки всех теорий и гипотез, и, в конце концов, это приводило к тому, что уже было не ясно, что проверять. Наступала тупиковая ситуация. За заявку брался другой исполнитель и проверял добрую половину уже проверенных гипотез. Мы пришли к выводу, что пора выбираться из такого тупика. Стали обсуждать на встречах шаги решения проблемы, включая гипотезы её возникновения, параллельно ведя протокол того, что и кому нужно сделать. Причём шаги должны были быть декомпозированы так, чтобы трудозатраты на выполнение одного из них были не более 4 часов.
Также мы по максимуму избавились от абстракции и поставили подзадачи с чётким результатом на выходе. Это всё дало возможность более последовательно и быстро начать “решать” треки и в случае необходимости наглядно видеть, какие технические ресурсы ещё нужно привлекать для решения.
Армия в рабочих процессах
Как было упомянуто выше, дисциплина является важным обстоятельством нивелирования рисковых ситуаций. Мы стали вести проект с ориентиром на измеримые показатели (наличие комментариев в Jira, прогресса по решению заявок у каждого исполнителя, обходного решения в сроки), более тщательно планировать загруженность команды с детализаций до одного дня. Если у кого-то не получалось выполнить установленный объём работы за день, обсуждали блокирующие вопросы и помогали друг другу их решить. Проводили ежедневную общую встречу, где актуализировали статусы своих задач.
Если вам кажется, что армейская дисциплина может убить все рабочие процессы в подобного рода ситуациях, то это не так. Баланс между бюрократией и полной анархией решается правилами и регламентами действий для каждого. Когда понятно, какой процесс, для чего и как работает, – всё идёт легко. Более того, технические специалисты работают эффективнее, когда им не нужно заниматься менеджментом.
Итак, дисциплину мы отдали тимлиду, а радость от решения технических задач – команде.
Коммуникация "достать мёртвого"
Заказчик, не отвечающий вовсе или отвечающий не вовремя, – типичная ситуация, с которой можно столкнуться на проекте.
Когда входишь в проект, многие вопросы, такие как доступ к приложениям и компонентам, обратные уточняющие вопросы по заявкам, являются острыми и актуальными для продвижения решений инцидентов вперёд. Если заказчик медленно отвечает или не отвечает вообще, то коммуникация в стиле “достать мёртвого” – вполне себе действенный способ. Найти 33 способа переспросить и апнуть один и тот же вопрос разными словами и разным эмоциональным окрасом ожидания и при этом не достать окончательно заказчика – не просто, но очень эффективно. Зачастую это помогает отодвинуть проект подальше от кризисной черты.
Так общаться всегда не просто, и не каждый готов это делать, но результат не заставит себя ждать. Такая же коммуникация работает и в обратную сторону, когда на стороне команды исполнителей происходят торможения. Благодаря такому стилю общения становятся лучше видны проблемы обеих сторон.
Анализируя проблемы одну за одной, мы пришли к решению каждой путём чёткого структурирования процессов и применения техник Agile. Тем не менее поддержка – это не та сфера, где подход управления проектами в стиле команд разработки уместен всегда. Это связано с тем, что инциденты систем – слабо прогнозируемое явление. Наработав экспертизу в особенностях проекта, создав паттерн приёмки нетипичного проекта на сопровождении, сформировав базу знаний, на выходе мы получили (почти) классический стиль ведения проектов сопровождения. Подход стал работать сам на себя и планомерно развиваться. Целевой процесс не потребовал плотного курирования, отдельно выделенного на фуллтайм менеджера и такого большого количества исполнителей. Мы сократили расход ресурсов, нормализовали управление и вывели проект на стабильный уровень.
Итак, несмотря на то, что история этого проекта изначально не предполагала иметь счастливый конец, happy end всё же случился. После ряда масштабных манипуляций в менеджменте проекта мы добились того, что поддержка проекта встала на устойчивые рельсы, команда начала успевать выполнять свою работу, а у заказчика перестали простаивать важные бизнес-процессы. Ключевое – дальнейший менеджмент проекта стал поддерживать сам себя: были выработаны паттерны ведения проекта, обязательные условия и поручения, которые обеспечили проекту длительную жизнь без привлечения кризис-менеджеров.