Многомерный конструктор
На уровне большого проекта или компании метрика по тому, кто нужен для того, чтобы какая-то инициатива состоялась, по сути, одномерная: "нам нужно 10 человек, 100 или 1000". Называется просто число, и никто не спрашивает, что это за 100 людей и что они будут делать.
Если спускаться с уровня топ-менеджмента, картинка начинает обрастать деталями: появляются дизайнеры, разработчики, QA, менеджмент среднего звена.
Дальше - больше: фронтендеры, бекендеры, спецы по C#, Angular, джуны, сеньоры и т.п. На этом уровне всё ещё довольно просто, хотя и уже начинают проскакивать нюансы того, как всех этих людей со своими слабыми и сильными сторонами собрать в нечто устойчивое.
Но когда доходишь до уровня конкретной команды, начинается самое интересное. Уже недостаточно просто взять ещё одного бекендера или закрыть пробел с помощью QA. Нужно учесть массу особенностей каждого человека: характер, темп работы, любовь к порядку или хаосу, опыт, стиль общения.
Сложность резко повышается, а процесс сбора и слаживания команды превращается в многомерный конструктор:
* в нем есть десяток-другой "измерений", по которым можно оценивать людей;
* существует разнообразие ролей в команде, в каждой из которых нужно определенное сочетание "метрик" по этим измерениям;
* требуется минимально допустимая общая "сумма" по каждой из метрик на всю команду;
* в межчеловеческом взаимодействии рождаются какие-то дополнительные эффекты и метрики, которые нужно учитывать;
* некоторые из людей демонстрируют совершенно уникальные свойства.
Какие выводы из этого можно сделать?
* люди на уровне конкретной команды - это не просто абстрактные "ресурсы";
* одни и те же люди в разных командах могут раскрываться совершенно по-разному;
* правильный найм требует гибкости и отхода от шаблонов;
* командный баланс чаще важнее, чем отдельные индивидуумы;
* хороший управленец обязан уметь балансировать между разными уровнями, понимая, когда стоит оперировать простыми числами, а когда уже пора браться за многомерное конструирование.
В общем, приходится иногда довольно много думать и действовать совсем не по учебнику, но это-то и самое интересное :)
#work #management
На уровне большого проекта или компании метрика по тому, кто нужен для того, чтобы какая-то инициатива состоялась, по сути, одномерная: "нам нужно 10 человек, 100 или 1000". Называется просто число, и никто не спрашивает, что это за 100 людей и что они будут делать.
Если спускаться с уровня топ-менеджмента, картинка начинает обрастать деталями: появляются дизайнеры, разработчики, QA, менеджмент среднего звена.
Дальше - больше: фронтендеры, бекендеры, спецы по C#, Angular, джуны, сеньоры и т.п. На этом уровне всё ещё довольно просто, хотя и уже начинают проскакивать нюансы того, как всех этих людей со своими слабыми и сильными сторонами собрать в нечто устойчивое.
Но когда доходишь до уровня конкретной команды, начинается самое интересное. Уже недостаточно просто взять ещё одного бекендера или закрыть пробел с помощью QA. Нужно учесть массу особенностей каждого человека: характер, темп работы, любовь к порядку или хаосу, опыт, стиль общения.
Сложность резко повышается, а процесс сбора и слаживания команды превращается в многомерный конструктор:
* в нем есть десяток-другой "измерений", по которым можно оценивать людей;
* существует разнообразие ролей в команде, в каждой из которых нужно определенное сочетание "метрик" по этим измерениям;
* требуется минимально допустимая общая "сумма" по каждой из метрик на всю команду;
* в межчеловеческом взаимодействии рождаются какие-то дополнительные эффекты и метрики, которые нужно учитывать;
* некоторые из людей демонстрируют совершенно уникальные свойства.
Какие выводы из этого можно сделать?
* люди на уровне конкретной команды - это не просто абстрактные "ресурсы";
* одни и те же люди в разных командах могут раскрываться совершенно по-разному;
* правильный найм требует гибкости и отхода от шаблонов;
* командный баланс чаще важнее, чем отдельные индивидуумы;
* хороший управленец обязан уметь балансировать между разными уровнями, понимая, когда стоит оперировать простыми числами, а когда уже пора браться за многомерное конструирование.
В общем, приходится иногда довольно много думать и действовать совсем не по учебнику, но это-то и самое интересное :)
#work #management