Управление продуктом *

Работали по Agile и радовались, пока не копнули глубже. Делимся опытом, как сделать эффективнее взаимодействие в команде на 30+ человек. Начали с аналитиков и не смогли остановиться.

Привет! Меня зовут Ксения Толокнова, я продуктовый дизайнер и дизайн-лид с 12+ летним стажем. Пару лет назад я осознала что дизайн-система не всегда справляется со своими задачами, и сегодня я хотела бы обсудить, почему так происходит.

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

В статье обсудим:

— Всегда ли наличие дизайн-системы гарантирует консистентность?

— Почему дизайн-система не панацея от всех проблем.

— Что с этим делать?

Эта статья - продолжение моей статьи "о пользе регламентов" в рамках цикла статей "О чем РП не рассказывают на курсах". 

В статье дан базовый процесс для работы любой ИТ команды, так что она будет полезна для любых ИТ менеджеров: ИТ директоров, Руководителей проектных офисов, Владельцев и Руководителей продукта, Руководителей проектов, Руководителей команд. 

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

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

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

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

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

Если вы не ждете, что бог торговли Гермес прилетит в своих крылатых сандалиях и поможет выполнить годовой план на 110%, предлагаем ознакомиться с best practices в продажах ИБ-услуг, которыми поделился наш BDM Иван Куракин. Передаем ему слово. 

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

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

Этой статьей я попытаюсь немного снизить порог входа в одну из самых полезных (для меня) методик - Getting Things Done. Предложу свою вариацию, которую легко начать применять уже сегодня. Без дополнительных пояснений система будет понятна только тому, кто ее использует. Но зато позволит быстро разгрузить голову, не вникая в детали, изложенные в довольно объемной книге Дэвида Аллена. 

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

Западные игроки, например, Adobe, Atlassian, IBM и др., покинули РФ, оставив вакуум, нарушивший бизнес‑процессы. Отечественные компании столкнулись с вопросами, на которые ни у кого в мире не было ответа. Внезапно для части отечественного бизнеса, выяснилось, что выстроенные бизнес‑процессы оказались хрупкими, позиционирование не строиться на конкурентном сравнении, маркетинговые стратегии свелись к постам в соцсетях — и все это не приносит ожидаемого результата.

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

Custdev (кастев) — метод проверки гипотез, инструмент, который показывает высокую эффективность в выявлении запросов / потребности целевой аудитории и отвечает на важные вопросы по бизнес‑модели продукта, оказывает сильное влияние на качественную продуктовую разработку.

Знакома ситуация, когда вы хотите найти какие-либо макеты другого дизайнера, а перед вами — куча пространств с кучей папок с файлами, а в файлах — куча непонятных страниц? И в итоге получается непонятное флоу, у которого актуальных макетов одной и той же страницы 100500, и все они лежат в разных файлах. В итоге вы, как первобытный дизайнер из Photoshop, идёте в чат и начинаете выпрашивать макеты, которые должны были найти за 5 минут. Было такое? Коллеги явно спасибо не говорили!

Как такое решить? 

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

Это продолжение истории о разработке самого удобного приложения для зубрежки английских слов инди-разработчиком. Еще одно?! — Да, но с GenAI и алгоритмами!

Представьте: вы придумали классное решение внутри своего продукта, которое в разы упростит жизнь клиентам. Анонсировали в СМИ коллаборацию с известной компанией, пилите интеграцию и готовитесь успешно выкатить релиз. Но внезапно выясняется, что при разработке потерялось важное бизнес-требование. Теперь проект висит на волоске, вы рискуете потерять репутацию, доверие общественности и партнеров, а еще затянуть проект минимум на полгода. Ситуация патовая.  

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

Привет, Хабр! На связи Даша Волкова из МТС. Сегодня поговорим о нововведении Peloton.

Эта компания выпускает умные тренажеры — например, модель S27i Studio Bike можно купить за 2 500 $ США. Некоторые владельцы тренажеров их продают: кто-то переезжает, кому-то такая система не подходит или просто надоедает. До 2024 года все было как обычно: продал и продал.

Но как тебе такое, Илон Маск? Сейчас Peloton вводит правило: при покупке б/у тренажера с рук, а не у компании новый владелец должен заплатить дополнительные 95 $. Средства взимаются за активацию smart-функций по подписной модели. Подробности — под катом.

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

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

Привет, это вторая статья из цикла про наш путь создания Low-Code платформы-конструктора для разработки сложных Back Office систем. В прошлой статье я сформулировал, что такое «сложные системы», задачу, которую необходимо решить, а также привел набор «наблюдений» о принципах построения IT-производства на базе Low-Code инструмента. В этот раз я опишу подход, который мы выбрали для построения Back-End и работы с базой данных. В следующих статьях про принципы организации тонкого клиента.

Дать что-то бесплатно и тем самым подсадить на свой продукт всегда было одной из наилучших стратегий продвижения. Быть может также рассуждал Билл Гейтс, который возможно целенаправленно поставлял “пиратские” копии своих продуктов в Россию. В 1996 году знаменитая Горбушка попала в Книгу рекордов Гиннесса за достижение в области «Самое быстрое пиратство». Билл Гейтс объявил о старте продаж пакета «Офис 97» по цене 495 долларов за копию. Уже через 4 часа «Офис 97» продавался на Горбушке по цене чуть менее 5 у. е. за ту же самую копию. Спустя 25 лет мы не меньше хотим “бесплатное”. В корпоративном IT рынка бесплатного софта нет, но есть всем известный Open Source. Насколько это выгодно самим разработчикам разберемся в этой статье.

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

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

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

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

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

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

Несмотря на важность вопроса мигрирования данных корпоративных информационных систем, литературных источников, дающих исчерпывающее представление о переносе информации не так много. Но даже в них есть изъяны: или слишком поверхностное описание, или излишняя детализация, исключающая стратегию как таковую. Примером первой категории работ служит статья [1], повествующая о миграции данных в SAP ERP, однако тонкости и детали переноса основных и переменных данных в ней не раскрыты. Прочие работы [2-3] дают максимум информации по автоматизированным средствам переноса данных в той же системе SAP, хотя взаимосвязь между техническими средствами и концепцией, стратегией, видением не прослеживается. Все это подчеркивает необходимость детального анализа миграции данных ERP-систем, что особенно актуально для транзакционных информационных систем.

В этой статье я поделюсь своим опытом адаптации стандартов Agile к реалиям своего текущего проекта；перечислю решения, которые продвинули мою команду вперед, призывая мыслить шире и проявлять креативность.

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

Она не совсем про Руководство проектами, она пошире: про руководство командами разработки. Но если вы Руководитель и у вас на проекте разработки ПО есть хотя бы пара разработчиков, вам ее будет полезно прочитать.

Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Правила – это скучно.

Я давно заметил, что, когда набираю новых менеджеров и рассказываю им про регламенты и правила разработки в компании, они очень внимательно слушают, усиленно кивают и вообще – само внимание. А спустя пару недель или месяц, внезапно выясняется, что они не даже не кликнули по ссылке, которую я отправлял в письме. И читают регламенты исключительно из-под палки. Хотя, казалось бы, что там: 5 листов, 30 минут осознанного времени, не более. Почему так?

В своей карьере я работала в таких компаниях, как Авито, Rutube, МТС, сейчас работаю в Банке [NDA] — и везде у меня была команда разработки самостоятельна. 

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

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