Proxy Product owner - источник проблем

[Artjom Serdyuk]

Столкнулся с такой ситуацией на разработке продукта:

Поскольку было решено усилить акцент на продажи, бывший Продакт Оунер
присоединился к сейлсам, и сейчас его роль выполняет архитектор
(который на ходится с той же стороны distributed team, что и ПРодакт
оунер, но по другую сторону от команды).

Спустя две итерации мы получили полный букет проблем от такой
конфигурации:
1) у рroxy PO нет видения продукта со стороны бизнеса и заказчиков,
поэтому
2) иногда его решения отменяет actual РО
3) иногда рroxy PO навязывает технические решения вместо
функциональных
4) часто рroxy PO вынужен переспрашивать у actual РО, как поступить
5) если же рroxy PO не переспрашивает, возникает обсуждение уже
выкаченной функциональности на демо в стиле "а почему так?"

Кто сталкивался с такими ситуациями? Чем вы их лечили?

[Alexander Burdun]

Сам был прокси пару раз, сталкивался с теми же проблемами, но со своей стороны. (посему всё что дальше - написано с точки зрения такого вот "прокси")

Но тогда работа велась не по скраму:) хотя как мне кажется не в этом суть.

Решалось всё вроде как и просто, но с большим трудом:

Методы: 

взять за воротки Продакт-овнера и хорошенько проработать с ним архитектуру и прочие данные по проекту, 

задача этого - получить от него вижн адекватный.

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

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

Кроче, резюме:

1. СПРАШИВАТЬ у актального ПО (как спрашивать это уже методы)

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

5 марта 2010 г. 11:45 пользователь Artjom Serdyuk <artem....@gmail.com> написал:

--
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

--
С уважением, Александр
mailto: a.bu...@gmail.com
icq: 307064073
тел.: 8/097/137 0443

[Alexander Rivkind]

Возможно без архитектора (который стал "прокси ПО") вы стали выбирать неудачные решения, и он это видит? Попытайтесь организовать отдельный митинг типа architecture review.
Возможно ему как архитектору легче формулировать функциональность именно таким языком. Попробуйте переформулировать его задачу, убрав из нее все аспекты реализации и согласуйте с ним результат. Со временем у него выработается соответствующий язык.

2010/3/5 Alexander Burdun <a.bu...@gmail.com>

--
Best Regards, Alik.

[Borys Lebeda]

Установить bypass :)

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

Проблемы (5) вообще не должно быть. Лучше что бы он прибегал к (4) как можно чаще, а за (3) получал жесткий отлуп от команды.

2010/3/5 Artjom Serdyuk <artem....@gmail.com>

--
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

--
Borys L.

[Artjom Serdyuk]

Борь, Александр, спасибо за ответы. Теперь повторю вопрос ))

У вас такое в практике было? Как вы боролись или что делали? Чем все
закончилось?

Спасибо ещё раз.

On 5 мар, 17:31, Borys Lebeda <borys.leb...@gmail.com> wrote:
> Установить bypass :)
>
> А если честно две интерации явно мало для того, что бы новый продакт оунер
> заменил старого. Если его заранее не готовили то нужно месяца три.
>
> Проблемы (5) вообще не должно быть. Лучше что бы он прибегал к (4) как можно
> чаще, а за (3) получал жесткий отлуп от команды.
>

> 2010/3/5 Artjom Serdyuk <artem.serd...@gmail.com>

>
>
>
>
>
> > Столкнулся с такой ситуацией на разработке продукта:
>
> > Поскольку было решено усилить акцент на продажи, бывший Продакт Оунер
> > присоединился к сейлсам, и сейчас его роль выполняет архитектор
> > (который на ходится с той же стороны distributed team, что и ПРодакт
> > оунер, но по другую сторону от команды).
>
> > Спустя две итерации мы получили полный букет проблем от такой
> > конфигурации:
> > 1) у рroxy PO нет видения продукта со стороны бизнеса и заказчиков,
> > поэтому
> > 2) иногда его решения отменяет actual РО
> > 3) иногда рroxy PO навязывает технические решения вместо
> > функциональных
> > 4) часто рroxy PO вынужен переспрашивать у actual РО, как поступить
> > 5) если же рroxy PO не переспрашивает, возникает обсуждение уже
> > выкаченной функциональности на демо в стиле "а почему так?"
>
> > Кто сталкивался с такими ситуациями? Чем вы их лечили?
>
> > --

