Agile и scrum для современного человека




Содержание страницы

Scrum (Agile) Что такое Scrum?

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

В основе лежат короткие ежедневные встречи — Scrum и циклические 30-дневные встречи, называемые Sprint. Во время ежедневного Scrum’a каждому члену команды задаются только 3 вопроса:

Что было сделано с последнего Scrum’a?

Что вы будете делать между этой и следующий встречей Scrum?

Что мешает вам выполнять работу?

Главные принципы Scrum

Индивидуализм и взаимодействие важнее строгих процессов и методов.

Работающее ПО важнее сложной документации.

Взаимодействие с заказчиками важнее контрактных договоренностей.

Готовность изменить важнее следованию плану.

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

Девизом Scrum’a можно считать следование здравому смыслу.

Построение команды

Команда — главная движущая сила проекта, это источник продуктивности и креативности.

Команда, которая будет участвовать в ежедневных Scrum’ах должна состоять из 7 плюс-минус 2 человека. Большее число не рекомендуется, лучше разделить на несколько команд. Scrum Master (или, более понятно – Project manager) ведет эту встречу. Члены команды называются «свиньями» и только они имеют право говорить. На встречах могут присутствовать молчаливые посетители — «курицы», которые такого права лишены. Scrum встречи должны быть короткими, опоздания не приветствуются. Кен Швабер (Ken Schwaber, автор книги «Agile Project Management with Scrum») на своих тренингах предлагал вводить практику наказания «рублем», когда каждый опоздавший платит по доллару или евро, собранные деньги впоследствии он отдавал бездомным на улице.

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

Scrum Master и управление проектом

Поскольку в основе Scrum’a лежат ежедневные встречи и 30-дневные циклические встречи, называемые Sprint, все возникающие организационные и технические проблемы всем хорошо видны.

Scrum-структура

В конце каждого Sprint’a команда должна демонстрировать заказчику готовый запускаемый файл. Требования на функциональность должны были быть определены в начале этого Sprint’a месяц назад и не должны были меняться в течение этого времени. Эти требования отображаются в бэклоге — отдельной таблице с указанием того, что нужно сделать и сколько этой займет времени.

Успех Scrum’a зависит во многом до деятельности Scrum Master’a. В числе его главных задач и особенностей деятельности:

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

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

Увеличивать продуктивность команды любыми возможными способами.

Мертвый Scrum Master — бесполезный Scrum Master.

Плохой опыт будет заметен сразу, хороший — незаметен.

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

Во-первых. это промышленный процесс. В настоящее время в нем нет места гениям-одиночкам, кроме как в отделах R&D. Также, как не бывает разработчиков-одиночек или замкнутых команд. Это анахронизм.

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

В-третьих. Усовершенствование процессов в компании должно происходить ежедневно. Понемногу, но постоянно. Компании, остановившиеся в своем развитии (пусть даже на уровне CMMI 5) – обречены. И дело даже не в том, что компания останется на месте, в то время как ее конкуренты уйдут вперед. Одна из основных причин постоянной работы над улучшениями то, что без постоянного поддержания процессы имеют свойство деградировать, причем достаточно быстро.

В-четвертых. Улучшение – дело каждого сотрудника. Грамотно поставленные процессы и следование принятой в компании методологии облегчают жизнь, а не усложняют ее. И если у изменений нет поддержки «снизу», то провал изменений, инициированных топ-менеджментом – неминуем.

Главная ошибка Agile-трансформаторов: почему Product Manager и Product Owner — это не один человек

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

«Да что этот пр*д*кт себе позволяет?» — воскликнут на этот раз топ-менеджеры и цифровые трансформаторы со стажем и начнут кидаться в меня маркерами и блокнотами для флипчарта, или чего у них там в избытке осталось после процесса Agile-трансформации?

Ведь мы касаемся скользкой темы: на территории СНГ профессия менеджера по продукту считается новой, в профессиональном сообществе ещё не выработалось её чёткое определение, а функциональность «продакта» разнится от компании к компании.

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

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

Что же было раньше

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

В 1931 году Нил МакЭлрой, в те годы президент Procter & Gamble, в своей записке расписал обязанности новой единицы в компании — Brand Man. Диапазон ее ответственности в значительной степени совпадал с современным представлением о функции менеджера продукта в сфере ИТ. По забавному стечению обстоятельств в этой записке МакЭлрой затрагивает проблему, близкую той, которую я решил поднять в этой статье.

