​​Dreamteam или как добиться немыслимых результатов?💪

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

Пару лет назад в нашей компании была команда поддержки систем 1С, которая использовала приоритизацию по принципу: в первую очередь "тушим пожар и принимаем роды", а остальное по приоритету FIFO😱🤯

🌀 11 конфигураций различных продуктов семейства 1С
🌀 Тонны поддержки
🌀 Факапы сроков (горизонт планирования доработок мог исчисляться годами)
🌀 Рассинхрон приоритетов
🌀 Не масштабируемость продукта

Может ли при таких вводных команда, внедрив у себя Скрам, 50 спринтов подряд (2 года) перфомить без факапов, т.е. иметь >90% выполненных задач и "А+++" burndown chart?🤨

- "Может"!🤩🥳

У команды 1С в среднем задачи каждого спринта выполнены более, чем на 98%. Кто-то скажет, что ну не 100 же?! А вы возьмите несколько целей не в одиночку, а группой людей и каждые 2 недели в течение 2 лет подряд попробуйте выполнять их с показателем в 95+ %

Формула успеха:
🍹 Верно подобранные участники команды (ключевой пункт за что спасибо нашему HR)
🍹 T-shape и матрица компетенций
🍹Работа с ожиданиями стейкхолдеров у владельца продукта
🍹Качественная проработка задач на PBR
🍹Ребята не соблюдают ценности Agile - они ими живут!

🤔 Может не хватало вызовов и команда просто специально брала нужное число сторипойнтов? - нет: они выросли с 70 до over 100 сторипойнтов за 2 года, применив больше 50 улучшений для своего процесса. Кроме того выросла число поддерживаемых баз с 25 до 38 с сохранением состава команды и, при этом, не выгорая в процессе работы.

По-прежнему остаются пути для роста:
🎓 Шэринг знаний
🎓 Развитие навыков
🎓 Инспекция и улучшение качества работы пула продукта 1С
🎓 К тому же сейчас команда входит в легкий storming (приходят новые участники, уходят старые) - важна гармоничная интеграция приходящих тиммейтов


Этот пример демонстрирует, что скрам прекрасно себя чувствует в разработке 1С и команда задаёт высокий уровень эффективности, при этом следуя принципам и ценностям Agile.

​​Выходишь с ретро и приходишь к выводу, что у команды ещё до начала спринта нет шансов на успешность улучшений. И это связано не с отвлечениями команды, отсутствием участников или плохим планированием, а с реакцией на возникающие проблемы

Понятно, что вся философия Скрама базируется на инспекции того, что пошло не так и при существовании проблем команда должна бросить все силы на их решение. Но бывают изматывающие спринты и команда даже справляется с инспекцией, но при этом есть нюанс который отличает такую команду от супертоповых!🦸‍♂️🦹‍♀️

Участники вообще ничего не придумывают для адаптации. Совсем. Ну, то есть они придумывают: "делать лучше тестирование", "повысить качество продукта" и т.п. Но как это измерить? Как понять, что мы стали лучше? Кто выполнит этот шаг? Просто надеются на другого участника DevTeam, PO, SM (подчеркнуть нужное)

Что же мешает команде выстроить баланс в поиске проблем и их адаптации?🔍

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

Чтобы становиться лучше нужно всего 5 моментов:

📌 Доходить до этапа формирования улучшений на ретроспективе
📌 Оставлять для этого достаточно времени
📌 Формировать шаги, которые можно измерить через промежуток времени (в идеале по SMART, но не обязательно)
📌 Назначать ответственного за улучшение
📌 Делать улучшение

5-й пункт не случаен. Как говорил друг создателя "Что, где, когда", чтобы решить задачу, нужно:

🔸Хотеть решить задачу
🔸Верить, что решение возможно
🔸Понять, что мешает решению, то является помехой
🔸Увидеть в помехе путь к решению
🔸РЕШАТЬ ЗАДАЧУ

Верификация улучшений - лучший показатель эффективности командной работы на ретро.

