TEST Проекты, программы, процессы, кейсы
!!! Серафима на заседании настаивает, что выполнение договора по высадке 100 деревьев в парке — это процесс. Дженнифер утверждает, что это кейс. Нуржигит говорит, что это проект. Кто прав?
--- Серафима, ибо 100 деревьев это точно что-то повторяющееся. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как процесс. Процесс — это только одно из возможных описаний/view этих работ.
--- Дженнифер, ибо непонятно, что мы встретим в выполнении этих 100 работ как целого, и работ по высадке отдельных деревьев. Да, там будет что-то повторяться, так это просто шаблон кейса. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как кейс с подкейсами. Кейс — это только одно из возможных описаний/view этих работ.
--- Нуржигит, ибо это совершенно уникальные работы в уникальном месте с уникальными условиями, и мы хорошо понимаем, сколько примерно времени займёт высадка одного дерева, можно говорить о нормировании работ. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как проект. Проект — это только одно из возможных описаний/view этих работ.
+++ Все ошибаются. Выполнение работ — это выполнение работ, изменения в физическом мире, само по себе выполнение работ не есть «процесс», или «проект», или «кейс». ### Да, мы какие-то работы можем описать как процесс, проект, или кейс. Это не означает, что сами работы вдруг стали процессом, проектом, кейсом, программой.
+++ Все неправы, но они могут продолжать думать и действовать в соответствии со своими убеждениями, учитывая разные особенности ведения работ по этому договору. ### Да, выполнение работ по договору — это действия в физическом мире, но думать о них можно по-разному.
!!! Можно ли одновременно использовать разные методы управления работами?
--- Нельзя, нужно определиться: если у вас уникальные работы, то используйте проектное управление, если повторяющиеся — процессное управление, если разработки — управление кейсами, если очень большие и пока непонятные работы, то используйте программы. Смешивать не получится, там даже терминология разная. ### Нет, разные методы управления работами будут отвечать на разные вопросы. Вполне можно использовать разные приёмы управления работами из самых разных методов самых разных школ. Нужно не забывать, что работы существуют как поведение взаимодействующих экземпляров физических объектов в реальном мире, а вот методы их описания могут быть задействованы разные. Разные методы описания одних и тех же работ используются разными школами операционного менеджмента: работы сами по себе не «объективно» проекты, процессы, кейсы, программы, это просто они описываются по-разному.
+++ Можно свободно перемешивать методы операционного управления, разные варианты этого смешивания просто будут давать разные акценты в моделировании потоков. ### Да, если вы понимаете, что речь идёт об управлении потоком работ, то разные методы операционного управления помогут давать ответы на вопросы в трудных случаях: на какие вопросы не ответит один метод, сможет ответить другой метод, и наоборот. Поэтому проще рассматривать содержание всех этих методов как набор мелких практик, которые можно задействовать по потребности, а не обязательно как целую методологию.
!!! Когда говорят «процесс проектного управления», что имеют в виду?
--- последовательность шагов процедуры/алгоритма, по которому идёт управления проектом (сначала открыть проект, потом запланировать работы, после этого начать работы и следить за выполнением плана и т.д.). ### Нет, слово «процесс» давно уже не относят именно к шагам, чаще всего оно означает «практику» или даже «метод». Хотя и могут говорить о практике открытия проекта, практике планирования работ, но это не последовательность шагов — это именно практики.
+++ просто это практики проектного управления, «процесс» тут синоним «практики» ### Да, это наиболее вероятно. «Процесс» как развёртка чего-то во времени уже редко используется в менеджменте, чаще в инженерии. Хотя «процессное управление» ещё работает с шагами процесса.
!!! Вам нужно выбрать софт для управления работами в вашей компании. Вы ожидаете, что будет довольно много работ по разработке, плюс придётся время от времени управлять муторными однообразными процедурами тестирования оборудования, а ещё обрабатывать мелкие поручения клиентов, вечно чем-то недовольных. Феликс предложил для управления работами использовать софт проектного управления, хотя бы входящий в MS Office Microsoft Project, ибо такой софт предназначен как раз для управления работами! Лидия предложила купить софт управления процессами, ибо процесс разработки, процесс тестирования, процесс выполнения поручений клиентов — это всё бизнес-процессы, а в этом софте есть и BPMN, можно написать это всё на языке Business Process Model and Notation. Виталия предложила использовать issue tracker, который используют программисты и системные администраторы компании: просто начать использовать его ещё и для всех некомпьютерных работ. Чьей рекомендации нужно последовать?
--- Феликса. ### Нет, проектное управление тут вряд ли пригодится, ибо речь идёт об управлении разработкой, и управлении поручениями, работы в них предварительно не запланируешь.
--- Лидии. ### Нет, ничего особо повторяющегося в разработке и в поручениях нет, и ход на компьютеризацию/автоматизацию тут тоже не пройдёт. BPMN будет бесполезен, хотя можно думать о его использовании при автоматизации помянутых «муторных однообразных процедур тестирования», но вот отработку неожиданных результатов этого тестирования (непрохождение тестов) всё равно придётся делать другими средствами.
+++ Виталии. ### Да, вполне можно приспособить issue tracker для управления работами, если там есть разработка и выполнение поручений. И можно даже использовать issue tracker для работы с чеклистами при выполнении «муторных однообразных процедур тестирования», а то и автоматизировать их (скриптование каких-то «процессов» есть в большинстве issue trackers, хотя необязательно на языке BPMN).
--- никого из них, каждый как-то сам приспособится. ### Нет, всё-таки придётся развернуть софт управления работами, иначе не будет удаваться согласовывать деление времени сотрудников между самыми разными проектами.
--- будем вести обычные протоколы на совещаниях по управлению работами, никакого софта, софт — это лишние хлопоты по его разворачиванию и поддержанию в актуальном состоянии. А протоколы — это классика, она вечно живая! ### Нет, протоколы непригодны для дел, которые не успеваются выполниться за неделю. В даже небольших программных проектах, например, проходит от 6 тысяч работ: какие протоколы переварят это количество? А ведь ни одну из них нельзя пропустить! Так что нужно от протоколов всё равно переходить к софту управления работами.
!!! К вам пришёл Гарегин, которому вы поручили на предыдущих трёх совещаниях 15 дел, а ещё до этого у него уже было недовыполненных 8 дел (всего ему поручили 23 дела). Каждое дело небольшое, на несколько часов или максимум на пару дней. Вы понимаете, что месяца на них всех вполне должно хватить. Гарегин рассказывает, что тратит на выполнение каждого дела примерно по 20 минут в день, иначе он не может гарантировать, что хоть как-то движутся все порученные ему вами дела. Что он делает не так?
+++ допускает мультитаскинг, занимается каждым делом слишком мало. ### Да, мультитаскинг с малым временем выполнения каждой работы приводит к обманчивому впечатлению, что «все дела идут». На самом деле «все дела стоят», ибо они бо́льшую часть времени будут в состоянии «не закончены». При таком подходе большинство дел будут выполнены позже, чем если их просто выполнять подряд целиком.
--- он всё правильно делает, это типичная ведь ситуация! ### Нет, он делает неправильно. Он задерживает те работы, которые могли бы быть выполнены быстро, если бы ими занимались достаточное время. А так большинство работ перейдёт из состояния «работы идут» в «выполнено» намного позже, чем если бы они выполнялись последовательно. Последние работы всё равно будут выполнены ближе к концу месяца, но результаты первых выполненных работ к этому моменту будут уже месяц как доступны!