На прошлой неделе от клиента поступил запрос: "хотим начать использовать гибкие методологии в управлении проектами". Провёл вебинар про 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")

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

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

Имел удовольствие попрактиковаться с коучами скрам-трека Настей Бутовой-Никишиной и Серёжей Липчанским.
Всё это "под соусом" золотого бейджа от ScrumTrek. Но мне был интересен не бейдж.
Люблю решать сложные кейсы и должен признать, что процесс выстроен достаточно интересным образом. Сначала надо пройти тест, потом написать эссе по 2м кейсам с командами (кейсы максимально ситуативные - примерно как встречал на сдаче PMI-ACP).

После успешного выполнения - практическое интервью с 2мя коучами на 4 темы:
📌 Продемонстрировать опыт успешной работы с командой
📌 Продемонстрировать опыт успешной трансформации компании
📌 Умение в коучинг/менторинг
📌 Умение результативно работать с большой аудиторией

Результат был предсказуем - коучинг я провалил, потому что для решения вопроса "включил" РПшника по полной программе😂
С остальными пунктами было всё отлично. Было очень интересно поработать "в полях с командами", пусть и в песочнице.

Когда Серёга вжился в роль неуступчивого вредного PO, конфликтующего с командой в кейсе с коучингом пришлось попотеть)) Вспомнил свои самые сложные кейсы с реальных ретроспектив. Думаю, что в реальной жизни удалось бы решить проблему но не за 3 минуты как на тестировании и не факт, что коучинговым способом😉 благо на это у СМа ещё 7 шапок😉

Однозначно советую попытать свои силы с разными экспертами, чтобы всесторонне оценивать свои скрам-мастерские силы.

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

​​Часть корабля - часть команды!

На прошлой неделе наша команда провела двухдневный командообразующий тренинг для руководителей одной из компаний.

Самое любимое, что ещё до тренинга изначально всё пошло не по плану🤪

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

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

В этот раз тренинг было решено провести в сеттинге экипажа викингов на Драккаре.
За своё путешествие команде было предложено пройти испытания на:

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

Отметил интересные моменты:

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

⚓️ в упражнении про коммуникации когда надо было ответить на вопрос: "Мне ЛУЧШЕ всего работается когда…" добрая половина участников в своём повествовании заменила слово лучше на "ПРОЩЕ/УДОБНЕЕ". Лучше - это про то, что побуждает двигаться вверх, окрыляет, мотивирует, а проще/удобнее - это что-то с душком демотивации - лишь бы от меня отстали и не трогали☹️ Любопытно, как люди в процессе упражнения неосознанно подменяли эти понятия.

Яркие фразы, которые запомнились с тренинга:

💥 Деньги - это коэффициент свободы
💥 Я люблю умничать, а если за это ещё и платят хорошие деньги, то это вдвойне круто!😉
💥 ОС бесполезная трата времени, если ничего с ней дальше не делать
💥 Под обратной связью некоторые подразумевают тотальное уничтожение личных границ, ну что поделаешь, будем надеяться, что когда-нибудь они все умрут🤣
💥 Важно правильно подбирать слова. "Помощь" и "поддержка" - разные штуки. Поддержка - это про психолога/инструктора по вождению. Помощь - это про то, что сделают за тебя.

В качестве полезного для себя "унёс с тренинга в рюкзачке" книгу на почитать:
📚 "Компас эмоций. Как разобраться в своих чувствах", Илсе Санд

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

@Cat_with_your_camera, спасибо за проделанную работу до, во время и после тренинга! Это было круто!🔥👏🤝

#полезное in English

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

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

📌 Интересный взгляд на роли, когда случается несправедливость: жертва, вредитель, лидер или тот, кто вступается. В том числе описаны паттерны поведения как следует поступать той или иной роли.

📌 Культура обучения через ошибки:
🔹Рассматривать инциденты как возможности
🔹Поощрять обмен знаниями
🔹Рефлексировать

📌 Как уволить чайка-менеджеров😂. А если честно, то селфчек как понять, что ты сам "не там" и что с этим дальше делать, если вдруг ты один из них?

#непропроекты Эмоциональное ностальжи от книги к ИИ

Пишу это лично соприкоснувшись со скайнет чатом ЖоПыТи😂. Возможно кто-то из олдфагов поймает себя на мысли, что тоже касались этих вещей.
 
⛩ 1991 - Книга "Энциклопедия профессора Фортрана" - получил первые знания о ПК.
 
