Менеджмент

3. ЦИТАТА одного из основателей «Я предприниматель и меня интересует развитие проекта. Он имеет большую социальную значимость (у нас 168 тысяч человек в базе), у нас сильный ИТ продукт, который кратно рос, и по-прежнему большие перспективы. Когда я согласился на сделку с Авито, я ожидал синергии и ускорения развития, однако окунулся в море бюрократии, симуляции активной работы, а вот теперь и надуманный иск схлопотал».

4. Что говорят СМИ:

4.1. Истцы реально волки бизнеса, закаленные в девяностые.

4.2. Основатели – типичные ребята про «успешный успех» и модный стартап-движ - «строим персональный бренд» серийного предпринимателя с атрибутами показной роскоши, триатлоном, «блэкджеком и шлюхами». К тому же с примесью бизнесмолодости.

4.3. Есть ощущение, что стартаперы шли по классической схеме венчурного рынка — процесс ради процесса. Тратим инвестиционные деньги, делаем лицо, фиксируем убытки, расходимся.

5. А теперь серьезные дяди отказываются разделять риски с юными учредителями стартапов и действуют так, как они привыкли — «с паршивой овцы хоть шерсти клок, просудим, надавим и отожмем хоть что-то».

МОИ РАЗМЫШЛЕНИЯ:

Я никогда не был сторонником подобного «успешного успеха», ибо убеждён, что в любом бизнесе нужно обладать уникальными и глубокими знаниями. Так что ждём судов и наблюдаем за развитием событий.

МОИ РАЗМЫШЛЕНИЯ:

1. Люди идут учиться с благими намерениями, для реализации своего потенциала. Что они получают во время обучения? Явно не то, что им поможет стать профессионалом.

2. Устаревшие методы образования – это одна из основных проблем маркетинга в целом. Как можно преподавать, если у тебя самого полевого опыта либо нет вообще, либо он десятилетней давности? Посмотрите на засилье «говорящих голов» на всех деловых конференциях, бизнес-завтраках, семинарах. Кто они? Я занимаюсь экспертной деятельностью, имея за плечами 23-х летний опыт построения собственного бизнеса с нуля, и я знаю всего несколько экспертов, к мнению которых стоит прислушиваться.

3. Отсутствие практики в обучении – ещё одна кочка на поле профессиональных знаний. Помню момент, когда ко мне в компанию пришла работать моя дочь, закончившая один из ведущих ВУЗов страны. Впервые посетив реально работающий дистрибьюторский склад, она заявила «Нас учили другому».

2) Работа по неполному/нечёткому алгоритму (целедостижение).

Есть ресурсы, есть цель, но как (путь/техпроцесс) выбирает исполнитель (сотрудник).

Т.е. по сути аналог «задачи по поисковой оптимизации» где надо найти оптимальную траекторию зная исходное и понятное состояние.

3) Пункты 3 и 4 можно объединить в один «задачи по избеганию».

(лирическо-философское отступление)

Что такое проблема?

Как правило тут два определения этого слова/понятия.

3.А) Проблема - как неприятность (беда) в бытовом значении где надо из этой «апож» выбираться. Не важно как там оказались, кто виноват (это будет обсуждаться на берегу, после того как выплывем), важно что делать, и делать быстро и эффективно (результативно).

3.Б) Проблема - как ситуация с неясными исходами, т.к. в зависимости от выбранного варианта результаты могут быть разными («дорога возникает под ногами идущего»). Т.е. по-научному, мы имеем «точку бифуркации» где далее или «туман войны», или надо просто выбирать, т.к. ресурсов на оба решения не хватает (нельзя усидеть на 2 стульях + рыбкой закусить). Окно Овертона может быть только одно, т.к. «двери открываются поочерёдно».

Сложность этого варианта не только в том что надо «вылезти из проблемы» (3.а), а в том что часто и не понятно в какую сторону вылазить (нет ориентиров, цели) т.к. нет опыта, или знаний (новая ситуация).

В общем (п.3) суть этой задачи «выдвижение из зоны дискомфорта» с разным уровнем масштаба этой «сумеречной зоны».

Или невляпаться в проблему (то же избегание, но в процессе работы) где надо заранее прогнозировать трудности (разведка) и подстраховываться.

А так как «пришла беда - отворяй ворота» часто ТТХ инструментария не соответствует «фронту работ» приходится проявлять смекалку (креативность) и нестандартное применение орудий труда и ЗУНов (ассоциативное мышление).

...

Потом там далее в исходнике что-то из: «смотрите, я знаю (прочёл) много умных слов, но перевести на отечественную терминологию (русификация) ниасилил».

