Борода продакта
Управление проектами
Подписаться
Product Growth.

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

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

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

Драйвер роста
- это показатель/метрика, увеличение которого увеличивает метрику North Star продукта и, как следствие, прибыль компании. Не все метрики являются драйвером: если у нас есть интернет-магазин, то увеличение количества регистраций не увеличивает оборот, соответственно, не является драйвером роста. Для выделения метрик, которые в конечном счёте превращаются в North Star описывается цепочка формирования прибыли. С этим помогают модели юнит-экономики или построение воронок конверсий.

После выделения драйверов роста начинается этап формулирования гипотез роста и проведения экспериментов. Важно понимать, что эти эксперименты не всегда являются minimum viable feature, а могут представлять собой механики маркетинга, продаж или качества обслуживания. Рост продукта не всегда и не столько зависит от фич. Вспомним, хотя бы модель 7P.

Успешно проведенные эксперименты со временем складываются в систему, которая является основой для формирования стратегии роста / развития. Эта стратегия позволяет составить логичный roadmap продукта на этом этапе, который привносит осознанность в приоритезацию требований на фичи.

В любом случае на этом этапе продукт переживает "взрыв" макро и микро фич, которые в нем появляются. Скелет MVP наращивает себе мясо, превращаясь в полноценный продукт. Главное, чтобы вместе с мясом продукт не нарастил себе жир
- бесполезные фичи, которые не влияют на North Star, т.е. е увеличивают ценность продукта. Именно поэтому так важна последовательность и осознанность при поиске доказательств необходимости в той или иной фиче. Иначе можно испортить фигуру.

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

P.S. Об этапе роста и поиске точек роста (growth hacking) в России заговорили активно только в последние два года. Да и с точки зрения мирового опыта это наименее изученная и скудная на модели область управления продуктами. Возможно, потому что здесь больше product marketing, чем product management. Так или иначе, это отличная сфера, в которой хочется видеть много новых открытий.

Другие статьи канала Борода продакта

Борода продакта
Управление проектами
Подписаться
Product Discovery.

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

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

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

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

Подтвержденная гипотеза ценности и сбалансированная бизнес-модель приводят нас к product / market fit, только после нахождения которого есть смысл говорить о формировании MVP для тестирования гипотезы решения по донесению ценности до конечного клиента. MVP вовсе необязательно должно быть IT-продуктом в каком-либо своем виде и может включать простой лендинг с бекендом из Зиночки для обработки заявок.

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

Профессионализм управления продуктом на этапе Product Discovery заключается в том, чтобы минимизировать time to market с минимизацией рисков нахождения product / market fit.

P.S. Практически все развитие продуктового менеджмента за последние пятнадцать лет было нацелено на поиск ответа именно на эти вопросы
- как сделать продукт, который нужен клиентам.

Борода продакта
Управление проектами
Подписаться
Аксиома четвертая.

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

Чтобы внедрить продукт, нужно его сначала создать. Не в том смысле, что разработать, а в смысле "discovery"
- процесс формулирования и проверки гипотез проблемы клиента, ценности, бизнес-модели, решения и т.д., в результате которого рождается mvp. Риски здесь заключаются в том, чтобы не придумывать что-то из головы, а последовательно уменьшать конус неопределенности до того момента, пока все кусочки не будут органично связаны друг с другом для нахождения product / market fit. Основной вопрос стратегии
- как выйти на рынок, чтобы начиная с ранних последователей получить и инноваторов получить ранее большинство.

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

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

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

О каждой из этих четырех фаз я расскажу подробнее на следующей неделе.

Борода продакта
Управление проектами
Подписаться
Аксиома третья.

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

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

В отличие от компании, целью которой является прибыль, целью продукта является закрыть те потребности, которые есть у клиентов. Шаверма закрывает потребность быстренько поесть. Jira закрывает потребность автоматизации процесса разработки. Дрель закрывает потребность повесить на стену картину. Способность продукта достигать своих целей определяется некоей метрикой, отличной от метки доли рынка компании. Сейчас её принято называть метрикой North Star
- чем она лучше, тем лучше потенциал продукта по решению проблем клиентов и, как следствие, получения компанией прибыли.

