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

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

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

Как именно — приглашаю почитать.


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

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

Про постановку задач

У руководителя есть 4 основные функции:

  1. Планирование

  2. Организация

  3. Мотивация

  4. Контроль

И особенность профессии как раз в том, что не нужно все делать самому. Даже не так — губительно все делать самому! Нужно раздавать задачи своим сотрудникам, так, как вы напланировали. Организовывать их работу, обеспечив всем необходимым. Далее мотивировать их, чтобы они достигали успеха. Ну и контролировать результат, а иногда и прогресс, чтобы на выходе получить именно то, что вы ожидаете.

Еще раз хочу обратить внимание, что когда вы ставите задачу своему сотруднику, то занимаетесь организацией его работы. А значит вашей обязанностью будет разжевать ему задачу, убедиться, что он верно ее понял, выдать ему все необходимое для ее выполнения (доступы, полномочия, информацию и т п). Правильная постановка задач — не менее 50% результата.

Как убедиться, что сотрудник вас понял? Самый простой вариант, попросить его рассказать вам, что от него требуется. Вариант посложнее — попросить его рассказать какие‑то шаги, как он будет вашу задачу выполнять. Здесь не каждый сможет сразу ответить, некоторым надо посидеть и подумать. Это нормально, просто дайте ему время и вернитесь с вопросом снова. Если задача объемная, то вы получите гигантский профит, когда в самом‑самом начале отловите, что сотрудник собирается делать вообще не то. Скорректировали, если нужно, и отправили его за результатом.

Про контроль

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

Выделяют 5 основных типов контроля:

  • Итоговый — самый простой вариант, просто смотрим, что получилось, сравниваем с тем, что хотели

  • Предварительный — это проверка результата до того, как задача выполнена полностью

  • Поэтапный — итерационный контроль, когда задача разбивается на этапы, готовность которых можно оценить

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

  • Выборочный — совершенно рандомные точки, иногда неожиданные для исполнителя и даже проверяющего

Чтобы было понятно, как это работает, разберем все эти типы на примере работы тимлида.

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

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

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

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

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

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

Про психотипы

Возвращаемся к тому, с чего все начиналось — люди разные. Это действительно так. Есть масса различных классификаций психотипов и других характеристик людей. И именно с поправкой на психотип следует ставить задачи, и потом их контролировать.

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

DISC — аббревиатура. Модель классифицирует людей на 4 типа:

  • D — Dominance — Доминирующий тип — Достигаторы, воодушевленные дофамином, готовы браться практически за любую задачу, стремятся к результату. Для людей типа D (красные) характерны прямолинейность, креативность, готовность к риску и неприятностям

  • I — Influence — Влияющий тип — Открытые, теплые, ставят комфортные отношения с людьми превыше всего. Для людей типа I (желтые) характерны общительность, дружелюбность, умение влиять на других

  • S — Steadiness — Стабильный тип — Любят работать в отлаженных процессах, надежные, методичные, исполнительные. Для людей типа S (зеленые) характерны надежность, добродушие, умение выслушать каждого

  • С — Compliance — Адаптивный тип — Аналитики, любят системность и четкость. Для людей типа C (синие) характерны аккуратность, осторожность, логичность, перфекционизм

Среди инженеров чаще всего преобладает «синий» психотип. Но других тоже немало, важно понимать, с кем вы имеете дело. Каждый психотип по‑разному реагирует на задачи, требует разного подхода к ее постановке и к контролю.

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

I (желтые) — для таких сотрудников характерно 2 вещи. Первое — уход в абстракции, что иногда требует от вас объяснить задачу гораздо шире, чем это требуется, но ему важно сложить весь пазл целиком. Второе — уклон в творчество, т е им интересно придумать решение, но зачастую неинтересно его реализовывать. Поэтому с такими сотрудниками лучше применять поэтапный контроль, сначала разобрать идею, потом отдельные шаги в реализации, чтобы он не сваливался в прокрастинацию.

