Читать книгу: «Управление продуктом. Российская практика», страница 2
Есть несколько особенностей в работе менеджеров продуктов, которые я встречаю в российских компаниях.
Сначала поговорим про широкий и часто нефиксированный спектр задач. Продакт-менеджер отвечает за исследования, планирование, определение приоритетов, управление ресурсами, взаимодействие с командой и др. Это требует объединения навыков из разных областей. Как следствие, происходит слияние продуктового и проектного управления. Чем сложнее бизнес-процессы и процессы согласования в компании, тем больше координационных задач выполняет продакт-менеджер, который берет на себя еще и роль руководителя проектов, и тем меньше времени у него остается на стратегический анализ и исследования. Если вы когда-нибудь видели календарь продакт-менеджеров в таких командах, то он состоит из бесконечных встреч и беготни. Часто на мероприятиях обсуждаются одни и те же вопросы, что приводит к потере времени. Менеджеры часто попадают в эту ловушку, создавая иллюзию активности, но не достигая реальных результатов.
Я нередко встречала продакт-менеджеров, которые просили в штат еще и руководителей проектов, бизнес-аналитиков, владельцев продуктов, так как «не успевали со всеми задачами». Проблема в том, что эту просьбу часто не одобряет руководство, которое придерживается подхода «сначала покажи результат, потом проси людей». Замкнутый круг.
С одной стороны, правы продакт-менеджеры. Во-первых, ожидание результатов без предоставления дополнительных ресурсов затрудняет достижение поставленных целей. Во-вторых, отсутствие поддержки и ресурсов вызывает демотивацию и стресс. Когда руководство требует результатов, но не предоставляет необходимых инструментов для их достижения, возникают напряжение и чувство беспомощности. Чтобы разорвать этот порочный круг, необходимы изменение подхода к управлению и понимание важности инвестиций в команду на ранних этапах. С другой стороны, правы руководители. Для них важны последствия действий через влияние на бизнес-результат. Об этом подробно мы будем говорить в главе 2.
В сложных коммуникациях неизбежно возникают конфликты интересов, которые могут быть как здоровыми, так и токсичными. Опасность токсичных конфликтов заключается в том, что люди начинают избегать друг друга, стремясь достичь своих целей через подрыв авторитета или использование «культуры отмены». Я убеждена, что программа российских школ должна включать развитие эффективных коммуникаций. Для продуктовых менеджеров особое значение имеют навыки влияния без формальных полномочий, стрессоустойчивость и мягкие навыки (soft skills). Командные конфликты часто возникают из-за несоответствия ожиданий, о которых не говорят. Про понимание ожиданий и проактивную позицию мы поговорим в главах 3, 4 и 18.
Многие российские компании начинают задумываться над своей долгосрочной стратегией и поиском значительных возможностей и приходят к необходимости продуктовой трансформации. Традиционные методы стимулирования роста через продажи, маркетинг или конкурентное ценообразование больше не работают. Компании, ориентированные на продажи, часто испытывают трудности с привлечением клиентов, которые не видят их ценность. Маркетинговые расходы постоянно растут, а конкуренция (в первую очередь по цене) приводит к бесконечной гонке, медленно снижающей прибыль. Крупные экосистемы концентрируют вокруг себя рынок, формируя барьеры для входа. Конкурентная борьба за платежеспособные сегменты становится жесткой.
Новая стратегия предполагает изменения не только в продукте, но и в подходах к работе. Самый большой риск заключается в том, что компании не подготовлены к этим изменениям ни с точки зрения компетенций, ни с точки зрения процессов, ни с точки зрения организационной структуры.
В ряде случаев продуктовая трансформация превращается в пустой лозунг. Формально создаются продуктовые команды, но фактически трансформация не получает поддержки. На собраниях декларируется приверженность продуктовому подходу, однако руководство и ключевые заинтересованные лица не оказывают продакт-менеджерам необходимую помощь, не выделяют ресурсы, продолжают придерживаться старых практик и не стремятся к реальным изменениям, способным пошатнуть их статус-кво.
В российских компаниях очень развита асимметрия во властных полномочиях: существуют ключевые люди, которые могут существенно повлиять на успех вашего продукта, используя свои возможности. Они обладают полномочиями одобрять бюджеты, блокировать изменения, принимать единоличные решения или, наоборот, игнорировать те изменения, которые не в зоне их интересов. В такой ситуации продакт-менеджер чувствует фрустрацию: его решения и усилия часто обесцениваются, поэтому он подстраивается под культуру и становится владельцем продукта или проектным менеджером. Эти вопросы мы подробнее рассмотрим в главе 2.
КАК ПОЛУЧИТЬ БОЛЬШЕ ПОЛЬЗЫ ОТ ЭТОЙ КНИГИ?
Одной из причин, по которым я начала писать, было желание выкристаллизовать многое из того, что я узнала за последнее десятилетие или около того. Для этого я создала телеграм-канал Strategic Move, но посты там не всегда представляют собой структурное освещение проблемы, хотя я считаю, что это отличный формат для саморефлексии, которая очень важна для менеджера продукта.
Во-первых, я признаю, что постоянно учусь и, как говорил Эйнштейн, «по мере того, как расширяется круг наших знаний, расширяется и окружающая его тьма». Рефлексия позволяет структурировать знания и задавать себе новые вопросы.
Во-вторых, я рекомендую читать эту книгу, не отвлекаясь на мессенджеры и тому подобные вещи. Концентрация – ключевой момент. Я обычно читаю рано утром, еще до начала работы, когда никто мне не мешает.
В-третьих, я уважительно отношусь к точке зрения другого человека, даже если с ней не согласна, но при этом она не нарушает моих границ. Конструктивная критика – способ учиться и становиться лучше, но тут ключевое слово «конструктивная», она должна быть аргументирована не на уровне чувств, а на уровне логики. Любую обратную связь по этой книге вы можете направить мне на почту: jbilinkis@gmail.com.
Эта книга будет полезна продакт-менеджерам, которые хотят стать лидерами изменений в компаниях в состоянии продуктовой трансформации и адаптировать лучшие практики к их текущему контексту. Материал основан на моем опыте работы и консультирования, а также исследованиях и опыте российского сообщества. После множества часов консультаций и обучения я постаралась выделить паттерны поведения продакт-менеджеров в переходный период.
Итак, приступим.
Юлия Билинкис, спикер и консультант по продуктовой стратегии, https://t.me/strategic_move
Часть I. Зоны влияния продакт-менеджера, продуктовый подход и создание продуктовых команд
Глава 1. Подходы к управлению продуктом
Что труднее всего на свете видеть своими глазами? То, что лежит перед ними.
Иоганн Вольфганг фон Гете
ПЕРЕОСМЫСЛЕНИЕ РАБОТЫ: ОТ ФАБРИКИ ФУНКЦИЙ К ОБНАРУЖЕНИЮ ВОЗМОЖНОСТЕЙ
Шестнадцать лет назад я работала в компании, которая занималась внедрением программного обеспечения. В какой-то момент у акционеров возникло желание создать стартап и сделать облачный Service Desk. Я играла роль бизнес-аналитика. У меня были диплом по направлению «информационные системы и сети» одного из ведущих вузов страны, опыт написания множества технических заданий и оценки требований.
В то время никто еще не слышал про продакт-менеджеров, такой роли просто не было. Я, как бизнес-аналитик, должна была переводить видение заказчиков в требования для разработчиков. Как вы думаете, что мы тогда делали? Наверное, вы уже догадались: «пилили фичи». И мы даже не осознавали, что нам нужно заняться тестированием бизнес-модели продукта и первыми продажами.
Прошлый опыт определяет, как мы принимаем решения, наши действия и предпочтения. Как-то Абрахам Маслоу сказал: «Если единственный инструмент, который вы имеете, – молоток, то заманчиво рассматривать все как гвозди». Люди могут по умолчанию использовать знакомые им методы, которые срабатывали в прошлом. Нам постоянно казалось, что продукт еще не готов; в итоге полтора года мы работали на фабрике функций без обратной связи от рынка, мыслей о модели продаж и монетизации. Главное ограничение роста всегда смещается в зону некомпетентности команды – «слепую зону», в которой команде не хватает экспертизы.
Это было начало 2000-х, и в свое оправдание могу сказать, что тогда опыта работы в стартапе почти ни у кого не имелось. В 1990-е мы стали свидетелями быстрого расширения технологических компаний, однако в 2001 году в США лопнул «пузырь доткомов» ровно потому, что старые методы больше не работали. Закрылось огромное количество интернет-стартапов, которые не смогли оправдать ожидания инвесторов и обеспечить соответствие продукта рынку. Это простимулировало появление новых подходов к управлению продуктом: Agile (гибкую разработку программного обеспечения) и Lean Startup (бережливый стартап).
Однако обо всем по порядку. Вы можете спросить: «Если не проводить исследования рынка, то как понять, какой продукт нужно делать?» На этот счет есть две теории.
Одна заключается в том, что идея – озарение предпринимателя, а сами бизнесмены – такой особенный класс людей, которые обладают даром предвидения. Часто приводят высказывание Стива Джобса: «Очень трудно создавать продукт для конкретных людей. Чаще всего люди сами не знают, чего хотят, пока ты не покажешь им это. Вот почему я никогда не полагаюсь на исследования рынка. Наша задача – прочесть то, чего еще нет на странице». Конечно, Джобс был визионером, готовым рисковать, но было ли это свойство даром свыше или следствием его характера и прошлого опыта?
Мне очень нравится речь Стива Джобса перед выпускниками Стэнфорда, в которой он поделился еще одной важной мыслью.
Нельзя соединить временные точки заранее; увидеть связь между ними возможно, лишь оглядываясь назад. Надо просто верить, что точки как-то соединятся в будущем. Ничего из того, что я тогда узнал, казалось бы, не могло иметь никаких практических последствий для моей жизни. Но десять лет спустя, когда мы создавали первый компьютер «макинтош», все это мне пригодилось. Мы заложили всю изученную мной премудрость в нашу машину. Это был первый компьютер, владеющий каллиграфией. Если бы я не наткнулся на тот курс в колледже, у «мака» никогда бы не было множества разных типов шрифтов. И поскольку Windows в этом отношении просто копирует «макинтош», возможно, что ничего этого не было бы ни на одном персональном компьютере. Итак, нельзя соединить временные точки заранее; увидеть связь между ними возможно, лишь оглядываясь назад. Надо просто верить, что точки как-то соединятся в будущем.
Эта цитата наводит меня на мысль, которая была описана в концепции экономиста Израэля Кирцнера об обнаружении ошибочно нераспознанных возможностей в его книге «Конкуренция и предпринимательство»2. По сути, идея Кирцнера вращается вокруг предпринимательской функции выявления возможности получения прибыли, которая обусловлена асимметрией информации на рынке. Согласно ему, предприниматели, благодаря своей бдительности и дальновидности, могут распознать возможности получения прибыли, которые другие упустили из виду или недооценили. Поэтому часто бизнесмены начинают стартапы с осознания и глубокого понимания проблемы, с которой сталкиваются лично: они – эксперты в предметной области. Я много раз была свидетелем тому, как какое-то стоящее предложение возникало у экспертов из-за объединения старых знаний в новые комбинации, то есть благодаря умению создавать новые взаимосвязи.
У Питера Тиля, соучредителя PayPal, в книге «От нуля к единице. Как создать стартап, который изменит будущее» есть интересная глава о секретах, которую он открывает словами: «Каждая из самых известных и знакомых сегодня идей когда-то была неизвестной и неожиданной. Лучшие предприниматели знают: в основе любого великого бизнеса лежит секрет, скрытый от внешнего мира».
Например, всем известный продукт Miro, который сейчас обслуживает 99 % компаний из списка Fortune 100 и имеет более 50 млн пользователей, начался в 2011 году с идеи Андрея Хусида и Олега Шардина3 перенести интерактивную доску в браузер для «визуального сотрудничества». На эту идею их натолкнула работа в креативном агентстве. Они поняли, что люди могут общаться визуально и этот способ во многих случаях лучше закрывает задачу совместного творчества по сравнению с обычным обменом сообщениями. Картинка стоит тысячи слов – такова была первоначальная идея Miro. Однако ей потребовалось четыре года, чтобы достичь соответствия продукта рынку после разработки первой версии решения.
Могу сказать, что знание ошибочно нераспознанных возможностей, которые и становятся «секретом», отличается от простой идеи продукта или галлюцинации основателя. Это первое, что нужно понимать, когда вам приводят статистику провала стартапов (девять из десяти «умирают» и закрываются). Ключевое слово тут – «возможность»: возможность создать жизнеспособную масштабируемую бизнес-модель.
Теперь представим, что вы не основатель, а работаете в продуктовой команде, не общаетесь с клиентами, не пользователь своего продукта или не имеете опыта в своей предметной области. Какова вероятность обнаружения и реализации вами стоящей возможности?
В итоге ложное убеждение в том, что проблема понятна, приводит к тому, что создаются ненужные решения, а попытка угнаться за большим рынком – к детищу Франкенштейна, собранному из кусочков разных пользовательских сценариев для разных сегментов рынка. Однако даже если вы понимаете нежизнеспособность такого подхода, не факт, что это ясно вашему руководителю, который «надел шляпу предпринимателя».
В корпорациях часто этап анализа рынка, сегментации и выявления потребностей пропускается или выполняется для галочки через заполнение бесполезных шаблонов. Ведь ставка уже сделана, бюджеты защищены, ресурсы выделены, дано обещание выпустить продукт до конца года и получить первую прибыль в краткосрочной перспективе. Начинается этап «пиления фич». Что делать в этой ситуации менеджеру продукта?
ИЗМЕНЕНИЕ ПОДХОДОВ: КАК МЫ ВНЕДРЯЛИ AGILE И SCRUM
Вернемся к нашему стартапу. Итак, как можно описать «пиление фич»?
Во-первых, тогда у меня не было ни знаний, ни ресурсов, чтобы проводить качественные исследования рынка. Основное, что приходило в голову, – сравнить продукты конкурентов, почитать о них отзывы в интернете и скопировать то, что казалось удачным решением. Более того, так же казалось и моему руководителю, а значит, соответствовало его ожиданиям от моей работы.
Во-вторых, мы были под постоянным давлением требований как можно быстрее выпустить готовую версию на рынок и начать продажи. Однако сроки запуска постоянно сдвигались. Как перфекционист, я винила себя в том, что недостаточно хорошо выявляла и описывала требования, ведь они постоянно менялись под натиском новых идей. В течение года мы несколько раз «переобувались» и делали то Service Desk, то систему для поддержки командной работы, то корпоративную электронную почту. Получив выгорание на рабочем месте, я уволилась. Нужно ли говорить, что проект в итоге закрылся примерно через два года после того, как я оттуда ушла.
Процесс работы в описанной мной компании показан на рис. 1.1.
Рис. 1.1. Процесс разработки продукта, пример
В то время многие еще применяли водопадную модель с длинными циклами разработки. Ключевым ограничением была низкая скорость разработки и вывода готового продукта на рынок (time to market). Быстро что-то изменить было не только сложно, но и дорого. Водопадная модель подходит для ситуаций с очень предсказуемыми требованиями или долгосрочными горизонтами планирования, однако для проекта с меняющимися требованиями нужны более гибкие подходы. Надо отдать должное: во всех командах, в которых я работала, мы шли в ногу со временем от водопада навстречу Agile.
В 2001 году появился «Agile-манифест»4. Этот подход базируется на четырех ключевых ценностях, которые помогают компаниям стать гибкими.
1. Люди и их взаимодействие важнее, чем рабочие процессы и инструменты.
2. Функционирующий продукт важнее, чем регламенты, написание инструкций, задания.
3. Сотрудничество с заказчиком важнее, чем просто подписание договора.
4. Адаптивность и оперативная реакция важнее, чем слепое следование плану.
Agile подразумевает итеративный процесс, в котором сначала создается базовое решение, которое затем со временем расширяется. Допустим, вы хотите сделать сайт для электронной торговли. В Agile вы не будете тратить месяцы на создание ресурса, вместо этого вы разработаете базовую первую версию – MVP (Minimum Viable Product – минимально жизнеспособный продукт). Возможно, просто страницу, чтобы начать продавать. Затем вы итеративно будете ее усовершенствовать, добавляя все больше разделов и функций. Эти итеративные улучшения называются инкрементами или потенциально готовыми к поставке приращениями продукта (PSPI, Potentially Shippable Product Increment) – ценностью, предоставляемой клиенту через элементы бэклога продукта, которые были выполнены во время спринта.
Agile-манифест на самом деле не описывает выполнение работы, то есть сам процесс. Когда компании решают использовать эти принципы, они должны выбрать его самостоятельно. Можно расценивать Agile как зонтик, под которым находятся процессные фреймворки, соответствующие его принципам и ценностям: Scrum, Kanban, LeSS, SAFe и др. Большинство технологических компаний не следуют ни одному из них буквально, а используют гибридные подходы, ориентированные на практические результаты, в виде набора практик (рис. 1.2).
Рис. 1.2. Agile как образ мышления и набор практик5
Мне нравится визуализация Ахмеда Сидки – основателя Международного Agile-консорциума, который изобразил континуум от образа мышления, ценностей Agile-манифеста к принципам и практикам.
Например, существует множество компаний, которые рассматривают гибкую разработку как серию «небольших водопадов». А есть компании с сильной функцией DevOps и микросервисной архитектурой, в которых частота релизов очень высока. В последнем случае начинает размываться смысл самого спринта, и процесс разработки эволюционирует от Scrum к линейному бэклогу и работе с использованием канбан-досок. Я всегда восхищаюсь командами разработки, которые научились выпускать релизы часто, идеальный вариант – несколько раз в день. Это служит важным фундаментом для успешного перехода к продуктовому подходу.
Большинство продуктовых команд работает по Scrum или в гибридном подходе Scrum + Kanban. Основным артефактом для работы становится бэклог продукта – список всех желаемых работ, обычно в виде пользовательских историй (user story), отсортированных в порядке приоритета. Он развивается по мере появления новых требований (или идей в нашем случае). В начале каждого спринта происходит планирование, в результате которого пользовательские истории переносятся из бэклога продукта в бэклог спринта с оценкой объема работ. Затем команда встречается на ежедневном стендапе, где делится ходом работы. В конце спринта проводится его ретроспектива.
Самый популярный фреймворк на данный момент – Scrum Кена Швабера и Джеффа Сазерленда. В его основе лежит идея работы короткими циклами – спринтами, в которых принимают участие и бизнес, и ИТ.
Спринты – регулярные ограниченные промежутки времени, в течение которых Scrum-команда выполняет заданный объем работы. Средняя продолжительность – 2–4 недели. По итогам команда обязуется создать новую версию продукта с приростом ценности для клиента (функционала) – инкрементом. Спринты выпускаются в определенные даты. Все это приводит к упорядочиванию работы ИТ. Поскольку вы действуете итеративно и попутно создаете продукты, вы можете предоставить больше гибкости своим конечным пользователям и клиентам и вовлечь их в процесс разработки и тестирования.
Пользовательская история – короткая формулировка намерения пользователя и того, что продукт должен сделать для него, поддержанная описанием функциональных требований и прототипом интерфейса. Если что-то не добавляет ценности клиенту, то это не может считаться пользовательской историей и будет оставаться задачей, подзадачей или просто требованием.
Формат пользовательской истории выглядит следующим образом: «Как [тип пользователя]; я хочу [некая цель]; так, чтобы [некая причина]». Рассмотрим все пункты подробнее.
• Как [тип пользователя]. В этом разделе указывается, кто пользователь. Это помогает лучше понять его точку зрения и потребности.
• Я хочу [некая цель]. Эта часть описывает, чего пользователь хочет достичь или какую функцию желает видеть в продукте. Она должна быть ясной и краткой, фокусироваться на желаемой функциональности, без подробностей реализации.
• Так, чтобы [некая причина]. Тут объясняется причина цели пользователя. Так мы обеспечиваем контекст и помогаем команде понять основную мотивацию, которая может иметь решающее значение для определения приоритетов и принятия решений.
Например, для сайта интернет-магазина пользовательская история может быть такой.
ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ: ОНЛАЙН-МАГАЗИН
Как клиент, я хочу иметь возможность просматривать подробную информацию о продукте, включая изображения, описание, цену и отзывы, чтобы принимать обоснованные решения о покупке.
Критерии приемки
• На странице продукта должны быть качественные изображения высокого разрешения, демонстрирующие продукт под разными углами, обеспечивающие четкое представление о его внешнем виде и функциях.
• Описание должно включать основные характеристики и быть структурировано так, чтобы включать краткую, но подробную информацию о ключевых функциях, спецификациях, размерах, материалах и любых других важных атрибутах, которые влияют на решение о покупке.
• Информация о ценах, включая базовую, любые применимые скидки, рекламные акции или пакетные предложения, должна отображаться на видном месте рядом с описанием продукта.
• Пользователи должны иметь возможность просматривать совокупные рейтинги и читать подробные отзывы тех, кто купил продукт. Система отзывов должна поддерживать материалы, отправленные проверенными пользователями, обеспечивая достоверность и подлинность.
• Клиенты должны иметь возможность фильтровать и сортировать отзывы по релевантности, дате, рейтингу или конкретным критериям.
Пользовательская история дополняется макетом интерфейса и нефункциональными требованиями к производительности, безопасности, отказоустойчивости (если применимо). Пользовательские истории могут быть сгруппированы в эпики, которые, в свою очередь, объединены в инициативы, а инициативы в темы.
Владелец продукта (Product Owner) – это ключевая роль в Scrum, отвечающая за максимизацию ценности продукта, создаваемого командой разработки. Он определяет приоритеты в бэклоге, собирает оценки трудозатрат, взаимодействует с заинтересованными сторонами для определения и удовлетворения их требований.
Все команды помешаны на планировании. Это неудивительно, ведь точные оценки позволяют прогнозировать сроки и бюджет проекта, на которые «коммитятся» владельцы продуктов. Сколько раз я участвовала во встречах, где все спрашивали: «Когда вы реализуете эту фичу?» Коммуникация статуса и сроков крайне важна, ведь по ней оценивается работа команды в фабрике функций.
Для каждой истории (либо в условных единицах – Story Points, либо в человеко-часах) выставляется оценка, которую дают разработчики. Поинты обозначают уровень сложности или трудоемкости реализации элементов бэклога продукта (пользовательской истории): один поинт – простую задачу, два – сложнее и т. д., однако для того, чтобы начать их использовать, необходим накопленный командой опыт разработки. Часто на этом этапе важно дробить истории, чтобы получить более точные оценки.
Для лучшего понимания нужно рассмотреть концепцию скорости работы (velocity). В конце каждого спринта команда суммирует оценки усилий, связанные с пользовательскими историями, которые были завершены за время спринта. Эта сумма называется скоростью: это количество поинтов, которое команда реализует за спринт. Таким образом, в начале вы как бы предполагаете или оцениваете, сколько поинтов вы можете набрать за спринт, но после пары спринтов вы сможете усреднить количество поинтов, а затем сделать вывод, что в среднем ваша команда может, например, набрать 15 поинтов за спринт. Это и есть скорость работы.
Для составления бэклога спринта команда берет пользовательские истории из бэклога продукта и обязуется доставить их за спринт. Это самый нижний уровень, на котором команды устанавливают приоритеты. В релиз (выпуск функциональности для пользователей) обычно попадают истории нескольких спринтов. Календарный план релизов представляет собой дорожную карту, которая часто выглядит как диаграмма Ганта с датами релизов.
Отдельно необходимо поднять вопрос качества планирования спринтов и релизов. Оно измеряется соблюдением сроков и соответствием требованиям пользовательской истории. При этом важно отслеживание качества не только в конце спринта, но и в процессе, а также проведение ретроспективного анализа. Этим тоже занимается владелец продукта.
Рис. 1.3. Пример Burndown Chart
Если скорость команды начинает падать, значит, она неправильно оценивает свои истории: берет на себя слишком много работы или кто-то заставляет ее это делать. Но если команда неожиданно обнаруживает, что у нее появляется много свободного времени, значит, ей следует сделать переоценку своих трудозатрат. Важный инструмент для налаживания темпа и прогнозирования скорости разработки – диаграмма сгорания задач, или Burndown Сhart.
Как следует из названия, диаграмма сгорания задач – это инструмент, показывающий, как быстро команда работает с пользовательскими историями. Они эффективны за счет того, что прогресс оценивается не в контексте потраченного времени, а в контексте оставшейся работы. Рекомендуется, чтобы оставшаяся работа уменьшалась более-менее равномерно по ходу спринта.
Один из популярных вопросов на собеседованиях: «Что делать, если команда отстает от графика?» Это головная боль владельца продукта и менеджера проекта. Тут можно вспомнить известный треугольник ограничений проекта, также называемый тройным ограничением, железным треугольником (рис. 1.4).
Рис. 1.4. Треугольник ограничений
Вот три основных ограничения (изменение одного из них обычно влияет на два других).
• Объем работ: определяет, что будет реализовано. Изменения объема могут повлиять как на время, так и на стоимость.
• Время: сроки и время, доступные для завершения проекта. Если временные ограничения ужесточены, может потребоваться больше ресурсов (увеличение затрат) или сокращение объема.
• Стоимость: включает бюджет, все ресурсы, необходимые для завершения задач, такие как рабочая сила, материалы, оборудование и накладные расходы. Увеличение бюджета может помочь уложиться в сжатые сроки или расширить объем работ, тогда как сокращение бюджета может потребовать уменьшения объема или продления сроков.
В центре треугольника находится качество, представляющее конечную цель: поддержание критериев приемки, несмотря на ограничения.
Итак, если команда отстает от графика, то допустимо сократить объем задач или перенести сроки запуска, однако это может плохо повлиять на бизнес-результат; добавить больше разработчиков (увеличить стоимость). Однако в последнем случае вы можете столкнуться с «мифическим человеко-месяцем» и законом Брукса – концепцией, которую описал Фред Брукс в своей книге «Мифический человеко-месяц: очерки по разработке программного обеспечения».
Идея добавления разработчиков в проект основана на предположении, что если один человек может выполнить задачу за определенное количество часов, то несколько человек могут выполнить ту же задачу за пропорционально меньшее количество часов. Однако при этом игнорируются сложности и накладные расходы, связанные с командной работой и координацией проекта.
Новым членам команды требуется время, чтобы они стали продуктивными. Это не только отнимает их собственное время, но и отвлекает время существующих членов команды, которым необходимо их обучать и интегрировать. По мере увеличения числа членов команды сложность и время, необходимое для общения и координации, растут в геометрической прогрессии. Каждый дополнительный участник увеличивает количество каналов связи и вероятность недоразумений или несогласованностей. И в целом не все задачи можно легко разделить между несколькими людьми.
Все это во многом исключает возможность реального варианта «сделать хорошо и быстро». В итоге приходится искать компромиссы, сокращать объем работ в угоду качеству, договариваться снова с заинтересованными сторонами.
Еще одним фактором, влияющим на сроки, становится задержка в работе другой команды, от результатов которой зависят ваши сроки. Часто она находится вне зоны контроля и влияния, и вопрос необходимо эскалировать.
Кто все вышеописанное будет делать и отвечать, если возникают сдвиги сроков, выпускается продукт, не отвечающий требованиям, и т. д.? Конечно, владелец продукта.
ВЛАДЕЛЕЦ ПРОДУКТА: ЗАДАЧИ И РОЛЬ В КОМАНДЕ
Я специально вынесла роль владельца продукта, а не менеджера продукта, в заголовок этого раздела. Между этими ролями есть существенная разница.
В команде выделяется роль владельца продукта, который должен отвечать за представление всех заинтересованных сторон и приоритизацию работ, уточнение требований и контроль сроков и бюджетов. Часто он берет на себя роль и Scrum-мастера, ответственного за соблюдение практик в команде и проведение мероприятий вокруг спринтов: планирование, обзор, ретроспективу, ежедневные статусы (стендапы). В подавляющем большинстве известных мне случаев владельцами продуктов становились системные аналитики, бизнес-аналитики и менеджеры проектов, которые и так выполняли функции планирования и администрирования задач, создания задач для разработчиков и тестировщиков.
Не стоит недооценивать ценность этой роли в контексте работы в разрозненных организационных структурах, на пересечениях зон влияния и ответственности. Организация представляет собой непростую систему, в которой степень сложности прямо пропорциональна количеству точек принятия решения.
Успешные владельцы продуктов часто помогают заказчикам конкретизировать видение и воплотить его в жизнь, работая со всеми заинтересованными сторонами.
Дело в том, что ресурс ИТ может быть общим (под ресурсом я понимаю сотрудников с необходимой специализацией и опытом: разработчиков, тестировщиков и т. д.) и делиться между множеством бизнес-заказчиков, а может быть выделенным под конкретного бизнес-заказчика.
Начислим
+15
Покупайте книги и получайте бонусы в Литрес, Читай-городе и Буквоеде.
Участвовать в бонусной программе