> > 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<agile-ukraine%2Bunsubscribe@goog legroups.com>
>
> --
> Borys L.

[Artjom Serdyuk]

Александр, спасибо за ответ.

А были у вас попытки поделить функции и ответственность с актуальным
ПО? Что-то вроде "на вопросы команды по беклогу отвечаю я, а истории
принимаешь ты и приоритеты ставишь ты"?

On 5 мар, 12:00, Alexander Burdun <a.bur...@gmail.com> wrote:
> Сам был прокси пару раз, сталкивался с теми же проблемами, но со своей
> стороны. (посему всё что дальше - написано с точки зрения такого вот
> "прокси")
>
> Но тогда работа велась не по скраму:) хотя как мне кажется не в этом суть.
>
> Решалось всё вроде как и просто, но с большим трудом:
> Методы:
> взять за воротки Продакт-овнера и хорошенько проработать с ним архитектуру и
> прочие данные по проекту,
> задача этого - получить от него вижн адекватный.
>
> Звучит вроде как просто, но на практике это практически неосуществимо.
> Продакт-овнер как правило сам полностью не видит архитектуры, но может
> ответить на наводящие вопросы, поэтому перед тем как пользовать такой метод
> - прокси должен составить список этих самых вопросов.
>
> Пробовал еще по-другому: делал то что описано выше, но каждую итерацию - это
> шло проще, хотя проблемы те же.
>
> Кроче, резюме:
> 1. СПРАШИВАТЬ у актального ПО (как спрашивать это уже методы)
> 2. а насчет навязывания технических решений вместо функциональных - хз,
> втемяшить вашему прокси, что его задача не в том, у меня такой проблемы не
> было, ниче более адекватного сказать не могу.
>
> 5 марта 2010 г. 11:45 пользователь Artjom Serdyuk

> <artem.serd...@gmail.com>написал:

>
>
>
>
>
> > Столкнулся с такой ситуацией на разработке продукта:
>
> > Поскольку было решено усилить акцент на продажи, бывший Продакт Оунер
> > присоединился к сейлсам, и сейчас его роль выполняет архитектор
> > (который на ходится с той же стороны distributed team, что и ПРодакт
> > оунер, но по другую сторону от команды).
>
> > Спустя две итерации мы получили полный букет проблем от такой
> > конфигурации:
> > 1) у рroxy PO нет видения продукта со стороны бизнеса и заказчиков,
> > поэтому
> > 2) иногда его решения отменяет actual РО
> > 3) иногда рroxy PO навязывает технические решения вместо
> > функциональных
> > 4) часто рroxy PO вынужен переспрашивать у actual РО, как поступить
> > 5) если же рroxy PO не переспрашивает, возникает обсуждение уже
> > выкаченной функциональности на демо в стиле "а почему так?"
>
> > Кто сталкивался с такими ситуациями? Чем вы их лечили?
>
> > --

> > 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<agile-ukraine%2Bunsubscribe@goog legroups.com>
>
> --
> С уважением, Александр
> mailto: a.bur...@gmail.com

[Alexander Burdun]

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

Но у меня были разные варианты с разными клиентами (ПО), поэтому универсального решения нету.

Один раз было так как вы привели в примере: беклог на мне(Прокси), а приоритеты на ПО (плюс по технической стороне я немного больше разбирался обычно, поэтому иногда вносил коррективы в приоритеты если например фичу1 удобнее сделать после фичи2, так как фича2 используе наработки фичи1, а фича1 разрабатывается проще и быстрее)

