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

"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. Отсутствовала системная работа по сопровождению нового процесса. Новые сложные системы требуют периода опытно-промышленной эксплуатации, чтобы устранить выявленные проблемы и гарантировать работоспособность в реальных условиях.

Заключение

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