СКОЛЬКО МЯСА В КОЛБАСЕ, СКОЛЬКО РАБОЧЕГО ВРЕМЕНИ В РАБОЧЕМ ДНЕ?

Немного запоздалый ответ на очень интересный вопрос. Автор пожелал остаться анонимным.

Вопрос:
Живем командами по Scrum. Оцениваем задачи в "чистых" часах, следовательно капасити = количество рабочих дней * количество чистых часов в дне. (чистые часы - часы, которые конкретно работаешь не отвлекаясь: берем рабочий день, минусуем среднее время на перекуры, консультации и прочие не планируемые вещи).

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

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

Ответ:
По сути, вы пытаетесь переизобрести сторипоинты 🙂 Изначальная их идея была как раз в этом: отвязаться от фактических человеко-часов в пользу некоторой нормы выработки. Ваших “чистых часов”.

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

Если команды работают сообща, например в реализации любого Scaled Agile Framework, то общее понимание размера сторипоинта нужно. Но там и скоуп общий, как раз. Если команды работают изолированно – большого смысла в этом нет, все равно будут расплываться.

Я бы считал объем “чистых часов” по факту. Сколько времени за спринт команда списала на проектные задачи? Сколько на коммуникации и ритуалы? Сколько на какие-то вообще внепроектные активности, аля встреча с HR, собеседование новичка, собрание с директором и т п? Вот исходя из статистики полезной утилизации за определенный период можно выделить эту норму. Не наугад, а на основании фактических данных.

Для Scrum нормой считается порядка 80% полезной утилизации. Т е это порядка 6,5 часов в день. Вот вам и бенчмарк. Если у команды выходит 5 часов в день, значит она занимается фигней минимум 1,5 часа каждый день 🙂 Повод задуматься и проанализировать их утилизацию подробнее.

Но можно добиться и лучших показателей. Идеалом для консалтинговой компании будет порядка 85-90% утилизации. Мы у себя достигали 92%. Смотрите, на что тратится время сотрудников, насколько это необходимо для проектов, можно ли что-то оптимизировать. И получите свой ориентир “чистого часа”.

Надеюсь, получилось ответить на вопрос.

У кого какие идеи по теме – добавляйте!

МЕНЕДЖЕР ПРОЕКТА БЕЗ ТЕХНИЧЕСКОГО ОПЫТА

Карьерный вопрос от Михаила @dulitman

Вопрос:
В данный момент тружусь Инженером ПТО в строительной компании специализирующейся на автомобильных дорогах. Имею техническое образование по специальности + второе управленческое. Морально подошёл к смене сферы деятельности, поэтому в ближайшее время планирую пройти курсы на проджект-менеджера в IT. Но это всё вступление, а теперь вопрос.
"Слышал что в проджект-менеджеры переходят из тестировщиков или аналитиков. Насколько сложно будет стать проджектом без технического опыта в IT?"

Ответ:
Менеджер проектов в IT – штука крайне интересная. И, почему-то, эта роль часто отличается от классического руководителя проекта. Определенно, есть некоторая специфика по части используемых подходов (всякие Agile-ы, Scrum-ы и т п). И гораздо больший фокус на координаторских задачах, нежели менеджерских. Итого, ПМ в IT – координатор, владеющий специфическим инструментарием. Не везде, но часто.

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

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

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

А теперь главное НО. Уровень погружения в ПМа в технику - это не rocket science. Вот совсем нет. Базовый уровень технической грамотности, некоторые нюансы конкретного проекта. Код тут писать не надо. Даже читать не надо. Надо понимать, что инженеры говорят. Все это прокачивается. Нужно время и много-много желания для этого. Но все достижимо. И таких примеров у меня, повторюсь, перед глазами было много.

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

Мир IT большой, компаний и проектов много. Выбирайте на старте что-то попроще (вплоть до сайтов на движках, например), выделяйте силы и время на саморазвитие, и двигайтесь плавно к более сложным проектам и более сложным позициям ПМ. И все получится!

Надеюсь, получилось ответить на вопрос.

ВОПРОС В ЗАЛ

Друзья, привет!

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

