Денис Бесков ([info]beskov) wrote,
@ 2007-10-24 23:12:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
PMI и пользователь
С тем, что на этапе инициации проекта можно ограничиться сбором бизнес-требований, я ещё могу согласиться, но вот то, что пользователь, по мнению PMI, не входит в число основных заинтересованных лиц — это довольно показательно.

Теперь есть формальное объяснение тому, почему PMI-подход так плохо совместим с разработкой публичных веб-систем.

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

(Post a new comment)


[info]imankey
2007-10-24 08:37 pm UTC (link)
Денис, спасибо за интересную мысль для обдумывания.
С удовольствием спрошу вас вот о чем: каким образом пользователь (не какой-то абстрактный пользователь, который участвует в сценариях использования), а конкретный человек, может принимать деятельное участие в выполнении проекта?

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

(Reply to this) (Thread)

[info]beskov
2007-10-24 08:53 pm UTC (link)
каким образом пользователь, конкретный человек, может принимать деятельное участие в выполнении проекта?
Я думаю, что как минимум понятие "фокус-группа" вам должно быть известно.

Кроме того, в малых XP-проектах часто роли заказчика и пользователя совмещены, и в XP-методологии есть отдельная практика Customer On Site. Ну т.е., скажем, для разработки бухгалтерской системы Заказчику проще (дешевле) выделить 1 бухгалтера и посадить его в команду разработки на полгода с сохранением ему обычной зарплаты, чем напороться потом на неудобство интерфейса или какие-то функциональные ошибки уже после выхода.

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

Ну вот у нас публичная веб-система, есть люди, которые отыгрывают его роль, и всё равно, у меня есть чёткое ощущение, что эти 5 внутренних человек не покрывают не то чтобы всего многообразия многотысячной аудитории, а просто имеют косное представление о потребностях пользователя и его ожиданиях, обусловленное замыленностью глаза, субъективностью и конфликтами с собственными интересами.

(Reply to this) (Parent)(Thread)

[info]belnetmon
2007-10-25 06:47 am UTC (link)
По поводу Customer On Site, точнее, вариации
Обычно, если разработка ведется на предприятии, где есть подобие многих подразделений, все делается по этому принципу + еще обязательная поэтапность. Одно подразделение выбирается как "базовое", внедрение ведется на нем. Добивается успеха. Потом ставится на другое. Учитываются их замечания, на третье, и т.п. итерациями.

(Reply to this) (Parent)(Thread)

[info]imankey
2007-10-31 09:01 pm UTC (link)
Верно, такой подход сопоставим с итерациями в scrum методологии. Приходилось использовать такое самому, работает эффективно.

(Reply to this) (Parent)

[info]imankey
2007-10-25 04:58 am UTC (link)
Да, customer on site - хороший инструмент. Пример про бухгалтера хорош, и он работает, но в случае с веб-системой это должно быть много различных пользователей. Весьма проблематично.
Я склонен с вами согласиться в том, что agile методики управления разработкой больше подходят для разработки публичных веб-систем в силу своей гибкости и легкости. Этого у них не отнимешь. По-моему, это уже стало общепринятой нормой: делиться с пользователем своим продуктом на самой ранней альфа или бета стадии, и затем воплощать те возможности, которые будут по-настоящему востребованы.
При разработке более консервативных систем используется, как правило, issue management, что менее эффективно и более дорого, но остается единственной возможностью пользователей заявить о своем видении проблем продукта.

(Reply to this) (Thread)

[info]beskov
2007-10-25 07:57 am UTC (link)
ну, кроме agile и классики есть ещё User-Centered Design и много всего другого

(Reply to this) (Parent)

[info]bulda131
2007-10-25 08:46 am UTC (link)
PMI болле общая практика используемая практически во всех областях деятельности а не только IT и основным ее фукусом является процесс управления проектом, в не зависимости от того, что это за проект. Плюс в строительстве, медицине, транспорте и прочих "давно устоявшихся и имеющих относительно четкую регламентацию требований пользователей" областях это менее актуально чем в IT в его текущей фазе.
XP практически используется только в IT проектах и заточен под их нужды и под текущее состояние индустрии.
Прямое стравнение этих практик не особо верно, тем более что PMI это практика ведения проекта и концентрируется на данном направление, а XP это практика разработки программного продукта и включает массу других аспектов нежели просто управление проектом. По моему скромному мнению XP более корректно сравнивать с RUP например.

(Reply to this) (Thread)

