Вчера устроил небольшой флем на фейсбуке ссылкой на статью Почему Microsoft Project нельзя использовать для управления проектами Статья примечательна тем, что собрала множество комментариев как от людей, использующих трекеры задач, так и от «настоящих проектных менеджеров» трекеры не использующих. Их аргументы звучат примерно так: трекеры это только для ИТ-проектов, трекеры это для управления продуктами (вероятно, речь о PLM), трекеры предназначены для отслеживания локальных задач и не позволяют осуществлять планирование и т.д.
В общем, все эти аргументы, в какой-то мере, правильные. Понятие проекта в трекерах это не совсем проект. Несмотря на схожесть таких видов деятельность как управление проектом, развитие продукта, устранение дефектов и управление инцидентами в них довольно много различий. Даже если мы сравним управление инцидентами в ИТ с управлением инцидентами в телекоме, то различий будет предостаточно. В телекоме важны клиенты и их подключения, в ИТ – приложения. И для управления задачами отдела или департамента трекеры не вполне удобны. Для того чтоб разобраться почему, надо более детально рассмотреть соответствующие варианты использования.
Как-то на хабре был опрос – какие фичи issue tracker-а являются для вас ключевыми. В победителях оказалась возможность создавать подзадачи. К этой функции мы еще вернемся. Но для меня, как для руководителя, наиболее важной функцией является интеграция с электронной почтой. Интеграция, заключающаяся не в получении спам-уведомлений о просроченных мною задачах, а наоборот – создание из писем задач. Я – функционер; на работе, дома, на совещании – я сижу и читаю e-mail-ы. Иногда в них попадаются поручения от начальства. И главное чего я хочу — это в один клик делегировать решение этой задачи кому-либо из сотрудников ( GTD – работает =) Раньше, я просто пересылал такие e-mail-ы. Сейчас я завожу тикет и копи-пастом вставляю туда текст сообщения. Это не удобно. А с мобильного телефона, который я читаю на совещаниях, практически не возможно. Намного удобней нажать кнопку «переслать» или сделать из письма задачу, как это предусмотрено в таких толстых решениях как Lotus Notes. Справедливости ради надо сказать, что некоторые трекеры это умеют делать, но есть ряд нюансов:
Во-первых, писем на одну и ту же задачу может прийти несколько и заводить на каждую из них по тикету неразумно. Лучше завести один тикет и всем участникам переписки разослать на него гиперссылку (а так же включить в копию письма ссылку на почтовый адрес тикета, чтоб дальнейшая переписка собиралась в нем автоматически).
Во-вторых, в письмах встречаются присоединенные файлы, которые надо тоже аккуратно вытащить из письма и куда-либо сохранить.
В-третьих, с проектом(группой тикетов) обычно связана группа сотрудников (экспертов по данной теме), которых тоже необходимо вовлечь в обсуждение. Тикет же назначается на конкретного человека или роль.
Вернемся к связанным задачам и подзадачам. Вообще говоря, есть две стратегии обработки issue. Первая заключается в том, чтоб передавать один и тот же issue между участниками. Допустим, решаю я инцидент и понимаю, что мне нужна чья-то помощь. В этом случае я переназначаю инцидент на другого сотрудника, продолжая его отслеживать. Другой подход в том, чтоб создать подзадачу и назначить её на того, чья помощь мне необходима. У каждого подхода есть плюсы и минусы. В первом случае сохраняется общий набор событий, комментариев, присоединенных файлов, но тикет может до бесконечности ходить по исполнителям, да и распараллеливать работы неудобно. Во втором случае теряется общая картинка и становится довольно сложно разобраться, кто и почему ничего не делает (я завел подзадачу и жду её решения). Когда задач становиться много, вводятся правила их автоматического закрытия на основании подчиненных задач и т.п. с трекеры начинают заметно тормозить.
Одним словом, нужен некоторый объект, не совпадающий с проектом, который объединит связанные задачи, контент(письма, файлы), будет иметь единый activity stream, почтовый адрес, группу участников и т.п. Очевидно, что таким объектом является хорошо нам знакомый кейс из дисциплины adaptive case management