⛩ 1992 - Сыграл в первую игру - гонки Grand Prix Circuit на ламповом 386м с кнопкой TURBO для "разгона процессора"😉
 
⛩ 1993 - написал свою первую программу на Turbo Basic. Результат был гораздо приятнее процесса, что предопределило быть проджектом, а не усидчивым разработчиком или продактом😊 В следующий раз с TB я столкнусь 16 лет спустя в центральном командном пункте ВМФ, только над системным блоком будeт висеть не плакат с выдержками из книг по программированию, а топор с надписью "уничтожать в первую очередь" - не шутка если что🤯
 
⛩ 1994 - Warcraft/Doom не могу разделить эти игры. Они перевернули мой детский мозг. Стратегия в итоге победила, потому что в Doom было по-просту страшно играть в 6 лет, даже если очень хотелось😂
 
⛩ 1997 - Photoshop 4.0. Это сейчас редактирование фотографии на телефоне так же просто, как отправить сообщение в телеге, а тогда возможность отсканировать на сканере черно-белое семейное фото и раскрасить в цвет казалось магией сродни сегодняшним картинкам нарисованным искусственным интеллектом.

⛩ 1999 - HoMM3. Будь проклят тот день, когда я сел за баранку этого пылесоса попробовал сыграть в Герои меча и магии 3 в первый раз😂. Не зная, что надо нажать кнопку "следующий день" закрыл игру как самую бесполезную в мире. Зато позже, когда распробовал - для меня это самая долгоиграющая и прокачивающая оперативную память мозга до сих пор (кстати, на тему развития объема нашей рабочей памяти мозга, можно посмотреть вебинар Ивана).
 
⛩ 2002 - собрал первый собственный ПК. Поразило то, что в одном устройстве могут быть: ПК, "видеомагнитофон", "музыкальный центр", обработка видео с VHS-камеры, можно писать музыку через аудиокарту с MIDI-клавиатуры Это казалось пределом того, что вообще когда либо смогут технологии😂 P.s. есть кто помнит ламповый Winamp😉?
 
⛩ 2007 - "точка невозврата"😊 Узнал, что можно получить сертификат Microsoft, если пройти обучение и сдать сертифицированный экзамен. Для курсанта военной системы казалось нереальной фантастикой и предопределило, что теперь ПК должен стать профессией, а не игрой.
 
⛩ 2017 - познакомился с управлением проектами в разработке ПО и Agile (спасибо Антону и ребятам той команды).
 
⛩ 2023 - опробовал chatGPT. Теперь уже профессии будущего не просто не за горами, а прямо "на ходу" можно начинать учиться - промпт инженер, детектив отпечатков ИИ-интеллекта в тексте, копирайтер у ИИ и т.д.
 
Каждый раз - это неподдельная эмоции от соприкосновения с чем-то, что открывает для тебя мир по-новому.
 
Когда писал задумался как забавно, что чем взрослее становишься, тем всё большие перерывы, когда какие-то события могут тебя поразить, но хорошая новость: по-прежнему могут!🙏🔥
 
А как твою жизнь 🫵 перевернули информационные технологии? Размышляли, что может появиться в будущем в сфере ИТ?

#полезное in English

📌 пособие для развивающихся лидеров о том, как можно разрешать сложные ситуации используя структуру: ("Вероятно", "Только", "Может быть", "Возможно"). Примерил как бы я разобрал пару своих недавних и сложных кейсов - оказалось действительно можно посмотреть на ситуации под другим углом используя этот метод.

📌 И снова про метрики😉 В статье описаны 3 метрики качества: внешнее, внутреннее и качество процессов. Понравилось, подчёркивание автора, что важно измерять внешнее качество (то, как пользователи воспринимают продукт), хотя это как правило сложно и частенько на это забивают. А зря, ведь именно здесь "зарыта собака" спрятана ключевая оценка ценности продукта!

📌 Очень плохие компании измеряют Velocity каждого отдельно взятого разработчика команды, плохие компании измеряют Velocity команды. Хорошие компании дают право самим командам измерять и управлять Velocity своей команды. Статья для чего на самом деле нужно измерять Velocity. Не ново, но содержательно.

📌 Что часто представляет продакт когда речь идёт о видении продукта? - Roadmap на год вперёд в Jira, MS Project, Wrike, Excel (нужное подчеркнуть)? А между тем - это прежде всего про пользовательский опыт и мечту. Текст с примерами того, как выстроить видение для продактов и владельцев продуктов