Важным моментом для восприятия этого положения является то, что продукт не обязательно должен быть объектом продажи, чтобы закрывать проблемы клиентов. Простой пример
- любой ecommerce-проект (Aliexpress, Amazon, Ozon, Ulmart, Booking и т.д.). Клиенты не покупают сам сайт, объектом продажи здесь является товар, размещенный на этом сайте. Однако, сам сайт решает проблему клиента, чтобы купить этот товар быстрее и с лучшим пользовательским опытом, чем поход в магазин. К тому же, если это не так, то чем же тогда занимаются полчища продакт-менеджеров этих проектов?! :)

Одним из краеугольных камней преткновения является тезис "продакт должен отвечать за деньги, если это не так, значит он не продакт". Приведенная аргументация разрешает это противоречие. Если продукт является объектом продажи, то скорее всего продакт менеджер это продукта будет отвечать за деньги, если нет
- то это находится вне фокуса его влияния. Но в обоих случаях продакт менеджер обязан отвечать и развивать north star метрику продукта, чье развитие и повлияет на получение прибыли компанией.

Борода продакта
Управление проектами
Подписаться
Аксиома первая.

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

Аксиома вторая. Форма любого бизнеса определяется его миссией.

В четвертом веке до нашей эры философ Архит доказал бесконечность Вселенной высказыванием: "Предположим, я подошел к границе мира. Если теперь я протяну вперед палку, во что она упрется?".

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

Например, текущая миссия Microsoft звучит как "Microsoft – технологическая компания, задача которой – дать возможность каждому человеку и каждой организации на планете достичь большего. Наша стратегия состоит в том, чтобы создавать лучшие в своем классе платформы и сервисы производительности для интеллектуального облака и intelligence edge, наполненного искусственным интеллектом." Это отличается от сформулированного им в 2006 году послания "Наша миссия – помочь людям и бизнесам по всему миру осознать свой потенциал. Достичь этой цели нам поможет технология, которая изменит то, как люди работают, играют и общаются.". И, уж тем более, от старого "Компьютер на каждый стол и в каждый дом.".

Именно миссия, которой предшествует некоторая идея, является фактором, определяющим форму бизнеса. Если ваша миссия
- открыть ларек с шавермой, у вас будут одни границы, в рамках которых вы реализуете свой потенциал. Если ваша миссия состоит в том, чтобы стать "Life Style Banking" компанией, как Тинькофф, или компанией, решающей городские транспортные проблемы, как Uber, то и коридор ваших возможностей совершенно другой. Ваш майндсет становится совершенно другим, что влечет за собой смену фокуса, приоритетов и стратегии развития. Старая формула "Думай иначе" не прекратит быть актуальной никогда.

Борода продакта
Управление проектами
Подписаться

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

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

С другой же стороны, наши рассуждения могут привести к парадоксам, т.е. истинным ситуациям, для которых нет логического объяснения в рамках выбранной теории. Например, как экономическая теория рационального выбора Адама Смита дошла до своих пределов в виде новых теорий иррационального выбора, представленных в трудах Ричарда Тайлера, Даниэля Канемана и Вернона Смита.

Я использовал фразу "дойти до предела", т.к. она важна для понимания, что у любой системы рассуждений есть свои границы. Другими словами, любая формальная теория либо включает в себя ложные высказывания (является противоречивой), либо содержит парадоксы (является неполной). Парадокс здесь
- это некое высказывание, которое нельзя ни доказать, ни опровергнуть в рамках данной формальной теории. Для того, чтобы разрешить парадокс, необходима более сильная теория, включающая в себя первую плюс набор новых аксиом. Этот как создание Agile Манифеста, который положил основу для разрешения проблем, связанных со скоростью разработки, введя в теорию проектного управления четыре аксиомы приоритезации.

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

