Софт для мозга, ч. 2

Введение

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

Предыстория

В то время я был участником крупного проекта, разрабатывавшего продукт в области ИБ. Проектная команда была большой (десятки человек) и сложно организованной. Она состояла из 10+ подкодмад из которых почти десять писали код. Как несложно догадаться, если такое количество людей коммитит в транк продукта, транк становится очень нестабильным, что мы и имели в полный рост. Наша индустрия уже имеет рецепт борьбы с такой проблемой в виде бранч-плана, подразумевающего разработку и стабилизацию новых фич в отдельных ветках с последущей интеграцией в транк.

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

Как это было

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

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

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

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

Разбор полётов

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

1. Активно вовлекал будущих "пользователей" процесса в его разработку, чем добился понимания ими целей внедрения и учёл их реальные интересы.
2. Применил пилотное внедрение на котором выявил слабые места процесса.
3. После внедрения процесса активно сопровождал его, оперативно решая возникающие проблемы и корректируя.
4. Начал с простого решения, которое по ходу эксплуатации развилось благодаря отзывам и инициативам коллег.

Главной ошибкой считаю попытку сразу завербовать всех заинтересованных лиц до перовых пилотных интеграций. Это серьезно затянуло процесс. Считаю, что правильнее было бы собрать небольшую инициативную группу и с ней попрактиковаться. Тогда было бы проще распространять влияние новых идей на остальных колллег.

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

Заключение

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