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