Каверзы при собеседовании на project manager'а или прогулка по минному полю чудес

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

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

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

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

1) У вас есть скрам команда из разработчиков и тестировщиков. Разработчики работают, оценивая задачи в сторипоинтах, а тестировщики в часах. Тестировщику поставили задачу запрограммировать кнопку, но он не умеет пользоваться сторипоинтами. Как объяснить ему методологию оценки задачи, которую ему предстоит использовать?

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

2) Что делать, если удаленный сотрудник потерял перфоманс?

image

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

3) Сотрудник ежедневно опаздывает на daily meeting, что делать?

“Он не разделяет ценности команды и компании, зачем нам такой сотрудник?” — Однажды я услышал такую фразу от hr, и задумался, а действительно ли стоит держать человека, который живет за 80 километров от офиса, ему не дают удаленку, и по утренним пробкам он постоянно опаздывает на митинг к 9 утра?

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

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

  • Узнайте у участников митинга удобное для всех время, может у кого-то высокий риск опоздания на 10-15 минут, за которые митинг уже закончится, а может у участников митинга разные часовые пояса и у кого-то ваши 9.00 по МСК будут 5 утра;
  • Подготовьте такое место для митингов, чтобы у членов команды не возникало отторжение от совещаний, на которых приходится кричать, чтобы услышать друг друга посередине опенспейса;

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

  • Давать небольшой всплеск дофамина в начале митинга путем рассказа о каком-то достижении компании или отдела, поздравления кого-то с достижением или с праздником, об отличной новости в отрасли. В случайные дни можно в начале встречи ставить на стол маленький торт (а почему бы и нет?);
  • Играть в игру “кто не успел — тот опоздал”. Кто опаздывает — тот ведет meeting notes следующие 2 встречи, к примеру. Это позволяет привнести в начало встречи чувство шуточного ехидства, и утвердиться вовремя пришедшим, что их пунктуальный приход — верное поведение в команде и компании.
  • Главное, пожалуй, к чему не стоит прибегать — это к финансовым штрафам. По трудовому законодательству РФ вы не можете делать вычет из оклада, а мотивационная составляющая, как правило, достаточно низка, чтобы это “ударило” по карману сотрудника и, следственно, мотивировало его.

4) Разница между waterfall с методом набегающей волны и scrum?

Постоянно работая с методологиями на этот вопрос ответить несложно. Waterfall и Scrum — это про процессы. Метод набегающей волны — это метод планирования. Поэтому мы получаем вопрос с подвохом, в котором метод набегающей волны — лишнее условие, и рассчитан вопрос на ваше четкое понимание методологий waterfall и scrum. Scrum — итеративная модель, позволяющая взять в работу проект до получения полного объема требований, в процессе работы над которым требования к продукту могут меняться, и процесс итерации повторяется. Waterfall — это четкое обозначение требований к будущему продукту, и отступление от них ломает процессы. А планировать методом набегающей волны можно все, что угодно. К слову, кто бы что ни говорил про косность waterfall’а, но даже PMBOK не запрещает использовать Rolling Wave Planning с ним.

5) На stand-up митингах несколько ваших коллег не рассказывают команде о вчерашних трудовых успехах, а “отчитываются” перед вами, что делать?

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

6) Предположим, у работника есть менеджер + линейный руководитель + еще 2 менеджера с других проекта (сотрудник работает над несколькими проектами одновременно), и два или три его руководителя поставили ему единовременно срочные задачи, к какой он должен приступить?

image

Вопрос из разряда математической задачи: “Вася купил 1000 бананов…”. А зачем?
При подобных иерархиях в компании разногласия между менеджерской составляющей неизбежны, разработчик не должен потакать таким ситуациям и влезать в самостоятельные разборки между 10-ю управленцами, чья задача приоритетнее, для этого есть менеджер его команды или непосредственный руководитель.

7) Разница между тим лидом и тех лидом в команде?

Очевидно, технический лидер — самый сильный специалист по технической части. С тим лидом все сложнее, как только должность тим лида не трактуют от компании к компании. Пожалуй, это одна из самых субъективных специальностей в IT. Предположим, приходит на собеседование разработчик, и его спрашивают: “Как вы считаете, чем занимается тим лид?”. А тим лид разработчика на предыдущей работе не только команду направлял и по тех части был классным специалистом, но еще и кофемашину успевал обслуживать, да за проджект менеджера роадмапы рисовать. У кого не спроси — у всех своя трактовка. Единственный здравый ответ, который можно дать на этот вопрос: “Покажите мне ваши должностные инструкции на тим лида и тех лида, и я скажу вам, в чем разница”.

