IT + Управление

В статье Почему подчиненные делают не то, что нужно я писал о четырех типах заданий, которые может поставить руководитель: алгоритм, задача, проблема, возможность и, соответственно, о четырех типах вопросов, один из которых встанет перед исполнителем, когда он будет выполнять задание:

• Как нужно делать?

• Что нужно сделать, к какой цели нужно прийти в итоге?

• Какую проблему нужно решить, зачем это делать?

• Почему эту проблему нужно решать, почему это нужно делать?

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

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

Еще один пример. Для наемного менеджера внутри бизнеса создание стратегии - это проблемная область, т.е. поиск и последующий выбор проблем, которые нужно решать, а для серийного предпринимателя или инвестора - это всего лишь задача, которая в свою очередь сводится к поиску соответствующего специалиста. Для того чтобы привести этот пример, мне пришлось уйти от абстрактных A, B, C, P, G в описании, т.е. пришлось добавить контекст. И теперь можно говорить не о неопределенности знания, а о сложности динамической системы, в рамках которой мы реализуем алгоритмы, ставим цели и решаем проблемы. А это в свою очередь означает, что классификация заданий превращается в известную многим айтишникам модель сложности Кеневин.

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

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

Как правило, люди видят только конец и начало соседних витков, выпрямляя спираль в одну прямую. Например, вот так могут выглядеть уровни сложности принятия решений некого наемного менеджера среднего звена:

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

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

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

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

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

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

Ну а с главным вопросом “почему?” вообще все просто, ответ на него давно уже дал один очень мощный компьютер. Формулировка ответа записана в книге Дугласа Адамса “Автостопом по галактике”.

Регулярно пишу в Telegram-канал Токсичный манагер про управление и все, что с ним связано. Заходите.

2. Выражения типа «Почти сделано», «Сделано, но..» приравниваются к «Я не сделал».

Нельзя не сделать задание из-за того, что руководитель или стейкхолдер не уточнил какие-то требования. Если у задания были неоговоренные детали, о которых сотрудник не знал, значит он не проанализировал задание, т.е. нарушил п. 1, или нарушил п. 4, если эти детали нельзя было выявить заранее. Задание считается выполненным только при выполнении 100% требований задания, задания выполненные на 50%, 75% или 99% считаются невыполненными.

3. После выполнения задания анализ сделанного должен быть проведен независимо от достигнутых результатов.

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

4. О препятствиях к 100%-ому выполнению задания следует сообщать руководителю и всем заинтересованным лицам заранее, до намеченной даты сдачи.

Сначала сотрудник пытается решить проблему самостоятельно. Информирует руководителя в момент, когда убедился в невозможности решения своими силами, и делает это обязательно до «точки невозврата», пока вмешательство руководителя еще может иметь смысл. Рассказ о том, почему задача не сделана в момент ее сдачи является нарушением п. 2.

5. Расширенное толкование полученного задания не допускается.

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

6. Несогласие с параметрами задания или регламентами исполнения не может служить поводом для их игнорирования.

Все параметры задания можно и нужно обсуждать (п. 1), но после принятия решений по этим параметрам договоренности нарушать нельзя. Не готов взять на себя ответственность из-за отсутствия соответствующего опыта или ресурсов – не бери. Наоборот,  хочешь больше ответственности – сообщи руководителю.

7. Запрещено в качестве мотивации к невыполнению задания использовать формулировки «Не успел», «Забыл».

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

8. Сотрудник имеет право требовать от руководителя пояснений о целях поставленной задачи.

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

9. Определение конкретных шагов в рамках выполнения делегированного задания остается за исполнителем.

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

10. Необходимо опираться на факты и цифры, а не на мнения и ощущения.

Это касается как постановки задания, критериев сдачи, так и определения причин его несдачи.

KPI (key performance indicators) - это ключевые показатели результатов деятельности.

Если все, что вам нужно знать про OKR, можно почерпнуть из книги Джона Дорра “Измеряйте самое важное”, то для KPI одной такой главной книги нет. Обычно, когда говорят про KPI, имеют ввиду либо методику MBO Питера Друкера, либо систему BSC Дэвида Нортона. Впрочем, в любом случае под KPI подразумеваются задачи, сформулированные по SMART, так же как и Key Results внутри OKR.

