Нам хватило одного столбца: как Kanban работает в бэк-офисе

Привет, Хабр! На связи снова Иван Чаплыгин, руководитель отдела ИТ-переводов КРОК. Сегодня хочу рассказать, как Kanban – подход, заточенный прежде всего под нужны разработчиков, можно использовать в бэк-офисе. Под катом – наш нехитрый опыт внедрения Kanban в дашборды Jira. Я думаю, вы все – как айтишники и завсегдатаи Хабры – гораздо лучше меня знаете, что такое Kanban. В общем случае это доска объявлений задач, разделенная на несколько столбцов. В одном столбце – что хотим и собираемся делать, во втором – что делаем сейчас, а в третьем – что уже сделали. Но если с разработчиками все понятно, то как применить этот подход в бэк-офисе, в частности, в отделе переводов? Мы об этом особенно не задумывались, пока работали в отделе переводов КРОК два человека, переводили по паре пресс-релизов и презентаций в неделю и горя, именуемого «режимом многозадачности», не знали. Но времена менялись. Бизнес развивался, запросов на перевод поступало все больше, и ими надо было как-то управлять. Много лет назад мы записывали задачи на флипчарте – практически вариант с наскальной живописью, потом перешли в Microsoft OneNote. Но там любые случайные удаления данных нельзя было ни откатить, ни отследить, что лишь добавляло хаоса в наши ежедневные процессы. Через какое-то время компания перешла на Jira, и возникла идея сделать цифровой флипчарт уже там. На входе мы получили кучу разных окон, диаграмм, графиков — то есть много разной информации, в которой довольно сложно разобраться. В результате нехитрых манипуляций с настройками и доработки Kanban-подхода под свои нужды мы сделали из Jira незаменимый инструмент, который сильно облегчает нам жизнь. Вполне возможно, наш кейс окажется полезен и для других групп и отделов бэк-офиса. Но обо всем по порядку. Отдел переводов работает по сервисной модели, то есть сами мы запросы не инициируем и проекты не запускаем. Наша задача – быстро и качественно отработать запросы, приходящие от внутренних заказчиков. Одному надо презентацию на английский перевести для выступления на конференции, другому – технико-коммерческое предложение, третьему – финансовую отчетность и т.д. Администрирование таких задач обычно преследует несколько целей: нужно проконтролировать, чтобы: Ни одна задача не потерялась среди тонны писем в корпоративной почте. У каждой задачи установлен адекватный срок и, учитывая ее объем и сложность, нам хватает и времени, и ресурсов, чтобы сделать нормальный перевод. Перевод действительно отдали вовремя. Помимо функции контроля, требовалась и функция отчетности, чтобы в конце квартала, полугодия или года выгружать в Excel нужные данные по всем задачам, анализировать производительность группы и процентное соотношение разных типов задач в общем котле. Мое глубокое убеждение (и не только мое): чем проще система, тем эффективнее она работает. Исходный интерфейс Jira с кучей дашбордов показался мне, мягко скажем, избыточным, поэтому я стал удалять оттуда дашборды один за другим. Сам Kanban-подход мне тоже кажется избыточным, когда речь заходит о группах бэк-офиса, да еще работающих, как мы, по сервисной модели. Отрезаем лишнее, или два принципиальных «все равно» В принципе нам все равно, какие задачи нас ждут в будущем, потому что, к сожалению, в нашем случае это совершенно не прогнозируемый и не планируемый процесс. Пока задача на нас не упала, мы про нее ничего не знаем и ее не видим, то есть первый столбец Kanban-модели нам не нужен. Задачи же, которые уже пришли, но еще не взяты в работу, могут точно так же лежать в общем котле – достаточно на входе автоматически присваивать им определенный статус. Например, в Jira есть статусы «в плане», «в работе», «на проверке», «завершено» и «на оценке». Каждой новой задаче автоматически присваивается статус «в плане», и лежит она себе, никому не мешает, ждет своего исполнителя. При этом она не потерялась, никуда не делась, и в любой момент можно все задачи отфильтровать по статусу и увидеть, сколько задач сейчас «в плане». В принципе нам все равно, что происходит с задачей после того, как мы ее сделали. Да, мы собираем обратную связь с коллег и все такое, но в тот момент, когда задача выполнена, то есть результат отправлен заказчику, она перестает для нас существовать. А значит, третий столбец Kanban-модели нам тоже не нужен. Получается, что для адекватного управления потоком задач нам нужен лишь один столбец Kanban – средний, и все. То есть в Jira нам нужен лишь один дашборд – «Незавершенные задачи, назначенные нашему отделу». Фильтры настроены так, что в этом нашем единственном дашборде видны только задачи со статусом «в плане», «в работе» и «на проверке» (в нашем случае «на проверке» – это этап проверки перевода редактором). Как только исполнитель меняет статус задачи на «завершено» или на «на оценке», задача пропадает из дашборда. Мы ее больше не видим и не отслеживаем. Ничего не потерять – воронка задач Новые задачи попадают в дашборд двумя способами. Идеальный вариант: пользователь создает задачу на перевод через нашу корпоративную витрину сервисов. В этом случае задача попадает в наш дашборд сразу, причем большинство полей в ней уже заполнено инициатором заявки. Как обычно бывает: пользователь нам пишет в мессенджер или в почту на рабочую рассылку переводчиков или конкретному переводчику. В этом случае задача в дашборд не попадает, но нам достаточно в пару кликов переслать это письмо (или скопировать сообщение из мессенджера и отправить его) на технический адрес электронной почты, который инженеры отдела внутренней техподдержки создали специально под наш дашборд, и тогда задача появится у нас в Jira. То есть даже при самом большом аврале и цейтноте можно выделить 5 секунд на то, чтобы отправить или, как мы обычно говорим, «пульнуть» задачу в Jira – так она точно не потеряется и будет спокойно дожидаться своего часа, когда освободившийся сотрудник заполнит в ней недостающие данные, свяжется с заказчиком и уточнит у него дедлайн и желаемый результат. Когда переводчик таким образом пересылает задачу в Jira, он автоматически становится ее автором (то бишь заказчиком), поэтому в ходе редактирования данных задачи нужно будет поменять ФИО переводчика на ФИО инициатора. Зато, отправляя задачу из почты в Jira, переводчик может сразу назначить ей исполнителя, просто указав конкретного человека в копии письма. В результате риск потери задачи сведен практически к нулю. Вместо кучи дашбордов у переводчиков остался только один. Осталось определить, какая информация нам в нем нужна, точно ли она нам нужна и если да, то зачем. В сухом остатке – из чего состоит дашборд На скриншоте – пример типичной задачи, которая отдельной строкой выведена в Jira. Мы пришли к выводу, что это минимальный набор полей, который нам нужен для адекватного администрирования задач. Приоритет. На скриншоте «синие стрелочки» означают приоритет «желательный», и он ставится на все задачи по умолчанию. Есть еще приоритеты «важный», «критический» и «блокирующий» – с каждым из них стрелочки будут все больше краснеть, а мы будем понимать, что эту задачу надо делать не в обычном режиме, а чуть быстрее или сильно быстрее. Создано. Это дата создания задачи. При прочих равных сначала отрабатывается запрос, который пришел раньше. Кроме того, если у задачи нет конкретного дедлайна, но она уже слишком долго висит, мы это тоже поймем, посмотрев на дату в поле «создано». Автор. Тот, кто заказал перевод. При заказе через корпоративную витрину сервисов тут был бы сразу указан инициатор задачи. Поскольку в нашем примере я пересылал письмо из почты, автором указан я, а значит, при обработке запроса мне надо будет поменять мое ФИО в этом поле на ФИО инициатора. Код. Это код, который система присваивает задаче. Иногда по нему удобно ее искать в системе, хотя мы почти дошли до той степени просветления, чтобы этот столбец убрать. Тема. Заполняется в свободной форме и по возможности лаконично, чтобы строки в дашборде не раздувались. Поле нужно для общего понимания, что это за задача. Как вариант, тут может быть написано «редактура описаний проектов», «расшифровка митапа» или «устный перевод на встрече – название компании-заказчика». Исполнитель. Переводчик, которому назначена задача. Как видно на скриншоте, пока исполнитель не назначен. Слова. Важный параметр для письменного перевода. Так мы понимаем объем задачи. Условно в среднем на перевод вручную презентации объемом 2438 слов уйдет один рабочий день и еще полдня на редактуру. ЗСП. Раньше это было поле «знаки с пробелами», т.к. объем текста считался не по словам, а по количеству знаков с пробелами согласно статистике MS Word. Сейчас поле устарело, и посему мы наполнили его новым содержанием. Придумали цифровые обозначения (а поле поддерживает только числовые данные) для разных видов перевода. Например, 666 – это полностью машинный перевод, 777 – машинный перевод с вычиткой человеком, 0 – написание текста с нуля, например, статьи на Хабр. Срок исполнения. Он же дедлайн – когда мы обещали отдать перевод. В задаче поле отображается в виде календаря, и нужно просто выбрать дату. Статус. На скриншоте у задачи статус «в плане». Потом назначенный исполнитель сможет перевести ее в следующие статусы «в работе» и «на проверке», и в конце «на оценке», после чего задача пропадет из дашборда. В самой карточке задачи заполняются дополнительные данные, которые не нужно выводить на дашборд: Тип задачи (у нас это поле называется «Компоненты»): перевод, устный перевод, редактура или заверение перевода у нотариуса. Департамент, к которому относится инициатор. Путь. Папка на сервере, где лежит переводимый текст и все сопроводительные материалы. В конце периода можно составить любой отчет, отфильтровав данные по нужным полям, и выгрузить его в Excel, что тоже довольно удобно. Информация по всем завершенным и пропавшим из дашборда задачам будет в этом отчете при условии, что сама задача удовлетворяет условиям фильтрации. Кроме того, всегда можно отфильтровать данные в дашборде по любому из столбцов и так понять, сколько задач сейчас «в плане», сколько задач на конкретном исполнителе или от конкретного автора. Дашборд очень гибкий, можно добавлять новые столбцы и убирать те, что больше не нужны для работы. Заключение Надеюсь, наш подход будет полезен для других подразделений бэк-офиса. Конечно, везде своя специфика, но мне видится, что некий скандинавский минимализм в администрировании задач – эффективная стратегия, которая закрывает базовые потребности контроля и отчетности и при этом сводит к минимуму рутинные задачи администрирования. А про свою работу и ИТ-переводы в целом я еще пишу в телеграм-канале "X-ren переведешь". Не проходите мимо.