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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

• Scrumwise - API

• Справочник по JIRA Cloud REST API

• API-интерфейс Alfresco Content Services