Вы когда-нибудь задумывались, что происходит в больших IT-компаниях? Те самые корпорации, которые гордо рассказывают о своих тысячах сотрудников и невероятных технологиях. Но давайте честно, сколько из этих сотрудников действительно создают продукт? А сколько просто сидят на бесконечных совещаниях, мечтая о кофебрейке?
Секрет в том, что многие из этих компаний — это настоящие бюрократические джунгли, где "руководитель над руководителем" стал нормой. Кто-то руководит процессом, кто-то этим руководителем, а кто-то — руководителем того руководителя. А внизу этой пирамиды? Разработчики. Те самые ребята, которые, как пони, тянут на себе весь проект. Они — двигатели прогресса, кодящие, тестирующие, исправляющие баги и выпускающие обновления.
Хочу поделиться одной историей из опыта. Однажды я работал с крупной IT-компанией, которая запускала новый, небольшой продукт. Команда была впечатляюще большой: десятки менеджеров, координаторов и аналитиков. На одном из первых совещаний, где обсуждалась стратегия, был представлен план на кучу страниц— каждый шаг, каждая деталь были расписаны. Но на вопрос "Кто будет это всё делать?" последовал ответ, который меня ошеломил: "У нас есть пара разработчиков, они справятся". Пара разработчиков на проект, который предполагал участие более 10 менеджеров!
Как вы думаете, что произошло дальше? Проект затянулся, бюджет был перерасходован, а разработчики сидели ночами, пытаясь уложиться в нереалистичные сроки. Это было похоже на то, как если бы пару пони попросили тянуть огромного слона. Они, конечно, справились, но какой ценой?
И возникает закономерный вопрос: а зачем столько руководителей?
Конечно, мы понимаем, что менеджмент — это важно. Но когда встреча менеджеров занимает больше времени, чем разработка продукта, начинаешь задумываться, куда уходят деньги компании? Может, лучше вместо этого нанять ещё пару необходимых специалистов, которые действительно тянут проект вперёд?
Это проблема, присущая именно большим компаниям, где иерархия становится такой сложной, что порой даже сами сотрудники теряются в понимании, кто за что отвечает. Это как играть в "Испорченный телефон", только вместо весёлого результата на выходе — задержка в релизе и выгорание команды.
Что можно с этим сделать? Задать себе простой вопрос: а что если сократить эту пирамиду и дать больше свободы тем, кто действительно создаёт продукт? Может быть, нам не нужно столько ступеней контроля, чтобы развивать идеи и внедрять их в жизнь?
Представьте себе: меньше бюрократии, больше дела. Разработчики работают, а компания растёт и развивается. А те, кто не знает, что делать на совещаниях, наконец-то смогут посвятить своё время чему-то полезному. Например, научиться верстать.
Итак, стоит ли пересмотреть подход к управлению в большим IT-компаниям? Не пора ли сделать команды более эффективными?
