​​Ужас🤯, тебе наверно придётся взять отпуск, чтобы это прочитать, но я попробую🤣

Начинающему менеджеру проекта или владельцу продукта трудно сказать "нет" Заказчику.
Но этому навыку надо учиться. И вот почему…

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

Представь ситуацию: ты 3 месяца владелец продукта и спонсор хочет добавить в продукт "крутейшую" с его колокольни фичу! При этом стейкхолдер - не простой, а целый спонсор продукта/проекта!

Что можно испытать при этом:
🤔 если я откажусь брать эту задачу - то меня уволят
🤔 если я откажусь брать эту задачу - то меня сочтут некомпентентным (синдром самозванца)
🤔 если я откажусь мне перестанут доверять
🤔 если я соглашусь - разделят со мной ответственность за предложенное решение и т.д.

Все мы люди, и чем больше ответственности на нас лежит, тем сильнее желание комфорта (лёгких решений), и это замыливает глаза, не позволяет видеть перспективы.

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

🎬 Недавно посмотрел интервью Квентина Тарантино о том как он подбирал альтернативный каст на свой второй фильм "Криминально чтиво".

📌 Исходные данные: он по-прежнему малоизвестный режиссёр с перспективой. Он видел в одной из ролей - Тима Рота, но студия не видела актёра даже в шорт-листе. По итоге Квентина спросил у боссов студии: "Если я выберу актера из вашего списка, вы уверены, что это принесёт вам бОльшую сумму в прокате, чем если я возьму Тима?" На что получил ответ: "Нет, я просто буду чувствовать себя комфортнее".

КОМФОРТНЕЕ, блин🤯!! То есть босс студии во главу угла поставил не заботу о ценности, которую принесёт решение, а гармонию со своими ощущениями.

