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

Существует всего 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. Существуют уровни работы с неопределенностью и выше четвертого, но они относятся уже к предпринимателям, инвесторам и политикам, а не к наемным сотрудникам компаний, поэтому их я рассматривать не стал.


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

Комментарии (24)


  1. akakoychenko
    00.00.0000 00:00
    +8

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

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

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

    Да, возможен вариант, что в неайтишном бизнесе тайтл СТО достаётся кому-то вроде head of IT helpdesk, и тогда как-то так оно работать и будет.

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

    То есть, фактически, чтобы оно работало, оно должно работать как-то так:

    когда бухгалтера жалуются СТО, он отвечает примерно следующее: у вас есть продакт, который определяет приоритеты того, насколько ваша проблема важнее остальных задач, и вы идёте к нему. Если он решает, что этим стоит заниматься, то он с тимлидом оценит варианты решения и их срок, если и после этого будет решено брать в работу, то команда возьмёт в работу. И если только окажется, что И задача достаточно важна И ее нельзя решить текущим ресурсом команды И полномочий команды не хватает, чтобы эти ресурсы расширить, тогда уже включусь я, СТО, и буду решать проблему на своём уровне (покупать новое железо за 100500 денег, нанимать новых DBA, брать внешний консалтинг, нанимать подрядчика, который сделает все под ключ etc).


    1. PereslavlFoto
      00.00.0000 00:00
      +2

      чтобы оно работало, оно должно работать как-то так:… есть продакт, который определяет приоритеты… он с тимлидом оценит варианты решения...

      Само условие, что бухгалтер идёт к CTO, означает, что нет продакта и нет тимлида (в том смысле, что teamlead и составляет всю team). Сверх того может оказаться, что бухгалтер и CTO живут в одном дворе и вместе едут на работу.


      1. akakoychenko
        00.00.0000 00:00

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

        Да пусть хоть в одной постели спят:)

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

        Ну и да, если нет продакта, но есть СТО, то это то, о чем я писал в начале комментария. Если СТО решает оперативные задачи и координирует подобные вопросы, он не СТО (хоть и может формально быть так подписан в справочнике и на визитке), и обсуждать кейс бессмысленно.


    1. BobArctor
      00.00.0000 00:00
      +3

      Услышав такой ответ бухгалтер идёт к финдиру и дальше СТО получает мотивацию через другие каналы.


      1. A1054
        00.00.0000 00:00

        и правильно сделает.


    1. A1054
      00.00.0000 00:00
      +1

      Мне кажется, что такого СТО скоро уволят. И поделом.

      Единственное, в чем вы правы, что сначала бухгалтеру стоит обратиться к продакту (если процессы компании это допускают). Вполне возможно, что продакт проблему решит. Но если нет, я плохо представляю бухгалтера, который не эскалирует проблему. И если СТО, вместо внятного объяснения причин, почему проблему решить сложно (т.е. вместо переговоров и согласования интересов), выдаст подобный ответ, то проблема быстро эскалируется на финдиректора и генерального. И я посмотрю, как на совещании у генерального на тему "технари совсем охренели" СТО еще раз скажет что-то подобное.

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


  1. saege5b
    00.00.0000 00:00
    +4

    Хих.
    Напомнило:
    -- начальник, есть проблемы с прохождением тестов самопроверки.
    -- тыже умный, разберись сам.
    -- начальник, там дурит блок управления.
    (Менеджер):
    -- блок управления стоит 25.000 евро. Вы же умные, придумайте что-нибудь.
    (Начальник - оператору):
    -- надо.
    (Оператор):
    -- я там скотчем примотал, спичкой подоткнул.
    (Все):
    -- как замечательно!
    (Работник):
    -- эхей начальники! Скотч не выдержал, всё упало.
    (Все):
    -- ....


    1. PereslavlFoto
      00.00.0000 00:00
      +3

      (Все):
      — Примотай нормальной изолентой.


      1. saege5b
        00.00.0000 00:00
        +3

        (Работник):

        • Изолента не входит в список закупаемой канцелярки. Есть скотч (прозрачный, бумажный), скобы для бумаги (трёх размеров), клей ПВА, бумага различной плотности, толщины, ширины. Гофрокартоны различные (от упаковочных коробок). Спички найдены в ящике стола, с неизвестных времён.


        1. PereslavlFoto
          00.00.0000 00:00
          +1

          (Все):
          — Свою надо иметь!


          1. saege5b
            00.00.0000 00:00
            +1

            (Работник):
            -- Я вообще оператор. Начальники! станок не проходит тесты самопроверки! Я не имею права работать на неисправном оборудовании! У меня до конца смены ещё 7 часов, вы пока решайте с ремонтом, а я пошёл, корпус, что-ли протру, потом ещё чего-нибудь придумаю чем заняться.


            1. PereslavlFoto
              00.00.0000 00:00
              +1

              (Все, хором, поднимаясь):
              — Ага, вот кто, значит, довёл станок и провалил тему. Теперь из-за тебя будем без премии сидеть. Теперь из-за тебя на нашем отделе крест поставят. Мы всё видели. Если из-за тебя на будущий год снова останемся без бюджета, уж мы молчать не будем. Возьми хоть гаечный ключ и отключи всю эту проверку.


              1. saege5b
                00.00.0000 00:00
                +1

                (Работник):
                -- Давайте конкретный приказ. И инструкцию, куда тыкать.

                /* Кстати, там всё в сборе, почти лям евро ;)
                У нас менеджеры как-то решили закупить всё, что может сломаться, заранее, но узнали в какую сумму оно встанет, и передумали */


                1. PereslavlFoto
                  00.00.0000 00:00
                  +2

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

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


                  1. saege5b
                    00.00.0000 00:00
                    +5

                    А нету в должностных инструкциях - ремонта производственной линии. И требований по электротехнике и микроэлектронике тоже нет, а так же по гидравлике, пневматике, механике.

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

                    Сам писал :) а начальство подписало. Поэтому, я довёл до руководства. А дальше: "солдат спит - служба идёт".
                    Да, я провожу некоторые ремонтные работы, неофициально. Но дёрнуть за это - не получится: начальство уведомлено, что у меня нет допуска к проведению каких-либо работ на электроустановках. У меня нет профессиональных навыков по электронике. Поэтому любой суд будет на моей стороне.
                    А если менеджерам стало жалко 25 тысяч на приобретение нового блока управления, то я вообще ни при чём - я не управляю финансовыми потоками.
                    Да, я могу что-то потыкать, где-то покрутить. Но договариваться со сервисниками, искать сервисные инструкции, раскуривать документацию на установленные узлы - это уже уровень начальника, или ремонтника, на которого руководству жалко зарплату.
                    И да, зарплата "оператора линии" не сказать что выше местного рынка.
                    Да, по получению прямого приказа, я полезу и в софт, и в датчики, и в плату. Но! Если в процессе оно окончательно умрёт, я ответственности не несу. И любой суд будет на моей стороне. И как любой разумный работник, я хочу получить прямой приказ руководства, что бы потом на меня разные менеджеры не пытались повесить ремонт в 50-100 тысяч евро.


                    1. PereslavlFoto
                      00.00.0000 00:00

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

                      Должно быть, что вы работаете на коммерческой фирме, а я работаю в государственном учреждении. Поэтому мы видим мир с очень разных сторон.


                      1. saege5b
                        00.00.0000 00:00
                        +1

                        Гоструктуры, это вообще что-то с чем-то. Регулярно покупают что-то, а про расходники никто даже не задумывается. Но все "важные", премии получили.
                        Куча начальников, но никто за конкретно не отвечает.
                        Кстати, единственное что радовало - что процедура списания в моё время была хоть и суровой, но иногда удавалось списать и вполне рабочие экземпляры. Тем и жил, но недолго :)

                        ПыСы. Современные конденсаторы в полупроф. технике и процы переживут. Больше выбешивает современный экоприпой, который любит усы раскидывать; и экономия на контактных площадках, которые за пару лет могут окислится вообще в ноль.


                    1. ixamilion
                      00.00.0000 00:00
                      +2

                      А нету в должностных инструкциях

                      Сколько видел инструкций - во всех было "выполнять устные распоряжения руководителя".


                      1. Ivan_Pod
                        00.00.0000 00:00

                        "В рамках должностных обязанностей". А то, мало ли какой Иван Дулин там у вас в начальниках...


  1. Vpan
    00.00.0000 00:00
    +2

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

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

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


  1. Germanjon
    00.00.0000 00:00

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


    1. FatherYan
      00.00.0000 00:00

      Подобные задачи часто могут не иметь решения в принципе. Так что неудивительно.


  1. Grigorenkovic
    00.00.0000 00:00

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


  1. Gradiens
    00.00.0000 00:00
    +6

    Какое-то простое разделение на уровни получается.

    Вот я - тимлид, руковожу как разработкой так и поддержкой продукта. По идее, мой уровень 2? Или 3?

    Одна из моих задач - улучшение атрибутов качества продукта. Надежность, доступность, и т.д. Мне нужно на своем уровне выявлять риски, оценивать их, предлагать меры по митигации (вместе со стоимостью) бизнесу. Случай из жизни: "коллеги, за год в нашей системе стало хранится в 5 раз больше данных. Если тенденция сохранится, еще через год произойдет полный отказ в работе системы. Мы провели volume testing, вот результаты. Чтобы этого не произошло, я предлагаю принять меры 1, 2, 3. По времени займет 4, 5, 6."

    Это, судя по вашей классификации, уровень 4.

    Но это 4 только для меня. Для моего руководителя это просто задача "обеспечить sla". Которую он делегирует мне. А для меня это уже совокупность проблем.

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

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