А в остальных случаях команда вообще не общалась с ПО - я был гласом команды для ПО, и ПО - для команды.

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

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

Во втором же всё ясно, но ответственности на прокси немного больше, если команда "сделала не то" значит прокси не правильно понял постановку от ПО.

Как-то так:) без умных слов;)

5 марта 2010 г. 19:23 пользователь Artjom Serdyuk <artem....@gmail.com> написал:

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

--
С уважением, Александр
mailto: a.bu...@gmail.com

[COTOHA .]

было? было

что делали? постоянно пинал этого человека, постоянно пинал реального ПО, постоянно боялся, что будет жопа

чем закончилось? проект чуть не факапнулся, если бы не вернулся ПО, то он бы таки факапнулся. но сроки превыслили в 2 раза (вместо 5 месяцев делали 10), эффорт превысили в полтора раза (вместо 1500чч делали 2300чч). в итоге заказчик доволен, но как говориться осадочек остался :).

не думаю, что это поможет :) 

2010/3/5 Artjom Serdyuk <artem....@gmail.com>

>
> --
> Borys L.

--
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...

[Alexander Burdun]

напутал в примере с фичами)) но думаю пример прозрачный)

5 марта 2010 г. 19:53 пользователь Alexander Burdun <a.bu...@gmail.com> написал:

[Alexander Burdun]

Были и столь трагичные примеры)))) но далеко не все;)

Когда на третьем проекте являешь таким вот "прокси" начинаешь понимать чего от тебя хотят;)

5 марта 2010 г. 19:55 пользователь COTOHA . <sergiy....@gmail.com> написал:

--

[Borys Lebeda]

 

Когда я был представителем команды я пробовал (в хронологическом порядке):

1) задавать вопросы прокси ПО

2) принимать решения 2а) сам 2б) с командой

3) задавать вопросы и договариваться о дедлайнах по ним

4) заставлять писать 4а) требования 4б) спецификации 4в) use cases

5) вовлекать его в фазу тестирования

6) писать письма напрямую старому ПО

7) настаивать на том, что бы руководство вернуло старого ПО.

8) заваливать вопросами прокси так, что бы он 8а) почувствовал себя некомпетентным 8б) заваливал вопросами руководство 8в) сам настаивал на том, что бы вернуть старого ПО

Когда я сам был прокси (было всего 2 раза), я пробовал:

1) принимать решения сам, отмазываться перед руководством

2) форвардить все неясные вопросы руководству

3) обуждать с руководством видение проекта в формальной обстановке

4) обуждать с руководством видение проекта в неформальной обстановке

5) участвовать в разработке

6) участвовать в тестировании

В первом случае наиболее эффективным способом оказались методы (3) и (8б), во втором (3) и (4) т.е.

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

Со стороны прокси: обуждать бизнес-видение проекта когда только возможно в формальной или неформальной обстановке и обязательно с несколькими Stakeholder'ами.

2010/3/5 Artjom Serdyuk <artem....@gmail.com>

Борь, Александр, спасибо за ответы. Теперь повторю вопрос ))

 

Язва Ты, Артём. Но я тоже съязвлю: Тебе объяснить как из вышеуказанных опытов в этом письме я пришёл к выводам написанном в предыдущем письме?  

У вас такое в практике было? Как вы боролись или что делали? Чем все
закончилось?

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

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

--
Borys L.

[Yuriy Mann]

Всем привет.

Я был таким прокси почти два года, с теми же примерно проблемами.

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

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

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

Насчет того, что ПО подсказывает технические решения, не вижу, почему
это должно беспокоить команду. Во-первых, ПО волен участвовать в
обсуждениях дизайна на ровне с любым девелопером. Во-вторых, ПО в
конечном счете ответственен за результат (опять же не вижу, чем ПО
кардинально отличается от менеджера проекта, кроме того, что процесс
построен немного по другому). И если девелоперов не удается убедить,
ПО в праве настаивать на нужном решении - это вопрос той же категории,
что и приоритеты, которые команде тоже бывает трудно объяснить из-за
недостатка информированности и перспективного видения развития
проекта. Справедливости ради отмечу, что у нас всегда удается найти
решение, с которым согласно большинство, причем нередко девелоперы
убеждают меня (ПО), что я не прав и проталкивают свое решение. Это
касается и приоритетов, и технических решений. Если команда
действительно не согласна с техническими решениями, "навязанными" ПО,
и им не удается это решить "полюбовно", пусть жалуется начальникам ПО
или ищет другой проект. Идеальное место для обсуждения таких проблем -
retrospective meetings.