📌Второй пример оттуда же: Квентин очень хотел суперстар на одну из ролей. И судьба подкинула ему встречу с Брюсом Уиллисом (в топе оплачиваемых звёзд на 1993г). И когда Брюс попросил сыграть сначала одну главную роль, потом другую - Квентин вынужденно отказывал ему дважды (с одной стороны потому что роль была уже предварительно закреплена за другими актерами, но по большей части потому что ОН - РЕЖИССЁР видел этого актера в другом амплуа. По итогу Брюс сыграл 3-ю ведущую роль в фильме.

История показала, что оба выбора были сделаны правильно. Хотя на первый взгляд личность актёра и статус спонсора подсказывали сделать очевидный выбор. Но Квентин видел свой "продукт" таким каким он считал будет самый ценный результат🫵

В итоге владелец продукта ты, а не стейкхолдер и тебе отвечать за конечный результат. Не надо думать, что если стейк сказал "делай так!", то можно будет переложить на него ответственность за принятые решения. Волшебство не в умении сказать "нет", а в способности изменить чужую точку зрения. А ещё в том: КАК изменить мнение такого типажа и вызвать его безграничное доверие, которое в последствии подкрепится результатом?

Как с этим в себе работать😁? Не бороться, а обернуть себе на пользу☝️?

Как сказал мой коллега бизнес-архитектор Витя на своём выступлении:

1️⃣ проявляй любопытство
2️⃣ рефлексируй
3️⃣ не хватает обратной связи - додумывай её!
4️⃣ меняй майндсет: у тебя не проблемы - а возможности!

50 проектов года в мире

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

В этом году зацепило 2 проекта:
↗️ Ретро-футуристический проект по созданию полноценного выступления цифровых аватаров группы ABBA образца 1979 года.💃🕺
↗️ Проект по цифровизации государственной валюты - "Реала" в Бразилии. Когда цифровые валюты не просто сосуществует с реальными, а начинают постепенно замещать реальную государственную валюту. Вопрос как быстро подхватят другие страны с смелым взглядом на цифровизацию?💸

Все проекты можно посмотреть по ссылке

Поздравляю всех читателей канала с наступающим НГ!🎄

Спасибо, что вкладывали свое время в чтение канала и собственное развитие несмотря ни на что.

Это был нещадный год и все мы знаем почему. Вчера на одном из ретро прозвучал вопрос: "Какой новый год был твой самый лучший?" На что я ответил: любой до 2019 включительно. Но мы можем стать гибче, сильнее и обязаны МИРнее. Всем любви, добра, мотивации и открытий в новом '23💙💛

​​Когда скрам-мастер отстаёт от команды.

В авиаотрасли есть такое выражение: "экипаж отстаёт от самолёта", когда пилоты запоздалыми действиями реагируют на инерционность самолёта.

У СМа тоже масса способов "отстать" от команды:

📌 подготовил план ретроспективы (естественно, опираясь на потребности команды), а на обзоре спринта команде от токсичного стейкхолдера прилетело, что всё в спринте реализовано не так.
📌 в команде образовался конфликт, а СМ предлагает команде обсудить какие они молодцы в спринте.
📌 команда активно хочет начать обсуждать используемые в разработке технологии, а СМ - про доверие и ценности (это безусловно важно и нужно, но не в текущем моменте).

Это примеры того, когда СМ находится в точке, которую команда уже прошла, а СМ ещё не осознал.

Причинами такого поведения может быть:
🔹 СМ работает с несколькими командами и не успевает
🔹 СМ живёт на своей волне как считает "должен работать скрам" и не вникает в потребности команд
🔹 СМ переносит опыт своей другой команды на новую со своими уникальными проблемами
🔹 Нехватка знаний в business-area или tech-area команды создаёт ложное восприятие, что проблема не существенна. Обсуждают другое, а команда в итоге демотивируется ещё глубже из-за неразрешённой корневой проблемы.

Конечно паттернов может быть ещё бесконечное множество, но решение только одно - менять себя (слушать, учиться, просить помощи). Ну, или менять команду, хотя вряд ли это поможет😉

Не хочу учиться, а хочу трудиться!

Недавно наш скрам-мастер проводила онбординг стажёра в компании. От него прозвучал вопрос: "Где учиться на скрам-мастера?" А и вправду где? И на скрам-мастера ли? А вышка вообще нужна? Можно ли войти в айти из другой отрасли пройдя Skillbox/GeekBrains/Udemy и т.д? 🧐

Помню как в 1994 году шёл с отцом в школу и слушал про устройство BIOS, DOS и Norton Commander. Microsoft к тому моменту уже 2 года как создавали win95. Переношусь на 12 лет вперед - на дворе 2006. В институте в рамках сетей и телекоммуникаций изучали принципы работы SMM - в закрытой военной системе это казалось какой-то бесполезной магией. Facebook уже родился, одноклассники уже успели "умереть", телеграмм, где я это пишу еще не существовал😁

Когда заканчивал работать сисадмином в 2011 уже несколько лет как появилось понятие DevOps как составляющая такого "незначительного" подхода к проектам по разработке продуктов - Agile😉 Ах да, сам Agile уже тоже 10 лет как возник, а Scrum так вообще был представлен в далёком 1995 как раз рядом с Win95.

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

🟣 Детектив по работе с данными
🟣 Проектировщик путешествий в дополненной реальности
🟣 Диспетчер магистралей
🟣 Криптокоуч
🟣 Мастер периферийных вычислений
🟣 Генеральный директор по доверию

Можно почитать больше ТУТ

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

А нужна ли при этом вышка? - Да, но надо понимать, что ты от неё хочешь? Системное мышление? Основы менеджмента, поведенческая психология, уметь в "магию цифр" или что-то другое? Условные 5 лет - это почти пресловутые 10000 часов, чтобы качественно овладеть на практике каким-то делом. Стоит ли того инвестиция вашего самого ценного ресурса - времени в это?

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

​​Когда мы знаем, что именно хотим сделать, самое трудное - знать, когда это сделать.

У нас была команда мастер-данных, перезапуск в том или ином формате мы осуществляли 2 раза, а "корабль всё не хотел идти"❌🛶

Исторически сложилось, что эта команда почти каждую каденцию обращалась к другой - шина данных, чтобы та ей делала бэк. Пришли к выводу, чтобы нивелировать этот разрыв надо бы в конце концов объединить усилия и создать единую команду. Так удалось провести командообразующий тренинг🤝. Сформировался коллектив из PO, Analyst, 3 Dev, QA, Project Manager и Coach (да, мы экспериментируем с форматом, где в одной команде могут быть и владелец продукта и менеджер проекта).

Многие ребята увидели друг друга в реале впервые. Поэтому первый день ставку сделали на то, чтобы создать атмосферу доверия и командных договорённостей через канвас доверия и ground rules🙏.
Второй день посвятили глубокой проработке архитектуры нового продукта и бэклога объединённой команды. Речь шла не об объединении бэклогов, а о формировании новой архитектуры будущего продукта с "0", но самые ценные истории из старых бэклогов мигрировали в новый.

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

Для айсбрейкеров выбрал: упражнение на запуск креативного мышления (уйти от стандартного мышления в начале работы команды полезно, чтобы отвлечься от старых наработок) и отработку коммуникации в команде через детективное расследование на время (ребята научились взаимодействовать вне зависимости от ролей, которые они исполняют - T-shape же ж🌚)

Как отдельная вишенка на торте само название новой команды - "DOS" (спасибо за идею руководителю нашего отдела разработки - Грише🔥). Новое - хорошо забытое старое, только теперь это не disk operating, а data orchestration. Теперь название полностью отражает суть того продукта, каким команде предстоит заниматься.

Главным инсайтом для меня во время тренинга послужила ситуация, когда на упражнении в знакомство ребята вместо того, чтобы рассказывать one-to-one стали самоорганизовываться в группы коллаборируя по 3-4 человека и стали делиться информацией о себе более эффективно. В этот момент произошла синергия и дальше достичь цели тренинга для участников стало лишь делом времени.

Наткнулся на 2 отличных поста в сети. Имхо, в таких мелочах и выражается движение команды в философии Agile.

1) текстом ниже - от тимлида разработки в компании FortyAU
2) картинкой - с командными метриками, которые "стоят дороже", чем показатели Velocity