SAFe'вые вопросы

Истёк 4й месяц как запустили SAFe в компании и заканчивается 3й Program Increment.
 
Возможно есть среди подписчиков те, кто задаются схожими вопросами на старте масштабирования поэтому решил поделиться. Во многом с ответами мне помогли разобраться эксперты SAFe: Сергей Рогачёв, Алексей Ионов и плотный нетворкинг на Agile Days '23. Но важно, чтобы ответы искались отталкиваясь от контекста твоей организации.
 
❓ Сколько уровней SAFe нужно внедрять? Все? Один? (мы стартовали до уровня "Solution" включительно, но сейчас он видится 5м колесом в телеге)
🤲 Начинать можно с любого числа уровней и выстраивать следующие по мере готовности менеджмента.

❓ RTE (Release Train Engineer) - это больше эдакий Grand Scrum Master или Руководитель проекта?
🤲 RTE ближе к РП, чем к SM, а ещё вернее ближе к Delivery Manager (недавно, кстати, у Лёши Пименова вышло видео с интервью от первого лица работающего в этой роли). Почему так? Потому что SM отвечает за процесс работы кросс-функциональной команды. В этом смысле SM не очень сочетается с ролью RTE, т.к. состав ART может меняться походу движения в SAFe, поэтому достаточно сложно выстраивать процесс, когда команда непостоянна на дистанции и у неё может меняться фокус в направлении своего движения.

❓ Обязательно ли нужно внедрять enablers как элементы системы, если логика enablers заложена в других элементах: тасках, спайках, арх задачах и т.д?
🤲 Самый спорный ответ, но тем не менее. Enablers нужны для того, чтобы на всех уровнях бизнеса не объяснять ему как раз детали всех сопутствующих типов задач, а послать в тот самый САЙТ. В итоге всё зависит от того, а насколько эджайловая у вас организация? - Уровень maturity наших стейков таков, что они в теме разрабатываемых элементов, поэтому пока отказались от энейблеров.

❓ Кто должен приходить на System Demo: Business Owners или ТОПы? И как завлечь ТОПов, если их участие очень дорогое, да и не сильно хотят участвовать (при этом нам это нужно, т.к. пересекаются зоны их управления и необходимо работать с конфликтом интересов)?
🤲 Можно начинать с ключевых стейкхолдеров, коими являются BO и потом постепенно привлекать заинтересованных ТОПов, но не всех разом. Можно сделать несколько System Demo по бизнес-направлениям (например: продажи, закупки, бэкофис и т.д.)

❓ Может ли Business Owner быть ИТ-бизнес-партнёром (эдаким Grand PO)?
🤲 Может, но у него должна быть мотивация (по-простому: получать бонус от того, что он участвует в развитии своего бизнес-направления). Если BO выполняет функцию передающего в команды звена того, что хочет ключевой стейкхолдер или ТОП, то фактически к нему приходят не с проблемой, а с решением, что сильно сужает его возможности в реальный вклад развития бизнеса со стороны ИТ команды.

Весело едем дальше🚅

​​#непропроекты работа на конфе
 
Люди, которые на конференциях не только слушают доклады существуют!
Предлагаю чек-лист как действую сам с первой конференции (ITSMf в 2011) и помогаю другим коллегам эффективно работать с профильными конференциями.
 
☑️ определить зачем тебе участвовать?
🏃не бывал ранее
🏃компания платит, что ж мне отказываться?😏
🏃виски-пати
🏃нетворкинг
🏃потребность узнать что-то новое
🏃решить проблемы, с которым сталкиваешься в работе

☑️ если едет команда - сделать общий чат в телеге, где нужно обсуждать дальнейшие пункты. Мы обычно делаем файлик в облаке для общей работы с ним до/во время/после конфы (пример в аттаче)

☑️ узнать кто спикеры, какие будут темы, и главное: какие проблемы, возникающие в твоей деятельности могут быть закрыты благодаря посещению конференции

☑️ если мероприятие проходит в формате параллельных активностей, то заранее сформировать уточнённый список докладов/воркшопов на которые хотите сходить (на самом мероприятии на это часто не остаётся времени)

☑️ подготовить какие вопросы и с кем из спикеров/участников ты хочешь проработать

