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

31

У меня всегда была такая борьба, чтобы люди обновляли свои проблемы, как в моей компании, так и на работе. У меня было несколько случаев, когда люди действительно делали это по доброй воле своего сердца, но ~ 70% времени мне приходилось гоняться за людьми.

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

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

dukeofgaming
источник
21
Исходя из личного опыта, проблема заключается в том, что обновление системы отслеживания проблем и хранение надлежащей документации в целом не так важны, как кодирование. И хотя это несколько естественный менталитет для разработчика, он не должен быть для менеджмента и компании в целом. Ваша компания рассматривает эту часть работы так же важно, как кодирование? Если нет, вы должны начать с этого, разработчики умны и адаптивны, если они чувствуют, что компания действительно считает это большим делом (с похвалой, когда все сделано правильно, и последствиями, когда нет), они скоро начнут делать это правильно.
Яннис
@YannisRizos Этот комментарий достаточно хорош, чтобы быть ответом
dukeofgaming
14
Ах! Я даже не могу заставить своего босса использовать систему отслеживания проблем. Он проходит мимо, быстро говорит о «мелочах» и уходит. Я называю это «сообщениями об ошибках на автомобиле». На самом деле меня высмеивают за использование системы отслеживания проблем ... Я чувствую некоторое разочарование в Силе.
MetalMikester
3
ИМХО, большинство «трекеров проблем», которые я видел, плохо сосут - пользовательский интерфейс оказывается слишком громоздким (поэтому они могут обрабатывать особые случаи). Так что, если вы спросите меня, почему я их не использую, вот почему.
GrandmasterB
1
По сути, убедитесь, что у вас есть приложение, которое работает хорошо, легко в использовании, быстро и не требует слишком много информации для ввода. Кроме того, необходимо классифицировать дефекты, например, что делать в следующем выпуске, и необходимо использовать введенную информацию. Например, если разработчик объясняет все правильно, но вы слишком ленивы, чтобы прочитать его, а вместо этого спросите его, тогда очевидно, что человек потерял бы мотивацию использовать систему, так как очень сложно объяснять одно и то же дважды.
Phil1970

Ответы:

30

Причина в том, что они не понимают, почему они должны обновлять систему отслеживания проблем, кроме того, что вы так говорите.

Почему это? Я предполагаю, что обновление трекера никак не повлияет на их работу, поэтому решение, вероятно, состоит в том, чтобы внедрить систему слежения, которая фактически помогает им лучше выполнять свою работу.

Мартин Викман
источник
«внедрить систему отслеживания, которая на самом деле помогает им лучше выполнять свою работу». Можете привести пример? Что-то, что им помогает, а не конкретная система отслеживания.
Бурхан Али
2
@BurhanAli Нет, я не в состоянии сказать им, что работает для них. Они должны понять это для себя. Предложение: начните с чего-то простого и используйте еженедельные отзывы, чтобы улучшить его.
Мартин Уикман
Ваша команда может отличаться, но, например, я стал гораздо лучше обновлять средство отслеживания проблем, когда начал использовать его в качестве коммуникационного центра, чтобы меня не прерывали так часто, пока я глубоко в коде.
Морген
13

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

Покажи, не говори. Например. не говорите, что вам (или вашему начальнику) нужны данные для отчета. Показать от сотрудников точки зрения , как уточненный отслеживания проблем влияет и помогает им.

Подавать пример.

Maglob
источник
10

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

Вот что заставило бы меня использовать трекер все время:

  • Полная интеграция с IDE и системой контроля версий. Мы используем какое-то неуклюжее веб-приложение, потому что для него уже были куплены лицензии. Создание / обновление задач занимает вечность, и имеет некоторые запутанные функции пользовательского интерфейса. К сожалению, использование этого находится вне контроля нашей команды.

  • Простота. Под этим я подразумеваю не брать 10 полей, заполненных вручную, просто чтобы добавить задачу. Почасовые оценки и время завершения, ввод вручную проекта / компонента / и т. Д. в нескольких полях и т. д. просто увеличьте количество времени.

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

Kryptic
источник
8

Прежде всего: что вы имеете в виду, когда люди обновляют свой прогресс?

Вы имеете в виду «разработчики, обновляющие текущую оценку», или «разработчики, не устанавливающие проблему для решения», или, скорее, «клиенты / тестировщики, не закрывающие решенную проблему», или все вместе?

С точки зрения разработчика, это смесь мышления и культуры.

  • склад ума: когда вы устанавливаете проблему для решения, это означает, что вы сделали, и несете ответственность, если она глючит
  • культура: если вся компания не очень заинтересована в использовании таких инструментов, но предпочитает другие организационные стратегии

Мой опыт таков: вам нужно, чтобы культура указывала в правильном направлении, по крайней мере. Далее следует определить DoD (определение «выполнено») - если разработчик (работает и для других ролей) может сказать, что он выполнил весь список, который он снимает, чтобы отметить решенную проблему и продолжить без необходимости оглянуться назад.

Энди
источник
5

Перестаньте спрашивать о прогрессе кодирования (обычно это произвольный процент, вырванный из воздуха в любом случае), пока билет не будет закрыт. Если главное измерить количество закрытых билетов, то оно улучшится.

Однако обратите внимание, что все метрики могут быть игровыми, и метрики, как правило, работают лучше, когда объединяются с дополнительными метриками, например, вы, вероятно, также хотите посмотреть на проблемы, которые вновь открываются, поскольку это подразумевает, что они преждевременно закрываются

JK.
источник
5

