​​🧨 Как избежать конфликт с эмоциональным заказчиком

Началась встреча с заказчиком, обсуждаем статус проекта. На встрече присутствуют менеджер проекта, продукта, технический руководитель и другие заинтересованные товарищи из бизнеса.
Предварительно заказчик посмотрел отчет за неделю. В отчете указано, что фичу Z не сделаем вовремя, нужно еще 2 недели - легаси дало о себе знать. Встреча сразу начинается с конфликта. Заказчика бомбит - какого хрена не успеваем? У нас тут вроде все умные, менеджеров много. Как так мы ошиблись? Нафига мы планируемся тогда?

И вроде бы ответ очевидный, как говорится в переговорных книжках:
📖 "Да, мы накосячили, произошло это потому что (вставить нужное). Мы сейчас думаем как сделать так, чтобы остальные планы не подвигались. Расскажем послезавтра."
📖 А если с эмоциями не совладать, закончить встречу, используя ту же фразу.

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

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

🤺 1. Будьте первым, кто "нанесет удар".
Обозначьте в повестке - "План продукта Z, изменения, расскажет ПМ". Так, вы первым выскажитесь о проблеме и дадите участникам новый контекст. Пока вы не дали контекст, в голове заказчика нет картинки. Он просто думает, что все плохо.

🤺 2. Следите за формулировками.
Если вы рассылаете участникам план встречи заранее - не пишите "Сдвиг сроков в продукте Z". Это кого угодно заставит волноваться и нервничать. Найдите формулировки, понятные заказчику.

❌ Нет: "Задача X - не сделали, переносится на следующий спринт."

✔️Да: "Задача X - перенесли на следующий спринт, т.к. появился влет - Задача Y."

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

З.ы.: кстати как вам картиночки?

​​🛣 Полугодовое планирование - это масштабная компания по сбору портфеля проектов на следующие полгода.

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

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

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

💭А еще финальная сборка плана по всему холдингу может выглядеть так, будто много проджектов стекаются со всех деревень, чтобы отдать дань - инициативы, которые они проработали и оценили, своему лендлорду (PMO) со словами "я сделаль".

​​🤯 Ошибки при планировании сроков

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

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

👉 В работе над ошибками планирования, стоит обратить внимание на то КАК мы считаем время разработчика и размазываем это время по календарю.

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

Что необходимо заложить?
Вот список того, из чего может состоять спринт, на примере 1-го разработчика.

Не производственные затраты:

👩‍💻Scrum: daily standup, планирование, демо, ретро, грумминг/backlog refinement - 5 часов.
👩‍💻Тет-а-тет встречи с руководителем - 1 час.
👩‍💻Код ревью - 2 часа.
👩‍💻Непредвиденные встречи, общение, фокус-фактор - 3 часа.

Производственные затраты:

👨‍💻Баги - 2 часа.
👨‍💻Решение обращений пользователей в техподдержку - 1 час.
👨‍💻Техдолг - 2 часа.
👨‍💻Продуктовые задачи - 16 часов.
👨‍💻Мелкие хотелки (замените логотип, сделайте выгрузку, добавьте ссылку) - 2 часа.
👨‍💻Технические проекты (вещи, которые не нужны пользователю, но нужны разработке, чтобы проект комфортно жил - настройка мониторинга, масштабируемость) - 4 часа.

👩‍💻Бонус: Непопадание в оценки. У нас есть метрика, которая показывает насколько мы попадаем в оценки, из нее вытекает погрешность для планирования, у каждой команды она своя - 3 часа.

👉 Определите, какие пункты для вас актуальны и впишите свои данные в гугл табличке, чтобы лучше понимать capacity своей команды для верхнеуровнего планирования.

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

#разработка

​​Настало время раскрыть карты и рассказать немного про конфу. 🤗

27 февраля состоится бесплатная онлайн конференция KZ BI Conf, в честь дня рождения KZ BI community.

Будет два потока - аналитика и менеджмент. Спикеры встречи – профи из таких компаний как: Facebook, Microsoft, Яндекс Go, Avito и многие другие.
Я тоже буду вещать - про риски, и как ими управлять.

Конференция пройдет в субботу 27 февраля с 10:30 утра по времени Алматы (7:30 МСК). Регистрируйтесь, вступайте в новые сообщества, увидимся в через пару недель. 😉

Продолжаю делиться чудесами нетворкинга в телеграмме. Сегодня хочу вас познакомить с каналом Марьяны Онысько - Продукты, книги и любовь. Марьяна занималась развитием продуктов в МИФе 🤩 и сейчас продюсирует школу ченджеров. Это когда вас учат быть инноватором по модели Gartner - Change and Run, подробнее почитать можно тут.

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

📚 Хватит проверять чаты каждые 5 минут
📚 Если что-то хочешь изменить в команде - поменяй это в себе
📚 Как мы додумываем и накручиваем себя
📚 Отзывы клиентов — ядерное оружие продакта
📚О человеке с неудобными вопросами

10 ошибок в управлении разработкой - совместная статья со Skillsetter

В феврале мне написала главред блога Skillsetter и предложила написать вместе статью. Соглашалась без раздумий - у ребят бомбическая подача с примерами и заданиями, хотелось поучаствовать в таком формате. Результат можно почитать потыкав на ссылочку.

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

