Как пасти желтых котов. Практика разделения оперативного и финансового учета для увеличения выработки сотрудников

О нашей компании

Я руковожу компанией «Арт Порт», которая входит в группу компаний «Арт Софт». Нашей группе компаний уже более 25 лет, мы разрабатываем отраслевые решения для портов, зерновых терминалов, элеваторов и т.д. – в основном занимаемся транспортной и портовой логистикой.

Я сам в 1C с 2012 года – сначала был просто разработчиком, потом стал руководителем разработки, т.е. вырос из разработчика в руководителя проекта.

Изначально наша фирма занималась только продуктами 1С (мы работаем в Украине и внедряем продукты из линейки «1С для Украины»), но впоследствии у нас начали выделяться отраслевые решения, на разработке/ сопровождении которых мы стали специализироваться, а поскольку это нестандартный процесс 1С франчайзинга, у нас есть множество особенностей:

• Во-первых, мы зависим сами от себя, поскольку 80% нашей работы – это разработка/ продажа/ внедрение наших собственных отраслевых решений.

• Во-вторых, большинство отраслевых решений возникают на основании опыта какого-то внедрения. Например, мы один раз адаптировали какой-нибудь УНФ под зерновой терминал/ железнодорожный цех, а потом увидели, что это интересно ещё для нескольких компаний, и превратили это в некое тиражное решение.

Проблемы учета работ сотрудников

Я часто замечаю, что мы, разработчики-франчайзи, как «сапожники без сапог». Несколько лет назад на партнерском семинаре 1С Борис Нуралиев озвучил идею, что при внедрениях нужна «реальная автоматизация», когда автоматизируется все, что можно, и только это поможет привлечь новых клиентов. И мы действительно на внедрениях стараемся автоматизировать клиенту все – от бухгалтерии до влияния количества кофейных зерен на себестоимость продукции. Но при этом самих себя как разработчиков мы автоматизировать не можем.

И хотя существуют инструменты и практики для автоматизации рутинной деятельности разработчиков (направление автоматизации тестирования, DevOps), большинство руководителей ИТ-шных проектов согласится с тем, что сейчас они пока что только начинают развиваться, и очень немного команд используют их в своей работе.

Так вот, три года назад, когда я только начал непосредственно руководить разработчиками, а не быть в их числе, мы в компании для собственного учета использовали программу УНФ – она использовалась для ведения взаиморасчётов с клиентами/ выставления счетов и т.д.

Работы сотрудников мы в УНФ регистрировали через «Задание на работу» и «Учет времени». Причем сотрудники заполняли «Задание на работу» полностью самостоятельно, вручную устанавливая, какой вид работы попадет в счет клиенту, отражали часы, как хотят и т.д. И в случае, если их вовремя не проконтролировать, это могло привести к проблемам.

В целом, был бардак:

• Бэклога как такового не было, «Задание на работу» могло иметь только два состояния – «Запланировано» и «Завершено». Эти два статуса не давали понять, что у нас происходит вообще с проектом и с каждой задачей. Кроме этого, не учитывались предыдущие этапы – когда задача еще находится на согласовании (когда просто возникла какая-то идея, и мы ее еще обсуждаем), когда конкретный исполнитель для задачи еще не назначен и т.д.

• Как я уже сказал, УНФ не предполагает детализации статусов задач, а мне, как руководителю, было важно знать – планируемые сроки выполнения задач, их приоритет, какие задачи сейчас в процессе, какие на тестировании внутри у пользователя, какие на code review и т.д.

• Отсутствовала понятная визуализация задач. Сегодня уже говорили, что удобнее всего работать с задачами в системах типа Trello, Jira – подобная визуализация очень нужна, потому что в обычном перечне задач не понятно, что у нас происходит.