А вопрос следующий:
Как воспитывать в сотрудниках ответственность?

Порой это прям массовая проблема, на всю компанию. Ну не сделал фичу вовремя, и ладно. Ну не закрыли в спринт все, что планировали, и ладно, передвинем в следующий. Ну не отгрузили поставку заказчику и он теперь бабки теряет, и ладно. И т д и т п, на разных уровнях. Хорошо, если хоть ТОПы бегают. А то, бывает, вообще один СЕО разгребает.

Тут нужна трансформация прямо в культурном коде уже. И вот как это делать?

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

ПРО ТОКСИЧНОСТЬ

Друзья, а что вы думаете про токсичность? Плохо это? Или хорошо?

Как по мне, токсичность в команде, это как лампочка “Check Engine” в машине. Да, неприятно, когда она горит. Бесит прямо даже. Но пусть лучше загорается вовремя, пока я еще могу ехать. И если долго ее игнорировать, то двигателю хана. И с командой точно также.

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

Поэтому крайне важно докопаться до сути. Лечить симптомы – не очень эффективно. Да и как их лечить то? Отругать? Премии лишить? Уволить? Как-то нет хороших методов в арсенале.

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

Допустим, узнали мы, что дело не в работе. Совсем. Кризис у человека, личностный, возрастной, не важно. Может случилось чего в жизни, образ справедливости порушился. Вот он и пытается как-то себя найти в пучине негативных эмоций, и выражается это все в чрезмерную критику, всего и вся. Как быть? В таких кейсах я старался разговаривать, как взрослый со взрослым. Показать, как его поведение влияет на работу и команду, спросить, готов ли он что-то с этим сделать. Чаще всего, договориться получалось. Либо человек говорит по-взрослому, что ничего менять не может, и тогда обсуждаем оффбординг.

Может быть, что это межличностная токсичность. Не любит конкретный Петя конкретного Васю. Причем взаимно. Хуже, когда Вася – это вы, а Петя – ваш сотрудник. Но и здесь рецепт примерно такой же. Обсудить, объяснить по-взрослому, что так работать не пойдет, и либо учимся конструктиву, либо кому-то придется компанию покинуть. Здесь в загашнике может быть классный вариант с ротацией – сменить одному из них команду или проект, минимизировать негативные отношения. Если с причиной не ошиблись, то все исправится. Есть прям целый парад таких кейсов в опыте.

Ну и, наконец, часто под токсичностью маскируются проблемы команды и процессов в ней. Об этом великолепно описал Ленсиони в своих “5 пороках команд”. Рекомендую. Путь решений также можно выстроить по Ленсиони – идем по пирамиде снизу вверх, закрываем порок за пороком. И так, пока не искореним эту самую токсичность.

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

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

Вот такая штука, эта токсичность. Не надо ее бояться, нужно смотреть на “лампочку” и определять “код ошибки”, а потом чинить свой “двигатель”.

А как вы работаете с токсичными кейсами?

БИГ-БОССЫ И ИХ РАДАРЫ

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

Вопрос:
Подходит к концу испытательный срок. Отношения с руководителем получилось выстроить, все ок. Каких-то взаимодействий с начальником +1 уровня не было, и пока не предвидится.

Для того чтобы развиваться дальше по карьере в этой компании, очевидно, нужно как-то начать работать с +1, +2 и выше, чтобы попасть к ним на радары, как-то зарекомендовать себя. Как сделать это экологично?

Ответ:
Поскольку инициативы от самого руководителя уровня +1 не поступает, ждать ее и не следует. Надо брать все в свои руки 🙂

Можно решать задачу в лоб – попросить тет-а-тет с +1 руководителем, обсудить с ним свои желания, договориться о совместной работе и о каких-то задачах. Будет ли это хорошо? Скорее всего, нет. Потому как ваш непосредственный руководитель может отреагировать не совсем благосклонно, оценить это, как прыжок через голову. Итого можно благими намерениями испортить себе важные рабочие отношения. Может быть, даже самые важные. На текущем этапе.

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

