вСтатьи

Интерфейс одной кнопки

Представьте, однородную и относительно небольшую группу сотрудников, выполняющих однотипные задачи (редакторы статей или фотографий, переводчики). Есть входящий поток задач и ресурсы, между которыми нужно распределять задачи. Всё просто… Нужно спроектировать интерфейсное решение распределения задач. Задачу я решал несколько лет…

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

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

Итак, у нас есть входящий поток задач и ресурсы, между которыми нужно распределять задачи. Всё просто… Нужно спроектировать интерфейсное решение распределения задач.

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

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

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

Через пару лет я снова оказался перед необходимостью решить эту задачу. И в этот раз решение пришло как-то подозрительно быстро 🙂

Я начал привычно думать о скорости обновления списка, как задумался над вопросом: «а сколько элекментов должно быть в списке?» Понятно, что весь перечень заданий вываливать в виде списка неразумно:

  1. их может быть очень много
  2. вряд ли пользователи будут просматривать его далее 50-го элемента, или 40-го, 30-го… 10-го?

И тут-то случился инсайт!

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

Должна быть просто кнопка… одна кнопка! «Новая задача». И система сама выберет первую задачу из списка, которая еще никем не выполняется. Так будет решена проблема с коллизиями, и так будет снята необходимость ненужного выбора.

Мда… Такое простое решение искать несколько лет?!

Вопрос: А если сотрудник все таки захочет переводить один текст, а не другой? Явное игнорирование желаний сотрудников. Как будто они какие то роботы или мыши лабораторные =)

Да, действительно, у пользователя могут возникнуть незапланированные желания:

  1. Не выполнять текущую задачу
  2. Заняться чем-нибудь ещё
  3. Не работать вообще
  4. и т.д.

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

Я же говорил о ситуациях более «индустриальных»: есть тысяча писем, которые нужно перевести и в срок доставить получателям. Чтобы справиться с такими объемами, нужно работать как на конвейере.

Люди, обслуживающие технологические процессы, всегда похожи немного на роботов, в том смысле, что их работа автоматизирована, распланирована, и подконтрольна.

Комментарии

комментариев