S (зеленые) — для таких сотрудников важен комфорт, причем не только собственный, но и всех вокруг. Они могут задавать странные вопросы при получении задачи, которые, на первый взгляд, не сильно относятся к делу, но им важно убедиться, что они никому не навредят. Правда, их доброжелательность и открытость иногда играет с ними злую шутку. Если по ходу выполнения задачи они будут разговаривать с людьми, то легко могут поменять исходную задачу во имя всеобщего комфорта. Поэтому здесь подойдет либо поэтапный контроль, если вы четко можете выделить точки, где сотрудника может кто‑то «переубедить», либо просто периодический, чтобы исключить такой эффект.

C (синие) — системные перфекционисты. На этапе постановки задачи ждите от них много‑много вопросов, чтобы выяснить абсолютно все, любые риски и «планы Б» по задаче. А на этапе выполнения нужно бороться с тем самым перфекционизмом. Здесь можно использовать выборочный или периодический контроль, преимущественно ближе к сроку выполнения задачи.

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

Про мотивацию

И последним кусочком пазла на сегодня будет мотивация.

Выделяют 4 основных причины, почему сотрудник что-то не делает:

  • Не понимает (задачи или ее важности)

  • Не может (нет ресурсов)

  • Не умеет

  • Не хочет

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

Про мотивацию написано очень много, и это тема для отдельной большой статьи. Я лишь хочу обратить внимание на то, что моделей оценки мотивации великое множество (например модель Герчикова, пресловутая пирамида Маслоу и т д), и важно определить, что именно является мотиватором для вашего сотрудника, и дальше эту самую мотивацию для него обеспечить.

Модель Герчикова, для примера, выделяет 5 типов мотивации:

  • Инструментальная — про деньги и возможность зарабатывать

  • Профессиональная — про развитие и возможность использовать свои знания

  • Патриотическая — про важность для компании и коллег

  • Хозяйственная — про возможность самостоятельности

  • Избегательная — про комфорт и избегание каких‑то демотиваторов

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

Резюме

Подводя итог, получается небольшой чеклист, как же «заставить» ваших сотрудников работать:

  1. Правильно организуйте работу и правильно поставьте задачу.

  2. Выберите правильный контроль.

  3. Учитывайте психотип сотрудника.

  4. Учитывайте и используйте мотивацию сотрудника.

Эпилог

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

Тоже самое и в работе с сотрудниками. Да, было бы сильно проще, если бы они все были одинаковые, как под копирку. Но вряд ли получилось бы делать что‑то серьезное. А они разные. И в этом ваша сила, как руководителя, но и в этом же ваша основная сложность.

P.S.

Приглашаю присоединиться к моему тг‑каналу «Седой директор». Там и про управление людьми, и про менеджмент в IT, и много разных интересных тематик.