Как указывают некоторые другие ответы, правильный вопрос здесь, вероятно, таков: почему у вас есть система отслеживания проблем? Хороший ответ на этот вопрос (не только с точки зрения управления, но и с точки зрения разработчика) необходим, если вы хотите, чтобы система отслеживания проблем действительно работала и регулярно обновлялась.

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

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

Чтобы дать полномочия системе отслеживания ошибок, я бы предложил следующее:

  • Разработчики работают только над ошибками / функциями, зарегистрированными в системе отслеживания проблем, и за ее пределами не выполняется никаких работ. Все идеи, проекты по рефакторингу, новые функции, настраиваемые инструменты и т. Д. Также должны быть зарегистрированы.
  • Вопросы прорабатываются в порядке приоритета. Приоритет должен частично определяться руководством, но разработчики должны определенно иметь право голоса при определении приоритетов. Это особенно верно, когда речь идет о вопросах обслуживания и рефакторинга.

Что касается обработки, вы можете использовать что-то вроде следующего:

  • статус «новый» означает, что разработчик еще не обнаружил проблему и все еще находится в очереди приоритетных проблем.
  • Статус «назначен» означает, что он был назначен разработчику. Это может сделать разработчик или кто-то еще, например, руководитель группы. Я считаю, что хорошо работает, когда каждому разработчику назначается несколько проблем, и обычно это сочетание «тяжелой работы», такой как новые функции и легкая комплектация, такая как простые ошибки или некоторые простые работы по обслуживанию. Это позволяет разработчикам выбирать работу в зависимости от их настроения.
  • Статус «в процессе» означает, что разработчик работает над проблемой. Только один или два вопроса на разработчика должны быть «в процессе» в любой момент времени.
  • как только проблема будет решена, разработчик может изменить статус проблемы на «нуждается в тестировании» и сменить владельца на тестера. Это важный шаг, так как это также рабочая очередь тестировщиков.
  • тестировщики могут изменить статус либо на «проваленное тестирование» и вернуть право собственности разработчику, что означает, что он переходит в начало очереди для разработчика, либо они могут изменить статус на «готов к развертыванию».
  • проблемы со статусом «готов к развертыванию» могут быть объединены и выпущены в соответствии с циклом выпуска, кто бы ни отвечал за выпуски.

Вкратце: сделайте систему отслеживания проблем неотъемлемой частью процесса разработки, и вам не придется беспокоиться о проблемах, которые не обновляются.

Мауриц Хансен
источник
3

Возможно, они считают слишком большой работой, чтобы открыть браузер, войти в систему, найти билет и заполнить его. Может быть, вы можете попытаться поощрить их с помощью крючков . В настоящее время распространенной особенностью является то, что в сообщении git / hg [я предполагаю, что вы используете один из них] вы можете напечатать что-то вроде «FIXED # 123», и тикет автоматически изменится, когда вы нажмете свой коммит. Таким образом, это почти не работает для разработчика [если он работает над каждой проблемой в отдельной ветке - у него уже есть идентификатор билета], и, скорее всего, он добавит эти пару символов в сообщение коммита. Если этого решения недостаточно, может быть, это означает, что объем заявок слишком велик, и его следует разделить на множество меньших билетов?

MKK
источник
3

Это звучит как вопрос корпоративной культуры больше всего на свете. Кто установил необходимость использования трекера? Если это что-то, что выбрасывает один человек или группа, и ожидает, что все остальные просто примут и используют, удачи. Если люди не понимают, что это такое, не знают, как им пользоваться, и не признают, что это действительно облегчает их жизнь (их жизнь, а НЕ вашу), они не будут использовать ее без принуждения со стороны руководства. Тем не менее, если использование трекера является решением компании, то оно должно быть на управлении, чтобы обеспечить его соблюдение. Если ваша роль не включает в себя ответственность и полномочия, чтобы заставить / заставить людей использовать трекер (звучит как «нет», как вы указали, что вы разработчик), вы не уйдете очень далеко, независимо от того, что вы делаете (реально IMHO ).

huntmaster
источник
2

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

Многие средства отслеживания ошибок интегрируются с IDE. Например, средство отслеживания рабочих элементов TFS позволяет пометить задачу как решенную при выполнении регистрации. Есть даже опция, требующая, чтобы регистрация была связана с задачей. Включение обновления рабочего элемента в процесс регистрации упрощает процесс. В качестве альтернативы можно открыть трекер проблем в отдельном интерфейсе для выполнения изменений.

Другим вариантом является проведение совещания по статусу (или во время ежедневного ожидания), когда кто-то открывает трекер и обновляет задачи, когда люди предоставляют статус.

Майкл Браун
источник
0

Одна вещь, которую нужно принять во внимание, - сам графический интерфейс, являющийся препятствием. Например, некоторые препятствия могут включать:

  • Слишком много кликов
  • Неоптимизированный или недостаточно мощный сервер приложений для отслеживания проблем
  • Плохое удобство использования или доступность

Предоставление API позволит обновлять систему отслеживания проблем с помощью сценариев, аналогичных техническим артефактам (покрытие кода, отчеты о модульных тестах, состояние сборки и т. Д.).

Ссылки

оборота Пол Свитт
источник
На одном из моих рабочих мест мы использовали Jira, и первые полтора года я стал причиной, по которой я научился ненавидеть его - он был медленным, раздутым, процесс был плохо определен, мне пришлось отмечать проведенное время в Jira, в моем собственном персональное программное обеспечение для отслеживания времени и в проприетарном программном обеспечении, которое не помогло. Если обновление трека между щелчками занимает больше секунды, это слишком долго. В конечном итоге я научился любить Джиру, когда в него было добавлено лучшее оборудование, и процесс был завершен.
Maurycy