Я руковожу командой из 6 бэкенд-разработчиков, и недавно я внедрил в компании методологию Agile & Scrum, начиная с бэкэнд-команды (которая позже будет применяться к другим отделам, когда процесс будет успешным и доработанным). .
Процесс оказался успешным в различных областях (качество, производительность и более приятная обстановка в помещении). Однако за последние 3 недели мы столкнулись с проблемой производительности (я измеряю KPI для каждого человека и для команды).
Моя реакция на это состояла в том, чтобы сделать планирование более эффективным в приоритизации задач, применяя обязательный брифинг для каждого крупного проекта (где будут присутствовать менеджер проекта, я и ведущий разработчик) и четкую коммуникацию между всеми сторонами. Я и управляющий директор (оба мы технические) обязательно оказываем техническую поддержку, устраняем любые препятствия, которые могут возникнуть у команды, и постоянно тестируем все, что указано в столбце «Тестирование», чтобы поддерживать качество и стандарты на высоком уровне.
Я чувствую, что сделал все, что мог, в плане управления. Я также получил поддержку всех директоров в компании, и у нас у всех отличные рабочие отношения, а это значит, что у меня нет никаких ограничений для внесения изменений. Единственное, что меня беспокоит, это то, что с коммерческой точки зрения мы недостаточно работаем, чтобы сделать нас прибыльными. Мы с доктором медицины считаем, что проблема может заключаться в индивидуальной продуктивности каждого члена команды.
TLDR — Какие еще методы/процессы, помимо упомянутых выше, вы использовали для дальнейшего повышения производительности при управлении командой бэкенда с использованием Agile и Scrum?
Я вижу здесь два вопроса: как повысить производительность команды? и Как мы можем помочь команде быть прибыльной?
прибыльность
Это обширная тема, поэтому я коснусь ее только для того, чтобы объяснить, почему производительность — это не то же самое, что прибыльность. Для простого примера, если я делаю виджеты, которые я продаю за 10 долларов, а их работа обходится мне в 100 долларов в день, мне нужно сделать больше, чем 10. Допустим, я делаю 8. Я могу решить эту проблему, найдя способ сделать, или вместо этого взимая 13 долларов. Оба этих варианта приносят мне прибыль.
Изменение производительности — это долгосрочная инвестиция. 100-процентное увеличение производительности, которое вы наблюдали за такое короткое время, практически неслыханно. Я рад за вас и вашу команду, что вы это увидели, но это не норма, и я бы не стал рассчитывать на еще один подобный поворот. Если вам нужно краткосрочное решение, вы должны создавать больше ценности, что может означать взимание большей платы или расстановку приоритетов над более ценной работой.
Производительность
Ретроспективы
Я бы посмотрел, какие улучшения произошли в результате ваших ретроспектив. Это ваш основной инструмент для улучшения команды. Загляните на https://plans-for-retrospectives.com/en/ , чтобы узнать, как проводить более эффективные ретроспективы. Попробуйте их более структурированный 5-этапный подход, чтобы увидеть, дает ли он более эффективную информацию. Я не знаю вашу команду, но большинство команд, с которыми я работал, не получают полной отдачи от своих ретро.
Бережливые отходы (3 М)
Есть отличное упражнение, которое я провел с командами с тремя М в бережливом производстве (Мура, Муда, Мури). Создайте 3 столбца или раздела на доске и объясните 3M (краткое описание ниже) и попросите их записать на стикерах отходы, с которыми они сталкиваются в течение рабочего дня, и поместить их в правильный столбец. Я обычно получаю по крайней мере 20-30 из группы. Вы не можете решить их все сразу, и многие из них можно только улучшить, а не удалить, но это даст вам отличный список вещей, замедляющих вашу команду, с которыми вы можете помочь.
Не удалось найти ссылку с описаниями, которыми я был доволен, поэтому вот краткие определения:
Мури (Перегрузка) : Максимальный объем работы, который я могу выполнить за один раз, просто увязает в управлении и расстановке приоритетов, и это отнимает у меня время, которое я выполняю. Для получения дополнительной информации и математических доказательств взгляните на закон Литтла из теории массового обслуживания. Подсказка: количество вещей обычно меньше 5, в некоторых случаях бывает 1.
Мура (Вариация) : В работе со знаниями я вижу три распространенных типа отходов Мура. Переключение контекста, когда я пытаюсь работать в многозадачном режиме или разделить время на разные проекты. Разнообразие типов задач, которые требуют, чтобы я работал совершенно по-разному (в этом может помочь группировка типов задач). И, наконец, изменение потока — например, все истории переходят к тестированию в конце спринта, а тестировщики из скучающих превращаются в перегруженных.
Муда (деятельность, не добавляющая ценность) : это говорит само за себя. Какие действия занимают время в течение дня, которые не продвигают функции вашего приложения. Вы также можете взглянуть на Lean 7 Waste, чтобы узнать больше об этом, хотя в основном он написан с точки зрения производства, и вам нужно немного перевести его на интеллектуальную работу. (например, предметы, лежащие в инвентаре, преобразуются в невыпущенный код)
Патрисия Шанахан
пользователь932132
Юха Унтинен
тиего1967
Толстяк
Неманья Трифунович
HLGEM
HLGEM
Алан Лаример