Комментарии 5
Не складывается у меня картинка того, о чем вы рассказываете. Если есть возможность, дайте пожалуйста пояснения.
О какого рода проектах, продуктах идет речь, что вы называете "хотелками"? Если вы продаёте продукт или доступ к нему, то кто такие стейкхолдеры и заказчики? Если это пользователи и клиенты, то вроде бы неоткуда взяться частым встречам с ними. Если это заказчик, который платит деньги за реализацию нужных ему задач, то непонятно про статус "хотелок" и отказ в выполнении. Если, обратно, не заказчик, а рандомные люди заводят хотелки, то что делают в этих хотелках сроки, как их угораздило сюда затесаться?
Фиксация всех “хотелок” заказчика, что не даёт финальной реализации отклониться от первоначальной задумки и критично выходить за бюджет. Это исключает ситуации, когда заказывали велосипед, а получили мопед по цене автомобиля.
Если хотелку завёл хотельщик, то не очень понятно про бюджет и тем более про задумку. На гитхабе я закинул фича-реквест. Мне либо ответили "спасибо, но нет", либо решили что-то да сделать. Что именно - полностью остаётся на той стороне. Я попросил что-то небольшое, но они осознали бОльшую картину и там, где мне виделся одноколесный велосипед, они соорудили космолёт, держа в голове свои какие-то цели. Про учёт именно "хотелок" - как будто много лишнего в описании и некоторые подробности, что называется, не отсюда. Если это работы, выполняемые по контракту, то опять не понятно, что здесь делают фрагменты сценариев про фича-реквесты от рандомных персонажей. А хотелось бы понять
Дальше набор задач с первичной оценкой попадает на CAB (Change Advisory Board) — совет по изменениям. В состав обязательно должны входить представители всех заинтересованных сторон помимо представителей разработчика.
Слегка попахивает инструкцией, как потратить кучу времени толпы людей на бессмысленные созвоны. Но возможно я чего-то не знаю или вы так называете процедуры, которые мне привычнее называть иначе. Интересует судьба Product Owner'а в такой картине мира. Он же ничем не владеет, получается. Возможно понятнее станет, если опишете, что за продукт, кто все эти люди, которые друг с другом постоянно ходят на совещания.
ps
вы найдёте пошаговую инструкцию по подготовке к проектированию и разработке продукта
но статья же не об этом.
Добрый день!
Спасибо за комментарий. Начну по порядку.
"О какого рода проектах, продуктах идет речь, что вы называете "хотелками"? Если вы продаёте продукт или доступ к нему, то кто такие стейкхолдеры и заказчики? Если это пользователи и клиенты, то вроде бы неоткуда взяться частым встречам с ними. Если это заказчик, который платит деньги за реализацию нужных ему задач, то непонятно про статус "хотелок" и отказ в выполнении. Если, обратно, не заказчик, а рандомные люди заводят хотелки, то что делают в этих хотелках сроки, как их угораздило сюда затесаться?"
В процесс, описанный в статье, закладывал проекты, когда вы выполняете роль разработчика для внешнего заказчика. То есть, из заинтересованных сторон могут быть представлены: Пользователи (внешние, внутренние), Заказчик, Спонсор и др.
Для в чистом виде продуктовой разработки, когда вы развиваете и монетизируете свой собственный продукт для B2B или B2C сегментов - данный процесс будет наименее применим.
Кто заводит "хотелки".
Проблема валидации и согласованности запросов на изменения рождается тогда, когда стейкхолдеров много, приведу пример.
Крупный бизнес решает сделать какую-нибудь CRM для одного из своих подразделений - придумал эту идею Коммерческий директор (и выделил деньги), пользоваться будут сотрудники отдела продаж, сотрудники логистики и склада будут получать из системы заказы на сборку и тд. Другой пример, различные государственные системы - есть министерство, которое отвечает за развитие и владеет системой, пользоваться системой может совершенно иное ведомство. В подобных проектах и возникают проблемы, когда из-за дискоммуникации возникает дублирование требований, противопоставления, конфликты интересов. Для структуризации и применяется описанный подход - когда все стейкхолдеры имеют единую точку входа, куда направляют свои RFC, и каждый запрос проходит валидацию прежде чем попадет в бэклог работ и будет законтрактован.
"Если хотелку завёл хотельщик, то не очень понятно про бюджет и тем более про задумку. На гитхабе я закинул фича-реквест. Мне либо ответили "спасибо, но нет", либо решили что-то да сделать. Что именно - полностью остаётся на той стороне. Я попросил что-то небольшое, но они осознали бОльшую картину и там, где мне виделся одноколесный велосипед, они соорудили космолёт, держа в голове свои какие-то цели. Про учёт именно "хотелок" - как будто много лишнего в описании и некоторые подробности, что называется, не отсюда. Если это работы, выполняемые по контракту, то опять не понятно, что здесь делают фрагменты сценариев про фича-реквесты от рандомных персонажей. А хотелось бы понять"
Рандомные персонажи конечно могут тут быть, если разрабатываемая система имеет публичный характер и большое количество внешних пользователей. Однако, CAB подразумевает не звать на встречу всех подряд, а собрание ключевых лиц заинтересованных сторон. Если прилетают какие-то запросы на изменение от большого числа внешних пользователей, то через тех поддержку эти запросы могут быть также формализованы и вынесены на CAB, где и решится их судьба. Это уже специфика конкретного проекта.
"Слегка попахивает инструкцией, как потратить кучу времени толпы людей на бессмысленные созвоны. Но возможно я чего-то не знаю или вы так называете процедуры, которые мне привычнее называть иначе. Интересует судьба Product Owner'а в такой картине мира. Он же ничем не владеет, получается. Возможно понятнее станет, если опишете, что за продукт, кто все эти люди, которые друг с другом постоянно ходят на совещания."
Надеюсь про специфику проектов, где это применимо, ответил выше. Что касается траты времени и судьбы Product-а.
Конечно, как и любое новое начинание - трата времени будет казаться бессмысленной на первых порах, здесь эффект накопительный и приходит с выработкой проф привычки всех участников процесса.
Соглашусь, что не совсем корректно указал Product-а как участника данного процесса. Просто сейчас каждая компания по-своему видит работу Product-a, и единого понимания лично я не встречал - поэтому ввел в заблуждение и сложилась путаница. Что подразумевалось - со стороны разработки привлекаются люди, которые владеют техническими компетенциями и знаниями по системе, и способные оперативно давать оценку. Это могут быть: Архитектор, Руководитель проекта (Product Owner - если он есть, а может эта роль собирательная), Аналитик (или несколько), Тех лид и тд.
Соглашусь с вопросом из предыдущего комментария: не ясно, как ответственность PO соотносится с CAB и с аналитиком. И по тексту статьи вижу 3 линии, которые хотелось бы прояснить.
1) Линия "PO-CAB". PO ничего не решает? Вспоминается на эту тему хорошая статья в журнале Analyze IT от января 2009 (это не реклама:)). Но! В те времена не было PO как роли да и Agile не было мейнстримом. Приятие решений по выпуску в статье предлагалось совету (правда название использовалось иное, Change Control Board, ССВ). Тогда это было объяснимо.
2) Линия "PO-аналитик". Складывается ощущение (возможно, конечно, что я неправильно понял мысль), что оценивает работу PO, а работает де-факто аналитик. Если это так, то PO вполне может не угадать с оценкой.
3) Линия "CAB-аналитик". Получается, что аналитика назначают решением CAB? Означает ли это, что аналитик всегда свободен или ему дают задачу на будущее (впрок)?
Если автор сможет прокомментировать и развеять возможные сомнения, было бы замечательно, т.к. управление изменениями всегда было непростой темой.
Спасибо за комментарий!
1) Линия "PO-CAB". PO ничего не решает? Вспоминается на эту тему хорошая статья в журнале Analyze IT от января 2009 (это не реклама:)). Но! В те времена не было PO как роли да и Agile не было мейнстримом. Приятие решений по выпуску в статье предлагалось совету (правда название использовалось иное, Change Control Board, ССВ). Тогда это было объяснимо.
Постарался ответить в предыдущем комментарии.
Добавлю, в современных реалиях, PO в данном процессе был бы не на стороне разработчика, а выделенный со стороны Заказчика. Тогда картинка будет корректней, на мой взгляд.
2) Линия "PO-аналитик". Складывается ощущение (возможно, конечно, что я неправильно понял мысль), что оценивает работу PO, а работает де-факто аналитик. Если это так, то PO вполне может не угадать с оценкой.
Не совсем так. Оценивает как раз-таки приближенный к разработке и владеющий техническими компетенциями специалист (или группа). Скорее аналитик собирает оценку, а PO вместе с бизнесом принимает решение о включении этой RFC в рабочий бэклог и определяет приоритет.
3) Линия "CAB-аналитик". Получается, что аналитика назначают решением CAB? Означает ли это, что аналитик всегда свободен или ему дают задачу на будущее (впрок)?
Все верно, аналитик получает задачу на будущее. На CAB происходит закрепление задачи на ответственного аналитика, чтобы все стейкхолдеры сразу знали с кем можно эту задачу обсуждать в рабочем порядке.
Надеюсь, ответил)
Хотели велосипед, а получили мопед по цене автомобиля: как управлять изменениями и ожиданиями заказчика