воскресенье, 11 октября 2015 г.



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

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

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

В чем тут польза для меня? Дело в том, что по роду своей работы я постоянно так или иначе веду переговоры с коллегами. Собственно, вся работа менеджера - это коллективное решение проблем с привлечением своих коллег в качестве партнёров (а иногда и оппонентов). Можно сказать, что я постоянно занят тем, что "продаю" свои идеи коллегам, а они продают свои идеи мне. 

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

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

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

Будьте здоровы :)


среда, 30 сентября 2015 г.

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

Введение

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

Предыстория

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

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

Как это было

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

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

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

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

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

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

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

Заключение

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

понедельник, 28 сентября 2015 г.

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

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

Заключение

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

четверг, 13 августа 2015 г.

How to turn Ideas into Reality, by GEN David Perkins



Посмотрел пару дней назад выступление генерала Дэвида Перкинса с необычным для военного темой: "Как сделать идеи реальностью". Перкинс руководит TRADOC - организацией, которая разрабатывает доктрины и программы подготовки для армии США. В каком-то смысле, быть реформатором - его профессия, потому что его работа - предлагать и внедрять новшества.

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

1. Основная причина неудач внедрения - отсутствие системного подхода. Люди пишут документы, кладут на полку и думают, что само получится. (Очень напоминает некоторые процессные внедрения, которые я видел)

2. Вместо того, чтобы разделять достижимые результаты внедрения по временной перпсективе (кратко-, средне- и долгосрочные), предлагает разделять их по затрате ресурсов и вовлечению "эшелонов". 
По измерению ресурсов: 
    1. Что мы можем сделать прямо сейчас с тем, что у нас есть?
    2. Что мы можем сделать, не изменяя существенно утвержденные планы или орг. структуру?
    3. Что мы можем сделать, если добьёмся выделения крупных ресурсов и/или изменения в организации

По эшелонам (как он приводил пример):
    1. У себя локально (т.е. в армии)
    2. С привлечением комитета конгресса.
    3. С привлечением конгресса и изменением законодательства.

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

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

Собственно, видео:


воскресенье, 19 июля 2015 г.

Визуализация прогноза как инструмент общения с заказчиком

Как известно, разработка софта была бы намного более приятным делом, если бы в ней не были замешаны пользователи и - герои статьи - заказчики. Все проблемы от них:

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

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

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

Теория

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

Здесь на вертикальной оси отложено содержание бэклога, а на горизонтальной - время. Верхний левый угол - это нулевое содержание с плановой сдачей сейчас. Движение вниз увеличивает содержание, движение вправо - количество оставшегося до релиза времени. Каждая точка на этой плоскости - конкретное решение <Содержание, Время>. Очевидно, что не все варианты являются реалистичными для нашей команды. Чтобы понять, что и за какое время мы успеваем сделать, применяется метод эмпирического прогнозирования, описанный выше. Этот метод позволяет рассечь эту плоскость на три области:
  1. "Зеленую зону" - решения из этой зоны попадают в зону возможностей команды даже при пессимистическом варианте развития событий.
  2. "Красную зону" - решения из этой зоны заведомо превосходят возможности команды даже в оптимистическом сценарии.
  3. "Конус неопределенности" - решения, находящиеся в конусе, возможны при оптимистическом варианте развития событий и невозможны при пессимистическом.
Хотя концепция неопределённости будущего и вероятностного характера планирования не нова, на практике ответ "не знаю" является некоторым табу, а фразы "скорее всего сделаем" или "наверное не успеем" часто округляются до "да" или "нет". Я считаю, что неопределённость будущего должна быть явно выражена в прогнозах, потому на диаграмме присутствует конус неопределённости. Как именно получить оптимистически и пессимистический варианты прогноза - тема отдельной статьи. Пока просто примем, что менеджер применяет какой-то метод.
Применять эту диаграмму можно для получения ответа на два принципиальных вопроса:
1. Что мы успеваем к выбранному сроку в оптимистическом и пессимистическом сценариях?
2. К какому сроку мы можем завершить выбранный объем работ в оптимистическом и пессимистическом сценариях?

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

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