​​Кризис - поиск возможностей

У вас бывали ситуации когда вы, как говорят англичане, "on the ball", можно перевести как "на коне"💪 и тут в один миг всё идёт крахом!😰 К примеру компания заключила выдающийся контракт, но разбежались люди, которые должны его выполнять или уходит ключевой менеджер, который привёл клиента и всё держится на нём.

Из недавнего такого события итальянский футбольный клуб "Интер" чемпионом, а спустя пару дней стало известно, что из клуба уходит главный тренер, приведший команду к чемпионству впервые за 10 лет. Сумасшествие!!!🥺 Но всегда есть череда событий, которая приводит к определённым последствиям. В случае футбола - это коронавирус и пустые стадионы, банкротство спонсоров, снижение доходов. В случае компании - хантинг менеджера, команды, неверная стратегия развития продукта или реализация проекта.

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

За аксиому важно принять:
✍️ Всегда можно сделать ситуацию лучше, чем она есть сейчас - асимптота мастерства
✍️ Можно вынести уроки из полученного опыта
✍️ Нужно давать людям идею, а не деньги (по аналогии с автомобилем бензин (деньги) - это лишь средство достижения цели, а не сама цель)
✍️ Деньги для обеспечения базовых потребностей люди могут получить везде, в любой компании, а работать ради того, что тебя так драйвит: именно эта команда, именно этот продукт, эти ценности, которые разделяешь со своей компанией - это так просто не получить.

Понимая это любая подобная кризисная ситуация будет восприниматься как временные трудности.
И у команды / компании непременно будет дальнейший взлёт, но только с теми людьми, которые верят в то, ради чего они приходят и проводят (А НЕ ТРАТЯТ) своё время на работе.

В конце концов вариант выхода существует всегда. Как любят повторять в Agile сообществе "Меняй компанию или меняй компанию"😜😂

P.s. Бывший президент клуба «Интера», отреагировал с философским спокойствием: «Давайте наслаждаться прекрасной победой. Жизнь полна неожиданных поворотов. Иногда кажется, что изменения – к худшему. Но оказывается, что все стало только лучше».

🟦⬛️ цвета клуба обязательно сменятся "белой" полосой, ведь идея и мастерство в этом клубе уже есть! Осталось вынести уроки из случившегося.

Чем обернулась миграция функционала из одного продукта в другой

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

👉 Спонсоры ожидали работающий продукт 9 месяцев назад, но дитя не родилось👩‍🦲❌. Впрочем, команды тогда ещё не существовало — дело рук подрядчика
👉 Стейкхолдеры хотят фичи здесь и сейчас
👉 Пользователи ожидали, что новая система будет "быстрее. выше. сильнее", чем старая
👉 Product Owner под колоссальным давлением со всех сторон
👉 А ещё ресурсы…даже без анализа эффективности потока работы (привет канбан - метод) команда видит, что разработка простаивает.

С помощью советов от других владельцев продуктов компании выделили шаги по улучшению в текущей ситуации:

🔥 Формировать реалистичные ожидания стейкхолдеров
🔥 Делегировать задачи по аналитике со стороны Product Owner в адрес командных игроков
🔥 Подойти к Data-driven решениям, а для этого обсудить с командой, как лучше считать ресурс и места простоя команды

Сейчас команде в сжатые сроки необходимо круто сменить вектор развития, чтобы улучшить имидж продукта. Входим в интересный этап. To be continued...

#новыйпродукт

​​Нетипичные шаги с Ретро или возврат "инвестиций" со временем

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

Вспоминается история о том, как в одном Британском соборе ⛪️ в конце 19 века прохудилась очень редкая сосна, из которой он был построен. Стали искать, где же добыть именно такую, чтобы восстановить собор. И нашли семейство, у которого во владении был высажен участок именно такого сорта деревьев. Как выяснилось, прапрадед этого семейства завещал, что "вы не продавайте участок…сосна рано или поздно прохудится (дед знал толк в инвестициях😜) и к вам обязательно придут за новой закупкой". Так и произошло спустя 2 поколения и семья озолотилась💲💲💲

