Теперь это все твое!

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

Думаю, у многих из вас в практике тоже бывало, когда вы приходите на какой-то проект или продукт – неважно – и не понимаете, что происходит. Это могли делать какие-то другие команды, другие подрядчики. Может вообще не быть документации, особенно если это in-house или какие-то собственные внутренние разработки. Если вы много работаете со смежниками, вам могут подарить в наследство еще какую-то систему не на платформе 1С, и с ней тоже надо будет как-то разобраться.

Три базовых вопроса: что, где и когда

Итак, мы присоединились к какой-то команде, и первое, что нужно сделать, помимо того, что нам сказали: «Беги, туши», – это ответить на три простых вопроса: что у нас, где и когда?

Что? Что мы вообще будем автоматизировать, какое у нас направление? Я взяла несколько кейсов:

• Исполнение закупок,

• Тендерная деятельность,

• Оценка поставщиков,

• Анализ экономики,

• Планирование и прогнозирование заказов поставщику.

Так получилось, что в какой-то момент я стала владельцем продукта всех систем, отвечающих за закупки.

Где это у нас происходит? Тут у нас некоторый «зоопарк»:

• 1С:УТ,

• Kaiten,

• 1С:ERP УХ Корпоративные закупки,

• BI,

• Data Viva.

И когда, на каком мы вообще этапе находимся, что происходит?

• MVP в доработке,

• Рестарт проекта,

• Развитие,

• Разработка и тестирование.

Есть MVP, который в доработке уже почти готов. Рестарт проекта – то есть абсолютно недовольный бизнес-пользователь, который говорит: «Переделайте, все очень плохо». Есть работающие системы на этапе развития. И есть вполне понятный, наверное, аналитику этап – когда мы просто еще разрабатываем, тестируем, и в целом еще можно что-то сообразить.

Для того чтобы дальше понять, что можно делать и что нужно делать, нужно хотя бы верхнеуровнево понимать хоть что-то о проектах и продуктах. Как минимум – из каких этапов могут состоять работы, какие у нас есть технологии внедрения или разработки. Такие вещи нужно верхнеуровнево понимать даже аналитику, просто для того чтобы понимать, какие задачи мы сейчас делаем.

Соответственно, технологии можно погуглить, поспрашивать. Если они есть – это вообще здорово. Если мы сталкиваемся или принимаем, например, работы от in-house, их может и не быть.

Дорожные карты и поиск артефактов

Что помогло мне разобраться, что мы делаем? У нас любят делать дорожные карты. Это must-have. Они показывают и ретро – какие задачи сделали, и что запланировано делать дальше.

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

Матрица стейкхолдеров и описание команды

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

Что мне помогло – нарисовать матрицу стейкхолдеров и описать саму команду проекта. Причем матрицу я составляла не просто спросив, например, у руководителя проекта, кто он и за что отвечает. Очень хорошо помогает метод тихой фасилитации.

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

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

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

Погружение в предметную область и терминологию

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

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

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

Что помогает? Составить глоссарий и верхнеуровнево описать структуру бизнеса, понять, кто за что отвечает внутри компании. И, опять же, учесть момент, что внутри разных подразделений и дирекций может быть абсолютно разная терминология. Как в примере с внешними и внутренними закупками: они же direct и indirect, они же еще ряд других названий.

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

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

Это по-разному оформляется, там разные шаги, разные подразделения, разная документация, а называется абсолютно одинаково. И все очень долго в этом путались, пока мы это нормально не описали.

Бизнес-цели, KPI и мотивация

Следующая вещь, которую обязательно стоит уточнить: какие у нас бизнес-цели? Потому что именно бизнес-цели диктуют нам цели к автоматизации.

Что помогает? Провести анализ KPI и ключевых отчетов. Это прямо всегда лежит на поверхности. Главное – не забыть запросить то, за что людям платят премии, то, что является для них мотивацией. Именно это мы и должны мерить в нашей системе и стремиться как минимум зафиксировать ключевые шаги этих процессов.

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

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

От этого и отталкиваемся. Хотя могут быть и риски саботажа, скажем так, если мы совсем не будем слушать конечных ключевиков.

Описание бизнес-процессов и точек взаимодействия

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

Банальный пример. Опять же, в больших корпорациях это не редкость, когда мы разговариваем о том, что является результатом вашей работы, куда вы его дальше отдаете. А нам отвечают: «Мы его в папочку складываем – и все». А что дальше с этой папочкой происходит? Агентство «Лунный свет» открывай, разыскивай, кто из этой папочки этот документ вообще берет. Особенно если внутри IT плохо коммуницируют или вы пришли со стороны – тут вообще риск никогда не найти.

Здесь все просто: все мы это умеем делать, рисуем схемы процессов. Ходим и настойчиво спрашиваем у всех: «А вы вот это не берете? А вы вот это не используете?»

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

Архитектура, документация и интеграции

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

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

Самое простое – составить диаграмму связей по ключевым объектам, которые привязаны к сквозному бизнес-процессу. Это можно сделать самостоятельно или найти кого-нибудь бодрого, активного, инициативного и попросить помочь.

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

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

Управление рисками и эскалация

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

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

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

Или, например, цели создания системы не зафиксированы. Ее передали: «Развивайте дальше». А зачем? Что нужно делать? Тоже хорошие вопросы.

Очень важно задавать себе хорошие вопросы и не стесняться эскалировать это повыше.

Итоги

Я не боюсь проектов на середине.

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

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

Это чек-лист: что и зачем мы делаем, и что неплохо знать, чтобы это сделать.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.