Подписывайтесь https://t.me/sedoydirector

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


  1. datacompboy
    00.00.0000 00:00
    +8

    Всё уже придумано за нас:

    надо выпускать львов.

    В НИИ стали приводить львов и выпускать в рабочее время в коридоры, чтобы сотрудники работали, а не болтались. Потом случилось ЧП, и львов убрали. Один лев — другому:
    — И нужна была тебе эта уборщица! Я двадцать два научных сотрудника съел, и никто не заметил!


  1. BattleAngelAlita
    00.00.0000 00:00
    +9

    >Почему так происходит?
    Потому что в 21-ом веке, в индустрии где ВСЁ это R&D, манагёры всё ещё живут принципами фабричного производства из 19-ого века.


    1. ilyaprakht Автор
      00.00.0000 00:00
      +1

      Пока не понял, хочу я с вами согласиться или спорить) Можете деталей добавить? О каких принципах 19 века идет речь?


      1. BattleAngelAlita
        00.00.0000 00:00
        +3

        Конвейерное производство, предсказуемость всех операций, низкая квалификация и лёгкая заменимость работника. Они воспринимают работника как машинку, в которую можно засыпаьт пластиковых шариков, и на выходе получить 200 изделий в час. Да, конечно, и сейчас существуют такие производства, где работник все 8 часов на конвейере вставляет пластиковую бибу в картонную бобу. Но тема-же про разработку. А разработка это R&D, т.е. создание апсолютно нового, ни кем не измеренного и никем ещё не изученого продукта. Тут конвейерный мэнеджер, учивщиеся по книгам 20-ых годов — просто вредитель.


        1. ilyaprakht Автор
          00.00.0000 00:00
          +5

          Теперь совсем не понял. Я не писал про конвейер. Наоборот, про погружение в особенности сотрудника, в его психотип, в его мотивацию. Это не 19 век, а вполне себе 20-21. Разве нет?

          Или вы не про статью, а в общем, как дополнение? В этом случае согласен, такое часто встречается, и это проблема.


  1. Fangaro
    00.00.0000 00:00

    У Вас название: "Как “заставить” сотрудников работать". Возможно поэтому и отсылка к 19-му веку.


    1. ilyaprakht Автор
      00.00.0000 00:00
      +1

      Оно же в кавычках) это, своего рода, ирония. А пишу я наоборот, о том как найти подход


  1. realevil
    00.00.0000 00:00
    +1

    На трех проектах в моей карьере у меня были руководители с примерно похожим подходом: вода про "мотивацию", "типы", флоу "сроки-контроль" и проч.

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

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

    И поверьте, разница между тем, когда ты объясняешь какому-то "левому хмырю", почему тут выросли сторики, а ему до фонаря вообще, он же такие красивые картинки нарисовал про мотивацию, ему НЕКОГДА вникать в то, что происходит, "программировай давай", и между тем, кто говорит с тобой на одном языке, но ЕЩЕ и ставит задачи по своему положению это разница между Теслой и индийской машиной за 1000$. Обе машины: на какую сами сядете, на какую подчиненных посадите?


    1. ilyaprakht Автор
      00.00.0000 00:00
      +1

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

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

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


      1. Elon_space
        00.00.0000 00:00

        100% согласен. когда тимлид пытается выехать только на софт скиллах и не шарит в матчасти - это тупиковый путь


        1. ilyaprakht Автор
          00.00.0000 00:00
          +2

          Есть такой подход, называется Servant leadership. Идея в том, что умные люди работают, а ты, как руководитель, им помогаешь чем можешь, и не мешаешь.
          Так вот, с технарями такое работать не может. Здесь лидерство и уважение, во многом, определяются через экспертность. И потому нормальному тимлиду надо быть классным технарем.
          А чтобы быть ХОРОШИМ тимлидом, нужно и то, и другое.


          1. Giz-A
            00.00.0000 00:00
            +1

            да, я как раз говорю об ИТ-сфере и наличии по "уомлчанию" высокой компетентности у руководителя


    1. ozzyBLR
      00.00.0000 00:00

      Вы говорите про четыре проекта, а опыт индустрии - это "сто тысяч миллионов" проектов. Означает ли это, что опыт индустрии однозначно подойдёт конкретно вашему проекту? Нет. Но ваш личный опыт совершенно точно не перечёркивает опыт индустрии. Т.к. в её масштабах это отклонение - это даже не песчинка на берегу океана.

      Но в целом соглашусь со мнением, высказанным выше. Взгляд на менеджмент немного отдаёт нафталином.


      1. geirby
        00.00.0000 00:00

        Все правильно: эти "сто тысяч" и есть машина из страны рупий. Она возит, в ней есть крыша и двери и даже стекла из пластика.

        Огромная "индус-трия" компании Microsoft год за годом выдаёт на гора шлак вместо продукта и выглядит молодцом именно в тех небольших сегментах, которые менее коммерциализированы, а, значит(как мне кажется), ещё не успели привлечь к себе внимание стаи очередных сияющих уверенностью выпускников мва-курсов.

        Телега едет, куда ей деться-то...


      1. ilyaprakht Автор
        00.00.0000 00:00
        +3

        А как надо, чтобы не было нафталина?

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


        1. Reposlav
          00.00.0000 00:00
          +3

          Между классическим менеджментом и самоорганизованными командами есть еще множество промежуточных вариантов. Лично я, как тимлид, придерживаюсь подхода "Manager as a service" и принципа "Не управляй, а направляй".

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

          Но, конечно, такой подход будет работать не во всех компаниях и не во всех профессиях


          1. ilyaprakht Автор
            00.00.0000 00:00
            -1

            Спасибо за комментарий. Сказкой не покажется, очень даже верю :)

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

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