Из таких изменений в наших командах мне с ходу вспомнились:
🔹 Предпланирование спринта с бизнесом - когда не хватает времени на Sprint Review
🔹 Ревью функционала - для работы с качеством продукта и регрессионного анализа
🔹 Внедрение инструментов матрицы скиллов и роста "T-shape" команды и т.д.

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

​​Маск не летал в космос потому что он не Б.......😂

За последние 3 недели двое владельцев частных космических компаний Брэнсон и Безос летали в космос🚀
Новая веха после событий 1961-1969. В 2021 возможность прокатиться за границу атмосферы стала доступна почти всем😉

Раз в "N" десятилетий происходит прорыв в технологиях: удвоение роста количества транзисторов на процессоре, снижение стоимости мили при владении авто (см. картинку), теперь - космотуризм спустя 60 лет после освоения космоса.

Всё это в макромире напоминает мне, как происходит развитие продукта:

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

Как ни странно - конфликт⚡️! Всё происходит через изменения. Как пишет Ицхак Адизес в своей книге: "покажите мне, где нет изменений и я покажу вам кладбище". Конструктивный конфликт ведёт к изменениям в сторону прогресса. Здоровая конкуренция - ведёт к коммерческим полётам в космос.

Но что стоит за этими полётами🧐? Брэнсон и Безос продают своим примером бизнес космического туризма.
Маск - продаёт нечто большее - недостижимую мечту о жизни на Марсе☄️

Глядя на картинку с авто, что думаете будет с космосом в 2081? Абонемент на полёты к ближайшим планетам? Клабхаус на Марсе? Услуги по клинингу космического мусора? Билеты на aviasales: можно выбрать прямой перелёт на Марс или с пересадкой на Юпитере😂

А ваш продукт про деньги или про идею?

​​"Открытый урок" или тренинг по тимбилдингу

Что вы представляете, когда слышите тимбилдинг? Поиграть в боулинг? Накидаться в барчике?
Иногда тимбилдинг - это в прямом смысле: "командное выстраивание"😉

Жила-была компания с 2 подругами из HR и всё шло хорошо, все найденные ими сотрудники становились их друзьями.🤝 И тут случилось, что бизнес резко стал расти, а отдел HR вырос. Да разросся так, что сформировалась целая группа людей. И мы решили помочь им узнать группа они или команда?

Стартовые проблемы:
🤷‍♀️ 2 лагеря: старожилы и новенькие сотрудники, пришедшие в компанию
🤷‍♀️ Неясная общая цель
🤷‍♀️ Конкуренция в работе
🤷‍♀️ Да и в целом сформировался вопрос: "а нужна ли нам команда и зачем"?


Тренинг прошёл по плану:
🔵 Проверка Тайминга:
🔹 работа не более 50 минут, чтобы сохранить активность и вовлечённость

🔵 Согласование правил:
🔹 чтобы все участники чувствовали себя максимально комфортно в рамках правил, которые они сами зафиксировали

🔵 Видение участников "Что такое команда и зачем она нужна"?
🔹 понять акценты в тренинге. Т.к. фактически были рамки мероприятия, но мы подстраивались под поведение участников

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

🔵 Дерево с чертами команды
🔹 правая часть дерева - сбор стикеров от всех участников с их представлением команды мечты

🔵 Дерево с чертами команды
🔹 левая часть дерева - а как выглядим мы? Какие черты ("+" / "-") у нас?

🔵 Приоритизация голосованием игродолларами за наиболее важные черты для нашей команды
🔹 в результате получилось денежное дерево — экспромт встречи за что я и люблю живые тренинги!

🔵 Шаги, которые нужно совершить, чтобы прийти к своей команде мечты!

🔵 Обратная связь о тренинге и настоящее шампанское🍾🥂 за успех команды виртуального корабля, отправленного в море рекрутинга, адаптации и много чего ещё.

