Всем привет!

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

В частности, нужен проектный план. Классический, где большие куски работы, связи между ними, назначенные работники и т.д. Чтобы можно было увидеть, когда что примерно будет готово, и успеваем мы или нет. Для этого хорошо подходит MS Project или OpenProj.

С другой стороны с этим сложно работать обычным разработчикам. Им нужно назначать уже конкретные задачи (иногда небольшие, являющиеся частью большого куска работы) с детальным описанием, что нужно сделать. Поэтому здесь поможет система типа JIRA или Redmine. Где можно назначать тикеты на разработку некоего конкретного функционала с подробным описанием.

В то же время, JIRA/Redmine не позволят создать классический план работ. Например, если разработчику Иванову была назначена разработка модуля А, после чего есть еще ряд работ, назначенных на него, то при изменения даты конца разработки модуля А в MS Project достаточно руками поменять конечную дату, и остальные работы Иванова сдвинутся. А в JIRA нужно руками проставлять все изменившиеся даты. Другими словами, JIRA не может отслеживать загрузку и выравнивание ресурсов.

Так вот, выходит так, что нужны две системы. Так как ни одна из них не решает всего спектра задач. Вот и выходит, что каждое новое требование, нужно вносить как в MS Project, так и в JIRA. И все изменения в требованиях также отражать сразу на двух системах.

Я поражаюсь, что до сих пор приходится так делать. Неужели ничего не придумали для избежания такого?? Или я чего-то не знаю?

Неужели нельзя избежать дублирования работы???

Здравствуйте, stranger_v, Вы писали:

_>в MS Project достаточно руками поменять конечную дату, и остальные работы Иванова сдвинутся. А в JIRA нужно руками проставлять все изменившиеся даты. Другими словами, JIRA не может отслеживать загрузку и выравнивание ресурсов.

Project более подходит для проектов по копанию траншей. Где «могу копать. могу не копать.» и все работники взаимозаменяемы.

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

Здравствуйте, stranger_v, Вы писали:

_>Вот, запустил свой бизнес по созданию интернет порталов. Не могу понять, как эффективно построить управление проектом.
А сколько суммарно людей в проектах и сколько одновременных проектов?

Здравствуйте, stranger_v, Вы писали:

_>Всем привет!

_>Вот, запустил свой бизнес по созданию интернет порталов. Не могу понять, как эффективно построить управление проектом.

_>В частности, нужен проектный план. Классический, где большие куски работы, связи между ними, назначенные работники и т.д. Чтобы можно было увидеть, когда что примерно будет готово, и успеваем мы или нет. Для этого хорошо подходит MS Project или OpenProj.

_>С другой стороны с этим сложно работать обычным разработчикам. Им нужно назначать уже конкретные задачи (иногда небольшие, являющиеся частью большого куска работы) с детальным описанием, что нужно сделать. Поэтому здесь поможет система типа JIRA или Redmine. Где можно назначать тикеты на разработку некоего конкретного функционала с подробным описанием.

_>В то же время, JIRA/Redmine не позволят создать классический план работ. Например, если разработчику Иванову была назначена разработка модуля А, после чего есть еще ряд работ, назначенных на него, то при изменения даты конца разработки модуля А в MS Project достаточно руками поменять конечную дату, и остальные работы Иванова сдвинутся. А в JIRA нужно руками проставлять все изменившиеся даты. Другими словами, JIRA не может отслеживать загрузку и выравнивание ресурсов.

_>Так вот, выходит так, что нужны две системы. Так как ни одна из них не решает всего спектра задач. Вот и выходит, что каждое новое требование, нужно вносить как в MS Project, так и в JIRA. И все изменения в требованиях также отражать сразу на двух системах.

_>Я поражаюсь, что до сих пор приходится так делать. Неужели ничего не придумали для избежания такого?? Или я чего-то не знаю?

_>Неужели нельзя избежать дублирования работы???

Я использую в Jira Time Tracking и отчёт "Сводка работ над версией". То есть я проставляю количество часов, необходимое на разработку, а не конечную дату выполнения. Очередность выполнения управляется приоритетом (также я дополнительно ввёл числовое поле для очередности). Соответственно, когда я назначаю Иванову задачу по разработке модуля А, я в этой задаче указываю, сколько требуется часов на разработку и ставлю приоритет в соответствии с которым Иванов выполняет его в нужном порядке.
Да, согласен, что нет графического представления, но, тем не менее, по каждому разработчику я вижу, сколько рабочих дней на нём "висит". Для планирования сроков и выравнивания загруженности мне хватает.
Конечно, мне приходится сначала назначить все работы разработчикам, и только после этого я могу более точно оценить время. С другой стороны, "примерно" оценить время я могу по тому объёму, который собираюсь включить в очередную версию.
Не уверен, что эта схема будет удобной при большом количестве разработчиков, но мне на моих 8 вполне хватает.Неужели нельзя избежать дублирования работы???

