Как часто бывает в жизни: приходит новый менеджер и ставит задачу повысить количество реализуемых фич в 2 раза за следующий спринт. Разработчики, конечно, стараются, работают, остаются на выходные, выполняют поставленный план, но потом почему-то все увольняются.
Большинство людей видит продуктивность, исходя из парадигмы: чем больше ты производишь, чем больше делаешь, тем выше твоя продуктивность. Но истинная продуктивность есть функция двух элементов: полученного результата и затраченных ресурсов. Поддерживать баланс между результатом и ресурсами часто бывает довольно непросто. Однако в этом балансе и заключается вся суть. Он приводит к сбалансированности краткосрочного и долгосрочного.
Любой руководитель, будь то руководитель группы разработки или руководитель отдела, должен заботиться о повышении продуктивности работы своей команды. Но как это сделать разумно? Можно ли повысить продуктивность работы команды, например, в 10 раз?
Сегодня я попробую рассказать мою точку зрения на этот вопрос. Если вам интересно, добро пожаловать под кат!
Для начала нужно понять, что такое продуктивность и как она измеряется в вашей команде. При этом вы можете использовать совершенно разные показатели. Они могут быть количественные и качественные.
В качестве примера количественных показателей можно взять, например, количество поставленных клиенту фич в единицу времени. Кто-то все еще оценивает работу программистов в строках кода (да-да, и такое бывает по сей день), кому-то важно количество пофикшенных ошибок, количество автотестов и прочее.
Для заведения качественных показателей нужно найти эталоны отношения. Например, текущая производительность комплекса и требования по железу N. Тогда метрикой будет являться повышение производительности продукта на 25% или ускорение исполнения длительных задач на те же 25%.
Неплохой метрикой является Cost per unit (стоимость за единицу продукции). Единицей продукции является все, что имеет хоть какое-то значение для пользователя (функциональность, исправление ошибки, повышение производительности и т.д.) Ее можно померить в разрезе на человека, продукт, проект и т.д. Это все те метрики, описанные выше, но выраженные в деньгах.
Для многих важной метрикой является Cycle time (время доставки изменения до клиента). Одно дело, когда вы выкатываете новые фичи и изменения каждый день, другое – раз в месяц или еще реже.
О продуктивности команды нельзя говорить в отрыве от качества поставляемого продукта. Безусловно, вы должны иметь целый набор метрик, оценивающие качество вашего продукта. Давайте приведем несколько примеров таких метрик:
Так как же повысить продуктивность команды?
Посмотрим на продукт, как результат работы команды. Всем известен принцип Парето, из которого следует, что 20% функциональности продукта покрывает 80% нужд пользователей. Остальной функционал либо совсем редко используется, либо не используется совсем. Очень важно тратить время команды именно на нужные и важные фичи, поэтому избавляйтесь от старого и ненужного кода, делайте рефакторинг, упрощайте код и его поддержку. В будущем это значительно повысит эффективность команды.
Невероятно легко попасть в ловушку активности, в круговорот дел и событий, все больше и больше усилий расходуя на то, чтобы делать какие-то новые бесполезные фичи, менять дизайн и т.д., чтобы в один момент осознать, что это никому не нужно. Можно быть и очень занятым человеком, не будучи эффективным.
Давайте разбираться с командой. Ни для кого не секрет, что определенные разработчики в разы, в 10-ки раз продуктивней своих коллег. Ваша задача как руководителя состоит в том, чтобы строить сильную команду и отбирать в нее только лучших кандидатов. Отсюда следует тот факт, что вам нужно прощаться с откровенно слабыми, снижающими продуктивность всей команды участниками. Постоянно задавайте себе вопрос: вы бы наняли этого человека на эту должность, зная то, что знаете сейчас? Если нет, он не должен ее занимать.
Однако, не рубите с плеча. Есть случаи, когда продуктивность отдельного участника команды низкая, но когда он/она находится в команде, продуктивность всей команды возрастает! Важно в команде иметь человека, который поднимал бы общий моральный дух команды. Пусть он даже делает меньше остальных, но зато сплочает коллектив и повышает общий результат.
Рассмотрим организационные и процессные моменты. Вы, как руководитель, обязаны следовать следующему процессу:
Устранив единожды узкое место, оно вылезет в другом месте. Устранив новое узкое место, вы получите его снова, скорее всего в более маленьком масштабе. В какой-то момент вы поймете, что поиск горлышка для вас стал слишком сложным и его устранение дороже, чем бонус от результата. Для вас настала пора экспериментирования в процессах! Ищите лучшие практики, пробуйте переложить их на свою команду, адаптируйте! Не нужно бояться неудач, не все лучшие практики приживаются в конкретных командах. Следует сделать выводы и двигаться дальше.
Вам нужно стараться автоматизировать все, для чего автоматизация в вашей команде разумна. Никто не будет спорить, что в подавляющем количестве проектов следует использовать CI/CD для быстрого разворачивания и доставки новой версии продукта клиенту. Автотесты сейчас не использует только ленивый руководитель. Вы сами можете и должны придумать, что разумнее всего автоматизировать для конкретно вашей команды.
Ну, и финальное правило для руководителей и всех, кто хочет развиваться!
Выходите из зоны комфорта! Остерегайтесь синдрома «лягушки в кипятке». Говорят, если бросить лягушку в горячую воду, она немедленно выпрыгнет. Но если поместить ту же лягушку в воду комнатной температуры и постепенно нагревать воду до кипения, лягушка не будет пытаться выбраться и в итоге просто сварится. Я не знаю, насколько правдива эта байка в отношении лягушек, но нечто подобное я периодически наблюдаю у руководителей и сотрудников. Люди склонны постепенно привыкать к неприемлемым вещам, которые повергли бы их в шок, если бы они увидели их свежим взглядом.
Развивайтесь, растите, добивайтесь успеха!
Большинство людей видит продуктивность, исходя из парадигмы: чем больше ты производишь, чем больше делаешь, тем выше твоя продуктивность. Но истинная продуктивность есть функция двух элементов: полученного результата и затраченных ресурсов. Поддерживать баланс между результатом и ресурсами часто бывает довольно непросто. Однако в этом балансе и заключается вся суть. Он приводит к сбалансированности краткосрочного и долгосрочного.
Любой руководитель, будь то руководитель группы разработки или руководитель отдела, должен заботиться о повышении продуктивности работы своей команды. Но как это сделать разумно? Можно ли повысить продуктивность работы команды, например, в 10 раз?
Сегодня я попробую рассказать мою точку зрения на этот вопрос. Если вам интересно, добро пожаловать под кат!
Для начала нужно понять, что такое продуктивность и как она измеряется в вашей команде. При этом вы можете использовать совершенно разные показатели. Они могут быть количественные и качественные.
В качестве примера количественных показателей можно взять, например, количество поставленных клиенту фич в единицу времени. Кто-то все еще оценивает работу программистов в строках кода (да-да, и такое бывает по сей день), кому-то важно количество пофикшенных ошибок, количество автотестов и прочее.
Для заведения качественных показателей нужно найти эталоны отношения. Например, текущая производительность комплекса и требования по железу N. Тогда метрикой будет являться повышение производительности продукта на 25% или ускорение исполнения длительных задач на те же 25%.
Неплохой метрикой является Cost per unit (стоимость за единицу продукции). Единицей продукции является все, что имеет хоть какое-то значение для пользователя (функциональность, исправление ошибки, повышение производительности и т.д.) Ее можно померить в разрезе на человека, продукт, проект и т.д. Это все те метрики, описанные выше, но выраженные в деньгах.
Для многих важной метрикой является Cycle time (время доставки изменения до клиента). Одно дело, когда вы выкатываете новые фичи и изменения каждый день, другое – раз в месяц или еще реже.
О продуктивности команды нельзя говорить в отрыве от качества поставляемого продукта. Безусловно, вы должны иметь целый набор метрик, оценивающие качество вашего продукта. Давайте приведем несколько примеров таких метрик:
- количество ошибок, найденных клиентами за промежуток времени после поставки новой версии (пример внешней метрики)
- количество найденных ошибок в отделе тестирования после передачи функциональности или исправления в верификацию (пример внутренней метрики).
Так как же повысить продуктивность команды?
Посмотрим на продукт, как результат работы команды. Всем известен принцип Парето, из которого следует, что 20% функциональности продукта покрывает 80% нужд пользователей. Остальной функционал либо совсем редко используется, либо не используется совсем. Очень важно тратить время команды именно на нужные и важные фичи, поэтому избавляйтесь от старого и ненужного кода, делайте рефакторинг, упрощайте код и его поддержку. В будущем это значительно повысит эффективность команды.
Невероятно легко попасть в ловушку активности, в круговорот дел и событий, все больше и больше усилий расходуя на то, чтобы делать какие-то новые бесполезные фичи, менять дизайн и т.д., чтобы в один момент осознать, что это никому не нужно. Можно быть и очень занятым человеком, не будучи эффективным.
Давайте разбираться с командой. Ни для кого не секрет, что определенные разработчики в разы, в 10-ки раз продуктивней своих коллег. Ваша задача как руководителя состоит в том, чтобы строить сильную команду и отбирать в нее только лучших кандидатов. Отсюда следует тот факт, что вам нужно прощаться с откровенно слабыми, снижающими продуктивность всей команды участниками. Постоянно задавайте себе вопрос: вы бы наняли этого человека на эту должность, зная то, что знаете сейчас? Если нет, он не должен ее занимать.
Однако, не рубите с плеча. Есть случаи, когда продуктивность отдельного участника команды низкая, но когда он/она находится в команде, продуктивность всей команды возрастает! Важно в команде иметь человека, который поднимал бы общий моральный дух команды. Пусть он даже делает меньше остальных, но зато сплочает коллектив и повышает общий результат.
Рассмотрим организационные и процессные моменты. Вы, как руководитель, обязаны следовать следующему процессу:
- устранить «бутылочное горлышко» в ваших текущих процессах и команде,
- установить обратную связь по изменению,
- повторять этот процесс бесконечное количество раз.
Устранив единожды узкое место, оно вылезет в другом месте. Устранив новое узкое место, вы получите его снова, скорее всего в более маленьком масштабе. В какой-то момент вы поймете, что поиск горлышка для вас стал слишком сложным и его устранение дороже, чем бонус от результата. Для вас настала пора экспериментирования в процессах! Ищите лучшие практики, пробуйте переложить их на свою команду, адаптируйте! Не нужно бояться неудач, не все лучшие практики приживаются в конкретных командах. Следует сделать выводы и двигаться дальше.
Вам нужно стараться автоматизировать все, для чего автоматизация в вашей команде разумна. Никто не будет спорить, что в подавляющем количестве проектов следует использовать CI/CD для быстрого разворачивания и доставки новой версии продукта клиенту. Автотесты сейчас не использует только ленивый руководитель. Вы сами можете и должны придумать, что разумнее всего автоматизировать для конкретно вашей команды.
Ну, и финальное правило для руководителей и всех, кто хочет развиваться!
Выходите из зоны комфорта! Остерегайтесь синдрома «лягушки в кипятке». Говорят, если бросить лягушку в горячую воду, она немедленно выпрыгнет. Но если поместить ту же лягушку в воду комнатной температуры и постепенно нагревать воду до кипения, лягушка не будет пытаться выбраться и в итоге просто сварится. Я не знаю, насколько правдива эта байка в отношении лягушек, но нечто подобное я периодически наблюдаю у руководителей и сотрудников. Люди склонны постепенно привыкать к неприемлемым вещам, которые повергли бы их в шок, если бы они увидели их свежим взглядом.
Развивайтесь, растите, добивайтесь успеха!