Вот 5 вещей, которые я не разрешаю в своей команде разработчиков:

⛔️ Не разрешается использовать слово "глупый" для описания себя или своей работы. Вместо этого мы используем слово "картошка". Почему? - Потому что это заставляет всех улыбаться, потому что незнание чего-то не делает человека глупым, и потому что это помогает относится к себе более снисходительно, когда речь идет об ошибках.

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

⛔️ Застревать или "теряться в море". Каждый вторник и четверг команда проводит встречи Tech Day (T-Day), на которые каждый может принести свой блокер и поработать в паре с другими. Это безопасное пространство, где можно сказать: "Я не знаком с..." или "Является ли мое решение лучшим?". Это помогает нашему проекту двигаться вперед и обеспечивает две тренинг-сессии в неделю.

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

⛔️ Извиняться за незнание термина или инструмента. Мы не извиняемся за обучение и рост! Несмотря на то, что от каждого ожидается ответственность за свое обучение и максимальная самостоятельность, мы создали глубокий уровень профессионального доверия, чтобы признать, когда что-то незнакомо. Нет ни одного разработчика, который бы знал все обо всем. Мы подходим к проблемам с мышлением о росте, и это выгодно всем. Не знать - это нормально, но НЕ нормально не учиться!

Бонус:

✅ Вам не нужно ждать, пока вы станете senior разработчиком, чтобы реализовать эти идеи!
✅ Доказано, что создание сильного чувства психологической безопасности повышает производительность, счастье команды и в конечном итоге приводит к более высокому уровню успеха и достижения целей. Если вы будете способствовать психологической безопасности, ваша команда станет на шаг ближе к тому, чтобы стать неудержимой!

Сегодня пятница, но это не #пятничныйюмор😉 - разыскивается кандидат на вакансию мечты!

Ищем в нашу команду Scrum Master🧙. Ты будешь помогать крутым командам стать ещё круче, но не зазнаваться😉

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

Что мы предлагаем:
🪁 Свобода
🏈 Уже есть команда сильных профи
🦄 Руководство топит за agile
🏄‍♀️ Сначала agile в сердце, а потом – в инструментах

Пожелания к тебе:
🪄 ты на одной волне с нами - готов(а) адаптироваться и меняться
🪄 кайфуешь от того, что делаешь и живешь этим
🪄 хочешь и можешь взять полную ответственность за свою работу
🪄 готов(а) уверенно браться и доводить до конца как интересные, так и скучные задачи
🪄 можешь в юмор и не пасуешь перед стрессом
🪄 владеешь английским или непревзойдённо пользуешься переводчиком
🪄 круто, если у тебя есть опыт, а если нет, то ты очень быстро схватываешь

