Каверзы при собеседовании на project manager'а или прогулка по минному полю чудес
Безумие есть неспособность видеть швы, соединяющие бред и явь. Стивен Э. КингПроходя в конце года собеседования на должность проджект менеджера, я повстречал много вопросов, которые могут показаться последним бредом и от лица hr’ов, и от лица квалифицированных специалистов. Конечно, каждая компания чудит по-своему, но цель некоторых вопросов до сих пор остается для меня загадкой.
Проджект менеджер — это специалист, который всегда должен находиться в контексте. Невозможно понять бизнес цели и бекграунд их реализации без вопросов: зачем? почему? как? На собеседовании цель менеджера — дать четкий ответ на поставленный вопрос, войдя в его контекст. Поэтому я всегда стараюсь не обращать внимание на “дичь”, которая присутствует на собеседованиях, и рассуждать даже на самые, казалось бы, дурацкие вопросы.
Все менеджеры прекрасно понимают, что собеседование — это неспешная, часовая прогулка по минному полю. Это утверждение великолепно демонстрирует старая менеджерская байка: “В первой компании меня спросили, что я буду делать, если команда не успевает к релизу: попрошу команду об овертайме или сяду писать код сам? Я ответил, что сяду писать код сам, и мне отказали с мотивацией: “у нас так не принято”. Во второй компании мне задали тот же вопрос, и я ответил, что попрошу выйти команду в овертайм, и последовавший отказ от этой компании был мотивирован тем, что у них так не положено. В третьей компании я вновь столкнулся с этим злополучным вопросом, и ответом на него был вопрос — а как у вас принято?”
Поэтому специально для читателей Хабра я записал самые интересные по моему мнению вопросы и решил разобрать возможные ответы на них. Вопросы будут и бредовые, и здравые.
1) У вас есть скрам команда из разработчиков и тестировщиков. Разработчики работают, оценивая задачи в сторипоинтах, а тестировщики в часах. Тестировщику поставили задачу запрограммировать кнопку, но он не умеет пользоваться сторипоинтами. Как объяснить ему методологию оценки задачи, которую ему предстоит использовать?
Иногда скрам доходит до абсурда. В ответе на данный вопрос стоит отметить, что в скраме команды универсальные, но в другом понимании этого слова. Контекст в данном вопросе в целом не сильно важен. Вам просто нужно объяснить сотруднику, как считаются сторипоинты. Нужно взять его предыдущие задачи, выписать на листочки и предложить сравнить их со шкалой фибоначи, объяснив ему само понятие сторипоинта: объем работы * сложность * риски. После тестировщик сможет сравнить задачу по разработке кнопки с его прошлыми выполненными задачами по трудоемкости и, соответственно, со значением в сторипоинтах.
2) Что делать, если удаленный сотрудник потерял перфоманс?
Самый абстрактный вопрос, который можно задать. За комфортную работу удаленщика в первую очередь отвечает культура и ценности компании. Если в компании качественная коммуникация, к примеру, активные совместные обсуждения задач и проблем в удобном мессенджере позволяют удаленному сотруднику почувствовать свою ценность и вхождение в работу команды и компании, когда же коммуникация ограничивается одним письмом в день туда-обратно, человек не чувствует связи с коллегами. Также, когда задачи просто улетают в мастер и релизятся на прод без фидбека и отметок об успехах каждого отдельного работника в течение месяцев, сотрудник начинает чувствовать себя изолированным от команды, он вкладывает в свою работу силы и эмоции, а в ответ их не получает, в связи с этим начинается эмоциональное выгорание даже без переусердствования в работе. Поэтому нужно поднять вопрос не почему сотрудник плохой, а что гасит его мотивацию к работе над его задачами, а затем их решать.
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 менеджера с других проекта (сотрудник работает над несколькими проектами одновременно), и два или три его руководителя поставили ему единовременно срочные задачи, к какой он должен приступить?
Вопрос из разряда математической задачи: “Вася купил 1000 бананов…”. А зачем?
При подобных иерархиях в компании разногласия между менеджерской составляющей неизбежны, разработчик не должен потакать таким ситуациям и влезать в самостоятельные разборки между 10-ю управленцами, чья задача приоритетнее, для этого есть менеджер его команды или непосредственный руководитель.
7) Разница между тим лидом и тех лидом в команде?
Очевидно, технический лидер — самый сильный специалист по технической части. С тим лидом все сложнее, как только должность тим лида не трактуют от компании к компании. Пожалуй, это одна из самых субъективных специальностей в IT. Предположим, приходит на собеседование разработчик, и его спрашивают: “Как вы считаете, чем занимается тим лид?”. А тим лид разработчика на предыдущей работе не только команду направлял и по тех части был классным специалистом, но еще и кофемашину успевал обслуживать, да за проджект менеджера роадмапы рисовать. У кого не спроси — у всех своя трактовка. Единственный здравый ответ, который можно дать на этот вопрос: “Покажите мне ваши должностные инструкции на тим лида и тех лида, и я скажу вам, в чем разница”.
8) Как объяснить разработчикам ценность сторипоинтов?
Кто бы что ни говорил, но для разработчиков главными ценностями сторипоинтов являются легкость подсчетов и вложение рисков в эту оценку, в отличие от часовой оценки. При оценке сторипоинтами разработчику не приходится брать на себя обязательства выполнить задачу, предположим, за 2 часа, чтобы его сразу по истечении времени начали дергать с требованием результата. Вложенное в оценку время на решение проблем, которые, возможно, возникнут, позволяет работать в комфортном режиме без лишнего стресса и постоянных приходов менеджера с требованием сдать задачу.
9) Как объяснить разработчикам ценность скрама?
Я как бывший разработчик могу написать целую оду Agile подходу, в том числе фреймворку SCRUM, за то, что жизнь участников команд становиться много проще, возьмем несколько пунктов:
- Исключительное редкое присутствие директивного управления и только в критической ситуации. То есть все задачи планируются на спринт вперед, и в теории никто не может их поменять, на практике иногда случаются форс мажоры, но от этого никто не застрахован.
- Коллективная ответственность, в scrum команде не получится переложить ответственность за качество продукта на отдельного участника.
- Владелец продукта лишь приоритезирует задачи в беклоге, но не управляет задачами команды в классическом понимании этих слов. Команда в сотрудничестве с product owner сама решает, какие задачи возьмет в следующий спринт.
Пунктов о ценности скрам можно написать много, если основные пункты не убедили разработчика из вашей команды, то можно прибегнуть к мнению о данном подходе других коллег, к примеру, так ответил на этот вопрос один из моих бывших коллег:
“В scrum-командах процессы отлажены. У тебя есть план на спринт и, как правило, не бывает срочных директивных пушей вида: “бросай все, прилетели новые срочные задачи”. Команда следит за сроками и разработка становится предсказуемой, можно планировать. За счет этого у текущих задач в спринте мало блокировок. Я как разработчик, хочу, чтобы когда я возьмусь за свою задачу, все для нее было готово: и бек, и дизайн нарисован. Не надо бегать и трясти других.”
Если ценность скрама все еще не воспринята, то последним средством будет прочтение Scrum Guide. А, возможно, в вашей команде Scrum — плохое решение (Think about it).
Подводя итоги, хочу дать рекомендацию менеджерам всех специальности о поведении при прохождении собеседования — воспринимайте любую “дичь”, как новый кейс для разбора, ведь “дичь” часто появляется не только в вопросах, но и в жизни, и тогда со временем для вас будет актуальна фраза: “Кто pm-ом работал — тот в цирке не смеется”.
P.S. Если у вас есть интересные вопросы pm’у, обязательно оставляйте их в комментариях!