СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

| сохранено

H Как повысить производительность команды в 10 раз в черновиках

Когда-то давно я первый раз столкнулся с такой постановкой вопроса, и тогда мне самому она показалась слегка вызывающей. Сначала я подумал: «В 10 раз?! Постойте, такого просто не может быть, это нереально!» Потом я усмирил бушующие внутри себя эмоции: «Давайте разбираться, что-то придумать все же можно».

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

— Представьте, что ваш начальник пришел к вам однажды и поставил вам цель увеличить производительность команды в 10 раз. Что вы будете делать?
— Уволюсь! – говорили они. :)

Все сводилось к ответу: «Ты безумец, это невозможно!» Люди даже не хотели подумать, как приблизиться к реализации данной цели и какие шаги нужно сделать.

Сегодня я попробую изложить свои мысли и рассказать мою точку зрения на этот вопрос. Если вам интересно, добро пожаловать под кат!

Для начала нужно понять, что такое производительность и как она измеряется в вашей команде. (Ведь измеряется же, правда?) Нужно четко понимать, что такое 1xПроизводительность, а что такое повышение производительности в 10 раз. При этом вы можете использовать совершенно разные показатели. Метрики производительности могут быть количественные и качественные. Давайте рассмотрим примеры таких (вымышленных и не очень) показателей.

В качестве примера количественных показателей можно взять, например, количество поставленных клиенту фич в единицу времени. Кто-то считает количество строк кода (да-да, и такое бывает, не удивляйтесь! Динозавры живут среди нас ;)), кому-то важно количество пофикшенных ошибок, количество автотестов и прочее.

Для заведения качественных показателей нужно найти эталоны отношения. Например, текущая производительность комплекса и требования по железу N. Тогда метрикой будет являться повышение производительности продукта на 25% или ускорение исполнения длительных задач на те же 25%.

Неплохой метрикой является Cost per unit (стоимость за единицу продукции). Единицей продукции является все, что имеет хоть какое-то значение для пользователя (функциональность, исправление ошибки, повышение производительности и т.д.) Ее можно померить в разрезе на человека, продукт, проект и т.д. Это все те метрики, описанные выше, но выраженные в деньгах.

Для многих в текущий век технологий важной метрикой является Cycle time (время доставки изменения до клиента). Одно дело, когда вы выкатываете новые фичи и изменения каждый день, другое – раз в месяц или еще реже!

С измерением производительности мы разобрались. Далее нам следует затронуть тему времени в своих целях: важно указать временной период, в течение которого планируется повысить производительность. Например, повысить производительность в 10 раз за 1 месяц – явно невыполнимая задача, а вот за 2-3 года – вполне себе (особенно если у вас новая команда и низкая текущая база).

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

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

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

Однако, не рубите с плеча. Есть случаи, когда производительность отдельного участника команды низкая, но когда он/она находится в команде, эффективность всей команды возрастает! Важно в команде иметь человека, который поднимал бы общий моральный дух команды. Пусть он даже делает меньше остальных, но зато сплочает коллектив и повышает общий результат.

Далее рассмотрим организационные и процессные моменты. Вы, как руководитель, обязаны следовать следующему процессу:

  1. Устранить «бутылочное горлышко» в ваших текущих процессах и команде
  2. Установить обратную связь по изменению.
  3. Повторять это бесконечное количество раз.

Устранив единожды узкое место, оно вылезет в другом месте. Устранив новое узкое место, вы получите его снова, скорее всего в более маленьком масштабе.

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

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

Ну, и финальное правило для руководителей и всех, кто хочет развиваться!

Выходите из зоны комфорта и развивайтесь! Остерегайтесь синдрома «лягушки в кипятке». Говорят, если бросить лягушку в горячую воду, она немедленно выпрыгнет. Но если поместить ту же лягушку в воду комнатной температуры и постепенно нагревать воду до кипения, лягушка не будет пытаться выбраться и в итоге просто сварится. Я не знаю, насколько правдива эта байка в отношении лягушек, но нечто подобное я периодически наблюдаю у руководителей и сотрудников. Люди склонны постепенно привыкать к неприемлемым вещам, которые повергли бы их в шок, если бы они увидели их свежим взглядом.

Развивайтесь, растите, добивайтесь успеха!

комментарии (29)

+3
+4 –1
Sirion ,  
Хороший план. А если на очередной итерации команде это надоест и она прекратит существовать, всегда можно загрузить предыдущее состояние из бэкапа. Реальность ведь именно так работает.
–2
digore ,  
Если не согласны с пунктами статьи, укажите, как вы повышаете производительность работы команды / свою производительность.
+2
+3 –1
Sirion ,  
Я не делаю это самоцелью. Цель — производить, а не повышать производительность.
–1
digore ,  
Я тоже не делаю это самоцелью. Но сущность любого организма — развитие и рост, без этого никуда. Откуда вы знаете, что ваше «производить» не превратится в застой и стагнацию?
+1
Alexsandr_SE ,  

Развитие это оптимизация, что-то новое, что дает преимущества, но не гонка по увеличению кол-ва одновременно имеющихся хвостов на одну ящерицу с одного до десяти.
Если я медленно будут делать свою программу, изменяя только когда на это найдется необходимость (запрос по пользованию), это застой? Или мне переписывать все по 10 раз просто ради того, что бы что-то делать? Думаю я могу все переписывать и так и этак, но реального роста то не будет.

