Этот подход приводил к следующим эффектам:
- задачи в среднем решались довольно быстро (особенно если были хорошо сформулированы), но в некоторых случаях могли по случайным причинам попасть в конец очереди и осесть там на недели. Когда же мы наконец добирались до них - выяснялось, что клиент уже потерял к ней интерес, на письма не отвечает или повторить проблему не удается.
- относительно быстрое решение части задач приводило к нереалистичным ожиданиям относительно того, как быстро мы на самом деле можем исправлять проблемы. Задачи решались не в порядке их важности/очередности, а скорее в зависимости от настойчивости/заинтересованности клиента. Более того, так как этот способ помогал - мы сами провоцировали подобное поведение, а в итоге весь топ-лист оказывался забит абсолютно срочными задачами, которые нужно сделать сегодня-завтра.
Сейчас решили разгребать текущие задачи исключительно в порядке поступления (при этом задачи от клиентов имеют более высокий приоритет, чем наши собственные идеи). Пока заметил такие следствия:
- наконец-то дошли руки до задач, которые в списке висели месяцами. Раньше их было удобно откладывать "на потом", т.к. есть более актуальные задачи, теперь же они "мозолят глаза" постоянно.
- т.к. разработчик не начинает делать только что поступившую задачу немедленно, то у других сотрудников появляется шанс вмешаться в процесс, запросить у клиента недостающие данные, попробовать повторить проблему и решить проблему. Таким образом снижается нагрузка на разработку, т.к. часть задач до нее просто не доходит (а та что доходит - повторяется).
- мы можем лучше прогнозировать когда задача будет решена просто ориентируясь на длину очереди.
