
Homo Sapiens non urinat in ventum
Обычно блок софт-скиллз входит в техническое собеседование, но в ходе последнего поиска работы, мне предложили прям выделенное, часовое собеседование по софтовым навыкам в продуктовую компанию Ciliz, они занимаются то ли игрой, то ли дейтинговым приложением «Целуй и знакомься».
Буду честен, я не прошёл это собеседование, не получил работу. Эйчарыня сказала, что считает, что с культурной точки зрения, я в команду не впишусь. На самом деле, к сорока годам учишься «вписываться» куда угодно. К этому возрасту мужчина приобретает способность договариваться с техническими чувачками про функторы, с госами и корпоратами про бюджеты и тендеры, с чоткими пацанчиками за тёрки и с ментами за юрисдикцию.
Оставим этот отказ на совести эйчаров и попробуем извлечь из истории пользу: сформировать список вопросов с софтового интервью и попробовать разобрать, какие качества они проверяют.
В чём вы видите зону ответственности прожект-менеджера?
Если кратко, то пиэм — это человек, которому больше всех надо.
С точки зрения зоны ответственности, есть три уровня: операционный, функциональный, стратегический.
В операционном менеджменте пиэм вручную управляет сотрудниками небольшой команды.
Пиэм планирует работу команды.
Пиэм принимает результаты работы команды и даёт участникам обратную связь.
Пиэм разруливает все сложные и непонятные ситуации в команде. Например, когда зоны ответственности сотрудников были нечётко определены и ребята не разобрались, кто какую задачу должен делать.
Особенно важно для пиэма уметь решать технически-организационные проблемы, которые лежат на стыке компетенций тимлида и, собственно, пиэма. Часто тимлид такую задачу решить неспособен.
Пиэм должен уметь снимать метрики с работы команды, чтобы отчитываться перед руководством не только словами, но и называть конкретные цифры. Высший пилотаж, конечно — метод освоенного объёма. Но на практике я не встречал команд, в которых бы им реально пользовались. Также пиэм составляет вручную отчёты по требованию руководителя проектного офиса.
Пиэм принимает активное участие в найме людей в команду. Аналитиков и подчинённых пиэмов он собеседует и нанимает сам, а также участвует в собеседованиях технических специалистов и имеет по ним совещательный голос (конечное решение о найме тех. специалиста принимает тимлид).
Пиэм проводит ретроспективы и пишет постмортемы. Прочтите о них отдельные статьи.
Пиэм проводит пресейлы.
Пиэм выстраивает отношения со стейкхолдерами компании.
Пиэм несёт ответственность за бюджет проекта.
Пиэм занимается пипл менеджментом, обеспечивая в команде приемлемый уровень текучки. Самая частая реальная причина ухода людей — начальник чудак.
Какой результат работы пиэма? За что его можно спросить?
Когда я был моложе, говорил, что за попадание проекта в треугольник. Сейчас говорю, что за удовлетворённость внешнего и внутреннего заказчиков.
Проект может провалиться по всем параметрам треугольника, но заказчик будет доволен и это будет успешным результатом. И наоборот, можно попасть во все плановые значения по срокам, деньгам и содержанию и совершенно испортить отношения с заказчиком, после чего он вам больше ничего не закажет.
С какими сложностями руководитель проекта обычно сталкивается в своей работе?
Может быть сложный заказчик, который не имеет чёткого представления о том, как должен выглядеть итоговый продукт. Пиэм для такого заказчика последовательно убирает неопределённость.
Могут быть сложности с командой. В ней могут оказаться люди, которые не умеют делать что-то нужное или не хотят это делать.
Сотрудник может посреди проекта попросить поднять ему зарплату, это в современных командах тоже считается в порядке вещей. Надо уметь подсчитать, не расползётся ли от этого подъёма экономика проекта и принять осознанное решение, есть ли смысл поднимать зарплату этому сотруднику или пусть лучше уволится.
Непредсказуемое затягивание сроков из-за объективных технических проблем. Проекты с легаси-кодом, в котором программист правит один кусок, у него расползается другой.
Недостаточно хорошая работа QA. Вроде, всё протестировали, но на проде вылезают баги, которые приходится спешно править.
По каким критериям вы определяете, что успешно справляетесь со своей ролью?
Заказчики удовлетворены.
Экономика проекта складывается, компания на нём зарабатывает.
Текучка приемлемая. Команде комфортно работать с пиэмом.
И самый крутой критерий. Пиэм может уйти в отпуск на две недели и работа команды при этом не разваливается. В некоторых компаниях пиэмы прям увлекаются микроменеджментом, контролируя в команде каждую мелочь и давая низкоуровневые распоряжения. Из-за этого без пиэма всё тут же начинает разваливаться. В целом, чем выше квалификация пиэма, тем выше автономность команды.
Как измерить успешность критериев работы пиэма, перечисленных в предыдущем пункте?
С финансами и экономикой проекта всё более-менее определённо, есть методология P&L. Если ключевые метрики в пределах допустимого, работа с бюджетом ведётся грамотно.
Заказчик или стейкхолдеры обычно сами сообщают руководству проектного офиса, комфортно или некомфортно работать им с данным пиэмом. Если они более-менее адекватные, они расскажут, что конкретно им не нравится.
Если члены команды работают хотя бы по 1,5-2 года, это уже означает, что работа с командой тоже ведётся успешно.
Качество продукта определяется формальными метриками, вроде количества багов на релиз. Продублирую ещё раз формальные проектные метрики:
- Deployment Frequency — частота поставки;
- Lead Time for Changes — время от коммита до релиза;
- Change Failure Rate — количество багов на релиз;
- Time to Restore Service — время на фикс бага в проде.
Можете рассказать о ещё каких-нибудь практиках работы с командой, отслеживания её состояния и проч?
Мы можем измерять velocity команды, её производительность. Она может колебаться в определённых пределах, но в целом, должна оставаться ровной. Если она падает, что-то не так.
Хорошая штука — one-to-one собраться с каждым членом команды хотя бы раз в пару месяцев и обсудить его состояние.
Можно проводить анонимные опросы и анкетирования, «Оценка 360». Но это спорная практика, можно получить, как в «Девелонике», войну всех со всеми.
Хорошая штука — групповая ретроспектива. Но она эффективна, только если пиэм прям записывает пожелания и претворяет их в жизнь, иначе метод работать не будет, люди потеряют мотивацию делиться проблемами.
Индивидуальные треки развития. Люди, как правило, хотят развиваться и им в этом можно и нужно помогать. При этом не стоит трогать и принудительно тащить людей, которые развиваться не хотят.
Принимает ли пиэм участие в увольнении сотрудников?
Да, он принимает конечное решение об увольнении участника из команды. При этом я не придерживаюсь правила: «Если вы только задумались, не уволить ли этого человека, его надо уволить». Мне больше по душе подход, утащенный у Алёны Владимирской.
Мы выписываем на одну часть листа всё хорошее, что сделал человек за последнее время, на другую часть листа — всё плохое. Выставляем веса и сопоставляем. Если плохого где-то в два раза больше хорошего, надо прощаться. Если меньше, с сотрудником ещё можно поработать и попробовать его вытащить.
Безусловно, бывают поступки, которые прощать не следует. Вроде слива клиентской базы конкурентам или организации распильно-откатной схемы.
Откуда формируется скоуп лично ваших рабочих задач?
Сильно зависит, на каком этапе я нахожусь в компании. На испытательном один подход к получению задач, в штате, в процессе перестройки работы команды другой, в штате после перестройки команды — третий.
Я принимаю непосредственное участие в формировании планов на итерацию. Вместе с продактом (определяет приоритеты) и тимлидом, мы планируем, какие таски будем брать в работу, кто именно ими будет заниматься.
Пока идёт разработка, я вместе с аналитиками прорабатываю и рецензирую требования к следующей итерации.
Если возникает конфликт или прилетает что-то от смежников, разруливаю.
Принимаю участие в приёмочном тестировании, могу что-то потестить.
Принимаю участие или провожу демо.
Провожу ретроспективу.
И вся эта операционка работает в цикле. Но есть ещё много всяких мелочей.
Изрядная часть задач исходит от самого пиэма, остальное прилетает. Соотношение может меняться в зависимости от компании.
Было ли такое, что вы замечали, что в одном из направлений что-то идёт не так и это поправили? Конкретный кейс, если можно.
Да. Например, в «Систехе» мы плотно работали с «Крафтом» и взаимодействие наше шло на условиях T&M. Проблемы возникали, когда фактические трудозатраты превышали плановые больше, чем на 30 процентов. И эта ситуация возникала часто.
В итоге мы внедрили в работу всякие весёлые формулы и поправочные коэффициенты, оценки стали точнее, но выше. Крафт стал меньше заказывать, но количество конфликтов и неоплаченных работ сильно снизилось.
Кейс. В вашей команде появилась роль SMM-специалиста. И на ретро вылез такой фидбек, что SMM-щик говорит, что команда арта работает медленно. Арт-директор же говорит, что SMM отвлекает его специалистов очень сильно от работы.
Возможно, арт-директор не до конца понимает важность SMM. Ему эту важность надо объяснить. Нужна встреча на троих, на которой SMM расскажет арту, какие у него планы по повышению прибылей компании, какие действия он собирается предпринять по ним, что он, в целом, делает и чем занимается.
Детально погрузиться в проблему и тщательно разобраться в деталях и особенностях конфликта. Понять, что за креативы просит делать SMM, насколько это адекватно, насколько они сложные и трудоёмкие. Порасспрашивать сотрудников арт-команды, комфортно ли им работать с SMM. Может, они друг друга плохо понимают.
Сформировать по итогам планы по исправлению ситуации.
Кейс. Фича, крайне важная для развития продукта, застряла в арт-отделе, её блокирует арт-директор. Говорит, что ему некогда взяться за неё из-за текучки.
Когда люди говорят, что им не хватает времени на что-то, им на самом деле, не хватает не времени, а приоритета. Может быть, арт-директор считает задачу неприоритетной.
Можно объяснить важность задачи, объяснить, как она повлияет на компанию и намекнуть, что может быть, неплохо было бы понять, что главный инструмент арт-директора не рисовальная программа, а дизайнер. И пора бы научиться делегированию кому-то наиболее адекватному.
Добиться того, чтобы он делегировал и курировал. Тоже есть вероятность, что она продолжит застревать, но если оставить её на арт-директора, она застрянет гарантированно.
Как в идеальной картине мира должны строиться взаимоотношения между лидами и прожектом?
Безусловно, партнёрские. Мы должны друг друга дополнять и дополнять. Отношения относительно равных партнёров. Каждый разбирается в своей части предметной области и должен это знание использовать.
Но если мы не можем договориться, решение принимаю я и ответственность за это решение тоже на мне. Это не скипетр, а скорее, тяжёлая ноша.
Был ли у вас опыт выстраивания процесса оценки и планирования в команде?
Да, был. Я считаю максимально адекватной сочетание первичной и точной оценки. Сначала мы оцениваем верхнеуровнево, определяем порядок цифр и ИСР-ку на уровне ключевых эпиков, верхнеуровневый вариант реализации. Если заказчика первичная оценка устраивает, непосредственно перед реализацией делаем проработку требований и точную оценку. Не забываем накидывать риски и всякие коэффициенты.
У меня есть статья о всех способах оценить проект.
Обязательно делаем план-фактный анализ, сколько планировали потратить на задачу, сколько потратили по факту.
Кто распределяет непосредственно задачи между разрабами?
Есть разные подходы, мне приходилось как раскидывать их самому, тимлид этот план только подтверждал, в других же компаниях, я отдавал тимлиду план итерации и он самостоятельно всё пилил на сабтаски и раздавал разрабам. Зависит от, короче.
Кейс. Команда работает по скраму, вы пилите итерацию, продакт или стейкхолдер пришёл со срочной задачей, требует добавить её в итерацию.
Мы обмениваем гарантию поставки на невмешательство в состав спринта в течение двух недель, это не так сложно обеспечить. Но да, руководство будет время от времени пытаться эту договорённость нарушить.
Действуем очень просто — предлагаем продакту извлечь из спринта задачу, аналогичного объёма в обмен на срочную.
Бонус
Вот вам ещё критерии хорошего менеджера от Google:
- Мой менеджер дает мне действенную обратную связь, которая помогает мне улучшить мои результаты.
- Мой менеджер не занимается микроменеджментом (не углубляется в детали, которые должны решаться на других уровнях).
- Мой менеджер проявляет ко мне внимание как к личности.
- Действия моего менеджера показывают, что он/она ценит мою точку зрения в команде, даже если она отличается от его/ее собственной.
- Мой менеджер держит команду сосредоточенной на наших приоритетных результатах/задачах.
- Мой менеджер регулярно делится со мной важной информацией от своего руководителя и старших руководителей.
- За последние шесть месяцев мой менеджер провел со мной содержательную беседу о карьерном развитии.
- Мой менеджер четко формулирует цели для нашей команды.
- Мой менеджер обладает техническими знаниями (например, программирование, продажи, бухгалтерский учет), необходимыми для эффективного управления мной.
- Я бы порекомендовал моего менеджера другим сотрудникам Google.
- Я доволен работой моего менеджера как руководителя.