Интересная тема. А нужны ли такие программы в принципе? Никогда их не использовала.. точнее попробовала один раз и поняла, что её администрирование занимает слишком много времени
( ... )
Бумажки и доски с маркерами отличное решение внутри компании или для себя лично. А для управления, допустим, фрилансерами этим механизмом не обойдешься. Например, на этапе тестирования и появления огромного количества правок обрастаешь быстро письмами с разных сторон, переговорами в скайпе/аське/телефоне (что совсем плохо). А самоорганизация у всех разная и некоторые правки могут попросту забыться.
У меня есть свое видение системы, поделенной на три части: 1. Подготовка к разработке - идеи, предложения, обсуждения, комментарии. 2. Разработка - график, плановые задачи, обсуждение. 3. Тестирование - список правок, комментарии, доступ заказчика.
А как залинковать ПМ на обсуждения? на аську на имейл? На конфоклы? вносить вручную? это опять же администрирование. На стадии тестирования будет возникать много вопросов, которые (в идеале) заказчик должен был озвучить в "подготовке к разработке", но объективно он не мог предугадать, что система поведет себя так-то и так-то и вопрос вообще возникнет. И в какую секцию это пойдет? И что будет? прогон текущего проекта с нуля? нью проджект? Получается, что структурированное сохранения всей хистори «хотелок заказчика» и «возможных вариантов технической реализации» - важна функция ПМ. Действительно интересно, как это можно реализовать.
Нужно упрощать по максимуму процесс линкования. Но абсолютно от него избавиться не получится.
Насчет новых вопросов, которые будут возникать в процессе тестирования - это легок решается. Оно так же заводится в проект на свою стадию. То есть выделяется в плановую задачу и в процесс разработки. Хотя у меня с собой противоречия - нужно ли так усложнять систему? С одной стороны это несомненный плюс - упрощается структурирование информации, проще найти что-либо, раздать права на доступ и т.д. А с другой - усложняется администрирование, увеличивается время на разбирательства...
КМК, это как сферический конь в вакууме - идеального инструмента быть не может. По-моему, всё очень сильно зависит от предметной области проекта и его управления. Функции необходимые на разных уровнях разные и КМК в одном инструменте их сосредотачивать не стоит вообще. А так если говорить про разработку, то мне нравился Trac.
Во, только что пришла мысль - идеальный инструмент, это тот который удовлетворяет потребностям конкретного проекта, а значит заточен под него. Опять же под прошлый проект trac затачивался с помощью плагинов и их модификаций. Всякие попытки создать универсальноидеальное заканчиваются настолько тяжеловесными и сложными системами, что они перестают быть полезными, а в некоторых случаях даже становятся вредными, навязывая свои процессы управления.
Возможно для тебя будет хорошим решением собрать участников проекта и вместе решить что вам от этой системы нужно, а потом подобрать максимально близкую по функционалу (или же несколько для различных областей) и кастомизировать её под себя.
Гм. Ты знаешь, практика показывает что в разработке нет типовых проектов. :))) Ключевое слово "разработка", которое означает наличие новых идей в проекте, а значит и новых воплощений. Очень многое зависит от команды. По хорошему именно она определяет бизнес-процесс, а не то, что ты собираешься делать. Почитай Peopleware.
Серег, идеи идеями, но их реализация укладывается в одну строгую последовательность: идея - формулирование - разработка - тестирование и отладка. Задача инструмента - рассортировать все задачи и идеи, назначить их группам и не дать ничему потеряться. Если, например, студия клепала всю жизнь сайтики на несколько страниц, самым сложным в которых была форма обратной связи, и тут этой студии приходит заказ на сайт, привязанный к 1С, да еще и с флэшовым баннером и инструмент, в котором ведется проект, не способен в себе это переварить - грош цена этому инструменту.
Comments 16
Reply
У меня есть свое видение системы, поделенной на три части:
1. Подготовка к разработке - идеи, предложения, обсуждения, комментарии.
2. Разработка - график, плановые задачи, обсуждение.
3. Тестирование - список правок, комментарии, доступ заказчика.
Ну а юзабилити даже не обсуждается. )
Reply
На стадии тестирования будет возникать много вопросов, которые (в идеале) заказчик должен был озвучить в "подготовке к разработке", но объективно он не мог предугадать, что система поведет себя так-то и так-то и вопрос вообще возникнет. И в какую секцию это пойдет?
И что будет? прогон текущего проекта с нуля? нью проджект?
Получается, что структурированное сохранения всей хистори «хотелок заказчика» и «возможных вариантов технической реализации» - важна функция ПМ. Действительно интересно, как это можно реализовать.
Reply
Насчет новых вопросов, которые будут возникать в процессе тестирования - это легок решается. Оно так же заводится в проект на свою стадию. То есть выделяется в плановую задачу и в процесс разработки. Хотя у меня с собой противоречия - нужно ли так усложнять систему? С одной стороны это несомненный плюс - упрощается структурирование информации, проще найти что-либо, раздать права на доступ и т.д. А с другой - усложняется администрирование, увеличивается время на разбирательства...
Reply
Reply
Reply
Во, только что пришла мысль - идеальный инструмент, это тот который удовлетворяет потребностям конкретного проекта, а значит заточен под него. Опять же под прошлый проект trac затачивался с помощью плагинов и их модификаций. Всякие попытки создать универсальноидеальное заканчиваются настолько тяжеловесными и сложными системами, что они перестают быть полезными, а в некоторых случаях даже становятся вредными, навязывая свои процессы управления.
Возможно для тебя будет хорошим решением собрать участников проекта и вместе решить что вам от этой системы нужно, а потом подобрать максимально близкую по функционалу (или же несколько для различных областей) и кастомизировать её под себя.
Reply
Reply
Reply
Reply
Leave a comment