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

Введение

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

Предыстория

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

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

Как это было

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

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

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

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

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

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

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

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

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

Заключение

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

Софт для мозга

"You can't do much carpentry with your bare hands and you can't do much thinking with your bare brain."

- Bo Dahlbom

Введение

Недавно я посмотрел выступление американского философа-когнитивиста Даниеля Деннета под названием "Tools To Transform Our Thinking". В нем он, рассуждая с позиций меметики, представляет наши полезные знания и умения как набор инструментов (или приложений), которыми мы можем пополнять свой арсенал, "скачивая" их у других людей или информационных источников. Это и другие его выступления я рекомендую посмотреть всем, кто заинтересован в науке о сознании.

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

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

Пример от противного

Представьте себе, что разработчик, которому поручили разработку line-of-business системы, проигнорировал реальные проблемы пользователей, не общался с будущими пользователями, не проводил промежуточных демо или пилотов. Все это время он провёл, разрабатывая "по водопаду" очень сложную систему, которая (по его мнению) должна идеально покрыть все пользовательские сценарии. После окончания разработки он установил программу только части пользователей, забыв настроить её под них нужды и обучить использованию системы. Более того, система заточена по Windows, в то время как у пользователей разносортица платформ: Windows, Linux, MacOS, Android. Проведя такое "внедрение" разработчик потерял интерес к проекту и занялся другими вещам. Не в силах разобраться с новой системой, и не видя в ней надобности, пользователи быстро забыли про неё и стали работать по-старому.

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

"Тринадцать шагов к успеху"

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

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

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

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

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

Анализ примера

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

1. Сотрудники не понимали целей внедрения и не видели в новом процессе решения насущных для них проблем. Та же проблема есть и при софтверных внедрениях. Как мы знаем, пользователей и прочих заинтересованных лиц надо активно вовлекать в разработку. Это не только проинформирует о  нововведении, но и поможет учесть интересы всех участников.
2. Был предложен сложный процесс, который было трудно запустить. За один прием разработать и запустить сложную систему тоже непросто, поэтому были придуманы такие методы, как пилотное внедрение, итеративная разработка и внедрение.
3. Информирование и обучение было сделано откровенно на "отвяжись". Мало того, что информирование было очень скудным и разовым, оно даже не покрыло всю проектную команду. Обучение сотрудников - это установка в их мозг новой программы. Внедрение сложной системы - это целый отдельный проект, который нужно планировать и исполнять.
4. Отсутствовала системная работа по сопровождению нового процесса. Новые сложные системы требуют периода опытно-промышленной эксплуатации, чтобы устранить выявленные проблемы и гарантировать работоспособность в реальных условиях.

Заключение

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