А давайте мерятся абстрактными числами

[metaclass]

У кого сколько задач в баг-трекере? У меня получается так:
За последний год/два года:
123/178 открытых
240/450 закрытых

У ребе belnetmon за аналогичные периоды:
13/18 открытых
216/540 закрытых

Похоже, что надо прекращать практику ставить себе неразрешимые задачи и записывать их в баг-трекер, это демотивирует.
Было бы еще неплохо статистику по сложности задачи сделать, но это в баг-трекере видно лишь косвенно, а вместо подзадач для сложных задач я использую комментарии к основной задаче.

PS: А теперь, внезапно, кто больше всех работает: kometa_zxc
47/0 открытых
274/575 закрытых

Comments

[zelanton.livejournal.com]

степень разбивки у разных людей различается на порядки - сравнение числа записей бессмысленно. Собственно и разбивать уже логично в системе планирования, а в багтрекере вести лишь укрепнённые ожидаемые результаты работ.

[vp.livejournal.com]

Я не думаю, что на порядки. Смысл багтрекера как средства учета рабочего времени (работы наз конкретной задачи) тогда сильно теряется. Хотя да, бывают большие куски, но желательно, конечно, чтобы по этому делу однозначно оценивалась активность работника, а не висящее 1 год задание типа "сделать все" :)

[zelanton.livejournal.com]

Система планирования.
Во-первых учёт прошедшего времени задача менее приоритетная, чем грамотное планирование времени будущего. Кроме собственно механического распределения работ это даёт менеджерам удобный инструмент для определения наличия ресурсов и расстановки приоритетов.
Во-вторых в подобных системах более развиты средства собственно оценки (отчёты и т.п.)
В-третьих, календари, обсуждения лучше интегрируются именно с системами планирования.
В-пятых системы планирования лучше интегрируются с канцелярским документообором.

И самое главное - любой крупный проект предполагает участие нескольких подрядчиков, а значит там действуют схемы взаимодействия менеджмента. И это как правило именно что система планирования, с багтреккером никто работать не будет, там инструменты не годятся.

А дублировать смысла нет, актуальная информация должна быть в одном месте.

В общем, в твоём случае вы имеете набор карточек, в моём - наглядные план-графики, опережающую информацию о загрузке исполнителей на будущий период.

А в багтреккере висит задача например "переписать продукт такой-то под, хехе, облако, срок 4 месяца, ответственный тот-то". Больше там ничего не нужно.

И глубина детализации планов отличается очень значительно, именно что на порядки. Особенно это от характера задачи зависит.

[vp.livejournal.com]

Мы привычно называем словом "багтрекер". На самом деле, пользуемся системой управления проектами. Там и планы, и контроль активности, не только баги. Целых два раздела - сугубо информация о клиентах, например. Там же ведется трекинг обслуживания.

[zelanton.livejournal.com]

а, ну тогда ок

[zelanton.livejournal.com]

у нас багтреккер - отдельная система. Туда автоматом складываются текущие баги, и хотелки и связанная с ними переписка. Конкретные планы - отдельно.

[vp.livejournal.com]

А чем вы пользуетесь для управления проектами?

[zelanton.livejournal.com]

менеджеры от внедрения и маркетинга - MS Project
менеджеры от программирования - частично MS Project, частично собственная разработка.

[zelanton.livejournal.com]

Причём багтреккеров тоже два - один helpdesk для автоматизации работы с почтой, второй - на базе собственной разработки, благо разрабатываемая система управления данными позволяет и не такое. Собственно "собственная система управления проектами" сейчас в её контексте реализуется.

То есть контекст внешнего взаимодействия с клиентами слегка отделён от внутренней кухни. Оно тесно взаимодействует, хотя там ещё есть над чем работать.

Ну и изначальный тезис никуда не делся - степень детализации даже у одного и того же человека по разным работам может отличаться на порядки. И простой счёт тут абсолютно ничего не даёт.

[metaclass.livejournal.com]

Клиенты и обслуживание - это вообще CRM, просто у нас нету смысла внедрять и его и планирование отдельно.