Багтрэкинг, работа с ним или без него

Не исключительно мое мнение:
Основное назначение трекера - дать возможность руководителю работ управлять реестром работ по проекту. Реестр задач на исправление багов,  подмножество реестра работ по проекту.”

Рекомендуемая последовательность:

  1. Внедряем процесс ведения реестра.
  2. Внедряем процесс управления реестром.
  3. Внедряем процессы создания развернутых описаний элементов реестра.

Обычно пытаются внедрять процессы в обратном порядке. С известным заранее результатом. Еще одним удивительным феноменом является иногда встречающееся нежелание руководителей заниматься управлением. Поэтому шаг “2″ иногда внедряется со скрипом. Лесть, уговоры, убеждение - все должно идти в ход. Потому что если нет управления реестром, то нет управления в целом. И неважно, что это - проект по созданию системы или процесс сопровождения. Да, модели управления отличаются, но управление должно быть.

“Если руководитель на регулярной основе не занимается управлением реестра, то с управлением проблемы”. И, очень вероятно, бактрекер не нужен. Если вы не собираетесь делать шаг “2″, то зачем вам шаг “1″!?
Кстати. “Внедрение процесса управления реестром” дает огромный эффект. Вполне может получиться, проект по разработке системы удастся сделать в 1.5 - 2 (это не только моя оценка) раза быстрее.

Комментариев: 3

  1. Mantis написал:

    С исходным мнением полностью согласен.
    Заинтересовало, что такое и чем отличаются между собой “процесс ведения” и “процесс управления”. Подскажите, где можно дальше почитать по этой теме?

  2. SALar написал:

    Заинтересовало, что такое и чем отличаются между собой “процесс ведения” и “процесс управления”. Подскажите, где можно дальше почитать по этой теме?
    Вот чтобы описание было только об этом - это вряд ли.
    Вскользь об этом упоминают Андрей Степенко с напарником в рассказе про внедрение теории ограничений на предприятии металлообработки. 3 месяца они ставили учет и три месяца управление. Через 6 месяцев завод начал показывать настолько невиданные результаты, что заказчики восхищенно матерились.
    Еще примерно об этом же есть один комментарий в книге “Записки автоматизатора”: “Полезно также помнить, что автоматизация учета должна предшествовать автоматизации планирования. Почему-то иногда пытаются сделать наоборот.”

    Как ни странно, “внедрение процесса ведения реестра”, далеко нетривиальная задача. Наверное, об этом лучше отдельную статью. или цикл статей. Но тренинг точно лучше.

  3. Тем, кто занимается поддержкой программного обеспечения | Необходимого достаточно написал:

    […] 4. Прозрачная деятельность отдела и управление задачами Помимо задач по поддержке программного обеспечения на регулярной основе ведутся дополнительные разработки. При выполнении основной задачи очень часто поступают звонки и возникают задачи, которые требуют реакции, иногда немедленной. Существуют системы заявок (тикетов), которые позволяют определить работы, описать их, задать им срок, приоритет. После того, как список сформирован, разработчики выполняют задачи вначале с наивысшим приоритетом и, далее, с более низким приоритетом. Это позволит руководству оценивать текущую загруженность отдела, принимать решения об изменении приоритета и сроках. Данный пункт предполагает работу над управлением задачами, их четкую постановку, управление рисками и сложен во внедрении, особенно он встречает сопротивление со стороны непосредственных руководителей разработчиков программного обеспечения, так как им приходится работать, а обычно работать не хотят. По ссылке http://blog.shumoos.com/archives/298 немного информации об этом. […]

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.