И KPI, и OKR могут формироваться для разных уровней компании, а потом объединяться в общую иерархию целей. Цели сотрудников должны вытекать из целей отделов, а цели отделов - из целей компании.

В общем, если из OKR убрать objectives, которые зачем-то ставят заведомо невыполнимыми, то оба подхода неотличимы. Получается, что OKR - это просто новый вид KPI? А если так, то вопрос “Можно ли смешивать KPI и OKR?” отпадает сам собой. Но на самом деле ответ зависит от того, зачем вашей компании нужен KPI или OKR.

OKR и KPI для разного

Итак, цели KPI конкретны и достижимы, а следовательно по ним можно судить об эффективности работы. Выполнили задачу всего на 50% - плохо, выполнили на 100% - нормально, а если больше - ну значит вообще молодцы. То есть это уже не просто метрика, не только инструмент контроля, но и способ мотивации. Компания явно дает понять, чего она хочет от сотрудников.

С OKR все сложнее. Вы не можете подойти к подчиненному и спросить, почему OKR выполнен всего на 50%, а не, как положено, на 70%. Цель ведь изначально была недостижимой, а результаты слабо предсказуемы. Если вы все-таки будете настаивать именно на достижении 70% и, скажем, для этого введете денежное вознагражение, то в следующий раз сотрудники сформулируют OKR таким образом, чтобы получилось заветное значение 70%. То есть вы, сами того не понимая, превратите OKR в KPI.

Таким образом, OKR в отличие от KPI нельзя использовать для мотивации сотрудников. Если смотреть на OKR как на способ донести сотруднику, что он должен делать, это очень плохой и неочевидный способ. Вместо этого OKR предлагает фокусироваться на вопросе: зачем мы делаем то, что делаем. Фактически OKR - это всего лишь способ организовать разговор внутри компании о том, куда мы идем. И OKR можно внедрять, только если топ-менеджмент таки знает, куда идем и значит нам есть о чем говорить, то есть когда у компании есть стратегия. А иначе от OKR пользы для бизнеса будет не больше, чем от “Камасутры” для пятиклассника. Очень интересно, но ничего не понятно.

С этой точки зрения KPI и OKR могут сосуществовать, так как выполняют разные функции - мотивации и целеполагания. Но важно максимально их разнести, чтобы они не влияли друг на друга. В первую очередь, конечно, KPI  на OKR. Можно сделать, чтобы KPI не зависел напрямую от решаемых бизнесом задач, а завязать его, скажем, на выходы одного из методов «360 градусов». Или связать, но на уровне гораздо выше, чем уровень сотрудника и его команда - достигли цель, все молодцы, все получают выплаты. Ну и самый простой вариант - KPI для одних отделов, OKR для других.

OKR и KPI для разных

Продолжаем идти по скользкому пути поиска глубинного смысла. Итак, OKR и KPI могут сосуществовать в пространстве одной компании. Это не просто, потребуется время, чтобы исключить влияние KPI на OKR, но в принципе возможно. А теперь любимый вопрос всех продукт-менеджеров: а зачем?

KPI - это способ мотивации сотрудников, способ донести до них, как они должны работать. То есть предполагается, что менеджмент компании знает, как нужно работать, что делать сотрудникам и нужно просто суметь это рассказать подчиненным.

OKR предполагает, что мы более-менее понимаем, куда идем, а вот как туда дойти, до конца не понятно. Мы хотим найти решение вместе, со всеми сотрудниками, на всех уровнях. Это не означает, что теперь нужно выкинуть все дашборды, кроме тех, где выводятся задачи OKR, они остаются полезными и нужными, но в них больше не нужно тыкать сотрудников. Теперь это просто метрики, характеристики состояния, но никак не рычаги влияния и управления человеческими ресурсами.

Я не хочу противопоставлять эти два подхода, но важно понимать, что они из разных парадигм управления. Это все равно, что сказать сыну: “Ты уже взрослый, можешь сам принимать решения теперь, я тебе доверяю… и кстати, я на всякий случай скрытую камеру в углу твоей спальни повесил”. Так не работает.

