Обсуждение

Potsemu posle mmnogo bukov nikogda ne bivajet komentariew?

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

А я прочитал до конца ;-) Объектная парадигма, конечно мощная штука (проект - объект, процесс - экземпляр объекта ), но, по-моему, есть процессы, которые не укладываются в эту объектно-озабоченную схему. ООПс :-) IMHO, операционное управление (процессы) и проектное управление (проекты) существенно отличаются тем, что проекты изначально ограничены во времени (и потому, вообще говоря, их можно запланировать). Процесс не имеет срока жизни, а проект имеет. Операционное управление через проекты (с использованием шаблонов) хоть и напоминает проектное управление, но всегда сталкивается с этой же временной неопределенностью - время завершения цикла работ ("минипроекта") часто неизвестно. Например, большинству сервисных организаций не известен заранее объем работ: никто не сможет заранее сказать, какое кол-во звонков в течение месяца поступит в call-центр, сколько заявок пришлют клиенты на модификацию кода или сколько человек придет стричься в салон. Т.е. деятельность таких организаций организуется потоком внешних событий (event-drive). Есть поток работ, которые возникают по случаю, и планировать (во времен) выполнение каждой работы проблематично - можно управлять реакциями. Даже если каждую стрижку в салоне будут делать по "проектному" шаблону (помывка головы -> уточнение требований -> стрижка -> помывка -> укладка -> акт сдачи-приемки :-) мы все равно не сможем заранее узнать, сколько времени займет каждая стадия и весь цикл работ в целом (ЖЦ) - слишком много вариаций. Можно, конечно, ввести рационирование (ограничение по времени) на каждую стадию, но всех стричь "под горшок" не получится - сервис предполагает интерактивность и итерационность. То же самое можно сказать про деятельность любых поддерживающих подразделений внутри организации - работу бухгалтерии предприятия, например, крайне проблематично описать в проектных терминах. Другой пример. Компания, в которой я работаю, занимается разработкой, внедрением и сопровождением ПО. Сопровождение - типичная операционная деятельность (по запросам), а разработка и внедрение - проектная. Для управления разработкой мы как раз и используем шаблоны (управление через проекты), поскольку разработчики "обслуживают" и проекты и сервис (один пул ресурсов). Канонические проекты внедрения "живут" в Project'е, разработка ПО - там же (шаблоны), а вот сопровождение туда засунуть не получается никаким манером (но очень хочется ;-).

Вы мне отвечаете странно: "если длинный проект, то можно засунуть в MSProject, а если на пару часов -- нельзя". А я говорю тут не о том, что можно засунуть в MSProject, или что можно засунуть в Issue Tracker. И не о том, что вообще стоит или не стоит заносить в софт, а просто поглядеть на то, что делает человек прямо сейчас (скажем, моет голову клиенту ;). Я говорю тут о понятийной модели. Мы готовы показать, как использовать Issue Tracker не только как процессный софт (в котором лежат Workflow), но и как проектный. И у меня тут нет цепочки метакласс-класс-объект ;) Хотя очень хотелось бы, чтобы она была :)

Project тут не при чем. Я говорю о концептуальной разнице - проект имеет время жизни, процесс - нет. И есть процессы, которые не втиснуть в проектную схему в этом смысле. Вероятно, я что-то упустил, но Issue Tracker в качестве проектного софта использовать не получается: очереди задач, распределение ресурсов, закрепление ответственности - это пожалуйста, пожалуйста, но где в этих трекерах временная составляющая? Каким манером можно сказать, что этот проект-процесс будет завершен к такому-то числу?

Конечно, процесс не имеет время жизни, а проект его имеет: тип не может иметь значения, а переменная его может иметь. Процесс -- это "штамп", а проект -- созданный этим штампом объект. Но тем самым процессы невозможно втискивать в проектную схему, это совсем другие сущности. Issue Tracker вполне используется в качестве проектного софта: там вполне делаются workflow (процессы), но каждое прохождение по ним -- это вполне проект. В Issue Trackers учитываются времена исполнения задач. Задачи там группируются, чтобы составить проект (ибо это не "шаблоны задач", а конкретные задачи с конкретным содержанием). Про процесс нельзя сказать, к какому числу он может быть завершен: про тип нельзя сказать, какое у него значение. Про проект это сказать можно.

В Issue Trackers нет балансировки ресурсов: низзя сетевые графики строить или критические пути или я ошибаюсь? Опять из практики: у меня в трекере выстраивается очередь задач на каждого специалиста, каждая задача в общем случае выполняется в порядке очереди (wait-for), при этом этот специалист задействован в нескольких проектах. Поэтому возникновение срочной задачи обычно приводит к изменению очередности выполнения задач из очереди, что практически означает изменение сроков реализации проекта. Трекер в этом случае должен включать "колокольчик", сообщающий мне о возможном нарушении сроков проекта, но он этого делать не умеет - ибо не делает пересчета плана-графика (см. выше).

Вы правы, трекеры всем хороши, но критический путь они показать не умеют (хотя выстроить зависимости лучшие из них вполне могут). Мы сейчас пытаемся поэкспериментировать в этом направлении -- сделать такой issue tracker, который будет считать критическую цепочку (даже не критический путь ;)