Практика

Как на практике я применяю этот подход? Хотя принципы построения диаграммы исключительно просты, строить и перестраивать её вручную нельзя: это убивает важное преимущество - интерактивность процесса поиска решения. Полноценной программы, которая бы это автоматизировала, я пока не сделал, но добился некоторых результатов в Excel. Первый прототип был сделан исключительно на формулах, но он был неудобен в использвании. Второй прототип использует несколько простых макросов (всего 126 строк).

Для получения картинки необходимо заполнить параметры "Average velocity" и "Velocity variation" (слева сверху), а так же заполнить таблицу бэклога работами с оценкой их трудоёмкости. После этого кнопка "Пересчитать" вызывает макрос, которой заполняет цветную диаграмму справа. Цифры в диаграмме - побочный артефакт работы макроса и ничего особенного не означают.



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

Эту табличку я приношу на встречу с заказчиком, где при необходимости даю пояснения о том, что это за метод и как мы этим можем воспользоваться. После этого начинается интерактив: перетасовка работ в бэклоге, перерасчёт прогноза, размышления о переносе сроков. Наглядность таблицы и возможность "играть" с бэклогом ("а что если мы сделаем вот так? Хм...") облегчает процесс поиска решения и делает его однозначно понятным обеим сторонам.

Ограничения инструмента

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

Заключение

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


четверг, 9 июля 2015 г.

"О стеклянном потолке" или приложение Теории ограничений к профессиональному развитию.




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

Может быть, дело в тебе

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


Почему так происходит? Хорошее объяснение можно найти в Теории ограничений Элияху Голдратта. Простое объяснение звучит так: производительность системы ограничивается её узким местом (т.е. её ограничением). Если это узкое место расширять, то производительность будет расти, но лишь до тех пор, пока это место не перестанет быть узким. Тогда будет какое-то другое узкое место, и работы по расширению прошлого узкого места потеряют смысл.


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

Это, конечно, упрощённая модель. У человека не может быть одного ограничения, которое во всех ситуациях мешает ему работать. В зависимости от ситуации человек может упираться в разные ограничения, но общая тенденция сохраняется. По мере развития технических навыков он чаще начинает упираться во что-то другое.

Но если работа программиста - писать программы, то что же такое его может ограничивать кроме, собственно, умения программировать? Судя по своему личному опыту, я могу привести такие примеры:
  • Личная несобранность и неумение организовать свою работу.
  • Неумение доносить свои мысли до коллег и воспринимать их идеи.
  • Неумение конструктивно решать конфликты точек зрения между коллегами.
  • Неконструктивное восприятие критики.
  • Неумение планировать и исполнять долгосрочные проекты в условиях отвлечения текущими проблемами.
  • Излишне оптимистичное мышление.
  • Отсутствие системности в решении проблем.
  • Невнимательность к деталям.
  • Непонимание бизнеса, в котором я работаю.
  • Неспособность взглянуть на проблему глазами заказчика или пользователя.


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

А может быть, и не в тебе

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

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

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

Что это означает на практике? Если хочется безудержного роста и развития, то следует хорошенько задуматься о своём месте в компании. Где в данный момент у компании узкое место, и где в данный момент находишься ты? Если ответы на эти два вопроса не совпадают, то надо либо менять своё место в компании, либо менять компанию.

Заключение

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

Побочным выводом является то, что человека можно рассматривать как мини-бизнес и применять к нему те же подходы, что и к "настоящему" бизнесу.

пятница, 17 апреля 2015 г.

Конференция SkillsWiki: .NET-разработчик глазами работодателей России и зарубежья

Регистрация на бесплатную конференцию SkillsWiki: http://ift.tt/1PR7Cie. Бесплатная конференция сообщества SkillsWiki о профессиональном развитии 29 апреля 2015 года в гостях у B2B-Center Вы разработчик? Часто задаетесь вопросами профессионального развития, к примеру, как стать ведущим или архитектором? Как расти по карьере? Как зарабатывать больше? Вырастет ли моя зарплата после изучения новой технологии? Какие…

