Антон, спасибо за развернутый комментарий! То, что вопрос в заголовке риторический — вы поняли абсолютно верно.
Касательно workflow здесь вот какая особенность — в статье я говорил исключительно про разработку приложений.
Я знаю десяток действительно великолепных решений на базе Jira для HR, ServiceDesk и прочих служб, в основе которых лежат так называемые «заявки», с жестко заданным и крайне редко меняющимся workflow.
В случае проектной деятельности по разработке ПО процесс должен эволюционировать, чтобы оставаться эффективным, и часто начинают вносить исправления именно в инструмент, а не в сам процесс. И получаются те проблемы, которые я описал в статье.
Люди важнее инструментов, поэтому нужно сдерживать себя и не поддаваться искушению кастомизации инструмента, а сначала попробовать привнести новые идеи в жизнь и убедиться, что они действительно необходимы и эффективны.
Ну и не стоит забивать гвозди отверткой — управление проектом сводится не только к issue tracking, но так же требует и работу с требованиями и нормальное планирование и многое другое, для чего инструменты вроде Jira просто не предназначены.
А используются. Как помните, было «ежики кололись и плакали, но продолжали есть кактус».
Если говорить только о сверлении дырок (отслеживание запросов) — то да.
Но попробуйте, имея в руках только дрель и набор сверел, сделать полный ремонт во всей квартире (разработка проекта) — вряд ли у вас что-то получится сделать это хорошо и быстро, согласны?
Мы же пытаемся сделать скорее доступный всем «набор для ремонта» — ящик с наиболее часто необходимыми инструментами, которые максимально подойдут большинству команд, разрабатывающих приложения. И который может заменить покупку и интеграцию трех или пяти различных инструментов.
Технически сделать контекстное меню не представляет трудности — но станет ли более удобнее, это вопрос. Нужно тогда весь интерфейс приводить к такому стилю, иначе 99% пользователей просто не догадается, что где-то на нашем сервисе можно вызвать контекстное меню.
Было бы здорово, если бы вы через форму обратной связи описали места, где добавление такого меню имело бы смысл — тогда это пожелание попадет к нам в список задач и мы будем иметь его в поле зрения.
согласен, в случае с проигрывателем все будет именно так.
но jira — инструмент несколько другого уровня, и для ее грамотной настройки (даже чтобы только все упростить) нужен отдельный человек, немало времени на нее отдавший. а иначе будет бардак и соответственно проблемы в вашей с ней работе.
более того — в большинстве случаев ошибка обязательно нуждается в согласовании, так как ее исправление может занять достаточно много времени, которое уже распланировано в итерации на другие работы, которые могут так и оставаться более приоритетными, чем найденная ошибка.
соответственно ее исправление может быть запланировано как в текущей, так и в любой другой итерации — а это один в один жизненный цикл задачи, так что здесь расхождений нет.
Такой подход годится только для первых оценок данным программистом по данному проекту, потому как чрезвычайно неточен (или для непрофессиональных управленцев).
Дальше следует использовать исторические данные, такие как средняя точность (неточность) оценки либо конкретного исполнителя, либо (что предпочтительнее) всей команды.
Подобные метрики умеют собирать многие продвинутые инструменты для управления проектами. Точность оценки на выходе — практически идеальна по сравнению с предложенным методом умножения на 2, 3 и любой другой коэффициент.
Мы все еще на пути понимания как же именно разложить на сайте все так, чтобы любому было понятно, похоже справляемся не очень, но тенденция положительная :)
Самая лучшая демонстрация — пощупать сам инструмент, для этого достаточно создать проект. Описание (с картинками) некоторых частей функционала доступно на закладке Возможности.
Хотим в ближайшее время презентации сделать или ролики, которые будут объяснять все в картинках, конечно это сразу повысит понимаемость, но и увеличит поверхностность суждений, поскольку все детали в ролики не запихнешь, а их может быть более 20.
На счет аудитории, бесспорно люди интересные, но слишком мало тех, кто занимается разработкой относительно крупных решений на заказ или поиском исполнителей, и даже среди них нет особенного интереса, поскольку для большинства инструмент — это лишняя головная боль, да и уровень управления проектами среди команд достаточно низкий.
Мало кто ценит прозрачность процесса и важность его постановки, пока так сказать ломают дрова :) А еще меньше люди ставят себя на место заказчика, у большинства вазимодействие строится на доверии и «авось».
На счет офисов (не обязательно крупных) мы уже некоторое время работаем в этом направлении и для них не требуется использования сайта, для них есть standalone или saas решения. Надеюсь в ближайшее время сообщим о какой-нить success story в этом плане.
в данном случае качественные и количественные показатели обсуждения мало о чем говорят: может быть не та аудитория, может быть не та тема, может быть все что угодно.
личный опыт говорит о необходимости подобного инструмента и отсутствии аналогов, в России как минимум.
Одна дизайнерша нас уверяла, что железно все должно быть в темных тонах (черный фон и т.п. :) Лично мне тоже было бы приятно работать в светлых :)
Сразу не получилось сгруппировать информацию так, чтобы она не перегружала… Делемма тут такая: информации много, но если ее спрятать за большим количеством вложенных страниц, то приходящий человек не очень понимает что за сервис, поскольку все скрыто и как куда добраться неизвестно.
Пока решили, чтобы показать какая информация вообще доступна выложили практически все для быстрого доступа.
Когда реализуем основной функционал наверно разложим информацию по целевой аудитории: в разделе для заказчика будет сосредоточена информация для него, в разделе для шароварщиков — для него, в разделе для аутсорсера что-то будет нужное ему, наверно как-то так, что скажете?
проблема шаблонов в том, что они под блоги, сайты визитки и т.п. Нам же нужен шаблон, который сможет охватить все наши разделы, такого не удалось найти.
Ну в первую очередь это не развлеательный портал, а инструмент. Поэтому мы пока сосредоточились на функционале, когда закончим задуманное, то натянем и дизайн.
Это достаточно сложный вопрос. Наличие этих показателей отличает нашу систему от многих остальных. В других системах есть подобная информация, но вряд ли ее можно агрегировать в наших показатели и встанет вопрос об адекватности сравнения показателей собранных из разных систем.
Мы предлагаем инструмент, пользоваться им или не пользоваться естественное дело выбора каждого.
необязательно там тусоваться, достаточно оставить реальный мыл, система позволит связаться. То есть в идеале, команда использует DEVPROM в удобном для нее окружении, а информация полезная для потенциального заказчика доступна в community.
вопросом рекламы скоро займемся, но видимо основное — это должна быть контекстная реклама, ориентированная как на заказчиков, так и на исполнителей. На «ломанулись» не рассчитываем, ниша довольно специфична и главное — интрумент должны попробовать, пока планируем выступления на конференциях, чтобы сформировать какое-то ядро.
Экстримальное программирование — это часть семейства Agile, так что вы совершенно правы в том, что понятия скорость и «принцип вчерашней погоды» заимствованы оттуда, однако похожими понятиями пользуются и другие методологии из семейства.
Однако, приведенной в моей статье формулы вы там не встретите, и вообще в «планировании» все очень абстрактно описано, как идея — замечательно, но как это использовать… я представил свой вариант практического применения.
Касательно workflow здесь вот какая особенность — в статье я говорил исключительно про разработку приложений.
Я знаю десяток действительно великолепных решений на базе Jira для HR, ServiceDesk и прочих служб, в основе которых лежат так называемые «заявки», с жестко заданным и крайне редко меняющимся workflow.
В случае проектной деятельности по разработке ПО процесс должен эволюционировать, чтобы оставаться эффективным, и часто начинают вносить исправления именно в инструмент, а не в сам процесс. И получаются те проблемы, которые я описал в статье.
Люди важнее инструментов, поэтому нужно сдерживать себя и не поддаваться искушению кастомизации инструмента, а сначала попробовать привнести новые идеи в жизнь и убедиться, что они действительно необходимы и эффективны.
Ну и не стоит забивать гвозди отверткой — управление проектом сводится не только к issue tracking, но так же требует и работу с требованиями и нормальное планирование и многое другое, для чего инструменты вроде Jira просто не предназначены.
А используются. Как помните, было «ежики кололись и плакали, но продолжали есть кактус».
Но попробуйте, имея в руках только дрель и набор сверел, сделать полный ремонт во всей квартире (разработка проекта) — вряд ли у вас что-то получится сделать это хорошо и быстро, согласны?
Мы же пытаемся сделать скорее доступный всем «набор для ремонта» — ящик с наиболее часто необходимыми инструментами, которые максимально подойдут большинству команд, разрабатывающих приложения. И который может заменить покупку и интеграцию трех или пяти различных инструментов.
Было бы здорово, если бы вы через форму обратной связи описали места, где добавление такого меню имело бы смысл — тогда это пожелание попадет к нам в список задач и мы будем иметь его в поле зрения.
но jira — инструмент несколько другого уровня, и для ее грамотной настройки (даже чтобы только все упростить) нужен отдельный человек, немало времени на нее отдавший. а иначе будет бардак и соответственно проблемы в вашей с ней работе.
соответственно ее исправление может быть запланировано как в текущей, так и в любой другой итерации — а это один в один жизненный цикл задачи, так что здесь расхождений нет.
Дальше следует использовать исторические данные, такие как средняя точность (неточность) оценки либо конкретного исполнителя, либо (что предпочтительнее) всей команды.
Подобные метрики умеют собирать многие продвинутые инструменты для управления проектами. Точность оценки на выходе — практически идеальна по сравнению с предложенным методом умножения на 2, 3 и любой другой коэффициент.
Самая лучшая демонстрация — пощупать сам инструмент, для этого достаточно создать проект. Описание (с картинками) некоторых частей функционала доступно на закладке Возможности.
Хотим в ближайшее время презентации сделать или ролики, которые будут объяснять все в картинках, конечно это сразу повысит понимаемость, но и увеличит поверхностность суждений, поскольку все детали в ролики не запихнешь, а их может быть более 20.
Мало кто ценит прозрачность процесса и важность его постановки, пока так сказать ломают дрова :) А еще меньше люди ставят себя на место заказчика, у большинства вазимодействие строится на доверии и «авось».
На счет офисов (не обязательно крупных) мы уже некоторое время работаем в этом направлении и для них не требуется использования сайта, для них есть standalone или saas решения. Надеюсь в ближайшее время сообщим о какой-нить success story в этом плане.
в данном случае качественные и количественные показатели обсуждения мало о чем говорят: может быть не та аудитория, может быть не та тема, может быть все что угодно.
личный опыт говорит о необходимости подобного инструмента и отсутствии аналогов, в России как минимум.
Сразу не получилось сгруппировать информацию так, чтобы она не перегружала… Делемма тут такая: информации много, но если ее спрятать за большим количеством вложенных страниц, то приходящий человек не очень понимает что за сервис, поскольку все скрыто и как куда добраться неизвестно.
Пока решили, чтобы показать какая информация вообще доступна выложили практически все для быстрого доступа.
Когда реализуем основной функционал наверно разложим информацию по целевой аудитории: в разделе для заказчика будет сосредоточена информация для него, в разделе для шароварщиков — для него, в разделе для аутсорсера что-то будет нужное ему, наверно как-то так, что скажете?
проблема шаблонов в том, что они под блоги, сайты визитки и т.п. Нам же нужен шаблон, который сможет охватить все наши разделы, такого не удалось найти.
может у Вас есть на что посмотреть?
А Вы бы что порекомендовали в этом смысле?
Мы предлагаем инструмент, пользоваться им или не пользоваться естественное дело выбора каждого.
вопросом рекламы скоро займемся, но видимо основное — это должна быть контекстная реклама, ориентированная как на заказчиков, так и на исполнителей. На «ломанулись» не рассчитываем, ниша довольно специфична и главное — интрумент должны попробовать, пока планируем выступления на конференциях, чтобы сформировать какое-то ядро.
Вы бы что порекомендовали?
на ± 3 дня конечно можно уговорить, но неделя, а тем более несколько при команде > 3 человек вылетит заказчику в копеечку.
а если говорить о заказной разработке (не r&d), то заказчика всегда интересует срок и стоимость, имхо, даже если есть видимость прогресса
Однако, приведенной в моей статье формулы вы там не встретите, и вообще в «планировании» все очень абстрактно описано, как идея — замечательно, но как это использовать… я представил свой вариант практического применения.
Можете немного охарактеризовать разработку? Что заставило вас потратить два года на разработку инструмента, у которого масса аналогов?