[Yuriy Mann]

Аналог нашего варианта описан Александром Бурдуном выше (только у нас
все называется своими именами ;-) ):

"А в остальных случаях команда вообще не общалась с ПО - я был гласом
команды
для ПО, и ПО - для команды.

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

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

Во втором же всё ясно, но ответственности на прокси немного больше,
если
команда "сделала не то" значит прокси не правильно понял постановку от
ПО. "

[Alimenkou Nikolay]

Наконец-то выделил время на то, чтобы поучаствовать в этой дискуссии.

Я работал на нескольких проектах с прокси PO и даже сам выполнял его
роль. Проблем практически не возникало. Понятное дело были иногда
рабочие проблемы, но не более чем. Мне кажется, что тут зависит от
человека, выполняющего эту роль. Поясню. Сам по себе шаблон прокси
предполагает, что никто никогда не узнает о том, что общается не с
реальным объектом. При плохой реализации возникают все перечисленные
проблемы, а именно 1, 3, 5. В пунктах 2 и 4 я не вижу проблемы. Такое
случается и с реальным PO, задаешь вопрос по поводу новой
функциональности, а над ним никто не задумывался никогда. Тогда
правильный PO возьмет паузу на то, чтобы обдумать, обсудить с
пользователями и другими вовлеченными лицами. А по поводу отмены
решений: я даже сам свои решения бывает отменяю (для самого же себя).

Самое важное в этой роли - не относиться к ней, как к очень простой,
занимающей только какой-то процент времени. Это полноценная роль. Я
никогда не забуду как все уходили домой вечером, а наш прокси
оставался (из-за разницы во времени с заказчиками) и много часов
обсуждал с заказчиком и видение дальнейшего развития, желаемый
функционал и детали по нему. И это в середине итерации, не в начале и
не на демонстрации. Зато он всегда был готов дать ответ. А если и не
был готов, то говорил об этом честно и старался решить вопрос, потому
как понимал свои обязанности.

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

[Evgeny Kompaniets]

Артем,

мне приходилось немного быть в роли прокси. 

По-моему самое главное для прокси - максимально погрузиться в решаемые бизнес проблемы заказчика (ПО). В первую очередь попытаться просто собрать максимально информации. Что-то возможно почитать, о чем-то максимальнo поговорить. Поговорить причем не только с заказчиком (с которым явно не всегда легко поговорить, раз у нас есть прокси), но и с разными другими людьми из бизнеса. Это могут быть клиенты, пользователи разных ролей продукта и т.п. Эти люди часто видят бизнес проблемы с разных сторон, и не редки ситуации когда заказчик имеет стратегическое видение, которое противоречит интересам каких-то людей. Понимание таких конфликтов является очень ценным для принятия решений. Набравшись информации гораздо легче коротко общаться с заказчиком - чем больше мы в теме, тем меньше нам нужно времени, чтобы сформулировать вопрос и тем понятнее ответ без лишних необходимостей много обьяснять. Начиная с какого-то момента прокси уже может иногда существенно помогать заказчику в работе с требованиями, просто напоминая о чем-то или предлагая свои варианты. 

Про переспрашивание - в идеале все планируемые задачи и их приоритеты утдверждаются настоящим заказчиком, поскольку прокси при всем желании будет делать гораздо больше ошибок. Не устаю напоминать что эти ошибки - самое узкое место в проекте! :) Я бы пытался не избавиться от этого, а минимизираовать на него затраты времени т.е. прокси стремиться научиться очень быстро получать ответы от заказчика. Включая иногда чисто технические приемы, например у меня заказчик часто быстро отвечает по СМС (при этом недоступен по другим каналам). 

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

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

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