[info]beskov
2007-10-25 09:44 am UTC (link)
Это всё понятно, но многие IT-менеджеры носятся с PMBOK и PMI/PMP как с писаной торбой, потому как "продажей" менеджмента по RUP, скажем, у нас в стране никто не занимается, рынка нет.

(Reply to this) (Parent)(Thread)

[info]bulda131
2007-10-25 10:42 am UTC (link)
Согласен, у нас пока явная тенденция валить все в кучу не разбираясь в назначение того или другого продукта (практики).
Юзабилити должно рассматриватся в дисцеплине "Управление продуктом", а не "Управление проектом". Тогда все встанет на свои места. :) Для продукта конечный потредитель является самым важным заинтересованным лицом. А для проекта он хоть и является заинтересованным лицом, но в основном с точки зрения сроков, затрат и ресурсов, а не с точки зрения его удовлетворенности конечным продуктом.
вообще взаимотношение таких понятий как "процесс", "продукт", "проект" и тп отдельная очень интересная тема.

(Reply to this) (Parent)(Thread)

[info]beskov
2007-10-25 10:48 am UTC (link)
Ну если в проекте одно из ключевых понятий - объект поставки, то в строительстве требования к устройству объекта поставки (здания) вполне могут прокатывать через Заказчика, а в софтверной разработке такое иногда не проходит.

(Reply to this) (Parent)(Thread)

[info]bulda131
2007-10-25 02:45 pm UTC (link)
угу, но все равно предметные области PMI и XP (RUP) разные. мало того, как правило практики организации процесса (XP, RUP) включают PM как одну из дисциплин, наряду например с аналитикой или деплоем. По этому моя мысль в том, что просто не верно возлагать ответсвенность за юзабилити на PM, за правильную реализацию юзабилити - да, ответсвенный PM, но процесс построения интерфейсов с пользователем должне быть отдельной дисцелиной в рамках процесса разработки. И конечные пользователей должне на проекте представлять например аналитик, он то и будет заинтересованным лицом (заказчиком юзабилит) в терминах PMI/PMBOK. Он будет сотоять в комменикации с PM по этим вопросам, а не абстрактные клинеты.

(Reply to this) (Parent)(Thread)

[info]beskov
2007-10-25 02:59 pm UTC (link)
Помимо юзабилити есть собственно пользовательские требования, фиксируемые с помощью user stories или use-case.

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

То, что любое другое заинтересованное лицо можно натянуть на термин "заказчик", я догадывался :)

(Reply to this) (Parent)(Thread)

[info]bulda131
2007-10-25 03:23 pm UTC (link)
>Одно вот это ваше "конечный пользователь" уже о многом говорит :)
А как надо правильно? :) Слово "конечный" не верное?

Пользователь, несомненно, один из основных источников требований, с этим ни один здравомыслящий человек спорить не станет. Я пытаюсь защитить практики PM, тк в круг рассматриваемых ими вопросов управление требованиями не входит, это отдельная дисциплина. PM практики рассматривают ее планирование, но не суть. А вот в практики построения разработки, управление требованиями входит как дисциплина.
То что пока на нашем рынке часто путают применение разных практик это не есть хорошо, но это пройдет :)

PS: не надо на ВЫ :)

(Reply to this) (Parent)(Thread)

[info]beskov
2007-10-26 10:02 pm UTC (link)
"ты" лучше? ) ок

Слово "конечный", на мой взгляд, происходит из сферы привычного производства:
"производитель сырья -> производитель полуфабрикатов -> производитель -> потребитель (aka конечный пользователь)". Т.е. это термин из мира трансформационных систем, где есть производственная цепь и на конце её потребитель, называемый конечным.

В IT-разработке можно конечно тоже считать, что есть цепь:
"производитель оборудования -> сборщик оборудования -> поставщик оборудования -> производитель системного ПО -> поставщик системного ПО -> разработчик прикладного ПО -> пользователь", но это весьма натянуто, на мой взгляд. Здесь слово "конечный" избыточно.

Не, я не предлагаю УТ в МП засовывать. Но ведь если классика PM явно называет основных заинтересованных лиц - это она делает зачем-то. Зачем? Наверняка затем, чтобы:
1) Получить комплексное представление о требуемом качестве продукта, как совокупности ожиданий ЗЛ;
2) Иметь возможность влиять на ожидания;
3) Последовательно обеспечивать нужное качество продукта.

Но пользователем она почему-то явно пренебрегает.