Возможно звучит несколько высокопарно, OKR можно внедрить, только если культура компании предполагает осознанность и открытость, а большинство сотрудников высокопрофессиональны, глубоко этичны, внутренне мотивированы. В вашей компании дела обстоят именно так? Ваши сотрудники, один раз услышав, что амбициозные цели можно выполнять на 60-70%, не решат, что можно не доделывать, не дожимать? Готовы поставить свой бизнес на кон и проверить? Если да, внедряйте OKR. Ровно в той степени, в какой вы не соответствуете этим высоким стандартам, в той же степени вам на самом деле нужен KPI и в той же степени вам рано использовать OKR.

Если вам хочется смешать OKR и KPI, значит скорее всего вам не нужен OKR.

«Шестидесятилетний Джим Лавуа – генеральный директор Rite-Solutions, компании-разработчика программного обеспечения (ПО), штаб квартира которой находится в Ньюпорте, штат Род-Айленд. Эта компания разрабатывает современные программные продукты, к которым предъявляются самые жесткие требования, – ПО для систем управления и контроля подводных лодок и оптических систем поисково-спасательных вертолётов Береговой охраны США. Президентом компании является деловой партнёр и давний друг Лавуа – Джо Марино, которому пятьдесят восемь лет.

Лавуа и Марино создали компанию, основной принцип которой – сформировать культуру, где труд доставляет радость, а инновации поощряются. […]

«У большинства компаний есть своего рода сито, – говорит Лавуа. – Дайте сюда все ваши идеи, и мы не оставим от них камня на камне. В моей прежней компании если у вас возникала блестящая идея, вам говорили: «Отлично, мы дадим вам возможность пообщаться с «расстрельной командой» (Murder board – группа, которая задаёт каверзные вопросы для проверки качества идей и планов – Прим. И.Л. Викентьева), – считая, что такая мера гарантирует, что компании не придется рисковать. Их работа – уничтожать идеи на корню».

Марино объясняет, что происходит в таком случае. «Кто-то из специалистов предлагает хорошую идею. Разумеется, ему задают вопросы, на которые он не может ответить. Например: «Как вы оцениваете размеры рынка? Какова ваша стратегия маркетинга? Что представляет собой ваш бизнес-план? Какова будет стоимость конечного продукта?» Такие вопросы сбивают с толку. Большинство людей не готово на них ответить. Тот, кто способен выдержать общение с такой командой, редко предлагает хорошие идеи. Скорее он отличается умением представить информацию в выгодном свете».

Чтобы стимулировать инновации и даже разрушение стереотипов в Rite-Solutions используют так называемый рынок идей. Каждому новому сотруднику в первый день работы в Rite-Solutions вручают виртуальную сумму в 10 000 долларов, которой он вправе распорядиться по собственному усмотрению.

Эти деньги можно инвестировать в идеи на внутреннем фондовом рынке. Он похож на реальный фондовый рынок, но у него есть важные отличия, которые позволяют идеям развиваться. Зарегистрировавшись на этом рынке, вы можете ознакомиться с «expectus» – кратким изложением идеи, предложенной кем-то из сотрудников компании. Это может быть несложная идея, например, набор команд, который позволяет дополнить компьютерную визуализацию новой функцией. На этом этапе игры идея остаётся идеей. Если она понравится другому сотруднику, он может инвестировать в нее часть своих виртуальных денег.

Капиталовложения растут, когда идея выходит на следующие уровни рынка. Чтобы она получила поддержку, другие люди должны высказать свои критические замечания и мысли о том, как можно усовершенствовать данную идею. Это называется «процентами». Лавуа и Марино подсчитывают сумму процентов исходя из количества замечаний по поводу конкретной идеи. Рынок устроен таким образом, что проценты стоят в два раза дороже первичных «капиталовложений». Но чтобы получить прибыль, сотрудник должен поработать над идеей в режиме реального времени. Этот этап называется инвестиционной фазой и является самым важным, поскольку именно в этот период начинается воплощение идеи в жизнь. Она не должна быть сложной. Достаточно, чтобы кто-то сказал: «Вот что следует сделать, и я готов потратить на это два часа своего личного времени».