–1
digore ,  
Ну вот приведу вам пример преимуществ:
1. Команда работает вроде бы эффективно, но постоянно находится большое количество ошибок на проде. Нужно сократить их количество в 10 раз, иначе бизнес закроется и программистов придется распустить.
2. Сервис работает на 100 серверах. Нужно сократить в 10 раз до 10 серверов для повышения конкурентноспособности компании.
+1
Alexsandr_SE ,  

Причем работа на н-ом кол-ве серверов к производительности труда? Может цель была изначально больше в 10 раз серверов в работу запустить :).
Ошибки закрываются тестированием в т.ч. выкаткой беты, увеличением кол-во предварительных загрузок на тесты…
Вам нужно уменьшить кол-во ошибок, но это приведет к увеличению времени разработки и тестирования, что входит в противоречие с увеличением в 10 раз производительности труда. Может программисты смогут еще добавить немного, но ошибок будет еще больше.

+4
+5 –1
ghrb ,  
1) Можно месяц заставлять команду заниматься ерундой, потом перестать и продуктивность вырастет в 10 раз
2) Можно давать команде первитин
3) Можно команду из разработки перевести на производство кирпичей, подключить физическое насилие и продуктивность тоже может вырасти в 10 раз.
+1
halted ,  
1) Можно месяц заставлять команду заниматься ерундой, потом перестать и продуктивность вырастет в 10 раз

Вот такая же мысль пришла в голову, сначала в 10 раз уронить продуктивность, а потом вернуть как было.
–1
digore ,  
Поделитесь, пожалуйста, как вы повышаете собственную производительность работы.
+1
+2 –1
vilgeforce ,  
Если производительность была нулевой, повысить ее можно во сколько угодно раз. Результата, правда, не будет. Попробуйте написать аналогичный текст про команду, которая решает неразрешимую задачу.
–2
digore ,  
Статья про другой кейс, про команду, которая приносит пользу и задачи решаемые.
Если будет адекватная критика на эту статью, возможно, напишу про ваш случай.
0
+1 –1
vilgeforce ,  
Да что вы говорите? Статья написана про то, как «повысить производительность команды в 10 раз», вот и повышайте в случае неразрешимой задачи. Начальник же сказал!
–1
digore ,  
Смысл в том, что если стремиться к чему-то высокому, то вы сможете достичь повышения производительности в 2-3 раза (разумными путями).
Если поставить себе цель «повысить на 30%», то можете не достигнуть и этой цели.
0
+1 –1
vilgeforce ,  
Смысл в том, что это — чушь. Последние 4 цифры числа Пи в студию, потом попробуйте повысить производительность этого процесса хоть сколько-нибудь. Потом подумайте.
–1
digore ,  
Что чушь? Вы можете адекватно и объективно покритиковать пункты, с которыми не согласны?
0
+1 –1
vilgeforce ,  
Чушь — что «если стремиться к чему-то высокому, то вы сможете достичь повышения производительности». Задача вам поставлена, пока вы не добьетесь повышения производительности при ее решении — ваши слова пусты, а написанное — чушь.
0
digore ,  
Если вы ничего не будете делать и не «стремиться к высокому», то ничего и не произойдет. :)
0
+1 –1
vilgeforce ,  
Бла-бла. Если будете — тоже не произойдет, потому что произойти не может
–1
digore ,  
Философский ответ, засчитывается!
+2
Alexsandr_SE ,  

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

0
digore ,  
Я понимаю вашу позицию и целиком ее поддерживаю. Я не говорю о революции и постановке программистам метрик «напиши в 10 раз больше фич за следующий релиз». Это процесс изменений долгий и методичный.
+1
JustDont ,  
Остаётся в нужный момент уволиться (пока всё не упало), и добавить в резюме строчку «повысил производительность в 10 раз».
+1
Sirion ,  
Да, именно это я сказал бы своим комментарием, если бы был более информативным и менее ироничным. Пожалуй, мне стоит на вас равняться.
+2
vadimm0s ,  
Возможно в аду есть отдельный «экспериментальный» котел, сами догадываетесь зачем.
А если серьезно, разработка это все же не штамповка медных тазиков, где производительность можно посчитать как отношение штук в единицу времени (если конечно компания не занимается копипастой кода, тогда да).
Как можно считать количество реализованных фитч, исправленных ошибок и т. п. в единицу времени?
Инженера-программиста можно сравнить с инженером-конструктором, так мне кажется абсурдность измерения производительности становится более «материальной» и очевидной. Представьте себе инженера-конструктора про которого можно сказать, что его производительность что-то вроде «5 уникальных изобретений в день».
Если компания не занимается непосредственно разработкой, а только лишь компоновкой готовых модулей (аля сборочный цех), то тут конечно можно производительность померить, а может и повысить, а может и в 10 раз (скоростной интернет подключить например).
–1
digore ,  
Я вас огорчу, но вы сильно преувеличиваете работу программиста и его творческую составляющую. Все измеряется, пусть не в строках кода, но в деньгах и финансовых показателях. Вы просто об этом не знаете.
+2
Welran ,   * (был изменён)
Если вы научитесь повышать производительность в хотя бы в полтора раза в произвольно взятой компании вы станете миллиардером :).
–1
digore ,  
Научился, но миллиардером не стал. Что я делаю не так? :)
+1
Ariant ,  
За всё хорошее, против всего плохого.