если это ты🙏, то напиши, пожалуйста, нашему менеджеру Кристине @KristinaAvant
напиши так, чтобы она вовлеклась и ответила 🙌
также, пожалуйста, поделись с друзьями, если это не ты🤝💫

p.s. для тех кто любит всё по полочкам - бездушное описание на hh.ru

На прошлой неделе от клиента поступил запрос: "хотим начать использовать гибкие методологии в управлении проектами". Провёл вебинар про Agile&Scrum для инжинирингового подразделения клиента.

После overview быстро перескочили на практические вопросы:

🙋‍♀️Какой длины должен быть спринт?
🙋‍♂️Как посчитать велосити?
💁‍♀️Как декомпозировать истории?
🤷‍♂️Скрам мастер для команды коуч, ментор или менеджер проекта? и т.д.

Порадовало искреннее желание людей менять свой подход к реализации проектов для более эффективного и гармоничного взаимодействия в командах🙏

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

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

📌 К о н т е к с т: в какой области развития находятся сейчас твои процессы (модели: "Киневина", "Стейси", да хоть здравого смысла🤷‍♂️)?
📌 Л ю д и: готовы ли участники потенциальной команды разделять не на словах, а на деле ценности и принципы гибких подходов?🫶
📌 М ы ш л е н и е: готовы ли мы двигаться от майндсета в сторону инструментов, а не наоборот?🏄🏼
📌 К о м а н д а: способны ли договориться какие выбрать инструменты/фреймворки/практики и сформировать и поддерживать собственные базовые правила работы?🤝

Получив ответ на эти вопросы можно с высокой долей вероятности ответить стоит ли стартовать трансформацию в Agile.

​​Провели эксперимент по временному обмену скрам-мастерами в командах.
Если кратко - эксперимент признан удачным!👍

Основные выводы:

1️⃣ Для команд и скрам-мастеров это был выход из зоны комфорта. Когда команда привыкает к коучу остаётся мало места неожиданностям. А Agile - это про непрерывные изменения. Чтобы мы не жили по "фэн-шую" - это был период активного пересмотра своих процессов.

2️⃣ Команды осуществили ряд важных изменений:
⏩ пересмотрели формат и время ключевой встречи для инспекции - ретроспективы
⏩ приняли изменения, которые помогли качественно улучшить работу со своими бэклогами
⏩ поработали над вовлечённостью и доверием участников команд
⏩ в некоторых командах перешли от "нянчинга" команд к коучингу по запросу, что повысило ответственность участников команды за процесс своей работы

3️⃣ Для скрам-мастеров это тоже принесло немалую пользу - возможность посмотреть как работать с другими "типажами" команд (какие-то команды более вовлечены, какие-то менее). Это позволило скрам-мастерам прокачать свои скиллы, которые не всегда нужно активировать в работе со своими "родными" командами.

И всё это всего за 3 двухнедельных спринта!!! Полезный опыт - будем практиковать.

​​Западный подход к сервису vs местные практики проектов😏

Мы пользуемся best-practice от PMI, Agile, а потом сталкиваемся с суровой проектной реальностью🤯
Чем заканчивается проект? - Развитием? Новым сервисом? Поддержкой? Выученными уроками?

- Судом!!!⚖️

Представь проект: твоя компания договорилась с Заказчиком, что надо вырыть прямую траншею 600 метров экскаватором. Ты стартовал проект, через 2 дня прорыл уже 300 метров (темп был согласован с Заказчиком) и тут видишь, что дальше по курсу траншеи яма в диаметре 20 метров и глубиной с ваш экскаватор. А за ней стоит ещё один экскаватор с Заказчиком, который говорит "Вы не вырыли 600 метров поэтому мы заказали другой экскаватор, который доделает вашу работу. Возвращайте назад деньги, которые я заплатил за первые 300 метров, потому что вы не выполнили работу до конца".

С софтовыми проектами всё немного сложнее, хотя геодезисты со мной, наверно, поспорят😂

На прошлой неделе состоялся суд по одному из проектов. В зале суда было "жарче", чем Крымским летом в степи☀️. Корпоративных судов я в карьере не проигрывал - и этот не стал исключением. Проигрывал только личный😀 Но проезд под ⛔️ с 📸 сложно оспорить🤦‍♂️