пятница, 3 апреля 2015 г.

IoC в руководстве. Несколько мыслей, пришедших ко мне в голову.

Когда я готовил предыдущие три статьи, я наткнулся на любопытную картинку. Она была в публикации, посвящённой командованию и контролю ("Command & Control", C2). Я её тогда не понял. На ней были изображены направления "командования" и "контроля" в директивном методе управления и управлении по целям:

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

Собственно, ровно это и нарисовано на картинке. В левой части нарисованы отношения с руководством в стиле "начальник обеспечивает пинковую тягу", а в правой "мне поставили цель, теперь я сам всех достану". Принципиальная разница в том, как именно осуществляется контроль. В директивном подходе начальник выступает как автором конкретных инструкций для исполнителя, так и "автором" контроля. Обычно он принимает форму регулярных отчетов или встреч, которых исполнитель по возможности старается избегать. При управлении по целям именно исполнитель ищет решение, он же является "автором" механизма контроля. Контроль осуществляется в виде обратной связи от исполнителя.
По сути это есть ни что иное, как реализация принципа Inversion of Control в руководстве. Программисты поймут :)
Окей, этому продвинутому методу руководства уже спето достаточно дифирамбов (дифирамб? не знаю:)). Все ли так тут просто? Может нам всем броситься руководить исключительно таким образом? Не всё так просто. Такой стиль управления очень требователен к обеим сторонам делегирования.

Вот фрагментарный (анти)портет человека, который может работать по таким принципам:

Хорошо Плохо
Отказывается принимать в работу плохо или нечётко поставленные задачи. Добивается от руководства их прояснения или сам предлагает варианты их проработки.
Что сказали, то и делает.
Сам ищет способы и  возможности достижения цели, предпочитает иметь свободу и ответственность принимать решения.
Ждет, что ему скажут, что делать. Избегает ответственности. Популярная отмазка "а мне не сказали, что это надо" или "сделал, что просили, чего ещё надо?"
Развивает сеть горизонтальных связей со всеми заинтересованными лицами для обмена информацией и координации усилий
Предпочитает всю информацию и координацию получить по вертикальным каналам
Сам создаёт петли обратной связи для получения регулярной критики своих действий. Понимает, что это не всегда приятно, но необходимо для успеха.
Критику не любит и избегает, воспринимает болезненно ("работать мешают!"). По возможности старается не привлекать лишнего внимания к своей работе. 
Обладает собственными принципами, служащими внутренним источником дисциплины и контроля
Контроль и дисциплина имеют внешнюю, принудительную природу.
Доверяет коллегам, способен положиться на них. Пользуется заслуженным взаимным доверием.
Считает, что без внешнего контроля и принуждения коллеги ничего полезного не сделают

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

Несложно заметить, что в правом столбце описан... инфантильный человек. Все эти примеры поведения абсолютно естественны для определенных этапов развития человека и по мере развития и взросления заменяются на их антиподы из левой части таблицы. Накладывая эту (ну ладно, не эту, а более продвинутую) матрицу на человека можно определять степень зрелости человека и его готовность к получению большей свободы и ответственности. 
Тут уместно вспомнить про теории X- и Y-менеджмента. Обычно говорят, что Х-менеджеры плохие, давят инициативу у сотрудников и вообще олицетворяют собой зло. Но Х-менеджмент - это не просто привычка конкретного менеджера, это культура, которая охватывает многих людей. Есть Х-менеджеры и Х-подчиненные. Наивная попытка работать методами Y-менеджмента с Х-подчиненными приведёт к плачевным последствиям.
Попытка делегировать больше, чем человек способен "переварить" на своём уровне зрелости, безответственна со стороны руководства. Идею об уровнях делегирования я впервые явно увидел у Юргена Аппело в его книге "Менеджмент 3.0", но до сих пор не мог для себя сформулировать критерий выбора. Такая ролевая модель может стать практическим инструментом для принятия такого решения. 


вторник, 24 марта 2015 г.

