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

09.07.21

Учетные задачи - Учет рабочего времени

С проблемой учета работ сотрудников сталкиваются все компании, оказывающие услуги по разработке, внедрению и поддержке программных продуктов. О том, как увеличить выработку сотрудников путем выявления скрытых трудозатрат и перераспределения нагрузки в команде, рассказал директор и ведущий разработчик компании «Арт Порт» Максим Артеменко.

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

 

 

Я руковожу компанией «Арт Порт», которая входит в группу компаний «Арт Софт». Нашей группе компаний уже более 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 все-таки не устроила, поэтому я думаю, что найти подходящую систему в готовом виде нереально. Зато вы можете создать такую систему самостоятельно на основе чего-то готового, а потом ее постоянно адаптировать и развивать.

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

 

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

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

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Путевой лист грузового автомобиля в 1С:Бухгалтерия 3.0

Печатные формы Учет рабочего времени Платформа 1С v8.3 Бухгалтерский учет Оперативный учет 1С:Бухгалтерия 3.0 Транспорт, автопарки, такси Россия Бухгалтерский учет Платные (руб)

Путевой лист грузового автомобиля в 1С:Бухгалтерия 3.0 - заполнить, распечатать, сохранить. Вы можете не только внести всю информацию и распечатать путевой лист грузового автомобиля в 1С, но и повторно использовать ранее введенные данные спустя любое время - данные путевого листа сохраняются в "1С:Бухгалтерия 3.0" без каких-либо доработок.

4200 руб.

23.08.2019    54210    162    63    

151

Помощник заполнения графиков при вахтовом методе работы

Зарплата Учет рабочего времени Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Зарплата и кадры государственного учреждения 3 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Платные (руб)

Обработка предназначена для заполнения не цикличных график работы для вахтового метода работы и для работы в полевых условиях труда. Вводятся все виды времени вахтового цикла. Её использование позволяет не заполнять индивидуальные графики работы на каждого сотрудника, что сильно снижает трудозатраты на ввод данных. Решение предназначено для ЗУП 3.х; ЕРП 2.х; КА 2.х; ЗКГУ 3.х. Благодаря использованию обычных графиков работы, норму времени можно указать по графику пятидневки.

5400 руб.

18.12.2019    26256    29    6    

28

Путевые листы (форма 3, 4С, ПГ-1, 6 спец, ЭСМ-2) грузовые, строительные, муниципальные и легковые, в том числе для индивидуальных предпринимателей

Печатные формы Учет рабочего времени Логистика, склад и ТМЦ Платформа 1С v8.3 Конфигурации 1cv8 Автомобили, автосервисы Транспорт, автопарки, такси Россия Бухгалтерский учет Управленческий учет Платные (руб)

Открытая конфигурация (расширение) 1с для учета путевых листов. В том числе для 1с Бухгалтерии 3.0. 1. Реестр путевых листов 2. Печать путевых листов по форме 3, 4С, ПГ-1, 6 спец, ЭСМ-2 (грузовые, строительные, муниципальные и легковые) в том числе для индивидуальных предпринимателей 3. Автоматический расчет расстояний, ГСМ (летнего или зимнего), одометра (общего пробега авто). 4. Расчет сумм за путевой лист (перевозку). 5. Печать реестра путевых листов

3000 руб.

03.07.2018    38574    217    116    

53

"Учет уроков (занятий)" Lessons management на платформе 1С 8.3. Оплаты, абонементы, часы, взаиморасчеты, учет зарплаты. Мобильный клиент.

Управление взаимоотношениями с клиентами (CRM) Взаиморасчеты Учет рабочего времени Платформа 1С v8.3 Развлечения, искусство, спорт Кадровые агентства, подбор персонала Управленческий учет Платные (руб)

Подходит для школ, рок-школ, кружков для ведения учета занятий, репетиций, уроков, мероприятий и оплат по ним. Учет зарплат педагогов. Бонусные системы. Абонементы. Так же внедряется в вашу 1с Бухгалтерию 3.0 или УНФ посредством расширения конфигурации. Доступен мобильный клиент.

3600 руб.

06.09.2016    39642    87    60    

48

Загрузка табеля рабочего времени в ЗУП из Excel

Зарплата Учет рабочего времени Загрузка и выгрузка в Excel Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Платные (руб)