Не буду вдаваться в подробности проекта и судебного разбирательства (типичное внедрение информационной системы "под ключ" для малого бизнеса) . Скажу о другом: всегда что-то пойдёт не так!👆 Думай об этом на инициации проекта, на планировании, при реализации, в любой фазе. И я сейчас не про управление рисками. Много лет назад CEO научил простым практикам взаимодействия с Заказчиком, чтобы правда всегда оставалась на твоей стороне, если конечно не обманываешь себя и управляешь проектом ответственно.

👉 после всех очных/онлайн встреч - высылай протокол договорённостей по итогам (followup, "минутки" кто как называет)
👉 всё устное/телефонное общение - высылай протокол договорённостей/статуса по итогам
👉 все представляющие значимость письма (пронумерованнын с датой) отправляй почтой с описью вложения и квитком уведомления о вручении
👉 в конце электронных писем с важными договорённостями не забывай приписывать "прошу ответить, если с чем-то не согласны"
👉 если в одностороннем порядке предлагаешь/инициируешь действия в письмах, то не забывать приписывать в конце письма "ожидаю ответа до "дата/время" включительно после чего считаю, что адресаты согласны с вышеизложенным"

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

Благо в этот раз судья была благосклонна🙌 и дала нам дополнительных 5 минут на ознакомление с отзывом оппонентов на иск и, о Боги!, на последней странице отзыва Заказчика я обнаружил скриншот с моим письмом от 2021 года в котором мной было написано "что без нашего ведома вы привлекли на проект параллельного подрядчика, который обрушил систему, и предписание: немедленно отключить и не нарушать больше пункт о конфиденциальности договора, иначе мы не гарантируем качества внедрения и результатов работ". Шёл 2022 год - не взирая на пункт договора о конфиденциальности подрядчик снова был привлечён, накуралесил изменений в системе в тайне от нас и нам предъявлена претензия об отвратительном качестве внедрения. Занавес!🙈

Всё, что аргументировалось дальше - уже лирика. Было нарушено правило, которое прописано в договоре и которое подсветили за полгода до последующих событий письмом.

P.s. И компания не должна экономить на хороших юристах 😉

​​"…Голубой вагон бежит качается, cкорый ART набирает ход…"

Последние 1,5 года анализировали способы подружить традиционные подходы проектного управления с действующими уже давно в компании гибкими подходами Скрам и Канбан-методом.

На прошлой неделе, наконец, утвердили новую ролевую структуру компании и запустили фреймворк SAFe. От инициации до старта решения путь составил 5 месяцев. Пока речь идёт только о полноценном уровне Essential, но уже заглядываемся на Large Solution🌊

Контекст наработанных взаимодействий определил, что:

🛤 роль системного архитектора будет сосредоточена в руках руководителей отделов аналитики, разработки, тестирования и эксперта DevOps
🛤 product Owners теперь как британские монархи - "царствуют, но не правят". Они по-прежнему доносят командам продуктовую цель, создают и упорядочивают элементы бэклога, а за формирование видения продукта и определение роудмапов теперь отвечают Business Owners.
🛤 ключевым вызовом будет донести одну из ценностей SAFe - "встроенное качество" до всех уровней менеджмента.

Ты говори, говори...

Ребята из команд подходят с вопросом:
- Как мне сделать, чтобы меня услышала команда?
- Начать говорить
- Вот так просто?
- Так просто

Бывает, что ребята даже в рамках одной команды молчат (недоверие к участникам, скучный продукт, демотивация, и "бла-бла-бла", которого как раз нет)😏

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

Вот и я решил выйти в общении из зоны комфорта и зарегился на платформе lunchclub🤝. Эдакий формат "random coffee" встреч, кто знаком.

За 2 недели удалось пообщаться с:

👨 Директором по инженерии данных из Мельбурна🇦🇺, который 2 года как приехал в Ханой, чтобы выстраивать Data Governance для правительства Вьетнама🇻🇳 и уяснил для себя, что австралийцы в отличии от вьетнамцев "lazy buddies bloody hell" (дословная цитата😂😅)

