Больше не значит лучше: почему маленькие команды разработчиков – ключ к инновациям

Раньше человечество часто совершало скачки в своем прогрессе. Инженеры, ученые и производители делали смелые шаги, которые продвигали нас вперед. Меньше 10 лет прошло с момента разработки реактивных двигателей до запуска сверхзвукового самолета, и 20 лет – с момента появления первого компьютера до разработки системы, которая доставит нас на ЛУНу.

Что же происходит теперь? Многие команды инженеров продвигаются очень медленно, делая маленькие шаги, несмотря на наличие существенных ресурсов. Будущее – за небольшими командами, члены которых поддерживают друг друга, и быстро принимают решения.

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

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

Хорошим примером того, что даже самым перспективным проектам нужно грамотное управление, является Microsoft Bob. Это ПО в 1995 году должно было заменить стандартный диспетчер программ Windows и предложить пользователю удобный интерфейс. В итоге, Microsoft Bob был изъят с рынка через год после релиза из-за того, что пользователи просто не смогли оценить его достоинства. Диспетчер для выполнения своих задач требовал больше производительности, чем мог предоставить любой компьютер того времени. Одним словом, команда разработчиков так и не смогла добиться поставленной перед ними цели.

Еще одной иллюстрацией подобного провала стал проект IBM 360 Project, о котором его руководитель Фред Брукс написал книгу The Mythical Man Month. Во время работы Брукс пришел к интересному выводу – чем больше увеличивалось количество программистов в 360 Project, тем быстрее снижалась общая эффективность команды, поскольку внушительный штат разработчиков требовал большого количества непродуктивных координаторов. Именно эта мысль и легла в основу книги. Одним словом, слишком крупные коллективы только ухудшают проблемы компаний.

Чтобы избежать досадных ошибок, стоит обратить внимание на тех же Стива Джобса и Стива Возняка, которые вдвоем создавали Apple в гараже и контролировали все – от внешнего вида материнской платы до выбора оттенка корпуса Apple II. То же самое касается WhatApp. Основатель мессенджера Ян Кум большую часть проекта реализовал сам. Его компания сознательно оставалась маленькой, потому что хотела сосредоточиться на продукте, а не на управлении. Когда в феврале 2014 году WhatsApp был продан Facebook, в его команде было всего 100 человек.

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

Крупные компании сегодня постепенно отказываются от больших команд. Так, GlaxoSmithKline разбила весь штат исследователей на группы от 8 до 60 человек. Это далеко не новый подход. Еще в 1970 году небольшая группа инженеров Volkswagen в свободное время решила модернизировать Golf. В итоге, им удалось создать Golf GTI, который стал одним из самых выдающихся автомобилей всех времен. Первый американский реактивный истребитель P-80 Shooting Star был разработан командой из 28 инженеров, у которых не было менеджмента и графиков. Но это не помешало им сделать шедевр.

С соблазном бросить большие средства и большое количество людей на проект важно и нужно бороться. Маленькие команды – важный инструмент, которые поможет создавать инновации.