Ах да, почему "открытый урок"?😂 Вспомнили школьную параллель, когда на урок учителя приходит завуч или директор🙂 Это было "боевое крещение" по проведению тренинг-сессии в нашей компании для нового скрам-мастера, с которым она блестяще справилась! (помним, что Скрам - это не только про DevTeam и PO, но и про то чтобы делать организацию лучше). Даша, спасибо!👏

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

P.s. Как приятный бонус вынесли тезисы про доверие и уважение, которые важны для команды:
🔹 Психологическая безопасность
🔹 Экологичная обратная связь
🔹 Умение слУшать, а не только слЫшать

Злоупотреблять VS пользоваться метриками

🔻 На прошлой неделе устроил себе city break. Гуляя по Москве в 7 утра, застал интересную картину: уличный клининг-персонал фотографирует часть улицы, где ею была произведена уборка.
🔻 А в ИТ сообществе на прошлой неделе произошёл медиахайп: уволили ~150 человек в компании XSOLLA "благодаря" полученной из бигдата информации о времени работы сотрудников. Вкратце потому что мало активничали в чатах, гугл почте, с тикетами и т.п., резюмируя не вовлечённостью на удалёнке. При этом в профиле компании в hh.ru заявлено, что "мы работаем на результат, а не процесс". Это в топку того, когда коллеги говорят в какую замечательную компанию их позвали работать! Фасад и начинка бывают разные.

Казалось бы, где тут связь?

Все считают метрики: поддержка считает SLA, команды разработки - Time-to-Market, менеджеры клинеров - чистоту улиц по фото.

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

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

💬 Автор одной книги оказался в Нью-Йорке и решил поужинать в фешенебельном французском ресторане на Манхэт­тене: вазы с цветами официанты во фраках. Посетитель признался официанту, что смущен роскошной об­становкой, и что на все у него есть только сто долларов, включая чае­вые. Что он даже не может прочесть меню, написанное от руки по-фран­цузски, и попросил принести ему лучший ужин из возможных на сто долларов. Ужин, который ему устроили в тот вечер (несколько блюд, постоянное напол­нение бокала и уважительное обслуживание) стоил явно дороже того, что он мог предложить. Он представился "нищим", а ему оказали наилучший сервис.

❗️Мне видится, что надо гнаться не за метриками, а выстраивать доверие к сотрудникам, мотивируя их через цели, через приверженность к ценностям компании. Культивировать желание сделать чуть больше для клиента, чем он даже заслуживает.

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

P.s. А про XSOLLA мы видим лишь вершину айсберга. Вполне возможно, что компании надо было срочно срезать "косты" из-за неудовлетворительных финрезультатов, а как известно, самые объёмные расходы компании - ФОТ сотрудников. Так что бигдата…ага-ага😏🤓… Но это из разряда теории заговоров🤪

#доверие #мотивация

​​Как выбрать "сторону": люди или технологии?

Мы стараемся работать командой и если ценности разделяются, а цель значима — то команда эффективна💪
Но в пользу чего сделать выбор каждому внутри себя: технологии или люди?🤔

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

Если поступает такой запрос, анализирую не hard- и даже не soft-skills человека, а пытаюсь выяснить кто он или она?👤

Интроверт или экстраверт? Любишь тусовки и быть в центре внимания или любил собирать пирамидку в детском саду часами? Да простят меня противники типизации, но мне близка структура, которую предложил А. Курпатов в своей книге "Троица". Если твой тип шизоид (например, Стив Возняк) - то иди работай с системами, если невротик (Билл Гейтс) - то создавай системы взаимодействия с людьми, если истероид (Стив Джобс), то взаимодействуй с большим числом людей и создавай невероятные продукты и команды, работающими над ними. Многое, но не всё зависит от того, что в нас изначально заложено природой🧬

