Кризис как стратегический переломный момент
Только сейчас добрались руки до книги 📚 Эндрю Гроува «Выживают только параноики», который возглавлял компанию Intel в конце прошлого столетия. Да, книга не нова, но ее основные идеи фундаментальны и вполне актуальны и по сей день, та же модель М. Портера, которой пользуется Гроув. Модель подходит как инструмент построения стратегии как отдельного продукта, так и целой компании.
Что полезного можно взять из книги для управления продуктовой компании?
Любой кризис можно рассматривать как стратегический переломный момент по Гроуву. Если проводить классический анализ стратегии конкуренции в соответствии с моделью М. Портера в такой момент могут поменяться многие составляющие/силы и соответствующие им угрозы:
✔️ Усиливается угроза клиентов/потребителей
Нарушаются цепочки поставок продукта к потребителю. Текущие потребители становятся «не потребителями».
✔️ Усиливается угроза продуктов-заменителей
Меняется модель потребления клиентов. Меняется процесс выбора и совершения сделки/покупки. Меняется восприятие продукта.
✔️ Усиливается угроза текущих конкурентов
Если эти конкуренты готовились к кризису и продумывали планы B и С; имели альтернативные «запасные» продукты с прицеливанием на перспективу, диверсифицировались; накапливали «жирок» на трудные времена, оптимизировали издержки и сокращали долговые обязательства.
✔️ Усиливается угроза поставщиков и подрядчиков
Многие из них перестраивают ценовые политики, у кого-то сломались бизнес-процессы, а кто-то даже приостановил работу, не справившись с ситуацией.
✔️ Усиливается угроза появления новых игроков
Можно увидеть, как активировалось множество стартапов почувствовавших возможность въехать на волне перемен в меняющийся рынок и подвинуть серьезные компании. Устоявшиеся игроки уже завоевали рынок, но продолжают работать в старой парадигме под действием внутреннего маховика.
В отсутствии кризиса как правило единовременно начинается большие движения только одна из этих сил. Она может нарастать в разы. Управлять в такой момент продуктами и компанией весьма нетривиальная задача. В кризис же начинается хаос, и вся расстановка сил может поменяться одновременно. Старая структура, старые модели конкуренции полностью перестают работать.
Что же делать?
К сожалению, часто бывает, что битва заканчивается еще до начала основного сражения.
Еще до наступления кризиса надо трезво смотреть на основную линейку продуктов бизнеса и заранее ощущать, что происходит в окружающем мире. Какие тенденции способные снести неповоротливую махину компании на задворки если она не подвергнет адаптации свою модель и продукты. Лучше, если фирма сделает это самостоятельно и заранее, не дожидаясь, когда это сделают процессы извне. С хаосом сложно бороться, но можно попробовать им управлять.
@aheadofthepack
Только сейчас добрались руки до книги 📚 Эндрю Гроува «Выживают только параноики», который возглавлял компанию Intel в конце прошлого столетия. Да, книга не нова, но ее основные идеи фундаментальны и вполне актуальны и по сей день, та же модель М. Портера, которой пользуется Гроув. Модель подходит как инструмент построения стратегии как отдельного продукта, так и целой компании.
Что полезного можно взять из книги для управления продуктовой компании?
Любой кризис можно рассматривать как стратегический переломный момент по Гроуву. Если проводить классический анализ стратегии конкуренции в соответствии с моделью М. Портера в такой момент могут поменяться многие составляющие/силы и соответствующие им угрозы:
✔️ Усиливается угроза клиентов/потребителей
Нарушаются цепочки поставок продукта к потребителю. Текущие потребители становятся «не потребителями».
✔️ Усиливается угроза продуктов-заменителей
Меняется модель потребления клиентов. Меняется процесс выбора и совершения сделки/покупки. Меняется восприятие продукта.
✔️ Усиливается угроза текущих конкурентов
Если эти конкуренты готовились к кризису и продумывали планы B и С; имели альтернативные «запасные» продукты с прицеливанием на перспективу, диверсифицировались; накапливали «жирок» на трудные времена, оптимизировали издержки и сокращали долговые обязательства.
✔️ Усиливается угроза поставщиков и подрядчиков
Многие из них перестраивают ценовые политики, у кого-то сломались бизнес-процессы, а кто-то даже приостановил работу, не справившись с ситуацией.
✔️ Усиливается угроза появления новых игроков
Можно увидеть, как активировалось множество стартапов почувствовавших возможность въехать на волне перемен в меняющийся рынок и подвинуть серьезные компании. Устоявшиеся игроки уже завоевали рынок, но продолжают работать в старой парадигме под действием внутреннего маховика.
В отсутствии кризиса как правило единовременно начинается большие движения только одна из этих сил. Она может нарастать в разы. Управлять в такой момент продуктами и компанией весьма нетривиальная задача. В кризис же начинается хаос, и вся расстановка сил может поменяться одновременно. Старая структура, старые модели конкуренции полностью перестают работать.
Что же делать?
К сожалению, часто бывает, что битва заканчивается еще до начала основного сражения.
Еще до наступления кризиса надо трезво смотреть на основную линейку продуктов бизнеса и заранее ощущать, что происходит в окружающем мире. Какие тенденции способные снести неповоротливую махину компании на задворки если она не подвергнет адаптации свою модель и продукты. Лучше, если фирма сделает это самостоятельно и заранее, не дожидаясь, когда это сделают процессы извне. С хаосом сложно бороться, но можно попробовать им управлять.
@aheadofthepack
Классическая ловушка
Бывает, что организации пытаются внедрять Agile подходы в своей разработке, при этом оставляют сущности, применимость и совместимость которых с Agile весьма сомнительна. Одним из краеугольных камней является управление стоимостью проекта или разработки продукта.
Есть проектный подход PMI с вычислениями по Методу освоенного объёма (Earned Value Management) через несколько показателей и индексов:
1️⃣ BAC — Совокупная запланированная стоимость (Budget at completion)
2️⃣ PV — Плановый объем (Planned value)
3️⃣ EV — Освоенный объем (Earned value)
4️⃣ ФС (AC, ACWP) — Фактическая стоимость выполненных работ (Actual Cost, Actual Cost of Work Performed)
5️⃣ ИВСР (SPI) — Индекс выполнения сроков (Schedule Performance Index)
6️⃣ ИВСТ (CPI) — Индекс выполнения стоимости (Cost Performance Index)
При переходе на Agile c постоянно пополняемым Backlog, упрощенной моделью риск-менеджмента, дорогая сердцу модель освоенного объема, разумеется, перестает работать. Графики начинают расползаться вверх как на дрожжах, а значения коэффициентов скакать то вверх, то вниз, путая старших менеджеров. Еще хуже, когда менеджеры начинают транслировать слепки этой "неправильной" информации, не понимая сути явления, остальным заинтересованным лицам. Я уверен, что не одному мне приходилось слышать вопросы от стейкхолдеров о том, на сколько же процентов "увеличились" описанные индексы при периодическом мониторинге. 🤦♂️
Что же делать? Как минимум избавиться от старого наследия.
В многих Agile фреймворках применяется совсем другой инструмент оценки – Диаграмма сгорания задач (BurnDown Chart). Именно она после нескольких итерационных циклов является более адекватный визуальный инструментом, а также позволяет рассчитать приблизительные оценки по стоимости в определённые моменты времени.
Нельзя менять отдельные элементы системы, не встав на ступеньку выше, и не посмотрев общую совместимость и применимость.
@aheadofthepack
Бывает, что организации пытаются внедрять Agile подходы в своей разработке, при этом оставляют сущности, применимость и совместимость которых с Agile весьма сомнительна. Одним из краеугольных камней является управление стоимостью проекта или разработки продукта.
Есть проектный подход PMI с вычислениями по Методу освоенного объёма (Earned Value Management) через несколько показателей и индексов:
1️⃣ BAC — Совокупная запланированная стоимость (Budget at completion)
2️⃣ PV — Плановый объем (Planned value)
3️⃣ EV — Освоенный объем (Earned value)
4️⃣ ФС (AC, ACWP) — Фактическая стоимость выполненных работ (Actual Cost, Actual Cost of Work Performed)
5️⃣ ИВСР (SPI) — Индекс выполнения сроков (Schedule Performance Index)
6️⃣ ИВСТ (CPI) — Индекс выполнения стоимости (Cost Performance Index)
При переходе на Agile c постоянно пополняемым Backlog, упрощенной моделью риск-менеджмента, дорогая сердцу модель освоенного объема, разумеется, перестает работать. Графики начинают расползаться вверх как на дрожжах, а значения коэффициентов скакать то вверх, то вниз, путая старших менеджеров. Еще хуже, когда менеджеры начинают транслировать слепки этой "неправильной" информации, не понимая сути явления, остальным заинтересованным лицам. Я уверен, что не одному мне приходилось слышать вопросы от стейкхолдеров о том, на сколько же процентов "увеличились" описанные индексы при периодическом мониторинге. 🤦♂️
Что же делать? Как минимум избавиться от старого наследия.
В многих Agile фреймворках применяется совсем другой инструмент оценки – Диаграмма сгорания задач (BurnDown Chart). Именно она после нескольких итерационных циклов является более адекватный визуальный инструментом, а также позволяет рассчитать приблизительные оценки по стоимости в определённые моменты времени.
Нельзя менять отдельные элементы системы, не встав на ступеньку выше, и не посмотрев общую совместимость и применимость.
@aheadofthepack
Обещай меньше, делай больше
💡 Простой прием партизанского маркетинга – немного завышать оценку чего-либо для управления впечатлениями клиентов и их лояльностью. Это может быть оценка сроков, может быть оценка стоимости, или что-то иное. Людям ведь нравится, когда результат не только соответствует ожиданиям, но и превосходит их. Получившуюся разницу стоимости после выполнения услуги или проекта можно вернуть скидкой без ущерба для нормы прибыли. Главное дать клиентам то, что действительно было бы ценно для них.
Я заметил, что подобным приемом пользуется одна известная в настоящий момент медицинская фирма. Она с завидной регулярностью оказывает свои услуги не просто вовремя, а значительно быстрее, чем ожидаешь. Стоит ли ей это чего-либо? Если процессы налажены, как правило, это не стоит фирме ни рубля.
🚷Противоположная тактика – занижать оценки, в попытке конкурентной борьбы, предоставляя оптимистичные цифры. Результат очевиден: стресс у персонала и менеджеров, недополученные прибыли, расстроенные клиенты и плохая молва.
💡 Применительно к продуктовой разработке можно сделать реалистичный открытый Roadmap для отдела продаж и клиентов, который содержит внутри скрытые резервы. Если что-то пойдет не так, резерв даст нужный запас. Возможно, риски и не сработают, и это позволит приятно удивить заинтересованных лиц новыми фичами раньше срока, и может быть, немного расстроить конкурентов. А если удастся сделать еще что-то полезное, но незадекларированное, это еще лучше! Когда у нас была такая возможность, мы делали именно так.
Для тех, кто сомневается, что это работает, читайте книгу 📚 Карла Сьюэлла «Клиенты на всю жизнь».
@aheadofthepack
💡 Простой прием партизанского маркетинга – немного завышать оценку чего-либо для управления впечатлениями клиентов и их лояльностью. Это может быть оценка сроков, может быть оценка стоимости, или что-то иное. Людям ведь нравится, когда результат не только соответствует ожиданиям, но и превосходит их. Получившуюся разницу стоимости после выполнения услуги или проекта можно вернуть скидкой без ущерба для нормы прибыли. Главное дать клиентам то, что действительно было бы ценно для них.
Я заметил, что подобным приемом пользуется одна известная в настоящий момент медицинская фирма. Она с завидной регулярностью оказывает свои услуги не просто вовремя, а значительно быстрее, чем ожидаешь. Стоит ли ей это чего-либо? Если процессы налажены, как правило, это не стоит фирме ни рубля.
🚷Противоположная тактика – занижать оценки, в попытке конкурентной борьбы, предоставляя оптимистичные цифры. Результат очевиден: стресс у персонала и менеджеров, недополученные прибыли, расстроенные клиенты и плохая молва.
💡 Применительно к продуктовой разработке можно сделать реалистичный открытый Roadmap для отдела продаж и клиентов, который содержит внутри скрытые резервы. Если что-то пойдет не так, резерв даст нужный запас. Возможно, риски и не сработают, и это позволит приятно удивить заинтересованных лиц новыми фичами раньше срока, и может быть, немного расстроить конкурентов. А если удастся сделать еще что-то полезное, но незадекларированное, это еще лучше! Когда у нас была такая возможность, мы делали именно так.
Для тех, кто сомневается, что это работает, читайте книгу 📚 Карла Сьюэлла «Клиенты на всю жизнь».
@aheadofthepack
Не начинай, если не закончишь
Случается так, что незавершенная работа в проектах начинает копиться как снежный ком. Отчет по проделанной работе не стали делать, задачу не закрыли. Код не успели отрецензировать, и он остался где-то на задворках в отдельной ветке не интегрированным в общий проект. Поменяли приоритеты в процессе выполнения и отложили задачи без зафиксированного результата.
Во всех случаях образовался задел сгенерированной информации, которая не обрела финальную форму и не может быть кем-либо использована. Со временем эта информация забудется, устареет, протухнет. Это приведет к потерям затраченного времени - финансовым потерям, к потерям энергии - мотивации.
Описанную проблему необходимо прорабатывать. Но чтобы начать работать с проблемой по крайней мере ее надо правильно идентифицировать. В разных методиках гибким подходов применяются разные фишки.
✔️Для Kanban можно отслеживать Cycle Time - период времени пока задача находилась в работе до момента интеграции или поставки.
✔️Для Scrum учитывать незаконченные задачи вернувшиеся в Backlog после очередной итерации.
✔️Для бережливого производства работать с концепцией объединенных термином muda.
✔️В общем же случае для формулировки задач не помешает использовать критерии SMART. Для данного применения прежде всего стоит обратить внимание на достижимость - Attainable и ограниченность по времени - Time Based.
Если велик шанс не закончить даже простую атомарную задачу, может и не стоит тратить на нее время в данный момент?
@aheadofthepack
Случается так, что незавершенная работа в проектах начинает копиться как снежный ком. Отчет по проделанной работе не стали делать, задачу не закрыли. Код не успели отрецензировать, и он остался где-то на задворках в отдельной ветке не интегрированным в общий проект. Поменяли приоритеты в процессе выполнения и отложили задачи без зафиксированного результата.
Во всех случаях образовался задел сгенерированной информации, которая не обрела финальную форму и не может быть кем-либо использована. Со временем эта информация забудется, устареет, протухнет. Это приведет к потерям затраченного времени - финансовым потерям, к потерям энергии - мотивации.
Описанную проблему необходимо прорабатывать. Но чтобы начать работать с проблемой по крайней мере ее надо правильно идентифицировать. В разных методиках гибким подходов применяются разные фишки.
✔️Для Kanban можно отслеживать Cycle Time - период времени пока задача находилась в работе до момента интеграции или поставки.
✔️Для Scrum учитывать незаконченные задачи вернувшиеся в Backlog после очередной итерации.
✔️Для бережливого производства работать с концепцией объединенных термином muda.
✔️В общем же случае для формулировки задач не помешает использовать критерии SMART. Для данного применения прежде всего стоит обратить внимание на достижимость - Attainable и ограниченность по времени - Time Based.
Если велик шанс не закончить даже простую атомарную задачу, может и не стоит тратить на нее время в данный момент?
@aheadofthepack
Продуктовый подход в помощь проектным продажам
Фирмы, контрактные разработчики программного обеспечения сталкиваются с целым рядом однотипных проблем при решении вопроса прохождения входящего запроса через воронку продаж. Вот только некоторые из них:
📌 Отсутствие единообразной системы принятой среди менеджеров
📌 Пропуски основополагающих пунктов, которые сильно сказываются на последующих проектных и других решениях
📌 Излишние потери на разных уровнях воронки продаж
Цели сводятся как правило к фильтрации релевантных запросов, которые с наибольшей вероятностью приведут к успешному взятию и успешному завершению проекта. Построение системы такой многоуровневой фильтрации и является такой «простой» задачкой.
Бывает так, что типовые проекты не занимают сколь-либо значимую долю. А большая часть имеет индивидуальную техническую специфику. Однако, это совсем не означает, что нельзя подойти к решению вопроса, просто поднявшись на ступеньку выше – на более высокий уровень абстракции.
Если для контрактника работа – это проект, то у заказчика как правило есть некоторое продуктовое виденье. Это когда-то натолкнуло меня на мысль применить продуктовые методики для решения этой задачки.
Для построения и ранжирования списка пунктов можно взять некоторый микс из маркетингового подхода к продуктовому планированию 4P, аналитического подхода с применением бизнес-модели А. Остервальдера – Business Model Canvas, и соуса из опыта разработки подобных продуктов. В результат рождается список открытых вопросов для заказчика, по которым можно более качественно представить идею, которую придется воплощать. Полагаю, что смысла вдаваться в детали здесь нет, важен лишь общий принцип построения такого списка и каждый без труда сможет это повторить.
Таким образом на этапе получения ответов можно с высокой долей вероятности отсеять продукты и проекты им соответствующие, которые в силу тех или иных причин никогда не достигнут этапа завершенности или хотя бы MVP. Получается весьма эффективный инструмент - сито, для просеивания «золотых самородков». Причем выгоды от процесса всегда получают обе стороны. Возможный исполнитель снижает издержки и потери на работу с воронкой, делая ее более эффективной; оттачивает бизнес-процесс, делая его унифицированным и предсказуемым. Потенциальный заказчик уточняет свое виденье; начинает задумываться над теми вопросами, которые он не знал или пропустил, покуда «варился в собственном соку».
@aheadofthepack
Фирмы, контрактные разработчики программного обеспечения сталкиваются с целым рядом однотипных проблем при решении вопроса прохождения входящего запроса через воронку продаж. Вот только некоторые из них:
📌 Отсутствие единообразной системы принятой среди менеджеров
📌 Пропуски основополагающих пунктов, которые сильно сказываются на последующих проектных и других решениях
📌 Излишние потери на разных уровнях воронки продаж
Цели сводятся как правило к фильтрации релевантных запросов, которые с наибольшей вероятностью приведут к успешному взятию и успешному завершению проекта. Построение системы такой многоуровневой фильтрации и является такой «простой» задачкой.
Бывает так, что типовые проекты не занимают сколь-либо значимую долю. А большая часть имеет индивидуальную техническую специфику. Однако, это совсем не означает, что нельзя подойти к решению вопроса, просто поднявшись на ступеньку выше – на более высокий уровень абстракции.
Если для контрактника работа – это проект, то у заказчика как правило есть некоторое продуктовое виденье. Это когда-то натолкнуло меня на мысль применить продуктовые методики для решения этой задачки.
Для построения и ранжирования списка пунктов можно взять некоторый микс из маркетингового подхода к продуктовому планированию 4P, аналитического подхода с применением бизнес-модели А. Остервальдера – Business Model Canvas, и соуса из опыта разработки подобных продуктов. В результат рождается список открытых вопросов для заказчика, по которым можно более качественно представить идею, которую придется воплощать. Полагаю, что смысла вдаваться в детали здесь нет, важен лишь общий принцип построения такого списка и каждый без труда сможет это повторить.
Таким образом на этапе получения ответов можно с высокой долей вероятности отсеять продукты и проекты им соответствующие, которые в силу тех или иных причин никогда не достигнут этапа завершенности или хотя бы MVP. Получается весьма эффективный инструмент - сито, для просеивания «золотых самородков». Причем выгоды от процесса всегда получают обе стороны. Возможный исполнитель снижает издержки и потери на работу с воронкой, делая ее более эффективной; оттачивает бизнес-процесс, делая его унифицированным и предсказуемым. Потенциальный заказчик уточняет свое виденье; начинает задумываться над теми вопросами, которые он не знал или пропустил, покуда «варился в собственном соку».
@aheadofthepack
Развивать нельзя резать
Ресурсы R&D всегда ограничены и необходимо концентрироваться на значимых вещах, которые максимизируют прибыль и рост.
Для развития продукта крайне важно быть в курсе, какие его функции используются постоянно, какие - время от времени, а что не используется вовсе. Для грамотного управления Roadmap необходимо работать с пользователями и проводить периодический аудит. Однако далеко не все продукты позволяют собирать статистику пользования автоматически. Тогда годятся и старые методы: анкетирование, интервьюирование и т д.
💡 Для измерительной платформы, в разработке которой я участвовал несколько лет назад, исследования проводили именно анкетированием. Были и сложности. Не всегда тот, кто отвечал за закупку, и конечный пользователь были одно лицо. Поэтому получить статистическую информацию было не просто.
И что же рождается в итоге? По результатам исследования можно построить ранжированный список использования функций. В левой части графика находятся основные лидеры. Их надо холить и лелеять. Как минимум, подчищать своевременно баги. В правой – нереализованные возможности, либо безнадежные аутсайдеры.
Почему же некоторые функции оказываются невостребованными? Бывает пользователи не видят ценности в их использовании, не знают, как ими правильно пользоваться, либо не знают об их существовании. Для этого может потребоваться уже отдельное исследование. Понять истинную причину очень важно, чтобы правильно скорректировать действия по маркетингу продукта.
Бывают и безнадежные варианты. Если функцию невозможно заставить работать на продукт, ее надо просто безжалостно удалять, чтобы не разводить хлам.
@aheadofthepack
Ресурсы R&D всегда ограничены и необходимо концентрироваться на значимых вещах, которые максимизируют прибыль и рост.
Для развития продукта крайне важно быть в курсе, какие его функции используются постоянно, какие - время от времени, а что не используется вовсе. Для грамотного управления Roadmap необходимо работать с пользователями и проводить периодический аудит. Однако далеко не все продукты позволяют собирать статистику пользования автоматически. Тогда годятся и старые методы: анкетирование, интервьюирование и т д.
💡 Для измерительной платформы, в разработке которой я участвовал несколько лет назад, исследования проводили именно анкетированием. Были и сложности. Не всегда тот, кто отвечал за закупку, и конечный пользователь были одно лицо. Поэтому получить статистическую информацию было не просто.
И что же рождается в итоге? По результатам исследования можно построить ранжированный список использования функций. В левой части графика находятся основные лидеры. Их надо холить и лелеять. Как минимум, подчищать своевременно баги. В правой – нереализованные возможности, либо безнадежные аутсайдеры.
Почему же некоторые функции оказываются невостребованными? Бывает пользователи не видят ценности в их использовании, не знают, как ими правильно пользоваться, либо не знают об их существовании. Для этого может потребоваться уже отдельное исследование. Понять истинную причину очень важно, чтобы правильно скорректировать действия по маркетингу продукта.
Бывают и безнадежные варианты. Если функцию невозможно заставить работать на продукт, ее надо просто безжалостно удалять, чтобы не разводить хлам.
@aheadofthepack
И лучше и дешевле
С завидным постоянством у менеджеров-идеегенераторов возникает мысль повторить имеющийся на рынке продукт, но «по-своему». Подход копирования и модификации чужих идей является самым стандартным продуктовым кейсом, который сильно минимизирует затраты на маркетинг, а также существенно снижает целый ряд рисков, связанных с выводом новых продуктов на старый рынок, а тем более новых продуктов на новый рынок. Часто мы можем наблюдать классные реинкарнации старых идей во многих областях IT.
Однако бывает приходит запрос реализовать нечто похожее, но с обязательной парой условий: сделать и лучше (по функционалу, техническим характеристикам, дизайну), и дешевле конкурентного продукта, уже имеющегося на рынке. При этом появляются даже попытки сделать экономическое обоснование или выполнить еще какие-либо проектные расчеты. Вопрос продуктового ценообразования достаточно глубок, но упростим формулировку до частного «сферического» случая затрат на R&D, поддержку и производство (если оно есть).
Надо всегда понимать, что выполнить такие условия без какого-либо прорыва невозможно. Отлично, если вы придумали как можно скрестить технологии, закрыть старую потребность с помощью новых инструментов, технологического стека, либо альтернативными кейсами. Но если у вас нет подобных козырей в кармане, не стоит верить в чудеса.
@aheadofthepack
С завидным постоянством у менеджеров-идеегенераторов возникает мысль повторить имеющийся на рынке продукт, но «по-своему». Подход копирования и модификации чужих идей является самым стандартным продуктовым кейсом, который сильно минимизирует затраты на маркетинг, а также существенно снижает целый ряд рисков, связанных с выводом новых продуктов на старый рынок, а тем более новых продуктов на новый рынок. Часто мы можем наблюдать классные реинкарнации старых идей во многих областях IT.
Однако бывает приходит запрос реализовать нечто похожее, но с обязательной парой условий: сделать и лучше (по функционалу, техническим характеристикам, дизайну), и дешевле конкурентного продукта, уже имеющегося на рынке. При этом появляются даже попытки сделать экономическое обоснование или выполнить еще какие-либо проектные расчеты. Вопрос продуктового ценообразования достаточно глубок, но упростим формулировку до частного «сферического» случая затрат на R&D, поддержку и производство (если оно есть).
Надо всегда понимать, что выполнить такие условия без какого-либо прорыва невозможно. Отлично, если вы придумали как можно скрестить технологии, закрыть старую потребность с помощью новых инструментов, технологического стека, либо альтернативными кейсами. Но если у вас нет подобных козырей в кармане, не стоит верить в чудеса.
@aheadofthepack
Можно ли завернуть шуруп стамеской?
Бывает люди пользуют инструменты не по назначению. Часто это не связано с каким-то злым умыслом, просто в личном багаже не нашлось ничего более подходящего, поискать времени не было, спросить было неудобно, да мало ли что…
Стоило мне как-то отлучиться в миниотпуск, в фирме изменился один из бизнес-процессов. Для его описания использовали не нотацию BPMN (Swim Lane), принятую в организации, а … диаграмму последовательностей. 🤪 Для разработчиков, привыкших к нотациям UML, используемых для описания поведения систем, понятность от такого нестандартного подхода, как ни странно, в основном сохранилась. По крайней мере, им удалось разобраться в статусах и последовательностях процесса. Однако процесс мне повторно переписать все же пришлось в стандартной нотации.
Для всего есть свой инструмент. А вот использование инструментов не по назначению является вредной привычкой. К ним быстро привыкаешь, закрепляешь применением, а потом никак не можешь отвыкнуть. А иногда даже требуется помощь со стороны.
@aheadofthepack
Бывает люди пользуют инструменты не по назначению. Часто это не связано с каким-то злым умыслом, просто в личном багаже не нашлось ничего более подходящего, поискать времени не было, спросить было неудобно, да мало ли что…
Стоило мне как-то отлучиться в миниотпуск, в фирме изменился один из бизнес-процессов. Для его описания использовали не нотацию BPMN (Swim Lane), принятую в организации, а … диаграмму последовательностей. 🤪 Для разработчиков, привыкших к нотациям UML, используемых для описания поведения систем, понятность от такого нестандартного подхода, как ни странно, в основном сохранилась. По крайней мере, им удалось разобраться в статусах и последовательностях процесса. Однако процесс мне повторно переписать все же пришлось в стандартной нотации.
Для всего есть свой инструмент. А вот использование инструментов не по назначению является вредной привычкой. К ним быстро привыкаешь, закрепляешь применением, а потом никак не можешь отвыкнуть. А иногда даже требуется помощь со стороны.
@aheadofthepack
Ценовое репозициорирование
Рынок – это динамичная среда и его возможности со временем тоже меняются. Если продукт не может выжать из текущего состояния рынка весь потенциал получения прибыли, а предпосылки для этого имеются, можно сделать репозиционированние. При выводе новых продуктов на рынок компания чаще всего не обладает всей необходимой информацией об эластичности спроса на данную категорию продукта. Но для перезапуска зрелых продуктов требуемая информация может найтись в отделе продаж, который знает все о прошедших сделках, предоставленных скидках, за что клиенты готовы и за что не готовы платить.
Репозиционирование по цене «сверху вниз» можно провести относительно легко, путем снижения издержек, оптимизации процессов, цепочек поставок и других мер. Но приведет ли это к значительному росту объемов продаж, а главное итоговой прибыли?
Гораздо интереснее и сложнее репозиционирование по цене «снизу вверх». Как правило это требует сильных изменений на уровне R&D, в качестве, дизайне, сопутствующих услугах и маркетинге для изменения восприятия продукта клиентами. Эти изменения могут быть затратны, но при прочих равных данный подход оказывается лучшим для показателей прибыли, нежели первый вариант.
У меня был удавшийся кейс по данной теме, связанный с измерительными приборами несколько лет назад. Измерительная техника - весьма консервативная категория продуктов с продолжительным жизненным циклом и ограниченным объемом рынка. В ней хорошо работают классические подходы. Предлагаю опрос для прогрева мозга в начале недели. Свой ответ напишу через пару дней.
@aheadofthepack
Рынок – это динамичная среда и его возможности со временем тоже меняются. Если продукт не может выжать из текущего состояния рынка весь потенциал получения прибыли, а предпосылки для этого имеются, можно сделать репозиционированние. При выводе новых продуктов на рынок компания чаще всего не обладает всей необходимой информацией об эластичности спроса на данную категорию продукта. Но для перезапуска зрелых продуктов требуемая информация может найтись в отделе продаж, который знает все о прошедших сделках, предоставленных скидках, за что клиенты готовы и за что не готовы платить.
Репозиционирование по цене «сверху вниз» можно провести относительно легко, путем снижения издержек, оптимизации процессов, цепочек поставок и других мер. Но приведет ли это к значительному росту объемов продаж, а главное итоговой прибыли?
Гораздо интереснее и сложнее репозиционирование по цене «снизу вверх». Как правило это требует сильных изменений на уровне R&D, в качестве, дизайне, сопутствующих услугах и маркетинге для изменения восприятия продукта клиентами. Эти изменения могут быть затратны, но при прочих равных данный подход оказывается лучшим для показателей прибыли, нежели первый вариант.
У меня был удавшийся кейс по данной теме, связанный с измерительными приборами несколько лет назад. Измерительная техника - весьма консервативная категория продуктов с продолжительным жизненным циклом и ограниченным объемом рынка. В ней хорошо работают классические подходы. Предлагаю опрос для прогрева мозга в начале недели. Свой ответ напишу через пару дней.
@aheadofthepack
На шаг впереди via @vote
Что поменяли в продукте прежде всего, чтобы реализовать ценовое репозиционировние «снизу вверх»?
anonymous poll
Разработали новые товары-дополнители, аксессуары – 46
👍👍👍👍👍👍👍 36%
Разработали новые убойные функции и фичи – 43
👍👍👍👍👍👍👍 33%
Улучшили дизайн, качество, потребительские свойства – 28
👍👍👍👍 22%
Улучшили техническую поддержку, пользовательскую документацию, курсы обучения пользователей – 12
👍👍 9%
👥 129 people voted so far.
anonymous poll
Разработали новые товары-дополнители, аксессуары – 46
👍👍👍👍👍👍👍 36%
Разработали новые убойные функции и фичи – 43
👍👍👍👍👍👍👍 33%
Улучшили дизайн, качество, потребительские свойства – 28
👍👍👍👍 22%
Улучшили техническую поддержку, пользовательскую документацию, курсы обучения пользователей – 12
👍👍 9%
👥 129 people voted so far.
Как продать старый продукт в новой упаковке и увеличить маржинальность?
Продолжение предыдущего поста о ценовом репозициорирование
Расскажу об удавшемся кейсе по репозиционированию измерительного оборудования. Измерительная техника - консервативная категория продуктов с продолжительным жизненным циклом и ограниченным объемом рынка. Для нее хорошо работают классические подходы.
Основная цель репозициорирования по цене «снизу вверх» состояла в перемещении линейки зрелых продуктов в более дорогую ценовую категорию. Одновременно с этим появлялась возможность выхода продукта на заграничный рынок.
Было сгенерировано много вариантов, что можно предпринять для «переупаковки» продукта, и не сделать ли все заново. 🤪 Выбрать нужный для построения Roadmap на тот момент помогла скорее интуиция. История умалчивает, что было бы, если пошли другим путем. Однако для выбранного направления имеются разумные обоснования.
Итак, стоит подумать над гипотезой, что для рынка B2B конечные потребители – это те же люди, что и в B2C с тем же представлением о товарах и услугах. Все вроде бы выглядит просто. За разные свойства продукта клиент готов доплачивать разную цену. Для максимизации прибыли логично концентрироваться на наименее затратных нововведениях, при реализации которых добавленная стоимость будет наибольшей. Не забыв правило Парето, введем понятие эффективности свойств. Атрибуты эффективности, влияющие на стоимость, разделим на базовые атрибуты и атрибуты привлекательности.
За базовый требования к продукту неискушенный клиент как правило не готов платить больше, чем средняя цена на рынке. К примеру, никто не требует от семейного седана разгона до 100 км/ч за 3 секунды. Да, да такие функции являются именно базовыми атрибутами. Они должны просто быть, работать хорошо и не вызывать разочарование у клиента. Пользователь будет сильно недоволен, если тот же семейный седан не сможет загруженный въехать на горку из-за нехватки мощности или ПО будет вылетать с ошибкой после каждого обращения к базе данных. Стоит ли выжимать из базовых атрибутов максимум? Относительно новых функций происходит то же самое. Будут ли функции оценены по достоинству или же это незначительные фишки, не выделяющие продукт? Являются ли они дополнительной ценностью? Неизвестно.
Как же обстоят дела с атрибутами привлекательности? Как правило именно они могут создать дополнительную ценность, которая будет оправдывать большую цену и увеличивать маржинальность. Дизайн, современные подходы и новшества, повышенное требование к качеству, бренд – эти атрибуты действительно могут хорошо монетизироваться.
Что же сделали мы? Подход был комплексный:
🔹 Прежде всего сделали рестайлинг, подобрав новые решения для корпуса. Новый дизайн корпус не отличался от западных аналогов-конкурентов.
🔹 Поработали с пользователями по UX, разобравшись с их болями по интерфейсу и меню. Даже небольшие изменения помогли улучшить удобство использования.
🔹 Сильно потрудились над качеством. Перелопатили Backlog с багами и отрефакторили самые закостыленные и глючные части. Помимо описанного ручного тестирования ввели автоматизацию тестирования с полным покрытием. Автоматизировали все, до чего технически смогли дотянуться руки специалиста по тестированию, реализовали Monkey testing. При этом продукт предшественник ограничили только багфиксом critical и major дефектов, а период обновления его релизов уменьшили.
🔹 Сильно улучшили потребительские свойства перейдя на емкий и современный аккумуляторный элемент. Время жизни устройства на одном заряде возросло, а время зарядки снизилось. Прокачали память.
Стали ли наращивать новый функционал в переупакованном продукте? Да, но уже на втором этапе после старта маркетинговой кампании и продаж. Вы скажете: «Ну так это же просто переупаковка!». Да, именно так. И как показывает практика, это работает! Продукт стал восприниматься по-другому. Его стоимость значительно возросла.
@aheadofthepack
Продолжение предыдущего поста о ценовом репозициорирование
Расскажу об удавшемся кейсе по репозиционированию измерительного оборудования. Измерительная техника - консервативная категория продуктов с продолжительным жизненным циклом и ограниченным объемом рынка. Для нее хорошо работают классические подходы.
Основная цель репозициорирования по цене «снизу вверх» состояла в перемещении линейки зрелых продуктов в более дорогую ценовую категорию. Одновременно с этим появлялась возможность выхода продукта на заграничный рынок.
Было сгенерировано много вариантов, что можно предпринять для «переупаковки» продукта, и не сделать ли все заново. 🤪 Выбрать нужный для построения Roadmap на тот момент помогла скорее интуиция. История умалчивает, что было бы, если пошли другим путем. Однако для выбранного направления имеются разумные обоснования.
Итак, стоит подумать над гипотезой, что для рынка B2B конечные потребители – это те же люди, что и в B2C с тем же представлением о товарах и услугах. Все вроде бы выглядит просто. За разные свойства продукта клиент готов доплачивать разную цену. Для максимизации прибыли логично концентрироваться на наименее затратных нововведениях, при реализации которых добавленная стоимость будет наибольшей. Не забыв правило Парето, введем понятие эффективности свойств. Атрибуты эффективности, влияющие на стоимость, разделим на базовые атрибуты и атрибуты привлекательности.
За базовый требования к продукту неискушенный клиент как правило не готов платить больше, чем средняя цена на рынке. К примеру, никто не требует от семейного седана разгона до 100 км/ч за 3 секунды. Да, да такие функции являются именно базовыми атрибутами. Они должны просто быть, работать хорошо и не вызывать разочарование у клиента. Пользователь будет сильно недоволен, если тот же семейный седан не сможет загруженный въехать на горку из-за нехватки мощности или ПО будет вылетать с ошибкой после каждого обращения к базе данных. Стоит ли выжимать из базовых атрибутов максимум? Относительно новых функций происходит то же самое. Будут ли функции оценены по достоинству или же это незначительные фишки, не выделяющие продукт? Являются ли они дополнительной ценностью? Неизвестно.
Как же обстоят дела с атрибутами привлекательности? Как правило именно они могут создать дополнительную ценность, которая будет оправдывать большую цену и увеличивать маржинальность. Дизайн, современные подходы и новшества, повышенное требование к качеству, бренд – эти атрибуты действительно могут хорошо монетизироваться.
Что же сделали мы? Подход был комплексный:
🔹 Прежде всего сделали рестайлинг, подобрав новые решения для корпуса. Новый дизайн корпус не отличался от западных аналогов-конкурентов.
🔹 Поработали с пользователями по UX, разобравшись с их болями по интерфейсу и меню. Даже небольшие изменения помогли улучшить удобство использования.
🔹 Сильно потрудились над качеством. Перелопатили Backlog с багами и отрефакторили самые закостыленные и глючные части. Помимо описанного ручного тестирования ввели автоматизацию тестирования с полным покрытием. Автоматизировали все, до чего технически смогли дотянуться руки специалиста по тестированию, реализовали Monkey testing. При этом продукт предшественник ограничили только багфиксом critical и major дефектов, а период обновления его релизов уменьшили.
🔹 Сильно улучшили потребительские свойства перейдя на емкий и современный аккумуляторный элемент. Время жизни устройства на одном заряде возросло, а время зарядки снизилось. Прокачали память.
Стали ли наращивать новый функционал в переупакованном продукте? Да, но уже на втором этапе после старта маркетинговой кампании и продаж. Вы скажете: «Ну так это же просто переупаковка!». Да, именно так. И как показывает практика, это работает! Продукт стал восприниматься по-другому. Его стоимость значительно возросла.
@aheadofthepack
Telegram
На шаг впереди
Ценовое репозициорирование
Рынок – это динамичная среда и его возможности со временем тоже меняются. Если продукт не может выжать из текущего состояния рынка весь потенциал получения прибыли, а предпосылки для этого имеются, можно сделать репозиционированние.…
Рынок – это динамичная среда и его возможности со временем тоже меняются. Если продукт не может выжать из текущего состояния рынка весь потенциал получения прибыли, а предпосылки для этого имеются, можно сделать репозиционированние.…
One way ticket
Пандемия ускоряет процессы, которые и так давно шли в IT. Все больше компаний понимают, что долговременные изменения в ежедневной работе избежать не удастся. Удаленка и территориально распределенные команды становятся нормой. Что же нужно для такой трансформации?
Процессы и инструменты
Компании, вовремя внедрившие процессы и инструменты для удаленной работы выглядят казалось бы «на коне». Наконец появляется возможность отказаться от устаревших оффлайновых KPI, такие как 40 списанных часов в неделю, или прихода к 10:00 в офис и сосредоточится на значимых результатах в соответствии с выбранной методологией управления. Но диджитализация - первая часть возможного успеха.
Адаптивная команда
Вторая не менее важная составляющая - это команда. Далеко не все работники способны работать удаленно. У одних не адаптировано домашнее рабочее место, или его в принципе невозможно организовать. Другие не могут самоорганизоваться и мотивироваться в удаленных условиях. Третьи не дружат с инструментарием удаленной работы без постоянной поддержки. Причем не все проблемы решаемы в принципе за какой-то обозримый период времени.
Долгосрочный план и ценности
Единственный разумный подход - первоначально разработать стратегический план найма нужных людей, которые могут и хотят работать в удаленном формате. Если копать глубже, смотреть надо на единые ценности работников и компании. Разбираться с имеющимися «неподходящими» кадрами, переобучать и мотивировать выйдет дорого. В период изменений пострадают не только прибыль, но и все работники из-за нарушения общей атмосферы компании.
Правила меняются на ходу
Уже видно, как крупные современные корпорации быстро приняли новые правила игры и заблаговременно начали адаптацию. Все или часть сотрудников в них уже переведена на удаленную работу. Не беда, что происходит снижение показателей в период адаптации. В долгосрочной перспективе с учетом нестабильности снижаются проектные и продуктовые риски. Работники воспринимают изменения как заботу о них. В среднесрочной перспективе такие компании еще сильнее начнут высасывать качественные адаптивные кадры с рынка.
Другие компании цепляются за старые принципы: командная работа в тесном физическом контакте в опенспейсе или офисной комнате, митинги в переговорной, частые встречи с заказчиками, партнерами и клиентами оффлайн. Однако уже сейчас такие компании испытывают ряд проблем.
Компании не способные адаптироваться к удаленке могу проиграть конкурентную борьбу не только во внутренней эффективности, но и в борьбе за кадры.
Полезные инструменты
Кто еще не понял, куда стремится мир IT? Пока есть время можно изучить некоторые полезные SaaS сервисы для совместной удаленной работы. Надеюсь, что вы уже работаете с ними:
✔️Визуальные доски с шаблонами Miro Mural
✔️Системы управления проектами YouTrack Trello Jira
✔️Мессенджеры для командной работы Slack MS Teams
✔️Системы контроля версий Github Bitbucket
✔️и, конечно же конференции Zoom
@aheadofthepack
Пандемия ускоряет процессы, которые и так давно шли в IT. Все больше компаний понимают, что долговременные изменения в ежедневной работе избежать не удастся. Удаленка и территориально распределенные команды становятся нормой. Что же нужно для такой трансформации?
Процессы и инструменты
Компании, вовремя внедрившие процессы и инструменты для удаленной работы выглядят казалось бы «на коне». Наконец появляется возможность отказаться от устаревших оффлайновых KPI, такие как 40 списанных часов в неделю, или прихода к 10:00 в офис и сосредоточится на значимых результатах в соответствии с выбранной методологией управления. Но диджитализация - первая часть возможного успеха.
Адаптивная команда
Вторая не менее важная составляющая - это команда. Далеко не все работники способны работать удаленно. У одних не адаптировано домашнее рабочее место, или его в принципе невозможно организовать. Другие не могут самоорганизоваться и мотивироваться в удаленных условиях. Третьи не дружат с инструментарием удаленной работы без постоянной поддержки. Причем не все проблемы решаемы в принципе за какой-то обозримый период времени.
Долгосрочный план и ценности
Единственный разумный подход - первоначально разработать стратегический план найма нужных людей, которые могут и хотят работать в удаленном формате. Если копать глубже, смотреть надо на единые ценности работников и компании. Разбираться с имеющимися «неподходящими» кадрами, переобучать и мотивировать выйдет дорого. В период изменений пострадают не только прибыль, но и все работники из-за нарушения общей атмосферы компании.
Правила меняются на ходу
Уже видно, как крупные современные корпорации быстро приняли новые правила игры и заблаговременно начали адаптацию. Все или часть сотрудников в них уже переведена на удаленную работу. Не беда, что происходит снижение показателей в период адаптации. В долгосрочной перспективе с учетом нестабильности снижаются проектные и продуктовые риски. Работники воспринимают изменения как заботу о них. В среднесрочной перспективе такие компании еще сильнее начнут высасывать качественные адаптивные кадры с рынка.
Другие компании цепляются за старые принципы: командная работа в тесном физическом контакте в опенспейсе или офисной комнате, митинги в переговорной, частые встречи с заказчиками, партнерами и клиентами оффлайн. Однако уже сейчас такие компании испытывают ряд проблем.
Компании не способные адаптироваться к удаленке могу проиграть конкурентную борьбу не только во внутренней эффективности, но и в борьбе за кадры.
Полезные инструменты
Кто еще не понял, куда стремится мир IT? Пока есть время можно изучить некоторые полезные SaaS сервисы для совместной удаленной работы. Надеюсь, что вы уже работаете с ними:
✔️Визуальные доски с шаблонами Miro Mural
✔️Системы управления проектами YouTrack Trello Jira
✔️Мессенджеры для командной работы Slack MS Teams
✔️Системы контроля версий Github Bitbucket
✔️и, конечно же конференции Zoom
@aheadofthepack
Miro
AI Innovation Workspace | Miro
Speed up product development from ideation to launch. Align teams, break tool silos, and ship what customers need in one AI-powered visual platform.
Два подхода к чтению книг
В большинстве мест работы я стараюсь проводить мероприятия по обучению, мотивации самообучения и собираю обратную связь по этому направлению. В одной из книг была озвучена классная мысль: «Лучше обучить сотрудника, и он покинет фирму, чем не обучить и он останется». Всегда стоит о ней вспоминать.
В прошлом году проводил анкетирование среди сотрудников. В анкете поднимались вопросы связанные с каналами получения новых знаний, планированием обучения, достижением результатов, и ценностями.
Вот как выглядел один из прямых вопросов анкеты: «Сколько книг читали сотрудники и сколько книг в итоге было прочитано до конца?». Имелась в виду только техническая и бизнес литература. Полученные данные привели меня к неожиданным заключениям. Оказалось, что в отличие от менеджеров и тимлидов, разработчики и тестировщики в подавляющем количестве случаев не дочитывают книги до конца. Не думаю, что разработчики склонны не завершать работу. По крайней мере в остальных рабочих моментах такой проблемы не просматривается. Используя опыт работы программистом, объяснить этот факт я могу лишь иной потребностью в чтении литературы. Изучение книг программистами увязано с проблемой решения конкретной специфической задачи. Потребность же менеджеров связана с необходимостью постоянного повышения квалификации и систематизации знаний. При этом прочтение одной главы из книги не решает всех вопросов.
Менеджерам разного уровня изучать приходится гораздо больше и шире, чем остальным сотрудникам. Чтобы просто не отставать на месте приходится перелопачивать большие стопки книг и проходить массу курсов.
@aheadofthepack
В большинстве мест работы я стараюсь проводить мероприятия по обучению, мотивации самообучения и собираю обратную связь по этому направлению. В одной из книг была озвучена классная мысль: «Лучше обучить сотрудника, и он покинет фирму, чем не обучить и он останется». Всегда стоит о ней вспоминать.
В прошлом году проводил анкетирование среди сотрудников. В анкете поднимались вопросы связанные с каналами получения новых знаний, планированием обучения, достижением результатов, и ценностями.
Вот как выглядел один из прямых вопросов анкеты: «Сколько книг читали сотрудники и сколько книг в итоге было прочитано до конца?». Имелась в виду только техническая и бизнес литература. Полученные данные привели меня к неожиданным заключениям. Оказалось, что в отличие от менеджеров и тимлидов, разработчики и тестировщики в подавляющем количестве случаев не дочитывают книги до конца. Не думаю, что разработчики склонны не завершать работу. По крайней мере в остальных рабочих моментах такой проблемы не просматривается. Используя опыт работы программистом, объяснить этот факт я могу лишь иной потребностью в чтении литературы. Изучение книг программистами увязано с проблемой решения конкретной специфической задачи. Потребность же менеджеров связана с необходимостью постоянного повышения квалификации и систематизации знаний. При этом прочтение одной главы из книги не решает всех вопросов.
Менеджерам разного уровня изучать приходится гораздо больше и шире, чем остальным сотрудникам. Чтобы просто не отставать на месте приходится перелопачивать большие стопки книг и проходить массу курсов.
@aheadofthepack
Польза должностной инструкции
В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как вынести пользу из этой формальной задачи?
Для начала стоит озадачится вопросом какая преследуется цель создания такого регламентирующего документа? Возможно, это инициатива высшего руководства для наведения общего порядка во всех документах. В другом случае - HR-служб для использования в процессе поиска кадров. В редких случаях процесс инициируется линейными менеджерами с целью наладить процесс развития команды разработчиков.
Как правило исполнитель тратит 5 минут на гугление примеров и скачивает чужой шаблон с авторскими ошибками и особенностями той другой организации. В другом случае автор пишет «отсебятину» вводя собственную терминологию и систему, рождая инструкцию в творческих муках. Формально задача вроде бы решена, все довольны, не так ли?
Я тоже одно время ломал голову над задачкой, пока не нашел другой, правильный подход. IEEE разработала документ – 📚 Software Engineering Competency Model (SWECOM). 👉Далее...
@aheadofthepack
В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как вынести пользу из этой формальной задачи?
Для начала стоит озадачится вопросом какая преследуется цель создания такого регламентирующего документа? Возможно, это инициатива высшего руководства для наведения общего порядка во всех документах. В другом случае - HR-служб для использования в процессе поиска кадров. В редких случаях процесс инициируется линейными менеджерами с целью наладить процесс развития команды разработчиков.
Как правило исполнитель тратит 5 минут на гугление примеров и скачивает чужой шаблон с авторскими ошибками и особенностями той другой организации. В другом случае автор пишет «отсебятину» вводя собственную терминологию и систему, рождая инструкцию в творческих муках. Формально задача вроде бы решена, все довольны, не так ли?
Я тоже одно время ломал голову над задачкой, пока не нашел другой, правильный подход. IEEE разработала документ – 📚 Software Engineering Competency Model (SWECOM). 👉Далее...
@aheadofthepack
Teletype
Польза должностной инструкции
В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как...
Продуктовая и проектная диверсификация
Любой стартап стартует с одного проекта или продукта в варианте MVP. Исходя из статистики 70-90% запусков терпят неудачу в силу массы причин. Почему? Срабатывают риски, которые не удалось или было невозможно оценить на входе. Большинство предпринимателей понимают это, но вместе с тем, будучи оптимистами, не отказываются от такой затей, т к и выгода в случае успеха может быть немалой.
Допустим запуск прошел успешно. 🚀 Появился один ключевой заказчик для проектов, либо продукт попал свою целевую нишу. Менеджмент компании, решает, что ухватили чёрта за хвост и пора делить бенефиты. Как правило в этот момент или чуть позже срабатывают риски. 🎲
Самый действенный, но не единственный способ минимизации рисков – портфельная диверсификация. В теории, если мы набираем в портфель различные проекты или расширяем линейку продуктов, корреляция рисков между которыми незначительна, интегральный риск уменьшается при возможном снижении общей маржинальности. Но важно помнить, что наивно подходить к диверсификации не получится. Если, к примеру, все продукты в портфеле относятся к одной отрасли (телеком, нефтедобыча, и т д) для них действуют общие отраслевые риски. Корреляция вероятности наступления рисков между отдельными продуктами высока. При проблемах в отрасли портфель будет отрабатывать синхронно. Так было в одной компании, в которой я работал. Системные риски также не снижаются методом диверсификации.
Лучший подход - посмотреть, как последовательно провести диверсификацию по отраслям, по направлениям, географически. А также не забывать о размерах проектов и объемах продаж отдельных продуктов, чтобы не создавались значительные перекосы. Проведя аналогии с финансовой сферой, стоит также пойти дальше и учитывать отдельные рисковые факторы, к примеру, для расчёта объемов вложений в отдельные продукты.
Диверсификация необходима. При проблемах в одном из продуктов или проектов весь портфель пострадает не так значительно, сохраняя устойчивость компании.
@aheadofthepack
Любой стартап стартует с одного проекта или продукта в варианте MVP. Исходя из статистики 70-90% запусков терпят неудачу в силу массы причин. Почему? Срабатывают риски, которые не удалось или было невозможно оценить на входе. Большинство предпринимателей понимают это, но вместе с тем, будучи оптимистами, не отказываются от такой затей, т к и выгода в случае успеха может быть немалой.
Допустим запуск прошел успешно. 🚀 Появился один ключевой заказчик для проектов, либо продукт попал свою целевую нишу. Менеджмент компании, решает, что ухватили чёрта за хвост и пора делить бенефиты. Как правило в этот момент или чуть позже срабатывают риски. 🎲
Самый действенный, но не единственный способ минимизации рисков – портфельная диверсификация. В теории, если мы набираем в портфель различные проекты или расширяем линейку продуктов, корреляция рисков между которыми незначительна, интегральный риск уменьшается при возможном снижении общей маржинальности. Но важно помнить, что наивно подходить к диверсификации не получится. Если, к примеру, все продукты в портфеле относятся к одной отрасли (телеком, нефтедобыча, и т д) для них действуют общие отраслевые риски. Корреляция вероятности наступления рисков между отдельными продуктами высока. При проблемах в отрасли портфель будет отрабатывать синхронно. Так было в одной компании, в которой я работал. Системные риски также не снижаются методом диверсификации.
Лучший подход - посмотреть, как последовательно провести диверсификацию по отраслям, по направлениям, географически. А также не забывать о размерах проектов и объемах продаж отдельных продуктов, чтобы не создавались значительные перекосы. Проведя аналогии с финансовой сферой, стоит также пойти дальше и учитывать отдельные рисковые факторы, к примеру, для расчёта объемов вложений в отдельные продукты.
Диверсификация необходима. При проблемах в одном из продуктов или проектов весь портфель пострадает не так значительно, сохраняя устойчивость компании.
@aheadofthepack
Возврат к средней величине
При улучшении процессов разработки происходит иногда значительные изменения. А большинство разработчиков, да и людей в целом, изменения не любят. Новые правила, новые подходы, новые инструменты вызывают дискомфорт.
Я много раз замечал, что если пустить поддержание нововведений на самотек, то со временем все деградирует и возвращается в предыдущее состояние процессов. Иногда это происходит быстро, если привычки еще не успели выработаться или медленнее, если принятые изменения системные. Так или иначе, без постоянной подталкивающей силы происходит обратный откат.
Вы видите это в числах, если внедрены "показометры" производительности, KPI или что-либо еще. Как пример, метрика Velocity в методологии Scrum.
Можно заметить, как при необходимой выборке и временном отрезке, значения сначала могут идти вниз из-за процесса адаптации. Потом становятся выше предыдущего среднего, если изменения были положительные. Но в отсутствии стимулов начинают сползать к средней величине, которая была до внедрения изменений.
Новые изменения должны принять все участники процесса разработки. А локальные лидеры мнений не только поддерживать эти изменения, но драйвить остальных участников. Без этого работа менеджера над улучшениями будет больше напоминать работу Сизифа.
@aheadofthepack
При улучшении процессов разработки происходит иногда значительные изменения. А большинство разработчиков, да и людей в целом, изменения не любят. Новые правила, новые подходы, новые инструменты вызывают дискомфорт.
Я много раз замечал, что если пустить поддержание нововведений на самотек, то со временем все деградирует и возвращается в предыдущее состояние процессов. Иногда это происходит быстро, если привычки еще не успели выработаться или медленнее, если принятые изменения системные. Так или иначе, без постоянной подталкивающей силы происходит обратный откат.
Вы видите это в числах, если внедрены "показометры" производительности, KPI или что-либо еще. Как пример, метрика Velocity в методологии Scrum.
Можно заметить, как при необходимой выборке и временном отрезке, значения сначала могут идти вниз из-за процесса адаптации. Потом становятся выше предыдущего среднего, если изменения были положительные. Но в отсутствии стимулов начинают сползать к средней величине, которая была до внедрения изменений.
Новые изменения должны принять все участники процесса разработки. А локальные лидеры мнений не только поддерживать эти изменения, но драйвить остальных участников. Без этого работа менеджера над улучшениями будет больше напоминать работу Сизифа.
@aheadofthepack
Зацикленность на технологиях
Как же часто встречаются организации, разрабатывающие продукт и при этом зацикленные на технологиях. Компании обладают набором компетенции, экспертами в технических областях, изученным технологический стеком. Эти технологии нравятся команде, их хочется исследовать глубже и применять везде.
Менеджеры начинают убеждать себя и команду в смысле выбранного технического решения. Вместо изучения проблем клиентов и различных групп пользователей они варятся в собственном соку. Иногда техническое решение продвигается от внутренних пользователей. Его начинают усложнять и наращивать, придумывая новые фичи, строя архитектуру с большим запасом на универсальность и последующие расширения.
Решение становится основной целью. Под него начинают придумывать потребности на рынке, искать конкурентов. Иногда их находят, закрепляя для себя правильность выбора.
Идет стереотипный сценарий - заводится проект, выделяется бюджет, рисуется план. Прототипы либо не разрабатываются вовсе, либо создаются и тестируются на внутренних же пользователях, предлагавших решение. Круг замыкается. Месяцами, а иногда и годами, разрабатывается "монолитный" законченный продукт, который интегрируется с кучей других систем. Решает ли он чужие проблемы? Продается ли он?
@aheadofthepack
Как же часто встречаются организации, разрабатывающие продукт и при этом зацикленные на технологиях. Компании обладают набором компетенции, экспертами в технических областях, изученным технологический стеком. Эти технологии нравятся команде, их хочется исследовать глубже и применять везде.
Менеджеры начинают убеждать себя и команду в смысле выбранного технического решения. Вместо изучения проблем клиентов и различных групп пользователей они варятся в собственном соку. Иногда техническое решение продвигается от внутренних пользователей. Его начинают усложнять и наращивать, придумывая новые фичи, строя архитектуру с большим запасом на универсальность и последующие расширения.
Решение становится основной целью. Под него начинают придумывать потребности на рынке, искать конкурентов. Иногда их находят, закрепляя для себя правильность выбора.
Идет стереотипный сценарий - заводится проект, выделяется бюджет, рисуется план. Прототипы либо не разрабатываются вовсе, либо создаются и тестируются на внутренних же пользователях, предлагавших решение. Круг замыкается. Месяцами, а иногда и годами, разрабатывается "монолитный" законченный продукт, который интегрируется с кучей других систем. Решает ли он чужие проблемы? Продается ли он?
@aheadofthepack
Forwarded from Analyst Marathon
Сегодня у нас видеопредставление спикера!
Александр Кузовлев
Руководитель проектов,
ВА\SA аналитик в Третий Пин – агентство разработки электроники и встроенных систем на заказ, – рассказал про свое выступление 17 декабря 2020 года на Аналитическом марафоне #3:
https://youtu.be/zFHXM_6AFOs
Александр Кузовлев
Руководитель проектов,
ВА\SA аналитик в Третий Пин – агентство разработки электроники и встроенных систем на заказ, – рассказал про свое выступление 17 декабря 2020 года на Аналитическом марафоне #3:
https://youtu.be/zFHXM_6AFOs
YouTube
Александр Кузовлев про свое выступление на Analyst Marathon #3
Тема: Польза и вред от техдолга в аналитике
Что назвать долгом в аналитике?
Кейсы с примерами технического долга
Фундаментальные причины появления технического долга
Частные причины возникновения долгов
Как долг превратить в пользу?
Как идентифицировать…
Что назвать долгом в аналитике?
Кейсы с примерами технического долга
Фундаментальные причины появления технического долга
Частные причины возникновения долгов
Как долг превратить в пользу?
Как идентифицировать…
Причем тут Маслоу?
Все, помнят пирамиду потребностей А. Маслоу. Однако я не часто встречаю ее упоминание при генерации и проверке новых идей для продуктов. Может быть зря?
Удовлетворение потребностей – это главное правило жизнеспособности любого продукта. Логика подсказывает, что для увеличения охвата в B2C, продукт проще строить вокруг нижних примитивных потребностей. Так больше шансов удачно масштабироваться, даже несмотря на то, что поляна занята гораздо плотнее.
Придумывать концепты вокруг проблемы личностного совершенствования – идея благородная. Но много ли найдется пользователей? Практика показывает, что людей, достигающих верхних уровней пирамиды, не так и много. К тому же сами потребности пятого уровня таковы, что люди сильнее всего отличаются друг от друга. Поэтому придумать унифицированное продуктовое решение будет не так просто.
@aheadofthepack
Все, помнят пирамиду потребностей А. Маслоу. Однако я не часто встречаю ее упоминание при генерации и проверке новых идей для продуктов. Может быть зря?
Удовлетворение потребностей – это главное правило жизнеспособности любого продукта. Логика подсказывает, что для увеличения охвата в B2C, продукт проще строить вокруг нижних примитивных потребностей. Так больше шансов удачно масштабироваться, даже несмотря на то, что поляна занята гораздо плотнее.
Придумывать концепты вокруг проблемы личностного совершенствования – идея благородная. Но много ли найдется пользователей? Практика показывает, что людей, достигающих верхних уровней пирамиды, не так и много. К тому же сами потребности пятого уровня таковы, что люди сильнее всего отличаются друг от друга. Поэтому придумать унифицированное продуктовое решение будет не так просто.
@aheadofthepack
Встреча совсем скоро
Я буду выступать на Третьем Аналитическом марафоне 17 декабря с докладом «Польза и вред от технического долга в аналитике». Несмотря на плотный график и яростные попытки вирусов подорвать приготовления, все сделано, и встреча состоится послезавтра.
Я подниму тему, с которой все сталкивались не единожды, и которая не раз приводила в уныние не одну команду разработки. Все мы сталкивались с ситуацией, когда надо срочно ускоряться, разрабатывать спецификации, писать код, выпускать релизы. Начальство говорит: «Давай, давай»! Но сделать ничего быстро не получается. Груз накопившихся в разработке проблем давит на плечи. И мы занимаемся переделкой ранее сделанной работы. Нас настиг Техдолг 💣
Почему же я акцентирую внимание именно на долге в аналитике? Возьмем любой сколь-либо кроткий цикл разработки, состоящий из выявления требований, имплементации, проверки качества и т д. Если сравнить стоимости ошибок и проблем в этой цепочке, то именно аналитика может стать самым дорогим звеном. Из практики получено, что вовремя не выявленные проблемы в требованиях могут быть на порядок дороже локальных проблем на последних этапах цепочки. Следуя принципам работы с рисками, именно этому направлению мы должны уделять особое внимание и выставлять максимальные приоритеты.
На марафоне будут еще 7 крутых спикеров с докладами о разных аспектах работы аналитиков: о процессах интеграции информационных систем, о дашбордах и визуализации данных, о различиях между проектом и продуктом, и о карьере аналитика. Будет интересно.
@aheadofthepack
Я буду выступать на Третьем Аналитическом марафоне 17 декабря с докладом «Польза и вред от технического долга в аналитике». Несмотря на плотный график и яростные попытки вирусов подорвать приготовления, все сделано, и встреча состоится послезавтра.
Я подниму тему, с которой все сталкивались не единожды, и которая не раз приводила в уныние не одну команду разработки. Все мы сталкивались с ситуацией, когда надо срочно ускоряться, разрабатывать спецификации, писать код, выпускать релизы. Начальство говорит: «Давай, давай»! Но сделать ничего быстро не получается. Груз накопившихся в разработке проблем давит на плечи. И мы занимаемся переделкой ранее сделанной работы. Нас настиг Техдолг 💣
Почему же я акцентирую внимание именно на долге в аналитике? Возьмем любой сколь-либо кроткий цикл разработки, состоящий из выявления требований, имплементации, проверки качества и т д. Если сравнить стоимости ошибок и проблем в этой цепочке, то именно аналитика может стать самым дорогим звеном. Из практики получено, что вовремя не выявленные проблемы в требованиях могут быть на порядок дороже локальных проблем на последних этапах цепочки. Следуя принципам работы с рисками, именно этому направлению мы должны уделять особое внимание и выставлять максимальные приоритеты.
На марафоне будут еще 7 крутых спикеров с докладами о разных аспектах работы аналитиков: о процессах интеграции информационных систем, о дашбордах и визуализации данных, о различиях между проектом и продуктом, и о карьере аналитика. Будет интересно.
@aheadofthepack
analyst-marathon.timepad.ru
ANALYST MARATHON #3. Онлайн-конференция. Видеозапись / События на TimePad.ru
Analyst Marathon — это образовательное онлайн-мероприятие для BA/SA-аналитиков.
Первая часть конференции посвящена процессам интеграции информационных систем в банковской сфере.
Во второй части речь пойдет о дашбордах и визуализации данных, проблеме…
Первая часть конференции посвящена процессам интеграции информационных систем в банковской сфере.
Во второй части речь пойдет о дашбордах и визуализации данных, проблеме…