🗑 Кидалово на работе

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

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

Дальше все зависит от Тани. Она может обидеться, закрыться, выложить резюме на HH, а может пытаться продавливать те договоренности.

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

Или вот, еще.

Тестировщик Вася договаривается с руководителем о повышении з/п через 3 месяца, если Вася поднимет планку покрытия тестами в команде.

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

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

🔗 На мой взгляд, если есть возможность соблюдать договоренности с бывшим руководителем - значит надо делать. Иначе страдает мотивация, лояльность сотрудника, авторитет нового руководителя, отношения между руководителем и подчиненным, HR-бренд компании и многое другое.

🔗 Если вы не можете выполнить их, то хотя бы относитесь к ним с трепетом. Поговорите с человеком, честно объясните всё и предложите другие варианты.
Чтобы не потерять человека, очень важна забота о нём, а не отмазки.

#софтскилы

​​А нам никто не сказал, у нас лапки

Есть небольшой b2b стартап. Команда разработки состоит из 9-ти человек, включая менеджера, который совмещает роли продакта и проджекта.
Команда запланировалась на 2х-недельный спринт - на доске расположилось более 80 задач, поставили цели спринта. Работа кипит, таски двигаются по статусам и колоночкам в JIRA.
В конце спринта, когда большинство задач должны подойти к своему логическому завершению - статусу Closed, менеджер смотрит на доску и видит, что все багфиксы и мелкие доработки зависли в статусе Release Candidate (RC).

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

Менеджера бомбит. Во-первых, они еще "не придумали" роль релиз-менеджера в команде. Во-вторых, ему намекают, что релиз менеджером должен быть он сам. И поэтому, в-третьих, у менеджера и так полный рот забот, а тут без него не могут катнуть правки.
Менеджер говорит: "Нет, котятки, так дело не пойдет. Я могла пропустить, что они в RC зависли из-за других моих задач. В тикете есть DOD, тестировщик проверил что все ему соответствует - задача едет дальше и не ждет моего согласования. А задачи, которые требуют моей приемки, всегда помечаются тегом Демо."

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

Хорошо, что менеджер не согласился с QA. Команда без релиз менеджера - лучше, чем команда с релиз менеджером и пустым беклогом. Это нормально, возвращать обезьян' на место, и полезно, рассказывать, что еще делает менеджер.

'Вечная рекомендация - Одноминутный Менеджер и обезьяны.

#софтскилы

🗣 Опрос по теме для конференции. Всем привет, нужна ваша помощь, guys and gals.

Меня тут позвали на одну конференцию для проджектов, нужно определиться с темой доклада. Все подробности обязательно расскажу позже.

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

1️⃣ вариант. Как структурировать поток сознания заказчика. У меня уже был подобный доклад на WTM, но в этот раз хочу дать больше примеров и учесть ошибки прошлого.

2️⃣ вариант. Как проджекту работать с рисками, разборы типовых и не очень кейсов.

Ставьте 1️⃣, если вы за первую тему, и 2️⃣, если за вторую. Мне важно знать, что вы думаете. Спасибо 💜

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

Началась встреча с заказчиком, обсуждаем статус проекта. На встрече присутствуют менеджер проекта, продукта, технический руководитель и другие заинтересованные товарищи из бизнеса.
Предварительно заказчик посмотрел отчет за неделю. В отчете указано, что фичу 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

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

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

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

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

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

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

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

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

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