Долгие годы продакт-менеджмент развивался в сфере производства товаров повседневного спроса, но позднее, в начале 1980-х годов, эта функция была применена в области производства программных продуктов выпускником P&G, бывшим «брендменом». После этого ранние технологические компании, такие как Microsoft, стали перенимать эту модель.

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

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

Как стало теперь

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

С распространением последнего менеджеры продукта, иногда менеджеры проекта, во многих случаях преобразовались во «Владельцев Продукта».

Так назвали Scrum-роль, которая предполагает «ответственность за достижение максимальной ценности продукта» и управление беклогом, включая обеспечение доступности и ясности его элементов для всех.

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

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

В чем суть проблемы

Когда новоиспеченному Product Owner приходится балансировать, совмещая две роли, возникают сложности. Если в организации происходит Agile-трансформация и менеджер продукта принимает на себя новые обязанности, старые чаще всего тоже остаются в его сфере ответственности.

Как владельцу продукта ему нужно донести до команды разработки видение целиком, ответить на все «Почему?», «Зачем?» и «Как?», прописать пользовательские истории, «отбиться» от стейкхолдеров, приоритезировать и почистить беклог, поучаствовать в скрам-событиях.

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

В итоге, сложив обе стороны, мы увидим, что на самом деле это работа для двух специалистов. Но ее приходится выполнять одному.

«Но Scrum же — такой замечательный фреймворк, он позволяет оптимизировать работу, именно поэтому совмещение двух ролей возможно», — скажут некоторые. К сожалению, это не так. На практике «тактико-стратегическое» балансирование заканчивается на одной стороне. Либо «владелец продукта» увлекается исследованиями, взглядом в будущее, теряя контакт с командой разработки.

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

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

Может быть, есть исключения?

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

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

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

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

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

В чем причина

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

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

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

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

Это простые концепции, но руководство многих компаний не учитывает их при построении организационной структуры.

Что же делать

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

Владелец продукта — очень важная роль, которая будет исполняться в тесном тандеме с менеджерами продукта с одной стороны и командой разработки — с другой. Ему может быть делегировано «представительство продукта» перед разработчиками и многими стейкхолдерами, а также все активности, описанные в руководстве по Скраму, в то время как продакт-менеджер и его команда сосредоточатся на стратегии и проработке видения продукта.

Тут возникают закономерные вопросы. Не будет ли функционал этих ролей пересекаться? Как разграничить ответственность? За кем последнее слово?

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

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

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

Можно ли сказать, что архитектор — «босс» прораба? Нет, но он вправе требовать и контролировать исполнение с целью достижения поставленной цели. Он может периодически появляться на объекте, пояснять детали проекта и интересоваться деталями процесса постройки.

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

При желании вам не составит труда соотнести эту аналогию со схемой «продакт-менеджер — продакт-оунер — команда разработки», которую я предлагаю.

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

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

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

Некоторые скажут: «Product Owner — это авторитет, только к нему все идут, только он решает все вопросы». Некоторые испуганно воскликнут: «А вдруг это уже и не Скрам?»

Я отвечу: «Вам шашечки или ехать?»

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Примеры онлайн курсов Strategium.Space по теме разработки стратегий и управленческим инновациям

Быстрое построение бизнес моделей (экспресс-онлайн-курс)

Бесплатный курс по стратегиям развития организации

Разработка стратегии развития по SCRUM

Аудит системы стратегического управления компанией. Практикум

Наши эксперты

Дмитрий Иванович Рыцев

+ Директор консультационной компании Совершенные индустрии

+ Ведущий блога о стратегическом управлении Dynamic Strategy

+ Разработчик Периодической системы стратегических элементов

+ Автор научных статей и публикаций по теме управления компаниями

+ Разработчик системы бизнес-моделирования Dynamic Business Model

+ Разработчик показателя оценки систем управления Strategium Space Score

+ Практик и исследователь систем управления организациями

+ Master of Business Administration, California State University

Отзывы о наших услугах и разработках

Занимаюсь стратегическим планированием с 2009 года и нахожу эту тему очень интересной и захватывающей по масштабу, охвату и результатам. В марте 2018 года прошла онлайн курс «Аудит системы стратегического планирования» на портале Strategium.Space. И получила интересные результаты. Спасибо Strategium.Space и его создателю Дмитрию Рыцеву за весомый вклад в развитие стратегического планирования на территории стран СНГ.