Есть английское выражение "nature VS nurture" - врождённый талант🧘‍♂️ или воспитанные качества🧗‍♂️ Можно пытаться вырастить в себе любовь к системам, если тянешься к людям или, наоборот, любителю коммуницировать погружаться в устройство печатных плат, но переделав своё нутро, добившись результатов, получишь ли ты настоящее удовольствие? Стоит того потраченное время?

Я несколько лет работал системным администратором, прежде чем понял, что моё - это работа с людьми и ушёл в область проектного управления и в Agile.

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

Знаю примеры, когда человек сразу после вуза работал менеджером 10 лет, а потом попробовал кодить и испытал нереальный кайф! Теперь пошёл по этой ветке. Так что любой, даже идущий путём проб и ошибок, может, при желании, свичнуться из менеджера в fullstack-разработчика. Главное — понять свой тип⁉️

А какой тип ты?

Дело в менталитете или мировосприятие?🤔

Общался с другом, который работает разработчиком в американской компании в составе команды по фреймворку Скраму

Типичное дэйли:
"Сидят латыши говорят на латышском🇱🇻, приходит русский developer, сразу переходят на русский🇷🇺, далее через пару минут присоединяется португальский веб-дизайнер 🇵🇹 - сразу все переходят на английский. Разговорный Alt+shift🏴󠁧󠁢󠁥󠁮󠁧󠁿 срабатывает как, само собой, разумеющееся. Причём неважно идёт разговор по рабочим вопросам или small talk перед началом основной повестки. Надо ли добавлять, что, конечно, все с камерами?🥳

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

#agile #скрам

​​Личное мнение важнее командных ценностей?

Доводилось сталкиваться на встречах, что команда никак не может прийти к консенсусу по техническому или организационному вопросу. Продолжать "давить друг на друга" - путь в никуда. Каждый при своём мнении.

Я использую два способа выхода из спорной ситуации:

⭐️ на уровне команды возвращаюсь к командным договорённостям, если это не помогает, то джокером выступает призыв к принципам и ценностям Agile и Скрам. Не случалось ситуаций, чтобы участники наплевательски относились к ценностям, какого бы уровня ни достиг спор.

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

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

#скрам #agile #конфликты

​​Личный тайм-менеджмент #непропроекты

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

Недавно вернулся из отпуска и начал этот "славный" путь в почте и рабочих чатах. С чатами проще: смотришь, где тебя тегнули лично и отвечаешь на эти запросы, если не сделал это в отпуске. Остальная информация, как с пропущенными новостями, непременно дойдёт вновь от команды. Но что делать с 300+ письмами?

Я давно выработал для себя правило приоритизации писем:

👉 Делегируемые - те письма, задачи в которых можно поставить на исполнение подчинённым, коллегам, командам или даже руководителям.
❓ Уточнения - лучше через ответное письмо, т.к. в письме мы склонны лучше структурировать подачу информации, чем голосом на встрече
💬 Информационные письма (спам, рассылки, FYI и т.д.), которые можно просто скипнуть прочитанными
⚠️ "Срочные и неважные" письма - запланировать в календаре встречи на ближайшую неделю
❗️ "Важные и несрочные" письма - метка в задачи в outlook/gmail и.т.д
‼️ "Срочные и важные" письма - уделить оставшиеся половину первого рабочего дня этим вопросам

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

P.s. хотя есть подход проще, который практиковал мой напарник - "пометь прочитанным все письма. кому очень надо вернутся к тебе"😜 немножко цинично и игнорно, но тоже возможный путь и гораздо быстрее моего😏😉

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

А у вас есть лайфхаки работы с пропущенной информацией после отпуска?

​​2 правила MVP

Руководитель проекта вертится в треугольнике сроков, скоупа и денег. Это отлично работает, если не подразумевается запуск нового продукта, который не предусматривает MVP. "Но всё меняется, когда приходят они"🤪

15 лет назад я впервые попробовал грузинскую кухню в ресторане. Это сейчас с лёгкостью эксперта я смогу объяснить разницу между аджапсандали и оджахури или тонкости того, чем мегрельское харчо отличается от супа харчо. Тогда же в меню - это были дивно звучащие слова на русском языке🤯