Надеюсь чем-то поможет.

5 марта 2010 г. 11:45 пользователь Artjom Serdyuk <artem....@gmail.com> написал:

--
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

--
Evgeny Kompaniets

[Tim Yevgrashyn]

Артем, привет.

Написали тебе уже много и по существу. Буквально пару слов о своем недавнем опыте.

Лучше не называть "прокси" - просто молодой и новый ПО. Старый ПО и остальные - это уже "заказчики" (stakeholders и т.п.) и с ними соответственно нужно налаживать взаимоотношения, исходя из базового опыта и знаний нового ПО.

Чтобы решить (1) и (2) из твоего вопроса - нужно, чтобы ПО наладил регулярный цикл общения с заказчиками. Пусть хотя бы раз в неделю собирается с сейлсами и прочими, спрашивает их бизнес приоритеты, показывает им свои планы и получает одобрение и/или отзывы. Инструменты у него есть (оценки, велосити и т.п.) - остальное дело техники и практики.

По поводу (4) и (5) - лечится вниманием к тому, как вы (ПО и команда) пишете требования. Если используете User Stories, то обратите внимание на наличие Condition of Satisfaction (acceptance tests и т.п). У нас договорились, что если CoS нет на момент начала спринта, то они должны появиться максимум во время первичного анализа разработчиками, даже статус специальный сделали Ready-Ready. Если команда не смогла получить внятные CoS, то вся история импедится или даже выкидывается из спринта. Это хорошо обучает ПО на его собственных "ошибках" (если важная функция разок задержалась, то больше он такого не допустит). Опять же, сбор новых требований - это регулярная работа, а не один раз за день до начала спринта.

Ну и по поводу (3) - тут уже действительно всей командой нужно спрашивать "а нафига". Если новый ПО и команда в целом общаются, то быстро найдут базу для взаимопонимания. Или же нужно искать более глубокие причины (ревность к новому ПО, непонимание архитектуры и т.п., все что было перечислено в других письмах).

P.S.

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

Если работа ПО занимает у него много времени, то нужно, чтобы это время ему выделили, иначе человек быстро "выдохнется". Ну или ищите другого ПО, более подходящего на эту роль ;-)

Tim Yevgrashyn,

Web: http://tim.com.uaАртем, 
Skype: spidertim
Phone: +380 67 408 53 30

2010/3/5 Artjom Serdyuk <artem....@gmail.com>

[COTOHA .]

кстати, все ж проблему поняли? :) прокси на той стороне.

а это чаще всего значит, что у ПО нет времени на проект, и введение роли прокси не меняет этого факта - времени как не было, так и не будет.

прокси на нашей стороне чаще всего более чем полезен. прокси на той стороне, как показывает мой скудный опыт - чаще всего признак проблемы, а не решение.

2010/3/8 Tim Yevgrashyn <yevgr...@gmail.com>

--
...dali bude...

[Artjom Serdyuk]

Сергей, а ты кстати прав. Я тоже не обратил на это внимание.

А сейчас понимаю, что на стороне команды разработки появился "прокси-
прокси-ПО", который перетащил на себя все общение, и дает команде
самые быстрые ответы на вопросы. И что с этим делать?

On 8 мар, 22:51, "COTOHA ." <sergiy.movc...@gmail.com> wrote:
> кстати, все ж проблему поняли? :) прокси *на той* стороне.

>
> а это чаще всего значит, что у ПО нет времени на проект, и введение роли
> прокси не меняет этого факта - времени как не было, так и не будет.
>
> прокси на нашей стороне чаще всего более чем полезен. прокси на той стороне,
> как показывает мой скудный опыт - чаще всего признак проблемы, а не решение.
>

> 2010/3/8 Tim Yevgrashyn <yevgras...@gmail.com>

