4 причины, почему люди чего-то не делают или “Как раскачать low-performer’а”

    Так получилось, что тесть и теща у меня доктора педагогических наук. Что приводит к тому, что волей-неволей начинаешь постигать различные полезные методики :)

    Однажды, после какого-то ученого совета за виски чаем на кухне тесть говорит: Саш, а вот как ты считаешь, почему люди чего-то не делают?

    Честно сказать, вопрос поставил меня в тупик. Я начал фантазировать: ну, обстоятельства мешают, черты характера, недостаток опыта…

    Не-не, сказал, тесть, все не так. Если люди чего-то не делают, для этого может быть 4 причины. После чего мой арсенал управленческих инструментов пополнился еще одним. И именно об этом инструменте мы сегодня поговорим, а заодно разберем несколько историй из реальной жизни:
    • Почему менеджеров проектов надо пересаживать в отдельное здание
    • Что делать, когда ваш заказчик не пользуется вашей системой отчетов
    • Как раскачать low-performer’а




    Итак, если человек не делает того, что вы от него хотите (или делает не то, или не так), не надо сразу кидаться его убивать решать проблему. Давайте возьмем паузу. Ведь если человек ведет себя не так, как мы от него хотим, для этого всегда может быть одна из 4 причин:

    1. Нечеткая цель (понял по-своему)


    Помню, еще в Intel говорю своему сотруднику: Макс, посмотри статические анализаторы. Макс говорит, мол не вопрос, и уходит. Приходит через 3 дня. Я:
    — Ну как?
    — Посмотрел.
    — И…?
    — Вот таблица…

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

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

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

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

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

    2. Не умеет (сюда же отнесем: не знает)


    Человек может не уметь делать то, что мы от него хотим. При этом он может добросовестно заблуждаться, что он умеет (“в крайнем случае разберусь”). “Если я писал виртуальные машины, неужели я презентацию в PowerPoint’е не сделаю?..” — и ведь сделает. Другое дело, что ее никому нельзя будет показывать, но это другая история…

    Есть ровно один случай, когда мы на 100% можем быть уверены, что человек умеет что-то делать. Если он уже неоднократно успешно (тут важны оба слова) делал аналогичные задачи, и вы это видели.

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

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

    3. Не может


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

    Или если предложить инженеру поотлаживать сурового корпоративного Enterprise монстра на 386 компьютере, где монстр только запускается 20 минут — вероятно, тоже задача будет двигаться не быстро.

    4. Не хочет


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

    Как пользоваться инструментом?


    Интуитивно, мы часто начинаем с 4-й причины и пытаемся найти решение по ней. “Как бы мне замотивировать сотрудника делать A, B и C” — вероятно, самый популярный запрос на наших тренингах.

    Эй, погодите, вопрос-то точно в мотивации? Давайте вначале закроем первые 3 причины. Если они не закрыты (нет у вас такой уверенности) не надо пока идти и решать “не хочет”. Это непросто, и на эту тему есть другие инструменты (раз и два).

    Но иногда доходит до смешного.

    Случай из жизни. Звонит как-то технический директор одной крупной компании:

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

    В этот момент мой мозг развалился напополам. Помните, как в КВН?

    Выбегает человек на сцену:
    — Мужики, там Леша в лифте застрял, дайте 500 рублей!
    — Не вижу связи…
    — А и не надо… “Леша в лифте застрял” — информация, “дайте 500 рублей” — просьба.

    Начинаем разбираться. Ситуация получается примерно следующая. В компании были команды исследований и разработок. В каждой команде были инженеры и были самые инженеристые инженеры — технические лидеры. Этих лидеров теперь сделали менеджерами проектов. Они отвечают за команду исследований, команду продуктизации, валидации + заведуют техническим писателем, системным аналитиком и кем-то там еще в рамках своего проекта.

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

    Хмм, картина становится более понятной… И вот тут я неожиданно вспоминаю про 4 причины.

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

    1. Они не понимают, чего ты от них хочешь. Ты им говоришь: думайте о стратегии проекта? Что им делать? Им надо как-то напрячься, покраснеть, припотеть? Как ты поймешь, что они думают о стратегии? По каким признакам?

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

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

    Может быть, имеет смысл им какую-то книжку подарить на эту тему? Или семинар провести? Или ты сам им расскажи. как писать стратегические планы, если ты сам умеешь.

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

    4. Люди вообще хотели быть менеджерами проектов? Или не смогли тебе отказать?

    Тяжело отказывать начальнику, который приходит и говорит: “Друзья, у нас грядет важнейшее преобразование в компании. Единственные люди, на кого я могу положиться — это вы!” Вряд ли кто-то в этот момент скажет: “Да ну нафиг!” Люди молча вздыхают и идут тянуть новую лямку.

    В итоге, перед переездом в новый офис нашлось много тем для обсуждения. :)


    Или вот еще случай:

    Случай из жизни. Подходит человек после конференции в Новосибирске:

    — Александр, такой вопрос. Мы тут три месяца писали новую систему отчетности. В итоге написали. В ней есть все: 28 страниц, на каждой по 10 вкладок. Там есть вся информация — вообще вся.
    — Поздравляю, а в чем проблема?
    — Наша немецкая заказчица ей не пользуется. Она вместо того, чтобы зайти в систему и получить данные, звонит каждому нашему инженеру и спрашивает у него, что он делал. Как нам ее замотивировать пользоваться нашей системой отчетности?

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

    1. Она вообще понимает, что ей надо пользоваться этой системой? Или вы ей написали письмо на 5 страниц с неясным заголовком, а она такая: “О, ребята — молодцы, чего-то делают… будет время, почитаю.”

    2. Она умеет пользоваться этой системой? Почему вы в этом уверены? Сколько времени у нее занимает найти нужную ей информацию? Может быть, она честно попробовала раз, два, три — зарылась в системе, ничего не нашла, и решил по-старинке — звонить инженерам. Они-то всегда отвечают что нужно.

    3. У нее вообще есть доступ в систему? Может быть. она туда зашла первый раз, ее не пустило, и она решила, что система еще не доработана. А пока она дорабатывается, буду-ка я звонить инженерам…

    4. Может быть, человеку просто нравится общаться с вашими инженерами? Или она не доверяет данным в системе и перепроверяет информацию.

    Хорошо бы перед разговором с ней подумать насчет этих причин — и так по ним и идти.


    Основная сложность использования инструмента


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

    Случай из жизни. На одном из тренингов у слушателей возник такой вопрос: как раскачать low-performer’а? В команде есть пара очень крутых ребят, несколько середнячков. И есть один человек, которые делает все существенно медленнее других. Как его раскачать. чтобы он начал делать больше и быстрее?

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

    1. Он не понимает, что то, как он работает — это плохо. Да, он видит, что медленно. Но зато качественно! Не то, что эти — наколбасили кода и бросили. А тут системный подход, юнит тесты, само-ревью и пр., и пр.

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

    2. Человек умеет работать быстрее? Было когда-нибудь такое, что он работал быстро?

    3. Что еще человек делает? Может быть, в скайпе отвечает на вопросы новичком? Или сейчас у него в семье проблемы, не до того ему.

    4. Чего он вообще хочет? Стабильности? Или развития? Денег? Стать тех.лидом? И тогда наши аргументы мы сможем привязывать к его хотелкам.

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

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


    Напоследок — попробуйте поискать причины


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

    Лишний раз подумать всяко не помешает. И совершенно точно, это будет нескучно. :)

    P.S. Предыдущие статьи из серии управленческие инструменты:
    1. Как объяснить, когда чувствуешь одним местом?
    2. Советы практикующего андрагога: как мы учимся
    3. Как играть в нелинейные шахматы
    4. Почему заказчики требуют дурацкие отчеты?
    5. 5 вопросов для прояснения целей или для чего нужен BMW X5?
    6. 4 принципа конструктивного общения или почему мы живем в режиме подвига?
    7. 4-фазный алгоритм решения проблем с людьми или «А чего ты хочешь, если ты такой хреновый менеджер?»
    8. Как невольно затроллить собеседника и получить минус в карму
    9. Набор мебельных ключей или как придумывать конструктивные аргументы
    10. Интеллект-карта «Формула работы с людьми»
    11. Формула нужды или Каким образом нас отжимают?


    P.P.S. Почитал первые комментарии — понял, что надо писать еще одну статью. :) А то наприлетало там опытному менеджеру аж с 2-летним опытом за случай 10-летней давности с Максом.

    Вероятно, мысль я не раскрыл. Давайте раскрою здесь, чтобы не менять текст статьи и релевантность комментариев. Если вкратце и по пунктам:

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

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

    Если читатели статьи поняли меня не так, как я того хотел, я не буду писать плохо про читателей. Люди как поняли, так поняли. Значит, я не раскрыл свою мысль. Поэтому и пишу этот постскриптум.

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

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

    P.S. Блог Стратоплана переехал на отдельный сайт: http://blog.stratoplan.ru — до встречи там!
    Стратоплан
    47.68
    Company
    Share post

    Comments 66

    • UFO just landed and posted this here
        +2
        Винтик заело — меняем всю машину? Или: у сотрудника горе — увольняем нафиг — потому что он не хочет работать, когда его личный мир рушится.

        ОКЭЙ, сэр.

        Ну тогда нужно применить это же самое правил на самих, менеджеров высшего звена:

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

        Схлоапываем все 4 пункта, по аналогии — вывод: не хотят!

        Батенька, вы не в нефтянке менеджером случайно работаете, чтобы так транжирить ресурсы?
        +44
        Мда. Как-то уж слишком непрофессионально все описано. Такое ощущение, что автор никогда не работал менеджером. Стратоплан упал в моих глазах.

        1 «Итак, если человек не делает того, что вы от него хотите...»
        А с чего вы вообще взяли, что человек будет делать то, что от него хотите вы? Любой человек делате только то, что хочет сам.

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

        2 Он не понимает, что то, как он работает — это плохо.
        Что еще за критерий «то, как он работает — это плохо». Вы его сами придумали?
        Можно ведь сказать, что «качество ниже ожидаемого» или «сроки больше приемлемых». Но «то, как ты работаешь — это плохо» — это очень плохая характеристика работы человека. Во-первых, в ней нет конкретики. Во-вторых, в ней не заложено решение. Если человек работал медленно, ему надо работать быстрее. А если все что он делает — это плохо, то что ему делать? Работать хорошо? Так может говорить ребенок 5 лет, но не менеджер.

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

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

        И этот человек учит нас менеджменту?
          +8
          Справедливо. Особенно по 3 пункту. У нас менджер так и не научился за пол года, после первого замечания, ставить нормально задачи. Причем, ему об этом напоминают регулярно, но в итоге в JIRE один заголовок. И по каждой задаче идут уточнения.
            +6
            Спасибо за комментарий. Понял, что мысль свою не донес, а напротив представил себя героем, который скидывает с себя всякую ответственность. :) А это совсем не то, что хотел донести, вообще писал не про это. Написал по этому поводу постскриптум в статье.

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

            Пока оставлю как есть — все равно конечная идея сделать из этого единую книгу. Там, по идее, должно быть все связано и корректно. Если согласитесь выступить ревьюером книги — буду отдельно благодарен. Хочется профессионализм материала не ронять. :)
            +15
            Нечеткая цель — это всегда, безоговорочно вина того и только того, кто эту цель ставит. А уж та задача из примера — эталон того, как делать нельзя. Говорю это как обитающий с обеих сторон баррикад.
              –1
              Позволю себе усомниться во «всегда, безоговорочно». Есть такой вид начальников, которые во всём разбираются и любого подчинённого за пояс заткнут. И подчинённые им нужны лишь в виде недостающих рук, анецефалов.

              Но вполне заслуживает права на жизнь ситуация, когда специалисты набираются для решения проблем в той области, в которой «плавает» руководитель команды. Здесь подчинённый должен сам поучаствовать в постановке задачи.
                +8
                Тут надо четко разделять цели и методы их достижения. Цель должна быть кристально ясна всем участвующим в рабочем процессе, и ответственность здесь лежит на руководители. А вот уж как до нее добраться — тут профессионалы и нужны.

                В примере с Максом я бы сделал так же. Потому что правильная задача должна была звучать «посмотри статические анализаторы и прикрути какой-нибудь». Ожидать телепатических способностей от подчиненных крайне неразумно со стороны руководителя.
                  0
                  Я всё-таки не про Максима, а про «всегда, безоговорочно». Меня смущает именно эта категоричность и безапелляционность.

                  Если говорить про цели, то мне привычней думать о SMART-целях. В таком случае, среди прочего, цель должна быть чётко сформулирована и измеряема. А это уже работа специалиста.
                    0
                    Ну, это мое личное отношение к вопросу. Я так категорично говорю не сточки зрения исполнителя, а именно руководителя. Если я ставлю задачу криво, то сам виноват и мне в голову не придет размазывать ответственность на исполнителя.
                    +1
                    Кстати, конкретно Максиму цель вообще не озвучили, а поставили задачу. Задача != цель ))))
                      0
                      Не могу не согласиться)
                +8
                Если человек может рассказать, как делать задачу — это безусловно лучше, чем если он не может рассказать. Но это не является гарантией того, что он умеет. Я могу достаточно подробно рассказать. как ломать кирпичи рукой. Но в реальности, боюсь, победит все равно кирпич.

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

                Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)
                [...]
                Делегирование задачи — это всегда игра двух или большего количества людей. И если бы я уточнил у Макса, как оно понял задание, этой ситуации бы не возникло. Но если бы Макс сам переуточнил бы у меня постановку задачи — этой ситуации тоже бы не возникло.

                Таки вы сами себе противоречите. Всё-таки виноваты, но виноваты тоже, а не только вы. ;-)
                Ну и плюс, вы ведь менеджер, руководитель. Для вас умение четко ставить задачу — одно из ключевых. Т.е., виноваты оба, но вы — в большей степени. Значительно большей.
                  +3
                  Таки вы сами себе противоречите. Всё-таки виноваты, но виноваты тоже, а не только вы. ;-)
                  Ну и плюс, вы ведь менеджер, руководитель. Для вас умение четко ставить задачу — одно из ключевых. Т.е., виноваты оба, но вы — в большей степени. Значительно большей.


                  Спасибо за комментарий. Конечно, виноват. Просто хотел подчеркнуть, что ответственность за четкость понимания задачи — она всегда на мне, независимо от того, какую роль я играю — менеджера, сотрудника или бизнес-партнера.

                  Но подчеркнул, как умею, коряво. :) Написал проясняющий постскриптум.
                  –1
                  Так и не понял из статьи, о каком вообще «инструменте» идёт речь? Что это вообще за управленец, который не может сформулировать задачу, не может выбрать из сотрудников наиболее компетентного для её выполнения, и не может предоставить ресурсов под неё? Нужно начинать с того, в чём вообще этот менеджер видит своё предназначение?
                    +16
                    «Но если бы Макс сам переуточнил бы у меня постановку задачи — этой ситуации тоже бы не возникло.»

                    А с чего ему уточнять, если он решил, что всё понял абсолютно правильно?
                      +1
                      что всё понял абсолютно правильно?

                      Программист не понял главного: что должно быть результатом его работы, а значит нужно было уточнить. Имхо.
                        +3
                        Для того, что бы захотеть уточнить у него должны были появиться сомнения. А он был уверен в правильности своего понимания задачи.
                          0
                          Классический случай, когда лажанулись оба — и программист и менеджер.

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

                          Аналогично, когда менеджер ставит задачу — должно чётко прозвучать, что надо на выходе. Не «посмотри», а «прикрути анализатор к нашей системе контроля версий». Не «проверь», а «проверь и напиши мне к вечеру письмо по результатам». Не «подумай какой вариант быстрее работает», а «напиши тесты и пришли мне результаты до пятницы». Если менеджер не сказал чётко, что ему нужно — может получить что угодно, от чертежей адронного коллайдера до открытки с розовым пони.
                            +3
                            Классический случай, когда лажанулись оба — и программист и менеджер.

                            Если в коллективе есть менеджер, то постановка задачи так, чтобы она не подразумевала многоликости трактовки — это его работа. Если разработчик будет включать своё воображение вперемешку с паранойей и додумывать стопицот потенциальных трактовок задачи, которые были бы валидны с позиции некой извращённой логики — то в итоге он первый кандидат на то, чтобы тот же самый менеджер вписал его в, прости господи, low-performer'ы. Ибо фигли он столько вопросов задаёт и придумывает какие-то странные непонятные сценарии, когда должен код строчить.
                              0
                              Если в коллективе есть менеджер, то постановка задачи так, чтобы она не подразумевала многоликости трактовки — это его работа.

                              Не все задачи поддаются 100% формализации, все равно будут темные области. Как бы вы ни расписывали задачу — все равно найдется один-два-три ключевых момента, которые будут поняты неправильно.
                              Постановка цели должна в первую очередь опираться на исполнителя. Кому-то достаточно сказать «поищи статистические анализаторы» и он в контексте общей проблемы поймет что нужно сделать, а другому нужен пошаговый алгоритм.
                              Но для того чтобы избежать проблемы недопонимания — исполнитель обязательно должен уточнить правильно ли он понял задачу, пересказав ее своими словами. Я когда разговариваю с заказчиками стараюсь делать именно так и хотел бы чтобы члены моей команды поступали так же.
                              А вот если не последовало уточняющих вопросов или пересказа — вот тогда менеджеру 100% нужно вмешиваться и вытаскивать из исполнителя клещами, как тот понял задачу. Проблемы как правило возникают именно здесь.
                        +2
                        1. Он не понимает чего ты от него хочешь. Ты ему говоришь: “Переуточняй постановку задачи”?
                        2. Идем дальше. Если человек никогда не переуточнял постановку задачи, то как он её переуточнит сейчас? Может быть, он попробовал, увидел, что получается какая-то ерунда, и даже еще раз пробовать не стал.
                        3. Как у человека с загрузкой по времени? Ты, наверное, от него еще релизов каких-то требуешь? Как у него со временем?
                        4. Человек вообще хотел переуточнять постановку задачи?
                        0
                        Но если бы Макс сам переуточнил бы у меня постановку задачи — этой ситуации тоже бы не возникло.

                        Согласен.
                        Если программист додумывает формулировку задачи за менеджера, вместо того, чтобы уточнить, то он[программист] берет на себя часть ответственности за правильное выполнение задачи.
                        Имхо, проблема не в расплывчатой формулировке задачи на входе, а в том, что изначально отсутствовал диалог (или обратная связь) между менеджером и программистом.
                          +3
                          Точно, поэтому я постоянно бегаю с глупыми вопросами к начальству.
                        • UFO just landed and posted this here
                            +2
                            В нечетких задачах можно обвинять менеджера, когда вы являетесь сотрудником. Но когда задачу ставят вам, не всегда можно сказать своему начальнику потом: ну ты там как-то соберись, научись нормально задачи-то ставить…

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

                            Максу платят за то, чтобы он [эффективно] прикручивал статические анализаторы. Вам платят за то, чтобы вы [эффективно] ставили ему задачи. Тот факт, что в каких-то компаниях придерживаются принципа «Я начальник — ты дурак», сути не меняет.
                              +1
                              И хочется заметить, что в этом плане подход в Японии гораздо более правильней. В том что подчиненный не справился всегда виноват начальник, который поставил перед ним такую задачу. Почему он не справился ( не правильно понял, не хватает опыта, времени) не важно. Спрашивать причину провала следует всегда с руководителя, он ведь в конце концов за эту ответственность получает вполне солидную зарплату.
                              +1
                              Друзья, спасибо за первые комментарии. Понял, что случай с Максом и кто же на самом деле был там виноват — важный вопрос. :) Добавил посткриптум в статью, надеюсь, что мысль пояснил. Спасибо за комментарии!
                                +1
                                Александр, извини, не смог удержаться :) Влезу со своим ИМХО.

                                Причиной дискуссии про Макса стала путаница с понятиями цель и задача. Задача != цель.
                                говорю своему сотруднику: Макс, посмотри статические анализаторы.

                                Это не цель. Это задача. Задача отвечает на вопрос «что надо сделать?». Цель — «зачем?»

                                Задача без цели, как правило, смысла не имеет. Цель без задачи имеет смысл.

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

                                Макс не спросил: «а на фига?». ИМХО, проявление непрофессионализма с его стороны.

                                Как-то, так.
                                  0
                                  Сергей, спасибо за комментарий! Рад тебя видеть, пусть и виртуально! :)
                                  +2
                                  Александр, вы явно хотели подчеркнуть, что людям всегда следует придерживаться внутреннего локуса контроля, не зависимо от того на какой должности они находятся. А большинство поняли это так, будто вы хотите свалить ответственность на подчиненного. Так и напишите, возможно станет понятнее
                                    0
                                    Я боюсь, если начнем говорить про «локус контроля», то всех только запутаем. :)) Постарался в посткриптуме прояснить.
                                    0
                                    Когда-то на тренингах по корпоративному управлению учили всегда уточнять задачу, пересказав ее своими словами. Стараюсь использовать в работе с заказчиками — сильно помогает. А вот если уточняющих вопросов от исполнителя не поступило — повод задуматься и постараться их вытянуть…
                                    НО степень детализации задачи должна зависеть от уровня исполнителя. Кому-то достаточно сказать «поищи статистичекие анализаторы» и он в контексте проблемы сразу поймет о чем речь, а кому-то потребуется пошаговый алгоритм.
                                      0
                                      Спасибо за комментарий.

                                      Стараюсь использовать в работе с заказчиками — сильно помогает.


                                      100%.
                                    0
                                    Менеджер был бы не менеджером, не пытайся он каждый раз оправдывать свою лень, глупость, некомпетентность и поиск виновников вокруг себя.
                                      0
                                      Цель (важно умение четко ее сформировать) +структура (тут важно правильно сформировать порядок выполнения задачи) +мотивация (здесь комментарии не нужны) = ожидаемый результат от работника.
                                      Что касается самих работников, то нужно уметь планировать пути достижения цели.
                                      Я например использую miniplan.ru и др напоминалки — помогает.
                                        +3
                                        >Помню, еще в Intel говорю своему сотруднику: Макс, посмотри статические анализаторы. Макс говорит, мол не вопрос, и уходит.
                                        >Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)
                                        >Мне нужно было, чтобы человек нашел бесплатный статический анализатор Java кода и прикрутил его к нашей системе контроля версий.

                                        Вы разберитесь, посмотреть или посмотреть и прикрутить. Видимо у Макса telepat.dll непропатченный.

                                        Бородатый анекдот:
                                        Жена мужу-программисту: иди в магазин и купи палку колбасы, а если будут яйца, то купи десяток.

                                        Муж приходит с 10 палками колбасы.

                                        P.S. Муж понял задачу однозначно. Зачем что-то уточнять? =))
                                          +1
                                          Есть старое армейское правило: получил приказ — повтори своими словами.
                                            +6
                                            Сталкивался с людьми, считающими что опыт командования в армии делает их очень компетентными управленцами — и крайне счастлив, что армейские правила в общей массе так в армии и остаются.
                                              0
                                              В армии своя специфика и другие внешние условия в чем-то они проще, в чем-то сложнее. Кроме того, там тоже есть хорошие и плохие управленцы. Что-то мне подсказывает, что хорошие командиры в армии не менее хороши и в жизни.

                                              Тем не менее правило придумано как раз чтобы обезопасить всех от случаев недопонимания. Там цена вопроса существенно выше. Хотя, конечно, все случаи оно тоже не покрывает.
                                            0
                                            11 палок колбасы муж должен был купить.
                                            +7
                                            Я с такими управленцами, которые говорят «посмотри список _», а потом пропадают на 3 (!!!) дня, а потом появляются (!!!) и спрашивают «а почему сайт ещё не готов?» (какой сайт? почему он должен быть готов? почему задача поставлена устно, а не в трекере?) я встречаюсь регулярно. Но самая печаль в том, что они считают, что так и надо, да ещё и не готовы признать свою неправоту. Менеджер, который не умеет и не хочет общаться с командой, потому что он всегда прав — это что-то эпическое.
                                            Если бы я был в такой ситуации и менеджер через 3 дня «чуть не убил», я бы уволился, а заодно в подробностях рассказал об этом менеджере и о его управленческих возможностях вышестоящему начальству.
                                            Вы говорите одно, а думаете совсем другое. Если вы сказали «хочу диван с розовой спинкой», это значит, что вы хотите диван, у которого, очевидно, розовая спинка. Если вы при этом подумали, что на самом деле то вы хотите чашку кофе и яблоко, то совершенно очевидно и никаких сомнений, разночтений, вариантов «а кто виноват, что я без яблока» нет и быть не может. Я бы охарактеризовал такое как саботаж.

                                            В остальном, очень похоже на опыт работы во некоторых местах. В том смысле, что я часто сталкиваюсь с отсутствием менеджмента. Как в статье — приходит Вася (менеджер проектов) раз в неделю и говорит «а чо у нас с задачами то?». Вот тут и Васю должны уволить к чертям. Ведь сам факт, того, что он приползает и задаёт такой вопрос, говорит о том, что процесс неуправляем. А Васе ответ всегда один — «что-то делается»

                                            Если есть таск трекер и люди делают задачи, которые им ставят, то непонятность формулировок лежит тяжким грузом на тех, кто эти задачи описывает. «Не умею», «не хочу» и «не могу» говорят о том, что люди не имею квалификации для этой работы и возникает совершенно справедливый вопрос HRам (и техническим специалистам, которые участвовали в собеседованиях) — почему же их взяли на работу?
                                              –2
                                              «Чуть не убил» — это ж было шутейное обозначение моей эмоциональной реакции. Прежде всего на себя, потому что понятно же, что моя вина, что цель так нечетко поставил.

                                              «Не умею», «не хочу» и «не могу» говорят о том, что люди не имею квалификации для этой работы и возникает совершенно справедливый вопрос HRам (и техническим специалистам, которые участвовали в собеседованиях) — почему же их взяли на работу?


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

                                              Не могу — вопрос не про собеседования, а про наличие ресурсов.

                                              Не хочу — мотивационные факторы можно проверить на собеседовании (обычно никто не проверяет, но это тема отдельно статьи :). Но у человека они со временем меняются. И отношение к работе меняется. Мы про это достаточно подробно писали вот тут.
                                              –3
                                              Хорошая и очень годная статья.
                                              И тем более поэтому хочется осветить один момент по «ту сторону баррикад», сторону разработки.

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

                                              В результате задача сделана в меру понимания программистом того, как это должно работать. Без учета того, что этим функционалом будут пользоваться люди «гуманитарного склада ума» (С). Без учета понятия «удобство». В общем, как в классических случаях, когда интерфейсы делают программисты: на стороне сервера всё вроде бы написано хорошо, но пользоваться этой штукой невозможно.

                                              Однако в нашей же игровой студии, находящейся несколькими этажами в здании ниже, программист никогда не начнет программировать, получив таск. Благо, что люди сидят на одном этаже — он подойдет к заказчику, и спросит "- Ты хочешь что бы эта штука работала так-то и так-то? Ок, это сделаю за 10 дней. Однако могу сделать за 5 дней, если вот ту штуку не трогать, она все равно устареет в следующем релизе". «О, отличная мысль. Тогда сейчас откомменчу таск, и делай».
                                              То есть убедиться, что ты находишься с заказчиком на одной волне — общее правило, позволяющее сэкономить кучу времени избежав переделок.

                                              Вот где-нибудь программистов учат такому?

                                              (п.с. К слову, из-за этого в ту игровую студию практически невозможно попасть программисту, который хоть и гениален, но не имеет желания развивать свои коммуникативные навыки — ибо в этом случае он всегда будет источником проблем из-за дискоммуникации. А одними «автономными» задачами его нагружать будет крайне сложно.)
                                                +4
                                                Тоже с таким сталкивался регулярно. Программисты начинают делать, не выяснив все подробности у заказчика.

                                                Вообще, это означает, что задача не сформулирована четко.

                                                Требования юзабилити можно рассказывать не только устно, их вполне можно изложить в трекере, а еще лучше нарисовать мокап. Но для менеджера это, очевидно, напряг, которого он пытается избежать путем устных переговоров. Для программиста же напряг ровно в противоположном — обсуждать по десять раз устно вместо того, чтобы прочесть четко изложенное требование и вернуться к нему в любой момент времени.
                                                Вот вам и конфликт интересов из-за разницы психотипов.
                                                  –1
                                                  Я склонен считать, что лучше всего найти понимание через обсуждение, а не через 10 вот таких итераций:
                                                  — «ты опять сделал не так»
                                                  — «я сделал всё как в таске написано»
                                                  — «так ведь ведь в таске не написано было делть эту фичу вот так»
                                                  — «поэтому я и сделал так, как считал правильным»
                                                  — «ну какое же это правильно, если мне надо было наоборот»
                                                  — «так надо было написать в таск, что надо наоборот»
                                                  — «ок, напишу»
                                                  (все расходятся недовольные тупизной друг друга, и история повторяется через два дня с новой «фичой не как в таске»)

                                                  Одна плохая крайность — «Я же тебе рассказал чего я хочу, неужели так просто взять и сделать безо всяких там ТЗ..?»
                                                  Вторая плохая крайность — «Да прочитал я что в таске написано, зачем тратить время на говорильню, сделаю к пятнице..»

                                                  Ведь программисту ничего, по-идее, не мешает выяснить «истинные» потребности заказчика, и согласовав их с ним, зафиксировать в таск-трекере в удобном для себя виде? Он не робот, и
                                                    0
                                                    … и вполне может найти общий язык с заказчиком, при обоюдном желании.
                                                    –3
                                                    программист, это инженер. Если вы хотите получить полностью разжёванную задачу, то честно называйте себя кодером.

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

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

                                                    Даже если программисту не выдают грамотно составленное ТЗ — нужно обозначить себе четкое понимание того, что будет в итоге.

                                                    источник: "Искусство программирования?"
                                                      +3
                                                      >> программист, это инженер. Если вы хотите получить полностью разжёванную задачу, то честно называйте себя кодером.

                                                      Обратите внимание, такому менеджеру не нравится не то, что нужно давать разжеванные задачи. С этим как раз все в порядке — ему в напряг разжевывать. Но решения, которые принимает программист, ему перманентно не нравятся. Он считает, что при каждом вопросе программист должен выйти из потока и найти незаменимого менеджера, который все пояснит на словах. Пользуясь вашей терминологией, такому менеджеру нужен именно кодер.
                                                  +1
                                                  Прочитал статью дважды, но не нашёл ответа на вопрос из заголовка: “Как раскачать low-performer’а”
                                                  Увидел описание причин первого порядка что результат не получен в срок и в необходимом объеме, но не ясно как выявлять причины второго порядка и что с ними делать.

                                                  А еще есть потрясающие случаи, когда человеку не хватает собранности и усидчивости. Короткие задачи он делает прекрасно, а на длинных начинает отвлекаться и постоянно движется «не туда». С одной стороны надо почти непрерывно контролировать такого работника, это микро-менеджмент, который негативно влияет как на менеджера, так и на исполнителя. А с другой стороны ослабление контроля ведет к падению производительности. При этом человек и умеет, и хочет, и может, и понял. У программистов такое встречается очень часто.
                                                    +1
                                                    Разбейте длинную задачу на короткие :-). «Путь в тысячу ли начинается с первого шага.» Прямо возьмите исполнителя и вместе с ним разбивайте. Не нужно сразу всю, просто начните определять: сейчас надо это, это и то. Одной из причин может быть то, что исполнителю сложно так самому взяться и разбить, например, потому что масштаб пугает при одной только мысли о задаче. И вообще говоря, такая операция выделения подзадач — тоже умственная работа, на неё нужны определённые усилия.
                                                      0
                                                      Возможно, разработчик иррационал. Тогда кроме варианта с разбиения задачи, есть другой. Такому разработчику можно помимо основной задачи дать ещё несколько мелких, и разрешить переключаться на них, когда большая достала. При переключении между задачами разработчик будет чувствовать прилив сил от результатов.
                                                        0
                                                        Спасибо за комментарий. Мысль была в том, что перед раскачкой надо таки провести анализ. А дальше в зависимости от причин. Скорее всего, это будет обратная связь, где человеку нужно будет «продать проблему» с его низкой производительностью по алгоритму, который мы разбирали вот здесь и здесь. И вместе с ним смотреть, будут ли изменения.

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


                                                        Да, распространенная ситуация. :)) Тут опять же, если обе стороны согласны с тем, что присутствует такая, скажем так, особенность в работе, и согласовали частоту и степень контроля — то это не будет восприниматься как микроменеджмент. Микроменеджмент — это в том числе, несогласованный, неожиданный тип контроля.
                                                          0
                                                          То есть описанные причины не являются исчерпывающими для определения в чем проблема? И как же в этом случае ответить на вопрос «как раскачать low performer_а»?
                                                            0
                                                            Имхо пока с человеком не начнешь общаться, полного списка причин не составишь. То, что написано в статье — возможные причины, которые мне сразу бросились в глаза при анализе ситуации. В разговоре может вылезти все, что угодно — от неприятия инженером конкретного менеджером до личных проблем.

                                                            Через это и станет ясно, что делать для «раскачки». А может быть, все кончится вообще расставанием.
                                                        +3
                                                        Для меня ситуация с Максов очень странная и непонятная. Что значит сказал своему разработчику? Получается, если менеджеров несколько, Макс должен учить наизусть, то что ему говорят все менеджеры, и такая ошибка очень распространена в среде менеджмента. В не правильной, не точной постановке всегда виноват менеджер. Работа программиста — писать код. Работа менеджера — ставить задачи(формализовать требования бизнеса, объяснить задачу исполнителю, проконтролировать сроки выполнения, корректировать и консультировать исполнителя) и если он с этой работой не справился — обвинять в чем-либо программиста не правильно. Программист может подойти и уточнить, что же именно необходимо бизнесу. Но ему не за это платят деньги.
                                                          +3
                                                          >Макс, посмотри статические анализаторы.
                                                          вообще-то Макс все правильно сделал. Глагол смотреть несет смысл мониторинга, а не воздействия на объект. В отличие от «прикрутить».
                                                          >Я чуть его не убил.
                                                          Думаю, он тоже
                                                            +4
                                                            Вспомнилась примерно такая история, дословно не нашел, так что по памяти.
                                                            «У нас тут лампочка периодически в коридоре вырубается. Оставили заявку „Прийти и посмотреть, что за фигня“. Инженеры пришли, посмотрели, сказали, „да, фигово“ и ушли. Надо похоже следующую заявку четче сформулировать»
                                                              +2
                                                              А мне вот такая вспомнилась:
                                                              -Админ, что-то форум не работает, можно разобраться?
                                                              -Можно, разбирайтесь.
                                                                +1
                                                                И похоже тоже с русского баш.рга. :)
                                                                Аааа, оттуда же!
                                                                Изменения
                                                                Вроде исправлен баг под кодовым названием «Редактор как-то не так сохраняет». По этому поводу чет такое сделал, чтоб сохранял как-то так.
                                                              0
                                                              > Моя мысль очень проста: ты должен брать ответственность за происходящее на себя. в какой роли ты бы не находился.
                                                              Нести ответсвенность за зарплату исполнителя?
                                                                0
                                                                С философской точки зрения, да. Потому что сначала должна расти ответственность, а потом зарплата — когда станет понятно, что с ответственностью ты справляешься.

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

                                                                Но это мои убеждения, мои, так сказать, тараканы. :) И это то, что принято в нашей компании. Другая точка зрения, вероятно тоже имеет право на жизни в каких-то компаниях.
                                                                +3
                                                                «Я чуть его не убил. Мне нужно было, чтобы человек нашел бесплатный статический анализатор Java кода и прикрутил его к нашей системе контроля версий.

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

                                                                Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)»

                                                                Щито?
                                                                Классика перевода стрелок и оправдания собственной промашки.

                                                                Если вы над Максом ходите, то вы по определению должны иметь больше опыта, уточнять неточности, и ловить ошибки Макса, а не наоборот. Есть конечно проактивные люди, которые не отходя от кассы вас расспросят (например я вас бы сразу задержал вопросом «И когда вы говорите посмотри, вы имеете ввиду...?», потому что я ненавижу нечёткие задания), но ожидание такого подхода от каждого работника как-то бредово звучит, особенно от вас — человека, который позиционирует себя как менеджер.

                                                                Если честно, только байки и понравились. Хороший опыт и своевременный [само]анализ.
                                                                  +1
                                                                  понравилось,

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

                                                                    Невозможно уметь всё.
                                                                      0
                                                                      Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)

                                                                      Не сомневайтесь, тут только ваша вина и кивание на Максима — «мог бы и переуточнить» — признак инфантильности сознания.
                                                                      Если не понятно, то поясняю — Максим считал, что он понял задачу и у него не было вопросов к тому, что он понял. И если он не дурак, то уже в следующий раз, зная что начальник плохо объясняет задачи и не способен убедиться в правильности понимания задачи подчиненным, предпримет попытку уточнить совпадение понимания обеих сторон. Говоря прямо — возьмёт часть обязанностей менеджера на себя.
                                                                      Бывают ситуации, когда начальнику лучше помочь: начальник в мыле разгребает завалы, старается выполнять свои обязанности и т.п. Но обвинять подчинённого в том, что он не взял добровольно на себя часть твоей работы это — свинство.

                                                                      Only users with full accounts can post comments. Log in, please.