Важно! Непосредственный руководитель может отреагировать иначе. Почувствовать угрозу. Закрыться. И тогда ничего у вас не выйдет. Совсем. Но тогда стоит и осознать, что роста в компании у вас не будет, во всяком случае, при этом начальнике. И тогда надо ли оно вам вообще тут надолго задерживаться? Почитайте по этому поводу Литвака, очень круто расписывает эту тему.

Если ваш руководитель, скорее, карьерист (по Литваку), то он охотно включится в эту игру. Вы получите план развития, цели и задачи. А во имя их воплощения будете получать что-то от начальника, что-нибудь он вам обязательно будет делегировать из своего, чтобы научиться. И такие вот задачи – как раз то, что вам нужно. Он же свое отдает. А он взаимодействует уже в других кругах, с этими самыми +1, +2, +N уровнями. И будет у вас классная и легитимная возможность поработать с ними, показать себя, на других посмотреть. Ну и на радары нужные попасть, чтобы расти и дальше по карьере.

P.S.
Если вам тоже нужна консультация или менторинг, пишите мне в личку @ilya_prakht и мы договоримся!

А если хотите получить бесплатную консультацию, то задавайте свой вопрос в форму

ПРО ОТВЕТСТВЕННОСТЬ

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

А теперь, как и обещал, поделюсь своей историей и своими мыслями.

Говоря об ответственности, о безответственных сотрудниках, о необходимости передачи ответственности, все время вспоминаются классические 4 причины. И не зря. Реально, инструмент сюда подходит, как нельзя прекрасно.

Человек делает что-то не так или не делает что-то (в нашем случае не берет на себя нужную нам ответственность) по 4 потенциальным причинам:
1. Не понимает
2. Не умеет
3. Не может
4. Не хочет

Давайте теперь разберемся с каждым пунктом подробнее.

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

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

Отсюда решение по пункту Не понимает – объяснять, проговаривать, четко обрисовывать свои ожидания от сотрудников. Вы про это точно писали.

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

А еще бывает, что руководитель сам, как мама-утка, все за своими сотрудниками прибирает и всю ответственность на себя сгребает. Случилась проблема – схватился и сам все решил. Делегировать надо. И обезьянок на спину возвращать. Условно, накосячил – исправляй, сам.

Отсюда решение по пункту Не умеет – делегировать ответственность, показывать своим личным примером, как надо, спрашивать за результаты. Про это тоже писали, довольно много.

Пост получился длинный, поэтому разбил на два. Продолжение следует.

ПРО ОТВЕТСТВЕННОСТЬ #2

Продолжение.

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

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

Отсюда решение по пункту Не может – давать ресурсы, расставлять правильные приоритеты, давать возможность для этой ответственности. Было и про это в ваших комментариях.

Не хочет. Ну и в завершении, для полноты картины. Был в комментариях логичный вопрос – “а почему должен?” И действительно. Что мы такого сделали для сотрудника, чтоб он взваливал на себя больше, чем было. Или чем ему комфортно. Тут уж зависит от ситуации. Понятие ответственности идет под руку с понятием мотивации. Есть мотивация – будет и ответственность. А если нет одного, то не будет и другого.

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

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

Итого получается следующий рецепт: понятные ожидания + полноценное делегирование и личный пример + ресурсы и приоритеты + правильная мотивация. Где-то нужен один пункт, где-то парочка, а где-то сразу все. Используйте, как чеклист.

Друзья!

Возвращаюсь после длительного перерыва. И эта неделя обещает быть богатой на контент 🙂

Начнем с анонса. В эту среду, 24 апреля, в 15.00 мск проведем эфир вместе с Сашей Орловым, где поговорим о роли Руководителя Отдела (менеджера менеджеров), его компетенциях, полезных инструментах. И покажем курс Стратоплана, который таких РО готовит.

Мероприятие бесплатное. Регистрируйтесь и приходите!

Сделали на канале "ВТБ для бизнеса" небольшую шпаргалку про DISC, особенности разных психотипов, подходы к контролю и управлению.
Полезное

УПРАВЛЕНИЕ РИСКАМИ В КОМПАНИИ

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

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