Местами смешно.

Улыбнуло.

2. Небольшое отступление. Когда я учился в ЛенВОКУ, то один из пожилых преподавателей говорил нам, что «Уставы написаны кровью и ваша задача знать их наизусть». Простой пример – обязанности часового из Устава гарнизонной и караульной служб «Часовому запрещается: спать, сидеть, прислоняться к чему-либо, писать, читать, петь, разговаривать, использовать личные средства связи, есть, пить, курить, отправлять естественные потребности или иным образом отвлекаться от исполнения своих обязанностей, принимать от кого бы то ни было и передавать кому бы то ни было какие-либо предметы, вызывать своими действиями срабатывание технических средств охраны, досылать без необходимости патрон в патронник». Вы согласны с тем, что любой человек, не обладающий диагнозом «Умственно отсталый», читает один раз и понимает, что можно, а что нельзя?

3. А теперь вернёмся к нашему родному бизнесу.

3.1. Почему во многих компаниях нет таких Уставов для сотрудников? Это должностные обязанности.

3.2. Почему не ведётся учёт деятельности отдельно взятого сотрудника?

3.3. Почему не разбираются и не записываются в летопись компании как положительные свершения, так и допущенные косяки? Ведь скрывая допущенные ошибки, мы обречены повторять их снова и снова.

P.S. Господа собственники, даю намёк – не путайте ошибку подчинённого с его непрофессионализмом, это чревато тяжёлыми последствиями.

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

Итак, 4 типа заданий:

1. Выполнить алгоритм.

2. Решить задачу, достичь цель.

3. Устранить проблему.

4. Найти возможность или избежать проблему.

Эта классификация подходит для сотрудников в любых должностях: от уборщика до CEO, принцип один.

Уровень 1: Выполнить алгоритм

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

Уровень 2: Решить задачу, достичь цель

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

Уровень 3: Устранить проблему

Руководитель описывает некую ситуацию, которую он считает “неправильной”. При этом как выглядит “правильная” ситуация (то, к чему нужно прийти), он не знает, это нужно выяснить подчиненному. Подчиненный сам формулирует цель и сам подбирает алгоритм для ее достижения. Будет ли он сначала изучать возможные варианты подходящих целей, а потом искать алгоритмы для лучшей из них или двигаться последовательно, перебирая возможные цели и сразу изучая алгоритмы для каждой, это его дело. На руководителе  остается  только ответственность за то, что проблема действительно существует и ее стоит пытаться решать.

Примеры проблем: упали продажи в этом квартале, наш сайт стал медленно работать, к нам не приходят новые пользователи и так далее.

Может показаться, что решение задачи и устранение проблемы, это одно и то же, просто в первом случае мы формулируем желаемый результат, а во втором - нежелаемую исходную ситуацию. Русский язык вполне позволяет формально переформулировать проблему в задачу. Была проблема “Продажи упали” - стала задача “Поднять продажи”. Но все не так просто, задача от проблемы отличается уровнем анализа, который необходимо провести для выполнения задания. Если внимательно почитать, например, PMBOK, можно обратить внимание, что все процессы проектной работы предполагают, что что-то похожее мы уже делали и базовый сценарий наших действий уже есть. Если мы знаем бюджет, сроки и скоуп задач, то более-менее сразу понятно, что нужно делать дальше, чтобы у нас появился новый сайт. А вот что делать, если упали продажи: нужно ли сделать новый сайт или  выложить новые товары на старом сайте, или вообще ничего не делать, а просто подождать?

Уровень 4: Найти возможность или избежать проблему

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

Проблемная область всегда включает контекст. Звучать это может как-то так: у нас есть это, а вот этого больше нет, что можно сделать здесь? "Здесь" - это контекст. Предполагается, что тот, кому ставят такое задание, его понимает. "C ванной что-то надо делать" - проблемная область, "Капает кран в ванной" - это уже проблема, которая через анализ превратится в стопку задач.

Пример разговора CEO и CTO

• Все наши клиенты в США, а наша инфраструктура в РФ, чего делать будем?

• Уже начали смотреть, как можно зазеркалить БД c контентом на Амазоне, все остальное не так критично, быстро развернуть сможем всегда.

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