👩‍🦰 Продактом из 🇳🇬Лагоса, которая развивает приложение для букинга отелей в Нигерии для популяризации отдыха в своей стране

🧑‍🦱 Руководителем отдела разработки из 🇺🇸Сан Карлоса, занимающийся кибербезопасностью промышленных объектов

У каждого свой стимул там общаться, но для меня эта платформа:
💎 возможность расширить горизонты в своей профессиональной области
💎 узнать чем живут люди других культур
💎 возможность прокачать свой разговорный и профессиональный английский
💎 узнать путь людей (в широком смысле). Не знаю как описать точнее, наверно, больше про мотивацию и про "North Star" в их жизни.

Очень доволен экспериментом и однозначно буду продолжать. Кто хочет последовать моему примеру ловите ссылку:
https://lunchclub.com/?invite_code=eugener7

И ещё пару моментов:
🔹 для того, чтобы зарегаться - нужен аккаунт linkedin
🔹 эта платформа работает через приглос (он выше)
🔹 если хотите общаться с людьми из определённого региона - выбирайте соответствующий временной диапазон в который хотите общаться

​​#пятничныйюмор или "не юмор"?😜

Сегодня на прайме выходит сериал про нашу тематику. Ожидаю с нетерпением, особенно, если учесть, что в главной роли Кристоф Вальц в типаже a.k.a Ганса Ланды из Бесславных ублюдков на первый взгляд.

"My job is to observe, to streamline, to improve..."😏
"For those who work remotely you have 1 hour to get here or you will be TEEERRRRMINATED"😅😂

Фразы что-то смутно напоминают😉

Не всегда нужно "5 почему", порой достаточно и 1-го

В прошлом году, отдыхая на курорте, зашёл в турецкое кафе. По размеру очереди было заметно, что с сервисом что-то не так. Бегающий супервайзер добавлял нервозности. В какой-то момент девушка, которая обслуживала посетителей под орущим прессингом старшего "товарища" просто сбежала с кассы в слезах😪. В итоге он не только не решил проблемы своим криком, а усугубил. Очевидную нехватку ресурсов в busy-time он вымещал злобой на своей подчинённой. В итоге в проигрыше все...он, коллега, клиенты, имя бренда🤯. Можно ли было поступить иначе, взяв под контроль свои эмоции?

Наш случай...представитель бизнеса схлеснулся с руководителем разработки. Предмет спора: деливери команде надо делать техдолг, а бизнесу - подай обоснование ценности реализации таких задач (команда in-house разработки). А можно обосновать ценность того, что надо выполнять ТО автомобиля?🤔 Или менять тормозные колодки? Масло? А нужно ли проходить заявленное производителем обслуживание самолёта? Он же уже построен!😤 Стоит ли говорить, что будет, если не делать эти плановые действия?

Это не вопрос ценности, а "гигиены" продукта. В этом смысле понравилась статья про техдолг:
https://www.infoq.com/articles/technical-debt-tells-you/

Полезно СМам без технического бэкграунда, которые могут подумать, что техдолг - повинность команды и её недоработки (серьёзно, в одной команде видел пример как задачи по техдолгу "оценивали" в 0 сторипойнтов и ожидалось, что участники будет выполнять эти задачи в своё личное время).

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

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

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

Про культуру и коммуникации. #заметкируководителя

Люди часто увольняются из компаний по разным причинам, но не потому что продолбали срок проекта или не выполнили EBITDA. А зачастую потому что мне надоел руководитель, команда, коллеги. Влияние локальной культуры не стоит недооценивать.

- Поднять паруса
- Есть поднять паруса!
- Поднять якорь
- Есть поднять якорь!

Зачем повторять на флоте? Потому что если я услышу "Есть…", то лучше сразу скорректирую последующие действия, чем потом буду разгребать последствия.

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

Карго культ #нереклама

В Старом Крыму стоит древний армянский монастырь - Сурб Хач⛪️. В паре километров от него небольшая кафешка. Больше 10 лет назад познакомился там с татарином Шевкетом. Сейчас там такой размах, что уже свадебные шествия играют, а тогда - стояло всего 4 стола под кустарным навесом. Я тогда попробовал самый вкусный шашлык из ягнёнка на кости🥩. Будучи к тому моменту уже экспертом в готовке разнообразного шашлыка подумал "А чем я плох? Тоже могу такое сделать и не нужно никуда ехать!" Сделал заказ у мясника на рынке и мне привезли отличного (как тогда показалось) ягнёнка. Опуская подробности шашлык получился ужасный🤦‍♂️🥴