> > 2010/3/5 Artjom Serdyuk <artem.serd...@gmail.com>

>
> > Столкнулся с такой ситуацией на разработке продукта:
>
> >> Поскольку было решено усилить акцент на продажи, бывший Продакт Оунер
> >> присоединился к сейлсам, и сейчас его роль выполняет архитектор
> >> (который на ходится с той же стороны distributed team, что и ПРодакт
> >> оунер, но по другую сторону от команды).
>
> >> Спустя две итерации мы получили полный букет проблем от такой
> >> конфигурации:
> >> 1) у рroxy PO нет видения продукта со стороны бизнеса и заказчиков,
> >> поэтому
> >> 2) иногда его решения отменяет actual РО
> >> 3) иногда рroxy PO навязывает технические решения вместо
> >> функциональных
> >> 4) часто рroxy PO вынужен переспрашивать у actual РО, как поступить
> >> 5) если же рroxy PO не переспрашивает, возникает обсуждение уже
> >> выкаченной функциональности на демо в стиле "а почему так?"
>
> >> Кто сталкивался с такими ситуациями? Чем вы их лечили?
>
> >> --

> >> 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<agile-ukraine%2Bunsubscribe@goog legroups.com>
>
> >  --
> > 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<agile-ukraine%2Bunsubscribe@goog legroups.com>
>
> --
> ...dali bude...

[Tim Yevgrashyn]

Артем,

Я бы все-таки рекомендовал тренировать (натаскивать) ТОГО, удаленного, нового ВП, чтобы он вам полноценно помогал.

Костыли в виде "толмача" на вашей стороне могут только усугубить ситуацию. Думаю сам понимаешь почему.

И прекратите использовать слово "прокси" - оно подразумевает, что человек не несет ответственности, мол я не я и корова не моя. Роль ВП подразумевает ответственность перед "заказчиками" и ее исполнение в любом виде - это уже взятие этой ответственности. Все остальное это навыки, опыт и командная работа. Как говориться, Insepct&Adapt вам поможет :-)

Tim Yevgrashyn,

Web: http://tim.com.ua

Skype: spidertim
Phone: +380 67 408 53 30

2010/3/9 Artjom Serdyuk <artem....@gmail.com>

>
> --
> ...dali bude...

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/

[Yuriy Mann]

Либо переквалифицируйте этого толмача в полноценного ПО.

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

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

On Mar 9, 9:36 am, Tim Yevgrashyn <yevgras...@gmail.com> wrote:
> Артем,
>
> Я бы все-таки рекомендовал тренировать (натаскивать) ТОГО, удаленного,
> нового ВП, чтобы он вам полноценно помогал.
> Костыли в виде "толмача" на вашей стороне могут только усугубить ситуацию.
> Думаю сам понимаешь почему.
>
> И прекратите использовать слово "прокси" - оно подразумевает, что человек не
> несет ответственности, мол я не я и корова не моя. Роль ВП подразумевает
> ответственность перед "заказчиками" и ее исполнение в любом виде - это уже
> взятие этой ответственности. Все остальное это навыки, опыт и командная
> работа. Как говориться, Insepct&Adapt вам поможет :-)
>
> Tim Yevgrashyn,
>
> Web:http://tim.com.ua
> Skype: spidertim
> Phone: +380 67 408 53 30
>

> 2010/3/9 Artjom Serdyuk <artem.serd...@gmail.com>

> > > >> 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<agile-ukraine%2Bunsu...@googlegroups.com>

> > <agile-ukraine%2Bunsubscribe@goog legroups.com>
>
> > > >  --
> > > > 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<agile-ukraine%2Bunsu...@googlegroups.com>

> > <agile-ukraine%2Bunsubscribe@goog legroups.com>
>
> > > --
> > > ...dali bude...
>
> > --

> > 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<agile-ukraine%2Bunsu...@googlegroups.com>

[Yuriy Mann]

Это был пост в поддержку и Тима, и Сергея двумя постами выше :)

> ...
>
> read more >>