Для каждого сотрудника есть комфортный для него тип заданий. Если вы будете ставить задания ниже его уровня, то это будет восприниматься либо как недоверие, либо как скукота. Если задание окажется выше уровнем, то подчиненный явно или неявно самовольно опустит уровень до комфортного для него. В обоих случаях это потенциальный провал задания. При этом не важно, как при этом звучит должность сотрудника. Это может быть продакт-менеджер, который думает, что решает бизнес-проблемы, а на самом деле занимается проектной работой. Это может быть техдир, который думает, что управляет рисками, а на самом деле работает координатором задач. Важно другое: что конкретно вы, как руководитель, ждете от своего подчиненного.

Пример разговора СTО и тимлида

• Бухгалтерия жалуется, что какие-то их отчеты стали очень медленно выгружаться, разберись, пожалуйста.

Прошло несколько дней.

• Ну что, как успехи с отчетами?

• Еще в процессе, изучаю планы запросов в БД.

• А что бухгалтеры говорят, что за отчет-то у них вообще?

• Я не спрашивал.

CTO просит решить проблему. Проблема в недовольстве бухгалтеров. Возможно можно просто обновить компьютеры, возможно эти отчеты можно запускать ночью автоматически. Тимлид не видит всех этих вариантов, потому что не думает о том, зачем нужно что-то делать, он думает о том, что нужно делать. Поэтому сразу занялся тем, что умеет, неявно подменив “жалуются на скорость” на “оптимизировать запросы”.

Задания более высокого уровня воспринимаются как непонятные, невнятные. Строго говоря, так оно и есть, эти четыре типа заданий отличаются уровнем неопределенности, с которым готов работать сотрудник. С повышением уровня задания растет объем работы, который нужно выполнить, увеличивается разнообразие экспертизы, которую нужно иметь, и соответственно растет количество людей, которые будут задействованы в работе над заданием так или иначе, что и приводит к росту неопределенности. Поэтому сотрудник, в должности которого есть слово “менеджер”, не может быть ниже уровня 2. Это уровень тимлидов и проектных менеджеров. Говорить о стратегировании можно только на уровне 4 - уровне, где происходит формулирование проблем, а не только их решение.

Коучи, проповедники аджайла аксиоматически предполагают, что все сотрудники компании имеют уровень 3 или 4 (ха!), умеют ставить себе цели, и собственно поэтому им не нужны линейные руководители (дважды ха!). Во-первых, чем выше уровень, тем меньше таких людей на рынке, придется долго искать и зачастую переплачивать. А во-вторых, захотят ли такие сотрудники делать задания первого уровня? В любой компании (не стартапе) есть скучная операционка (т.е. задания первого уровня), которую кому-то нужно делать.

Задания более низкого уровня, чем привык сотрудник, могут создавать не меньше проблем. При менеджерском попустительстве они либо провоцируют сотрудника на нарушение субординации и самовольное “я хотел как лучше”, либо приводят к выгоранию и апатии из-за слишком простых для него задач, ощущению своей недооцененности.

Пример разговора проджект-менеджера и разработчика

• Я просил тебя убрать всю анимацию со страницы, она тормозит, а демонстрация работы клиенту уже завтра. Готово?

• Ну я на прошлой неделе покопался в коде и улучшил производительность, теперь не должно тормозить.

• То есть вместо задач из бэклога, ты чинил анимацию, которую я просил просто выключить?

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

Отдельная история, если начальник сам до конца не понимает, чего хочет от подчиненного. В этом случае часто смешивают несколько типов заданий.

Каждый из 4 типов заданий предполагает, что подчиненный будет искать ответ на один из 4 вопросов: как сделать, что сделать, зачем делать или почему нужно что-то сделать. Если менеджер сам до конца не знает, что должно быть в итоге, он пытается  пробелы забить советами как делать. Если менеджер расписывает алгоритм достижения цели, но знания деталей не хватает, он добавляет рассказы о том, что будет в итоге. В обоих случаях задача превращается в ребус.

Пример разговора CPO и продакт-менеджер

• У нас увеличился отток пользователей, нам нужна геймификация.

• Ок, я изучу данные по поведению пользователей.

• Да, славно, когда ТЗ для разработки подготовишь?

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

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

P.S. Кому-то могло показаться, что приведенные мной примеры неточны и то, что я назвал проблемой, на самом деле задача или проблемная область. Вполне возможно, в вашем случае это так и есть. Дело в том, что сложность задания можно считать абсолютной величиной только в рамках одной компании и на определенном этапе ее развития. Скажем, в одной компании “запуск A/B-тестов” - это четко расписанный алгоритм, в другой - это целый проект, который требует каждый раз координации работ нескольких отделов и ручного сопровождения. А в третьей компании - это вообще организационная проблема, которую можно решить только полностью пересмотрев методы целеполагания компании.

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

Мой телеграм-канал Токсичный манагер