☑️ иметь "план Б", если что-то пойдёт не так, а всегда идёт🙏! (например, на последней конфе не приехало 2 спикера, с которыми планировал обсудить LeSS, а один интересующий доклад просто сняли с ростера)

☑️ поделиться результатами с командой. После конференции мы обязательно собираемся вместе и делимся что полезного успели обсудить во время нетворкинга и других активностей

☑️ применить полученные знания внутри компании через план "кто - с кем - когда - ожидаемый результат"

☑️ профит!

А какая была ваша первая профильная конференция🛫? Было интересно/полезно? Делитесь в комментариях🙏

И снова про T-shape и доверие

Классный пример работы T-shape команды показала недавно Metallica на шоу Goward Stern.
Ребята рассказывают пример того, как создавался их самый известный риф для "Enter Sandman"🎧.

Как Кирку Хэммету (🎸) в 3 ночи пришла в голову идея риффа, а Ларс (🥁) предложил: "а ты можешь добавить сюда ещё это и вот это?" Забавно, что ребята даже дали название тому, что они придумали: "3 повторения с хвостом".

Ларс не умеет играть на гитаре, но он сказал Хэтфилду (🎸): "сделай аранжировку того, что придумал Кирк, но в другой тональности!

Хэт говорит: "что я бы этого не сделал, я бы даже не додумался до такого, потому что я не делал такого элемента игры в принципе!" Но при этом он ответил Ларсу: "Хм, я никогда это не делал, но дай мне 1 день, я немного поработаю над задачей и вернусь с проверкой твоей гипотезы".

В команде нет места такому - "это моя гитара, не рассказывай мне как на ней играть!"
Ларс: "Когда мы погружаемся в написание песен, мы оставляем наше эго за дверью" - это же звучит просто как слоган для командной ретроспективы!

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

Как часто мы слышим вопрос (особенно начинающих команд) как я могу оценивать разработку я же тестировщик??? Как я могу оценивать аналитику я же разработчик??? Когда у вас есть единая цель - создать классный продукт, когда все вовлечены и УВЛЕЧЕНЫ этой идеей, то не будет стоять вопрос "как я могу?" - будет вопрос - "а что я могу сделать чтобы тебе помочь?"

❗️ P.s. а для тех, кому нужно обличить субъективные показатели доверия в math-friendly делюсь статьёй, которой поделились сегодня со мной☺️ Интересно как оказывается можно вывести уравнение доверия.

​​#пятничныйюмор или нет🤔😂

Наконец-то решена извечная проблема фасилитаторов на онлайн-встречах по поводу "хочу/не хочу включать камеру!"😂 Не знаю как насчёт другого софта для видеовстреч, но в MS Teams добавили функцию аватаров, которые можно активировать не включая камеру! При этом аватары достаточно реалистично подстраиваются под то, что говорит человек. Отличный компромисс для тех, кто не готов включать камеру.

+ 1 новый айсбрейкер для тех, кто пробует эту фичу впервые👍

Геймифицируй

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

Его проект заключается в том, чтобы считать ключевые показатели и "важнейший KPI".
Ключевые показатели достаточно базовые для тех, кто знаком с проектным менеджментом от PMI:
🕐 SPI (Schedule Perfomance Index) - насколько мы в сроках проекта
💲 CPI (Cost Perfomance Index) - насколько мы попадаем в бюджет
👨‍💻 Useful Time - насколько утилизируется время непосредственно на работу с тасками, а не встречи, youtube, бла-бла и прочий waste.

💎 Важнейшим KPI он определил - количество инноваций, которые будут реализованы и востребованы конечными пользователями (да, в составе команды в том числе продакт, который делит успешность запуска потенциальных инноваций наравне с командой разработки)

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

В процессе изучения попалась занимательная статья про долг по Velocity (раньше даже не сталкивался с таким термином, не Velocity конечно😁, а долгом по нему). Пусть статья "продающая", но она стимулирует подумать о таких интересных показателях как:

📌 Годовой оклад команды (надеюсь, считают все, кто задумывается об эффективности работы команды)

📌 Opportunity Cost Ratio - ценность, которая производится сотрудником на единицу оклада, которая должна быть больше, чтобы оправдать найм (а это уже интереснее)

📌 Накладные расходы на долг по Velocity (% времени, который можно было бы потратить с долга по Velocity на создание новых фич, которые несут ценность)

У кого-то был опыт геймификации процессов в компании? Поделитесь опытом, если так.