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