Но вот, что главное: я не помню, что я заказал, но помню, что мне - это понравилось!🤩

Эта мысль натолкнула на 1️⃣-е правило: когда запускается MVP не столь критично важно, чтобы в функционале программы сразу становилась доступна killer-фича. Необходимо добиться того, чтобы хоть и ограниченный функционал, который мы предлагаем пользователю работал максимально качественно.

Пусть он не узнает всех "блюд", но захочет вернуться снова и снова, и снова.

Проблема в том, что попадаются вредные посетители (читай Заказчики), а клиент - всегда прав. И в "идеальном блюде" MVP такой человек найдёт к чему придраться. Отсюда 2️⃣-е правило: саботёры известны заранее на этапе реализации проекта. Необходимо выстроить с ними грамотный диалог, заручиться коалицией вышестоящего спонсора, либо снизить влияние такого заказчика к минимуму на момент запуска MVP.

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

Вот такая кухня😏

#projectmanagement

Прыгни выше головы! - стать лучше - возможно!

Пройденный руководительский тренинг помимо прочей пользы побудил прочесть книгу Маршалла Голдсмита "Прыгни выше головы! 20 привычек, от которых нужно отказаться, чтобы покорить вершину успеха".

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

📌 Некий добрый человек сделал отличную СХЕМУ - выжимку из книги, но для полного понимания всё же рекомендую ознакомиться с книгой.

P.s. Провёл среди коллег опрос по своим привычкам и открыл для себя инсайты, о которых не догадывался. Выявленные проблемы - путь к улучшениям, чего и вам искренне советую!

❗️ P.p.s Если кому-то нужна книга в pdf или в аудио-формате пишите в личку.

Вакансия для любознательного лидера или желающего им стать😉

Привет! Возможно вы, ваши друзья или знакомые в поисках роли скрам-мастера!

У нас есть все условия, чтобы реализовать такие амбиции.

⚡️ 2 команды для работы (в стадиях "Storming" & "Norming" по Такману)
🕋 2 разных, но интересных продукта
✌️ 2 agile - эксперта для обмена опытом
3️⃣ года компания практикует Скрам в соответствии со Scrum Guide
🤝 всесторонняя поддержка Agile со стороны руководства
🏄‍♂️ для нас agile - это mindset, а уж потом различные практики и инструменты
💫 мы руководствуемся слоганом: "Эта работа сделает тебя счастливей!"

🤔 Больше о вакансии можно узнать кликнув ТУТЪ😊

💬 Для связи писать nastya_astr

🙏 Благодарен за репост в лички заинтересованным и в профильные каналы.

В продолжение поста про статистику хорошая статья: http://ronlichty.blogspot.com/2021/04/measuring-productivity.html

Краткое summary какие метрики использовать для команд:

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

​​Убрать нельзя оставить

На отдыхе я люблю готовить из местных продуктов и первое что делаю, когда арендую жильё по airbnb - это покупка в ближайшем магазине острого ножа. Хозяева обычно пекутся об исправном душе, чистом постельном белье и доступном wi-fi, но точно не о заточенных ножах🔪🔪🔪
Конечно можно приготовить блюдо и с тупым инструментом🤷, но сколько на это уйдёт времени, потерянных нервов и каков получится результат одному Будде известно⛩

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

Дьявол в деталях… команда в скрам находится в операционном потоке разработки и время взглянуть и порефлексировать возникает только на ретро. Скрам - мастер может подмечать и подсвечивать то, что в пылу работы незаметно для команды, он обязан интересоваться best-practice с точки зрения практик и инструментов, делиться этими знаниями с командой и выступать медиатором всевозможных ситуаций от командных конфликтов до чествования командных побед👂👀 🤲

Если есть желание быть на острие эффективной разработки по скраму - выделенный специалист в этой роли крайне необходимый элемент системы.

Без "хорошего ножа" будет: устали очень тяжело второй год не получается в скрам ничего🤪