Часто такое бывает, что разработчик становится руководителем группы разработки и оказывается, что хотя ты и программируешь, но по факту — ты становишься совершенно другим специалистом, которому необходим набор несколько иных компетенций. На этапе становления в новой должности большое значение имеет предыдущий опыт — то есть, если разработчик до этого был участником agile команды, то, вполне вероятно, что он будет использовать техники agile и в текущей разработке. Что же произойдет, если руководитель разработки не участвовал ранее в разработке по agile и даже не знает, что такие методики существуют или знает, но не имеет времени на изучение или они кажутся очень вычурными или неэффективными? Об этом тема публикации.
Именно таким путем довелось пройти мне, где я узнал много нового, получил колоссальный опыт и сделал ряд интересных выводов, чем и хочу поделиться.
Введение. Главный фактор эффективности разработки
Итак, возвращаюсь к вопросу — если не знаком с методологиями, то какой способ организации разработки кажется самым логичным и приемлемым? Ну, конечно, поделить разрабатываемую конфигурацию на подсистемы и каждого разработчика назначить ответственным за одну из подсистем. Логично? Логично!
По сути — это будет очередная ступень иерархии, со всеми вытекающими из этого последствиями — в этом случае у каждого разработчика будет зона своей ответственности и всегда можно будет найти ответственного, чья подсистема дала сбой. В случае возникновения ошибки замечание будет сделано руководителю разработки, который должен будет как-то отреагировать. И тут возникает интересный вопрос — как реагировать? Если разработчика лишить каких-нибудь ресурсов или припугнуть или сделать резкое замечание и прочее, то это непременно вызовет у него негативные эмоции, а это путь к издержкам. Поскольку разработчик — это творческий человек, и его настроение напрямую влияет на его эффективность — когда есть настроение он творит, создает шедевры и от этого получает дополнительную энергию, которую использует на очередной шедевр; когда настроения нет — он работает, вытягивает из себя строки кода, делает то, что требуется, лишь бы от него отстали. Согласитесь, что между этими двумя стилями работы разработчика имеется заметная разница. А если теперь эту разницу перевести в нормочасы работы, а нормочасы перевести в недописанные программы и недополученные для бизнеса деньги, то отрицательный эффект может быть очень весомым. Отсюда вывод: эффективность разработки (а значит скорость и прибыль) напрямую зависит от настроения и настроя разработчиков. Любая демотивация разработчиков приводит к прямым потерям.
Как же тогда быть? Ответ простой — нужна внутренняя культура, где каждого участника разработки задевали бы его ошибки и мотивировали на дальнейшее совершенствование без лишних замечаний. А для этого нужно, что бы каждый разработчик "болел душой" за результат, а не просто писал код и штамповал задания.
Рассуждение. Эффективность разработки при делении конфигурации на подсистемы с назначением ответственных
Разделение по иерархическому признаку (деление конфигурации на подсистемы с назначением ответственных разработчиков) при разработке, с одной стороны — снижает конфликты, поскольку каждый является "начальником" своей подсистемы и самостоятельно решает что и как должно быть. Но с другой стороны — да, разработчик решает как должно быть, но будет ли его решение лучшим? То есть, отдавая право принятия решения о реализации задания разработчику без контроля и обсуждения существует риск неэффективной реализации задания, пропорциональный опыту каждого разработчика. Причиной будет являться отсутствие обсуждения альтернативных идей реализации. И даже если руководитель разработки поинтересуется о способе реализации и согласится с ним, то все-равно это может быть не лучшее решение, так как и руководитель разработки так же может не видеть лучшего решения.
Ещё один негативный фактор связан с изоляцией разработчика, поскольку реализуя задания на своём уровне — он не растёт и не развивается, а в последствии его уровень разработки даже может начать снижаться. Так же, при разделении на подсистемы, теряется общий стиль реализации, что так же снижает качество разрабатываемого продукта. Выше писалось про эмоции разработчика, так вот при разделении на подсистемы отсутствует полноценная обратная связь, то есть задание получено, реализовано и должным образом не оценено, поскольку руководителя разработки волнует факт реализации задания; тестировщика — что бы не было ошибок; пользователя — что бы реализованный функционал решал его задачу, а кто оценит оригинальность решения и эффективность реализации, так необходимое разработчику для его дальнейшего роста и совершенствования? Наверное только он сам, что является слабым мотиватором. Таким образом, скоро у разработчика возникает ощущение, что он "станок", штампующий задания, и вся деятельность видится как рутина, не вызывающая положительных эмоций, что, как было описано выше, ведет к потере эффективности и, как следствие, производительности.
При такой схеме организации разработки роль руководителя разработки заключается в диспетчировании заданий и контролировании сроков реализации. И это совсем не соответствует картинке лидера, ведущего команду за собой, как пишут во многих книгах по лидерству и саморазвитию...
Анализ. Поиск совершенства в управлении разработкой
Мой первый опыт в роли руководителя разработки начался именно с разделением конфигурации на подсистемы с назначением ответственных разработчиков на каждую из подсистем.
Некоторое время поработав таким образом я сделал описанные выше выводы, при этом логика мне подсказывала, что все должно быть не так, но тогда как? Эта мысль подтолкнула меня на поиск правильной организации командной работы при разработке. Долго искать не пришлось, поскольку на мои запросы поисковики тут же направили меня в направлении agile.
Если честно, то поверхностная оценка этой методологии как-то не впечатлила — много действий, причем непонятно зачем нужных, но это подогрело интерес к данной теме и подтолкнуло на более глубокий поиск истины, что привело меня к книгам по agile [1, 2, 3], которые ответили на часть моих вопросов. В этот момент я начал понимать, насколько важен менеджмент и насколько разный он может быть, поэтому мне захотелось понять и сам менеджмент, как базу agile, что заставило копнуть ещё глубже [4, 5]. В итоге, когда в голове все сначала перемешалось и через некоторое время улеглось и мозг уловил дополняющие друг-друга концепции, мне все стало более-менее понятно. Своими выводами мне бы и хотелось поделиться.
Начну с краткого обсуждения менеджмента с переходом к командной работе. Итак, менеджмент. На текущий момент главенствуют две основные парадигмы управления — это американская модель (представляющая организацию как иерархию и базирующуюся на контроле сотрудников, находящихся ниже по иерархии) и японская модель (представляющее организацию как систему и базирующуюся на вовлеченности сотрудников в деятельность в процессе командной работы). Главное отличие иерархической модели от командной заключается в способах принятия решений: в первом случае решение принимает сотрудник, находящийся выше по иерархии; во втором случае — решение принимает команда, а сотрудник, находящийся "выше по иерархии" (на самом деле в системной модели все равны), выносит вопросы на обсуждение команды и организует процесс конструктивного обсуждения и принятия решений, таким образом команда становится самоорганизующейся.
Преимущества командного взаимодействия очевидны:
- каждый член команды вовлекается в работу и жизнь команды, а учитывая то, что каждый из членов команды может влиять на командное решение, мотивирует на улучшение всех протекающих внутри процессов;
- повышается качество принимаемых решений, так как команда сама решает, как поступить в рамках действующих ограничений и таким образом все участники становятся заинтересованы в принятии лучших решений;
- повышается командный дух, поскольку все работают на единый результат и при его достижении испытывают чувство гордости и собственной значимости от внесенного вклада. Это дает ещё большую энергию для последующих свершений.
Таким образом, команда "растет" и "развивается", как живая сущность (по этому поводу есть ряд научных статей).
В иерархической модели за работу команды (точнее отдела) отвечает руководитель, а значит и все решения принимает он. Если команда сработала хорошо, то хвалят руководителя, а он награждает сотрудников за успешное выполнение проекта. Руководитель в такой системе становится контролером действий подчиненных, поскольку ответственен он один. Поскольку его основная мотивация — сдача проектов в срок, то сотрудники выступают инструментами для реализации этого. При этом роль сотрудника заключается в подчинении руководителю и получается, что при такой организации работы сотрудник ничего не решает, все действия согласовывает и послушно всё выполняет. Что является мотиватором сотрудника? Награда за выполненную работу и все, сильных внутренних мотиваций нет. Поэтому сотрудники при такой организации работы приходят на работу в основном только зарабатывать деньги, ощущая себя шестеренкой в большой машине. Если кто-то и находит для себя внутреннюю мотивацию, то она очень блеклая и далека от мотивации реализации себя в команде единомышленников как творческая личность, болеющая за командный результат.
Говоря метафорически, при иерархической организации работы разработчики воспринимаются как "станки", на вход которым подаются задания, а на выходе получают их реализацию. Дальше можете сами провести аналогию в случаях, когда станок делает брак, износился и т.д. В отдел, где не хватает "мощностей", могут переместить "станок" из соседнего отдела или "закупить". Руководитель разработки воспринимается как оператор станка, который контролирует выход и качество. При командной организации работы разработчики представляются как "растения", которым создаются условия для их роста. Устраняются все негативные (как физические, так и эмоциональные) факторы, мешающие продуктивной работе. Создается конкурентная не враждебная среда из единомышленников, имеющая общие цели и работающая на общий результат, где каждый заинтересован в положительном результате других членов команды. Каждый из участников имеет равные права, равный доступ к информации, имеет возможность повлиять на командные решения. Руководитель разработки (тимлид) воспринимается как садовник, выращивающий команду [3].
В сфере разработки программ, схема работы основанная на системном менеджменте и вовлеченности, описана в методологии agile. Именно тут реализуется высвобождение творческой энергии команды разработки в момент покер-планирования или анализе заданий, на стендапах можно похвалиться результатами или попросить помощь, на ретроспективах поговорить о дальнейших улучшениях командного взаимодействия и способов повышения эффективности.
Подготовка. Первый опыт разработки стратегии развития
… Итак, будучи руководителем группы разработки команды, работающей по иерархическому принципу и после осознания того, что же такое "вовлеченность" и какой эффект от использования можно получить, мне конечно же захотелось попробовать методики в деле.
И я решил начать с… стратегии развития команды.
После прочтения нескольких книг и публикаций по стратегическому менеджменту [8], я поймал себя на мысли, что мы приходим на работу, выполняем свои обязанности, но даже не задумываемся зачем? А также мы не думаем — что из себя представляет идеально выполняемая нами работа, то есть к какому результату надо стремиться? Обсудив эти вопросы с командой, выяснилось, что мы приходим на работу не для написания кода и даже не для выполнения заданий, а для того, что бы помогать выполнять свою работу пользователям программы, а учитывая то, что это сфера общепита, а прием пищи вызывает положительные эмоции, то мы косвенно влияем на настроение посетителей. Согласитесь, что это немного другая мотивация, она придает смысл работе и добавляет положительных эмоций. Эти выводы были записаны как Миссия команды разработки.
Для реализации Миссии нам следует выполнять свою работу идеально, а для этого нужно хотя бы визуализировать идеальный результат работы. Конечно же, работать таким образом нереально, всегда будут издержки, но это будет тот результат, к которому надо стремиться. Обсудив между собой, что из себя представляет наша идеальная работа и объединив все основные выводы в несколько предложений, мы получили Видение, т.е. тот результат работы суперэффективной команды, к которому надо стремиться.
Что бы достичь Видения, необходимо задать Цели, в каких направлениях совершенствоваться. Например, если в Видении сказано "команда умных специалистов", то должны быть заданы Цели — "совершенствование знаний и навыков программирования", "развитие командной работы" и т.д.
Согласно теории Ицхака Адизеса "PAEI" [6] можно выделить 4 направления совершенствования команды, которые, относительно разработки, обозначают:
- производство (качество выполнения заданий),
- администрирование (логистика заданий от поступления до реализации, решение организационных вопросов),
- интеграция (взаимодействие членов команды)
- предпринимательство (планы по развитию и совершенствованию команды)
и для построения эффективной командной работы, необходимо совершенствоваться во всех этих направлениях. Таким образом, были заданы цели по каждому из предложенных направлений.
Наш стратегический план развития был изображен на плакате и повешен в кабинете. Теперь на ретроспективах стало возможно обсуждать насколько за сессию мы продвинулись по каждой из Целей и приблизились к нашему Видению суперэффективной команды.
Внедрение. Первые шаги agile
Изменения решил начать с ввода ретроспектив. Дождавшись очередного послерелизного понедельника собрал всю команду и предложил встречаться после сдачи релиза для обсуждения — насколько эффективно мы отработали по каждой из целей и как можно было бы ещё увеличить эффективность и приблизиться к Видению.
Там же предложил совместно обсуждать реализацию заданий, аргументируя тем, что при наличии нескольких мнений можно находить лучшее решение. К тому же, при подобных обсуждениях, должна повыситься видимость внутренних процессов конфигурации для разработчиков, сопровождающих смежные подсистемы. Да и совместное обсуждение интересующей всех темы — это лучший тимбилдинг. От этого простого действия видны одни лишь плюсы. Минус только один — чуть большие затраты времени, но при всех описанных плюсах — эта издержка ничтожна.
Весь следующий релиз мы работали по новому. Теперь, когда приходило задание, я его не диспетчировал на разработчика, а ставил всех разработчиков в наблюдатели, что бы они могли ознакомиться с заданием, а на следующее утро приглашал для обсуждения. И сработало. Обсуждения были жаркими, каждый пытался блеснуть креативностью и в результате, после просева предложений по реализации задания или после смешения нескольких идей в одну, рождались очень интересные решения, по факту — лучшие, исходя из совместного интеллектуального опыта команды. Как руководитель разработки я стал спокоен за качество реализуемого функционала.
Встречи для обсуждения функционала подтолкнула меня к мысли, а почему бы не встречаться ежедневно для обсуждения не только заданий, но так же и своими результатами разработки (то есть я дорос до стендапов, предлагаемых в agile). Это и было мною предложено на очередной ретроспективе и так появились ежедневные утренние встречи (что бы не пугать иноземной терминологией, они у нас назывались "планерки").
На каждой ретроспективе (кхе, на "подведении итогов") искались слабые направления развития (то есть Цели), по которым мы меньше всего продвинулись за релиз и обсуждались способы наверстать отставание, например,
- Совершенствование цели «Производство» (качество выполнения разработки) осуществляется за счет оптимизации функционала, рефакторинга кода, визуализации бизнес-процессов, обучения разработчиков и т.д.
- Совершенствование цели «Администрирование» осуществляется за счет поиска и устранения простоев заданий или изменения маршрута задания, с целью повышения эффективности; так же здесь решались хозяйственные вопросы.
- Совершенствование цели «Интеграция» (взаимодействие членов команды) осуществляется за счет чтения лекций по командному поведению, по мотивам книг [7], [3].
- Совершенствование цели «Предпринимательство» (планы по развитию и совершенствованию команды) осуществляется за счет проведения ретроспектив и обсуждения там вопросов улучшения любой из целей выше, введение правил или норм поведения или обсуждение конфликтных ситуаций, возникших в команде, изменение целей.
Таким образом был организован agile, с ориентиром на стратегический план, то есть на Миссию, Видение, Цели. Ох, про Ценности забыл. Ценности — это перечень правил поведения в команде, то есть чем мы руководствуется при взаимодействиях. Например, указали в Ценностях "Сотрудничество" и если кто-то начинает "тянуть одеяло на себя", то будет способ его одернуть, напомнив про Ценности команды. Если задали "Честность", то за любой обман можно будет спросить, опираясь на Ценности команды. Ценности так же разрабатываются совместно всеми членами команды.
Сопровождение. Текучка по agile
… Теперь рабочий день начинался с обсуждения незавершенки, новых заданий, планов на день. Когда долгосрочных заданий стало очень много, была заведена канбан-доска и обсуждение происходило по всем работам, которые имели состояние "В работе". Так же на доске можно было посмотреть, что у нас "В плане" и "На анализе". После выпуска релиза мы обсуждали способы совершенствования работы нашей команды.
Таким образом, из скучной рабочей группы, где каждый в одиночку развивал свой кусок конфигурации, мы развились в команду, со своими правилами, нормами, культурой и ценностями.
Можно развиваться и дальше — по целям разработать KPI и оценивать недоработки команды уже в количественных показателях, но мне кажется, что для небольшой команды это будет перебор.
Ретроспектива. Подведение итогов
Какие выводы я сделал в процессе перехода к командной работе:
- В командной работе руководителю приходится жертвовать властью, становясь одним из членов команды, в пользу роста эффективности команды. Единственным инструментом влияния, в этом случае, является умение задавать правильные вопросы.
В иерархических системах управление осуществляется авторитетом руководителя, и чем более авторитарно управление, тем более безинициативны управляемые. - Командный подход организации разработки позволил мне, как руководителю разработки, ненавязчиво влиять на процесс разработки и быть в курсе всех дел. При этом все разработчики становились осведомленными по текущим работам и проблемам, делающие возможным их легкую взаимозаменяемость. Новые сотрудники быстро вникали в текущую разработку. Сообщение о сделанной работе за день перед всеми участниками группы дает возможность высказаться и показать себя, что развивает команду. От такого взаимодействия одни плюсы.
На контрасте с этим подходом замечу, что при иерархической организации разработки (разделении на подсистемы) приходилось бы руководить директивно или постоянно спрашивать о процессах и итогах разработки. При этом руководитель разработки становился бы незаменимым сотрудником, единственным, кто был бы в курсе всей разработки. Взаимозаменяемость разработчиков была бы так же намного проблематична. - Поскольку команда совершенствуется влиянием каждого его члена, то каждый новый участник совершенствует работу команды, и чем он опытнее, тем больший положительный вклад может внести в развитие команды; при иерархическом подходе у участников обычно не спрашивают мнения (только результаты), а попытки применения более совершенных подходов часто ведут к конфликтам с руководством, у которого власти больше.
- Компетенции руководителей системного менеджмента (куда так же отношу и agile), противоположны компетенциям руководителей иерархических организаций.
В иерархических системах принято, что начальник отдела должен уметь донести до подчиненных и реализовать директиву сверху любыми, иногда даже непопулярными, способами, а значит и нужен волевой, строгий, ориентированный на процесс сотрудник. В системном менеджменте руководитель группы — это гибкий организатор с навыками фасилитации (умением вести обсуждение), обладающий лидерскими качествами, чувствующий людей и команду, который неприятную директиву вынесет на обсуждение команды с дальнейшей совместной разработкой плана действий. - Индивидуальная ответственность за результат команды провоцирует на создание иерархии внутри, поэтому для развития командной работы — или ответственность должна быть командная или необходим спрос с руководителя группы как результатов работы, так и результатов командного взаимодействия.
Надеюсь, что вы почерпнете что-то полезное из моего опыта, а может быть даже возьмете на вооружение.
Список литературы из статьи:
1. «Постигая Agile» Дженнифер Грин
2. «Scrum. Революционный метод управления проектами» Джефф Сазерленд
3. «Agile-менеджмент. Лидерство и управление командами» Юрген Аппело
4. «Менеджмент нового времени. Простые механизмы, ведущие к росту, инновациям и доминированию на рынке» Эдвардс Деминг
5. «Эффективный руководитель» Питер Друкер
6. «Стили менеджмента – эффективные и неэффективные» Ицхак Адизес
7. «Пять пороков команды» Патрик Ленсиони
8. «Стратегическое сафари. Экскурсия по дебрям стратегического менеджмента» Генри Минцберг
