какие требования-критерии вы выставляете к PO? что он должен уметь делать? что может не уметь делать? какой бекграунд у него должен быть? не должен быть?
> Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы > определить какой должен быть ПО. Пока лично мне удаётся только определить > каким он не должен быть:
>>>>> хенрик готов приехать в районе 16-17 декабря в украину. >>>>> есть желающие посетить csm класс?
>>>>> хенрик готов читать любой другой материал, не обязательно certified >>>>> scrummaster. >>>>> стоимость его гонорара при этом остаётся фиксированной. >>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе порядка >>>>> 370-400 долларов с участника.
>>>>> какие тренинги вам было бы интересно посетить?
> какие требования-критерии вы выставляете к PO? > что он должен уметь делать? что может не уметь делать? > какой бекграунд у него должен быть? не должен быть?
>> Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы >> определить какой должен быть ПО. Пока лично мне удаётся только определить >> каким он не должен быть:
>>>>>> хенрик готов приехать в районе 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
Впрочем, помечтать можно: - знать, что конечные пользователи хотят от системы - уметь донести понимание системы до команды - понимать приоритеты этих вещей - не путать требования и реализацию - быть доступным для команды и достаточно мотивированным, что бы давать квалифицированные ответы - не делегировать полномочия людям, которые не удовлетворяют перечисленным выше пяти качествам или не расходятся во мнении с ним - уметь всё это проверить
Если честно, я не видел ни одного человека который может выполнить хотя бы два пункта из того, что я перечислил ...
У меня основная проблема состоит в том, что контакт-персон с той стороны как бы это сказать... not-committed. Не то чтобы ему было начхать на успех проекта или он саботирует процесс, но ситуация в целом напоминает анекдот, где муж жене говорит "ну ты же у меня умная - придумай что-нибудь сама".
вот и приходится постоянно расписывать варианты бизнес-нидсов, чтобы он мог ткнуть пальцем "вот это". Потому что дождаться внятного описания истории от него сложно. Приоритезация тоже хромает, т.к. в силу этой специфики много приоритезирую я сам. В среднем получается неплохо, но иногда влетаем :) но не сильно. Уже подумываю о том, чтобы показать разок, что "не такая я уж и умная" - то есть сделать что-то специально тупо совсем не в том порядке, чтоб он понял, что надо следить и самому расставлять приоритеты. А с другой стороны сцыкотно :) да и реноме... Короче вот так и живём.
И есть у меня подозрение, что это не очень нетипичная ситуёвина. Вот я и подумал - может есть какие-то практики, которые могут мне жисть облегчить?
везде где я писал "он" можно читать "представители заказчика в среднем". То есть есть такие, к которым претензий нет, но про них и разговор не идёт :)
> Впрочем, помечтать можно: > - знать, что конечные пользователи хотят от системы > - уметь донести понимание системы до команды > - понимать приоритеты этих вещей > - не путать требования и реализацию > - быть доступным для команды и достаточно мотивированным, что бы давать > квалифицированные ответы > - не делегировать полномочия людям, которые не удовлетворяют перечисленным > выше пяти качествам или не расходятся во мнении с ним > - уметь всё это проверить
> Если честно, я не видел ни одного человека который может выполнить хотя бы > два пункта из того, что я перечислил ...
> У меня основная проблема состоит в том, что контакт-персон с той стороны > как бы это сказать... not-committed. Не то чтобы ему было начхать на успех > проекта или он саботирует процесс, но ситуация в целом напоминает анекдот, > где муж жене говорит "ну ты же у меня умная - придумай что-нибудь сама".
я называю это недостаточной мотивацией, можно было бы это назвать ленью, но чаще всего это не лень ...
> вот и приходится постоянно расписывать варианты бизнес-нидсов, чтобы он мог > ткнуть пальцем "вот это". Потому что дождаться внятного описания истории от > него сложно. Приоритезация тоже хромает, т.к. в силу этой специфики много > приоритезирую я сам. В среднем получается неплохо, но иногда влетаем :) но > не сильно. Уже подумываю о том, чтобы показать разок, что "не такая я уж и > умная" - то есть сделать что-то специально тупо совсем не в том порядке, > чтоб он понял, что надо следить и самому расставлять приоритеты. А с другой > стороны сцыкотно :) да и реноме... Короче вот так и живём.
> И есть у меня подозрение, что это не очень нетипичная ситуёвина. Вот я и > подумал - может есть какие-то практики, которые могут мне жисть облегчить?
Если Ты тот самый Sergiy Movchan, который в предыдущем треде грозился продемонстрировать некоторые best practices то милости прошу: Твой ход ...
> везде где я писал "он" можно читать "представители заказчика в среднем". То > есть есть такие, к которым претензий нет, но про них и разговор не идёт :)
>>> какие требования-критерии вы выставляете к PO?
>> Обычно он выставляет к нам требования ...
>> Впрочем, помечтать можно: >> - знать, что конечные пользователи хотят от системы >> - уметь донести понимание системы до команды >> - понимать приоритеты этих вещей >> - не путать требования и реализацию >> - быть доступным для команды и достаточно мотивированным, что бы давать >> квалифицированные ответы >> - не делегировать полномочия людям, которые не удовлетворяют перечисленным >> выше пяти качествам или не расходятся во мнении с ним >> - уметь всё это проверить
>> Если честно, я не видел ни одного человека который может выполнить хотя бы >> два пункта из того, что я перечислил ...
Согласен - PO выбирают вместе с родиной :)
Т.е. можем поменять работу по этому критерию.
Для меня и некоторых моих знакомых PO - один из главных критериев при
выборе работы.
Из-за этого мы обычно не работаем в больших фирмах, иногда сами
становимся PO и т.п :)
On Oct 21, 3:40 pm, sun <aleksey.solnt...@gmail.com> wrote:
> > какие требования-критерии вы выставляете к PO?
> > что он должен уметь делать? что может не уметь делать?
> > какой бекграунд у него должен быть? не должен быть?
> >> Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы
> >> определить какой должен быть ПО. Пока лично мне удаётся только определить
> >> каким он не должен быть:
> >>>>>> хенрик готов приехать в районе 16-17 декабря в украину.
> >>>>>> есть желающие посетить csm класс?
> >>>>>> хенрик готов читать любой другой материал, не обязательно certified
> >>>>>> scrummaster.
> >>>>>> стоимость его гонорара при этом остаётся фиксированной.
> >>>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе порядка
> >>>>>> 370-400 долларов с участника.
> >>>>>> какие тренинги вам было бы интересно посетить?
> Согласен - PO выбирают вместе с родиной :) > Т.е. можем поменять работу по этому критерию. > Для меня и некоторых моих знакомых PO - один из главных критериев при > выборе работы. > Из-за этого мы обычно не работаем в больших фирмах, иногда сами > становимся PO и т.п :)
> On Oct 21, 3:40 pm, sun <aleksey.solnt...@gmail.com> wrote: > > PO как и родину не выбирают )
> > > какие требования-критерии вы выставляете к PO? > > > что он должен уметь делать? что может не уметь делать? > > > какой бекграунд у него должен быть? не должен быть?
> > >> Это отдельная тема для разговора. Я прилагаю много усилий для того, > что бы > > >> определить какой должен быть ПО. Пока лично мне удаётся только > определить > > >> каким он не должен быть:
> > >>> в настоящем мире, на сколько я вижу, многие PO на самом деле являются > > >>> проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.
> > >>>>>> хенрик готов приехать в районе 16-17 декабря в украину. > > >>>>>> есть желающие посетить csm класс?
> > >>>>>> хенрик готов читать любой другой материал, не обязательно > certified > > >>>>>> scrummaster. > > >>>>>> стоимость его гонорара при этом остаётся фиксированной. > > >>>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе > порядка > > >>>>>> 370-400 долларов с участника.
> > >>>>>> какие тренинги вам было бы интересно посетить?
Сразу оговорюсь, что говоря здесь о PO я понимаю заказчика в терминах XP. Мое понимание скрама ограничивается паралелями с XP и возможно может привести к ошибке, которую если такая возникнет, я надеюсь кто-нибудь исправит. Подумав, я понял, что похоже никогда не был, так сказать 100% PO. Я несколько раз был прокси и последнее время пытаюсь одновременно находиться в командах PO и програмистов. В команде PO в моем текущем проекте есть один человек, который принимает финальные решения (обычно это нужно только в случае конфликтов). С субподрядчиками никогда не делал ничего серьезнее веб дизайна и верстки.
На вопрос как хорош я как PO я лучше расскажу о тех 100% PO с которыми работал последнее время. По-моему с точки зрения процесса, там все довольно хорошо. Основные сложности за рамками процесса. Например: - придумать удобный интерфейс - угадать проблемы пользователя нового продукта еще до того, как этот пользователь появился - придумать изменения бизнесс процесса который приведет к более эфективной работе компании. Этот бизнес процесс как раз и автоматизируется разрабатываемым софтом и глазами разработчика - это придумывание новой фичи к софту.
Рассказывать что надо делать, расставлять приоритеты и не заниматься не своей работой, как показывает опыт, довольно легко научиться.
Мне кажется главные сложности для украинских реалий - это аусорсинг который идет с двумя проблемами: обычно плохой с точки зрения agile заказчик (PO) и распределенность участников проекта. Почему это так - большой отдельный разговор :) Я предпочитаю избегать таких проектов, из-за чего мой опыт борьбы с этими проблемами незначительный. Зачем заниматься процессом, если можно писать программу? :) Не кидайте в меня камнями - знаю, что здесь много тех, кто не смотря на эти проблемы многое делает.
>> Согласен - PO выбирают вместе с родиной :) >> Т.е. можем поменять работу по этому критерию. >> Для меня и некоторых моих знакомых PO - один из главных критериев при >> выборе работы. >> Из-за этого мы обычно не работаем в больших фирмах, иногда сами >> становимся PO и т.п :)
>> On Oct 21, 3:40 pm, sun <aleksey.solnt...@gmail.com> wrote: >> > PO как и родину не выбирают )
>> > > какие требования-критерии вы выставляете к PO? >> > > что он должен уметь делать? что может не уметь делать? >> > > какой бекграунд у него должен быть? не должен быть?
>> > >> Это отдельная тема для разговора. Я прилагаю много усилий для того, >> > >> что бы >> > >> определить какой должен быть ПО. Пока лично мне удаётся только >> > >> определить >> > >> каким он не должен быть:
>> > >>> в настоящем мире, на сколько я вижу, многие PO на самом деле >> > >>> являются >> > >>> проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.
>> > >>>>>> хенрик готов приехать в районе 16-17 декабря в украину. >> > >>>>>> есть желающие посетить csm класс?
>> > >>>>>> хенрик готов читать любой другой материал, не обязательно >> > >>>>>> certified >> > >>>>>> scrummaster. >> > >>>>>> стоимость его гонорара при этом остаётся фиксированной. >> > >>>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе >> > >>>>>> порядка >> > >>>>>> 370-400 долларов с участника.
>> > >>>>>> какие тренинги вам было бы интересно посетить?
Мне кажется, что требования к 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:
> > какие требования-критерии вы выставляете к PO?
> Обычно он выставляет к нам требования ...
> Впрочем, помечтать можно:
> - знать, что конечные пользователи хотят от системы
> - уметь донести понимание системы до команды
> - понимать приоритеты этих вещей
> - не путать требования и реализацию
> - быть доступным для команды и достаточно мотивированным, что бы давать
> квалифицированные ответы
> - не делегировать полномочия людям, которые не удовлетворяют перечисленным
> выше пяти качествам или не расходятся во мнении с ним
> - уметь всё это проверить
> Если честно, я не видел ни одного человека который может выполнить хотя бы
> два пункта из того, что я перечислил ...
У нас был человек на голландской стороне, который был совершенно
невыносим в качестве Продакт менеджера. Он предлагал технические
решения, постоянно менял планы, задавал идиотские вопросы, не отвечал
на письма, лез не в своё дело и т.п.
Сейчас он - лучший Продакт оунер из всех, кто работает с украинскими
командами. Смотря на него, я вижу вот такие критерии "хорошести":
а) РО должен отвечать хоть чем-то за результат проекта. Коммитмент
приложится.
б) РО обязательно кто-то должен обучить и поддерживать. В нашем случае
Маурисом занялись лично Chief Technological и Chief Informational
компании. После двух месяцев муштры глупые вопросы сошли на нет.
в) РО должен хорошо относиться к команде разработке и обязательно быть
лично с ними знакомым. После визита "ужасного Мауриса" в Украину,
когда он лично познакомился с командой (и понял какие же мы
классные )). Ну и народу здесь тоже стало понятно, что он - вполне
вменяемый чувак. После этого общение поменялось кардинально в лучшую
сторону.
в) РО должен быть толковым. Остальное наберётся автоматом.
Результат: за 3 месяца человек полностью поменял стиль работы и стал
чуть ли не лучшим Продакт оунером компании.
З.Ы. Уж не те ли это бест прэктисес, которых просил Сергей? ;))
On Oct 21, 3:38 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> какие требования-критерии вы выставляете к PO?
> что он должен уметь делать? что может не уметь делать?
> какой бекграунд у него должен быть? не должен быть?
> > Это отдельная тема для разговора. Я прилагаю много усилий для того, что бы
> > определить какой должен быть ПО. Пока лично мне удаётся только определить
> > каким он не должен быть:
> >>>>> хенрик готов приехать в районе 16-17 декабря в украину.
> >>>>> есть желающие посетить csm класс?
> >>>>> хенрик готов читать любой другой материал, не обязательно certified
> >>>>> scrummaster.
> >>>>> стоимость его гонорара при этом остаётся фиксированной.
> >>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе порядка
> >>>>> 370-400 долларов с участника.
> >>>>> какие тренинги вам было бы интересно посетить?
А кто что думает о таком: 1. Отличаются ли "хороший product owner" и "хороший product manager"? 2. Одинаковые ли критерии для Product Owner проекта и продукта?
> У нас был человек на голландской стороне, который был совершенно > невыносим в качестве Продакт менеджера. Он предлагал технические > решения, постоянно менял планы, задавал идиотские вопросы, не отвечал > на письма, лез не в своё дело и т.п.
> Сейчас он - лучший Продакт оунер из всех, кто работает с украинскими > командами. Смотря на него, я вижу вот такие критерии "хорошести": > а) РО должен отвечать хоть чем-то за результат проекта. Коммитмент > приложится.
> б) РО обязательно кто-то должен обучить и поддерживать. В нашем случае > Маурисом занялись лично Chief Technological и Chief Informational > компании. После двух месяцев муштры глупые вопросы сошли на нет.
> в) РО должен хорошо относиться к команде разработке и обязательно быть > лично с ними знакомым. После визита "ужасного Мауриса" в Украину, > когда он лично познакомился с командой (и понял какие же мы > классные )). Ну и народу здесь тоже стало понятно, что он - вполне > вменяемый чувак. После этого общение поменялось кардинально в лучшую > сторону.
> в) РО должен быть толковым. Остальное наберётся автоматом.
> Результат: за 3 месяца человек полностью поменял стиль работы и стал > чуть ли не лучшим Продакт оунером компании.
> З.Ы. Уж не те ли это бест прэктисес, которых просил Сергей? ;))
> On Oct 21, 3:38 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > wrote: > > почему бы это не обсудить в новом топике?
> > какие требования-критерии вы выставляете к PO? > > что он должен уметь делать? что может не уметь делать? > > какой бекграунд у него должен быть? не должен быть?
> > > Это отдельная тема для разговора. Я прилагаю много усилий для того, что > бы > > > определить какой должен быть ПО. Пока лично мне удаётся только > определить > > > каким он не должен быть:
> > >>>>> хенрик готов приехать в районе 16-17 декабря в украину. > > >>>>> есть желающие посетить csm класс?
> > >>>>> хенрик готов читать любой другой материал, не обязательно certified > > >>>>> scrummaster. > > >>>>> стоимость его гонорара при этом остаётся фиксированной. > > >>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе > порядка > > >>>>> 370-400 долларов с участника.
> > >>>>> какие тренинги вам было бы интересно посетить?
Сегодня Сергей Руженков напомнил мне об очень важном моменте в работе
PO.
В свободное время Серега поддерживает несколько проектов с его
предыдущей работы.
Сегодня его заказчикам позарез понадобилась новая фича и они пришли к
нам в комнату слезно просить его пообщаться с ними на эту тему.
Заказчики - две женщины из финансового отдела (финансовый софт).
Серега пообщался с ними полчаса и вернувшись отметил, что как это
часто бывает, они вместе придумали фичу, которую он может реализовать
за 15 мин.
Что там произошло на самом деле: заказчик пришел с бизнес проблемой и
предполагаемым решением. Под решением я имею ввиду не то как это будет
програмироваться (благо его финансисты не умеют програмировать), а
набор фич, которые надо добавить в софт, чтобы решать их бизнес
проблему.
Их решение на первый взгляд было довольно неплохим. Необходимо
добавить довольно значительную функциональность в программу, которая
будет решать возникшую бизнес задачу. Решение довольно удобно - в
интерфейсе появляются соответствующие изменения, позволяющие
пользователям решать новые задачи.
Что делает Серега? Он начинает задавать правильные вопросы. Делает он
это замечательно - я знаю очень мало людей, которые умеют так
эфективно общаться в таких ситуациях с людьми, которые не являются
програмистами :) Получая на них ответы он докапывается до сути их
реальной проблемы, не обращая внимание на то, что они предлагают
добавить в софт. В результате они находят простейшее решение,
сводящееся к изменению нескольких xml файликов. Интерфейс похоже
несколько хуже того, что они предлагали изначально, но совершенно
несравним по цене.
Эта история демонстрирует важнейшую ценность PO: уметь отказываться от
ненужных фич.
Звучит это просто, но на практике часто получается плохо.
Напоследок предлагаю развлечься следующим упражнением (как раз
связанным с вопросом отличий ПО, от ПМ и т.п):
Дайте ответ на вопрос: какую роль в этой истории играл Серега? Продакт
Онера? Скрам Мастера? Програмиста? Менеджера проэкта? Ваш вариант?
> Сегодня Сергей Руженков напомнил мне об очень важном моменте в работе > PO. > В свободное время Серега поддерживает несколько проектов с его > предыдущей работы. > Сегодня его заказчикам позарез понадобилась новая фича и они пришли к > нам в комнату слезно просить его пообщаться с ними на эту тему. > Заказчики - две женщины из финансового отдела (финансовый софт).
> Серега пообщался с ними полчаса и вернувшись отметил, что как это > часто бывает, они вместе придумали фичу, которую он может реализовать > за 15 мин. > Что там произошло на самом деле: заказчик пришел с бизнес проблемой и > предполагаемым решением. Под решением я имею ввиду не то как это будет > програмироваться (благо его финансисты не умеют програмировать), а > набор фич, которые надо добавить в софт, чтобы решать их бизнес > проблему. > Их решение на первый взгляд было довольно неплохим. Необходимо > добавить довольно значительную функциональность в программу, которая > будет решать возникшую бизнес задачу. Решение довольно удобно - в > интерфейсе появляются соответствующие изменения, позволяющие > пользователям решать новые задачи. > Что делает Серега? Он начинает задавать правильные вопросы. Делает он > это замечательно - я знаю очень мало людей, которые умеют так > эфективно общаться в таких ситуациях с людьми, которые не являются > програмистами :) Получая на них ответы он докапывается до сути их > реальной проблемы, не обращая внимание на то, что они предлагают > добавить в софт. В результате они находят простейшее решение, > сводящееся к изменению нескольких xml файликов. Интерфейс похоже > несколько хуже того, что они предлагали изначально, но совершенно > несравним по цене. > Эта история демонстрирует важнейшую ценность PO: уметь отказываться от > ненужных фич. > Звучит это просто, но на практике часто получается плохо.
> Напоследок предлагаю развлечься следующим упражнением (как раз > связанным с вопросом отличий ПО, от ПМ и т.п): > Дайте ответ на вопрос: какую роль в этой истории играл Серега? Продакт > Онера? Скрам Мастера? Програмиста? Менеджера проэкта? Ваш вариант?
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 проекта и продукта?
> > У нас был человек на голландской стороне, который был совершенно
> > невыносим в качестве Продакт менеджера. Он предлагал технические
> > решения, постоянно менял планы, задавал идиотские вопросы, не отвечал
> > на письма, лез не в своё дело и т.п.
> > Сейчас он - лучший Продакт оунер из всех, кто работает с украинскими
> > командами. Смотря на него, я вижу вот такие критерии "хорошести":
> > а) РО должен отвечать хоть чем-то за результат проекта. Коммитмент
> > приложится.
> > б) РО обязательно кто-то должен обучить и поддерживать. В нашем случае
> > Маурисом занялись лично Chief Technological и Chief Informational
> > компании. После двух месяцев муштры глупые вопросы сошли на нет.
> > в) РО должен хорошо относиться к команде разработке и обязательно быть
> > лично с ними знакомым. После визита "ужасного Мауриса" в Украину,
> > когда он лично познакомился с командой (и понял какие же мы
> > классные )). Ну и народу здесь тоже стало понятно, что он - вполне
> > вменяемый чувак. После этого общение поменялось кардинально в лучшую
> > сторону.
> > в) РО должен быть толковым. Остальное наберётся автоматом.
> > Результат: за 3 месяца человек полностью поменял стиль работы и стал
> > чуть ли не лучшим Продакт оунером компании.
> > З.Ы. Уж не те ли это бест прэктисес, которых просил Сергей? ;))
> > On Oct 21, 3:38 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
> > wrote:
> > > почему бы это не обсудить в новом топике?
> > > какие требования-критерии вы выставляете к PO?
> > > что он должен уметь делать? что может не уметь делать?
> > > какой бекграунд у него должен быть? не должен быть?
> > > > Это отдельная тема для разговора. Я прилагаю много усилий для того, что
> > бы
> > > > определить какой должен быть ПО. Пока лично мне удаётся только
> > определить
> > > > каким он не должен быть:
> > > >> в настоящем мире, на сколько я вижу, многие PO на самом деле являются
> > > >> проксями к аккаунт менеджерам, продакт менеджерам и прочим людям.
> > > >>>>> хенрик готов приехать в районе 16-17 декабря в украину.
> > > >>>>> есть желающие посетить csm класс?
> > > >>>>> хенрик готов читать любой другой материал, не обязательно certified
> > > >>>>> scrummaster.
> > > >>>>> стоимость его гонорара при этом остаётся фиксированной.
> > > >>>>> мой расчёт даёт стоимость дня тренинга при 20 человек в классе
> > порядка
> > > >>>>> 370-400 долларов с участника.
> > > >>>>> какие тренинги вам было бы интересно посетить?
> Сегодня Сергей Руженков напомнил мне об очень важном моменте в работе > PO. > В свободное время Серега поддерживает несколько проектов с его > предыдущей работы. > Сегодня его заказчикам позарез понадобилась новая фича и они пришли к > нам в комнату слезно просить его пообщаться с ними на эту тему. > Заказчики - две женщины из финансового отдела (финансовый софт).
> Серега пообщался с ними полчаса и вернувшись отметил, что как это > часто бывает, они вместе придумали фичу, которую он может реализовать > за 15 мин. > Что там произошло на самом деле: заказчик пришел с бизнес проблемой и > предполагаемым решением. Под решением я имею ввиду не то как это будет > програмироваться (благо его финансисты не умеют програмировать), а > набор фич, которые надо добавить в софт, чтобы решать их бизнес > проблему. > Их решение на первый взгляд было довольно неплохим. Необходимо > добавить довольно значительную функциональность в программу, которая > будет решать возникшую бизнес задачу. Решение довольно удобно - в > интерфейсе появляются соответствующие изменения, позволяющие > пользователям решать новые задачи. > Что делает Серега? Он начинает задавать правильные вопросы. Делает он > это замечательно - я знаю очень мало людей, которые умеют так > эфективно общаться в таких ситуациях с людьми, которые не являются > програмистами :) Получая на них ответы он докапывается до сути их > реальной проблемы, не обращая внимание на то, что они предлагают > добавить в софт. В результате они находят простейшее решение, > сводящееся к изменению нескольких xml файликов. Интерфейс похоже > несколько хуже того, что они предлагали изначально, но совершенно > несравним по цене. > Эта история демонстрирует важнейшую ценность PO: уметь отказываться от > ненужных фич. > Звучит это просто, но на практике часто получается плохо.
> Напоследок предлагаю развлечься следующим упражнением (как раз > связанным с вопросом отличий ПО, от ПМ и т.п): > Дайте ответ на вопрос: какую роль в этой истории играл Серега? Продакт > Онера? Скрам Мастера? Програмиста? Менеджера проэкта? Ваш вариант?
Я тоже назвал бы такую работу аналитической. Может быть из-за образования полученного в Институте Прикладного Системного Анализа. А может просто профессиональный стереотип. 4 года назад я работал аналитиком на стороне заказчика. Это было славное время сидишь полдня в чужой конторе, любезничаешь с бухгалтерами и их грозными начальниками (совсем не Agile-среда) и формулируешь требования, потом доступно объясняешь как работает система и почему её нельзя было сделать как они просили; Тогда я не знал Agile, о водопаде знал из курса по современным технологиям программирования, а программировать вообще не умел. Да, я был аналитиком на 100% (и программистом на 0%).
Спустя 4 года я не могу сказать что я был хоть чуть-чуть ПО.
Между аналитиком и менеджером есть существенная разница: менеджер наделён административными полномочиями: он расставляет приоритеты. И ПО должен быть наделён т.е. он должен быть менеджером. Это не значит, что ему можно пренебречь аналитическими навыками - как раз исходя из того, что я написал ранее, нельзя. Более того, он чаще всего не может эффективно делегировать принятие решений другим аналитикам: "мыши должны стать ёжиками, а вы додумайте как ..."
Кстати, большинство известных мне ПО с лёгкостью отказываются от фич, когда им предоставляют смету затрат. Чаще всего разработчики не могут отказаться от программирования не нужных фич ...
> Сегодня Сергей Руженков напомнил мне об очень важном моменте в работе > PO. > В свободное время Серега поддерживает несколько проектов с его > предыдущей работы. > Сегодня его заказчикам позарез понадобилась новая фича и они пришли к > нам в комнату слезно просить его пообщаться с ними на эту тему. > Заказчики - две женщины из финансового отдела (финансовый софт).
> Серега пообщался с ними полчаса и вернувшись отметил, что как это > часто бывает, они вместе придумали фичу, которую он может реализовать > за 15 мин. > Что там произошло на самом деле: заказчик пришел с бизнес проблемой и > предполагаемым решением. Под решением я имею ввиду не то как это будет > програмироваться (благо его финансисты не умеют програмировать), а > набор фич, которые надо добавить в софт, чтобы решать их бизнес > проблему. > Их решение на первый взгляд было довольно неплохим. Необходимо > добавить довольно значительную функциональность в программу, которая > будет решать возникшую бизнес задачу. Решение довольно удобно - в > интерфейсе появляются соответствующие изменения, позволяющие > пользователям решать новые задачи. > Что делает Серега? Он начинает задавать правильные вопросы. Делает он > это замечательно - я знаю очень мало людей, которые умеют так > эфективно общаться в таких ситуациях с людьми, которые не являются > програмистами :) Получая на них ответы он докапывается до сути их > реальной проблемы, не обращая внимание на то, что они предлагают > добавить в софт. В результате они находят простейшее решение, > сводящееся к изменению нескольких xml файликов. Интерфейс похоже > несколько хуже того, что они предлагали изначально, но совершенно > несравним по цене. > Эта история демонстрирует важнейшую ценность PO: уметь отказываться от > ненужных фич. > Звучит это просто, но на практике часто получается плохо.
> Напоследок предлагаю развлечься следующим упражнением (как раз > связанным с вопросом отличий ПО, от ПМ и т.п): > Дайте ответ на вопрос: какую роль в этой истории играл Серега? Продакт > Онера? Скрам Мастера? Програмиста? Менеджера проэкта? Ваш вариант?
> Сегодня Сергей Руженков напомнил мне об очень важном моменте в работе >> PO. >> В свободное время Серега поддерживает несколько проектов с его >> предыдущей работы. >> Сегодня его заказчикам позарез понадобилась новая фича и они пришли к >> нам в комнату слезно просить его пообщаться с ними на эту тему. >> Заказчики - две женщины из финансового отдела (финансовый софт).
>> Серега пообщался с ними полчаса и вернувшись отметил, что как это >> часто бывает, они вместе придумали фичу, которую он может реализовать >> за 15 мин. >> Что там произошло на самом деле: заказчик пришел с бизнес проблемой и >> предполагаемым решением. Под решением я имею ввиду не то как это будет >> програмироваться (благо его финансисты не умеют програмировать), а >> набор фич, которые надо добавить в софт, чтобы решать их бизнес >> проблему. >> Их решение на первый взгляд было довольно неплохим. Необходимо >> добавить довольно значительную функциональность в программу, которая >> будет решать возникшую бизнес задачу. Решение довольно удобно - в >> интерфейсе появляются соответствующие изменения, позволяющие >> пользователям решать новые задачи. >> Что делает Серега? Он начинает задавать правильные вопросы. Делает он >> это замечательно - я знаю очень мало людей, которые умеют так >> эфективно общаться в таких ситуациях с людьми, которые не являются >> програмистами :) Получая на них ответы он докапывается до сути их >> реальной проблемы, не обращая внимание на то, что они предлагают >> добавить в софт. В результате они находят простейшее решение, >> сводящееся к изменению нескольких xml файликов. Интерфейс похоже >> несколько хуже того, что они предлагали изначально, но совершенно >> несравним по цене. >> Эта история демонстрирует важнейшую ценность PO: уметь отказываться от >> ненужных фич. >> Звучит это просто, но на практике часто получается плохо.
>> Напоследок предлагаю развлечься следующим упражнением (как раз >> связанным с вопросом отличий ПО, от ПМ и т.п): >> Дайте ответ на вопрос: какую роль в этой истории играл Серега? Продакт >> Онера? Скрам Мастера? Програмиста? Менеджера проэкта? Ваш вариант?
Эх, читаю ответы, потом перечитывают свой пост и понимаю, что хотел
написать об одном, а получилось как всегда.
Попытаюсь исправить ошибку.
В моем описании работы Сергея получилось, что он практически придумал
другой интерфейс, который решает туже проблему что и вариант
заказчика, но просто проще в реализации.
На самом деле все обстоит иначе:
Заказчик приходит с набором фич, а после разговора с Сергеем просто
отказывается делать большую часть того, что он хотел.
Попробую описать на детальном примере. Пример я придумал. Возможно он
не самый удачный, но лучше пока не могу :)
Итак:
Пускай мы пишем приложение.
У нас уже реализована фича аутентификации по корпоративному LDAP
серверу. В настройках можно описать сервер, после чего работает single
sign-on.
Приходит заказчик и просит добавить поддержкy нескольких LDAP серверов
и несколько внешних систем аутентификации (типа пускаем в систему
gmail, yahoo и msn пользователей).
Все это можно задать в настройках и прозрачно пользоваться нашим
софтом смогут пользователи всех описанных систем.
Фича понятна, мы можем ее оценить. Заказчика устраивает наша оценка.
Можно работать.
Вот здесь и появляется Серега с вопросом: зачем эта фича нужна?
Обычно заказчик раскалывается не сразу. Сначала он рассказывает про то
как это круто и как удобно это будет. Он увлекся фичей также, как
програмист иногда увлекается новой технологией. Часто послушав
заказчика програмисты заряжаются его энергией и бросаются делать новую
прикольную фичу.
Но Серега на такие уловки не поддадется! :)
На самом деле заказчику нужно поддержать следующий сценарий: дать
возможность работать нескольким пользователям, которых нет в
корпоративном LDAP. Таких пользователей будет обычно совсем немного а
иногда не будет совсем. Эта фича довольно сильно отличается от того, с
чем пришел заказчик.
Реализовать поддержку gmail, yahoo и msn потребовало бы несравнимо
больше времени, чем то, к чему мы пришли.
Что в этой истории я хочу подчеркнуть:
1. Стандарный механизм дать заказчику оценку, после которой он
откажется делать фичу не работает. Этот метод скорее сработает в
ситуациях, когда оценка заказчика например страшно напугает и он
вспомнит сам с чего начал. Но часто это не так.
2. Есть очень большая вероятность, что "придуманая" подобным образом
фича потом переделывается или выбрасывается совсем. Именно потому, что
она реализовывает не то, что действительно нужно, а то что заказчку
понравилось. Такие примеры были на практике неоднократно. Теперь мы
стараемся такое не допускать.
С учетам второго пункта экономию от вмешательства Сергея на проекте
трудно переоценить :)
Думаю нет. До тех пор, пока есть заказчик, который приходит с просьбой "я хочу то-то и то-то", роль product manager играет именно заказчик. Безусловно, Сергей талантливый аналитик, удовлетворяющий заказчика минимальными усилиями. :) Но все же аналитик. Я так понимаю, во всяком случае.
> Эх, читаю ответы, потом перечитывают свой пост и понимаю, что хотел > написать об одном, а получилось как всегда. > Попытаюсь исправить ошибку. > В моем описании работы Сергея получилось, что он практически придумал > другой интерфейс, который решает туже проблему что и вариант > заказчика, но просто проще в реализации. > На самом деле все обстоит иначе: > Заказчик приходит с набором фич, а после разговора с Сергеем просто > отказывается делать большую часть того, что он хотел. > Попробую описать на детальном примере. Пример я придумал. Возможно он > не самый удачный, но лучше пока не могу :)
> Итак: > Пускай мы пишем приложение. > У нас уже реализована фича аутентификации по корпоративному 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. Есть очень большая вероятность, что "придуманая" подобным образом > фича потом переделывается или выбрасывается совсем. Именно потому, что > она реализовывает не то, что действительно нужно, а то что заказчку > понравилось. Такие примеры были на практике неоднократно. Теперь мы > стараемся такое не допускать.
> С учетам второго пункта экономию от вмешательства Сергея на проекте > трудно переоценить :)
Ещё интереснее бывает когда аналитик говорит бизнесмену как улучшить бизнес процессы. Это тоже нормально: когда я работал аналитиком, помогая автоматизировать бухгалтерский учёт, это было обычной практикой: дело в том, что хаос не поддаётся автоматизации. Если порядок очень сложный, то он также приравнивается к хаосу. Его нужно упростить. Большой бизнес должен быть простым. Не верите? Прочитайте историю FedEx ... ИМХО, отличие ПО от аналитика заключается в том, что последний не имеет админресурса.
> Эх, читаю ответы, потом перечитывают свой пост и понимаю, что хотел > написать об одном, а получилось как всегда. > Попытаюсь исправить ошибку. > В моем описании работы Сергея получилось, что он практически придумал > другой интерфейс, который решает туже проблему что и вариант > заказчика, но просто проще в реализации. > На самом деле все обстоит иначе: > Заказчик приходит с набором фич, а после разговора с Сергеем просто > отказывается делать большую часть того, что он хотел. > Попробую описать на детальном примере. Пример я придумал. Возможно он > не самый удачный, но лучше пока не могу :)
> Итак: > Пускай мы пишем приложение. > У нас уже реализована фича аутентификации по корпоративному LDAP > серверу. В настройках можно описать сервер, после чего работает single > sign-on. > Приходит заказчик и просит добавить поддержкy нескольких LDAP серверов > и несколько внешних систем аутентификации (типа пускаем в систему > gmail, yahoo и msn пользователей). > Все это можно задать в настройках и прозрачно пользоваться нашим > софтом смогут пользователи всех описанных систем. > Фича понятна, мы можем ее оценить. Заказчика устраивает наша оценка. > Можно работать. > Вот здесь и появляется Серега с вопросом: зачем эта фича нужна? > Обычно заказчик раскалывается не сразу. Сначала он рассказывает про то > как это круто и как удобно это будет. Он увлекся фичей также, как > програмист иногда увлекается новой технологией. Часто послушав > заказчика програмисты заряжаются его энергией и бросаются делать новую > прикольную фичу. > Но Серега на такие уловки не поддадется! :) > На самом деле заказчику нужно поддержать следующий сценарий: дать > возможность работать нескольким пользователям, которых нет в > корпоративном LDAP. Таких пользователей будет обычно совсем немного а > иногда не будет совсем. Эта фича довольно сильно отличается от того, с > чем пришел заказчик. > Реализовать поддержку gmail, yahoo и msn потребовало бы несравнимо > больше времени, чем то, к чему мы пришли.
> Что в этой истории я хочу подчеркнуть: > 1. Стандарный механизм дать заказчику оценку, после которой он > откажется делать фичу не работает. Этот метод скорее сработает в > ситуациях, когда оценка заказчика например страшно напугает и он > вспомнит сам с чего начал. Но часто это не так. > 2. Есть очень большая вероятность, что "придуманая" подобным образом > фича потом переделывается или выбрасывается совсем. Именно потому, что > она реализовывает не то, что действительно нужно, а то что заказчку > понравилось. Такие примеры были на практике неоднократно. Теперь мы > стараемся такое не допускать.
> С учетам второго пункта экономию от вмешательства Сергея на проекте > трудно переоценить :)
> Ещё интереснее бывает когда аналитик говорит бизнесмену как улучшить > бизнес процессы. Это тоже нормально: когда я работал аналитиком, помогая > автоматизировать бухгалтерский учёт, это было обычной практикой: дело в том, > что хаос не поддаётся автоматизации. > Если порядок очень сложный, то он также приравнивается к хаосу. Его > нужно упростить. Большой бизнес должен быть простым. Не верите? Прочитайте > историю FedEx ... > ИМХО, отличие ПО от аналитика заключается в том, что последний не > имеет админресурса.
> Эх, читаю ответы, потом перечитывают свой пост и понимаю, что хотел >> написать об одном, а получилось как всегда. >> Попытаюсь исправить ошибку. >> В моем описании работы Сергея получилось, что он практически придумал >> другой интерфейс, который решает туже проблему что и вариант >> заказчика, но просто проще в реализации. >> На самом деле все обстоит иначе: >> Заказчик приходит с набором фич, а после разговора с Сергеем просто >> отказывается делать большую часть того, что он хотел. >> Попробую описать на детальном примере. Пример я придумал. Возможно он >> не самый удачный, но лучше пока не могу :)
>> Итак: >> Пускай мы пишем приложение. >> У нас уже реализована фича аутентификации по корпоративному LDAP >> серверу. В настройках можно описать сервер, после чего работает single >> sign-on. >> Приходит заказчик и просит добавить поддержкy нескольких LDAP серверов >> и несколько внешних систем аутентификации (типа пускаем в систему >> gmail, yahoo и msn пользователей). >> Все это можно задать в настройках и прозрачно пользоваться нашим >> софтом смогут пользователи всех описанных систем. >> Фича понятна, мы можем ее оценить. Заказчика устраивает наша оценка. >> Можно работать. >> Вот здесь и появляется Серега с вопросом: зачем эта фича нужна? >> Обычно заказчик раскалывается не сразу. Сначала он рассказывает про то >> как это круто и как удобно это будет. Он увлекся фичей также, как >> програмист иногда увлекается новой технологией. Часто послушав >> заказчика програмисты заряжаются его энергией и бросаются делать новую >> прикольную фичу. >> Но Серега на такие уловки не поддадется! :) >> На самом деле заказчику нужно поддержать следующий сценарий: дать >> возможность работать нескольким пользователям, которых нет в >> корпоративном LDAP. Таких пользователей будет обычно совсем немного а >> иногда не будет совсем. Эта фича довольно сильно отличается от того, с >> чем пришел заказчик. >> Реализовать поддержку gmail, yahoo и msn потребовало бы несравнимо >> больше времени, чем то, к чему мы пришли.
>> Что в этой истории я хочу подчеркнуть: >> 1. Стандарный механизм дать заказчику оценку, после которой он >> откажется делать фичу не работает. Этот метод скорее сработает в >> ситуациях, когда оценка заказчика например страшно напугает и он >> вспомнит сам с чего начал. Но часто это не так. >> 2. Есть очень большая вероятность, что "придуманая" подобным образом >> фича потом переделывается или выбрасывается совсем. Именно потому, что >> она реализовывает не то, что действительно нужно, а то что заказчку >> понравилось. Такие примеры были на практике неоднократно. Теперь мы >> стараемся такое не допускать.
>> С учетам второго пункта экономию от вмешательства Сергея на проекте >> трудно переоценить :)
Я понимаю, можно сказать, что у каждого есть право принимать решения, но официальное право есть не у всех: генерал всегда остаётся генералом, даже если решения за него принимает жена или любовница :)
>> Ещё интереснее бывает когда аналитик говорит бизнесмену как улучшить >> бизнес процессы. Это тоже нормально: когда я работал аналитиком, помогая >> автоматизировать бухгалтерский учёт, это было обычной практикой: дело в том, >> что хаос не поддаётся автоматизации. >> Если порядок очень сложный, то он также приравнивается к хаосу. Его >> нужно упростить. Большой бизнес должен быть простым. Не верите? Прочитайте >> историю FedEx ... >> ИМХО, отличие ПО от аналитика заключается в том, что последний не >> имеет админресурса.
>> Эх, читаю ответы, потом перечитывают свой пост и понимаю, что хотел >>> написать об одном, а получилось как всегда. >>> Попытаюсь исправить ошибку. >>> В моем описании работы Сергея получилось, что он практически придумал >>> другой интерфейс, который решает туже проблему что и вариант >>> заказчика, но просто проще в реализации. >>> На самом деле все обстоит иначе: >>> Заказчик приходит с набором фич, а после разговора с Сергеем просто >>> отказывается делать большую часть того, что он хотел. >>> Попробую описать на детальном примере. Пример я придумал. Возможно он >>> не самый удачный, но лучше пока не могу :)
>>> Итак: >>> Пускай мы пишем приложение. >>> У нас уже реализована фича аутентификации по корпоративному LDAP >>> серверу. В настройках можно описать сервер, после чего работает single >>> sign-on. >>> Приходит заказчик и просит добавить поддержкy нескольких LDAP серверов >>> и несколько внешних систем аутентификации (типа пускаем в систему >>> gmail, yahoo и msn пользователей). >>> Все это можно задать в настройках и прозрачно пользоваться нашим >>> софтом смогут пользователи всех описанных систем. >>> Фича понятна, мы можем ее оценить. Заказчика устраивает наша оценка. >>> Можно работать. >>> Вот здесь и появляется Серега с вопросом: зачем эта фича нужна? >>> Обычно заказчик раскалывается не сразу. Сначала он рассказывает про то >>> как это круто и как удобно это будет. Он увлекся фичей также, как >>> програмист иногда увлекается новой технологией. Часто послушав >>> заказчика програмисты заряжаются его энергией и бросаются делать новую >>> прикольную фичу. >>> Но Серега на такие уловки не поддадется! :) >>> На самом деле заказчику нужно поддержать следующий сценарий: дать >>> возможность работать нескольким пользователям, которых нет в >>> корпоративном LDAP. Таких пользователей будет обычно совсем немного а >>> иногда не будет совсем. Эта фича довольно сильно отличается от того, с >>> чем пришел заказчик. >>> Реализовать поддержку gmail, yahoo и msn потребовало бы несравнимо >>> больше времени, чем то, к чему мы пришли.
>>> Что в этой истории я хочу подчеркнуть: >>> 1. Стандарный механизм дать заказчику оценку, после которой он >>> откажется делать фичу не работает. Этот метод скорее сработает в >>> ситуациях, когда оценка заказчика например страшно напугает и он >>> вспомнит сам с чего начал. Но часто это не так. >>> 2. Есть очень большая вероятность, что "придуманая" подобным образом >>> фича потом переделывается или выбрасывается совсем. Именно потому, что >>> она реализовывает не то, что действительно нужно, а то что заказчку >>> понравилось. Такие примеры были на практике неоднократно. Теперь мы >>> стараемся такое не допускать.
>>> С учетам второго пункта экономию от вмешательства Сергея на проекте >>> трудно переоценить :)