Небольшая, не сильно перегруженная излишними функциональными возможностями внешняя обработка для конфигурации ЗУП 3.1, которая позволит легко загрузить данные в табель учета рабочего времени из Excel.

1000 руб.

12.03.2021    16478    14    14    

19

Табель с выделением цветом различных видов времени

Учет рабочего времени Платформа 1С v8.3 Сложные периодические расчеты 1С:ERP Управление предприятием 2 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Абонемент ($m)

Расширение для конфигураций ЗУП 3.1 и 1С:ERP Управление предприятием 2, позволяющее настроить цвета для разных видов времени в документе "Табель".

1 стартмани

07.05.2024    2154    14    Dima69    5    

12
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. serg33rus 28 09.07.21 14:20 Сейчас в теме
Чисто личное мнение и личный опыт по сравнению с другими системами управления проектами.
У меня не стоит задача "управлять проектом". У меня задача - управлять фирмой, которая занимается практически всем, что связано с IT. Тут и связь, и инет, и сервера, и видеонаблюдение, и скуд, и 1С само собой, и АТС. Т.е. есть набор разноплановых задач и набор спецов. И вот тут УЗ от Антона у меня "выстрелила". Чего я только не перебирал. Спринты у меня есть, но лишь в 20% задач, а остальные либо периодические, либо разовые по запросу. И классические типа JIRA не вытанцовываются. Это система помогающая "пасти котов". И без нее тяжко.
А если учесть что лично у меня сюда же приляпан сервер регистрации ошибок 1С и задача автоматом генерится. Туда же падают письма на support@. Туда же бот телеги присобачен. И уведомления сыпятся не только на почту или телегу, но и на анахронизм типа аськи, ну исторически так сложилось, что она используется в конторе.
А еще много задач рождается в процессе общения по телефону, а звонки у меня тоже фиксируются в системе с возможностью привязать звонок к задаче. Там же можно послушать разговор, чтобы понять откуда ноги растут. Там же оценить сколько общение сожрало времени.
У меня даже проходная падает в TASK в виде оповещения, чтобы понимать на территории специалист или в поле.
И это не предел. Если мне еще что-то понадобиться, я нарисую еще одно расширение. У меня даже связка с бух работает, чтобы поймать оповещение что бабки по счету пришли.
И небольшая База знаний там же. И файлы удобнее в БЗ хранить поскольку полнотекстовый поиск работает и по файлам.
И аналог системе я не найду. Если только самому писать.
В общем как система управления проектом по созданию ПО наверно не самая сильная вещь. Как система управления задачами в конторе (разноплановыми задачами) ей цены нет. я сейчас без нее просто сдохну. Ну или сам застрелюсь.
Все вышеизложенное является частным мнение отдельно взятого руководителя отдельно взятой конторы.
BlizD; rovenko.n; drmaxart; +3 Ответить
2. o.nikolaev 213 10.07.21 14:27 Сейчас в теме
Потом вы можете проанализировать это потерянное время и выставить эти часы клиенту, чтобы не было недополученной прибыли.
Про вот это можно подробнее? За что в данном случае заплатит клиент?
3. o.nikolaev 213 10.07.21 14:33 Сейчас в теме
наш внутренний Confluence, база знаний, мы согласовываем в нем документы, счета, и он обменивается с УНФ договорами и счетами.

Что-то как-то у вас все смешалось: Confluence, база знаний, согласование документов, учет договоров, учет счетов. Вы уверены что этот склад разнородных данных тыкаемых разносмешанными процессами можно назвать "базой знаний"?
4. RustIG 1631 23.07.21 13:05 Сейчас в теме
(0)
В результате внедрения системы учета задач у нас получился интересный эффект – выработка (количество регистрируемых часов) увеличилась в 1.5-2 раза! Мы смогли выявить скрытые часы, за которыми скрывалась недополученная прибыль. Как нам это удалось?

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

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

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

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

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


Клиент все равно заплатит за работу аналитика, тестировщика, менеджера проекта - так отдали бы эти деньги программистам, которые кроме разработки также по телефону консультируют...

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

С ростом оборотов компании надо штат увеличивать, делить компетенции, прописывать бизнес-процессы, автоматизировать свою систему учета задач...Все как у всех....


Спасибо за доклад.
maksa2005; +1 Ответить
Оставьте свое сообщение