MCDP: Скорость


Введение.

В предыдущих двух статьях я рассказал об общей философии руководства и о подходе к планированию, принятым в Корпусе морской пехоты США.  Эта заметка завершает цикл, и в ней я хочу поговорить о скорости. Феномен скорости описывается в 4-ой главе статьи "MCDP 1-3 Tactics".  В современной маневренной войне скорость - это ключевое преимущество, необходимое для победы. Задача любого военной организации быть быстрее, чем противник, чтобы захватить инициативу, застать противника врасплох. В конкурентном бизнесе, да и в любом проекте с дедлайном, скорость тоже - необходимый фактор успеха.

Что такое скорость? Понятие скорости более емкое, чем, собственно, скорость передвижения войск по местности. Танковый батальон, который заправляет свои машины за час, быстрее, чем тот, который тратит на это два часа. Моторизованная часть, которая может пройти пятьсот километров без поломок быстрее той, которая может пройти лишь двести. Подразделение, которое способно развернуться из маршевого построения в боевое за пять минут быстрее того, которое тратит на это десять. Звено самолетов, способное совершить пять вылетов за сутки быстрее того, которое совершает только три. Дивизия, штаб которой тратит на обработку новых разведданных и изменением планов час быстрое той, у которой штабу требуется два. Полк, который сам принимает решение об изменении направления удара быстрее того, который ждет для этого решения штаба дивизии. Рота, чей командир способен в бою договориться с соседними ротами о плане совместных действий за минуту, быстрее роты, чьему командиру требуется на это пять минут.

На войне все очень просто. Но самое простое оказывается наиболее сложным.
- Карл Клаузевиц

Карл Клаузевиц писал, что на войне вещи, простые в теории, совсем не просты на практике. Причины этой сложности две - трение ("friction") и туман войны ("fog of war").

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

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

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

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

В разработке мы сталкиваемся с тем же трением и неопределённостью, с которыми уже давно учатся бороться военные. Может быть их рецепты окажутся полезными для нас?

Стать быстрее

Какие методы повышения скорости предлагаются в описываемой статье?

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

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

2. Децентрализация и управление по целям.
Краеугольный камень всей философии управления, на котором строятся методы руководства и планирования. Децентрализация позволяет сократить цикл принятия решения, который активизируется при изменениях в обстановке. Военные называют его цикл "OODA" (Observation, Orientation, Decision, Action). Чем чем больше людей задействовано в этом цикле, чем сложнее правила его регулирующие, тем дольше он будет проходить. Чем более централизованная система, тем уже зона самостоятельности у каждого уровня, и "выше" по иерархии эскалируется каждая проблема.

