Изоморфизм в менеджменте

С завидной периодичностью возникают интернет-войны на тему “Нужна ли математика программистам”. А мне хочется на одном примере показать, как математическая подготовка помогает лично мне в моей менеджерской работе.

Больше всего помогают не какие-то навыки вроде умения взятия интегралов или знания правила Лопиталя, а очень основополагающие понятия и способы мышления, которые как раз математика и формирует. Вот, например, чудесное понятие изоморфизма. Это когда мы знаем, что два объекта являются разными, но для нас они идентичны и мы работаем с ними как с одним и тем же объектом. Как это в принципе может помочь? Давайте рассмотрим на примере.

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

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

1. Человек пропустил митинги из-за случайностей. Тогда можно этому человеку доверять дальше и договориться, что такое не повторится.
2. Человек несерьёзно относится к своей работе и пропустил митинги намеренно. Тогда доверять человеку нельзя.

И дальше менеджер тратит время на выяснение подробностей произошедшего, чтобы понять, какой из этих двух вариантов имел место. Он спрашивает о причинах самого подчинённого, опрашивает коллег, анализирует косвенные признаки и т.д. Этот подход имеет следующие недостатки:

1. Тратится много времени. На решение этой проблемы надо тратить минут 30, не больше. Проводить расследование времени не будет.
2. Вся активность направлена “в прошлое”. Мы пытаемся анализировать, как оно было, не работая над тем, как оно будет. В результате, например, мы можем выяснить, то у человека и правда была череда случайных событий, из-за которых он пропускал митинги, но следующий митинг он пропустит нарочно. Потому что его достало.
3. Вопрос ставится о доверии или недоверии, поэтому всё общение очень эмоциональное и если человека придётся убрать из проекта, то отношения будут разрушены. Да и даже если человек останется в проекте, всё равно он будет помнить, что ему пришлось доказывать, что он не саботажник. Нормальными такие отношения назвать нельзя.
4. В абсолютном большинстве случаев чётко разделить эти две альтернативы просто нельзя. Одновременно имеют место и несобранность человека, и какие-то внешние факторы.

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

1. Сказать заказчику, что имела место нелепая случайность и вы лично проконтроллируете, чтобы в будущем всё было зашибись. Можно и часть реального плана действий заказчику рассказать, чтоб он видел, что вы и правда работаете.
2. Сказать подчинённому, что эскалация из-за этих пропусков митингв очень серьёзная, но, чтоб он не волновался, и вы его поддержите, даже если в будущем заказчик потребует его замены. Но человек сам должен приложить усилия, чтоб такие накладки не повторялись.
3. Для минимизации рисков вместе с подчинённым выработать план мероприятий. Например, митинговать из дома, чтоб не рисковать застрять в утренней пробке. Или митинговать из офиса, чтоб спастись от пробок вечерних. Или купить 3G модем и митинговать через ноут, откуда угодно. Или сдвинуть время митингов. Или готовить какую-то информацию, чтобы его мог заменить любой из команды. Или митинги сделать более редкими, чтоб нагрузка от них была меньше. Или сделать митинги более частыми и в ненапряжное для заказчика время, чтобы каждый из них не был столь критичным. Или ещё что-нибудь. Вариантов может быть очень большое количество.
4. Параллельно работать над планом по замене этого сотрудника на другого, потому что развитие событий может быть самым разным.
5. Уведомить всех заинтересованных лиц о том, что у вас может быть замена сотрудника (HR, другие менеджеры вашего уровня, менеджеры более высого уровня, это зависит от процессов компании).

На случай одного варианта план есть. А что на случай другого варианта? Ну решите вы заменить ключевого человека, откуда вы возьмёте замену? Если бы это было так просто, это не было бы проблемой. В тех областях, где менять человека легко, сотрудников меняют и за случайные промашки. А в IT даже если вы придёте с жалобой на ненадёжного человека к своему начальству, вам скажут, что а) С надёжными людьми и высокооплачиваемые менеджеры не нужны б) Изменить отношение не всегда возможно, но всегда нужно попробовать. И в результате у вас получится абсолютно такой же план, как и в первом случае.

Поэтому сразу можно человека не подозревать ни в каком саботаже и работать по вышепридведённому плану. Варианты, которые пытался рассматривать менеджер, не являются одинаковыми, но являются изоморфными. Это действительно не одно и то же, саботирует ли сотрудник работу или не умеет минимизировать влияние случайностей. Но эти варианты можно считать не отличимыми. Мы сразу верим человеку (реально верим) и начинаем вместе работать над проблемой. Если сотрудник саботажник, у него будет шанс исправиться. В любом случае нет никакого конфликта, в который надо эмоционально вовлекаться. Есть рабочая проблема. При любом исходе с сотрудником отношения не испорчены безнадёжно, а у менеджера риски минимизированы.

Самое ценное в этом подходе, это знание о самом этом подходе. Любой разработчик, который один раз серьёзно разобрался в разнице между Equals() и ReferenceEquals(), потом автоматически улавливает разницу между равными и идентичными объектами. Если менджер знает, что даже разные варианты могут быть изоморфными, то он эти изоморфные варианты может вычленять и готовить реально работающие решения для них. Это экономит время, это избавляет от ошибок. Поэтому тот склад ума, который формирует математика, я считаю гораздо более важным для менеджера чем арифметические навыки в подсчёте бюджетов.