Process, Project, Case, Agile, Product и другие виды менеджмента - сопоставляем конструкцию и назначение

Материал из MaksWiki
Перейти к: навигация, поиск
Конференция «Прикладное системное мышление 2021» 3-4.04
Видео на youtube в общей записи второго дня, начало моего доклада 42:24

Есть много разных видов менеджмента. Наиболее известны process и project management, а также методы agile-менеджмента, по которым есть хорошо проработанные учебники и тренинги. Менее известен case management, сравнительно недавно появился product management – управление продуктами. Новые виды появляются на основе ранее созданных, и в развитии обогащались практиками из разных источников. Поэтому часто складывается впечатление, что это просто вариации одного большого менеджмента. Это – неверно, в конструкции разных видов менеджмента заложена принципиальная разница, которая и позволила новым видам решать ранее не решаемые задачи.

В докладе будет сравнительный анализ назначения и принципиальных конструкций различных видов менеджмента (process, project, case, product etc.) на схеме OMG Essence и других, которые позволят представить принципиальную разницу методов. Это попытка представить state of art менеджмента на общей схеме - потому что никакой фиксации state of art нет, есть инкременты в рамках отдельных ветвей, при этом некоторые ветви выделились полстолетия назад. Текстом я это сделал в статье «Process, Project, Case и Product management – в чем разница?», в докладе будет схематизация и развитие.

Предварительные тезисы

Когда делали презентацию, содержание несколько поменялось.

  1. Менеджмент развивается быстро. Никакого state of art в зафиксированном - нет. Есть инкременты к предыдущему, часто представляющие отдельные многолетние течения, и по ним тоже нет state of art - все живет. Есть способы их объединения под конкретные случаи.
  2. В OMG Essence есть важная попытка - создать схему, на которой можно фиксировать state of art в разных вариантах, сравнивать и комбинировать - именно за счет того, что они положены на единую схему, есть претензия, что ничего важного не упущено, а если упущено - то есть способы дополнения, по аналогии с открытыми точками расширения в софте.
    1. Схема OMG - как она есть. Стейкхолдеры дают возможности, они фокусируют определение системы.
    2. Это дает два полюса управления: процессное, ориентированное на оптимизацию и обработку однородного потока задач, и проектный, ориентированный на разовую работу.
    3. То, что поместили на общую схему дает возможность работу на смешанных потоках, к которым относятся IT-проекты - там после первого релиза почти всегда эксплуатация вместе с развитием. И так же покрывает Case Management.
  3. Принципиальная новизна схемы - что верхний слой, Customer, втянут внутрь деятельности и относится к объекту управления, а не задает контекст. Хотя по стрелкам на схеме этого НЕ скажешь. Учебники классического менеджмента преимущественно относят это как к контексту, или выделяют в совершенно отдельные потоки работы, например, работу со стратегией. А здесь это - внутри.
    1. Отметим, что классический проектный менеджмент выносил ответ на вопрос "обеспечивает ли результат проекта требуемые возможности" за рамки проекта, на уровень программ проектов - об этом я писал тоже статью для профессионального журнала Управление проектами https://mtsepkov.org/ValuableProjects
    2. Однако, цепочка создания ценности на схеме - стрелки на стейкхолдеров нет. Так что здесь схема не фиксирует важное изменение менеджмента. Удовлетворенность стейкхолдеров как критерий успеха проекта - совсем не то, что работа со стейкхолдерами классического менеджмента. Мой доклад https://mtsepkov.org/Sth-Satisfied-2017
  4. Здесь так же уместно говорить про Lean, который впервые разграничил task flow и value flow, поставил задачу устранения task, не несущих value - muda, пустая работа. И это тот фокус, который следует держать в современном менеджменте.
  5. Схема также добавила Команду и Метод в объекты управления. И это - очень правильно.
    1. Баланс между Методом и Компетентностью как средством обеспечить выполнение работ - он важная составляющая проекта. А он таким образом не рассматривается и даже вопроса не ставится, наоборот говорят "обеспечьте компетентными сотрудниками". Что в нынешних условиях невозможно.
    2. Однако, не проявлена тема формирования команды и выбора технологии. Если обратиться к схеме Минцберга, то этим занимается отдельная структура - техноструктура. И она же занимается технологиями. И тут как раз мы имеем серую зону разделения ответственности между командой и стейкхолдерами. Насколько эти стейкхолдеры играют именно внешние роли. И на начальном этапе, когда команда находится в процессе формирования, и на последующих, когда при переходе между фазами проекта существенным образом меняется поток работ, требующий переформирования команды и технологий - насколько эта задача внутренняя (то есть выполняется Team) или внешняя (выполняется стейкхолдерами). Это - важная точка внимания в современном менеджменте.
  6. Вопрос: а как создается определение системы? И что включает это определение? Ведь если посмотреть на схему внимательно, то там нет задач, которые бы его создавали.
    1. Есть вариант отдельного проекта по его созданию. Но у него получается висящая обратная связь, невозможно проверить результат.
    2. Поэтому правильная рисовка - другая, на основе возможностей и потребностей стейкхолдеров Команда, выполняя Задачи, создает и Образ системы и его Воплощение системы.
    3. И я бы считал правильным изменить Описание системы на Образ системы, имея в виду именно идеальный объект, быть может не представленный артефактами. Образ - точно предшествует воплощению. И его важно верифицировать. А вот Описание - как придется…
  7. Product Management.
    1. Фишка в том, что помимо Стейкхолдеров появляются Пользователи, которым нужны возможности системы-продукта. А Стейкхолдерам нужны возможности НЕ от системы - им нужен охват рынка, генерация потока денег для бизнеса и так далее.
    2. Таким образом, в Opportunity заложен дуализм: когда мы делаем фичу, полезную и нужную группе пользователей, то есть приносящую им ценность, то мы тем самым одновременно способствуем, чтобы эта группа начала больше использовать продукт, реализуя идеи стейкхолдеров о развитии. И мне кажется важным, что это дуализм одного объекта, в каждому его экземпляре должны быть две этих составляющих.
    3. Однако, при этом фича превращается из действительно требуемого и приносящего ценность изменению продукта в предпринимательскую гипотезу об этом изменении. И это принципиально меняет жизненный цикл работы с ним. Именно этим Product management отличается от остального менеджмента. Предпринимательство втягивается внутрь объекта управления.
  8. Самоорганизация и самоуправление. Социократия как State of the Art. OKR как средство синхронизации целей и приоритетов между Стейкхолдерами и Командой. Альтернативная обычной приоритизации задач.
  9. Принципиальные инновации Agile

Видео доклада

Презентация

Скачать весь pdf
MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf MngTypes-SysSchool-2021-Tsepkov.pdf