• Одно «Задание на работу» не всегда соответствовало одной задаче, при этом расшифровка счета, который выставляется клиенту, всегда детализировалась по задачам, т.е. одно «Задание на работу» соответствовало одной строчке расшифровки счета. Но поскольку сотрудники вносят описание задачи для клиента сразу напрямую, то возникает проблема – что делать, если у одной задачи несколько исполнителей? Например, в спецификации прописано: «Разработка подсистемы взаимодействия с весами» – одна задача на 50 часов. И хотя ей по факту будут заниматься: администратор, который найдет драйверы для весов, 1С-разработчик, тестировщик, консультант, сервис-инженер и т.д., но клиенту все эти действия не выставляются как отдельные строчки – ему выставляется как одна строка. Таким образом нам было нужно иметь возможность указывать на одну задачу несколько исполнителей.

• Не было детального учёта времени – было непонятно, сколько на какую задачу затрачено времени фактически. Да, не все время является для сотрудника оплачиваемым, но знать, чем занимался, нужно. В УНФ для этих целей есть документ «Учет времени», но его не очень удобно было вести, потому что сотрудникам иногда приходится переключаться между разными задачами, и получается, что нужно выключить трекинг одной задачи, переключиться на другую и т.д. – это проблема.

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

Требования к системе учета задач

Когда мы проанализировали проблемы учета времени, мы сделали выводы, что:

• Факт времени должен идти отдельно от финансов. Т.е. я как руководитель хочу понимать, каким видом деятельности занимался мой сотрудник в течение дня. Например, сотрудник выставил себе за определенную работу 30 часов, но я предполагал, что эта работа займет не более 20 часов. Возникает вопрос – это я как руководитель неправильно оценил задачу? Или я оценил правильно, но задача из-за каких-то факторов заняла больше времени? Или сотрудник долго сдавал работу заказчику? В чем проблема, почему задача так долго выполнялась? Но при этом даже если факт времени превысил количество часов, которое мы можем выставить клиенту, это не обозначает, что эти часы нужно выставлять. Чаще всего это уже какая-то наша проблема, мы не учли какие-то моменты. И тогда это, действительно, уже будет наш убыток.

• Алексей Лустин из компании «Серебряная пуля» любит говорить, что «Все есть код». А мне нравится связанное с этим утверждение, что «Все есть задача». Раньше мы УНФ учитывали только те задачи, которые делались для нашей фирмы или для клиента – например, разработка нашего отраслевого решения или его тестирование, а по платным работам для клиента писали в трудозатраты по времени только то, что выставится клиенту. В такой ситуации непонятно, куда уходит время – это нигде не регистрируется. Поэтому приняли решение, что на все нужно создавать задачу, нет задачи – нет работы. В идеале каждая минута должна быть расписана – чем ты занимался. Поначалу это сложно, но потом это приносит реальную пользу.

• Нужна отдельная система оперативного учета. В 50% случаев на проектах CRM-блок или подсистему управления производства выделяют отдельно от бухгалтерской системы. Мы тоже решили, что нам для учета задач нужна отдельная система, которая изначально не будет связана с финансовым учетом. Задачи на этапе планирования не должны детализироваться на тестирование/ документирование/ постановку задач бизнес-аналитику, не должны быть связаны с «Заданиями на работу» и взаиморасчетами с клиентами.

• В фильме «Облачный атлас» есть фраза – «Все взаимосвязано». Применительно к нашей ситуации ее смысл в том, что все системы, которые нужны для учета, должны быть между собой взаимосвязаны. Все процессы – начиная от коммерческого предложения клиенту и заканчивая написанием автотестов для задачи, которая привела к этому предложению – все это в идеале должно быть взаимосвязано.

К системе учета задач мы сформировали следующие требования:

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

• Для разработчиков в задачах нужна возможность указывать специфические данные и статусы. У нас разработчики и линия консультации вели свои задачи в одной системе, при этом у линии консультации с задачами все было просто – там просто статусы «На рассмотрении», «В работе» и «Закрыто». А у разработчиков достаточно много специфических этапов: «Тестирование», «Code review» и т.д. Помимо этого, в задаче нужна возможность указывать такие параметры, как конфигурация, параметры подключения, VPN и т.д. – множество настроек.