Lazzat Irgalieva (Kazakhstan)

Вы делаете очень хорошее дело. Особенно для России. Профиль vk.com.

Marina Rosen (Ирландия)

Сразу пришла мысль использовать подобный «визуалистический» подход к собственным разработкам в области управленческого консультирования. Профиль в LinkedIn.

Евгений Труфанов (Россия)

Даже в Африке я видел, что выработка стратегии — это хорошо структурированный процесс. Профиль в LinkedIn.

Александр Самарин (Швейцария)

Спасибо большое. Выводы очень близки к реальности. В настоящее время назрела необходимость в улучшении, чем мы будем и заниматься, надеюсь, что не без Вашей помощи. Karabalta Ore Mining Combine (Renova Group).

Азат Талипов (Кыргызстан)

Добро пожаловать на Strategium.Space!

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

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

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

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

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

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

Обзор онлайн-курсов Strategium.Space

Основные онлайн курсы программы

Личное планирование — наша зона ответственности: онлайн курс по разработке личной стратегии

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

Мы адаптировали методы стратегического управления, которые могут быть применимы для личного планирования, добавили специфические подходы к разработке планов, и создали курс “Как составить личный план”.

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

Онлайн курс по теме «Разработка стратегии корпорации, бизнеса, функции или подразделения»

Разработка стратегии организации — наша основная компетенция и этому посвящен отдельный курс под названием Стратегия развития и ее разработка с применением подхода SCRUM. Это действительно новое слово в деле разработки стратегий развития.

В этом курсе мы объединили три, казалось бы, разные вещи:

  1. Процесс разработки стратегии развития
  2. Сложный продукт этого процесса — саму стратегию
  3. Гибкую методологию разработки сложных продуктов SCRUM, которая входит в семейство Agile подходов.

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

Онлайн курс «Стратегическое управление»

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

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

Вспомогательные и специализированные онлайн курсы программы

Аудит стратегического управления — старт вашего консалтингового бизнеса

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

Мы разработали подробную методологию проведения аудита этой важной части системы управления. Открытая для публики часть этой методологии называется Strategium Space Score (читается: стратегиум спейс скор).

После изучения этого курса вы сможете самостоятельно провести аудит стратегического управления в вашей организации и это ваш легкий старт в области стратегического консалтинга. Вы сможете определять Strategium Space Score для ваших потенциальных клиентов и определять уровень развития их систем управления.

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

Расширенный онлайн курс по бизнес моделированию

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

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

Внедрение системы управления стратегией развития в организациях

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

Кто эти люди? Как правило, это консультанты по управлению, специалисты в области организационного развития и в области внедрения систем управления.

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

Уникальный онлайн курс про динамические способности фирмы

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

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

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

НОВОЕ В НАШЕМ БЛОГЕ