8) Как объяснить разработчикам ценность сторипоинтов?

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

9) Как объяснить разработчикам ценность скрама?

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

  • Исключительное редкое присутствие директивного управления и только в критической ситуации. То есть все задачи планируются на спринт вперед, и в теории никто не может их поменять, на практике иногда случаются форс мажоры, но от этого никто не застрахован.
  • Коллективная ответственность, в scrum команде не получится переложить ответственность за качество продукта на отдельного участника.
  • Владелец продукта лишь приоритезирует задачи в беклоге, но не управляет задачами команды в классическом понимании этих слов. Команда в сотрудничестве с product owner сама решает, какие задачи возьмет в следующий спринт.

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

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

Если ценность скрама все еще не воспринята, то последним средством будет прочтение Scrum Guide. А, возможно, в вашей команде Scrum — плохое решение (Think about it).

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

P.S. Если у вас есть интересные вопросы pm’у, обязательно оставляйте их в комментариях!

Комментарии 14

    –1
    полезная инфа, спасибо
      0
      Waterfall — это четкое обозначение требований к будущему продукту, и отступление от них ломает процессы.

      Поэтому в Waterfall вводят управление требованиями и изменениями.
        +1

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

          0

          С такими ответами не пройти собеседование, если спрашивающий имеет точные "правильные" ответы.

            +5
            насколько важны ежедневные митинги

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


            И да… сертификат/значок PMI у меня где то валяется.

              0
              mmMike, да, вы правы. При проведении митингов нужно руководствоваться здравым смыслом, чтобы они не становились тратой времени. Но хочу отметить, что в статье речь идет о митингах в контексте scrum. Daily meetings в этом фреймворке незаменимый атрибут для саморегуляции направления работы в команде.
                0
                Daily meetings в этом фреймворке незаменимый атрибут для саморегуляции направления работы в команде.

                Позвольте не согласится.
                Что можно обсуждать/прослушать на общей каждодневной (!) встрече (толпа человек 10..20 например)? Выступление/расскачку 'scram' 'мастера'? В стиле "стартующие корабли бороздят просторы.."?


                Общие вопросы, которые требуют общего присутствия и обсуждения возникают не каждый день. Если возникли, то тогда и собираться нужно. А не по расписанию.


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


                Какой то карго культ с этим Scrum "процессом"… Противопоставление "старых" методик PMI и "новых" Agile… Бред.
                Все это лишь набор инструментов и чей то обобщенный опыт.
                С умом все нужно применять, без догматизма и фанатизма.

                  +1
                  На дейли не может собираться 10-20 человек, потому что команда в скраме — это 5-9 человек. И есть четкий план — кто что сделал вчера и собирается сделать сегодня. Какие при этом возникли сложности. Это нужно, чтобы все участники команды были в курсе что происходит. Не больше 3-5 минут на каждого. Если обсуждение какого-то вопроса затягивается, то оно выносится за рамки дейли митинга.
                  Вообще странно, что такие вещи стоит разъяснять. Вроде уже все компании в той или иной мере пришли к этому.
                +1
                Абсолютно согласен. Мы в чате команды пишем свои достижения за вчера — дело одной минуты, вместо часового переливания из пустого в порожнее.
                  +1

                  Какая хорошая идея! А всё потому, что когда Скрам писали, чатов не было.

                  0
                  у тебя срочная работа

                  ты должен присутствовать на болтовне которая как правило не дает НИЧЕГО

                  Это лишь значит, что про срочность вам наврали)

                  Менеджеры любят так делать — нагнетать сроки и дедлайны, чтобы разработчики были в тонусе (или в стрессе).
                    0

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

                  0

                  На каком-то треннинге слышал прекрасное объяснение стори-пойнтов.


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


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

                    0

                    А потом оказывается, что арбуз должен обладать совершенно другими свойствами и… "Аааа! Нам нужно менять методологию оценки задач!", и вообще "Кто посмел уточнить требования?"

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

                  Самое читаемое