- Исторически сложилось
- Решения и подводные камни
- Суровая реальность
- Технологии: Bitrix24 REST API, Google Spreadsheets API, React
- Подробнее о синхронизации
- О чем забывают проектируя “волшебный интерфейс”
- Результаты
Понимаете, каждый год 31 декабря мы с друзьями ходим в баню.
Это у нас такая традиция…(с) Ирония судьбы, или С лёгким паром!
Похожая традиция есть и у меня. Каждый год 30 декабря я собираю статистику по проектам выполненным ИНТЕРВОЛГОЙ за год. По каждому проекту вычисляю важный финансовый показатель: стоимость часа разработчика в проекте. Он показывает насколько каждый проект для нас выгоден, и в каких мы допустили серьезные просчеты в оценках. Проблема в том, что управленческие решения на основе этой метрики нужно принимать намного чаще, чем раз в год.
Исторически сложилось
Более 5 лет наши сотрудники пишут в в Google-таблицах ежедневные отчеты, за которые ставятся оценки. Там же у нас KPI, заплаты, выработка.
Из десятка таких отчетов (по 12 листов-месяцев в каждом) я собираю данные в 1 таблицу, очищаю от мусора и пытаюсь отнести каждую запись о потраченном времени к конкретному проекту. На разовый подсчет такой статистики 5 лет назад требовалось не менее 4-х часов. С ростом штата эта цифра быстро выросла.
Задача #1. Считать статистику по потраченному времени более оперативно и с меньшими трудозатратами.
Была еще одна проблема, которую хотелось исправить - отчет для постановщиков задач. До сих пор узнать, сколько времени потрачено на задачу можно было, только спросив у исполнителя голосом. Исполнителю в свою очередь приходилось идти в отчет и искать “хвосты” этой задачи.
Задача #2. Получать информацию /отчет о потраченном времени для постановщиков задачи без дополнительных трудозатрат со стороны исполнителя.
Решения и подводные камни
Решение пришло само собой: учет времени в Битрикс24.
Голоса “за”:
-
задачи мы давно ставим только через эту систему;
-
есть учет времени;
-
заявляется, что есть отчеты по затраченному времени в разных разрезах (проекты, люди, даты).
Голоса “против”:
- отказываться от отчетных файлов мы не хотели (помимо потраченного времени там есть KPI и другие важные данные);
- дублирование руками - чистой воды muda;
- известна пара багов:
- две задачи могут одновременно иметь статус "выполняется",
- иногда руководитель и подчиненный видят разный статус выполнения.
Хочу обратить внимание на “теоретическую” простоту желаемого решения. Теоретическую потому, что компоненты этой схемы в том или ином виде реализуемы.
Но вылезло много подводных камней.
OAuth повсюду.
И Google, и Битрикс24 требуют для работы подтвердить, что вы это вы, а не робот, который работает от Вашего имени. Мало того, что сам механизм ужасно неудобен для программиста, так еще и без человека не работает.
Вывод: никакого выполнения операций по расписанию. Обязательно нужен кто-то перед браузером, авторизованный и в Google, и в Битрикс24.
Права доступа
В Битрикс24 куда ни плюнь, все завязано на права доступа. Это настоящий ад. В самых неожиданных местах вдруг выясняется, что вы не имеете доступа к задаче, которую делал Ваш подчиненный для соседнего отдела.
Скажу больше, каждый сотрудник может создать “закрытую невидимую” группу, и даже администратор портала не сможет ее увидеть, если не включит “режим бога”.
В итоге сотрудник задачу в такой группе делает, время записывает, а вы к задаче доступа не имеете и, соответственно, не можете в нее перенести время или посчитать в отчетах.
Вывод: строить отчет в разрезе сотрудников или вообще всех проектов без потери данных может только администратор.
“Текущий” пользователь
Эта особенность Битрикс24 доставила больше всего неудобств. Допустим, существует задача, которую делает сотрудник Вася, и у вас к ней даже есть доступ. Вы устроили совещание по этой задаче и решили зафиксировать потраченное время самостоятельно (за себя и за Васю). Думаете это возможно?
А вот и невозможно. Все операции в Битрикс24 (и по REST API тоже) выполняются от имени текущего авторизованного пользователя. В случае REST API от имени того, кто предоставил авторизацию. Поэтому записать время вы можете только на себя.
Вывод: каждый сотрудник должен выполнять синхронизацию самостоятельно.
Заявляемая и реальная функциональность
Отчеты по потраченному времени в Битрикс24 Вам не помогут. Они там конечно, есть но…
Но относят все время из задачи на непосредственного исполнителя. А ведь задачу могут делать 2-3-4 человека. И каждый тратит/записывает время. Но в отчете вы увидите у всех 0, а у главного исполнителя - полную сумму.
Вывод: отчеты придется “переписать”.
Суровая реальность
Вернемся к схеме. Теперь она приобрела вот такой вид:
Для поддержки этой схемы мы немного модифицировали сами отчетные файлы. Ранее в них присутствовала колонка “название проекта” и с группировкой по ней возникали проблемы (пропуски, опечатки, различное написание). Мы заменили ее на “ID задачи или ссылка на нее”.
Это позволило точно сопоставить потраченное время с задачей, а, как следствие, с проектом.
Как вы лодку назовете , так она и поплывет. Наше приложение мы назвали “Потрачено” :)
Технологии: Bitrix24 REST API, Google Spreadsheets API, React
При разработке хотелось избавиться от необходимости авторизации хотя бы в одной из систем Google/Битрикс24. Google-авторизация оказалась проще. Решили сделать приложение 2-го типа для Битрикс24, а в нем дополнительную авторизацию в Google. Такое приложение не требует программирования отдельной авторизации в Битрикс24.
Итого минус 1 блок в нашей схеме.
Общение с таблицей-отчетом происходит через Google Apps Script API https://developers.google.com/apps-script/.
Для успешной работы с отчетным листом сотрудник должен быть авторизован в аккаунте Google и указать в приложении ID документа-таблицы. В интерфейсе, если все области горят зеленым, значит данные подходят и можно приступать к синхронизации. Остается нажать кнопку «Синхронизировать рабочее время».
Мы заранее понимали, что JS-кода будет очень много. Так много, что в нем черт ногу сломит. Чтобы хоть немного все структурировать решили попробовать связку фреймворков React и Flux.
React+Flux дает ряд преимуществ при разработке приложений подобного рода. В нашем случае увесистая “модель” ворочает большим (конечно, если речь идет о JS) количеством данных, получаемых и отправляемых двумя асинхронными API.
Вдобавок к этому, интерфейс приложения должен вовремя, правильно и красиво отреагировать на то, что происходит как со стороны Битрикс24, так и со стороны Google.
Подробнее о синхронизации
Итак, имеем 2 независимые системы: отчетные файлы и Битрикс24. Данные в каждой из систем могут изменяться независимо. Возникают 2 вопроса:
- Как сопоставить записи в отчетах и их аналоги в Битрикс24?
- Как понять какая из тысяч строк в отчете изменилась с момента последней синхронизации?
К сожалению в Битрикс24 не нашлось места куда бы могли сохранить служебные данные для ответов на эти вопросы. Пришлось изобретать велосипед.
По каждой строке таблицы-отчета на стороне Google вычисляются уникальный идентификатор строки (XML_ID) и контрольная сумма (VERSION). Эти данные мы добавляем прямо в комментарий к записям о временных затратах.
Поле VERSION помогает “экономить” запросы. Каждое удаление или вставка отдельной записи о затраченном времени делается отдельным асинхронным запросом. Это долго и можно упереться в лимиты API. Если вывернуться наизнанку, можно отправлять их пакетами по 50 штук. Но кода становится больше в разы, а его поддержка усложняется на порядок.
В процессе разработки “Потрачено” была написана собственная обертка для отправки запросов пакетами. Она самостоятельно занимается контролем их количества, объединением порций получаемых данных и т.п. Тут Вам и DRY, и задел для следующих проектов.
О чем забывают проектируя “волшебный интерфейс”
При синхронизации может возникать десяток коллизий. Расскажем о некоторых из них.
Коллизия “Записали время не в ту задачу”.
В отчете указали время по задаче X, синхронизировали. Опомнились, что это не та задача. Изменили задачу на Y в отчете и снова синхронизировали.
Если ничего не предпринять, время потраченное на одну и ту же работу окажется в 2-х задачах, ведь нигде не хранится информация об изменениях в отчете. Возникает коллизия если задача X больше нигде не фигурирует и приложение вообще не узнает что нужно рассматривать эту задачу при синхронизации.
В решении этой коллизии нам помогает специальное хранилище в Битрикс24. В хранилище мы складываем все задачи, которые упоминались в отчете за последние несколько месяцев.
Коллизия “Очистка строки отчета”.
В отчет можно не только вписывать свои подвиги и делать в них правки, но и удалять их из отчета вовсе (бывает по-разному). При этом, как узнать, что где-то в корпоративном портале осталась запись о затраченном времени, которую пора уничтожить?
Решение: из отчета мы забираем не только заполненные строки, но и все пустые. У пустых строк остается все тот же XML_ID, который не зависит от заполнения, а значит ему по-прежнему может соответствовать что-то в кор. портале. Дальше дело техники.
Коллизия “не положено”.
Бывает так, что все шло хорошо, задачу делали, вписывали и синхронизировали, но вдруг по каким-то причинам в Битрикс24 были изменены настройки доступа. Теперь сотрудник, а соответственно и “Потрачено” от его имени, не имеет прав вписать или отредактировать время. Синхронизация проходит не полностью, что-то упущено, состояния отчета и портала разные. Чтобы отслеживать подобные ошибки, строки отчета красятся разными цветами. Это позволяет сразу после синхронизации заглянуть в отчет и проверить, все ли прошло гладко.
Кроме того, “Потрачено” отправляет самому синхронизирующему всплывающее уведомление о проблеме, а для ускорения решения проблемы с правами доступа (если проблема в них) вычисляет постановщика задачи, которую не удалось синхронизировать, и пишет ему в чат о случившейся проблеме.
Коллизия “задача-сирота”
Если выполняемая задача не принадлежит проекту, постановщику такой задачи приходит предупреждение.
Результаты
Разработка приложения велась 2 месяца. Еще 2 месяца подчищались баги и писались обходные пути для коллизий. Весь процесс занял 205 рабочих часов. #Wasted Своих целей мы достигли и теперь намного оперативнее делаем выводы о расходе времени и ставке часа в проекте.
Разработка приложений для Битрикс24 дело не для слабонервных. Тем более если внутри интеграция с внешней системой. При этом сама платформа совсем не дружелюбна.
С другой стороны, разработка подобных приложений может быть хорошим решением если ваша задача состоит в консолидации информации и расширении типовых возможностей облачного портала.
Читайте нашу статью о разработке системы синхронизации потраченного времени по задачам.
Мы готовы и умеем решать нетиповые задачи работы с данными, построения отчетов и формирования управленческой отчетности для Битрикс24. Расскажите о своей задаче и мы предложим решение!
Статьи по теме
