Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
отличная статья.
а микрософту - опять выговор за сырой софт и за монополистские замашки.
а микрософту - опять выговор за сырой софт и за монополистские замашки.
ничего отличного...
единственное с чем я согласен, это то, что проекты могут получиться громоздкими и с ними становится тяжело работать, больше эта статья ни о чем не говорит...
единственное с чем я согласен, это то, что проекты могут получиться громоздкими и с ними становится тяжело работать, больше эта статья ни о чем не говорит...
У тому же автор предложил в качестве альтернатив только Excel и необходимость искать систему самостоятельно. В первом случае нужно будет делать слишком много дополнительных действий. Особенно если проект длится дольше недели.
Есть ли система принципиально позволяющая вести сложные проекты (не только по разработке ПО) легко и удобно при любом количестве задач? Желательно с примерами, а не абстрактно - "не тормозит".
Есть ли система принципиально позволяющая вести сложные проекты (не только по разработке ПО) легко и удобно при любом количестве задач? Желательно с примерами, а не абстрактно - "не тормозит".
У тому же автор предложил в качестве альтернатив только Excel и необходимость искать систему самостоятельно.
Замечу, что в конце текста автор сослался на несколько своих статей по этой теме. Цитирую:
Моя статья про один из лучший инструментов Issue Tracking на данный момент “Trac - швейцарский нож среди инструментов управления проектом”
Только вот аргументы какие-то странные порой:
«Лично не проверял, но могу предположить, что с Project’ом ситуация будет похожей.»
Это как «Я Пастернака не читал, но осуждаю». Автор говорит про одну программу и переносит ее недостатки на другую, так можно опуститься до аргументации «микрософт сакс».
«Project рассчитан на меньшее количество задач, чем вам нужно. Средний документ, вероятно, содержит меньше ста задач.»
Почему же в «среднем документе» менее 100 задач? Наверное, не потому, что Project такой нехороший, а потому что пользователи просто не заводили больше. Потому что это _им_ не нужно было.
«В разработке софта задача, выполненная на 80% - не выполнена!»
Если дом построен на 80% или пациент прооперирован на 80%, то тоже не выполнена. Не Project тут виноват. Коли мыслить бинарно, пользуйте только значения 0% и 100%.
«В issue-tracking’е вы можете использовать wontfix. А в Project?»
А в Фотошопе я могу размытие по Гауссу сделать, а в Проджекте никак. Project это не issue tracking!!!
«Лично не проверял, но могу предположить, что с Project’ом ситуация будет похожей.»
Это как «Я Пастернака не читал, но осуждаю». Автор говорит про одну программу и переносит ее недостатки на другую, так можно опуститься до аргументации «микрософт сакс».
«Project рассчитан на меньшее количество задач, чем вам нужно. Средний документ, вероятно, содержит меньше ста задач.»
Почему же в «среднем документе» менее 100 задач? Наверное, не потому, что Project такой нехороший, а потому что пользователи просто не заводили больше. Потому что это _им_ не нужно было.
«В разработке софта задача, выполненная на 80% - не выполнена!»
Если дом построен на 80% или пациент прооперирован на 80%, то тоже не выполнена. Не Project тут виноват. Коли мыслить бинарно, пользуйте только значения 0% и 100%.
«В issue-tracking’е вы можете использовать wontfix. А в Project?»
А в Фотошопе я могу размытие по Гауссу сделать, а в Проджекте никак. Project это не issue tracking!!!
Фразу "нельзя использовать для управления проектами" следует читать как "нельзя использовать для управления разработкой ПО" ?
Видимо так. Кстати, спасибо 
Uznick за корректный заголовок.
Uznick за корректный заголовок.
А я боссу, как раз предлагал начать использовать project. Видимо, зря.
Для меня статья достаточно актуальна. В своё время нам нужно было создать систему, которая могла бы помочь в распределении задач. Попробовав всякие сложные программы типа MS Project и ClearQuest, а также некоторые российские продукты. Мы в итоге пошли от простого и взяли за основу своей системы бесплатную Mantis, немного доработали её напильником и она теперь вполне удачно используются. Система не так уж наворочена, но задачи вроде: заведения проектов/подпроектов, задач, их решение, статистика и отчёты, проставление сроков (это мы дописали сами) вполне выполняет.
Из плюсов:
- лёгкость установки
- локализована на русский (средне, немного правили перевод)
- работает в броузере в любой системе
- лекго дописывать и улучшать
Из минусов:
- сложный, непродуманный и малоэффективный контроль доступа
- невозможность некоторых настроек
- неуникальность
- необходимость иметь майл-сервер, даже для получения паролей новых юзеров (в нашей корпоративной сетке такого не было, что легко решилось подпиливанием функции отправки писем).
Из плюсов:
- лёгкость установки
- локализована на русский (средне, немного правили перевод)
- работает в броузере в любой системе
- лекго дописывать и улучшать
Из минусов:
- сложный, непродуманный и малоэффективный контроль доступа
- невозможность некоторых настроек
- неуникальность
- необходимость иметь майл-сервер, даже для получения паролей новых юзеров (в нашей корпоративной сетке такого не было, что легко решилось подпиливанием функции отправки писем).
Хм... собственно хотелось бы узнать какие есть альтернативы. Например чтобы можно было начать использование системы в кач-ве баг трекера, а затем расширяя возможность к управлению базов клиентов и пр.
Мы используем Мантис и PHProjekt. Первый для работы над задачами и обмена информацией, второй для контроля времени.
Не сколько ни защищая микрософт. Цитаты и комментарии.
«Project рассчитан на меньшее количество задач, чем вам нужно». Доказательство оставляет желать лучшего. На сколько я понимаю – внутренности Project'а суть БД, а на примере того же Access'а мы можем наблюдать достаточно надежную настольную БД. И вообще автор пытается взвалить на Project функции багтреккинга, для чего он слабо предназначен.
«Project позволит вам случайно поменять ID задачи». Не очень понял о каком ID говорит автор – как такового ID в Project не припомню. А вообще он позволяет удалять задачу, ай-яй... Наверное думать надо прежде чем что-то делаешь, а не списывать на случайности.
«Надо что-то делать с жизненным циклом задачи». Надо – делаем. Например, добавляем новые подзадачи. В чем проблема – не совсем понятно. Если мы хотим спланировать работу по каждому из исполнителей (один уровень детализации) – добавляем отдельные подзадачи.
«Исполнители взаимозаменяемы». Да, а производительность, о которой страдает автор, отражаем в % доступности ресурса. При этом если мы поменяем исполнителя Project автоматически предложит нам пропорционально увеличить (уменьшить) длительность задачи. Согласен, не самый красивый способ, но у большинства других виденных мною систем даже такой возможности не существует.
«Поэтому здравомыслящий менеджер использует бинарную систему оценки готовности: готово - не готово. Всякие проценты - это, как правило, мишура, отвлекающая от более важных вещей.». Автору срочно перечитать «Вальсируя с медведями».
«половину информации о проекте удастся внести в Project, вторую половину придется держать в голове». Не встречал ни одной системы управления проектами, которая полностью удовлетворяет потребностям разработчика. Тот же Trac, так активно продвигаемый автором, имеет свои недостатки, прежде всего связанные с тем, что его прародителем явно являлась система багтреккинга – достаточно развитый функционал по работе над каждой конкретной задачей, при этом крайне бедный timelin. Если для рядового разработчика вполне хватает существующего функционала, то уже для лидера группы (не говоря уже о проджекте) функционала крайне не хватает.
Теперь о плюсах Project'а. Сам по себе он не имеет всего спектра необходимых инструментов для решения всех задач. Но не даром в названии присутствует слово «Office». Этот продукт интегрируется с другими, что дает возможность построить мощную систему. MS SPS и Project Server дают работать с рисками проекта. Вы много знаете систем управления проектами в области разработки ПО в которые интегрирована возможность управления рисками?
Подведя краткие итоги – каждый инструмент хорош в чем-то своем, у каждого есть свои плюсы и минусы. Каждый предназначен для своего круга задач.
«Project рассчитан на меньшее количество задач, чем вам нужно». Доказательство оставляет желать лучшего. На сколько я понимаю – внутренности Project'а суть БД, а на примере того же Access'а мы можем наблюдать достаточно надежную настольную БД. И вообще автор пытается взвалить на Project функции багтреккинга, для чего он слабо предназначен.
«Project позволит вам случайно поменять ID задачи». Не очень понял о каком ID говорит автор – как такового ID в Project не припомню. А вообще он позволяет удалять задачу, ай-яй... Наверное думать надо прежде чем что-то делаешь, а не списывать на случайности.
«Надо что-то делать с жизненным циклом задачи». Надо – делаем. Например, добавляем новые подзадачи. В чем проблема – не совсем понятно. Если мы хотим спланировать работу по каждому из исполнителей (один уровень детализации) – добавляем отдельные подзадачи.
«Исполнители взаимозаменяемы». Да, а производительность, о которой страдает автор, отражаем в % доступности ресурса. При этом если мы поменяем исполнителя Project автоматически предложит нам пропорционально увеличить (уменьшить) длительность задачи. Согласен, не самый красивый способ, но у большинства других виденных мною систем даже такой возможности не существует.
«Поэтому здравомыслящий менеджер использует бинарную систему оценки готовности: готово - не готово. Всякие проценты - это, как правило, мишура, отвлекающая от более важных вещей.». Автору срочно перечитать «Вальсируя с медведями».
«половину информации о проекте удастся внести в Project, вторую половину придется держать в голове». Не встречал ни одной системы управления проектами, которая полностью удовлетворяет потребностям разработчика. Тот же Trac, так активно продвигаемый автором, имеет свои недостатки, прежде всего связанные с тем, что его прародителем явно являлась система багтреккинга – достаточно развитый функционал по работе над каждой конкретной задачей, при этом крайне бедный timelin. Если для рядового разработчика вполне хватает существующего функционала, то уже для лидера группы (не говоря уже о проджекте) функционала крайне не хватает.
Теперь о плюсах Project'а. Сам по себе он не имеет всего спектра необходимых инструментов для решения всех задач. Но не даром в названии присутствует слово «Office». Этот продукт интегрируется с другими, что дает возможность построить мощную систему. MS SPS и Project Server дают работать с рисками проекта. Вы много знаете систем управления проектами в области разработки ПО в которые интегрирована возможность управления рисками?
Подведя краткие итоги – каждый инструмент хорош в чем-то своем, у каждого есть свои плюсы и минусы. Каждый предназначен для своего круга задач.
есть же jira. чем не подходит для управления проектами по разработке ПО?
Читали вот этот блог, от разработчиков confluence ?
http://fishbowl.pastiche.org/2005/09/28/…
Если коротко, там описывается как они используют jira для разработки confluence:
====
1) При подготовке к выпуску очередной версии они печатают все интересные баги.
2) Потом девелоперы разбирают эти бумажки, читают их и пишут каким-нибудь ярким фломастером сколько времени может занять исправление баги.
3) Опять смотрят и перебирают бумажки, может что-то нужно исправить в оценках ?
4) Находят кусок стены и вешают туда эти бумажки (фотка стены прилагается). Причем вешают не просто так, а группируют по функциональности.
5) А теперь работаем:
- девелопер снимает бумажку со стены и работает с этой задачей.
- девелопер не должен работать ни с чем, чего нет на стене.
- если появилась какая-то непредусмотренная задача, то ее нужно сначала внести в jira, распечатать, повесить на стену.
- когда с задачей закончили, девелопер складывает ее в отдельное место и пишет сколько на самом деле времени у него на задачу ушло.
===
Отзывы как все круто и насколько это прогрессивная методика поскипаны :-)
Если такое количество работы по управлению проектами (назначение ответственных, оценка сроков, оценка состояния проекта и т.п.) проходит мимо jira, значит там что-то с этим нечисто :-)
ИМХО в данном проекте JIRA выступает как CRM, т.е. с клиентов собираются требования, все управление проектом идет "на бумажках", а потом в JIRA клиентам сообщается что сделано, а что нет. Это очень хорошо видно по их hosted-системе - там баги обычно закрываются массово прямо перед релизом или через несколько дней после, это верный признак что туда данные просто переносятся из какого-то другого источника информации. Теперь понятно из какого :-)
http://fishbowl.pastiche.org/2005/09/28/…
Если коротко, там описывается как они используют jira для разработки confluence:
====
1) При подготовке к выпуску очередной версии они печатают все интересные баги.
2) Потом девелоперы разбирают эти бумажки, читают их и пишут каким-нибудь ярким фломастером сколько времени может занять исправление баги.
3) Опять смотрят и перебирают бумажки, может что-то нужно исправить в оценках ?
4) Находят кусок стены и вешают туда эти бумажки (фотка стены прилагается). Причем вешают не просто так, а группируют по функциональности.
5) А теперь работаем:
- девелопер снимает бумажку со стены и работает с этой задачей.
- девелопер не должен работать ни с чем, чего нет на стене.
- если появилась какая-то непредусмотренная задача, то ее нужно сначала внести в jira, распечатать, повесить на стену.
- когда с задачей закончили, девелопер складывает ее в отдельное место и пишет сколько на самом деле времени у него на задачу ушло.
===
Отзывы как все круто и насколько это прогрессивная методика поскипаны :-)
Если такое количество работы по управлению проектами (назначение ответственных, оценка сроков, оценка состояния проекта и т.п.) проходит мимо jira, значит там что-то с этим нечисто :-)
ИМХО в данном проекте JIRA выступает как CRM, т.е. с клиентов собираются требования, все управление проектом идет "на бумажках", а потом в JIRA клиентам сообщается что сделано, а что нет. Это очень хорошо видно по их hosted-системе - там баги обычно закрываются массово прямо перед релизом или через несколько дней после, это верный признак что туда данные просто переносятся из какого-то другого источника информации. Теперь понятно из какого :-)
Спасибо всем за комментарии.
Я добавил в текст небольшой обзор issue tracking систем, которые можно использовать в качестве своей первой системы такого рода
Я добавил в текст небольшой обзор issue tracking систем, которые можно использовать в качестве своей первой системы такого рода
«Project позволит вам случайно поменять ID задачи». Не очень понял о каком ID говорит автор – как такового ID в Project не припомню. А вообще он позволяет удалять задачу, ай-яй... Наверное думать надо прежде чем что-то делаешь, а не списывать на случайности.
«Надо что-то делать с жизненным циклом задачи». Надо – делаем. Например, добавляем новые подзадачи. В чем проблема – не совсем понятно. Если мы хотим спланировать работу по каждому из исполнителей (один уровень детализации) – добавляем отдельные подзадачи.
Насколько я понял, мы оба при обсуждении этих пукнтов подходим к Project как к хранилищу информации. Мои претензии сводятся к тому, что Project - плохое хранилищу информации, потому что не соответствует нескольким базовым требованиям. А именно:
- Один из базовых принципов хранения информации состоит в том, что информация не должна удаляться безвозвратно. То что в большинстве систем учета чего бы то ни было вместо физического удаления записи используется поле `deleted` - пример реализации этого принципа. Я не знаю аналогичного механизма в project'е
- Данные должны быть структурированы. Project плохо справляется со структурированием информации о задачах в области разработки ПО, что и ведет к необходимости эмулировать статус через подзадачи и другим подобным фокусам. Напомню, что основная проблема неструктурированных данных не к том что их неудобно вносить или читать, а в том, что по ним практически невозможно построить отчет или сделать поиск. Между тем, повседневная работа со сколько-нибудь большой базой задач заставляет каждого участника проекта пользоваться поиском по многу раз в день.
Нет, не совсем правильно поняли. Project я рассматриваю как средство планирования, оценки и контроля проекта. Поэтому хранить данные, которые мне не нужны внутри Project'а мне нет нужы. Впрочем, как и хранить там вообще какие-то расширенные данные (тексты, например).
А какой статус нужно эмулировать? Лично для меня - разбиение на мелкие подзадачи является большим плюсом. Отчеты же в Project'е достаточно развиты, в отличии от многих других систем - можно получить практически любое представление. С чем я не буду спорить - совместная работа несколько затруднена и построена не совсем так, как лично мне было бы удобнее. Но повторюсь - пока не встретил ни одной системы, которая полностью меня бы удовлетворяла. Скорее всего это приведет к тому, что рано или поздно, но будет самостоятельно разработан принципиально другой инструмент, в который будет заложена принципиально иная идеалогия. Ибо, как уже писал, у всех систем, которые пошли от tracking-систем - мало развит функционал собственно управления проектом и задачами, контроля, планирования. А у того же Project'а слабо развит функционал оперативного управления проектом. В частности об этой проблеме говорит тот факт, что очень многие, отметившиеся в комментариях, используют 2 системы.
А какой статус нужно эмулировать? Лично для меня - разбиение на мелкие подзадачи является большим плюсом. Отчеты же в Project'е достаточно развиты, в отличии от многих других систем - можно получить практически любое представление. С чем я не буду спорить - совместная работа несколько затруднена и построена не совсем так, как лично мне было бы удобнее. Но повторюсь - пока не встретил ни одной системы, которая полностью меня бы удовлетворяла. Скорее всего это приведет к тому, что рано или поздно, но будет самостоятельно разработан принципиально другой инструмент, в который будет заложена принципиально иная идеалогия. Ибо, как уже писал, у всех систем, которые пошли от tracking-систем - мало развит функционал собственно управления проектом и задачами, контроля, планирования. А у того же Project'а слабо развит функционал оперативного управления проектом. В частности об этой проблеме говорит тот факт, что очень многие, отметившиеся в комментариях, используют 2 системы.
Кстати да. Кое-где ПМ-ы работают и отчитываются с помощью M$ проджекта, а программерам задания выдают в чем попало, а то и вообще как придется, бессистемно.
По поводу статуса - разные люди работают с задачей на разных этапах. Кто-то вносит новую задачу, менеджер или дев лид назначают приоритет и исполнителя, разработчик реализует, тестировщик проверяет и т.д. Каждому нужно, в идеале, видеть только те задачи, которые _сейчас_ требуют его участия. Именно это и достигается с помощью статуса (new, assigned, implemented, verified) и фильтрации по оному. В общем, типичный workflow.
Да, можно хранить данные в двух системах. Но я пока не видел на практике ни одного нормального способа синхронизации, а иметь рассогласованные данные - небольшое удовольствие. Лично я предпочитаю единую систему, пусть и несколько менее функциональную чем сумма двух других.
Как вариант - можно импортировать данные из Issue Tracking в Project и использовать его только для мониторинга и отчетов. Такое использование Project'а выглядит вполне осмысленным.
Согласен, что в качестве отчетника Project хорош.
Да, можно хранить данные в двух системах. Но я пока не видел на практике ни одного нормального способа синхронизации, а иметь рассогласованные данные - небольшое удовольствие. Лично я предпочитаю единую систему, пусть и несколько менее функциональную чем сумма двух других.
Как вариант - можно импортировать данные из Issue Tracking в Project и использовать его только для мониторинга и отчетов. Такое использование Project'а выглядит вполне осмысленным.
Согласен, что в качестве отчетника Project хорош.
Согласитесь, статус при таком использовании, выглядит как костыли. Объясню почему. Если я не проджект, то статус как таковой меня мало интересует. Я поставил задачу, меня интересует лишь когда она будет выполнена, если при этом мне предоставят дату выполнения с учетом рисков (это скорее для клиента) - будет вообще супер. Если я проджект (или рук.группы) то для меня должно существовать только три статуса у задачи - еще не принятая в работу, которую мне прислал другой участник разработки; выполняемая (стоящая у меня на контроле); и уже выполненная (собственно она нужна только для составления отчета по начальной поставленной задаче и для статистики).
Вообще говоря, любой участник процесса разработки должен очень просто получать доступ к 2м спискам задач - те, что поставили ему ("отчеты наверх"), и те, что поставил он ("контроль передо мной") + возможность наложить филтр по времени - сегодня, наделя, месяц. Весь остальной функционал системы должен строится вокруг этих двух списков. Это "прототип идеальной ситемы управления проектами" :)
Что касается использования двух разных систем (если они не интегрируются) - это потенциальный залет, полностью согласен.
Вообще говоря, любой участник процесса разработки должен очень просто получать доступ к 2м спискам задач - те, что поставили ему ("отчеты наверх"), и те, что поставил он ("контроль передо мной") + возможность наложить филтр по времени - сегодня, наделя, месяц. Весь остальной функционал системы должен строится вокруг этих двух списков. Это "прототип идеальной ситемы управления проектами" :)
Что касается использования двух разных систем (если они не интегрируются) - это потенциальный залет, полностью согласен.
Не соглашусь :)
Вопрос в том, как удобнее представлять этапы выполнения задачи - связанными подзадачами, назначаемыми отдельным людям или одной задачей, передаваемой дальше по цепочке вместе со сменой статуса.
В первом случае информационная модель задачи гораздо сложнее. Подзадача категории "Проверить как Илья реализовал функцию X" не самодостаточна - для проверки нужно знать как эта задача ставилась. Эта информация будет либо дублироваться в нескольких подзадачах, со всеми вытекающими из дублирования данных аномалиями, либо нужно будет смотреть постановку в другом месте: предыдущей задаче, либо родительской задаче. Не уверен, что такое усложнение оправдано.
Вопрос в том, как удобнее представлять этапы выполнения задачи - связанными подзадачами, назначаемыми отдельным людям или одной задачей, передаваемой дальше по цепочке вместе со сменой статуса.
В первом случае информационная модель задачи гораздо сложнее. Подзадача категории "Проверить как Илья реализовал функцию X" не самодостаточна - для проверки нужно знать как эта задача ставилась. Эта информация будет либо дублироваться в нескольких подзадачах, со всеми вытекающими из дублирования данных аномалиями, либо нужно будет смотреть постановку в другом месте: предыдущей задаче, либо родительской задаче. Не уверен, что такое усложнение оправдано.
Набор статусов резко ограничивает гибкость системы. Либо мы должны дать возможность для каждого проекта (а еще лучше - этапа проекта или вообще для каждой задачи) иметь возможность создавать свой набор статусов. Либо строить иерархические зависимости - "задача А распадается на В и С. В, в свою очередь, должна предшествовать С и состоит из В1 и В2, которые могут выполняться одновременно". Это наиболее наглядно раскрывает процесс разработки и позволяет легко строить 2 списка задач, о которых писал выше.
Как всегда, приходится выбирать либо гибкость (подзадачи), либо удобство работы (статусы).
В контексте хорошо технологизированного процесса разработки программных продуктов я предпочитаю удобство работы.
Многие системы issue tracking'а предоставляют возможность настроить свой набор статусов и переходов между ними. Даже если эти настройки общие для всех проектов, то это позволит закрыть более 80% случаев, если, конечно, в организации есть какая-то технология работы. Если нет - то workflow инструменты этой огранизации тоже не нужны
В контексте хорошо технологизированного процесса разработки программных продуктов я предпочитаю удобство работы.
Многие системы issue tracking'а предоставляют возможность настроить свой набор статусов и переходов между ними. Даже если эти настройки общие для всех проектов, то это позволит закрыть более 80% случаев, если, конечно, в организации есть какая-то технология работы. Если нет - то workflow инструменты этой огранизации тоже не нужны
Вы говорите страшные вещи :-)
Подзадачи и статусы можно легко совмещать, пример реализации см. тут
http://www.trackstudio.ru/products.html
Можно и для каждой задачи создавать свой набор статусов, и строить иерархические зависимости между задачами любого вида (внутри проекта может быть версия, но внутри версии проект создавать нельзя), и параллельно/последовательно задачи выполнять.
Подзадачи и статусы можно легко совмещать, пример реализации см. тут
http://www.trackstudio.ru/products.html
Можно и для каждой задачи создавать свой набор статусов, и строить иерархические зависимости между задачами любого вида (внутри проекта может быть версия, но внутри версии проект создавать нельзя), и параллельно/последовательно задачи выполнять.
Господа, alexlebedev и long, мне кажется, вы, MS Project воспринимаете различным образом. long, говорит, что эта система for planning, project tracking and oversight (с чем я согласен), а господин alexlebedev, почему-то воспринимает Project как какую-то CRM систему. Не надо это путать. Project и любая там Bugzilla или ClearQuest, могут и должны совместно существовать. Они приследуют различные цели.
Если вы используете CRM систему для назначения задач - флаг вам в руки. Это очень хорошая практика. Но как вы сможете планировать задачи в СRM системе, я не понимаю.
Если вы используете CRM систему для назначения задач - флаг вам в руки. Это очень хорошая практика. Но как вы сможете планировать задачи в СRM системе, я не понимаю.
как вы сможете планировать задачи в СRM системе, я не понимаю.
золотые слова :)
Не очень понял что вы имеете в виде под CRM.
Для меня терминология выглядит следующим образом:
- Багтреккинг, issue tracking - workflow инструмент, используется всеми участниками проекта для учета багов, проблем, задач и т.п.
- Planning, project tracking - высокоуровневый взгляд на планы и текущее состояние. Используется менеджером, иногда еще и лидами. В идеале данные берутся из системы issue tracking'а, либо это вообще одна и та же система.
- CRM - учет клиентов, их представителей и взаимодействия с ними. В идеале сюда же вносятся все обещания, сделанные заказчику (управление требованиями). Используется только теми, кто общается с заказчиками.
Соответственно, CRM для меня никак не касается темы данного обсуждения.
Для меня терминология выглядит следующим образом:
- Багтреккинг, issue tracking - workflow инструмент, используется всеми участниками проекта для учета багов, проблем, задач и т.п.
- Planning, project tracking - высокоуровневый взгляд на планы и текущее состояние. Используется менеджером, иногда еще и лидами. В идеале данные берутся из системы issue tracking'а, либо это вообще одна и та же система.
- CRM - учет клиентов, их представителей и взаимодействия с ними. В идеале сюда же вносятся все обещания, сделанные заказчику (управление требованиями). Используется только теми, кто общается с заказчиками.
Соответственно, CRM для меня никак не касается темы данного обсуждения.
А системы бегтрекинга намного ближе по своей сути к CRM, чем к системе управления проектом (суть которых планирование процесса разработки и контроль).
для меня CRM включает bug tracking, т.к. изменения могут исходить не только из уст заказчика, но и тестера, разработчика и т.п. Любой валидный баг, по своей сути - это change request, но не каждый change request это баг. Change Request может быть, например, новым требованием или изменением в требованиях.
Я готов поспорить с утверждением: "В идеале данные берутся из системы issue tracking'а..." Мне кажется в идеале все дожно быть с точностью наоборот (хотя проекты бывают разные). После того, как было произведено планирование и составлен план, где проставлены, связи, ресурсы и даты, можно (или даже желательно) завести, для лучшего отслеживания проекта, несколько сиарок, которые будут, каким-нибудь лидом назначены на инженера. Это нужно лишь для удобства. Как уже было замечено ранее, Project не подходит для назначения задач, именно поэтому удобно использовать issue tracking системы. Связь между этими вещами поддерживать очень бы хотелось, но на моей практике, это всегда осуществлялось вручную, каким-нибудь PM-ом. Хотя, существуют различные системы, такие как Borland Star Team и все что туда входит, а так же, если мне не изменяет память, Microsoft далеко продвинулся в этой области и позволяет связывать таски в MS Project аж c кусками кода, но при этом нужно пользоваться Visual Studio и всем остальным от Microsoft. Я видел их презентацию на эту тему в прошлом году, но не могу сказать, насколько им удалось все это реализовать.
Я готов поспорить с утверждением: "В идеале данные берутся из системы issue tracking'а..." Мне кажется в идеале все дожно быть с точностью наоборот (хотя проекты бывают разные). После того, как было произведено планирование и составлен план, где проставлены, связи, ресурсы и даты, можно (или даже желательно) завести, для лучшего отслеживания проекта, несколько сиарок, которые будут, каким-нибудь лидом назначены на инженера. Это нужно лишь для удобства. Как уже было замечено ранее, Project не подходит для назначения задач, именно поэтому удобно использовать issue tracking системы. Связь между этими вещами поддерживать очень бы хотелось, но на моей практике, это всегда осуществлялось вручную, каким-нибудь PM-ом. Хотя, существуют различные системы, такие как Borland Star Team и все что туда входит, а так же, если мне не изменяет память, Microsoft далеко продвинулся в этой области и позволяет связывать таски в MS Project аж c кусками кода, но при этом нужно пользоваться Visual Studio и всем остальным от Microsoft. Я видел их презентацию на эту тему в прошлом году, но не могу сказать, насколько им удалось все это реализовать.
Посмотрел я тут всякие системы, что вы все писали. Но особого качественного скачка не увидел. Возможно я искал не то, что нужно =))
А от связки которую я описывал выше мне, в принципе, не хватает нескольких вещей:
- возможности создавать типичные проекты из готовых шаблонов. например, создав проект для сайта хотелось бы сразу получить набор стандартных задач: составление и обсуждение ТЗ заказчика с менеджерами, предварительный макет, резка макета и т.д.. чтобы к этим задачам только нужно было привязать нужных исполнителей.
- невозможность привязать к одной задаче нескольких исполнителей (в Мантисе, который я использую этого нет, но возможно есть в других ITS)
- кивка в строну CRM, т.е. чтобы можно было вести удобную базу клиентов, посредников, заказчиков ... - всех людей участвующих в процессе, и удобно линковать их с задачами и проектами.
- некоторых более развёрнутых статистических данных о выполняемых задачах. Ну хотя бы диаграмму Ганта. (... хотя это я думаю решить напильником под Мантис)
А вот чего не очень нужно, так это расчёт средств, бухгалтерии, зарплаты и пр. связанное с деньгами. Этим могут заняться и более специализированные программы.
Ничего этого в просмотренных бегло системах я не нашёл. А в сложных системах типа ClearQuest, внедрение такой структуры неоправдано по времени.
А от связки которую я описывал выше мне, в принципе, не хватает нескольких вещей:
- возможности создавать типичные проекты из готовых шаблонов. например, создав проект для сайта хотелось бы сразу получить набор стандартных задач: составление и обсуждение ТЗ заказчика с менеджерами, предварительный макет, резка макета и т.д.. чтобы к этим задачам только нужно было привязать нужных исполнителей.
- невозможность привязать к одной задаче нескольких исполнителей (в Мантисе, который я использую этого нет, но возможно есть в других ITS)
- кивка в строну CRM, т.е. чтобы можно было вести удобную базу клиентов, посредников, заказчиков ... - всех людей участвующих в процессе, и удобно линковать их с задачами и проектами.
- некоторых более развёрнутых статистических данных о выполняемых задачах. Ну хотя бы диаграмму Ганта. (... хотя это я думаю решить напильником под Мантис)
А вот чего не очень нужно, так это расчёт средств, бухгалтерии, зарплаты и пр. связанное с деньгами. Этим могут заняться и более специализированные программы.
Ничего этого в просмотренных бегло системах я не нашёл. А в сложных системах типа ClearQuest, внедрение такой структуры неоправдано по времени.
Посмотри Instant Business Network 4.5 - есть триал версия: http://ibntrial.mediachase.net/?Reseller…
CRM конечно там в зачатке, но макеты проектов есть, портфели есть, гант есть.
CRM конечно там в зачатке, но макеты проектов есть, портфели есть, гант есть.
TaskJuggler спасет отца русской демократии.
К сожалению многих присутствующих, он работает (с GUI) только в *nix.
Для остальных есть GanttProject (джава), dotProject (веб), Planner (есть для виндовс и линукс), Open Workbench (мне лично не нравится, но поклонников - море), и прочая, и прочая. Свет на поделке MS клином не сошелся.
А есть еще немеряно платных решений. А также приблуды, адаптированные к XP.
Дело в умении, а не в софте ;)
К сожалению многих присутствующих, он работает (с GUI) только в *nix.
Для остальных есть GanttProject (джава), dotProject (веб), Planner (есть для виндовс и линукс), Open Workbench (мне лично не нравится, но поклонников - море), и прочая, и прочая. Свет на поделке MS клином не сошелся.
А есть еще немеряно платных решений. А также приблуды, адаптированные к XP.
Дело в умении, а не в софте ;)
проблема только в том, что среди такого огромного количества софта нет того единственного дествительного удобного инструмента управления проектом. :)
А что-то я не видел, чтобы кто-нибудь с сертификатом PMI жаловался на софт.
Все же я думаю, что проблемы не в софте. Вы, к примеру, готовы написать развернутое ТЗ на гениальный софт для PM? Например, я за это дурное дело не возьмусь, потому что поддерживающие (в определенной мере) методологию PMBOK програмы уже давно имеются, а альтернативную методологию можно хоть с помощью вики поддерживать, немного ее доработав.
Все же я думаю, что проблемы не в софте. Вы, к примеру, готовы написать развернутое ТЗ на гениальный софт для PM? Например, я за это дурное дело не возьмусь, потому что поддерживающие (в определенной мере) методологию PMBOK програмы уже давно имеются, а альтернативную методологию можно хоть с помощью вики поддерживать, немного ее доработав.
А я ведь не зря выделил слово "удобное" ;) Приспособиться можно практически под любой софт. Другое дело - удобство работы с ним. Дело конечно субъективное, универсального для всех написать наверное не реально. Но то, что в существующем софте очень четко прослеживаются две тенденции - "похожие" на Project и "продивинутые" бегтрекинг системы - мне кажется не совсем то, что действительно нужно РМ.
Что же, по-Вашему, нужно PM?
Какие цели преследует PM? Как предполагает их добиваться?..
Лично я, - чтобы не быть голословным, - пользовался 80% перечисленного и еще много чем (в т.ч. PPP). В итоге остановились на JSPwiki для планирования и разработки внутренней документации и инструкций, проприетарной системе управления для выдачи и контроля исполнения поручений (задач), и LaTeX для разработки документации на продукт (упоминаю его отдельно, т.к. в вики можно было бы при желании и это делать). А филозофскаго камня действительно нет :)
Какие цели преследует PM? Как предполагает их добиваться?..
Лично я, - чтобы не быть голословным, - пользовался 80% перечисленного и еще много чем (в т.ч. PPP). В итоге остановились на JSPwiki для планирования и разработки внутренней документации и инструкций, проприетарной системе управления для выдачи и контроля исполнения поручений (задач), и LaTeX для разработки документации на продукт (упоминаю его отдельно, т.к. в вики можно было бы при желании и это делать). А филозофскаго камня действительно нет :)
Давно хотел создать, да все времени не хватало, а тут как раз повод - предлагаю обсудить это в новом блоге "Управление проектами"
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Недостатки Microsoft Project