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

Оценка своей роли

Если вы управляете кораблем, правильно оценивайте его размеры. Они определяются количеством сотрудников компании, длительностью ее существования и размером бизнеса (количеством производимого ПО, процессами и др.), а также уровнем порога рисков.

Персонал

Чем больше работников в вашей компании, тем более проработанную организационную структуру она должна иметь, чтобы сориентировать всех в правильном направлении. Руководители, желающие обладать контролем над организацией, нуждаются в более совершенной структуре, обеспечивающей выполнение их желаний. Современные компании сосредоточивают структурные решения в основном на выработке и постановке целей, а не на том, чтобы все решения принимались наверху. И нельзя недооценивать роль организационной структуры в том, что касается постановки целей и эффективного доведения их до людей.

Возраст компании

Чем дольше существует компания, тем больше в ней упрочившихся норм и обычаев. С другой стороны, чем старше компания, тем больше у нее шансов на выживание.

Размеры существующей инфраструктуры

Если в вашей компании немного устоявшихся правил, связанных с бизнесом (например, «вот так мы устанавливаем цены»), и немного кодово-программной и материальной инфраструктуры (магазины, склады и или материально-технические фонды), то она меньше нуждается в организационно-структурных мероприятиях. С другой стороны, чем больше у вас правил бизнеса и материальной инфраструктуры, тем нужнее ясное понимание того, как с ними обращаться.

Порог рисков

Работает ли ваша компания в отрасли с высоким государственным регулированием? Много ли вы потеряете в случае ошибок? Или вы работаете в отрасли с низкой степенью регулирования? Организационная структура и процессы в вашей компании должны учитывать этот фактор. Чем больше людей задействовано в бизнесе и чем он объемнее, тем меньше рисков вы захотите на себя взять даже без регулирующих ограничений.

Организационная структура компании растет по мере ее роста и возраста. Есть даже закон, описывающий эту связь. Он приводится в книге Джона Галла «Системантика»21:

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

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

Мой совет руководителям прост: когда случаются неудачи, исследуйте все аспекты окружающей действительности, приведшие к ним. То, что вы увидите, станет возможностью совершенствовать организационную структуру предприятия либо за счет создания дополнительных вариантов, либо за счет отказа от некоторых. Обдумайте вопрос, как часто вашу организацию постигают неудачи, сколько они стоят, и постарайтесь вынести оптимальное суждение относительно необходимых перемен. Использование неудачи как компаса для развития позволяет применять организационную структуру на нужном уровне. Если неуспех случается только в части системы (например, в одной из команд), можно осуществить структурные изменения только там, не затрагивая всей организации. А как с анализом успехов? Что же, вы можете кое-чему научиться на примере успеха, но, как правило, он плохой учитель. Как ни смешно, хотя судьба зачастую играет одинаковую роль и при успехе, и при неудаче, мы в большинстве случаев приписываем неуспех невезению, а успех — собственным действиям. Как гласит закон Галла, работающая простая система может развиться в систему сложную. Но это не означает, что применение уроков, полученных из успешной сложной системы, может позволить нам повторить успехи в других местах. Будучи людьми, мы склонны винить в неудачах фатум до тех пор, пока становится невозможным игнорировать собственную роль в них. Поэтому мы не слишком торопимся реорганизовывать структуру команд на основе опыта неудач. Напротив, успех заставляет нас верить, что везение позволит и дальше достигать высот. Но помните, что необходимо реально оценивать шансы на улучшение дел при более широком применении уроков успеха. Не забывайте, что для повторения успеха нужно хорошо понимать необходимый контекст.

В этом вопросе важную роль играют возраст компании и размер команды. Если вы работаете в организации, существующей уже в течение приличного времени и имеющей шансы на дальнейшее существование, эксперименты с организационной структурой (расширение или сокращение), нацеленные на повышение эффективности, могут быть очень полезны, даже если на первом этапе они окажутся весьма затратными. Это часть сделки. Обучение редко обходится бесплатно. Анализ ситуации и стремление к позитивным результатам требуют времени. Ваше время в будущем стоит меньше, чем в настоящем. Поэтому не следует слишком беспокоиться об экономии времени в будущем. То, что компания большая, имеет солидную историю и стабильна, еще не означает, что ее структура может быть такой жесткой и неизменной, как вы хотите. Изменения в технологиях часто делают рискованные в прошлом действия более безопасными по сравнению с неповоротливыми вариантами. Хороший пример — частота релизов. Частые релизы долго были трудным и дорогим делом. В значительной степени это происходило потому, что компании выпускали свое ПО потребителю в неизменном виде. Сегодня же, когда программное обеспечение стало услугой (SaaS)22, недочеты в нем могут быть легко устранены уже по ходу использования. Поэтому риски, связанные с изданием ПО, значительно снижаются по сравнению с небыстрой разработкой, что негативно влияет на конкурентоспособность продукции. Привязанность к старым понятиям структурности мешает многим людям воспринимать ее как таковую. Но если вы не признаете необходимость организационной структуры тогда, когда она нужна, то дела у вас могут пойти совсем плохо.

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