После того как вы выполнили большую часть перехода программно, разработайте инструменты самообслуживания и документацию, чтобы команды могли вносить необходимые изменения, не застревая на месте. Лучшие инструменты перехода – постепенные и обратимые: пользователи должны иметь возможность немедленно откатиться к предыдущей версии. Если что-то пойдет не так. И инструменты должны быть понятными и однозначными, чтобы снизить риск при выборе конкретного пути перехода.
Отнеситесь к документации и инструментам самообслуживания как к продуктам: понаблюдайте за тем, как несколько команд следуют вашим инструкциям, а затем доработайте их. Подключите еще одну команду. Повторите. Потратив дополнительные два дня на то, чтобы привести документацию в порядок, а инструменты сделать интуитивно понятными, вы сэкономите годы при больших переходах. Обязательно сделайте это!
Последним этапом перехода является отказ от устаревшей системы, которую вы заменили. Он требует стопроцентного внедрения, а это может быть весьма непросто.
Начните с остановки кровотечения, то есть сделайте так, чтобы весь недавно написанный код отвечал новым требованиям. Улучшите ваши линты[17] и инструменты статистического анализа кода (25) или обновите документацию и инструменты самообслуживания. Это всегда первый шаг, потому что время из вашего врага превращается в друга. Вместо того чтобы по умолчанию отставать, теперь вы по умолчанию добиваетесь прогресса.
Хорошо, теперь вы должны начать генерировать тикеты для отслеживания прогресса и установить механизм, который передает статус перехода командам, которым необходимо выполнить переход, и общей структуре управления. Важно дать более широкий контекст управления переходом, потому что менеджеры – это люди, которые должны расставлять приоритеты в процессе. Если команда не работает над переходом, это обычно происходит потому, что их руководство не расставило приоритеты должным образом.
Тут вы уже близитесь к завершению, но остается длинный хвост непонятной или нераспределенной работы. Теперь подход должен быть такой: закончите переход сами. Это не обязательно весело, но для достижения стопроцентного результата потребуется, чтобы команда, возглавляющая переход, сама покопалась в укромных уголках и закромах, вникнув во все детали.
Мой последний совет по переходам сосредоточен на признании. Важно отмечать переходы, пока они продолжаются, но большую часть празднования и признания нужно оставить до успешного завершения. В частности, запуск, но не завершение перехода часто влечет за собой значительный технический долг, поэтому будьте осторожны со стимулами и признанием заслуг, чтобы избежать ложных поощрений.
3.7. Проведение инженерной реорганизации
Я считаю, что при работе в быстрорастущих компаниях важны два управленческих навыка, которые оказывают непропорционально большое влияние на успех всей организации: удешевление технического перехода и проведение чистых реорганизаций. Делайте и то и другое как следует, и вы сможете избавиться от постоянного ощущения, что надо куда-то сломя голову нестись, и потратите время более продуктивно.
Из этих двух навыков управление организационными изменениями является более общим, поэтому давайте рассмотрим слегка структурированную основу для (повторного) проектирования инженерной организации.
ПРИ РАБОТЕ В БЫСТРОРАСТУЩИХ КОМПАНИЯХ ВАЖНЫ ДВА УПРАВЛЕНЧЕСКИХ НАВЫКА, КОТОРЫЕ ОКАЗЫВАЮТ НЕПРОПОРЦИОНАЛЬНО БОЛЬШОЕ ВЛИЯНИЕ НА УСПЕХ ВСЕЙ ОРГАНИЗАЦИИ: УДЕШЕВЛЕНИЕ ТЕХНИЧЕСКОГО ПЕРЕХОДА И ПРОВЕДЕНИЕ ЧИСТЫХ РЕОРГАНИЗАЦИЙ.
Предостережение: это скорее пища для размышлений, чем готовый рецепт!
Вот мой подход к планированию организационных изменений:
1. Убедитесь, что организационные изменения – это правильный инструмент.
2. Определите количество сотрудников на ближайший год.
3. Установите целевое соотношение руководителей и подчиненных.
4. Определите логические команды и группы команд.
5. Спланируйте штатное расписание для команд и групп.
6. Возьмите на себя обязательство двигаться вперед.
7. Запустите изменения.
Теперь давайте немного углубимся в каждый из пунктов.
3.7.1. Является ли реорганизация правильным инструментом?
Есть два вида оптимальной реорганизации:
• Та, что решает структурную проблему.
• Та, что вообще не происходит.
Хуже всего реорганизация, которую начинают, чтобы избежать проблемы управления персоналом.
Вот мой контрольный список для определения уместности реорганизации:
1. Является ли проблема структурной? Организационные изменения дают возможность улучшить коммуникацию, уменьшить трудности при принятии решений и сконцентрировать внимание. Если вы хотите внедрить другие изменения, подумайте, нет ли более простого подхода.
Рисунок 3.6 Реструктуризация организаций по мере их роста.
2. Проводите ли вы реорганизацию, чтобы не работать с человеком, с которым разорвали отношения? Менеджмент – это профессия, в которой карма всегда настигает, и вам лучше разобраться с основной проблемой, а не обходить ее.
3. Проблема уже существует? Лучше подождать, пока проблема возникнет, нежели заранее внедрять решение, потому что предсказать будущие проблемы чрезвычайно трудно. Даже если вы правы в том, что эта проблема возникнет, в конечном итоге вас может раньше накрыть другая проблема.
4. Являются ли текущие условия временными? Может у вас начался тяжелый, но временный кризисный период, или же вы делаете что-то, что не собираетесь повторять? Если это так, то, возможно, проще заняться решением и переосмыслением проблемы с другой стороны и избежать реорганизации, так как сам сбой носит временный характер.
Итак, вы все еще думаете, что вам нужна реорганизация.
ЕСТЬ ДВА ВИДА ОПТИМАЛЬНОЙ РЕОРГАНИЗАЦИИ:
• ТА, ЧТО РЕШАЕТ СТРУКТУРНУЮ ПРОБЛЕМУ.
• ТА, ЧТО ВООБЩЕ НЕ ПРОИСХОДИТ.
3.7.2. Определение количества сотрудников, необходимых проекту в ближайший год
Первым шагом организационного проектирования является приблизительное определение общего размера команды. Я рекомендую рассмотреть это число с трех или четырех разных точек зрения:
1. Оптимистичное число, основанное на том, что едва ли возможно.
2. Число, основанное на «естественном размере» вашей организации. Если каждая команда полностью укомплектована персоналом и все главные позиции закрыты.
3. Реалистичное число, основанное на исторических показателях найма.
Затем проанализируйте все и выведите единое число.
ОПРЕДЕЛЕНИЕ ПРИБЛИЗИТЕЛЬНОЙ ЧИСЛЕННОСТИ ПЕРСОНАЛА ЗА ГОД ПОМОГАЕТ ИЗБЕЖАТЬ ЧРЕЗМЕРНОЙ ОПТИМИЗАЦИИ В РАМКАХ КОНКРЕТНОЙ СИТУАЦИИ И С УЧЕТОМ ЧИСЛА СОТРУДНИКОВ, С КОТОРЫМИ ВЫ УЖЕ РАБОТАЕТЕ.
Если вы не вносили в процесс значимых изменений, вполне вероятно, что историческая тенденция близка к реальной, и вам, скорее всего, следует ориентироваться именно на нее (и мне кажется, что список изменений, которые существенно влияют на объем найма, весьма невелик).
Определение приблизительной численности персонала за год помогает избежать чрезмерной оптимизации в рамках конкретной ситуации и с учетом числа сотрудников, с которыми вы уже работаете. Организационные изменения на большинство людей действуют так губительно, что я все больше убеждаюсь: начинать нужно не с перевода ключевых сотрудников, а с изменения сферы деятельности команд, не ломая их состава.
3.7.3 Соотношение менеджеров и инженеров
Как только у вас будет прогноз по численности персонала, нужно определить, сколько человек должен, на ваш взгляд, вести каждый менеджер. Это число зависит от роли ведущего инженера в компании. Если на ведущих инженеров ложится практическая техническая работа, то их команды, скорее всего, должны состоять из трех-пяти инженеров (если только вы не имеете дело со сплоченной командой, которая давно отлично сработалась: в этом случае все становится очень специфичным, и обобщать такой опыт трудно).
В остальном обычно ориентируются на пять-восемь инженеров, в зависимости от опыта сотрудников. Если вы планируете более чем восемь инженеров на одного менеджера, то стоит задуматься о том, почему вы считаете, что ваши менеджеры способны выдерживать значительно более высокую нагрузку, чем в среднем по отрасли. Они являются исключительно опытными? Ваши ожидания относительно качества ниже, чем обычно?
В любом случае, выберите число, скорее всего, в диапазоне от шести до восьми.
3.7.4. Определение команд и групп
Теперь, когда у вас есть целевой размер организации и целевое соотношение менеджеров и инженеров, пришло время определить общую форму вашей организации!
Предположим, что у вас работают 35 инженеров, а на одного менеджера приходится 7 инженеров.
35 / 7 = 5 менеджеров
Log7(35) ≈ 1.8 верхнеуровневого менеджера или менеджера второй степени
В растущей компании вам, как правило, следует округлять количество менеджеров, поскольку это расчет для состояния «в покое», а ваша организация будет живой, развивающейся.
Полученные цифры пригодятся для определения общего количества команд и групп команд, которые у вас должны быть.
В первом случае, с 35 инженерами, вам понадобится от одной до трех групп, состоящих в общей сложности из пяти-шести команд.
Отлично, у вас на руках все данные. Задайте себе еще несколько дополнительных вопросов:
1. Можете ли вы написать четкую декларацию миссии для каждой команды?
2. Были бы вы лично рады быть членом каждой из команд, а также стать менеджером каждой из этих команд?
3. Расположите команды, которые работают вместе (особенно те, у которых взаимодействие страдает), как можно ближе друг к другу. Это сводит к минимуму возможность эскалации во время разногласий, позволяя судьям-посредникам иметь достаточный контекст. Кроме того, плохие рабочие отношения – это, как правило, побочный продукт информационных пробелов, и ничто не заполняет их быстрее, чем близость.
4. Можете ли вы определить четкие интерфейсы для каждой команды?
5. Можете ли вы перечислить сферы ответственности каждой команды?
6. Удалось ли вам создать карту задач без пробелов во владении проектами, чтобы ответственность за каждую задачу лежала на конкретной команде? Старайтесь избегать неявного создания таких пробелов. Однако если вам нужно создать явные пробелы во владении проектами, это лучшее решение (по сути, это определение не укомплектованных персоналом команд).
7. Есть ли у вас убедительные кандидатуры для каждой из этих команд?
8. Есть ли шанс, что вы чрезмерно полагаетесь на отдельных людей, а не создаете разумную структуру?
Это наименее шаблонный аспект организационного проектирования. Если возможно, сейчас самое время обратиться за идеями к знакомым и ознакомиться с опытом аналогичных организаций.
3.7.5. Определение кадрового состава команд и групп
С помощью организационной структуры и планирования численности персонала вы можете примерно определить, когда вам потребуется нанять человека на каждую из технических и управленческих должностей.
У вас есть четыре источника кандидатов:
1. Члены команды, которые готовы занять свободные позиции прямо сейчас.
2. Члены команды, которые могут вырасти и занять свободные позиции в установленные сроки.
3. Переводы внутри компании.
4. Внешние сотрудники, которые уже обладают необходимыми навыками.
Вероятно, это пошаговый список того, как вы должны стараться заполнить ключевые роли. В конечном итоге вам нужны люди, которые уже знакомы с корпоративной культурой, а кроме того реорганизацию, которая зависит от еще не нанятых людей, гораздо труднее успешно осуществить.
В частности, я бы рекомендовал иметь под рукой электронную таблицу, в которой перечислены все сотрудники или соискатели, их текущая и будущая роль. Случайное упущение и неучет кого-то – главный грех реорганизации.
3.7.6. Обязательство двигаться вперед
Пришло время принять окончательное решение. Вот несколько вопросов, которые нужно задать себе, прежде чем вы решите полностью посвятить себя делу:
1. Являются ли изменения значимыми и позитивными?
2. Будет ли новая структура существовать более шести месяцев?
3. Какие проблемы вы обнаружили во время проектирования?
4. Что может спровоцировать следующую реорганизацию?
5. На кого это повлияет сильнее всего?
После того как вы ответите на эти вопросы, убедитесь, что не только разобрались с внутренними сомнениями, но и получили согласие коллег и руководства. Организационные изменения откатить будет сложно, поэтому все должны быть готовы двигаться вперед, даже если на пути возникнут проблемы (что, если верить истории, почти всегда случается).
3.7.7. Внедрение изменений
Заключительный и часто самый дискомфортный этап реорганизации – это ее развертывание. Есть три ключевых элемента для эффективного внедрения изменений:
1. Объяснение причин, побудивших к реорганизации.
2. Письменное разъяснение, как это повлияет на каждого человека и команду.
3. Открытость и сопереживание, которые помогут справиться с разочарованием людям, которых реорганизация затронет.
В общем, по факту тактика такая:
1. Сначала обсудите реорганизацию наедине с людьми, которым придется тяжелее всего.
2. Убедитесь, что менеджеры и другие ключевые сотрудники готовы объяснять причины изменений своим подчиненным.
3. Отправьте электронное письмо, подробно описав изменения.
4. Будьте открыты для обсуждения.
5. При необходимости организуйте общую коммуникацию, но все же постарайтесь этого избежать. Люди плохо справляются с обсуждениями в больших группах, так что лучше вести дискуссии в узком кругу.
6. Если с кем-то вам не удается поговорить один на один – старайтесь лучше.
Иии… кончено! Вы провели инженерную реорганизацию. Искренне надеюсь, что вам нескоро надо будет повторять это.
В заключение отметим, что организация – это одновременно (1) совокупность людей и (2) воплощение идеи отдельно от составляющих ее индивидов. Нельзя рассуждать об организациях только с одной точки зрения. Существует множество чрезвычайно обоснованных, различных способов планирования реорганизации. Так что приведенные выше шаги воспринимайте как идеи, как базовую модель, а не как окончательный план.
ОРГАНИЗАЦИЯ – ЭТО ОДНОВРЕМЕННО (1) СОВОКУПНОСТЬ ЛЮДЕЙ И (2) ВОПЛОЩЕНИЕ ИДЕИ ОТДЕЛЬНО ОТ СОСТАВЛЯЮЩИХ ЕЕ ИНДИВИДОВ. НЕЛЬЗЯ РАССУЖДАТЬ ОБ ОРГАНИЗАЦИЯХ ТОЛЬКО С ОДНОЙ ТОЧКИ ЗРЕНИЯ.