Сегодня проснулся в 4 утра, и уснуть больше не смог. Пошел налил чай, и пока смотрел как он заваривается, вдруг понял суть декомпозиции задач относительно оргструктуры 🙂

Фишка в том что декомпозировать задачи надо уметь. И единственная адекватная и по совместительству самая простая методика это ВИСИ.

Когда задачи достаточно малы, то проблем нет. Но если мы говорим о проектах, которые как правило реализуются на стыке различных отделений организации, то нам нужно четко понимать, кто и какую часть проекта реализует.

Здесь нам нужно 3 или 2 структуры. Вероятно всего 3.

Первая структура это сама декомпозиция. Это дерево задач или требований, которые структурированы по ВИСИ.

Вторая структура это оргструктура. Структура отделений организации.

Вся суть в том, что это дерево должно быть разбито на стволы таким образом, чтобы один отдел мог отвечать за один ствол дерева.

Если дерево не получается разбить на стволы, вероятно плохо сделана декомпозиция.

И треться структура, это структура кейсов (мы же проповедуем кейс менеджмент…), каждый кейс это ствол. Центральный кейс — за него отвечает ведующее отделение, далее на каждый ствол создается подкейс, и назначается ответственным кто либо из смежных отделений.

Таким образом декомпозированная задача «надевается» на орг структуру.

Особо это заметно в строительных проектах. Где проект это то чем занимается вся организация, а каждый отдел выполняет какую то конкретную часть этого проекта.

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

Тут стоит остановиться на том, что подобную концепцию крайне сложно реализовать в приложениях для управления проектами аля MS Project. Получается полная попа.

На мой взгляд кейс менеджмент тут подходит как нельзя лучше.

Во первых не каждое отделение в организации может мыслить категориями проектов. Скажем часть проекта для отдела ИТ может подпадать под категорию «Запроса на обслуживание», как и для хоз отдела. При этом оно попадает в общую очередь операций из той же категории, иначе планировать работу отдела ИТ становится не возможно. Нарушается единообразие и получается лажа.

Конечно можно поставить срок и в этом случае руководитель отдела ИТ обязан спланировать очередь операций так, чтобы уложиться в срок либо обозначить проблему.

Надеюсь примеры углубили понимание данной идеи.

Теперь давайте разберем еще две интересные особенности этой идеи.

К примеру в MS Project декомпозиция записей идет до уровня задач. Каждая задача имеет подзадачу и надзадачу. И так образуется дерево. Я же полагаю что это плохая идея. На мой взгляд декомпозиция задач должно идти до стволов. А стволы это то что можно передать целиком в тот или иной отдел или под ответственность кого либо из сотрудников.

Но стволы конечно же могут делиться на ветки. Ветка это такой же пункт декомпозиции но мелкий. В MS Project мы вынуждены такие ветки фиксировать как отдельные задачи. В кейс менеджменте ветки образуются чек листом (контрольным списком). Каждая значимая ветка записывается как чек поинт (пункт контроля, веха, галочка).

Стоит понимать что проект похож на дерево возможно на много сильнее чем мы можем догадываться. Ну или как минимум больше чем я думал 🙂 До тех пор пока не осознал эти идеи.

Мы можем подумать что в MS Project существует понятие стволов. Его можно перепутать с группой задач. Это не так.

Конечно мы можем обозначить эту группу как ствол и закрепить ее за каким то отделением. Но это не отражает всю суть идеи.

Ствол в понятии кейс менеджмента может иметь отдельную категорию и свой набор реквизитов. Управляться по своим правилам и регламентам, быть операцией отдельного процесса. Это очень самостоятельная и самодостаточная сущность, но имеющая отношение к проекту и подвержена влиянию этих отношений. В этом ключевая разница от подхода который нам навязывает MS Project и который стал по сути стандартом дефакто в сфере управления проектами.

А ветки ствола — это чек поинты чек листа. Ветки более гибки и они легко отрастают и легко обрываются. В этом суть чек поинта.

И вот тут возникает интересная делема, а чем отличается ветка от ствола?

Ответ прост — размером.

Ветка может легко стать стволом и поделиться на другие стволы и другие ветки. Если это требуется.

Почти все системы которые так или иначе развиваются в направлении кейс-менеджмента позволяют парой щелчков ветку превратить в ствол. Например Trello, там чекпоминт легко превращается в карточку (кейс).
9131

Кейс-менеджмент — крутая штка. Она на много естественней, чем MS Project и подобные инструменты. Аналогия с деревом колоссальная.

А если техническая система начинает походить на природные творения — для меня это признак адекватности идей и правильного хода мыслей.

Я долго не мог понять что такое проект, и как управлять крупными проектами, которые пронизывают множество отделений организации. Так чтобы это ровно ложилось в концепцию кейс-менеджмента. И вот теперь понял 🙂