Начну свой рассказ с выделения аксиом.

Борода продакта
Управление проектами
Подписаться

Где-то месяц назад я заново посмотрел на весь тот фидбек, что собрал по фреймворку, структурировал его и получил именно картину, которая подтверждала его целесообразность. Вместе с тем, проблемы, которые помогает закрыть paf, глубже, и только той красивой систематизации, что сейчас отображается на сайте, явно недостаточно. Фреймворку не достаёт фреймворковости. Собственно, последний месяц я и потратил в попытках сформировать более сильную теорию, чем просто текущий набор моделей. И кажется, у меня это получилось
- собрать из разложенных ранее кирпичиков здание. В последующие пару недель я буду рассказывать сказку о фреймворке.

Борода продакта
Управление проектами
Подписаться
Да, и еще одна важная новость.

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

Борода продакта
Управление проектами
Подписаться
В последнее время много общаюсь со всеми по PAF.

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

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

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

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

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

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

Борода продакта
Управление проектами
Подписаться
Для мобильных продактов может оказаться полезна эта подборка с инструментами от AppSee:

аналитика, тестирование, привлечение, монетизация, вовлечение, фидбек и многое другое.

Борода продакта
Управление проектами
Подписаться
Коллеги, все привет.

Раскрою тайну, почему так мало было полезного за последний месяц
- я участвовал в подготовке интенсива по работе с воронками конверсий для UX-специалистов. И это неспроста, ведь мы ищем UX-стажера на внешние и внутренние проекты. А когда стажер действительно подходит компании? Когда он обучается на кейсах компании. Поэтому вместе с UX Boost мы вместе готовили интенсив максимально набивая в него кейсы LAF24 и те подходы к проектировани и аналитике, которые мы используем. С учетом моей любви к структурности, интенсив получился весьма методологичным. В конце команда даже сокрушалась, что в нём мало воды. Почему собственно именно воронки? Потому что именно они пмогают найти те бутылочные горлышки в интерфейсе (и не только), оптимизация которых принесёт бизнесу наибольшую пользу. Этот интенсив нацелен на то, чтобы сместить фокус UX-специалистов с проектирования интерфейсов на бизнес-составляющую и измерение результатов изменений, которые они вносят в продукт.

Занятия начнутся 17 ноября и будут идти по субботам и вторникам. Группа будет небольшая (12 человек), преподавателей будет двое: Глеб Долгов (Head of Product Design в БигДатаТехнологии, работал в Рамблере и Mail.ru) и Иван Серебренников (Chief UX officer в DSX.uk, работал в EPAM и SEMrush.com, 15+ лет опыта в дизайне, автор канала UX Boost). Я принимаю участие с точки зрения ответа на вопросы и передаче обратной связи.

В программе:
1. Бизнес, бизнес модель и место сайта в бизнес-модели
2. Выбор метрика для бизнеса, типы бизнеса и на что может влиять дизайнер
3. Путь пользователя, основные типы сайтов, цели и триггеры
4. Как заставить разработчиков поставить цели в Метрику и их обработать
5. Визуализация воронки и конверсии, формулы и работа с таблицами
6. Линейные зависимости и сходящиеся воронки
7. Сегментирование по ролям, источникам, запросам и т.д., сводные таблицы
8. Интерпретация данных и ошибки в них

Данный интенсив
- один из планируемых в линейке обучения для UX-специалистов на реальных кейсах и методологиях. Курс будет полезен не только специалистам по работе с интерфейсами, но и дизайнерам, начинающим маркетологам, ecommerce-менеджерами и продактам в ритейле. Инжойте https://uxboost.school/

Борода продакта
Управление проектами
Подписаться

Кстати

Борода продакта
Управление проектами
Подписаться

В пятницу

Борода продакта
Управление проектами
Подписаться
Не так давно я узнал, что, оказывается, есть вторая версия всем известного Agile Manifest.

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