Я использую в Jira Time Tracking и отчёт Неужели нельзя избежать дублирования работы???

Я использую в Jira Time Tracking и отчёт Неужели нельзя избежать дублирования работы???

Я использую в Jira Time Tracking и отчёт

Здравствуйте, stranger_v, Вы писали:

_>Я поражаюсь, что до сих пор приходится так делать. Неужели ничего не придумали для избежания такого?? Или я чего-то не знаю?
Придумали.

Есть, например, task adapter, он как минимум в одном направлении поможет данные перегонять. Может быть, сможет и в обратном направлении синхронизировать. Если интересно, спросите автора (alskor), он вам подробнее расскажет.

Здравствуйте, Centaur, Вы писали:

C>Project более подходит для проектов по копанию траншей. Где «могу копать. могу не копать.» и все работники взаимозаменяемы.

Да ну? А как хотя-бы примерно рассчитать сроки и объяснить их заказчику без подобного механизма? Я не вижу альтернативы, мы же разрабатываем софт не для себя, а для заказчика, где есть вполне конкретные бюджеты и сроки.

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Здравствуйте, stranger_v, Вы писали:

_>>Вот, запустил свой бизнес по созданию интернет порталов. Не могу понять, как эффективно построить управление проектом.
N_C>А сколько суммарно людей в проектах и сколько одновременных проектов?
Пока что один проект, потом рассчитываем на еще один или два параллельных проектов.
Суммарно людей в проекте сейчас 5: Менеджер (он же аналитик), тим лид, два разработчика, один тестер.
С появлением новых проектов еще планируем набрать одного или двух разработчиков.

Здравствуйте, maxkar, Вы писали:

M>Есть, например, task adapter, он как минимум в одном направлении поможет данные перегонять. Может быть, сможет и в обратном направлении синхронизировать. Если интересно, спросите автора (alskor), он вам подробнее расскажет.
229 долларов в месяц. Для нашего проекта это пока много... Тем более, мы нашли достойную бесплатную альтернативу JIRA. Я об этом напишу в посте ниже.

Здравствуйте, Аноним, Вы писали:

А>Я использую в Jira Time Tracking и отчёт "Сводка работ над версией".

Мы решили уйти от JIRA. Сейчас запощу ответ на свой же вопрос. Прошу прокомментировать, если что...

Я сейчас промониторил тулы этого направления. Остановился на:
Для проджект-менеджмента: Gantter, который ставится как приложение на Google Docs. Позволяет строить проектный план. Вполне мощное приложение + возможность заходить на него с любого места, не устанавливая никакой специфичный софт и не морочась с синхронизацией проектных файлов.
Для issue management: Redmine с бесплатным хостингом на hostedredmine.com. Тоже хорошее приложение.
Можно ли их как-то подружить? Или есть, возможно, другие бесплатные или недорогие альтернативы?

Здравствуйте, stranger_v, Вы писали:
_>Пока что один проект, потом рассчитываем на еще один или два параллельных проектов.
_>Суммарно людей в проекте сейчас 5: Менеджер (он же аналитик), тим лид, два разработчика, один тестер.
_>С появлением новых проектов еще планируем набрать одного или двух разработчиков.
Для такого количества людей достаточно Excel. Городить связки программ для управления проектами при одном-трех одновременных проектах, трех-пяти разработчиках и одном ПМе — ИМХО пустая трата времени и сил прежде всего самого ПМа.

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Для такого количества людей достаточно Excel. Городить связки программ для управления проектами при одном-трех одновременных проектах, трех-пяти разработчиках и одном ПМе — ИМХО пустая трата времени и сил прежде всего самого ПМа.

И как рассчитать первоначальные сроки для заказчика и оценить трудозатраты? Неужели в Excel это проще, чем в MS Project-подобном туле?

А как трегать баги, общие задание в Excel-файле? Как организовать с ним совместную работу? Как назначать новые задачи и присылать о них уведомления? По-моему, с Redmine все равно проще, даже при таком небольшом количестве разработчиков.

Или Вы со мной не согласны?

Здравствуйте, stranger_v, Вы писали:

_>Здравствуйте, Nikolay_Ch, Вы писали:

_>И как рассчитать первоначальные сроки для заказчика и оценить трудозатраты? Неужели в Excel это проще, чем в MS Project-подобном туле?
Да. Расчет трудозатрат зиждется на оценке трудозатрат по каждой задаче, это да, но в прожекте их хранить — безумство. В прожекте надо делать только крупные мазки проекта, типа "Разработка", "Тестирование" и пр. и уж их оценивать. А еще надо менеджмент резерв заложить. И прочее и прочее. Заказчику, обычно с высокой колокольни все эти премудрости — ему важен срок и стоимость. Но те сроки, которые Вы называете заказчику и те, которые называют программеры достаточно различны. Также обычно заказчику каждую неделю не делают релизы ПО, поэтому можно просто в прожекте сделать одинаковые стадии релизов, а уж в тулзе управления тасками группировать их по релизам. В итоге прожект оказыватся и не так нужен. Важен срок релиза и объем задач к этому релизу.

_>А как трегать баги, общие задание в Excel-файле? Как организовать с ним совместную работу? Как назначать новые задачи и присылать о них уведомления? По-моему, с Redmine все равно проще, даже при таком небольшом количестве разработчиков.
Не... Трекать баги, конечно, удобнее в тулзе какой-нибудь. Но импортировать потом эти баги в MSProject — верх странности. Прожект не предназначен для учета всей этой мелкотни.

_>Или Вы со мной не согласны?
Смотря в чем.

Здравствуйте, stranger_v, Вы писали:

_>Всем привет!
_>Неужели нельзя избежать дублирования работы???

Можно, используй только jira и объясни сам себе и нам зачем тебе project.

Здравствуйте, stranger_v, Вы писали:

_>Я сейчас промониторил тулы этого направления. Остановился на:
_>Для проджект-менеджмента: Gantter, который ставится как приложение на Google Docs. Позволяет строить проектный план. Вполне мощное приложение + возможность заходить на него с любого места, не устанавливая никакой специфичный софт и не морочась с синхронизацией проектных файлов.
_>Для issue management: Redmine с бесплатным хостингом на hostedredmine.com. Тоже хорошее приложение.
_>Можно ли их как-то подружить? Или есть, возможно, другие бесплатные или недорогие альтернативы?

В итоге Вы заменили бесплатным Gantter'ом MS Project и вместо Jira взяли Redmine. Проблема осталась та же. В чём смысл (кроме бесплатности Gantter)?
Вы так никогда работать не начнёте, подыскивая инструменты для планирования.
Я на Jira 2,5 года веду проект и мне её хватает и для того, чтобы раздать задания разработчикам, и для того, чтобы не срывать сроки перед клиентами. И людей у Вас в проекте почти вдвое меньше, чем у меня.

Планирование ради планирования...

Здравствуйте, Nikolay_Ch, Вы писали:

_>>А как трегать баги, общие задание в Excel-файле? Как организовать с ним совместную работу? Как назначать новые задачи и присылать о них уведомления? По-моему, с Redmine все равно проще, даже при таком небольшом количестве разработчиков.
N_C>Не... Трекать баги, конечно, удобнее в тулзе какой-нибудь. Но импортировать потом эти баги в MSProject — верх странности. Прожект не предназначен для учета всей этой мелкотни.
Если честно, я всё ещё пытаюсь выяснить, для чего же реально предназначен проджект. Пока что, кроме умения рисовать гантт-чарты, ничего интересного я в нём не нашёл.
То есть он много обещает, и оно "почти работает", но реально вызывает чудовищный фрустрейшн.
Простейшая вещь — рассчитать срок изготовления проекта.
Работает только в том случае, если задачи реально зависимые по окончанию. Если делать "крупными мазками", то неприменимо даже к копанию траншей. Тупо потому, что "укладка труб" у вас будет зависеть от "копания траншей", которое само по себе занимает шесть месяцев. А на самом деле, можно выкопать сто метров, и уже начинать укладывать трубы, пока траншеекопатель фигачит себе дальше по графику. Итого, "крупномазочный" проект покажет срок окончания в 12 месяцев там, где на самом деле должно быть семь.
Все книжки по планированию софтных проектов говорят "используйте мелкие таски". "Если вы планируете крупными мазками — вы скорее всего сильно ошибаетесь". При этом проджект "не предназначен для учёта всей этой мелкотни".
Далее, те же книжки на вопрос "а как же нам планировать мелкие таски до того, как мы проведём детальное исследование" отвечают "используйте метод набегающей волны". То есть, накидываем задачки "крупными мазками", делаем приблизительные связи (типа start-to-start +30 days для копания и трубоукладывания), а потом, по мере приближения, начинаем дробить на более мелкие задачи.
В проджекте это делать практически нереально — он очень плохо понимает ситуации, когда подзадачи залинканы одновременно с задачами.
Кроме того, тщательное следование этой болезненной практике приводит в будущем к ещё большим проблемам. Стандартный вопрос "как так получилось, что проект, стоивший по оценке 50 человекомесяцев за 1 год, выполнился за 20 месяцев и потратилось 150 человекомесяцев" ответа не находит. Нет в проджекте способа сравнить два списка задач, увы.