Во-первых, есть специальные стандарты. Их очень много. Есть общие и универсальные. Есть локальные. Есть специфические для отрасли, например, целая куча стандартов есть в банкинге. Наиболее интересные и популярные:

- ISO 31000
- FERMA
- COSO
- …

И вот реализуя какой-то из стандартов, мы делаем риск-менеджмент в компании качественным, унифицированным, получаем кучу преимуществ, помимо внутреннего порядка, например, инвестиционная привлекательность.

Во-вторых, есть совершенно классная модель “3 линий защиты”. Как понятно из названия, мы делаем 3 уровня работы с рисками:

1. Уровень функций – реализуется в каждом подразделении, выполняется мониторинг, контроль и реагирование на риски. Например, тимлид следит за исполнением требований ИБ своими сотрудниками.

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

3. Уровень внутреннего аудита – какой-то орган, чаще всего комитет, реже – прям выделенное подразделение, которое оценивает общее качество риск-менеджмента в компании, постоянно адаптирует процессы под стратегию компании. Например, изменение политик ИБ, если появились изменения ФСТЭК.

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

1. Люди или команды, которые выполняют работу согласно процессу

2. Специальные роли, определяющие, как именно работать в рамках процесса, и контролирующие это

3. Дополнительный механизм пересмотра работы процесса и его согласованности с текущей реальностью

Вспоминаю, как мы внедряли Scrum. Тимлиды на местах и команды реализовывали фреймворк. Delivery Manager-ы определяли, как адаптировать Scrum к проекту, как его внедрять и как мониторить потом. Ну а топ-менеджмент давал добро или недобро на всякие изменения, когда того требовали новые цели компании или конкретный проект не мог раскатать тот процесс, который был нужен нам. Эдакие “3 линии внедрения Scrum”. Интересно 🙂

Вот такие мысли. И такие инструменты. Надеюсь, будет полезно.

Видео вчерашнего Openday Стратоплана "Руководитель отдела: Смена декораций в управлении людьми"

https://youtu.be/aONzCVfgxGo

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

Посмотрите, вдруг и вам что-то будет полезно.

Что внутри?
✅ авторские экспертные каналы
✅ личный опыт, инсайты и кейсы
✅ свежие идеи и лайфхаки
✅ море пользы и вдохновения

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

И еще один анонс!

Уже завтра, 26 апреля, в 20.00 мск проведу открытый урок курса Delivery Manager в OTUS "Слон на нитке – реально ли управлять тимлидами и как это делать?".

Поговорим об инструментах управления тимлидами и роли DM во всем этом.

Присоединяйтесь

КАК ПОДРУЖИТЬ DISCOVERY И DELIVERY

Конфликт интересов Discovery и Delivery – тема классическая и распространенная. Круче и чаще только конфликт “Продажи vs Производство”. Почему так?

Оба эти этапа, и Discovery, и Delivery, находятся последовательно в одной цепочке производства ценности. И, стало быть, очень сильно зависят друг от друга.

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

Есть еще распространенная фишка, поставить каждому из них свой KPI на Lead Time. И тогда Discovery, лишь бы сделать что-нибудь, отдает побыстрее сырой материал в разработку, а Delivery, понимая все риски для своего Lead Time, долго и нудно не принимает требования и постоянно возвращает обратно в Discovery. Вот так и живем.

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

Как быть? Как по мне, нужно сделать 2 вещи:

1. Формализовать процесс передачи продукта из Discovery в Delivery. Какие-то чеклисты, четкие Definition of Done и т д. Чтобы однозначно было понятно, как должна выглядеть документация и проработка требований, чтобы разработка могла начать ими заниматься

2. Добавить командам какой-то общей мотивации. Внедрить общий KPI. Например, пусть вместе гонятся за единым T2M (Time To Market). Тогда не до ругачек на стыке, иначе премия у всех погорит. При этом, их собственные KPI на Lead Time тоже можно оставить, но мотивацию на них сделать ниже, чем на общий результат. Например, делить премию 30/70 за свои/общие KPI

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

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

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

Что скажете? Согласны с такой идеей? Какие еще есть варианты?