• У клиента должен быть доступ к просмотру статусов и постановке задач в бэклог, он должен иметь возможность анализировать, кто и чем занимается. Это нужно, чтобы клиент не сам у нас спрашивал, как дела, а мог сам в любой момент зайти и посмотреть на бэклог (только на то, что ему доступно – без детализации по задачам). На YouTube есть вебинар Алексея Лустина о том, что клиентов не нужно пускать в вашу Jira (в ваш тасктрекер), а нужно пускать в ваш Confluence, т.е. нужно некое общее пространство, в котором вы сможете оперативно осведомлять заказчика о проекте.

• Нужно разделить учет фактического времени выполнения задач и того, которое мы выставляем клиенту. Потому что нам физическое время сотрудников важно для контроля. А для клиента часы, которые ему выставляются, не являются реальным временем – для него это единица измерения услуги, некий курс оплаты часов в валюте. По факту на эту задачу может быть потрачено в два раза больше времени, чем вы выставили, если ее делал, например, стажёр, а не опытный специалист.

• Сотрудник не должен проставлять вид работ – они должны определяться автоматически в зависимости от категории или проставляться менеджером

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

Поиск решения

В процессе поиска решения я проанализировал порядка десяти разных продуктов – Итилиум (Service Desk), JIRA, Redmine, ЭСТИ и т.д., но не нашел ни одного, которое бы полностью покрывало все наши требования.

Некоторое время мы активно пользовались Битрикс24 и Trello.

Плюсы Битрикс24:

• не требует затрат на внедрение;

• может быть быстро внедрен прямо сейчас;

• можно везти заказы;

• есть CRM-блок;

• можно вести задачи проекта совместно с клиентом – он может видеть статус ваших задач.

Но для нас Битрикс24 оказался слишком нагруженным, плюс возникла проблема его доработки – нам нужно было кое-что дописывать под себя, а разработчиков Битрикс24 у нас не было, и заказывать эти работы не хотелось. Кроме этого, возможности интеграции с 1С, встроенные в Битрикс24, неполные, и тоже требуют дополнительной доработки 1С.

Также мы попытались использовать для трекинга задач Trello, но столкнулись с тем, что там нет разделения, что показывать клиенту, а что не показывать. К тому что, что касается интеграции, в Trello есть возможность выгрузки задач в JSON, но нам по ряду причин результаты интеграции с 1С через JSON не понравились.

Выводы, которые я сделал в результате поисков системы для учета задач, можно охарактеризовать фразой: Eat your own dog food – разработчики должны использовать то, что они сами продают и внедряют.

Управление задачами

В результате на просторах Инфостарта я наткнулся на очень хорошую бесплатную разработку Антона Иванова «Управление задачами», которая достаточно активно сопровождается автором – он развивает свой продукт через GitHub, а для общения с пользователями использует Telegram-канал https://t.me/mtasks.

На основе этого решения мы сделали свою собственную отдельную систему «Управление разработкой» и настроили для нее обмен с нашей финансовой системой.

Алгоритм работы с задачей

Опишу используемый у нас алгоритм работы с задачами:

• Регистрируется задача – она может прийти от линии консультаций, ее может поставить аналитик, руководитель или сотрудник сам на себя.

• Далее задача начинает перемещаться по заранее определенным статусам – «Идея к обсуждению», «Зарегистрирована», «Бэклог», «К выполнению» и т.д. При перемещении задачи в процесс «Выполнение» сотрудник регистрирует фактические отрезки времени, потраченные на задачу, но эта информация не попадает в УНФ и никак не влияет на взаиморасчеты с клиентом.

• В конце месяца руководители проектов проверяют все задачи по своим подчиненным и по своим проектам и выполняют их групповое закрытие – при этом автоматически по определенным шаблонам подставляются описания, заполняются виды работ согласно договору и проекту, а также задачи регистрируются для обмена с УНФ.

• При попадании задачи в УНФ бухгалтерия и финансовый отдел на ее основании выставляет счета и начисляет зарплату, но меня, как разработчика и руководителя разработки, это уже не интересует, для меня главное – это выполнить работу и отразить ее выполнение.