Например, планировалось сделать систему диагностики ошибок. Неожиданная проблема привела к тому, что пользовательскую историю нельзя выполнить так, как задумано изначально. В централизованном цикле исполнитель не обладает правом принятия решения и качественным пониманием цели (как это описано в статье про планирование), поэтому вопрос эскалируется до product owner`а. Если он перегружен или недоступен, то реализация может быть заблокирована. 

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

3. Горизонтальные коммуникации ("lateral communications")
Очень тесно связанная с предыдущим пунктом тема. Если изменения в планах затрагивают соседние подразделения, то запрос к ним может пойти либо через начальство (вертикально), либо напрямую (горизонтально). В описанном примере, может потребоваться дополнительная работ от дизайнеров, которым надо будет перепроектировать интерфейс. Вместо того, чтобы "забрасывать" им новую задачу через руководство, можно привлечь их напрямую. 

Другой пример - информация. Нет нужды пускать важную для "соседей" информацию через начальство. Если я узнаю что-то, что может оказаться полезным знать моим коллегам из смежного отдела, я рассказываю им об этом сам. Как это ни удивительно, но я несколько раз встречался с попытками ограничивать передвижение информации формальными (обычно - вертикальными) каналами.

4. Неявные коммуникации ("implicit communications")
Совещания, на которых принимаются решения - это потеря времени. Как можно их избежать? В хорошо слаженных командах люди знают, что друг от друга ожидать в разных ситуациях. Им не надо каждый раз проговаривать это явно. Как этого можно добиться? Стандартизация подходов и процедур, общее понимание цели и задачи, срабатывание позволяют сократить коммуникации, т.к. люди и так знают, что друг от друга ожидать в разных ситуациях. Тренировки и множество инструкций и уставов существуют именно для того, чтобы снизить трение и ускорить выполнение процедур, а не для того, чтобы замуштровать людей до потери творческого мышления.

Хорошим примером из нашей области является практика внедрения стандартов: стандарты кодирования, definition of done, процедуры и процессы, ролевые модели, уставы проектов. Здесь, главное, не перегнуть палку. Слишком сложные стандарты и процедуры сами собой становятся источником трения: либо они приводят к итальянской забастовке, либо просто игнорируются и перестают приносить пользу.

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

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

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

7. Хорошая умственная и физическая форма.
Здесь сложно что-то добавить. Хорошая форма позволяет дольше оставаться сосредоточенным и активным.

Заключение.

Этой заметкой я завершаю цикл "военных" статьей в моем блоге. В своих статьях я рассказал о том, что мне показалось интересным: о том, как люди из совершенной другой области решают проблемы, удивительно похожие на наши, и о том, как они это делают. Читая заметки из цикла Marine Corps Doctrinal Publication я почерпнул лично для себя несколько полезных идей, которые стал применять на практике. Однако я не призываю бросать всё и бежать читать эти статьи в поисках управленческой мудрости. У нас есть много своих хороших книг, в которых описаны те же самые принципы и идеи. Главное - ощутить необходимость учиться и развиваться.

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

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

среда, 11 марта 2015 г.

MCDP: Планирование


"Ни один план не переживает встречи с противником."
- Хельмут фон Мольтке

"При подготовке к бою, я всегда понимал, что планы – бесполезны, а планирование – бесценно".

- Дуайт Д. Эйзенхауэр

Введение

В первой статье я описал философию управления Корпуса морской пехоты США. В этой хочу поговорить о тесно связанном с этим явлении - планировании.

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

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

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

В доктрине КМП США "планирование" - это развитие понимания ситуации коллективом вовлеченных людей. Конкретный артефакт на выходе - план - это побочный результат планирования. Главный результат - глубокое и единое понимание ситуации, цели и подхода у всех участников. Это очень важная мысль, я её повторю:
Главный результат планирования остаётся в голове, а не на бумаге.
То, что остаётся в голове у участников планирования позволит им быстро создавать новые согласованные планы по мере необходимости, когда первая версия плана устареет (т.е. сразу после начала его исполнения; иногда - до). То, что в КМП США понимают под "планированием", в нашей епархии называют "problem-solving" и "vision building". Из этого следует важный вывод - нельзя планировать для других. Листочек с планом передать можно, а знание в голове - нет. Те, кому предстоит исполнять планы должны участвовать в их разработке.

Понятие "план" определяется просто - любой артефакт, возникший в результате планирования.

Что у нас?

В нашем деле ситуация очень неоднородная. Медиапространство насыщенно идеями гибкой разработки, которые пропагандируют адаптивность. В зависимости от взглядов конкретного человека идея планирования наперед может либо полностью отвергаться, либо приниматься так, как описано выше. На практике же наш менеджмент обожает "твердые" линейные планы: мол, вы подпишитесь кровью, что сделаете систему за год, а я потом с вас буду за это по всей строгости спрашивать. Особенно комично это выглядит, когда финальные требования проясняются примерно к дедлайну. Или когда проект уже затянут по срокам в четыре раза (кстати, реальный случай).

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

Содержание плана.

Согласно "MCDP 5 Planning" план содержит в себе описание:
  1. Желаемого результата.
  2. Организованных в пространстве и времени действий.
  3. Задействованных ресурсов.
  4. Процесса контроля и обратной связи.
Интересны первый и последний пункты. О них забывают, сводя план к "кто что делает". 

Описание цели, ожидаемого результата - ключевая часть плана. Она направляет людей, когда им нужно принимать не заложенные в план решения. В публикациях уделяется внимание описанию того, какой должна быть постановка цели. Функция цели - направлять инициативу подчиненных. Цель должна быть широкой ("general"), чтобы оставлять свободу принятия решения. Она должна описывать "что", а не "как". При этом цель не должна быть туманной ("vauge"), она должна быть достаточно конкретной, чтобы ориентировать подчиненных. Хорошо сформулированная цель позволяет оценить степень достижения цели и стать инструментом оценки решения.

Процесс контроля и обратной связи необходим, чтобы понимать, актуален еще план или уже нет. Хороший план имеет в себе механизм коррекции себя. Этот механизм представляет собой зафиксированные ожидания о нормальном исполнении плана, действия по проверке этих ожиданий и действия на случай нарушениях ожиданий ("переходим к плану "Б").

Что у нас?

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

Когда количественные оценки есть, то достаточно неплохо работают пропагандируемые Scurm`ом механизмы отслеживания статуса: диаграммы сгорания и стандартный набор метрик (скорость, фокус-фактор). Главная беда в том, что редко такие планы составляются на горизонт дальше одной итерации, что приводит к удивительной картине: проваленный релиз при идеальных итерациях.

