[agile-ukraine] проблема с беклогом, у кого какие советы
Kostya Shein
Предыстория. Есть вялотекущий проект (больше года) без единого релиза, т.е. сборки и демосейсии есть но требования постоянно меняются, беклог айтемы имею вид не user story, а как мелочные поправки к тому что уже есть. Овнер раз в 3 месяца говорит что он наконец пообщался со всеми стейкхолдерами и теперь уже точно знает что нужно делать, после чего создает 10 новых юзерстори, отличающихся от старых.
Прошли очередные 3 месяца и овнер опять "точно знает что нужно делать", но команда ему уже не верит и вообще без энтузиазма рассматривает новые/измененные идеи, тем более что эти идеи затрагивают все уже сделанное.
Уже были попытки:
- разрабатывать проект как это видит команда, самим создавать требования (безуспешно, овнеру понравилось, стейкхолдеры все завернули)
--
-- Костя
Alexey Krivitsky
У вас не "проблема с беклогом". У вас проблемы с пониманием "что же мы разрабатываем". Но это неплохо. Это ОК.
В современном мире lean start-up называется "pivot". То есть менять траекторию проекта - нормально, при условии, конечно, что это делает осознанно и что замеряется фидбек от рынка.
Если этого не делается, а все эти месяцы ведется разработка без выпуска наружу, - то дело хуже.
Так что тут есть 2 большие разницы. У вас первое или второе? Pivot или ходьба вслепую?
-----
Помогать ли овнеру? Мой ответ - да и всему возможными силами. Не думайте о себе как об оффшорной зоне, задачей котороя является кодить.
Вы - часть продуктовой разработки и ответственность за продукт и исход проекта вы делите с овнером. Это честно и профессионально.
Это вы это можете признать и принять, тогда остается помогать и учиться, учиться и помогать.
Я бы попробовал построить процесс вокруг частых и регулярных демо, куда бы звал овнера и всех стейкхолдеров. И там бы пытался с ними решить, что делать в следующем коротком спринте.
Также я бы подсунул им книгу Lean Startup после чего помог бы планировать measurable learning cycles с выпуском продукта хотя бы для узкого пользования.
Леша
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
sergiy movchan
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
...dali bude...
Alexey Krivitsky
Я так кратко еще не научился излагать. Учусь.
Леша
Kostya Shein
у нас больше "ходьба вслепую" но ненужной фигней это не назовешь. Есть система написана еще в 2002 и за 10 лет очень сильно обросла, но ей все пользуются, матюкаются и пользуются, А понимание какая же система нужна и какие бизнес задачи нужно решать сперва - очень часто меняются. Т.е. штука и нужная, но есть старая и все привыкли.
-- Костя
Kostya Shein
-- Костя
Nataliya Trenina
Подскажи, есть ли еще какие-то причины редкого выпуска релизов, кроме изменений в беклоге? Если да, что это - на твой взгляд?
Наташа
--
CEO & Agile coach @ SCRUMguides
Founder & Executive @ InnovationFriends
Conference Producer @ Agile Base Camp
Conference Chair @ Agile Eastern Europe
LinkedIn | FaceBook | Twitter | Skype nattrenina | +38 050 412 61 35
Join us for Stanford Club @ InnovationFriends!
Alexey Krivitsky
С чего ты начнешь и когда?
Леша
> конкретно по овнеру - учите его запросы от стейкхолдеров записывать как "зачем?" а не как "что?"
sergiy movchan
...dali bude...
Serhiy Yevtushenko
Sergii Malyi
--
Sincerely,
Sergii Malyi
Kostya Shein
-- Костя
Serhiy Yevtushenko
Сергей
Сергей, все написано по делу, но неуместное применение термина "портфолио менеджмент" режет глаза. "принятие решений на стороне заказчика, какие задачи должны делаться, а какие не должны, и доведение тех фич, по которым принято решение делать, до конца" - это скорее продакт менеджмент, если под "задачами" подразумевается "реализация функционала", "фичи", "требования", т.е. высокоуровневые...
Alexey Krivitsky
- портфолио-менеджмент: процесс решений на уровне корпорации о приоритезации проектов (20'000 футов над проектами)
- продукт-менеджмент: решения на уровне проекта о том, какой функционал и когда выпускать (5'000 футов)
Так как мы смотрим на ситуацию Кости с уровня океана наверх (с уровня команды) - мы точно не знаем, где там сверху что поломано. Может на 5'000, а может и на 20'000 футах.
Но чинить-то мы будем снизу, так как это то место, где мы есть. А значит нам в принцине неважно где наверху не так. Важно, чтобы волна нашего процесса срезонировала и дошла до нужного уровня.
Сорри на метафоризмы и имхо.
Кри
Kostya Shein
-- Костя
Alexey Krivitsky
Serhiy Yevtushenko
Borys Lebeda
становится чьей-то ПОСТОЯННОЙ ОБЯЗАННОСТЬЮ.
Как правило люди очень боятся показать свою некомпетентность, если он
раскажут команде, что именно хотят сделать. Визит к заказчику (Сергей
Евтушенко предложил) чаще всего помогает, но основное - нужно, что бы
скрам-мастер (на практике член команды) всё время следил за состоянием
беклога и НАСТАИВАЛ, что бы заказчик исправлял выявленые недочёты.
Онсайт это безусловно проще.
Если он боится браться за сложные задачи - Напугайте его сильнее
перспективой, что эта сложная задача будет решаться только через месяц
или вообще не решится!
2012/1/13 Kostya Shein <kostya...@gmail.com>:
--
Borys L.
Kostya Shein
-- Костя
Antuan Mark
Или они в творческом поиске и их видение постоянно диаметрально
меняется?
Если так, то выдавливание из них бэклога ничем Вам не поможет! Это
будет временный бэклог, который потом опять придется менять.
И так каждый раз. Это вэйст еще тот будет.
Тогда нужно им помочь понять, что нужно ИМ. Как один из вариантов -
стори маппинг, как предложил Леша.
Если у них есть четкое понимание, но эта информация до Вас доходит в
искаженном виде, то такую проблему надо решать с другой стороны
конечно.
On Jan 16, 3:40 am, Kostya Shein <kostya.sh...@gmail.com> wrote:
> Уже месяц НАСТАИВАЮ на заполнении беклога. Пока добились того что провели
> демо по всей сисстеме и записали пожелания и доработки (насобирали на
> короткий спринт-багфикс). Но все еще нет новых фич.
>
> Система сейчас находится в состоянии когда "админка" сделана и основные
> юзкейсы уже проходят. Но никто не знает как система должна выглядеть
> снаружи. Видать не хотят платить UX специалистам а самим не удается
> придумать.
>
> Заказчик убежал к стейкхолдерам и обещал вернуться с фичами....ждем...и
> напоминаем.
>
> 13 января 2012 г. 15:23 пользователь Borys Lebeda
> <borys.leb...@gmail.com>написал:
>
>
>
>
>
>
>
> > Если честно я этим давно занимаюсь и знаю это задача, которая обычно
> > становится чьей-то ПОСТОЯННОЙ ОБЯЗАННОСТЬЮ.
>
> > Как правило люди очень боятся показать свою некомпетентность, если он
> > раскажут команде, что именно хотят сделать. Визит к заказчику (Сергей
> > Евтушенко предложил) чаще всего помогает, но основное - нужно, что бы
> > скрам-мастер (на практике член команды) всё время следил за состоянием
> > беклога и НАСТАИВАЛ, что бы заказчик исправлял выявленые недочёты.
> > Онсайт это безусловно проще.
>
> > Если он боится браться за сложные задачи - Напугайте его сильнее
> > перспективой, что эта сложная задача будет решаться только через месяц
> > или вообще не решится!
>
> > 2012/1/13 Kostya Shein <kostya.sh...@gmail.com>:
> > > И как "заставить" заказчика создать таки нормальный беклог?
>
> > > Не мелочный и не абстрактный.
> > > 1. Мелочный - беклог состоящий из задач-исправлений на существующий
> > > функционал
> > > 2. Абстрактный - диаграмы связей с другими системами.
>
> > > И первый и второй варианты уже были.
> > > При первом задачи создавались ради задач - изменения без объяснения
> > зачем и
> > > кому нужно.
> > > При втором диаграмы разваливались при первой же попытке понять зачем и
> > кому
> > > нужно.
>
> > > Есть какое-то ощущение что заказчик боится браться за сложные бизнес
> > задачи
> > > и создает видимость работы для стейкхолдеров. Может не разбирается в
> > вопросе
> > > и не хочет этого показать стейкхолдерам. Может еще что-то...где-то очень
> > > "наверху".
>
> > > 12 января 2012 г. 21:03 пользователь Alexey Krivitsky
> > > <alexeykrivit...@gmail.com> написал:
>
> > >> В моем понимании:
> > >> - портфолио-менеджмент: процесс решений на уровне корпорации о
> > >> приоритезации проектов (20'000 футов над проектами)
> > >> - продукт-менеджмент: решения на уровне проекта о том, какой функционал
> > и
> > >> когда выпускать (5'000 футов)
>
> > >> Так как мы смотрим на ситуацию Кости с уровня океана наверх (с уровня
> > >> команды) - мы точно не знаем, где там сверху что поломано. Может на
> > 5'000, а
> > >> может и на 20'000 футах.
>
> > >> Но чинить-то мы будем снизу, так как это то место, где мы есть. А значит
> > >> нам в принцине неважно где наверху не так. Важно, чтобы волна нашего
> > >> процесса срезонировала и дошла до нужного уровня.
>
> > >> Сорри на метафоризмы и имхо.
>
> > >> Кри
>
> > >> 2012/1/12 Serhiy Yevtushenko <syevtushe...@gmail.com>
>
> > >>> Я понимаю под портфолио менеджментом процесс решения о том, какие
> > проекты
> > >>> делаются, а какие не делаются вообще (в смысло Johanna Rothmans
> > "Manage your
> > >>> project portfolio". Уровень проектов при этом может быть абсолютно
> > разным.
> > >>> Отсутвие такого процесса приводит к серьезным проблем. По сути своей,
> > это
> > >>> принятие решение делать что-то (и выделение ресурсов), не делать
> > чего-то
> > >>> вообще, или запарковать решение до следующего пересмотра, и еффективное
> > >>> управление имеющейся емкостью команды.
>
> > >>> Задача продакт менеджмента - решать, какие вещи с точки зрения продукта
> > >>> должны быть сделаны, и окупяться ли они, их приоритизация.
>
> > >>> Сергей
>
> > >>> 12 января 2012 г. 9:44 пользователь Sergii Malyi <serg.m...@gmail.com>
> > >>> написал:
>
> > >>>> Сергей, все написано по делу, но неуместное применение термина
> > >>>> "портфолио менеджмент" режет глаза. "принятие решений на стороне
> > заказчика,
> > >>>> какие задачи должны делаться, а какие не должны, и доведение тех фич,
> > по
> > >>>> которым принято решение делать, до конца" - это скорее продакт
> > менеджмент,
> > >>>> если под "задачами" подразумевается "реализация функционала", "фичи",
> > >>>> "требования", т.е. высокоуровневые...
>
> > >>>> --
> > >>>> Sincerely,
> > >>>> Sergii Malyi
>
> > >>>> 2012/1/11 Serhiy Yevtushenko <syevtushe...@gmail.com>
> > >>>>> <nat.tren...@gmail.com> написал:
>
> > >>>>>> Костя, привет.
>
> > >>>>>> Подскажи, есть ли еще какие-то причины редкого выпуска релизов,
> > кроме
> > >>>>>> изменений в беклоге? Если да, что это - на твой взгляд?
>
> > >>>>>> Наташа
>
> > >>>>>> 11 января 2012 г. 17:37 пользователь Kostya Shein
>
> ...
>
> read more >>
Kostya Shein
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
-- Костя
Sergii Malyi
Ребята, если заказчик тратит на что-то деньги, то это значит, что на бизнес-уровне ожидания от проекта как раз более чем ясны. Для него, естественно.
Увы, не все понимают, что заказчика меньше интересуют технические аспекты реализации, а больше эффект, который получит бизнес. И вот именно потребности бизнеса в первую очередь и определяют "хотелки" заказчика. И наша задача увидеть бизнес-потребености и предложить их эффективное решение.
Соответственно, если мы не видим этого, то это наша беда, а не стейкхолдеров. И помогать нужно нам :-)
С таким и только с таким настроением нужно общаться с заказчиком, иначе успеха не видать.
--
Sincerely,
Sergii Malyi
sergiy movchan
...dali bude...
Sergii Malyi
--
Sincerely,
Sergii Malyi
Kostya Shein
Так как проект уже довольно долго тянется, то думаю скоро настанет тот момент когда менеджеру все-таки придется показать баджет овнеру не только показатели но и продукт.
И какие же действия?
Если ориентироваться на ожидания баджет овнера, то выходит нужно перешагнуть/забить на менеджера и сделать самим так как считаем нужным, ну или хитро подсунуть менеджеру нашу реализацию как его собственное видение.
-- Костя
Дмитрий Горбенко
так именно так и есть - есть люди которые ответственны за проект, на них заводят все решения.
я от туда ушел 2.5 года тому назад, и вы знаете, пилят и дальше. и будут пилить.
там, квартиру под эти деньги у самом начале отпилили, я помню.
я так был, потому что набирался опыта.
прыгать через кого-то не надо, имхо.
мне кажется надо просто идти дальше, рынок ждет.
Kostya Shein
-- Костя
Дмитрий Горбенко
при этих условиях, у вам будет совсем иной диалог с текущим заказчиком:
* быть может вам откроются причины той ситуации что вы имеете сейчас, и вам предложат вариант продолжения сотрудничества (только будьте бдительны, обещания могут быть данны вам. а вот исполнять их -- совсем другой разговор -- здесь все зависит от вас, от вашего чутья)
* либо как все -- вырос в знаниях, готов к новым этапам, и значит пора выкладывать резюме на сайт.
Sergii Malyi
Прыгать через менеджера нужно лишь в том случае, если не получается наладить с ним конструктивную работу в интересах баджет овнера. Как это сделать - другой вопрос. Обычно проводят митинг с участием обоих, на котором бизнес презентует свои ожидания. Другой вариант - совместно с менеджером презентовать бизнесу свое видение его ожиданий. Обычно это помогает устранить различные непонятки и разночтения. Вариант с демо хорош, но иногда сопровождается воплями: "Я же совсем не эту хрень заказывал!" (если заказчик воспитан, то он просто молчит как кролик из "Винни Пуха" J). Особенно бывает обидно, если перед этим проводились несколько более удачных демо, а тут "внезапно" оказалось, что по кусочкам вроде все выглядит как "оно самое", а в сборе - нет...
Sincerely,
Sergii Malyi