Почему старое
- неактуально? Потому что раньше, чтобы стать разработчиком, нужно было разбираться не только в структурах данных и алгоритмах, но и немножко сечь в архитектуре. Порог входа был в специальность был намного выше, чем сейчас (почти 20 лет назад): инструментарий языков был беднее, фреймворков было меньше, технологии были сложнее, чтобы изучать тему, приходилось вникать самому или общаться на форумах. В таких условиях хороший разработчик действительно был "высокомотивированным специалистом", который должен уметь взаимодействовать с такими же, как и он, профессионалами. Но сейчас порог входа другой. Рынку нужно больше разработчиков, чем есть в наличии, появилось куча курсов, школ и программ обучения, где все разжевано. Иногда до такой степени, что молодым программистам кажется, что они детально владеют ситуацией, что реальные задачи будут сильно схожи с примерами обучения. В итоге, мы сейчас рынок получил кучу зелёных юнцов, которые хотят дохера, а умеют нихера. Кстати, сейчас подобная ситуация кажется похожей и среди продактов.

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

Да и сами команды теперь нужно трактовать намного шире. Это уже не просто совокупность разработчиков, тестировщиков, архитекторов или других технических специалистов, но м продактов, маркетологов, ux специалистов, аналитиков и т.д. Потому что подход к построению продуктов стал другим по причине пункта
2.


2. Бизнес ценность важнее работающего продукта

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

Однако, это хорошо работало, когда на рынке потребность в IT продуктах была выше, чем их предложение. Когда не хватало даже необходимых приложений. Концепция minimum viable product
- тоже часть этой эпохи, когда ваше "быстренькое" решение должно было проверить гипотезы необходимости тех или иных фич, чтобы долго не лабать никому не нужный продукт.

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

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


3. Развитие партнёрских отношений важнее сотрудничества с клиентом

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

Борода продакта
Управление проектами
Подписаться
перманентном состоянии разработки, так и не достигнув собственных целей.

Партнёрские же отношения подразумевают ситуацию "win-win", когда обе стороны достигают поставленных перед ними целей. Как своих собственных, так и совместных. Смотрели фильм "Игры разума"? Там как раз был эпизод про этот принцип, именуемый равновесием Нэша.
4. Готовиться к изменениям важнее реакции на изменения

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

Вспомним историю. Когда ПО строилось по "изначальным планам", выраженным в скучных технических заданиях, его разрабатывали долго. Но знаете... Оно работало! Оно реально работало. С переходом на гибкую разработку, реагирующую на изменения, мы получаем продукты быстрее, но их качество оставляет желать лучшего. В итоге ПО, разрабатываемое таким образом, довольно быстро доходит до пределов возможностей своей бизнес-логики, утопая в техническом и архитектурном долге. После чего приходится пилить новый продукт, который бы решить проблемы старой системы. Тем самым та пресловутая гибкость, о которой говорится в манифесте, оборачивается жёсткими ограничениями в развитии.

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

Борода продакта
Управление проектами
Подписаться
Коллеги, доброе утро.

Мне вот тут совершенно справедливо говорят, что я совсем охренел, мало пишу и скидываю в основном "рекламу". К сожалению, так оно и есть. Сейчас основное время уходит на формирование и валидацию фреймворка, а это задача
- не просто пост в телеграмушку написать. Поэтому-то и отписываюсь очень редко. Но очень скоро я вывалю на сайт фреймворка много новой информации. P.S. Опять забыл сказать главное
- я все-таки тоже буду на Product Sense в Минске, можем пересечься при желании, познакомиться, пообщаться.

Рейтинг авторов

  • "Записки Дизайнера" (про дизайн и только про него 157 157 157
  • (Не) только немецкий 157 157 157
  • #анямастерконтента 157 157 157
  • #Фудтех 157 157 157
  • 10 идей и трендов дня 157 157 157
Показать весь рейтинг
Загрузка ...