С постановкой целей сложнее. Если о цели заявить не забывают, то формулируют её обычно так: "сдать релиз к концу июня" или "провести 15 ноября демо заказчику". Такая формулировка мало что поясняет кроме срока, по мере приближения к которому градус истерики будет нарастать. Она не содержит критерия, который позволит принимать правильные trade-off-решения в условиях, когда ограничения не позволяют сделать всё так, как планировалось изначально, т.е. изменить план.

Иерархия планов.

Хаос войны естественным образом ограничивает возможность детально планировать наперед. Чем дальше горизонт планирования, тем более общие планы получаются на выходе. В статье предлагается такая иерархия планов:
  1. Ориентация ("orientation planning") - общий уровень планирования, имеет дальний горизонт и низкую детализацию. На этом уровне планирования проясняются цели и подходы к их достижению. 
  2. Планирование вариантов ("contingency planning") - промежуточный уровень. На этом уровне создаются и оцениваются альтернативные варианты действий по достижению цели. На обеспечение будущих вариантов уже могут выделяться силы и средства, но существенно меньше, чем для следующего уровня планирования.
  3. Конкретный план ("commitment planning") - близкий по времени, детальный уровень планирования. Выбирается, прорабатывается и исполняется один вариант, на которые выделяются основные силы.

Что у нас?

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

Связность планов.

MCDP 5 вводит понятие "связности плана" ("plan coupling"). Это понятие знакомо программистам и означает вероятность, что изменение в одной части плана повлечет изменения в другой. Сильносвязные планы называются "интегрированными" или "синхронизированными", слабосвязные - "модульными". Нельзя сказать, что одни лучше других. Выбор между модульным и интегрированным планом - это выбор между снижением риска и повышением эффективности использования ресурсов.

Тем не менее, военные любят именно модульные планы. В MCDP 5 дана общая рекомендация - применять модульные планы, если только ограничения ресурсов не вынуждают обратного. Трение и туман войны похоронят любой план. Если план будет интегрированным, они похоронят его целиком. Придется переделывать его полностью с потерей самого ценного - времени и скорости. Это создает риск провала, который сведет на нет попытки оптимизировать за счет интеграции. Модульный план в похожей ситуации потребует переделки части плана. Благодаря этому модульные планы более устойчивы к трению и неожиданности, они проще и быстрее адаптируются к неожиданным поворотам событий. Они способствуют ускорению реакции, что укладывается в принятую в Корпусе морской пехоты философию управления.

Что у нас?

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

Удивительно, но при таком богатом теоретическом багаже из обеих школ вопрос зависимостей на практике решается достаточно плачевно. Как только появляется несколько разных команд и отделов, которые надо координировать, у менеджера начинает распухать голова и он начинает проводить большую часть своего времени в челночных забегах по отделам или на синхронизирующих совещаниях. Отсутствие систематического применения "тяжеловестных" инструментов для управления зависимостями накладывается на неспособность обеспечить модульность планов (опять попытка усидеть на двух стульях и провал между ними). Это подводит нас к следующей теме.

