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

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

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

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

Каналы в телеграмм, которые считаю интересными и полезными:

Продукты:
https://news.1rj.ru/str/pmdaily - интересные подходы к управлению высоконагруженными проектами

https://news.1rj.ru/str/dindex - посты, как выстрелы! для продактов самое - то!

https://news.1rj.ru/str/product_proverbs - истории из жизни продакта и как это находит отражение в работе

https://news.1rj.ru/str/pm_god - хорошие советы по продуктовому и проектному управлению

https://news.1rj.ru/str/productionpain - к сожалению не частая, но интересная инфа от продакта

Agile:
https://news.1rj.ru/str/inteamwetrust_rus - что команда, что организация начинается с доверия внутри коллектива. Алексей Пикулев один из лучших может рассказать про эту тему

https://news.1rj.ru/str/tw0_percent - интересные инсайты про Agile - тематику

https://news.1rj.ru/str/no_shame_facilitation - всё, что нужно мастеровитому фасилитатору знают Саша, Женя и Оксана

https://news.1rj.ru/str/condensedAgility - выдержки лучших обсуждений на тему agile из самого большого agile-сообщества в ТГ

https://news.1rj.ru/str/agile_coach_notes - полезные заметки от Agile Coach

https://news.1rj.ru/str/agilethinking - интересности из Agile

https://news.1rj.ru/str/myscrum - канал практикующего Скрам-мастера

https://news.1rj.ru/str/scrummasters - интересности про Agile и Скрам

Другие:
https://news.1rj.ru/str/antxt - Иван пишет очень необычные истории и погружает в вопросы аналитики различных вещей. Для ценителей вопросов аналитики всё очень интересно и второго подобного канала в ТГ точно нет! Советую!

https://news.1rj.ru/str/junior_pm - Артём погружает участников канала в особенности проектного управления и рассказывает про свой путь в этой области

https://news.1rj.ru/str/itSMFRussia - тема ITIL и сервис-менеджмента мне по прежнему близка и интересна, поэтому можно узнать, что происходит в ITSM среде

https://news.1rj.ru/str/pimenov_spoken - канал Алексея Пименова. Лидер Канбан-метода в России, жаль, что не часто пишет в своём канале

Удаление фич в продукте

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

Возможно, ЦЕННОСТЬ будет состоять в том, чтобы не добавить функциональность, а УБРАТЬ! Чтобы не тащить за собой эту "телегу камней", а сделать продукт более мобильным, современным, лёгким и интуитивно понятным для пользователей.

Когда стоит рассмотреть удаление уже имеющегося функционала в продукте:

🗑 Полное несоответствие стратегическому плану развития компании

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

🗑 Чересчур новаторский функционал (не пользуется спросом, непонятный)

🗑 Совсем нишевый функционал (не пользуется спросом)

🗑 Функционал больше не решает проблемы клиента

🗑 Излишнее резервирование - есть другой способ, который решает проблему клиента более лучшим образом

🗑 Несовместимость - попытка "скопировать" функционал с другого успешного продукта, но абсолютно не подходящий для нашего ("натянуть сову на глобус", да 😏)

🗑Чрезмерные затраты на поддержку имеющегося функционала как со стороны команды разработки, так и со стороны хелпдеска

Удаляли функционал из продукта за невостребованностью?

Про жизненный цикл Технологических революций и какое место в них может занимать Биткоин...https://stratechery.com/2021/the-death-and-birth-of-technological-revolutions/