В целом, я готов простить проджекту неумение помогать менеджеру с такими вопросами. Но никаких других инструментов я не знаю!
В сказки про ексель я тоже не верю. Потому что в нём ещё труднее, чем в проджекте оперативно ответить на вопрос вице-президента "а что будет с проектом, если мы по-быстрому всунем в него фичу ХХХ, которую попросил наш большой друг?".

Здравствуйте, Sinclair, Вы писали:

S>В сказки про ексель я тоже не верю. Потому что в нём ещё труднее, чем в проджекте оперативно ответить на вопрос вице-президента "а что будет с проектом, если мы по-быстрому всунем в него фичу ХХХ, которую попросил наш большой друг?".
Ну как Вам сказать. Из опыта работы с заграничными кампаниями (не совсем маленькими и не крупными, которые доросли до создания собственного софта по управлению проектами) могу сказать, что Excel достаточно легко подходит под водопадную модель. И делать в нем такие вещи не сильно сложне прожекта, более того, иногда — даже проще. Понятно, что Excel не дает автоматически производить перерасчет дат, не даст рассчитать критический путь и пр. но для типовых задач по развертыванию ПО с доработками у заказчика (а это развертывание может длятся не один год (сбор требований, проведение фит-гэп анализа, доработка, тестирование) вполне подойдет.
По Вашему примеру — ведь обычно вставка фичи, это ровно столько времени, во сколько ее оценили. И варианта у менеджера, по сути, три — либо что-то выкинуть из проекта (аналогичной трудоемкости), либо задержать проект, либо увеличить ресурсы. На всякие "если" (типа а что если мы ее сделаем не сейчас, а через два месяца) ответить не сможет ни одна программа.

Здравствуйте, stranger_v, Вы писали:

_>Я поражаюсь, что до сих пор приходится так делать. Неужели ничего не придумали для избежания такого?? Или я чего-то не знаю?
_>Неужели нельзя избежать дублирования работы???

Можно.

Но это не так просто. Для этого необходимо хоть на минуту перестать поражаться, набраться смелости, и заглянуть в репозиторий плагинов JIRA. С двумя прямолинейными поисковыми запросами.

https://plugins.atlassian.com/search?q=Gantt
https://plugins.atlassian.com/search?q=Project

И обратить, например, внимание, хоть вот эту штуку, которая существует уже много лет: https://plugins.atlassian.com/plugins/com.ecliptictech.connector

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Не... импортировать потом эти баги в MSProject — верх странности. Прожект не предназначен для учета всей этой мелкотни.
Да, убедили, проджект и JIRA, все же, не стоит сдруживать...

_>>Также обычно заказчику каждую неделю не делают релизы ПО, поэтому можно просто в прожекте сделать одинаковые стадии релизов, а уж в тулзе управления тасками группировать их по релизам. В итоге прожект оказыватся и не так нужен. Важен срок релиза и объем задач к этому релизу.
У меня вот тоже начинается фрустрация. Как все же оценить сроки проекта, который достаточно сложный и состоит из множества задач? Project не помогает, получается, JIRA не для этого, как все-таки делать оценку??? Я в потерях ,помогите, плиз!

Здравствуйте, Sinclair, Вы писали:

S>Если честно, я всё ещё пытаюсь выяснить, для чего же реально предназначен проджект. Пока что, кроме умения рисовать гантт-чарты, ничего интересного я в нём не нашёл.

Ок, я тебе помогу.

S>То есть он много обещает, и оно "почти работает", но реально вызывает чудовищный фрустрейшн.
S>Простейшая вещь — рассчитать срок изготовления проекта.
S>Работает только в том случае, если задачи реально зависимые по окончанию.

То есть, про функцию MS Project "Resource Levelling" ("выравнивание загрузки ресурсов"), ты пока не знаешь.

Не беда, это можно исправить за 5 минут чтением, например, вот этой заметки.
http://gaperton.livejournal.com/19205.html

Добро пожаловать в увлекательный мир MS Project . Это основная фукнция — по сути, главное, что он вообще делает.