Организационное планирование

Не всякая организационная структура допускает модульное планирование. Методы организации и методы планирования тесно связаны между собой. 

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

У каждого вида структур есть сильные и слабые стороны. Кроссфункциональные структуры с автономными единицами позволяют планировать модульно и освободить руководство от необходимости координировать действия отделов. Но функции в них "распылены" по всей системе, и при необходимости их концентрированного применения возникают проблемы. Специализированные структуры позволяют сфокусировано применить функцию на одном объекте, но требуют координации.

Как решается вопрос с распределением функций у военных? Посмотрим организацию мотострелкового батальона на БТР в разрезе распределения противотанковых возможностей. Каждый батальон состоит из трех рот, каждая рота из трёх взводов. В каждом взводе есть своё противотанковое оружие - РПГ. Каждый взвод является "универсальным" в том смысле, что сочетает противопехотную и противотанковые функции. Но в каждой роте помимо  помимо трёх "универсальных" взводов есть специализированное противотанковое отделение. На батальонном уровне картина повторяется: батальон имеет три "универсальные" роты плюс специализированный противотанковый взвод. Получается своеобразный организационный фрактал. Командир на каждом уровне может воспользоваться гибкостью и модульностью, которую дают "универсальные" подразделения, и в то же время усилить танкоопасное направление специализированным подразделением.
Концепцию автономных войсковых соединений успешно применили немцы во время Второй мировой войны. Они создали оружие блицкрига - танковую дивизию Вермахта. Она имела свои танки для удара, свою мотопехоту для закрепления на захваченных рубежах, свою самоходную или моторизованную артиллерию для огневой поддержки, свой зенитный батальон и свой моторизованный обоз. Такая структура позволяла дивизии самостоятельно решать задачи оперативного уровня, не завися от других частей. Именно такая структура дивизии, а не чудо-танки или чудо-пушки, определили успехи немцев в первом периоде войны. На нашем профессиональном арго танковую дивизию Вермахта можно было бы назвать "гибкой кроссфункциональной командой, нацеленной на достижение результата". 

Что у нас?

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

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

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

Такая структура не позволяет иметь модульные планы. У руководителя главной головной болью становится координация усилий и выравнивание возможностей отделов. Помню, как один директор мне рассказывал, что менеджер проекта должен досконально знать, какой программист что программирует, и какой тестировщик что тестирует, чтобы на корню пресекать любую рассинхронизацию и самодеятельность (обратите внимание, как это замечательно с точки зрения управления по целям). Если в команде проекта пять человек, это нормально, но в том проекте их было полсотни.

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

Некоторые подвижки есть. Например, Антон Волков на AgileDay'13 в своём докладе рассказывает как раз о трудностях функциональной структуры и непростом опыте перехода к проектной схеме организации. Там же он говорит и о том, как упростилась его жизнь с переходом к управлению по целям и модульному планированию.

Заключение

В этой статье я дал выборочный обзор того, как в КМП США смотрят на планирование и как с этим обстоит дело у нас. Естественно, рассказ охватил лишь о несколько заинтересовавших меня аспектов планирования. Для более полного понимания вопроса следует прочитать соответствующую статью из цикла публикаций - "MCDP 2 Planning"

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

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

В следующей статье я хочу осветить вопрос скорости: что это такое, от чего она происходит и как добиться её повышения.

пятница, 6 марта 2015 г.

MCDP: Философия управления



Вступление

