критерии к поиску ПО (было: Тренинги Хенрика Книберга)
4 views
Skip to first unread message
Alexey Krivitsky
Oct 21, 2008, 8:38:36 AM10/21/08
to agile-...@googlegroups.com
почему бы это не обсудить в новом топике?
какие требования-критерии вы выставляете к PO?
что он должен уметь делать? что может не уметь делать?
какой бекграунд у него должен быть? не должен быть?
--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
какие требования-критерии вы выставляете к PO?
что он должен уметь делать? что может не уметь делать?
какой бекграунд у него должен быть? не должен быть?
2008/10/21 Borys Lebeda <borys....@gmail.com>
Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы определить какой должен быть ПО. Пока лично мне удаётся только определить каким он не должен быть:
http://atriplex-on-software.blogspot.com/2008/10/where-to-start-building-up-solution.html
Но я уверен, что рано или поздно появится инструкция как найти правильного ПО. Как знать может и сам придумаю ...
2 Sergiy Movchan: поделись best practices если они у Тебя есть :)Borys L.2008/10/21 Alexey Krivitsky <alexeyk...@gmail.com>в настоящем мире, на сколько я вижу, многие PO на самом деле являются проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.2008/10/21 Sergiy Movchan <sergiy....@gmail.com>
вот если будет PO Proxy best practices, то я очень хочу. Сам по себе PO не интересен....dali bude...On Tue, Oct 21, 2008 at 12:29 PM, Dmitry Danilchenko <dm1...@yahoo.com> wrote:
мне Product Owner интересно.
From: Tim Yevgrashyn <yevgr...@gmail.com>
To: agile-...@googlegroups.com
Sent: Tuesday, October 21, 2008 12:13:19 PM
Subject: [agile-ukraine] Re: Тренинги от Хенрика Книберга
Certified Product Owner :-D
Такого еще никто не читал в Украине
2008/10/21 Alexey Krivitsky <alexeyk...@gmail.com>
привет,
хенрик готов приехать в районе 16-17 декабря в украину.
есть желающие посетить csm класс?
хенрик готов читать любой другой материал, не обязательно certified scrummaster.
стоимость его гонорара при этом остаётся фиксированной.
мой расчёт даёт стоимость дня тренинга при 20 человек в классе порядка 370-400 долларов с участника.
какие тренинги вам было бы интересно посетить?
--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
--
Tim Yevgrashyn,
Phone: +380 67 408 53 30
Skype: spidertim
LinkedIn: http://www.linkedin.com/in/yevgrashyn
--
--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
--
--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
sun
Oct 21, 2008, 8:40:56 AM10/21/08
to agile-...@googlegroups.com
Borys Lebeda
Oct 21, 2008, 8:47:56 AM10/21/08
to agile-...@googlegroups.com
2008/10/21 Alexey Krivitsky <alexeyk...@gmail.com>
почему бы это не обсудить в новом топике?
какие требования-критерии вы выставляете к PO?
Обычно он выставляет к нам требования ...
- знать, что конечные пользователи хотят от системы
- уметь донести понимание системы до команды
- понимать приоритеты этих вещей
- не путать требования и реализацию
- быть доступным для команды и достаточно мотивированным, что бы давать квалифицированные ответы
- не делегировать полномочия людям, которые не удовлетворяют перечисленным выше пяти качествам или не расходятся во мнении с ним
- уметь всё это проверить
Если честно, я не видел ни одного человека который может выполнить хотя бы два пункта из того, что я перечислил ...
Sergiy Movchan
Oct 21, 2008, 9:08:36 AM10/21/08
to agile-...@googlegroups.com
У меня основная проблема состоит в том, что контакт-персон с той стороны как бы это сказать... not-committed. Не то чтобы ему было начхать на успех проекта или он саботирует процесс, но ситуация в целом напоминает анекдот, где муж жене говорит "ну ты же у меня умная - придумай что-нибудь сама".
вот и приходится постоянно расписывать варианты бизнес-нидсов, чтобы он мог ткнуть пальцем "вот это". Потому что дождаться внятного описания истории от него сложно. Приоритезация тоже хромает, т.к. в силу этой специфики много приоритезирую я сам. В среднем получается неплохо, но иногда влетаем :) но не сильно. Уже подумываю о том, чтобы показать разок, что "не такая я уж и умная" - то есть сделать что-то специально тупо совсем не в том порядке, чтоб он понял, что надо следить и самому расставлять приоритеты. А с другой стороны сцыкотно :) да и реноме... Короче вот так и живём.
И есть у меня подозрение, что это не очень нетипичная ситуёвина. Вот я и подумал - может есть какие-то практики, которые могут мне жисть облегчить?
везде где я писал "он" можно читать "представители заказчика в среднем". То есть есть такие, к которым претензий нет, но про них и разговор не идёт :)
--
...dali bude...
вот и приходится постоянно расписывать варианты бизнес-нидсов, чтобы он мог ткнуть пальцем "вот это". Потому что дождаться внятного описания истории от него сложно. Приоритезация тоже хромает, т.к. в силу этой специфики много приоритезирую я сам. В среднем получается неплохо, но иногда влетаем :) но не сильно. Уже подумываю о том, чтобы показать разок, что "не такая я уж и умная" - то есть сделать что-то специально тупо совсем не в том порядке, чтоб он понял, что надо следить и самому расставлять приоритеты. А с другой стороны сцыкотно :) да и реноме... Короче вот так и живём.
И есть у меня подозрение, что это не очень нетипичная ситуёвина. Вот я и подумал - может есть какие-то практики, которые могут мне жисть облегчить?
везде где я писал "он" можно читать "представители заказчика в среднем". То есть есть такие, к которым претензий нет, но про них и разговор не идёт :)
2008/10/21 Borys Lebeda <borys....@gmail.com>
--
...dali bude...
Borys Lebeda
Oct 21, 2008, 9:14:57 AM10/21/08
to agile-...@googlegroups.com
У меня основная проблема состоит в том, что контакт-персон с той стороны как бы это сказать... not-committed. Не то чтобы ему было начхать на успех проекта или он саботирует процесс, но ситуация в целом напоминает анекдот, где муж жене говорит "ну ты же у меня умная - придумай что-нибудь сама".
я называю это недостаточной мотивацией, можно было бы это назвать ленью, но чаще всего это не лень ...
вот и приходится постоянно расписывать варианты бизнес-нидсов, чтобы он мог ткнуть пальцем "вот это". Потому что дождаться внятного описания истории от него сложно. Приоритезация тоже хромает, т.к. в силу этой специфики много приоритезирую я сам. В среднем получается неплохо, но иногда влетаем :) но не сильно. Уже подумываю о том, чтобы показать разок, что "не такая я уж и умная" - то есть сделать что-то специально тупо совсем не в том порядке, чтоб он понял, что надо следить и самому расставлять приоритеты. А с другой стороны сцыкотно :) да и реноме... Короче вот так и живём.
И есть у меня подозрение, что это не очень нетипичная ситуёвина. Вот я и подумал - может есть какие-то практики, которые могут мне жисть облегчить?
Если Ты тот самый Sergiy Movchan, который в предыдущем треде грозился продемонстрировать некоторые best practices то милости прошу: Твой ход ...
везде где я писал "он" можно читать "представители заказчика в среднем". То есть есть такие, к которым претензий нет, но про них и разговор не идёт :)
2008/10/21 Borys Lebeda <borys....@gmail.com>Впрочем, помечтать можно:2008/10/21 Alexey Krivitsky <alexeyk...@gmail.com>
почему бы это не обсудить в новом топике?
какие требования-критерии вы выставляете к PO?
Обычно он выставляет к нам требования ...
- знать, что конечные пользователи хотят от системы
- уметь донести понимание системы до команды
- понимать приоритеты этих вещей
- не путать требования и реализацию
- быть доступным для команды и достаточно мотивированным, что бы давать квалифицированные ответы
- не делегировать полномочия людям, которые не удовлетворяют перечисленным выше пяти качествам или не расходятся во мнении с ним
- уметь всё это проверить
Если честно, я не видел ни одного человека который может выполнить хотя бы два пункта из того, что я перечислил ...
--
...dali bude...
--
Borys L.
Sergiy Movchan
Oct 21, 2008, 9:18:34 AM10/21/08
to agile-...@googlegroups.com
2008/10/21 Borys Lebeda <borys....@gmail.com>
я где-то грозился? :) это ты что-то не то прочитал - я как раз просил.
Я не рискну назвать то, что я делаю, бест практиками, т.к. меня текущая ситуёвина не удовлетворяет.
--
...dali bude...
Если Ты тот самый Sergiy Movchan, который в предыдущем треде грозился продемонстрировать некоторые best practices то милости прошу: Твой ход ...
Я не рискну назвать то, что я делаю, бест практиками, т.к. меня текущая ситуёвина не удовлетворяет.
--
...dali bude...
Borys Lebeda
Oct 21, 2008, 9:29:02 AM10/21/08
to agile-...@googlegroups.com
Да, действительно, я неправильно понял ... Прошу пардона.
Лично меня эта ситуёвина тоже не удовлетворяет, но я к ней привык. У кого-то должна болеть голова: либо на стороне команды, либо на стороне заказчика.
Лично меня эта ситуёвина тоже не удовлетворяет, но я к ней привык. У кого-то должна болеть голова: либо на стороне команды, либо на стороне заказчика.
В Agile у команды теоретически голова не болит: значит у ПО головняка должно быть больше ...
2008/10/21 Sergiy Movchan <sergiy....@gmail.com>
2008/10/21 Sergiy Movchan <sergiy....@gmail.com>
--
Borys L.
Evgeny Kompaniyets
Oct 21, 2008, 11:30:46 AM10/21/08
to Agile Software Development Group, Ukraine
Согласен - PO выбирают вместе с родиной :)
Т.е. можем поменять работу по этому критерию.
Для меня и некоторых моих знакомых PO - один из главных критериев при
выборе работы.
Из-за этого мы обычно не работаем в больших фирмах, иногда сами
становимся PO и т.п :)
> 2008/10/21 Alexey Krivitsky <alexeykrivit...@gmail.com>:
Т.е. можем поменять работу по этому критерию.
Для меня и некоторых моих знакомых PO - один из главных критериев при
выборе работы.
Из-за этого мы обычно не работаем в больших фирмах, иногда сами
становимся PO и т.п :)
> 2008/10/21 Alexey Krivitsky <alexeykrivit...@gmail.com>:
>
>
>
> > почему бы это не обсудить в новом топике?
>
> > какие требования-критерии вы выставляете к PO?
> > что он должен уметь делать? что может не уметь делать?
> > какой бекграунд у него должен быть? не должен быть?
>
> > 2008/10/21 Borys Lebeda <borys.leb...@gmail.com>
>
>
> > почему бы это не обсудить в новом топике?
>
> > какие требования-критерии вы выставляете к PO?
> > что он должен уметь делать? что может не уметь делать?
> > какой бекграунд у него должен быть? не должен быть?
>
>
> >> Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы
> >> определить какой должен быть ПО. Пока лично мне удаётся только определить
> >> каким он не должен быть:
>
> >>http://atriplex-on-software.blogspot.com/2008/10/where-to-start-build...
> >> Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы
> >> определить какой должен быть ПО. Пока лично мне удаётся только определить
> >> каким он не должен быть:
>
>
> >> Но я уверен, что рано или поздно появится инструкция как найти правильного
> >> ПО. Как знать может и сам придумаю ...
>
> >> 2 Sergiy Movchan: поделись best practices если они у Тебя есть :)
>
> >> 2008/10/21 Alexey Krivitsky <alexeykrivit...@gmail.com>
> >> Но я уверен, что рано или поздно появится инструкция как найти правильного
> >> ПО. Как знать может и сам придумаю ...
>
> >> 2 Sergiy Movchan: поделись best practices если они у Тебя есть :)
>
>
> >>> в настоящем мире, на сколько я вижу, многие PO на самом деле являются
> >>> проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.
>
> >>> 2008/10/21 Sergiy Movchan <sergiy.movc...@gmail.com>
> >>> в настоящем мире, на сколько я вижу, многие PO на самом деле являются
> >>> проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.
>
>
> >>>> вот если будет PO Proxy best practices, то я очень хочу. Сам по себе PO
> >>>> не интересен.
>
> >>>> On Tue, Oct 21, 2008 at 12:29 PM, Dmitry Danilchenko <dm1...@yahoo.com>
> >>>> wrote:
>
> >>>>> мне Product Owner интересно.
>
> >>>>> ________________________________
> >>>>> From: Tim Yevgrashyn <yevgras...@gmail.com>
> >>>> вот если будет PO Proxy best practices, то я очень хочу. Сам по себе PO
> >>>> не интересен.
>
> >>>> On Tue, Oct 21, 2008 at 12:29 PM, Dmitry Danilchenko <dm1...@yahoo.com>
> >>>> wrote:
>
> >>>>> мне Product Owner интересно.
>
> >>>>> ________________________________
> >>>>> To: agile-...@googlegroups.com
> >>>>> Sent: Tuesday, October 21, 2008 12:13:19 PM
> >>>>> Subject: [agile-ukraine] Re: Тренинги от Хенрика Книберга
>
> >>>>> Certified Product Owner :-D
>
> >>>>> Такого еще никто не читал в Украине
>
> >>>>> 2008/10/21 Alexey Krivitsky <alexeykrivit...@gmail.com>
> >>>>> Sent: Tuesday, October 21, 2008 12:13:19 PM
> >>>>> Subject: [agile-ukraine] Re: Тренинги от Хенрика Книберга
>
> >>>>> Certified Product Owner :-D
>
> >>>>> Такого еще никто не читал в Украине
>
Borys Lebeda
Oct 21, 2008, 12:21:37 PM10/21/08
to agile-...@googlegroups.com
Кстати, Женя, если Ты сам становишься ПО, стало у Тебя должны быть критерии насколько Ты хорош в этом деле ...
Но прежде всего: когда Ты - ПО, Ты работаешь с субподрядчиками или только с коллегами?
--
Borys L.
Но прежде всего: когда Ты - ПО, Ты работаешь с субподрядчиками или только с коллегами?
2008/10/21 Evgeny Kompaniyets <evg...@gmail.com>
--
Borys L.
Evgeny Kompaniets
Oct 21, 2008, 1:56:37 PM10/21/08
to agile-...@googlegroups.com
Сразу оговорюсь, что говоря здесь о PO я понимаю заказчика в терминах
XP. Мое понимание скрама ограничивается паралелями с XP и возможно
может привести к ошибке, которую если такая возникнет, я надеюсь
кто-нибудь исправит.
Подумав, я понял, что похоже никогда не был, так сказать 100% PO. Я
несколько раз был прокси и последнее время пытаюсь одновременно
находиться в командах PO и програмистов. В команде PO в моем текущем
проекте есть один человек, который принимает финальные решения (обычно
это нужно только в случае конфликтов).
С субподрядчиками никогда не делал ничего серьезнее веб дизайна и верстки.
XP. Мое понимание скрама ограничивается паралелями с XP и возможно
может привести к ошибке, которую если такая возникнет, я надеюсь
кто-нибудь исправит.
Подумав, я понял, что похоже никогда не был, так сказать 100% PO. Я
несколько раз был прокси и последнее время пытаюсь одновременно
находиться в командах PO и програмистов. В команде PO в моем текущем
проекте есть один человек, который принимает финальные решения (обычно
это нужно только в случае конфликтов).
С субподрядчиками никогда не делал ничего серьезнее веб дизайна и верстки.
На вопрос как хорош я как PO я лучше расскажу о тех 100% PO с которыми
работал последнее время. По-моему с точки зрения процесса, там все
довольно хорошо.
Основные сложности за рамками процесса. Например:
- придумать удобный интерфейс
- угадать проблемы пользователя нового продукта еще до того, как этот
пользователь появился
- придумать изменения бизнесс процесса который приведет к более
эфективной работе компании. Этот бизнес процесс как раз и
автоматизируется разрабатываемым софтом и глазами разработчика - это
придумывание новой фичи к софту.
Рассказывать что надо делать, расставлять приоритеты и не заниматься
не своей работой, как показывает опыт, довольно легко научиться.
Мне кажется главные сложности для украинских реалий - это аусорсинг
который идет с двумя проблемами: обычно плохой с точки зрения agile
заказчик (PO) и распределенность участников проекта. Почему это так -
большой отдельный разговор :)
Я предпочитаю избегать таких проектов, из-за чего мой опыт борьбы с
этими проблемами незначительный. Зачем заниматься процессом, если
можно писать программу? :)
Не кидайте в меня камнями - знаю, что здесь много тех, кто не смотря
на эти проблемы многое делает.
2008/10/21 Borys Lebeda <borys....@gmail.com>:
--
Evgeny Kompaniets
Artem Marchenko
Oct 21, 2008, 2:15:49 PM10/21/08
to Agile Software Development Group, Ukraine
Привет всем
Мне кажется, что требования к PO точно так же зависят от потребностей
и реалий конкретного проекта, как и требования к команде, процессу,
оборудованию и т.д. Человек идеально подходящий для одного случая,
может не справляться с другим проектом.
Если же в общих чертах, по для меня хороший Product Owner - это прежде
всего человек понимающий в бизнес причинах и приоритетах проекта и
умеющий говорить об этом с командой.
Идеальный Product Owner - это, разумеется, сам клиент имеющий понятие
о программировании в данной предметной области, вежливый, болеющий за
дело, не боящийся признавать ответственноть и ошибки и имеющий время
на всё то, что перечислил Борис. Такие Product Owner'ы в природе
действительно встречаются, но не очень часто, а у многих проектов и
конкретного клиента-то нет. Ну что ж, Scrum is the art of possible и
если Product Owner готов учиться, можно потихоньку двигаться к идеалу
вместе с ним. Я так понимаю, что многие участники этой группы Scrum
Master'а и как Scrum Master'а как раз и отвечают за обучение Скраму в
возможных пределах.
Удачи!
Артём.
On Oct 21, 3:47 pm, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> 2008/10/21 Alexey Krivitsky <alexeykrivit...@gmail.com>
Мне кажется, что требования к PO точно так же зависят от потребностей
и реалий конкретного проекта, как и требования к команде, процессу,
оборудованию и т.д. Человек идеально подходящий для одного случая,
может не справляться с другим проектом.
Если же в общих чертах, по для меня хороший Product Owner - это прежде
всего человек понимающий в бизнес причинах и приоритетах проекта и
умеющий говорить об этом с командой.
Идеальный Product Owner - это, разумеется, сам клиент имеющий понятие
о программировании в данной предметной области, вежливый, болеющий за
дело, не боящийся признавать ответственноть и ошибки и имеющий время
на всё то, что перечислил Борис. Такие Product Owner'ы в природе
действительно встречаются, но не очень часто, а у многих проектов и
конкретного клиента-то нет. Ну что ж, Scrum is the art of possible и
если Product Owner готов учиться, можно потихоньку двигаться к идеалу
вместе с ним. Я так понимаю, что многие участники этой группы Scrum
Master'а и как Scrum Master'а как раз и отвечают за обучение Скраму в
возможных пределах.
Удачи!
Артём.
On Oct 21, 3:47 pm, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> 2008/10/21 Alexey Krivitsky <alexeykrivit...@gmail.com>
Artjom Serdyuk
Oct 21, 2008, 4:07:07 PM10/21/08
to Agile Software Development Group, Ukraine
У нас был человек на голландской стороне, который был совершенно
невыносим в качестве Продакт менеджера. Он предлагал технические
решения, постоянно менял планы, задавал идиотские вопросы, не отвечал
на письма, лез не в своё дело и т.п.
Сейчас он - лучший Продакт оунер из всех, кто работает с украинскими
командами. Смотря на него, я вижу вот такие критерии "хорошести":
а) РО должен отвечать хоть чем-то за результат проекта. Коммитмент
приложится.
б) РО обязательно кто-то должен обучить и поддерживать. В нашем случае
Маурисом занялись лично Chief Technological и Chief Informational
компании. После двух месяцев муштры глупые вопросы сошли на нет.
в) РО должен хорошо относиться к команде разработке и обязательно быть
лично с ними знакомым. После визита "ужасного Мауриса" в Украину,
когда он лично познакомился с командой (и понял какие же мы
классные )). Ну и народу здесь тоже стало понятно, что он - вполне
вменяемый чувак. После этого общение поменялось кардинально в лучшую
сторону.
в) РО должен быть толковым. Остальное наберётся автоматом.
Результат: за 3 месяца человек полностью поменял стиль работы и стал
чуть ли не лучшим Продакт оунером компании.
З.Ы. Уж не те ли это бест прэктисес, которых просил Сергей? ;))
On Oct 21, 3:38 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> >>>> *From:* Tim Yevgrashyn <yevgras...@gmail.com>
> >>>> *To:* agile-...@googlegroups.com
> >>>> *Sent:* Tuesday, October 21, 2008 12:13:19 PM
> >>>> *Subject:* [agile-ukraine] Re: Тренинги от Хенрика Книберга
> >>>>> Certified ScrumMaster and Practitioner
> >>>>> Agile coach and trainer at SCRUMguides.com <http://scrumguides.com/>
невыносим в качестве Продакт менеджера. Он предлагал технические
решения, постоянно менял планы, задавал идиотские вопросы, не отвечал
на письма, лез не в своё дело и т.п.
Сейчас он - лучший Продакт оунер из всех, кто работает с украинскими
командами. Смотря на него, я вижу вот такие критерии "хорошести":
а) РО должен отвечать хоть чем-то за результат проекта. Коммитмент
приложится.
б) РО обязательно кто-то должен обучить и поддерживать. В нашем случае
Маурисом занялись лично Chief Technological и Chief Informational
компании. После двух месяцев муштры глупые вопросы сошли на нет.
в) РО должен хорошо относиться к команде разработке и обязательно быть
лично с ними знакомым. После визита "ужасного Мауриса" в Украину,
когда он лично познакомился с командой (и понял какие же мы
классные )). Ну и народу здесь тоже стало понятно, что он - вполне
вменяемый чувак. После этого общение поменялось кардинально в лучшую
сторону.
в) РО должен быть толковым. Остальное наберётся автоматом.
Результат: за 3 месяца человек полностью поменял стиль работы и стал
чуть ли не лучшим Продакт оунером компании.
З.Ы. Уж не те ли это бест прэктисес, которых просил Сергей? ;))
On Oct 21, 3:38 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> почему бы это не обсудить в новом топике?
>
> какие требования-критерии вы выставляете к PO?
> что он должен уметь делать? что может не уметь делать?
> какой бекграунд у него должен быть? не должен быть?
>
> 2008/10/21 Borys Lebeda <borys.leb...@gmail.com>
>
> какие требования-критерии вы выставляете к PO?
> что он должен уметь делать? что может не уметь делать?
> какой бекграунд у него должен быть? не должен быть?
>
>
>
>
> > Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы
> > определить какой должен быть ПО. Пока лично мне удаётся только определить
> > каким он не должен быть:
>
> >http://atriplex-on-software.blogspot.com/2008/10/where-to-start-build...
>
>
> > Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы
> > определить какой должен быть ПО. Пока лично мне удаётся только определить
> > каким он не должен быть:
>
>
> > Но я уверен, что рано или поздно появится инструкция как найти правильного
> > ПО. Как знать может и сам придумаю ...
>
> > 2 Sergiy Movchan: поделись best practices если они у Тебя есть :)
>
> > 2008/10/21 Alexey Krivitsky <alexeykrivit...@gmail.com>
> > Но я уверен, что рано или поздно появится инструкция как найти правильного
> > ПО. Как знать может и сам придумаю ...
>
> > 2 Sergiy Movchan: поделись best practices если они у Тебя есть :)
>
>
> >> в настоящем мире, на сколько я вижу, многие PO на самом деле являются
> >> проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.
>
> >> 2008/10/21 Sergiy Movchan <sergiy.movc...@gmail.com>
> >> в настоящем мире, на сколько я вижу, многие PO на самом деле являются
> >> проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.
>
>
> >> вот если будет PO Proxy best practices, то я очень хочу. Сам по себе PO не
> >>> интересен.
>
> >>> On Tue, Oct 21, 2008 at 12:29 PM, Dmitry Danilchenko <dm1...@yahoo.com>wrote:
>
> >>>> мне Product Owner интересно.
>
> >>>> ------------------------------
> >> вот если будет PO Proxy best practices, то я очень хочу. Сам по себе PO не
> >>> интересен.
>
> >>> On Tue, Oct 21, 2008 at 12:29 PM, Dmitry Danilchenko <dm1...@yahoo.com>wrote:
>
> >>>> мне Product Owner интересно.
>
> >>>> *From:* Tim Yevgrashyn <yevgras...@gmail.com>
> >>>> *To:* agile-...@googlegroups.com
> >>>> *Sent:* Tuesday, October 21, 2008 12:13:19 PM
> >>>> *Subject:* [agile-ukraine] Re: Тренинги от Хенрика Книберга
>
> >>>> Certified Product Owner :-D
>
> >>>> Такого еще никто не читал в Украине
>
> >>>> 2008/10/21 Alexey Krivitsky <alexeykrivit...@gmail.com>
> >>>> Certified Product Owner :-D
>
> >>>> Такого еще никто не читал в Украине
>
>
> >>>>> привет,
>
> >>>>> хенрик готов приехать в районе 16-17 декабря в украину.
> >>>>> есть желающие посетить csm класс?
>
> >>>>> хенрик готов читать любой другой материал, не обязательно certified
> >>>>> scrummaster.
> >>>>> стоимость его гонорара при этом остаётся фиксированной.
> >>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе порядка
> >>>>> 370-400 долларов с участника.
>
> >>>>> какие тренинги вам было бы интересно посетить?
>
> >>>>> --
> >>>>> Alexey Krivitsky,
> >>>>> Coordinator of AgileUkraine.org <http://agileukraine.org/>
> >>>>> привет,
>
> >>>>> хенрик готов приехать в районе 16-17 декабря в украину.
> >>>>> есть желающие посетить csm класс?
>
> >>>>> хенрик готов читать любой другой материал, не обязательно certified
> >>>>> scrummaster.
> >>>>> стоимость его гонорара при этом остаётся фиксированной.
> >>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе порядка
> >>>>> 370-400 долларов с участника.
>
> >>>>> какие тренинги вам было бы интересно посетить?
>
> >>>>> --
> >>>>> Alexey Krivitsky,
> >>>>> Certified ScrumMaster and Practitioner
> >>>>> Agile coach and trainer at SCRUMguides.com <http://scrumguides.com/>
Alexander Rivkind
Oct 22, 2008, 1:54:09 PM10/22/08
to agile-...@googlegroups.com
А кто что думает о таком:
1. Отличаются ли "хороший product owner" и "хороший product manager"?
2. Одинаковые ли критерии для Product Owner проекта и продукта?
--
Best Regards, Alik.
1. Отличаются ли "хороший product owner" и "хороший product manager"?
2. Одинаковые ли критерии для Product Owner проекта и продукта?
2008/10/21 Artjom Serdyuk <artem....@gmail.com>
--
Best Regards, Alik.
Evgeny Kompaniyets
Oct 22, 2008, 2:41:47 PM10/22/08
to Agile Software Development Group, Ukraine
Сегодня Сергей Руженков напомнил мне об очень важном моменте в работе
PO.
В свободное время Серега поддерживает несколько проектов с его
предыдущей работы.
Сегодня его заказчикам позарез понадобилась новая фича и они пришли к
нам в комнату слезно просить его пообщаться с ними на эту тему.
Заказчики - две женщины из финансового отдела (финансовый софт).
Серега пообщался с ними полчаса и вернувшись отметил, что как это
часто бывает, они вместе придумали фичу, которую он может реализовать
за 15 мин.
Что там произошло на самом деле: заказчик пришел с бизнес проблемой и
предполагаемым решением. Под решением я имею ввиду не то как это будет
програмироваться (благо его финансисты не умеют програмировать), а
набор фич, которые надо добавить в софт, чтобы решать их бизнес
проблему.
Их решение на первый взгляд было довольно неплохим. Необходимо
добавить довольно значительную функциональность в программу, которая
будет решать возникшую бизнес задачу. Решение довольно удобно - в
интерфейсе появляются соответствующие изменения, позволяющие
пользователям решать новые задачи.
Что делает Серега? Он начинает задавать правильные вопросы. Делает он
это замечательно - я знаю очень мало людей, которые умеют так
эфективно общаться в таких ситуациях с людьми, которые не являются
програмистами :) Получая на них ответы он докапывается до сути их
реальной проблемы, не обращая внимание на то, что они предлагают
добавить в софт. В результате они находят простейшее решение,
сводящееся к изменению нескольких xml файликов. Интерфейс похоже
несколько хуже того, что они предлагали изначально, но совершенно
несравним по цене.
Эта история демонстрирует важнейшую ценность PO: уметь отказываться от
ненужных фич.
Звучит это просто, но на практике часто получается плохо.
Напоследок предлагаю развлечься следующим упражнением (как раз
связанным с вопросом отличий ПО, от ПМ и т.п):
Дайте ответ на вопрос: какую роль в этой истории играл Серега? Продакт
Онера? Скрам Мастера? Програмиста? Менеджера проэкта? Ваш вариант?
PO.
В свободное время Серега поддерживает несколько проектов с его
предыдущей работы.
Сегодня его заказчикам позарез понадобилась новая фича и они пришли к
нам в комнату слезно просить его пообщаться с ними на эту тему.
Заказчики - две женщины из финансового отдела (финансовый софт).
Серега пообщался с ними полчаса и вернувшись отметил, что как это
часто бывает, они вместе придумали фичу, которую он может реализовать
за 15 мин.
Что там произошло на самом деле: заказчик пришел с бизнес проблемой и
предполагаемым решением. Под решением я имею ввиду не то как это будет
програмироваться (благо его финансисты не умеют програмировать), а
набор фич, которые надо добавить в софт, чтобы решать их бизнес
проблему.
Их решение на первый взгляд было довольно неплохим. Необходимо
добавить довольно значительную функциональность в программу, которая
будет решать возникшую бизнес задачу. Решение довольно удобно - в
интерфейсе появляются соответствующие изменения, позволяющие
пользователям решать новые задачи.
Что делает Серега? Он начинает задавать правильные вопросы. Делает он
это замечательно - я знаю очень мало людей, которые умеют так
эфективно общаться в таких ситуациях с людьми, которые не являются
програмистами :) Получая на них ответы он докапывается до сути их
реальной проблемы, не обращая внимание на то, что они предлагают
добавить в софт. В результате они находят простейшее решение,
сводящееся к изменению нескольких xml файликов. Интерфейс похоже
несколько хуже того, что они предлагали изначально, но совершенно
несравним по цене.
Эта история демонстрирует важнейшую ценность PO: уметь отказываться от
ненужных фич.
Звучит это просто, но на практике часто получается плохо.
Напоследок предлагаю развлечься следующим упражнением (как раз
связанным с вопросом отличий ПО, от ПМ и т.п):
Дайте ответ на вопрос: какую роль в этой истории играл Серега? Продакт
Онера? Скрам Мастера? Програмиста? Менеджера проэкта? Ваш вариант?
Sergiy Movchan
Oct 22, 2008, 3:01:21 PM10/22/08
to agile-...@googlegroups.com
Artem Marchenko
Oct 22, 2008, 3:04:21 PM10/22/08
to Agile Software Development Group, Ukraine
Привет
Product Manager - это одна из самых неопределённых должностей в мире.
В некоторых фирмах они выполняют роль сейлсов, в некоторых - погибают
в подробном документальном оформлении требований, в некоторых -
передают пожелания настоящего начальника и тестируют и т.д. В идеале,
конечно, Product Manager - это голос клиента - человек знающий
потребности рынка, способный выделить нерешённые проблемы конкретного
сегмента рынка, определить какие из них именно его фирма может
удовлетворить лучше конкурентов и умеющий говорить обо всём этом с топ-
менеджментом и хотя бы с начальником инженеров. Но это - идеальный и
редко встречающийся в природе случай.
Scrum Product Owner. с другой стороны, - это сложная, но достаточно
определённая роль процесса. Причём, частенько эту роль играют
несколько человек. Сравнивать слабо определённую должность с ролью не
очень просто, но если попробоват упростить, то PM - это PO сдвинутый в
сторону маркетинга, бизнеса и вообще клиента, а PO - это PM сдвинутый
в сторону технической команды. Ну и кроме того, Scrum PO может
работать не только над созданием нового продукта, но и, скажем, над
мелкой поддержкой предыдущего.
Удачи!
Артём.
On Oct 22, 8:54 pm, "Alexander Rivkind" <alik1...@gmail.com> wrote:
> А кто что думает о таком:
> 1. Отличаются ли "хороший product owner" и "хороший product manager"?
> 2. Одинаковые ли критерии для Product Owner проекта и продукта?
>
> 2008/10/21 Artjom Serdyuk <artem.serd...@gmail.com>
Product Manager - это одна из самых неопределённых должностей в мире.
В некоторых фирмах они выполняют роль сейлсов, в некоторых - погибают
в подробном документальном оформлении требований, в некоторых -
передают пожелания настоящего начальника и тестируют и т.д. В идеале,
конечно, Product Manager - это голос клиента - человек знающий
потребности рынка, способный выделить нерешённые проблемы конкретного
сегмента рынка, определить какие из них именно его фирма может
удовлетворить лучше конкурентов и умеющий говорить обо всём этом с топ-
менеджментом и хотя бы с начальником инженеров. Но это - идеальный и
редко встречающийся в природе случай.
Scrum Product Owner. с другой стороны, - это сложная, но достаточно
определённая роль процесса. Причём, частенько эту роль играют
несколько человек. Сравнивать слабо определённую должность с ролью не
очень просто, но если попробоват упростить, то PM - это PO сдвинутый в
сторону маркетинга, бизнеса и вообще клиента, а PO - это PM сдвинутый
в сторону технической команды. Ну и кроме того, Scrum PO может
работать не только над созданием нового продукта, но и, скажем, над
мелкой поддержкой предыдущего.
Удачи!
Артём.
On Oct 22, 8:54 pm, "Alexander Rivkind" <alik1...@gmail.com> wrote:
> А кто что думает о таком:
> 1. Отличаются ли "хороший product owner" и "хороший product manager"?
> 2. Одинаковые ли критерии для Product Owner проекта и продукта?
>
Anton Maryukhnenko
Oct 22, 2008, 3:06:03 PM10/22/08
to agile-...@googlegroups.com
Borys Lebeda
Oct 22, 2008, 5:18:04 PM10/22/08
to agile-...@googlegroups.com
Я тоже назвал бы такую работу аналитической. Может быть из-за образования полученного в Институте Прикладного Системного Анализа. А может просто профессиональный стереотип.
4 года назад я работал аналитиком на стороне заказчика. Это было славное время сидишь полдня в чужой конторе, любезничаешь с бухгалтерами и их грозными начальниками (совсем не Agile-среда) и формулируешь требования, потом доступно объясняешь как работает система и почему её нельзя было сделать как они просили;
Тогда я не знал Agile, о водопаде знал из курса по современным технологиям программирования, а программировать вообще не умел. Да, я был аналитиком на 100% (и программистом на 0%).
Спустя 4 года я не могу сказать что я был хоть чуть-чуть ПО.
Между аналитиком и менеджером есть существенная разница: менеджер наделён административными полномочиями: он расставляет приоритеты. И ПО должен быть наделён т.е. он должен быть менеджером. Это не значит, что ему можно пренебречь аналитическими навыками - как раз исходя из того, что я написал ранее, нельзя. Более того, он чаще всего не может эффективно делегировать принятие решений другим аналитикам: "мыши должны стать ёжиками, а вы додумайте как ..."
Кстати, большинство известных мне ПО с лёгкостью отказываются от фич, когда им предоставляют смету затрат. Чаще всего разработчики не могут отказаться от программирования не нужных фич ...
2008/10/22 Evgeny Kompaniyets <evg...@gmail.com>
Alexander Rivkind
Oct 23, 2008, 4:01:12 AM10/23/08
to agile-...@googlegroups.com
Совершено однозначно - аналитик.
Наиболее точно было бы его назвать knowledge engineer, но в IT своя терминология :)
К product management это уж точно никакого отношения не имеет.
--
Best Regards, Alik.
Наиболее точно было бы его назвать knowledge engineer, но в IT своя терминология :)
К product management это уж точно никакого отношения не имеет.
2008/10/22 Sergiy Movchan <sergiy....@gmail.com>
--
Best Regards, Alik.
Evgeny Kompaniyets
Oct 23, 2008, 2:01:02 PM10/23/08
to Agile Software Development Group, Ukraine
Эх, читаю ответы, потом перечитывают свой пост и понимаю, что хотел
написать об одном, а получилось как всегда.
Попытаюсь исправить ошибку.
В моем описании работы Сергея получилось, что он практически придумал
другой интерфейс, который решает туже проблему что и вариант
заказчика, но просто проще в реализации.
На самом деле все обстоит иначе:
Заказчик приходит с набором фич, а после разговора с Сергеем просто
отказывается делать большую часть того, что он хотел.
Попробую описать на детальном примере. Пример я придумал. Возможно он
не самый удачный, но лучше пока не могу :)
Итак:
Пускай мы пишем приложение.
У нас уже реализована фича аутентификации по корпоративному LDAP
серверу. В настройках можно описать сервер, после чего работает single
sign-on.
Приходит заказчик и просит добавить поддержкy нескольких LDAP серверов
и несколько внешних систем аутентификации (типа пускаем в систему
gmail, yahoo и msn пользователей).
Все это можно задать в настройках и прозрачно пользоваться нашим
софтом смогут пользователи всех описанных систем.
Фича понятна, мы можем ее оценить. Заказчика устраивает наша оценка.
Можно работать.
Вот здесь и появляется Серега с вопросом: зачем эта фича нужна?
Обычно заказчик раскалывается не сразу. Сначала он рассказывает про то
как это круто и как удобно это будет. Он увлекся фичей также, как
програмист иногда увлекается новой технологией. Часто послушав
заказчика програмисты заряжаются его энергией и бросаются делать новую
прикольную фичу.
Но Серега на такие уловки не поддадется! :)
На самом деле заказчику нужно поддержать следующий сценарий: дать
возможность работать нескольким пользователям, которых нет в
корпоративном LDAP. Таких пользователей будет обычно совсем немного а
иногда не будет совсем. Эта фича довольно сильно отличается от того, с
чем пришел заказчик.
Реализовать поддержку gmail, yahoo и msn потребовало бы несравнимо
больше времени, чем то, к чему мы пришли.
Что в этой истории я хочу подчеркнуть:
1. Стандарный механизм дать заказчику оценку, после которой он
откажется делать фичу не работает. Этот метод скорее сработает в
ситуациях, когда оценка заказчика например страшно напугает и он
вспомнит сам с чего начал. Но часто это не так.
2. Есть очень большая вероятность, что "придуманая" подобным образом
фича потом переделывается или выбрасывается совсем. Именно потому, что
она реализовывает не то, что действительно нужно, а то что заказчку
понравилось. Такие примеры были на практике неоднократно. Теперь мы
стараемся такое не допускать.
С учетам второго пункта экономию от вмешательства Сергея на проекте
трудно переоценить :)
В этом описании роль Сергея меняется?
написать об одном, а получилось как всегда.
Попытаюсь исправить ошибку.
В моем описании работы Сергея получилось, что он практически придумал
другой интерфейс, который решает туже проблему что и вариант
заказчика, но просто проще в реализации.
На самом деле все обстоит иначе:
Заказчик приходит с набором фич, а после разговора с Сергеем просто
отказывается делать большую часть того, что он хотел.
Попробую описать на детальном примере. Пример я придумал. Возможно он
не самый удачный, но лучше пока не могу :)
Итак:
Пускай мы пишем приложение.
У нас уже реализована фича аутентификации по корпоративному LDAP
серверу. В настройках можно описать сервер, после чего работает single
sign-on.
Приходит заказчик и просит добавить поддержкy нескольких LDAP серверов
и несколько внешних систем аутентификации (типа пускаем в систему
gmail, yahoo и msn пользователей).
Все это можно задать в настройках и прозрачно пользоваться нашим
софтом смогут пользователи всех описанных систем.
Фича понятна, мы можем ее оценить. Заказчика устраивает наша оценка.
Можно работать.
Вот здесь и появляется Серега с вопросом: зачем эта фича нужна?
Обычно заказчик раскалывается не сразу. Сначала он рассказывает про то
как это круто и как удобно это будет. Он увлекся фичей также, как
програмист иногда увлекается новой технологией. Часто послушав
заказчика програмисты заряжаются его энергией и бросаются делать новую
прикольную фичу.
Но Серега на такие уловки не поддадется! :)
На самом деле заказчику нужно поддержать следующий сценарий: дать
возможность работать нескольким пользователям, которых нет в
корпоративном LDAP. Таких пользователей будет обычно совсем немного а
иногда не будет совсем. Эта фича довольно сильно отличается от того, с
чем пришел заказчик.
Реализовать поддержку gmail, yahoo и msn потребовало бы несравнимо
больше времени, чем то, к чему мы пришли.
Что в этой истории я хочу подчеркнуть:
1. Стандарный механизм дать заказчику оценку, после которой он
откажется делать фичу не работает. Этот метод скорее сработает в
ситуациях, когда оценка заказчика например страшно напугает и он
вспомнит сам с чего начал. Но часто это не так.
2. Есть очень большая вероятность, что "придуманая" подобным образом
фича потом переделывается или выбрасывается совсем. Именно потому, что
она реализовывает не то, что действительно нужно, а то что заказчку
понравилось. Такие примеры были на практике неоднократно. Теперь мы
стараемся такое не допускать.
С учетам второго пункта экономию от вмешательства Сергея на проекте
трудно переоценить :)
В этом описании роль Сергея меняется?
Alexander Rivkind
Oct 23, 2008, 2:40:05 PM10/23/08
to agile-...@googlegroups.com
Думаю нет.
До тех пор, пока есть заказчик, который приходит с просьбой "я хочу то-то и то-то", роль product manager играет именно заказчик.
Безусловно, Сергей талантливый аналитик, удовлетворяющий заказчика минимальными усилиями. :)
Но все же аналитик.
Я так понимаю, во всяком случае.
--
Best Regards, Alik.
До тех пор, пока есть заказчик, который приходит с просьбой "я хочу то-то и то-то", роль product manager играет именно заказчик.
Безусловно, Сергей талантливый аналитик, удовлетворяющий заказчика минимальными усилиями. :)
Но все же аналитик.
Я так понимаю, во всяком случае.
2008/10/23 Evgeny Kompaniyets <evg...@gmail.com>
--
Best Regards, Alik.
Sergiy Movchan
Oct 23, 2008, 3:32:39 PM10/23/08
to agile-...@googlegroups.com
нет. разве что можно добавить "толковый" впереди "анатилитк"а :)
--
...dali bude...
2008/10/23 Evgeny Kompaniyets <evg...@gmail.com>
--
...dali bude...
Borys Lebeda
Oct 23, 2008, 5:34:08 PM10/23/08
to agile-...@googlegroups.com
Ещё интереснее бывает когда аналитик говорит бизнесмену как улучшить бизнес процессы. Это тоже нормально: когда я работал аналитиком, помогая автоматизировать бухгалтерский учёт, это было обычной практикой: дело в том, что хаос не поддаётся автоматизации.
Если порядок очень сложный, то он также приравнивается к хаосу. Его нужно упростить. Большой бизнес должен быть простым. Не верите? Прочитайте историю FedEx ...
ИМХО, отличие ПО от аналитика заключается в том, что последний не имеет админресурса.
--
Borys L.
Если порядок очень сложный, то он также приравнивается к хаосу. Его нужно упростить. Большой бизнес должен быть простым. Не верите? Прочитайте историю FedEx ...
ИМХО, отличие ПО от аналитика заключается в том, что последний не имеет админресурса.
2008/10/23 Evgeny Kompaniyets <evg...@gmail.com>
--
Borys L.
Alexander Rivkind
Oct 24, 2008, 3:11:36 AM10/24/08
to agile-...@googlegroups.com
А что такое админресурс в данном контексте?
--
Best Regards, Alik.
2008/10/24 Borys Lebeda <borys....@gmail.com>
--
Best Regards, Alik.
Borys Lebeda
Oct 24, 2008, 3:17:33 AM10/24/08
to agile-...@googlegroups.com
Официальное право принимать решения.
Я понимаю, можно сказать, что у каждого есть право принимать решения, но официальное право есть не у всех:
генерал всегда остаётся генералом, даже если решения за него принимает жена или любовница :)
--
Borys L.
Я понимаю, можно сказать, что у каждого есть право принимать решения, но официальное право есть не у всех:
генерал всегда остаётся генералом, даже если решения за него принимает жена или любовница :)
2008/10/24 Alexander Rivkind <alik...@gmail.com>
--
Borys L.
Alexander Rivkind
Oct 24, 2008, 3:30:24 AM10/24/08
to agile-...@googlegroups.com
Не-не, официальное право принимать решение "что делать" есть только у бизнеса. Полностью согласен, аналитик таким правом не обладает.
--
Best Regards, Alik.
2008/10/24 Borys Lebeda <borys....@gmail.com>
--
Best Regards, Alik.
Alexander Rivkind
Oct 24, 2008, 3:32:07 AM10/24/08
to agile-...@googlegroups.com
А что по поводу:
2. Одинаковые ли критерии для Product Owner проекта и продукта?
--
Best Regards, Alik.
2. Одинаковые ли критерии для Product Owner проекта и продукта?
Best Regards, Alik.
Alexey Krivitsky
Oct 24, 2008, 5:32:10 AM10/24/08
to agile-...@googlegroups.com
Product Owner называется так, чтобы дать понять, что он должен быть один на продукт. Если у вас один продукт и много проектов, наличие множества оунеров - это путь к локальным оптимизациям, компонентным командам и, как следствие, к водопаду.
Так считает гуру Bas Vodde, которого я уважаю.
Так считает гуру Bas Vodde, которого я уважаю.
Alexander Rivkind
Oct 24, 2008, 5:38:36 AM10/24/08
to agile-...@googlegroups.com
Ты имеешь в виду ситуацию, когда одному продукту соответствует более одного проекта и у каждого проекта свой Product Owner?
--
Best Regards, Alik.
2008/10/24 Alexey Krivitsky <alexeyk...@gmail.com>
--
Best Regards, Alik.
Alexey Krivitsky
Oct 24, 2008, 5:44:35 AM10/24/08
to agile-...@googlegroups.com
Alexander Rivkind
Oct 24, 2008, 5:52:22 AM10/24/08
to agile-...@googlegroups.com
А в этом есть смысл?
В "классике" это был бы один product manager и несколько project manager.
--
Best Regards, Alik.
В "классике" это был бы один product manager и несколько project manager.
2008/10/24 Alexey Krivitsky <alexeyk...@gmail.com>
--
Best Regards, Alik.
Alexey Krivitsky
Oct 24, 2008, 12:09:10 PM10/24/08
to agile-...@googlegroups.com
в классике был водопад.
Артур Ракицкий
Oct 25, 2008, 10:17:06 AM10/25/08
to agile-...@googlegroups.com
Несогласная я! :)
В "классике" (если мы говорим о современный процессах - MSF и RUP) продакт все же один для одного продукта (решения)! Но в виде роли, которую может выполнять команда Product managers + Analysts, во главе с единственным человеком, который их координирует, и без которого не принимаются решения в данной области деятельности. Участники этой группы могут каждый отвечать за отдельный подчиненный продукт (компоненту, или набор функций в рамках отдельного набора бизнес процессов). Но отдельный участник группы принимает решения ИСКЛЮЧИТЕЛЬНО внутри своей области компетенции, и любое решение, влияющее хоть каким-то образом на другие области - выносит на обсуждение с участием руководителя группы Продактов.
Аналогично и с ролью Program manager (Project manager в RUP) - может быть командой, в которой каждый из менеджеров ведет отдельный подпроект, но ОБЯЗАТЕЛЬНО есть глава команды, и главный проект, в рамках которого и принимаются решения, и идет взаимодействие с другими ролями.
А вот уже разработка, тестирование, развертывание - эти деятельности в "классике" можно организовать либо по тому же принципу - с главным архитектором, QA и главой саппорта, так и раздельно - в рамках отдельных подпроектов. Тут уж зависит от эффективности взаимодействия команд. Например, если подпроекты на 80% базируются на общем коде, и этот общий код часто редизайнится - нужен руководитель. Если общего кода крайне мало (или используются готовые сторонние решения), или общий код меняется раз в 3 года - тогда лучше всех разделить - управляемость улучшится.
Так что не нужно так вот сразу "обламывать" - мол "водопад", и это не лечится :) Было бы все так грустно - уже бы 99% команд работали "гибко" :) Люди в нашем деле быстро учатся :)
--
С уважением,
Артур Ракицкий
------------------
ICQ: 21062147
В "классике" (если мы говорим о современный процессах - MSF и RUP) продакт все же один для одного продукта (решения)! Но в виде роли, которую может выполнять команда Product managers + Analysts, во главе с единственным человеком, который их координирует, и без которого не принимаются решения в данной области деятельности. Участники этой группы могут каждый отвечать за отдельный подчиненный продукт (компоненту, или набор функций в рамках отдельного набора бизнес процессов). Но отдельный участник группы принимает решения ИСКЛЮЧИТЕЛЬНО внутри своей области компетенции, и любое решение, влияющее хоть каким-то образом на другие области - выносит на обсуждение с участием руководителя группы Продактов.
Аналогично и с ролью Program manager (Project manager в RUP) - может быть командой, в которой каждый из менеджеров ведет отдельный подпроект, но ОБЯЗАТЕЛЬНО есть глава команды, и главный проект, в рамках которого и принимаются решения, и идет взаимодействие с другими ролями.
А вот уже разработка, тестирование, развертывание - эти деятельности в "классике" можно организовать либо по тому же принципу - с главным архитектором, QA и главой саппорта, так и раздельно - в рамках отдельных подпроектов. Тут уж зависит от эффективности взаимодействия команд. Например, если подпроекты на 80% базируются на общем коде, и этот общий код часто редизайнится - нужен руководитель. Если общего кода крайне мало (или используются готовые сторонние решения), или общий код меняется раз в 3 года - тогда лучше всех разделить - управляемость улучшится.
Так что не нужно так вот сразу "обламывать" - мол "водопад", и это не лечится :) Было бы все так грустно - уже бы 99% команд работали "гибко" :) Люди в нашем деле быстро учатся :)
24 октября 2008 г. 19:09 пользователь Alexey Krivitsky <alexeyk...@gmail.com> написал:
--
С уважением,
Артур Ракицкий
------------------
ICQ: 21062147
Alexander Rivkind
Oct 25, 2008, 5:51:55 PM10/25/08
to agile-...@googlegroups.com
Alexander Rivkind
Oct 25, 2008, 6:04:37 PM10/25/08
to agile-...@googlegroups.com
Письмо отправилось до того, как дописалось :)
--
Best Regards, Alik.
Так вот, здесь и начинается полный бардак в терминологии. В результате я ничего не понял в посте ниже...
Помимо прочего, Program Manager и Project Manager - это все же не одно и то же. Но как Program Manager может быть командой?... Что это вообще значит? :)
Единственное, что понял - это то, что классика - не обязательно водопад. И с этим согласен. Впрочем, никто нигде не определил, что такое классика.
RUP, как известно, - это не процесс, а framework, который спокойно настраивается на итерационный процесс, а значит он адаптируется как под водопад, так и под agile.
2008/10/26 Alexander Rivkind <alik...@gmail.com>
--
Best Regards, Alik.
Evgeny Kompaniyets
Oct 26, 2008, 4:19:14 AM10/26/08
to Agile Software Development Group, Ukraine
Пишу редко (это так я оправдываю свои тормоза), дискуссия убегает
вперед, а я еще не успел договорить о предыдущем :)
Возвращаясь к "толковому" аналитику:
Вопрос о роли Сергея в моей истории я задал специально, чтобы
проилюстрировать свое отношение к подобным вопросам.
Изучая иностранный язык многие изучают его граматику - части речи,
разные правила и т.п. Цели изучающего язык могут быть разные. Кто-то
изучает язык, чтобы иметь возможность на нем общаться, читать
литературу и т.п. Кого-то также интересует язык как наука. Т.е. всякие
детали и аспекты частей речи для него важны сами по себе. Цели в
данном вопросе влияют и на метод обучения. Например тот, кого язык как
наука не интересует, может попытаться "погрузиться" в языковую среду и
достичь цели не изучая граматики вообще, либо сведя ее изучение к
минимуму.
Крайне важно, по-моему, эту цель не забывать.
Моя цель в изучении гибких методик - эфективно делать софт. Любые
детали я изучаю исключительно с этой целью.
Как называть Сергея в этом моменте, по-моему не важно. Он делает
полезную работу. И делает ее очень просто.
Это дейсвительно не сложно, выяснить у заказчика реальные требования.
Для совмевающихся: попробуйте, держа в голове цель. Уверен что у вас
это получится не с первого, так со второго раза. Когда получится
можете городо добавить себе в резюме "аналитические способности" или
другой вариант названия, который вам нравится :)
Я рассказал эту историю, чтобы поделиться поезной практикой. Польза от
ее применения часто значительно больше чем от огромного кол-ва других
мне известных практик. Затронута она в этой ветке потому, что связана
с заказчиком или PO.
Обратите внимание, что применять эту практику вы можете "занимая"
любую роль на вашем проекте. Единственное условие - вы должны иметь
возможность общаться с заказчиком, а это, надеюсь, у вас уже есть.
On Oct 23, 9:32 pm, "Sergiy Movchan" <sergiy.movc...@gmail.com> wrote:
> нет. разве что можно добавить "толковый" впереди "анатилитк"а :)
>
> 2008/10/23 Evgeny Kompaniyets <evge...@gmail.com>
вперед, а я еще не успел договорить о предыдущем :)
Возвращаясь к "толковому" аналитику:
Вопрос о роли Сергея в моей истории я задал специально, чтобы
проилюстрировать свое отношение к подобным вопросам.
Изучая иностранный язык многие изучают его граматику - части речи,
разные правила и т.п. Цели изучающего язык могут быть разные. Кто-то
изучает язык, чтобы иметь возможность на нем общаться, читать
литературу и т.п. Кого-то также интересует язык как наука. Т.е. всякие
детали и аспекты частей речи для него важны сами по себе. Цели в
данном вопросе влияют и на метод обучения. Например тот, кого язык как
наука не интересует, может попытаться "погрузиться" в языковую среду и
достичь цели не изучая граматики вообще, либо сведя ее изучение к
минимуму.
Крайне важно, по-моему, эту цель не забывать.
Моя цель в изучении гибких методик - эфективно делать софт. Любые
детали я изучаю исключительно с этой целью.
Как называть Сергея в этом моменте, по-моему не важно. Он делает
полезную работу. И делает ее очень просто.
Это дейсвительно не сложно, выяснить у заказчика реальные требования.
Для совмевающихся: попробуйте, держа в голове цель. Уверен что у вас
это получится не с первого, так со второго раза. Когда получится
можете городо добавить себе в резюме "аналитические способности" или
другой вариант названия, который вам нравится :)
Я рассказал эту историю, чтобы поделиться поезной практикой. Польза от
ее применения часто значительно больше чем от огромного кол-ва других
мне известных практик. Затронута она в этой ветке потому, что связана
с заказчиком или PO.
Обратите внимание, что применять эту практику вы можете "занимая"
любую роль на вашем проекте. Единственное условие - вы должны иметь
возможность общаться с заказчиком, а это, надеюсь, у вас уже есть.
On Oct 23, 9:32 pm, "Sergiy Movchan" <sergiy.movc...@gmail.com> wrote:
> нет. разве что можно добавить "толковый" впереди "анатилитк"а :)
>
Alexey Krivitsky
Oct 27, 2008, 4:31:29 PM10/27/08
to agile-...@googlegroups.com
Женя,
Спасибо за case studies. Очень цикавые случаи.
Но я тоже считаю, что твой Сергей сыграл роль аналитика. Конечно же классно, когда PO такой толковый и умеет минимизировать количество фич и сложности системы, повышая её полезность. Это просто чудесно! :)
Но заметь, в твоих случаях не Сергей принимал финальное решение о том, как имплементить фичу, это делали финансистки. То есть они брали на себя ответственность за растрачу "программистских ресурсов" и получение выгоды. То есть как по мне они были ближе к PO, чем Сергей.
Спасибо за case studies. Очень цикавые случаи.
Но я тоже считаю, что твой Сергей сыграл роль аналитика. Конечно же классно, когда PO такой толковый и умеет минимизировать количество фич и сложности системы, повышая её полезность. Это просто чудесно! :)
Но заметь, в твоих случаях не Сергей принимал финальное решение о том, как имплементить фичу, это делали финансистки. То есть они брали на себя ответственность за растрачу "программистских ресурсов" и получение выгоды. То есть как по мне они были ближе к PO, чем Сергей.
2008/10/26 Evgeny Kompaniyets <evg...@gmail.com>
Alexey Krivitsky
Oct 27, 2008, 5:10:12 PM10/27/08
to agile-...@googlegroups.com
спасибо всем за отличную и конструктивную дискуссию. перечитал, понравилось. флейма почти не было. иногда правда складывалось впечатление, что отвечающие не перечитывают название темы. от чего начинаются лирические отступления. но всё же, тред отличный!
я написал небольшой саммери, скорее сбор цитат, которые при перечитывании, как мне показалось, отвечают на вопрос темы.
вот собственно пост
буду рад, если в будущем желающие будут писать небольшие резюме. как вариант это может сделать тот, кто начал тему (открыл вопрос). права постинга на сайт agileukraine раздаются легко. только попросите. у некоторых они уже давно есть, кстати :)
кстати, статейка по теме
http://www.scrumalliance.org/articles/44-being-an-effective-product-owner
я написал небольшой саммери, скорее сбор цитат, которые при перечитывании, как мне показалось, отвечают на вопрос темы.
вот собственно пост
буду рад, если в будущем желающие будут писать небольшие резюме. как вариант это может сделать тот, кто начал тему (открыл вопрос). права постинга на сайт agileukraine раздаются легко. только попросите. у некоторых они уже давно есть, кстати :)
кстати, статейка по теме
http://www.scrumalliance.org/articles/44-being-an-effective-product-owner
2008/10/21 Alexey Krivitsky <alexeyk...@gmail.com>
почему бы это не обсудить в новом топике?
какие требования-критерии вы выставляете к PO?
что он должен уметь делать? что может не уметь делать?
какой бекграунд у него должен быть? не должен быть?
Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы определить какой должен быть ПО. Пока лично мне удаётся только определить каким он не должен быть:
Но я уверен, что рано или поздно появится инструкция как найти правильного ПО. Как знать может и сам придумаю ...
2 Sergiy Movchan: поделись best practices если они у Тебя есть :)
в настоящем мире, на сколько я вижу, многие PO на самом деле являются проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.
2008/10/21 Sergiy Movchan <sergiy....@gmail.com>
вот если будет PO Proxy best practices, то я очень хочу. Сам по себе PO не интересен.
On Tue, Oct 21, 2008 at 12:29 PM, Dmitry Danilchenko <dm1...@yahoo.com> wrote:
мне Product Owner интересно.
From: Tim Yevgrashyn <yevgr...@gmail.com>
To: agile-...@googlegroups.com
Sent: Tuesday, October 21, 2008 12:13:19 PM
Subject: [agile-ukraine] Re: Тренинги от Хенрика Книберга
Certified Product Owner :-D
Такого еще никто не читал в Украине
привет,
хенрик готов приехать в районе 16-17 декабря в украину.
есть желающие посетить csm класс?
хенрик готов читать любой другой материал, не обязательно certified scrummaster.
стоимость его гонорара при этом остаётся фиксированной.
мой расчёт даёт стоимость дня тренинга при 20 человек в классе порядка 370-400 долларов с участника.
какие тренинги вам было бы интересно посетить?
--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
--
Tim Yevgrashyn,
Phone: +380 67 408 53 30
Skype: spidertim
LinkedIn: http://www.linkedin.com/in/yevgrashyn
...dali bude...
--
--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
Borys L.
--
--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
Evgeny Kompaniets
Oct 27, 2008, 5:26:22 PM10/27/08
to agile-...@googlegroups.com
Так я и не против названия. Аналитик так аналитик! :)
По-моему главное не помещать себя в ограничение ролями и техниками,
а понимать суть и опираясь на понимание эфективно делать софт.
В данном случае, например человек в роли скрам мастера или
разработчика, может по-моему ошибочно не делать работы аналитика
(вполне доступной ему), считая, что это не его дело.
Во взрослой команде, по-моему только ПО явно выделяется, а остальная
команда может выполнять любую работу. Выбор ролей определяется
навыками, ситуацией, пожеланиями и т.п. Роли у людей могут меняться и
комбинироваться. На мой взгляд, когда есть понимание сути процесса и
ответственность (а это и есть необходимое условие взрослой команды),
нет нужны думать на уровне ролей - просто все делают все для того,
чтобы эфективно делать софт.
По-моему главное не помещать себя в ограничение ролями и техниками,
а понимать суть и опираясь на понимание эфективно делать софт.
В данном случае, например человек в роли скрам мастера или
разработчика, может по-моему ошибочно не делать работы аналитика
(вполне доступной ему), считая, что это не его дело.
Во взрослой команде, по-моему только ПО явно выделяется, а остальная
команда может выполнять любую работу. Выбор ролей определяется
навыками, ситуацией, пожеланиями и т.п. Роли у людей могут меняться и
комбинироваться. На мой взгляд, когда есть понимание сути процесса и
ответственность (а это и есть необходимое условие взрослой команды),
нет нужны думать на уровне ролей - просто все делают все для того,
чтобы эфективно делать софт.
2008/10/27 Alexey Krivitsky <alexeyk...@gmail.com>:
--
Evgeny Kompaniets
Reply all
Reply to author
Forward
0 new messages