Результаты внедрения

В результате внедрения системы учета задач у нас получился интересный эффект – выработка (количество регистрируемых часов) увеличилась в 1.5-2 раза! Мы смогли выявить скрытые часы, за которыми скрывалась недополученная прибыль. Как нам это удалось?

Раньше, если сотрудник не укладывался в отведенное на задачу время, мы у него спрашивали: «Почему тебе на работу был выделен один час, а ты ее сделал за три часа?» И он оправдывался: «Мне нужно было пообщаться с заказчиком, уточнить». У нас на тот момент не было отдельного аналитика, программистам приходилось самим общаться с заказчиком, и это неэффективно расходовало время.

Но когда начали вести трекинг, то увидели, что действительно – где-то 20 минут ушло на звонок с заказчиком, потом 30 минут на программирование, а потом несколькими заходами по 30 минут с повторным переключением за программирование сотрудник эту задачу сдавал заказчику. В результате получилось три часа, хотя разработка заняла меньше часа.

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

Именно благодаря сделанным на основании появления у нас трекинга времени выводам мы организовали выделенную линию консультации по нашим отраслевым продуктам – до этого мы думали, что ее могут поддерживать только программисты.

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

Таким образом программисты стали меньше времени тратить на постановку и сдачу задачи и смогли вырабатывать в 1.5-2 раза больше – как раз за счет того, что выявились эти скрытые часы.

Как выглядит наша система для управления разработкой

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

Внутри задачи указывается:

• вся аналитика, которая нужна разработчикам – конфигурация, тип работ, разбивка по проектам;

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

• отдельно есть форматированный текст – сюда можно вставить описание с картинками, загрузить текст из письма (есть автоматизированная загрузка из почты);

• и отдельно внизу есть описание для заказчика, которое формируется автоматически, но его можно дописать.

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

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

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

Работа происходит следующим образом – задачи перетаскиваются из колонки в колонку, есть различные маркеры – процент выполнения, заказчик, значок, что по задаче есть файлы и т.д.

И есть набор различных отчетов.

Также мы сюда внедрили такое понятие, как выпуск релиза – по аналогии с выпуском обновления в СППР.

До этого вести учет выпуска релизов было сложно – в УНФ этого просто нет, там оно и не нужно, там ведется финансовый учет. А здесь мы каждые две недели с разработчиками собираемся и в разрезе каждой конфигурации планируем, какие задачи на этом спринте у нас войдут в релиз. А потом уже менеджер по продукту оформляет эти задачи непосредственно в форматированный текст, который рассылается по почте клиентам.

Планы

Хочу рассказать, как мы планируем развивать нашу систему учета дальше.

• В УНФ существует блок CRM, но нам недостаточно функциональности, которая там есть, поэтому мы хотим интегрироваться с другой CRM-системой;

• У нас работает BAS:Документооборот – это своего рода наш внутренний Confluence, база знаний, мы согласовываем в нем документы, счета, и он обменивается с УНФ договорами и счетами. Есть идея интегрировать BAS:Документооборот с «Управлением разработкой» для того, чтобы тоже можно было из задачи посмотреть спецификацию по работам.

• Также мы собираемся интегрировать «Управление разработкой» с другими конфигурациями для разработчиков:

  • средства перевода, такие как 1С:Переводчик или 1С:SmartSync (SmartCat) – мы также разрабатываем конфигурации на разных языках;

  • СППР;

  • 1С:АПК;

  • конфигурации для тестирования, в которых запускается Vanessa Automation и т.д.

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

Выводы

Какие выводы я хочу сделать:

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

• Идеально подходящей вам системы учета задач не существует – все активно хвалят стек Atlassian, но нас Jira все-таки не устроила, поэтому я думаю, что найти подходящую систему в готовом виде нереально. Зато вы можете создать такую систему самостоятельно на основе чего-то готового, а потом ее постоянно адаптировать и развивать.

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

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Инструментарий руководителя проекта".