«уже к финальному релизу предъявлял ту самую кучу новых требований» — у нас была несколько похожая ситуация, как раз в конце статьи я об этом упомянул. Только заказчик не предъявил кучу новых требований, а немного посетовал, что сделали не все, что было у него в голове. В принципе, если это возражение быстро и качественно с аргументами обработать, то получается ок и дальше запускается следующий этап проекта (релиз), уже в рамках нового бюджета.
По поводу сырости и недоработок, на моем опыте такое впечатление заказчика о промежуточных результатах сильно зависит от того, что мы ему показываем. Если показываем сырое, падающее, непонятно как сверстанное — тогда понятно, он будет недоволен. А если показывать небольшими инкрементами функциональности, но зато условно production качества — это уже другой разговор.
Как я уже писал в комментарии выше, мы вместе с заказчиком делаем нужный ему продукт, с максимально возможным набором функций, в рамках бюджета проекта.
Если вы имеете ввиду полностью закрыть ответственность исполнителя договором — ну тут вариант только один, все четко прописать и получить контракт с зафиксированными бюджетом, сроком и скоупом.
Тогда заказчик точно получит то, что просил на старте проекта. Но не то, что ему по факту нужно. И обе стороны будут иметь те же проблемы, от которых хотели уйти :)
В таком случае мы, наверное, будем не очень хорошими исполнителями. Если клиент хотел CRM, то он должен получить CRM.
Весь вопрос в объеме реализованной функциональности, которая постоянно обсуждается нами и заказчиком в течение проекта, но свои основные функции как CRM система должна выполнять.
Иначе да, как в бодишопах, когда у исполнителей нет никакой ответственности за итоговый продукт — продается просто человек, а там будь что будет.
Всегда удивляюсь, почему в описании use cases используют неблагозвучное для русского языка слово Актор.
Ведь аналитика пишется для простых заказчиков и разработчиков, которым гораздо более понятны фразы «Зритель называет номер брони» и «Зритель передает оператору плату за билет», а не «Актор называет номер брони».
Теперь создание проекта (настоящего или тестового) доступно на сервисе Облако проектов (http://projectscloud.ru) — это бесплатный проектный хостинг, в основе которого лежит система управления проектами DEVPROM
"… для реально гибких разработчиков даже Scrum недостаточно гибок" — главное, чтобы под маской этой «гибкости» не скрывался хаос в проекте, что бывает в большинстве случаев.
Не соглашусь, мы же говорим про разумных людей, проектные команды внутри одной компании.
Википедия имеет такие жесткие правила потому что открыта на «весь интернет» — это единственный способ не превратить ее в помойку. Да и типичное сообщение проектного блога — это не огромная, тщательно продуманная статья, а, как правило, небольшая заметка, автор которой считает, что она может быть полезна его коллегам.
1/3 сотрудников очень неплохой результат!
К тому же блоги проектные, т.е. один блог на команду. Если из 7 человек команды 1-2-3 будут писать, получится отлично. Умножаем на количество проектов — получаем живую блогосферу внутри компании.
На одной из прошлых работ для обмена информации в целом по компании мы использовали обычный форум, было очень удобно. Единственный минус, некоторые личности сильно увлекались общением и забывали про основные рабочие обязанности :)
Как правильно написали в комментариях выше, помимо удобного инструмента как и в любом другом начинании нужен еще и «драйвер», который будет развивать идею ведения блогов. И остальные подхватят — главное чтобы пользу для себя видели.
«Удачность» примеров зависит от используемых в компании инструментов. Я видел реализацию новостей на sharepoint — не проектные, а в целом по компании. Если активно используется например Jira + Wiki, то блог можно вести через встроенные в wiki новости — не могу объяснить почему, но особой популярностью у разработчиков такой движок не пользовался.
Еще один из примеров devprom.ru/co/news.php, на локальной установке будут доступны две закладки — Мои проекты и Новости всех проектов компании с RSS подпиской. Этот вариант очень похож на обычные блого-движки + с системой идет ежедневная работа, возможно поэтому во многих компаниях, где используется этот инструмент, проектные блоги ведутся очень активно.
Как показывает опыт, разработчики часто сами выступают с инициативой завести блог внутри компании.
Главное чтобы был простой и удобный способ писать, читать и комментировать записи. Один начнет писать — остальные подтянутся.
На мой взгляд главное вести именно Проектные блоги, т.е. с тематическим содержанием.
От демо-проекта мы отказались, потому что слишком быстро он превращается в помойку.
Лучше просто создайте свой тестовый проект и в нем вы сможете посмотреть все возможности инструмента.
Вообще, та IDE, которую вы описали, выглядит очень заманчиво :)
Есть ненулевая вероятность, что вы входите в 20% до тех пор, пока для изменения настроек вашей IDE не требуется отдельный ИТ отдел, как в случае, описанном в статье.
Уверен, что еще один баг-трекер никому не нужен :)
Мы делаем инструмент управления проектами по разработке ПО, про автоматизацию деятельности HR и прочих административных служб речи не идет. Я уже писал выше в комментариях, что Jira с такими задачами справляется на 100%.
В основном нас беспокоит юзабилити, сейчас пытаемся его улучшить, одновременно и дизайн подтянется. Сервис постоянно развивается, мы ни в коем случае не говорим, что уже закончили работу над ним.
Насчет того, что не смогли разобраться — какой момент оказался самым непонятным? Если вам действительно нужна система управления проектом — с удовольствием помогу разобраться.
По поводу сырости и недоработок, на моем опыте такое впечатление заказчика о промежуточных результатах сильно зависит от того, что мы ему показываем. Если показываем сырое, падающее, непонятно как сверстанное — тогда понятно, он будет недоволен. А если показывать небольшими инкрементами функциональности, но зато условно production качества — это уже другой разговор.
Если вы имеете ввиду полностью закрыть ответственность исполнителя договором — ну тут вариант только один, все четко прописать и получить контракт с зафиксированными бюджетом, сроком и скоупом.
Тогда заказчик точно получит то, что просил на старте проекта. Но не то, что ему по факту нужно. И обе стороны будут иметь те же проблемы, от которых хотели уйти :)
Весь вопрос в объеме реализованной функциональности, которая постоянно обсуждается нами и заказчиком в течение проекта, но свои основные функции как CRM система должна выполнять.
Иначе да, как в бодишопах, когда у исполнителей нет никакой ответственности за итоговый продукт — продается просто человек, а там будь что будет.
Ведь аналитика пишется для простых заказчиков и разработчиков, которым гораздо более понятны фразы «Зритель называет номер брони» и «Зритель передает оператору плату за билет», а не «Актор называет номер брони».
Википедия имеет такие жесткие правила потому что открыта на «весь интернет» — это единственный способ не превратить ее в помойку. Да и типичное сообщение проектного блога — это не огромная, тщательно продуманная статья, а, как правило, небольшая заметка, автор которой считает, что она может быть полезна его коллегам.
К тому же блоги проектные, т.е. один блог на команду. Если из 7 человек команды 1-2-3 будут писать, получится отлично. Умножаем на количество проектов — получаем живую блогосферу внутри компании.
Еще один из примеров devprom.ru/co/news.php, на локальной установке будут доступны две закладки — Мои проекты и Новости всех проектов компании с RSS подпиской. Этот вариант очень похож на обычные блого-движки + с системой идет ежедневная работа, возможно поэтому во многих компаниях, где используется этот инструмент, проектные блоги ведутся очень активно.
Главное чтобы был простой и удобный способ писать, читать и комментировать записи. Один начнет писать — остальные подтянутся.
На мой взгляд главное вести именно Проектные блоги, т.е. с тематическим содержанием.
Лучше просто создайте свой тестовый проект и в нем вы сможете посмотреть все возможности инструмента.
Есть ненулевая вероятность, что вы входите в 20% до тех пор, пока для изменения настроек вашей IDE не требуется отдельный ИТ отдел, как в случае, описанном в статье.
Мы делаем инструмент управления проектами по разработке ПО, про автоматизацию деятельности HR и прочих административных служб речи не идет. Я уже писал выше в комментариях, что Jira с такими задачами справляется на 100%.
Насчет того, что не смогли разобраться — какой момент оказался самым непонятным? Если вам действительно нужна система управления проектом — с удовольствием помогу разобраться.