Военная история и варгейминг - мои хобби. Недавно я прочитал публикации из серии Marine Corps Doctrinal Publications (MCDP). Это набор статей, в которых излагаются основополагающие подходы, принятые на вооружение в Корпусе морской пехоты США. Я не планировал найти что-то за пределами моего хобби, но оказалось, что там затрагиваются такие вопросы, которые интересны мне и с профессиональной точки зрения. Ключевые идеи, заложенные в них, не потрясают новизной или оригинальностью. Тем не менее,  я посчитал эти статьи интересными, так как в них даётся очень простой и конкретный понятийный аппарат, описывающий вопросы управления, планирования и оптимизации операций. Сказать по правде, у меня сложилось такое впечатление, что там простыми и понятными словами описано то, что мучительно открывают и пытаются рассказать миру сторонники agile.

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

Всего я планирую написать три статьи:
  1. Философия управления.
  2. Планирование.
  3. Скорость.

Философия

Война хаотична и непредсказуема, этим она и трудна. Есть две крайних подхода к объяснению ее природы: детерминистический и вероятностный.

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

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

Корпус морской пехоты США твердо придерживается вероятностного взгляда на войну, и это определяет подходы ко всем аспектам его жизнедеятельности.

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

  1. Бизнес без консультации с разработчиками подписывает контракт.
  2. Составляется План, зачастую без количественной оценки. Очень быстро он теряет связь с реальностью и забывается. 
  3. Кодим-фиксим-кодим-фиксим.
  4. Ближе к дедлайну руководство почти случайно видит систему и устраивает разнос, так как всё не так, как надо.
  5. Кодим-фиксим-костылим-кодим-фиксим-костылим, но теперь по выходным.
  6. Кое-как отчитываемся по контракту, с замиранием сердца ожидая, когда клиент первый раз потыкается в систему.
  7. ... PROFIT??? 
И всё это под флагом Scrum`а. А под капотом старый добрый принцип "копаем от забора и до обеда".
"Agile is like teenager sex. Everyone wants to do it, many say they’re doing it, only some actually are, and very few are doing it right."


Управление

Как сделать децентрализованную систему управляемой? Определяющее свойство такой системы - распределение ответственности за принятие решений по всем уровням. Чтобы  дать подчиненным свободу для проявления инициативы, но при этом оставить их действия согласованными, применяется два метода:
  1. "Mission order" -  ставить подчиненному цель, а не давать инструкции, оставляя выбор конкретного метода решения задачи исполнителю приказа.
  2. "Commander's intent" - ясно раскрывать, общую цель и контекст действий (принцип называется ).
В статьях указывается что любой командир должен хорошо понимать цель и задачи как минимум двух командных эшелонов вверх от него. Командир взвода должен быть в курсе целей и планов роты и батальона. Большое внимание уделяется целеполаганию. Поставленные цели должны помогать подчиненным проявлять инициативу, а не мешать этому. Для этого цели должны быть достаточно широкими ("general"), но не туманными ("vague"). Подробнее о целях в следующей статье.

Этот подход требует, чтобы в отношениях между командиром и подчиненным было доверие. Командир должен доверять подчиненному, чтобы дать ему свободу действий. Подчиненный должен доверять командиру, чтобы не бояться проявлять инициативу. Командир не должен допускать перфекционизма ("zero defect mentality") у своих подчиненных, так как боязнь совершить ошибку сковывать инициативу.

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



А что у нас?

Разработка (какую я видел) отличается хаотичностью и непредсказуемостью, этим она напоминает войну. Любой, кто работал по выходным, чтобы уложиться в дедлайн, согласится, что в ней важен и темп. Как в свете описанных принципов выглядят наши реалии?

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

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

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


Заключение

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

Впрочем, не везде всё так плохо:

Хороший пример создания общего контекста я видел Лаборатории Касперского. Когда я там работал, там было две очень хороших традиции (как сейчас - не знаю). Во-первых, Евгений Касперский выступал перед новичками с рассказом о том, чем вообще занимается Лаборатория, какая у неё история, традиции и планы на будущее. Во-вторых, каждый год всех сотрудников собирали на ежегодное собрание, где нам рассказывали об итогах прошедшего года, текущем положении и стратегии компании на следующий год. Это создавало ощущение причастности и понимание того, для чего и зачем ты делаешь то, что делаешь.

Есть о чем задуматься. В следующей статье я хочу осветить подход КМП США к планированию.