С другой стороны, что есть "Scope Management", как ни одна из составляющих УТ? Пересечения есть, без этого никак.

(Reply to this) (Parent)
Управление качеством
[info]xoxerix
2007-11-02 07:24 am UTC (link)
Денис,
если смотреть в сторону PMBOK, то там есть область знаний Управление качеством,
имхо юзабилити это одна из частей качества.
Так что ПМ за юзабилити отвечает своей головой.

(Reply to this) (Parent)

[info]imankey
2007-10-31 09:07 pm UTC (link)
Спасибо за грамотную формулировку.

(Reply to this) (Parent)

[info]tutunov
2008-01-24 04:54 pm UTC (link)
Пользователь не входит в число основных заинтересованных, по мнению PMI, возможно потому, что могут быть проекты без будущих пользователей. Проект, по их мнению, это предприятие по достижение цели. А цели далеко не всегда в создании эксплуатируемого продукта. Например, цель снижения издержек на 10%, выход на такой-то рынок, высадится на Луну (на Марс) и т.д.
По их мнению, роль, которая определяет требования результатам поставки проекта - это Заказчик.

А где написано про бизнес-моделирование у PMI (про изучение устройства деятельности заказчика)? По моему, это совсем за рамками их PMBOK.

(Reply to this) (Thread)

[info]beskov
2008-01-24 05:27 pm UTC (link)
Хорошо, причины понятны, но есть же и следствие - PMI не предлагает никаких способов учёта специфики работы с пользователем.

На бизнес-моделирование PMI опирается в ряде мест (прежде всего оргструктурное), попозже найду, где.

(Reply to this) (Parent)(Thread)

[info]tutunov
2008-01-25 06:07 am UTC (link)
Если хотите более выраженную ИТ специфику, тогда имеет смысл брать соотвествующие источники:
Например: PMP® Project Management Professional Exam Study Guide. Fourth Edition, 2007
Автор: Kim Heldman, PMP, is the chief information officer for the Colorado Department of Transportation and is responsible for managing projects with IT components ranging from small in scope and budget to multi-million dollar, multi-year, multi-vendor projects. She has over 17 years experience in Information Technology project management. Kim has served in a senior leadership role for the past 9 years and is regarded as a strategic visionary with an innate ability to collaborate with diverse groups and organizations, instill hope and improve morale, and lead her teams in achieving goals they never thought possible.

В этой работе не раз встречается "user" и примеры даются по ИТ проектам.

(Reply to this) (Parent)
цитата из первоисточника
[info]tutunov
2008-01-25 06:15 am UTC (link)
До данного момента писал в примнципе, но раз уж полез смотреть источники, то заглянул и в PMBOK

Key stakeholders on every project include:
• Project manager. The person responsible for managing the project.
• Customer/user. The person or organization that will use the project’s
product. There may be multiple layers of customers. For example, the
customers for a new pharmaceutical product can include the doctors who
prescribe it, the patients who take it and the insurers who pay for it. In some
application areas, customer and user are synonymous, while in others,
customer refers to the entity acquiring the project’s product and users are
those who will directly utilize the project’s product.
• Performing organization. The enterprise whose employees are most directly
involved in doing the work of the project.
• Project team members. The group that is performing the work of the
project.
• Project management team. The members of the project team who are
directly involved in project management activities.
• Sponsor. The person or group that provides the financial resources, in cash or
in kind, for the project.
• Influencers. People or groups that are not directly related to the acquisition
or use of the project’s product, but due to an individual’s position in the
customer organization or performing organization, can influence, positively
or negatively, the course of the project.
• PMO. If it exists in the performing organization, the PMO can be a
stakeholder if it has direct or indirect responsibility for the outcome of the
project.

(Reply to this) (Parent)

[info]tutunov
2008-01-25 06:28 am UTC (link)
Содержание PMBOK большей частью излагается в разрезе областей знаний (интграция, управление сроками, стоимостью и т.д.), а не в разрезе групп процессов (инициация, планирование, исполнение, контроль и завершение). Имеется лишь краткое рассмотрение в разрезе групп процессов, но и там при упоминании заинтересованных лиц единственные проименованные персонально это "потребители", которые по PMI являются группой "потребители/пользователи" (Customer/user).

Involving the customers and other stakeholders during initiation generally improves the probability of shared ownership, deliverable acceptance, and
customer and other stakeholder satisfaction. Such acceptance is critical to project success. (стр. 44)

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

(Reply to this) (Parent)

Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…