> а также позволяет регламентировать Ваши отношения с клиентом при помощи договора
на сколько я помню ГК, для заключения договора даже ИП совсем не обязательно становится.
>Как уберечься от недобросовестных заказчиков? Никак.
Не правда. Разбивайте проект на не большие этапы. Каждый этап - предоплата-работа-полная оплата. Если этапы разбиты правильно - вероятность кидалова сводится практически к нулю.
>Через несколько лет практически не останется компаний, которые не используют интернет.
да, да... я слышал это еще в 97...
>мы все увидим то время, когда ... рекламные агентства и многие посредники исчезнут
какое-то у Вас странное видение мира. "толстому" заказчику выгодно обратится в РА и получить полный спектр работ, чем искать много фрилансеров-специалистов. поэтому РА никогда не умрут. максимум - мутируют во что-то более современное.
цинизм - в определенной мере да, но без этого (в разумных пределах разумеется) не выжить в более-менее крупном проекте. А вот с жадностью... категорически не согласен. Если Вы не поняли мою фразу, то расшифрую - разработчик, для которого действительно важны эти 9 вещей является очень ценным сотрудником, поэтому его "оторвут с руками".
зы. "минусовать" тоже ничего не стал :) ибо все имеют право на ошибку.
смайл остался не замеченым :(
вообще говоря - это проблема клиента. если он ставит некий софт и не может его настроить (при условии, что все параметры настроек ему известны) - это проблемы клиента.
Набор статусов резко ограничивает гибкость системы. Либо мы должны дать возможность для каждого проекта (а еще лучше - этапа проекта или вообще для каждой задачи) иметь возможность создавать свой набор статусов. Либо строить иерархические зависимости - "задача А распадается на В и С. В, в свою очередь, должна предшествовать С и состоит из В1 и В2, которые могут выполняться одновременно". Это наиболее наглядно раскрывает процесс разработки и позволяет легко строить 2 списка задач, о которых писал выше.
Согласитесь, статус при таком использовании, выглядит как костыли. Объясню почему. Если я не проджект, то статус как таковой меня мало интересует. Я поставил задачу, меня интересует лишь когда она будет выполнена, если при этом мне предоставят дату выполнения с учетом рисков (это скорее для клиента) - будет вообще супер. Если я проджект (или рук.группы) то для меня должно существовать только три статуса у задачи - еще не принятая в работу, которую мне прислал другой участник разработки; выполняемая (стоящая у меня на контроле); и уже выполненная (собственно она нужна только для составления отчета по начальной поставленной задаче и для статистики).
Вообще говоря, любой участник процесса разработки должен очень просто получать доступ к 2м спискам задач - те, что поставили ему ("отчеты наверх"), и те, что поставил он ("контроль передо мной") + возможность наложить филтр по времени - сегодня, наделя, месяц. Весь остальной функционал системы должен строится вокруг этих двух списков. Это "прототип идеальной ситемы управления проектами" :)
Что касается использования двух разных систем (если они не интегрируются) - это потенциальный залет, полностью согласен.
А я ведь не зря выделил слово "удобное" ;) Приспособиться можно практически под любой софт. Другое дело - удобство работы с ним. Дело конечно субъективное, универсального для всех написать наверное не реально. Но то, что в существующем софте очень четко прослеживаются две тенденции - "похожие" на Project и "продивинутые" бегтрекинг системы - мне кажется не совсем то, что действительно нужно РМ.
Нет, не совсем правильно поняли. Project я рассматриваю как средство планирования, оценки и контроля проекта. Поэтому хранить данные, которые мне не нужны внутри Project'а мне нет нужы. Впрочем, как и хранить там вообще какие-то расширенные данные (тексты, например).
А какой статус нужно эмулировать? Лично для меня - разбиение на мелкие подзадачи является большим плюсом. Отчеты же в Project'е достаточно развиты, в отличии от многих других систем - можно получить практически любое представление. С чем я не буду спорить - совместная работа несколько затруднена и построена не совсем так, как лично мне было бы удобнее. Но повторюсь - пока не встретил ни одной системы, которая полностью меня бы удовлетворяла. Скорее всего это приведет к тому, что рано или поздно, но будет самостоятельно разработан принципиально другой инструмент, в который будет заложена принципиально иная идеалогия. Ибо, как уже писал, у всех систем, которые пошли от tracking-систем - мало развит функционал собственно управления проектом и задачами, контроля, планирования. А у того же Project'а слабо развит функционал оперативного управления проектом. В частности об этой проблеме говорит тот факт, что очень многие, отметившиеся в комментариях, используют 2 системы.
Не сколько ни защищая микрософт. Цитаты и комментарии.
«Project рассчитан на меньшее количество задач, чем вам нужно». Доказательство оставляет желать лучшего. На сколько я понимаю – внутренности Project'а суть БД, а на примере того же Access'а мы можем наблюдать достаточно надежную настольную БД. И вообще автор пытается взвалить на Project функции багтреккинга, для чего он слабо предназначен.
«Project позволит вам случайно поменять ID задачи». Не очень понял о каком ID говорит автор – как такового ID в Project не припомню. А вообще он позволяет удалять задачу, ай-яй... Наверное думать надо прежде чем что-то делаешь, а не списывать на случайности.
«Надо что-то делать с жизненным циклом задачи». Надо – делаем. Например, добавляем новые подзадачи. В чем проблема – не совсем понятно. Если мы хотим спланировать работу по каждому из исполнителей (один уровень детализации) – добавляем отдельные подзадачи.
«Исполнители взаимозаменяемы». Да, а производительность, о которой страдает автор, отражаем в % доступности ресурса. При этом если мы поменяем исполнителя Project автоматически предложит нам пропорционально увеличить (уменьшить) длительность задачи. Согласен, не самый красивый способ, но у большинства других виденных мною систем даже такой возможности не существует.
«Поэтому здравомыслящий менеджер использует бинарную систему оценки готовности: готово - не готово. Всякие проценты - это, как правило, мишура, отвлекающая от более важных вещей.». Автору срочно перечитать «Вальсируя с медведями».
«половину информации о проекте удастся внести в Project, вторую половину придется держать в голове». Не встречал ни одной системы управления проектами, которая полностью удовлетворяет потребностям разработчика. Тот же Trac, так активно продвигаемый автором, имеет свои недостатки, прежде всего связанные с тем, что его прародителем явно являлась система багтреккинга – достаточно развитый функционал по работе над каждой конкретной задачей, при этом крайне бедный timelin. Если для рядового разработчика вполне хватает существующего функционала, то уже для лидера группы (не говоря уже о проджекте) функционала крайне не хватает.
Теперь о плюсах Project'а. Сам по себе он не имеет всего спектра необходимых инструментов для решения всех задач. Но не даром в названии присутствует слово «Office». Этот продукт интегрируется с другими, что дает возможность построить мощную систему. MS SPS и Project Server дают работать с рисками проекта. Вы много знаете систем управления проектами в области разработки ПО в которые интегрирована возможность управления рисками?
Подведя краткие итоги – каждый инструмент хорош в чем-то своем, у каждого есть свои плюсы и минусы. Каждый предназначен для своего круга задач.
ну если вы настаиваете... давайте тогда уточним предмет договора. предлагаю - "оказание услуг по составлению искового заявления о возмещении ущерба, причененного в результате нарушения авторских прав"?
на сколько я помню ГК, для заключения договора даже ИП совсем не обязательно становится.
>Как уберечься от недобросовестных заказчиков? Никак.
Не правда. Разбивайте проект на не большие этапы. Каждый этап - предоплата-работа-полная оплата. Если этапы разбиты правильно - вероятность кидалова сводится практически к нулю.
>Через несколько лет практически не останется компаний, которые не используют интернет.
да, да... я слышал это еще в 97...
>мы все увидим то время, когда ... рекламные агентства и многие посредники исчезнут
какое-то у Вас странное видение мира. "толстому" заказчику выгодно обратится в РА и получить полный спектр работ, чем искать много фрилансеров-специалистов. поэтому РА никогда не умрут. максимум - мутируют во что-то более современное.
зы. "минусовать" тоже ничего не стал :) ибо все имеют право на ошибку.
вообще говоря - это проблема клиента. если он ставит некий софт и не может его настроить (при условии, что все параметры настроек ему известны) - это проблемы клиента.
золотые слова :)
Вообще говоря, любой участник процесса разработки должен очень просто получать доступ к 2м спискам задач - те, что поставили ему ("отчеты наверх"), и те, что поставил он ("контроль передо мной") + возможность наложить филтр по времени - сегодня, наделя, месяц. Весь остальной функционал системы должен строится вокруг этих двух списков. Это "прототип идеальной ситемы управления проектами" :)
Что касается использования двух разных систем (если они не интегрируются) - это потенциальный залет, полностью согласен.
А какой статус нужно эмулировать? Лично для меня - разбиение на мелкие подзадачи является большим плюсом. Отчеты же в Project'е достаточно развиты, в отличии от многих других систем - можно получить практически любое представление. С чем я не буду спорить - совместная работа несколько затруднена и построена не совсем так, как лично мне было бы удобнее. Но повторюсь - пока не встретил ни одной системы, которая полностью меня бы удовлетворяла. Скорее всего это приведет к тому, что рано или поздно, но будет самостоятельно разработан принципиально другой инструмент, в который будет заложена принципиально иная идеалогия. Ибо, как уже писал, у всех систем, которые пошли от tracking-систем - мало развит функционал собственно управления проектом и задачами, контроля, планирования. А у того же Project'а слабо развит функционал оперативного управления проектом. В частности об этой проблеме говорит тот факт, что очень многие, отметившиеся в комментариях, используют 2 системы.
«Project рассчитан на меньшее количество задач, чем вам нужно». Доказательство оставляет желать лучшего. На сколько я понимаю – внутренности Project'а суть БД, а на примере того же Access'а мы можем наблюдать достаточно надежную настольную БД. И вообще автор пытается взвалить на Project функции багтреккинга, для чего он слабо предназначен.
«Project позволит вам случайно поменять ID задачи». Не очень понял о каком ID говорит автор – как такового ID в Project не припомню. А вообще он позволяет удалять задачу, ай-яй... Наверное думать надо прежде чем что-то делаешь, а не списывать на случайности.
«Надо что-то делать с жизненным циклом задачи». Надо – делаем. Например, добавляем новые подзадачи. В чем проблема – не совсем понятно. Если мы хотим спланировать работу по каждому из исполнителей (один уровень детализации) – добавляем отдельные подзадачи.
«Исполнители взаимозаменяемы». Да, а производительность, о которой страдает автор, отражаем в % доступности ресурса. При этом если мы поменяем исполнителя Project автоматически предложит нам пропорционально увеличить (уменьшить) длительность задачи. Согласен, не самый красивый способ, но у большинства других виденных мною систем даже такой возможности не существует.
«Поэтому здравомыслящий менеджер использует бинарную систему оценки готовности: готово - не готово. Всякие проценты - это, как правило, мишура, отвлекающая от более важных вещей.». Автору срочно перечитать «Вальсируя с медведями».
«половину информации о проекте удастся внести в Project, вторую половину придется держать в голове». Не встречал ни одной системы управления проектами, которая полностью удовлетворяет потребностям разработчика. Тот же Trac, так активно продвигаемый автором, имеет свои недостатки, прежде всего связанные с тем, что его прародителем явно являлась система багтреккинга – достаточно развитый функционал по работе над каждой конкретной задачей, при этом крайне бедный timelin. Если для рядового разработчика вполне хватает существующего функционала, то уже для лидера группы (не говоря уже о проджекте) функционала крайне не хватает.
Теперь о плюсах Project'а. Сам по себе он не имеет всего спектра необходимых инструментов для решения всех задач. Но не даром в названии присутствует слово «Office». Этот продукт интегрируется с другими, что дает возможность построить мощную систему. MS SPS и Project Server дают работать с рисками проекта. Вы много знаете систем управления проектами в области разработки ПО в которые интегрирована возможность управления рисками?
Подведя краткие итоги – каждый инструмент хорош в чем-то своем, у каждого есть свои плюсы и минусы. Каждый предназначен для своего круга задач.
"покажите мне мульон" :D