вторник, 15 сентября 2009 г.

Процессы, проекты и российские компании

Введение

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





Определения

Задача – однократно выполняемая за короткое время работа одного исполнителя (то есть, каждое новое задание выполняется одним сотрудником по каждый раз новым или модифицированным правилам);

Функция – регулярная работа одного работника, выполняемая по известным ему правилам (то есть, каждое новое задание выполняется одним сотрудником, но всегда по установленным, повторяющимся, известным ему правилам);

Проект – однократно выполняемая работа многих исполнителей за длительное время (то есть, каждое новое задание выполняется многими сотрудниками, по каждый раз заново сформулированным правилам и алгоритмам);

Процесс – это регулярно выполняемая работа многих исполнителей по четко зафиксированным правилам и алгоритмам.

Отличия процессов от проектов

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

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

Так, все бизнес системы, ориентированные на автоматизацию типовой деятельности характеризуются следующим ключевым свойством:

Процесс «планируется» однократно, на стадии внедрения системы автоматизации и становится частью этой системы. Далее, он периодически подправляется (оптимизация процесса) или может быть полностью заменен (реинжениринг процесса).

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

Системы управления проектами должны предоставлять не только средства контроля следования плану, но и средства быстрого создания плана проекта и ежедневной модификации (актуализации) плана.

Далее стоит отметить разницу в подходах к контролю деятельности при процессном и проектном управлении:

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

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

Таким образом, автоматизация управления процессами отличается от автоматизации управления проектами подходами к планированию и контролю деятельности. Причем разница существенна и применение систем управления процессами для управления проектами, либо наоборот — неэффективно.

Автоматизация проектов и автоматизация процессов

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

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

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

Классические системы управления проектами строятся вокруг стандартного цикла: план-реализация-контроль результата”. Они включают компоненту для создания плана проекта, компоненту для сбора информации о фактическом ходе проекта и компоненту для сравнения плана и факта.

Каждый из этих типов продуктов очень хорошо работает в ситуации, когда мы имеем дело с «чистым» процессом или «чистым» проектом. Чистый процесс означает, что мы выполняем только повторяющиеся активности и никогда их не варьируем, отклоняясь от плана. Чистый проект — что все активности уникальны и повторяющихся просто нет .

Но часто ли в реальной жизни мы сталкиваемся с чистыми процессами и чистыми проектами?

Организация деятельности в средней российской компании

Рассмотрим классический пример, взятый из статьи, посвященной процессам и проектам:

Пример:

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

Но представьте, что в какой-то момент времени, Вам необходимо закупить нечто, что Вы никогда не закупали, и при этом, не ясно как это нечто закупить. Например, Вам потребовалось сырье, которое производится лишь в одной стране мира, представительства и поставщика данного производителя в РФ нет, и не ясно как его можно вообще купить? Что Вы будете делать в этой нестандартной ситуации?

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

Андрей Борисов, старший консультант компании TOPs, г. Москва.

Что мы здесь видим? Идет процесс — от него отделяются проекты, их результаты встраиваются обратно в процесс. Таким образом, в деятельности средней компании есть и процессы и проекты. Более того, они связаны между собой, обмениваются результатами и в целом их можно рассматривать совокупно, как деятельность , имеющую признаки и процесса и проекта.

Пример является характерным, по крайней мере для российских средних компаний.

Что получается при применения классической процессной автоматизированной системы для управления такой деятельностью? Одно из двух:

  • нестандартные активности (проекты) идут мимо процесса и не учитываются в системе
  • систему приходится перенастраивать почти ежедневно, добавляя в нее каждый проект в виде отдельного процесса

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

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

Эти проблемы, заставляют директоров искать другие пути управления деятельностью.

Заманчивой, выглядит идея примененить для управления такой деятельностью проектную систему. Однако и здесь есть свои недостатки. Если процессная система не учитывает нестандартные активности, то проектная не удобна при работе со стандартными. При ее применении, вам придется каждый раз заново планировать повторяющуюся деятельность. Это надоедает, занимает лишнее время, приводит к ошибкам. Кроме того, в системе теряется информация о том, что какие-то части являются повторяющимися активностями, что не помогает при анализе деятельности.

Тогда какая нужна система?

В идеале, было бы иметь систему, способную обрабатывать оба вида активностей — периодические и нестандартные.

Читать полностью...

пятница, 17 июля 2009 г.

Недостатки планировщиков


В этом документе я попытался описать наиболее раздражающие меня недостатки настольных инструментов планирования проектов. Таких, как MS-Project Standard (не путать с сервером), OpenWorkbench или OpenProj.


Очень интересно, услышать Ваше мнение по этому поводу.



WBS versus календарный график

В жизни существует две независимых «топологии» над набором задач проекта:

  • Иерархическая структура задач (в которой деление на подзадачи происходит естественным образом)
  • Распределение задач по вехам, или по версиям системы. Здесь две подзадачи одной задачи вполне могут попасть в разные вехи. Например, если одна подзадача крайне важна, а вторая — незначительная «фича»


Все существующие планировщики хорошо работают с первой топологией, но почти ничего не предлагают для работы со второй. Это — исторически сложившийся факт, вызванный тем, что давным-давно, когда основным способом разработки софта был т.н. водопад, никакой второй топологии вообще не возникало. Версия у проекта была одна. А если была вторая, то она оформлялась как отдельный проект. Эти времена давно в прошлом. Итеративному подходу к разработке уже наверное почти 20 лет, а вот инструмент остался прежним. И этот инструмент почти не позволяет посмотреть на задачи проекта в разрезе версий. И тем более управлять распределением задач по версиям.