Но почему люди должны тратить время, работая над идеями, которые не имеют непосредственного отношения к их прямым обязанностям? Марино убеждён, что в первую очередь это вопрос доверия. «В первый же рабочий день мы позволяем новичку увидеть всё, над чем трудятся наши сотрудники. Это делают очень многие компании». Другая причина состоит в том, что рынок идей позволяет людям определять круг своих обязанностей. «Автор идеи выигрывает не только в материальном отношении. Если его идея удачна, именно он будет заниматься разработкой ответствующей технологии», – говорит Лавуа.

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

Грегори Бернс, Разрушители стереотипов: когда и как можно нарушать общепринятые правила и выходить победителем, М., «Альпина Бизнес Букс», 2009 г., с. 84-86.

Источник — портал VIKENT.RU

Фрагмент текста цитируется согласно ГК РФ, Статья 1274. Свободное использование произведения в информационных, научных, учебных или культурных целях.

Если публикация Вас заинтересовала – поставьте лайк или напишите об этом комментарий внизу страницы.

Дополнительные материалы

• О социальных переменах / инновациях по мэру Москвы Г.Х. Попову

• Методы организации творческой деятельности и принятия решений, часть II по И.Л. Викентьеву — видео, 1 ч 46 мин

• Менеджмент компаний — около 90 материалов по теме

• см. термин ТРИЗ-Бизнес в 🔖 Словаре проекта VIKENT. RU

+ Плейлист VIKENT. RU из 20-ти видео: ТВОРЧЕСКИЕ ЗНАНИЯ / УМЕНИЯ / НАВЫКИ

+ Ваши дополнительные возможности:

Идёт приём Ваших новых вопросов по более чем 400-м направлениям творческой деятельности – на онлайн-консультации третье воскресенье каждого месяца в 19:59 (мск). Это принципиально бесплатный формат.

Задать вопросы Вы свободно можете здесь:

https://vikent.ru/w0/

Изображения в статье

1. Изображение от rawpixel.com на Freepik

2. Изображение от Freepik

3. Изображение от Freepik

Значит, пора расти как менеджер, управленец или командный игрок. Кроме того, важным сигналом станет накопленная усталость от того, что рабочего дня не хватает, чтобы переделать все дела.

Главная сложность в делегировании — решиться подключать к своим задачам других людей, особенно если вы действительно делаете всё лучше всех или являетесь единственным хранителем знаний, как всё сделать идеально. Но возможности и время одного человека ограничены: придется делегировать. С точки зрения механики всё просто.

1. Выберите задачи

— Мелкие поручения и рутина, на которую нет времени: например, бронирование билетов или заполнение Excel-таблицы.

— Задачи, которые будут прямыми обязанностями сотрудника и позволят ему расти: например, сбор аналитики по рынку или организация мероприятий.

— Узкоспециализированные задачи, для которых у руководителя недостаточно экспертных знаний: такие, как веб-аналитика или SMM от лица компании.

— Представительские функции: когда руководитель передаёт свои полномочия одному или нескольким сотрудникам на время своего отсутствия.

2. Найдите исполнителя

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

Если все пункты вызывают сомнения, лучше поручить задачу другому человеку или нескольким сотрудникам.

3. Проследите за выполнением

Это можно сделать при помощи регулярных встреч, на которых будете обсуждать, как идёт процесс, или советоваться в спорных случаях.

Чтобы делегировать задачи и контролировать их, удобно пользоваться CRM или таск-менеджерами вроде Trello, Jira или Notion. Так сразу видно, насколько загружена команда: у кого проблемы со сроками, а кто свободен и может помочь. В небольшой команде такой подход позволит легко распределять большие задачи: подключать сразу несколько человек к одной или разбивать на этапы и поручать каждому свои задания.

4. Радуйтесь и учитесь развивать команду дальше

Как видите, механика делегирования несложная. Тем не менее, сама работа не даётся легко. Её можно и нужно изучать, чтоб развивать качества руководителя.

Прочитайте что-то из списка:
— «Эмоциональный интеллект», Дэниел Гоулман;
— «Делегирование: результат руками сотрудников», Александр Фридман;
— «Делегирование и управление», Брайан Трейси;
— «Делегирование полномочий», Кейт Кинан;
— «Делегирование полномочий. Руководство для менеджеров», Ричард Люк, Перри Макинтош.

Пройдите курсы

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

Узнать о курсе