Не секрет, что айтишники и менеджеры (а особенно – айтишные менеджеры) очень любят проходить различные тесты и заполнять анкеты. Давайте проведём небольшой эксперимент.
Попробуйте выбрать из нижеследующих утверждений те, с которыми вы согласны:
- У меня постоянно не хватает времени, чтобы всё успеть.
- Я бы передал работу другому, да некому.
- Уж лучше я сделаю сам, но наверняка. И переделывать не придётся.
-
Все кругом
идиотыне обладают достаточной компетенцией, чтобы им что-то поручить. - Объяснять и ставить задачу дольше, чем просто сделать работу.
-
У меня есть ценные кадры, но я жду, пока они подрастут и
улетятнаберутся опыта.
Если вы выбрали три и более пункта, то нам есть о чём поговорить.
Несмотря на кажущуюся логичность приведённых выше утверждений, корень проблемы (нет, мы не про ITIL, поэтому такой оборот вполне допустим) может быть вовсе не в нехватке ресурсов. Мне кажется, что переход от исполнителя к руководителю – это качественное изменение. Нельзя назавтра проснуться грамотным начальником (не по должности, а по сути), это не одномоментный переход и он не случится сам собой. Его нужно готовить и воспитывать в себе, в том числе через ежедневные дела, задачи, структуры, взаимодействия.
Особенно ярко это видно на деловых играх. Там времени мало, а работы – много. В каждой игре есть роли управляющие и роли исполнительские. Разделение между ними, точнее отсутствие разделения, очень заметно.
Вот пример из игры "Apollo-13", которую я недавно проводил. Есть первая линия, есть вторая. Есть менеджер инцидентов. Команда решила построить процесс таким образом, чтобы менеджер выступал в роли маршрутизатора заявок – так как ничего неизвестно о предметной области, то пусть менеджер и разбирается кому что назначать из приходящего. Разумное вроде бы решение, но есть нюанс – вся та работа, которую должен был выполнять менеджер инцидентов, а именно: отслеживание хода работ других участников, эскалация и "разруливание" сложных случаев, выявление узких мест и перераспределение ресурсов, понимание сколько работы делается и укладываемся ли в SLA, – всё это, разумеется, осталось без должного внимания. Результат – решено только 44% всех инцидентов при среднем времени решения почти вдвое выше, чем оговорено в SLA.
Другой типичный случай – это руководитель всей группы, который не только сам строит процесс для всех остальных (что от него, вообще говоря, не ожидается), но и потом "помогает" всем по нему работать, игнорируя им же придуманные правила и вмешиваясь в задачи каждого участника цепочки. Замедление работ, потеря заявок, общий хаос – всё это наглядно демонстрирует "работу рядом с шефом", а точнее – работу шефа вместо тебя.
Получается, что границу-то надо проводить.
Основная сложность здесь, на мой взгляд, в том, что в небольших коллективах невозможно стать "выделенным начальником" и всю работу "раздавать". Нужен баланс, позволяющий каждому делать то, в чём он наиболее силён и эффективен. Поделиться работой наполовину – огромная трудность и очень ценный навык хорошего руководителя.
Вот мы и подошли к проблеме делегирования. Продолжим?
– Джонсон, я верю в силу делегирования полномочий,
поэтому поручаю Вам уволить Спенсера, Хансена и Вильямса.
Из моего опыта, для того, чтобы делегирование работало, команду надо учить и совершенствовать. И дело не только в профессиональных навыках команды.
Считаю следующие факторы наиболее существенными:
1. открытый и быстрый обмен информацией;
2. создание базы знаний, накапливание и легкий доступ до знаний;
3. повышение универсальности специалистов: знания не только в своей предметной области, но и углубление знаний в смежных областях;
4. доверие между членами команды.