Вчера устроил небольшой флем на фейсбуке ссылкой на статью Почему Microsoft Project нельзя использовать для управления проектами Статья примечательна тем, что собрала множество комментариев как от людей, использующих трекеры задач, так и от «настоящих проектных менеджеров» трекеры не использующих. Их аргументы звучат примерно так: трекеры это только для ИТ-проектов, трекеры это для управления продуктами (вероятно, речь о PLM), трекеры предназначены для отслеживания локальных задач и не позволяют осуществлять планирование и т.д.
В общем, все эти аргументы, в какой-то мере, правильные. Понятие проекта в трекерах это не совсем проект. Несмотря на схожесть таких видов деятельность как управление проектом, развитие продукта, устранение дефектов и управление инцидентами в них довольно много различий. Даже если мы сравним управление инцидентами в ИТ с управлением инцидентами в телекоме, то различий будет предостаточно. В телекоме важны клиенты и их подключения, в ИТ – приложения. И для управления задачами отдела или департамента трекеры не вполне удобны. Для того чтоб разобраться почему, надо более детально рассмотреть соответствующие варианты использования.
Как-то на хабре был опрос – какие фичи issue tracker-а являются для вас ключевыми. В победителях оказалась возможность создавать подзадачи. К этой функции мы еще вернемся. Но для меня, как для руководителя, наиболее важной функцией является интеграция с электронной почтой. Интеграция, заключающаяся не в получении спам-уведомлений о просроченных мною задачах, а наоборот – создание из писем задач. Я – функционер; на работе, дома, на совещании – я сижу и читаю e-mail-ы. Иногда в них попадаются поручения от начальства. И главное чего я хочу — это в один клик делегировать решение этой задачи кому-либо из сотрудников ( GTD – работает =) Раньше, я просто пересылал такие e-mail-ы. Сейчас я завожу тикет и копи-пастом вставляю туда текст сообщения. Это не удобно. А с мобильного телефона, который я читаю на совещаниях, практически не возможно. Намного удобней нажать кнопку «переслать» или сделать из письма задачу, как это предусмотрено в таких толстых решениях как Lotus Notes. Справедливости ради надо сказать, что некоторые трекеры это умеют делать, но есть ряд нюансов:
Во-первых, писем на одну и ту же задачу может прийти несколько и заводить на каждую из них по тикету неразумно. Лучше завести один тикет и всем участникам переписки разослать на него гиперссылку (а так же включить в копию письма ссылку на почтовый адрес тикета, чтоб дальнейшая переписка собиралась в нем автоматически).
Во-вторых, в письмах встречаются присоединенные файлы, которые надо тоже аккуратно вытащить из письма и куда-либо сохранить.
В-третьих, с проектом(группой тикетов) обычно связана группа сотрудников (экспертов по данной теме), которых тоже необходимо вовлечь в обсуждение. Тикет же назначается на конкретного человека или роль.
Вернемся к связанным задачам и подзадачам. Вообще говоря, есть две стратегии обработки issue. Первая заключается в том, чтоб передавать один и тот же issue между участниками. Допустим, решаю я инцидент и понимаю, что мне нужна чья-то помощь. В этом случае я переназначаю инцидент на другого сотрудника, продолжая его отслеживать. Другой подход в том, чтоб создать подзадачу и назначить её на того, чья помощь мне необходима. У каждого подхода есть плюсы и минусы. В первом случае сохраняется общий набор событий, комментариев, присоединенных файлов, но тикет может до бесконечности ходить по исполнителям, да и распараллеливать работы неудобно. Во втором случае теряется общая картинка и становится довольно сложно разобраться, кто и почему ничего не делает (я завел подзадачу и жду её решения). Когда задач становиться много, вводятся правила их автоматического закрытия на основании подчиненных задач и т.п. с трекеры начинают заметно тормозить.
Одним словом, нужен некоторый объект, не совпадающий с проектом, который объединит связанные задачи, контент(письма, файлы), будет иметь единый activity stream, почтовый адрес, группу участников и т.п. Очевидно, что таким объектом является хорошо нам знакомый кейс из дисциплины adaptive case management
Я вот тут начинаю продвигать идею, что должна быть синдикация issues и модель подписки, как в RSS. Ибо письма поэтому и остаются письмами, что в них есть issue из партнерских issue-трекеров — ровно как новости из чужих веб-сайтов. Просто нужно догадаться, как из них сделать ленту. Для этого нужен стандарт: решение не столько в «интеграции с почтой нашего уютного трекера», сколько в понимании, что везде у соседей эти трекеры — до самого горизонта, и не все трекеры наши…
А пока да, транспорт (письма) путаем с содержанием (issue, cases).
C основным же тезисом (про разницу проектов-кейсов-дел-процессов) полностью согласен, сам давно об этом пишу.
Тема, безусловно, актуальная! Даже не только и не столько для трекеров, сколько для всех прочих приложений для управления проектами, программами, инцидентами, запросами (нужное вписать). И все они пишут письма. И что это за письмо — комментарий участника, изменение статуса, обновление контента или isuue, естественно, не понятно.
Атрибутов у писем, практически, нет. Раньше хоть были попытки структурировать поле subject, темой в квадратных скобках, хэштегами. Хотя, конечно, такие атрибуты должны быть в заголовках или в теле в виде microdata.
Другая больная тема — интеграция трекеров: «на ваш входящий с номером X отвечаем нашим исходящим с номером Y…» Состояния разные, переходы разные, справочники разные…., одним словом, безнадега полная.
С удовольствием присоединюсь к обсуждению темы
Как я понял, в OMG прямо сейчас полностью переписывается стандарт ACM (ибо на вход подали сразу аж четыре предложения). Увы, там много умышленно заложенного наследства с другими стандартами OMG — но поглядим, что получится. Ведь это как раз стандартизация метамодели для работ общего случая.
В любом варианте, мы в PraxOS будем пытаться сделать какой-то мэппинг для всех этих разных подходов — а по технологии этот мэппинг должен быть в нейтральное представление. Вот на основе этого нейтрального представления, как результата мэппинга можно будет пробовать сформулировать метамодель «работы как таковой». По минимуму, в этом мэппинге должны поучаствовать «работы» из проектов, процессов, ситуационной инженерии методов (например, OMG SPEM 2), адаптивного управления кейсами и issue trackers (всяческих «управлений изменениями» и «управлений конфигурациями» в том числе).
Я надеялся, что часть проблем будет решена в рамках WS HumanTask http://docs.oasis-open.org/bpel4people/ws-humantask-1.1.html Но что-то победоносного шествия этих идей не наблюдается
Есть тонкие разницы между
— практиками (которые не разворачиваются во времени, они «шаблоны для методов»), процессами (которые «употребляют практики» в их развертке во времени), это изучается в situational method engineering
— документооборотом по поводу дел и собственно делами.
Разные стандарты по-разному утыкиваются в это. Так, в http://activitystrea.ms/ строго про документооборот и tasks («глаголы») как действия приложений, а в OASIS про «практики» главным образом (при этом «методы» они выдают за «сервисы», подразумевающие «обещание» и тем самым ныряя чуть-чуть в communication based описания процессов, но опять-таки неразвёрнуто.
Вот тут у меня чуть-чуть про это пытается рассуждать в комментах kom2006 — http://ailev.livejournal.com/969870.html
Я поглядел еще чуть-чуть: там ведь не для победоносного шествия идеи были, а для конкретных продуктов. Продукты авторов вполне есть: http://www.activevos.com/products
Приведенный в конце поста тезис, выглядит по меньшей мере странным, поскольку описываемые (по сути) составляющие части проектной деятельности называть понятием «проект» не хочется.
Обычно деятельность организации делят на проектную (отражающую новизну) и операционную (отражающую оформленный процесс), в этом смысле любой кейс скорее ближе к проектной деятельности, поскольку трудно запланировать ход его решения заранее.
Вряд ли стоит ожидать инструмента, который позволит автоматизировать всевозможные разнообразия активностей и взаимодействий, отчасти поэтому трекеры и развиты больше, поскольку поддерживают функции постановки и контроля — наиболее востребованные.
Что до удобства и возможностей современных трекеров, то описанные проблемы они уже давно и успешно решают:
* для FogBugz ключевая фича — создание задач из писем, скорее даже полное размытие между почтовым клиентом и трекером историй/задач.
* Watchers — фича многих трекеров, позволяющая нескольким участникам быть «в теме» о происходящем.
* Связи между тикетами и задачами, а также их общий контекст (обсуждения, файлы, история изменений) реализованы в каждом втором трекере.
* Многие трекеры поддерживают «мультипроектность», например в виде иерархии проектов.
Скорее всего проблема не в трекерах или их «философии», а в отсутствии совсем уж готового решения для управления «быстрыми проектами», инициация которых начинается по письму руководителя, а до финала доводится ответственным исполнителем с вовлечением группы экспертов, обильными коммуникациями и простыми средствами контроля.
Почему-то, вспомнились feature team из Agile: «A feature team is a small, dynamically formed team that develops a small activity»
Похоже, я всех запутал =) Я всего лишь хотел сказать, что 1) кейс не надо называть проектом, потому что понятие «проект» и так перегружено, а территория управления проектами давно оккупирована проектными менеджерами со своими взглядами на ИТ системы. Кроме того, кейс может быть проектом, минипроектом, задачей, в может быть продуктом, клиентом, услугой и т.д.. 2) С другой стороны, потоки сообщений, контент, рабочую группу лучше привязывать не к конкретной задаче, как это сейчас делается в трекерах, а именно к кейсу
Господа, не ссортесь ))
Ответ на этот вопрос давно найден 🙂
Начнем с того, что давайте договоримся, что Кейс, Проект, Задача или Операция — это суть одно и тоже.
Это экземпляры классов, таких сущностей как Процесс или Процедура.
Давайте, для обобщения назоваем это Действия, а большое количество действий одной категории назовем Деятельностью.
Так вот, Д. Майстер в книге Управление фирмой оказывающей профессиональные услуги, определил что бывает 3 типа деятельности, различных по своей природе. Мозги, Седина и Процедуры.
Проектный тип управления свойственен Мозгам и Седине. Лучше всего к мозгам. Для Седины тоже полезен. Для Процедур — слишком избыточен.
ЭйСиЭм в понятии Иссуи лучше подходит для Процедр, терпимо для Седины, но Мозгами управлять уже сложно, т.к. там нужно учитывать принцип иерархии мышления ВИСИ http://itau.ru/2011/05/03/budte-visi-ili-mece-principe/
А ВИСИ и ЭйСиЭм — это противоположности.
Далее, контекст Кейса как объединение Проектов — это ИМХО — заблуждение.
Другое дело, что в рамках одного Кейса — может создаваться множество Дочерних. Особенно если это кейс уровня Мозги или Сложные проекты. Такие кейсы как правило рождают сотник и тысяи кейсов уровня Процедуры. Начиная от инцидентов, заканчивая отправкой писем, приемом и увольнением сотрудников.
Касательно идеи: Передачи Кейса или Почкования Кейса — я нашел простой признак. Если кейс в одной процедуре и по одной ситуации — то Передача.
Если кейс для решения требует иных процедур/компетенций то Почкование.
Пример: вот сбойй в системе ЭДО, открылся кейс по процедуре Инцидент в ИТ, начал разбор и понял что причина не в ИТ, а в Процессе. И решить можно только через руководство. Сменил тип кейса на Отклонение СМК и передал руководителю. Пусть улучшают Процесс. ИТ не при чем. т.е. это Движение одного Кейса из процедуры А в процедуру Б.
А вот кейс Увольнение сотрудника. Он уже почканет от себя кейс в ИТ на удаление пользователя из ИС и передачу материалов в части ОС. И т д
Один кейс службы кадров родит кейсы для ИТ и для бухгалтерии.
А бывает так, что малые кейсы по процедурам, рождают большие кейсы типа проекты. Например кейс-процедура типа жалоба клиента на сайт, может родить или мутировать в кейс-проект «Создание функции ХХХ для сайта ууу.пп»
Остановлюсь подробней на Мозгах, Седине и Процедурах.
Мозги — это большие кейсы, с высокой степенью не определенности, отсутствием готовых инструкций по решению. Тут нужно много аналитики, исследования, риски, планирование ресурсов и т д. Пример: разработка и реализация стратегии, внерение или разработка ИС …Опыт, инструкции и технология играют меньшую роль, нужно много соображать и придумывать ходы.
Седина — это большие или средние кейсы, со средней степенью не определенности, более или менее проработанной технологие. Порядок действий в целом понятен. Думать нужно меньше, а вот опыт уже играет большую роль. Примеры: органиация форума, проведение маассового мероприятия и т д
Процедуры — тут просто, есть ситуация, нужно сделать по инструкции. Думать нужно меньше, опыт тоже играет меньшую роль. Выше уровень технологичности, есть инструкции и их нужно соблюдать как отче наш. Это как раз Инциденты в ИТ, прием сотрудника на работу, и т д
Передам нашему руководителю проектного офиса. Он давно уже хочет услышать от меня классификацию проектов =)
Причем во всех 3-х случаях, операции мы можем назвать кейсом, задачей или проектом исходя из ситуации и личных симпатий )
Например для дизайнерской студии — разработка баннера может быть Процедурой и называться Задачей. А для какой нибудь конторы, которая не хочет заказывать это по какой либо причине, это будет Проектом типа Мозги, потому что придется попатеть.
Продукты есть, даже у IBM и Oracle. Правда для версии 1.0. Я писал про эту спеку http://wp.me/pRljZ-fo и о том, что HumanTask, не смотря на это, обойден вниманием заказчиков.
Про activitystrea.ms забросил пока в backlog, на подумать =)
>>должна быть синдикация issues и модель подписки, как в RSS
>>Заинтересовался кейсом — подписался на него
Во как, а если не заинтересовался — не подписался, да?
Кейсы — это, в грубом приближении, совокупности работ, задач, поручений, с функционалом, несколько кореллирующим, конечно, с форумами и блогами в Сети, где такая подписка имеет смысл, но все же имеющим кардинальные отличия в ролях участников.
Не «подпишешься» на поручение начальника — будешь уволен. Поэтому «подписка» в кейсах, если и имеет смысл, то не для основного функционала, а как опция для необязательных информационных сообщений
>>Но для меня, как для руководителя, наиболее важной функцией является интеграция с электронной почтой. Интеграция, заключающаяся не в получении спам-уведомлений о просроченных мною задачах, а наоборот – создание из писем задач
Да, важная функция, но мало где толком реализованная. К тому же, такую интеграцию приходится делать для каждого почтового клиента. У вас, по-видимому, в качестве почтового клиента все тот же Lotus Notes, давно еще Андреем Кузнецовым привнесенный вместе с документооборотом, или и другие используются? Как раз сейчас выясняю, для каких почтовых клиентов такую функцию в первую очередь делать. Базовую версию, очевидно, для MS Outlook
>трекеры предназначены для отслеживания локальных задач и не позволяют осуществлять планирование
Зато трекеры лучше всего подходят для оперативного управления (тех самых локальных задач, из которых и состоит глобальный проект), а вес этого критерия на порядок больше возможности «стратегического планирования» в MSP. Никакой софт не поможет управлять (а только их отслеживать) сроками глобальных строительных или ИТ-проектов, 100% которых не исполняются вовремя. Например, для управления строительством стадионов для ЕВРО-2012 на Украине и Олимпиады 2014 в Сочи используется СЭД, а не системы управления проектами — способность обрабатывать и согласовывать в электронном виде кучи документов оказывается важнее, чем способность строить далекие от реальности диаграммы Ганта
Максим, ваша идея о ACM и WordPress не дала мне покоя.
Я начал работы над этой системой.
Описание тут http://itau.ru/aria-acms/
Альфа-демо версия тут http://itau.ru/acms/cases
Буду благодарен за отзыв и любые идеи 🙂
Выглядит очень здорово! Надо еще посмотреть, помедитировать, но то что уже сделано не выглядит чем-то «кустарным». Отличный опыт
Мне вроде как совсем чуть чуть осталось там допилить до состояния бетта версии 🙂 Примете участие в опробации? 🙂
Хочу похвастаться 2-мя фишками, которых не заметил в аналогах:
1. Система обладает искуственным интелектом и на основании похожих слов подбирает аналогичные кейсы http://itau.ru/acms/120
Это может быть полезно в процедуре управления инцидентами, служб ИТ. Когда бывает что один инцидент решил один специалист, а потом возник похожий инцидент, но назначен другому, а тот снова тратит время на поиск решения. Тут же этот риск минимизируется за счет этой функции. И она уже работает 🙂
2. А вот постановка задач через электропочту, в планах на следующую версию:. Описание схемы тут http://itau.ru/acms/255
п. 1 — это не описание а пример. Там внизу система вывела похожую запись 🙂
казалось бы, постановка задач через отправку письма такая простая процедура, а только сейчас изобретается. странно как-то.