Проект глобальной системы управления экономикой Strategium Space Globe (#rytsevproject)

Проект создания методологии и инфраструктуры для перехода к новому экономическому укладу. Цель проекта — сбалансированное, безопасное и устойчивое развитие человечества.

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

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

Принцип ограниченной интенциональности в реализации стратегий

Что такое многослойная природа организации, принцип ограниченной интенциональности и как они определяют требования к содержанию и реализации стратегий.

Новейшие методы управления в практике компаний на примере внедрения системы стратегического менеджмента

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

Главная ошибка Agile-трансформаторов: почему Product Manager и Product Owner — это не один человек

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

«Да что этот пр*д*кт себе позволяет?» — воскликнут на этот раз топ-менеджеры и цифровые трансформаторы со стажем и начнут кидаться в меня маркерами и блокнотами для флипчарта, или чего у них там в избытке осталось после процесса Agile-трансформации?

Ведь мы касаемся скользкой темы: на территории СНГ профессия менеджера по продукту считается новой, в профессиональном сообществе ещё не выработалось её чёткое определение, а функциональность «продакта» разнится от компании к компании.

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

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

Что же было раньше

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

В 1931 году Нил МакЭлрой, в те годы президент Procter & Gamble, в своей записке расписал обязанности новой единицы в компании — Brand Man. Диапазон ее ответственности в значительной степени совпадал с современным представлением о функции менеджера продукта в сфере ИТ. По забавному стечению обстоятельств в этой записке МакЭлрой затрагивает проблему, близкую той, которую я решил поднять в этой статье.

Долгие годы продакт-менеджмент развивался в сфере производства товаров повседневного спроса, но позднее, в начале 1980-х годов, эта функция была применена в области производства программных продуктов выпускником P&G, бывшим «брендменом». После этого ранние технологические компании, такие как Microsoft, стали перенимать эту модель.

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

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

Как стало теперь

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

С распространением последнего менеджеры продукта, иногда менеджеры проекта, во многих случаях преобразовались во «Владельцев Продукта».

Так назвали Scrum-роль, которая предполагает «ответственность за достижение максимальной ценности продукта» и управление беклогом, включая обеспечение доступности и ясности его элементов для всех.

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

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

В чем суть проблемы

Когда новоиспеченному Product Owner приходится балансировать, совмещая две роли, возникают сложности. Если в организации происходит Agile-трансформация и менеджер продукта принимает на себя новые обязанности, старые чаще всего тоже остаются в его сфере ответственности.

Как владельцу продукта ему нужно донести до команды разработки видение целиком, ответить на все «Почему?», «Зачем?» и «Как?», прописать пользовательские истории, «отбиться» от стейкхолдеров, приоритезировать и почистить беклог, поучаствовать в скрам-событиях.

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

В итоге, сложив обе стороны, мы увидим, что на самом деле это работа для двух специалистов. Но ее приходится выполнять одному.

«Но Scrum же — такой замечательный фреймворк, он позволяет оптимизировать работу, именно поэтому совмещение двух ролей возможно», — скажут некоторые. К сожалению, это не так. На практике «тактико-стратегическое» балансирование заканчивается на одной стороне. Либо «владелец продукта» увлекается исследованиями, взглядом в будущее, теряя контакт с командой разработки.

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

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

Может быть, есть исключения?

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

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

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

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

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

В чем причина

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

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

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

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

Это простые концепции, но руководство многих компаний не учитывает их при построении организационной структуры.

Что же делать

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

Владелец продукта — очень важная роль, которая будет исполняться в тесном тандеме с менеджерами продукта с одной стороны и командой разработки — с другой. Ему может быть делегировано «представительство продукта» перед разработчиками и многими стейкхолдерами, а также все активности, описанные в руководстве по Скраму, в то время как продакт-менеджер и его команда сосредоточатся на стратегии и проработке видения продукта.

Тут возникают закономерные вопросы. Не будет ли функционал этих ролей пересекаться? Как разграничить ответственность? За кем последнее слово?

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

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

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

Можно ли сказать, что архитектор — «босс» прораба? Нет, но он вправе требовать и контролировать исполнение с целью достижения поставленной цели. Он может периодически появляться на объекте, пояснять детали проекта и интересоваться деталями процесса постройки.

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

При желании вам не составит труда соотнести эту аналогию со схемой «продакт-менеджер — продакт-оунер — команда разработки», которую я предлагаю.

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

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

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

Некоторые скажут: «Product Owner — это авторитет, только к нему все идут, только он решает все вопросы». Некоторые испуганно воскликнут: «А вдруг это уже и не Скрам?»

Я отвечу: «Вам шашечки или ехать?»

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Agile и Scrum для современного человека.

Agile и Scrum для современного человека

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

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

Agile это философия , это некий образ мышления , который фокусируется на четырех простых принципах , которые закреплены в документе называемом Agele Manifest.

Слово Agile еще довольно молодо и родилось в 2001 году в Американском штате Юта , совсем маленькой горной деревне Сноуберд ,которое и объеденило в себе некий современный подход к разработке программного обеспечения.

Авторы Agile манифеста- Dave Thomas, Kent Beck , Jeff Sutherland, Mike Beedle, Ken Schwaber, Arie van Bennekum и др.

Начинание данному «явлению» было положено из отрасли информационных технологий , где в 2001 году группой людей из ИТ индустрии и было объявлено понимание о фокусировке в работе на четырех постулатах или идеях манифеста.

-Сами люди и взаимодействия между ними важнее процессов и инструментов.

-Рабочее программное обеспечение приоритетнее документации.

-Сотрудничество с клиентами приоритетнее согласования условий контакта.

— Гикая готовность внести изменения в приоритете , нежели придерживаться первоначального плана.

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

В 2001 году это прозвучало практически как взрыв бомбы , потому что во многом бизнес был сфокусирован на контрактах , документации и подписании документов — родоначальники же Agile подхода показали нечто иное.

В переводе на русский язык agile – означает расторопный , живой (alive) , гибкий (flexible). В применение к проектам и образу мышления — Agile подразумевает проактивность, то есть flexible с напором.

То есть это образ мышления — так можно думать-либо не думать! Agile подход нельзя делать! Им можно быть либо не быть!

Это бинарная вещь-либо –ДА! Либо –нет! Более того – мышления с присущей ей системой ценностей , несомненно похож на некую философию или да же культуру или религию-где так же присутствуют алгоритмы определенных установок, поддерживаемых человеком- его верой , влиянием на него и несомненно поведением.

Часто многие это сравнивают с буддизмом и веганством.

— Буддисты в своем поведении и вере направлены на просветление, медитацию, умеренность во всем и не причинении вреда и злобы другим.

— Веганы -нацелены на приоритет жизни любого живого организма и существа , огромно заботы о нем и экологии земной цивилизации.

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

Попробуем подвести резюме философии -Agile-

— Agile-‘это объединенная группа профессионалов , достигающих успеха без начальника, вместе с клиентом и постоянной готовностью изменения плана , максимально быстрый запуск действующего продукта полностью устраивающего и клиента и заказчика.

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

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

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

Итерация представляет собой небольшой программный проект . После завершения проделанной итерации группа начинает переоценку приоритетов разработки проекта. Часто работа команды Agile проекта происходит в формате и рамках одного офиса ( bullhen) , где происходит общение по принципу «лицом к лицу», где иногда присутствует м сам представитель заказчика , определяющий и диктующий требования к продукту

. Внутри Agile много- framework ( в переводе –каркас). Это если говорить опять простым языком — есть большая философия с верху и есть конкретные инструменты исполнения.

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

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

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

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

Product Owner — все это делает посредством сбора всех требований , идей и прочих «хотелок» в единый документ или список , который называется- Product Backlog.

Задача Product Owner ысе это собрать во едино и выставить по приоритету- сверху положить самые важные задачи , ниже расположить менее важные задачи. Далее команда которая непосредственно будет делать продукт , а в Scram принято брать команды небольшого размера –от 3 до 9 человек , для того что бы они могли успешно между собой коммуницировать и именно соответствовать первому принципу манифеста Agile (Потому как если команда состоит из 15 -20 людей считается не совсем эффективной)_ — приходит на собрание , которое называется Sprint Planning Meeting и выбирает из Backlog приоритетные задачи к исполнение , в том объеме сколько они предположительно успеют выполнить в ближайшем «спринте».

«Спринтом» в Scrum называется итерация, то есть отрезок времени. Очень великолепно , когда мы набираем Sprint Backlog не просто списком задач а они объединены вокруг одной цели , так называемой Sprint Goal.

Принято работать таким образом , что бы не менять во время «спринта»-цель и продолжительность. ( Если договорились -2 нд, то и работаем — 2 нд), если не удалось выполнить в срок , то считаем «спринт» -провальным.

Делаем- Retrospective и «учимся» , делаем выводы почему мы не успели и как в следующий раз спланировать «спринт» таким образом что бы наши действия были успешными.

Каждый день проводится Daily Scrum Meeting на котором вся команда вместе с Scrum Master и Product Owner собираются для того чтобы понять на сколько успешно команда приближается к цели «спринта».

Все участники отвечают на три вопроса-

1 Что он сделал з а вчерашний день для достижения цели?

2.Что он планирует сделать сегодня?

3.Какие у него есть преграды или помехи на пути достижения цели «спринта».

Встреча имеет место быть ежедневно , с длительность не более 15 минут

В течении «спринта»-мы можем проводить встречу , которая называется Backlog Refinement , собравшись на этой встрече команда просматривает верхнюю часть Backlog задают Product Owner уточняющие , наводящие чтобы лучше разобраться в задачах , которые ближайшее время команде предстоит делать и делает предварительно оценку данных задач.

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

В конце когда команда устраивает Retrospective-который необходим для ответов на вопросы

— Что помогает нам быть более успешными?

-Помогает достигать целей в спринте, что нам мешает?

-От чего стоит избавиться? Чего стоит делать больше и пр?

— Что нас мотивирует и что нет ?

В Scrum существуют и имеет место следующие процессы — Принципы и ценности Scrum.