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