Такое положение дел иногда приводит к тому, что планировщики начинают использовать некорректно, заменяя WBS структурой вроде следующей:

Первая версия

  Разработка

    Разработка фичи 1

  Тестирование

    Тестирование фичи 1

Вторая версия

  Разработка

    Разработка фичи 2

  Тестирование

    Тестирование фичи 2


Здесь появляются версии, но ломается логическая структура работ. Теряется информация о том что какие то задачи являются частями одной бОльшей задачи.

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


Разработка

  Разработка фичи 1

  Разрапотка фичи 2

Тестирование

  Тестирование фичи 1

  Тестирование фичи2

Веха — версия 1, зависит от (Разработка фичи 1, Тестирование фичи 1)

Веха — версия 2, зависит от (Разработка фичи 2, Тестирование фичи 2)


Здесь все правильно с точки зрения логики. Но к сожалению, абсолютно не наглядно. При сколько нибудь приличном объеме проекта, в котором есть много задач и много связей между ними, оказывается крайне сложным сказать какие задачи попадают в какую из вех. (Поскольку большая часть зависимостей транзитивна). Тем более сложно осмысленно перемещать задачи между версиями. При этом совершенно не видно к каким последствиям это перемещение приведет — что потянется за перемещаемой задачей. Опять таки причина этого явления в том, что в древние времена не возникало такой проблемы как перенос задачи между версиями. Версии сами являлись независимыми проектами и были статичны.

Дополнительным неудобством является тот факт, что вехи являются задачами. Ничем от них не отличаются. Поэтому увидеть какие вехи зависят от данной задачи очень сложно. Вехи перечисляются в списке ВСЕХ задач, которые зависят от данной. (Кроме того тут опять появляется вопрос о транзитивных зависимостях, которые просто так не увидишь)

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

О них, кстати, подробнее:

Транзитивные зависимости между задачами

Ни в одном планировщике нет способа увидеть все задачи, зависимые от данной или все — зависящие от данной. То есть есть возможность увидеть только список непосредственно зависимых (или зависящих). А вот зависимых от зависимых (и тд) — нельзя никак. Часто это оказывается неудобным.

Наиболее яркий пример неудобства — это выставление этих самых зависимостей при планировании проекта из 100 и более задач. Практически нет удобного способа убедиться что все зависимости выставлены правильно. Вполне может оказаться что задача 32 зависит от задачи 44, но мы эту зависимость не указали, потому что решили, что она и так есть — транзитивная. Может быть она даже была, но в какой то момент пропала. Отследить это, не видя транзитивных зависимостей, крайне сложно.

Можно возразить, что надо-де вставлять все зависимости напрямую и не полагаться на транзитивные. Но вот пример — задача «Подготовительные активности» в которой 30 подзадач. И задача «Разработка» в которой еще 50 подзадач. Станете вы вставлять полторы тысячи прямых зависимостей для каждой из 50ти задач по разработке от каждой из 30ти подготовительных задач? А проходить по списку подготовительных задач, искать зависимые для каждой из них и переносить каждую из этих зависимостей в каждую из 50 ти задач разработки? А поддерживать целостность такого плана?

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

Личные планы

Другим забавным неудобством планировщиков является трудность в просмотре личного плана — плана работы для одного человека. Нечто подобное реализовано только в OpenWorkbench в виде фильтра по ресурсам (людям), скрывающим все задачи, в которых данный человек не участвует.

Это уже кое-что. Но. Было бы очень неплохо видеть на этом графике входящие и исходящие зависимости задач этого человека от других задач. Чтобы при планировании было видно где график работы Васи Пупкина может «поплыть» не по его вине, а из-за задержки другого члена команды. С другой стороны, чтобы этот самый Вася видел, на какие задачи ему стоит обратить внимание, чтобы не «удружить» своему товарищу.

А еще мне не хватало возможности выбрать ни одного, а несколько человек в этом фильтре. Скажем двоих — чтобы посмотреть зависимости между их задачами.

Молчаливый и настойчивый Искусственный интеллект

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

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


12:21.22 — Попытка сдвинуть задачу такую-то ранее 12го августа пресечена, поскольку 12е августа — дата старта нашего проекта.

12:21.45 — Пользователь Вася изменил длительность задачи такой то, поэтому теперь работа пользователя Пети, который будет эту задачу делать увеличилась и составила 24 часа вместо ранее запланированных 16ти.


Это бы сэкономило время и нервы, а заодно бы послужило хорошим заменителем длинных мануалов.

При этом, особо важные сообщения можно показывать сразу же — в виде всплывающих подсказок, клик по которым открывал бы всё тот же лог.

Информационная атака

Очень симпатично смотрятся примеры работы с планировщиками, взятые из разных tutorial-ов. Типа проект «постройка дома» мило делится на 15 задачек, вроде «заказ гвоздей» иди «заливка фундамента».

В реальности, нормальный средний проект редко содержит менее тысячи задач.

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

А если план меняется (как это всегда бывает в жизни), да к тому же менять его надо именно вам?

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

Например, есть такая задача менеджера как осмысление взаимных зависимостей различных частей проекта. В реальности, далеко не все подзадачи вообще имеют какие-либо зависимости. Так почему же менеджер должен видеть всю тысячу задач, чтобы осмыслить скажем 30 зависимостей? В данной ситуации было бы очень полезно уметь скрыть ненужные задачи.

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

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

Кстати, пункт «Личные планы» тоже из этой оперы. Это срез информации необходимый для оценки плана работ каждого участника проекта.

Статичность

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

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

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


Читать полностью...