Больше разговаривая с Шевкетом понял, что выбор правильного ягнёнка - это целое искусство, а как известно 50% успеха шашлыка - это исходное качество мясо. У него свой поставщик, огромный опыт определения сходу "то или не то", количество проб и ошибок, которые привели к ныне отменному качеству👌

Навеяло мысли, что не стоит пытаться взять и "схватить" чужой скрам такой же как у других как это часто случается в компаниях. Важен контекст, опыт инспекции и адаптации в собственных процессах компании. Мышлении того не только "КАК" мы хотим прийти к росту, но и "ЗАЧЕМ" (читайте Саймона Синека "Начни с почему"?).

Важна индивидуальность и идентичность команды. Вы никогда не вырастете, если будете искусственно копировать другие команды.

Как-то пришел запрос помочь запустить скрам в командах в одной крупной страховой компании. 10 команд с тимлидами, которых руководство хотело сделать владельцами продуктов/скрам-мастерами (именно "слэш", а зачем нам лишние люди и роли?).

За час общения с менеджментом выяснил, что никакие ценности и принципы Agile/Scrum людям там не близки и не нужны. Стояла задача внедрить инструмент (Скрам), который позволит ещё более жёстко контролировать и карать разработчиков за их действия. Наши пути разошлись.

Из последнего, что меня поразило коллега спрашивал какой на рынке усреднённый показатель срока за который можно сжечь весь бэклог?🧐🤔

Ну, камон?!!! Какой состав команды? Какой у них уровень зрелости? Тасуется ли команда? Шэрятся ли ресурсы? и т.д.
А главное ЗАЧЕМ? Сама цель стоит сжечь весь бэклог? Вообщем "готовность к изменениям важнее следования первоначальному плану" в этой ситуации "по борту".

А кафе Шевкета от души рекомендую - всего 2 км от старой (до Тавриды) трассы Керчь-Симферополь и вы отведаете лучший шашлык и шурпу в Старом Крыму😉

#полезное

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

Незримый рост

Тяжело отпускать. Потому что:

👎 хочешь сделать сам
👎 потому что у тебя получается
👎 потому что уверен, что хорошо сможешь только ты
👎 потому что другие не смогут также хорошо как ты
👎 потому что ты умеешь, наконец

...величайшее заблуждение руководителя😂

На прошлой неделе произошло ужасно прекрасное событие скрам-мастер в личке сказала мне на одной из командных встреч, что меня много и не мешало бы помолчать (без пассивной агрессии)😉 Даша, спасибо, за озарение🙏

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

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

В начале моего пути как РП стояла задача овладеть хард скиллами (aka PMBoK, PRINCE2). На следующем этапе - овладеть софт скиллами (коммуникации, лидерство, фасилитация и др.). Новым уровнем пару лет назад стало желание понять ценности каких компаний мне близки и какими проектами я хочу/не хочу заниматься потому что это идёт в разрез с моими ценностями.

Сейчас же столкнулся с новой реальностью уже не как специалист, а как руководитель: понять какие скиллы важны помимо "хардовых" (матрица Эйзенхауэра, мотивация сотрудников через цели, процесс и результат, делегирование и т.д.)

Описанное выше - это только база, а есть не менее важные вещи:

👍 уметь выстраивать нетворкинг
👍 уметь в сторрителлинг
👍 критицизм
👍 эмпатия
👍 гибкость
👍 растить лидеров, а не последователей (спасибо @scrumbatya и @anyapavliuchenko за книгу "Turn the ship around")

Для себя понял, что быстрый (не путать с легким😂) путь научиться доверию - это чтобы те, с кем ты работаешь учились тому, что плохо или вовсе не знаешь ты...в таком случае у тебя не остаётся выбора как довериться человеку и всячески саппортить его успеху (но не мешать!).

Вдохновляющим примером для меня является адмирал Риковер - "отец" атомного флота, США, которому приписывают фразу..."Если подчинённый всегда соглашается с начальником, то он бесполезная часть организации".