Делегирование.
Терпеть не могу категоричность. Наш мир состоит из тысячи оттенков и из синтеза причин, и миллиона нюансов. Да, что-то можно упростить, иначе не сдвинешься с места. Но до определенных моментов.
Как только я слышу категоричное утверждение я хватаюсь за пистолет во мне просыпается дух противоречий, и я ввязываюсь в споры. Чаще всего. Хотя склько раз уже говорил себе, что это нахер никому не нужно, особенно мне. Видимо я получаю удовольствие от процесса мазохист походу
Итак. Сегодняшний пост по поводу френда drboglav (кстати рекомендую к зафренду ) и его двух постов про "Делегировать". Первый и дополнение с оговорками.
Краткая мысль мысль первого поста "Делегирование как принцип жизни." и "Люди это такие существа, которые не любят когда им что-то делегируют."
Второй пост уточняет, что нельзя делегировать "Процесс построения системы. Контроль над системой. Модернизация процессов."
Поехали. Здесь должна быть картинка про матрицу Эйзенхауэра с указанием на делегирование не более 20 процентов.
Делегировать можно только рутинные процессы, имеющие средний (и ниже) уровень важности, монотонность и стандартность процесса, который можно внятно описать и донести до подчиненного.
Простой, накатанный, формальный, контролируемый. С четко сформулированным результатом иди сроком (там, где результат один и тот же). Но большая часть подобных процессов вписывается в "должностные обязанности". Бухи должны сдавать отчеты, считать зарплату. Производство производить, продажники продавать... Тут стоит главный вопрос, "кто ты" в этой фирме. Делегирование начинается с начальника. Любого уровня. Чем выше начальник, тем больше ты делегируешь "своих" обязанностей. Тем больше тебе есть чего делегировать. Тут проявляется принцип "то что ты можешь делегировать на 70 процентов, ты можешь делегировать целиком". Вроде бы. Но нет, потому что смотри Следствие 1. Делегировать стерссовые процессы(дедлайны, авралы) - верный путь провалить все.
Следствие 1 из предыдущего: Нельзя делегировать критические, важные или срочные процессы.
Да. То, что за что ты несешь ответственность лично. Или же ключевые пункты своего бизнеса - все это должно быть только у тебя. Важные клиенты всегда должны иметь прямой выход на тебя. Неважно ты начальник производства, хозяин, или сейлер. Для всех ключевых клиентов ты доступен по прямому номеру. Для них же надо лично комплектность отправки, работоспособность оборудования и т.д.
Примеры из личного. В бытность нач производства все (ВСЕ КАРЛ) терминалы проверялись мною лично по ключевым параметрам. Любой из клиентов мог мне позвонить. Но не мог сказать, что "ко мне пришло бракованное" (стандартный первичный наезд). Потому что я лично проверял)) Постепенно это знали все. А делать я стал так, потому что подчиненные могут врать. И организовывать независимое ОТК очень сложно, как на уровне нервов так и по деньгам.
Пример из продаж. Директор котнторы всегда размещал свой личный телефон тем, у кого закупался. Позволяло ускорить процессы решения большинства вопросов. Не давало закупать его менеджерам по "взаимовыгодным" для менеджеров условиям.
Следствие 2: Нельзя или невыгодно делегировать гибкие (недетерминированные) процессы.
С одной стороны очевидно, с другой стороны написано кровью. Примеров за 4 ода из жизни проджект манагера отдела R&D могу писать бесконечно. Пожалуй самый живой и простой. Делегировал Сначала написание программы-обработчика (условно сервера) потока штатному программисту. Алгоритм обговорили. Делегировал. Все было неплохо года два. Полгода назад решили перевести программу в ПЛИС. Делегировал второму программисту. Через полгода они зашли в тупик. Потратил неделю на понимание. Вскрылось, что первый программист полностью изменил алгоритм, который вроде работает, но он его не помнит и не понимает от слова "совсем". Целая рабочая неделя ушла у меня на то, чтобы понять что он там намутил. Сейчас он будет это переделывать, а уже приготовил контрольные тесты)) Хорошо, что вскрылось это до дедлайнов.
Если вы контролируете только того, кто контролирует систему - вы не контролируете систему.
Смотри пример выше. Вечный разговор "ты проверял - да конечно"Начинаешь проверять результат и как следствие возить носом по клавиатуре.
Для делегирования нужны полномочия обоих полюсов.
Самая грустная моя мозоль. Чтобы делегирование было эффективным у тебя должен быть кнут и пряник. Работа одним кнутом неэффективна, потому что все скатывается к увиливанию и как следствие к увольнению. Один пряник тоже бесполезен - материальное стимулирование рабоает три месяца. Чаще всего у меня в руках нематериальные стимулы, по жизни. И это большая печаль и тема для отдельного разговора. Но тут же стоит оставить слова "саботаж", "забастовка", "мы можем прикрыть глаза".
Ну и по дополнению. Любая система - живой, постоянно модернизирующийся процесс. Дада, прям по Голдрату. Любая система идет по итеративному циклу. (тут следовало бы поговорить о открытых и закрытых конченых автоматах, но лень). При изменении внешних условий - надо менять систему, при неизменных, модернизировать существующие процессы, не забывая о золотом правиле - "работает - не трожь, но будь готов к поломке заранее"
Как только я слышу категоричное утверждение я хватаюсь за пистолет во мне просыпается дух противоречий, и я ввязываюсь в споры. Чаще всего. Хотя склько раз уже говорил себе, что это нахер никому не нужно, особенно мне. Видимо я получаю удовольствие от процесса мазохист походу
Итак. Сегодняшний пост по поводу френда drboglav (кстати рекомендую к зафренду ) и его двух постов про "Делегировать". Первый и дополнение с оговорками.
Краткая мысль мысль первого поста "Делегирование как принцип жизни." и "Люди это такие существа, которые не любят когда им что-то делегируют."
Второй пост уточняет, что нельзя делегировать "Процесс построения системы. Контроль над системой. Модернизация процессов."
Поехали. Здесь должна быть картинка про матрицу Эйзенхауэра с указанием на делегирование не более 20 процентов.
Делегировать можно только рутинные процессы, имеющие средний (и ниже) уровень важности, монотонность и стандартность процесса, который можно внятно описать и донести до подчиненного.
Простой, накатанный, формальный, контролируемый. С четко сформулированным результатом иди сроком (там, где результат один и тот же). Но большая часть подобных процессов вписывается в "должностные обязанности". Бухи должны сдавать отчеты, считать зарплату. Производство производить, продажники продавать... Тут стоит главный вопрос, "кто ты" в этой фирме. Делегирование начинается с начальника. Любого уровня. Чем выше начальник, тем больше ты делегируешь "своих" обязанностей. Тем больше тебе есть чего делегировать. Тут проявляется принцип "то что ты можешь делегировать на 70 процентов, ты можешь делегировать целиком". Вроде бы. Но нет, потому что смотри Следствие 1. Делегировать стерссовые процессы(дедлайны, авралы) - верный путь провалить все.
Следствие 1 из предыдущего: Нельзя делегировать критические, важные или срочные процессы.
Да. То, что за что ты несешь ответственность лично. Или же ключевые пункты своего бизнеса - все это должно быть только у тебя. Важные клиенты всегда должны иметь прямой выход на тебя. Неважно ты начальник производства, хозяин, или сейлер. Для всех ключевых клиентов ты доступен по прямому номеру. Для них же надо лично комплектность отправки, работоспособность оборудования и т.д.
Примеры из личного. В бытность нач производства все (ВСЕ КАРЛ) терминалы проверялись мною лично по ключевым параметрам. Любой из клиентов мог мне позвонить. Но не мог сказать, что "ко мне пришло бракованное" (стандартный первичный наезд). Потому что я лично проверял)) Постепенно это знали все. А делать я стал так, потому что подчиненные могут врать. И организовывать независимое ОТК очень сложно, как на уровне нервов так и по деньгам.
Пример из продаж. Директор котнторы всегда размещал свой личный телефон тем, у кого закупался. Позволяло ускорить процессы решения большинства вопросов. Не давало закупать его менеджерам по "взаимовыгодным" для менеджеров условиям.
Следствие 2: Нельзя или невыгодно делегировать гибкие (недетерминированные) процессы.
С одной стороны очевидно, с другой стороны написано кровью. Примеров за 4 ода из жизни проджект манагера отдела R&D могу писать бесконечно. Пожалуй самый живой и простой. Делегировал Сначала написание программы-обработчика (условно сервера) потока штатному программисту. Алгоритм обговорили. Делегировал. Все было неплохо года два. Полгода назад решили перевести программу в ПЛИС. Делегировал второму программисту. Через полгода они зашли в тупик. Потратил неделю на понимание. Вскрылось, что первый программист полностью изменил алгоритм, который вроде работает, но он его не помнит и не понимает от слова "совсем". Целая рабочая неделя ушла у меня на то, чтобы понять что он там намутил. Сейчас он будет это переделывать, а уже приготовил контрольные тесты)) Хорошо, что вскрылось это до дедлайнов.
Если вы контролируете только того, кто контролирует систему - вы не контролируете систему.
Смотри пример выше. Вечный разговор "ты проверял - да конечно"Начинаешь проверять результат и как следствие возить носом по клавиатуре.
Для делегирования нужны полномочия обоих полюсов.
Самая грустная моя мозоль. Чтобы делегирование было эффективным у тебя должен быть кнут и пряник. Работа одним кнутом неэффективна, потому что все скатывается к увиливанию и как следствие к увольнению. Один пряник тоже бесполезен - материальное стимулирование рабоает три месяца. Чаще всего у меня в руках нематериальные стимулы, по жизни. И это большая печаль и тема для отдельного разговора. Но тут же стоит оставить слова "саботаж", "забастовка", "мы можем прикрыть глаза".
Ну и по дополнению. Любая система - живой, постоянно модернизирующийся процесс. Дада, прям по Голдрату. Любая система идет по итеративному циклу. (тут следовало бы поговорить о открытых и закрытых конченых автоматах, но лень). При изменении внешних условий - надо менять систему, при неизменных, модернизировать существующие процессы, не забывая о золотом правиле - "работает - не трожь, но будь готов к поломке заранее"