От разработчика до руководителя. Менеджмент для IT-специалистов - читать онлайн книгу. Автор: Камиль Фурнье cтр.№ 69

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

Такая группа обычно бывает сравнительно небольшой и однородной. Однородность группы необходима, чтобы обеспечить ее членов общим языком взаимодействия. Люди с различными бэкграундами могут придать ценность группе, ориентированной на увеличение знаний членов, имеющих возможность учиться на опыте других. Но слишком большие различия между членами группы, ориентированной только на решение определенной задачи, обычно приводят лишь к тому, что они перестают понимать друг друга. Коллеги с различным опытом начинают по-разному интерпретировать слова и действия друг друга. У них обычно разные ожидания, связанные с поведением других членов группы, и действия друг друга они оценивают исходя из разных критериев. Если каждый хорошо знает других членов группы, то такие различия могли бы быть нивелированы. На самом же деле они обычно только приводят к недопониманию внутри группы и бесконечным часам, потраченным на погашение неожиданных конфликтов.

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

В такой группе должен быть невысокий уровень профессиональной специализации. В группе не каждый член должен быть в состоянии делать все, но все должно быть выполнимо более чем одним человеком. Таким образом, в группе нет незаменимых людей. До какой-то степени все они становятся заменимыми частями единого целого.

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

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

Организационная бесструктурность часто проявляется в технических решениях и в процессах. Существуют вполне определенные причины того, что на ранних этапах существования стартапов в области ПО часто встречается так называемый спагетти-код20. Когда работа по написанию кода делается только для того, чтобы выполнить ближайшую задачу в виде объединенной кодовой базы, созданной группой программистов, то частый результат — не продуманная структура, а точечные действия, помогающие только достичь промежуточного результата и двигаться вперед. Неудивительно, что, желая сделать красивый масштабируемый код, вы вынуждены прибегать к рефакторингу, то есть контролируемой операции улучшения без изменения функциональности. Ведь рефакторинг в конце концов и предназначен, чтобы идентифицировать и высветить структуру кода и очистить его, сделать легко читаемым и удобным для работы.

В этом, коротко говоря, и состоит ценность структурированности. Структурирование — то, как мы расширяем и разнообразим решаемые задачи, а также принимаем на себя более сложные и долгосрочные. Мы структурируем ПО, наши команды и процессы. Точно так же как сильные инженеры-программисты могут определять и формировать структуры информационных систем, сильные руководители могут создавать организационную структуру в командах и процессах. При этом руководители поступают так, чтобы обеспечить достижение долгосрочных целей команды и побудить работников на максимально эффективную работу.

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

В небольших компаниях, напротив, более распространен запоздалый ввод элементов организационной структуризации. Проблемы в таких компаниях возникают незаметно. Один человек привыкает принимать все решения и часто их меняет. Такая стратегия работает в мини-организации, где есть только он и еще пара людей. Но когда такая схема применяется при работе с командой из 10, 20, а то и 50 человек, то сразу становится заметным высокий уровень взаимного непонимания и затраченных впустую усилий. Цена изменения решений становится все более высокой.

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