🕺 Скорее читать: https://skillsetter.io/blog/10-mistakes-development-management

#разработка

Last call на KZ BI Conf , которая состоится уже завтра - 27 февраля. Это бесплатная онлайн конференция для аналитиков и менеджеров проектов.

Вот несколько тем докладов из разных потоков:
🔜 Введение в Искусственный Интеллект: основы и применение в аналитике (Microsoft)
🔜 Навыки для визуализации данных (Яндекс Go)
🔜 Аплифт моделирование (Facebook)
🔜 Чем занимается product-менеджер и как им стать (Авито)
🔜 Гибкое управление заказными проектами (ScrumTrek)
🔜 Как проджекту работать с рисками (Актион Технологии) 😉

Конференция проходит с 7:30 по времени Москвы (10:30 г. Астана, Казахстан). Идеально для жаворонков, для всех остальных - будут доступны записи.
Регистрируйтесь на конфу, увидимся завтра!

▶️ https://databoom.kz/KZ_BI_Conf

​​👿 Плохие руководители

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

👩‍💼 Марина: я себя такой тупой чувствую, он мне дает задачи и потом стебётся, что я долго их закрываю. А я же только устроилась и вникаю. Еще он может дать мне задачу вечером в пятницу и сказать, что ее нужно сделать к утру понедельника.

🧑‍💼Или например, когда вас отчитывают / делают замечание при всей команде. Я так отчитывала свою team-mate за опоздания, когда совмещала роль проджекта с тимлидом бекофиса. У меня накипело и я решила, что "публичная порка" возымеет эффект. Более того, я считала, что "публичная порка" полностью оправдана, ведь человек опаздывал постоянно. В итоге, почему накипело у меня я осознала только через какое-то время, а человек в моменте стоял, краснел и обижался.

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

Какой ваш?

🌝 Неопытный руководитель - делает ошибки, но развивается, ценит команду. По щелчку пальцев руководитель не станет самым лучшим и классным, но он туда идёт. Поэтому вопрос к вам, готовы ли вы совместно с ним идти этот путь.

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

Что делать?

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

🚪Уходить. Если вы не готовы ждать и страдать, пока ваш руководитель изменится или на его место придет новый, то очевидный ответ - выходите из этих токсичных отношений.

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

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

#софтскилы

Алоха, запускаю сбор кейсов по проблемам с руководителями.

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

Переходите в гугл формы 👉 https://forms.gle/nx7TgNs58ZxzAfdr8
Вам наверняка есть чем поделиться. Буду очень признательна за ваши ответы, спасибо 😌

P.s.: оставайтесь на линии, для руководителей тоже такая движуха будет.

"Психологическая помощь" для руководителей 👉
https://forms.gle/ovFS5mfnLr7s9Vhw6

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

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

🚪Знаешь об увольнении - скажи

Если вам стало известно об увольнении члена своей команды - сообщите сразу об этом тому, кто отвечает за проект. Даже если есть шанс уговорить человека остаться.
Увольнение человека - это риск для проекта, а также возможная смена приоритетов в моменте.

Если узнал тимлид → сообщить менеджеру проекта.
Если менеджер проекта → сообщить тимлиду.

НЕТ
🧔Василий-ПМ: Олег решил уволиться. Мы с ним вчера пообщались, переубедить не удалось.
👨Лев-ТЛ: Вот блин, я ему план развития готовил все утро.

НЕТ
👨Лев-ТЛ: Олег вчера сообщил, что решил уволиться. Сейчас обсуждаем с ним дату.
🧔Василий-ПМ: Черт, я сутра уже отправил заказчику план релизов на следующий месяц, а закрыть место Олега пока некому.

ДА
👨Лев-ТЛ: Олег только что сообщил, что решил уволиться. Мы еще поговорим с ним, но на всякий случай сообщаю тебе.
🧔Василий-ПМ: Понятно, держи меня в курсе, я как раз хотел планировать задачи на следующий месяц.

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

Большие письма. 1 часть о культуре переписки

Не пишите большие письма. Это раздражает.

Ситуация: общаюсь я с товарищем по цеху, он мне гордо сообщает, что писал письмо партнеру почти 2 часа.
🧔"Это большое и сложное письмо, нужно было объяснить, что происходит сейчас в проекте и почему перенесли интеграцию с ним(партнером)",- говорит коллега.
В этот момент у меня возникают вьетнамские флешбеки.

Я в свое время тоже так делала - писала большие письма, когда с заказчиком накалялись отношения, а email считался официальным каналом связи. Мой любимый жанр был "я вам сейчас расскажу, где вы накосячили, а не мы". Сначала ты отправляешь письмо с 10-ю пунктами, потом получаешь ответ с комментарием по каждому пункту. И кажется, можно бесконечно перекидываться цитатами, выяснять кто-когда-что сказал, имел ввиду, наобещал или не наобещал.

Почему большие письма - плохо, еще раз:

📵Это неэффективный расход времени. 2 часа на одно письмо, где что-то нужно было объяснить!? Есть телефон.

📵 Большое письмо, которое "всё объясняет" понять сложнее - в нем слишком много мыслей, тезисов, фактов. Оно только путает получателя. Хуже когда получатель начинает вас подозревать в том, что вы хотите его запутать таким образом.

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

#софтскилы