Понимаете, каждый год 31 декабря мы с друзьями ходим в баню. 
Это у нас такая традиция…

(с) Ирония судьбы, или С лёгким паром!

Похожая традиция есть и у нас. Каждый год 30 декабря руководитель отдела проектов Алексей Шкарупа собирает статистику по проектам выполненным ИНТЕРВОЛГОЙ за год. По каждому проекту вычисляется важный финансовый показатель: стоимость часа разработчика в проекте. Он показывает насколько каждый проект для нас выгоден, и в каких мы допустили серьезные просчеты в оценках. Проблема в том, что управленческие решения на основе этой метрики нужно принимать намного чаще, чем раз в год.

Исторически сложилось

Более 5 лет наши сотрудники пишут в  в Google-таблицах ежедневные отчеты, за которые ставятся оценки. Там же у нас KPI, заплаты, выработка. 

 

 

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

Задача #1. Считать статистику по потраченному времени более оперативно и с меньшими трудозатратами. 

Была еще одна проблема, которую хотелось исправить - отчет для постановщиков задач. До сих пор узнать, сколько времени потрачено на задачу можно было, только спросив у исполнителя голосом. Исполнителю в свою очередь приходилось идти в отчет и искать “хвосты” этой задачи. 

Задача #2. Получать информацию /отчет о потраченном времени для постановщиков задачи без дополнительных трудозатрат со стороны исполнителя.

Решения и подводные камни

Решение пришло само собой: учет времени в Битрикс24.

Голоса “за”:

- задачи мы давно ставим только через эту систему;
- есть учет времени;
- заявляется, что есть отчеты по затраченному времени в разных разрезах (проекты, люди, даты).

Голоса “против”:

- отказываться от отчетных файлов мы не хотели (помимо потраченного времени там есть KPI и другие важные данные);
- дублирование руками - чистой воды muda;
- известна пара багов: две задачи могут одновременно иметь статус "выполняется"; иногда руководитель и подчиненный видят разный статус выполнения.    

После анализа  фактов родилась идея: “затянуть” данные о потраченном времени из наших GoogleDocs-отчетов в Битрикс24. В голове была следующая схема.

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

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 вопроса:

1. Как сопоставить записи в отчетах и их аналоги в Битрикс24?
2. Как понять какая из тысяч строк в отчете изменилась с момента последней синхронизации?

К сожалению в Битрикс24 не нашлось места куда бы могли сохранить служебные данные для ответов на эти вопросы. Пришлось изобретать велосипед.

По каждой строке таблицы-отчета на стороне Google вычисляются уникальный идентификатор строки (XML_ID) и контрольная сумма (VERSION). Эти данные мы добавляем прямо в комментарий к записям о временных затратах.

Поле VERSION помогает “экономить” запросы. Каждое удаление или вставка отдельной записи о затраченном времени делается отдельным асинхронным запросом. Это долго и можно упереться в лимиты API. Если вывернуться наизнанку, можно отправлять их пакетами по 50 штук. Но кода становится больше в разы, а его поддержка усложняется на порядок.

В процессе разработки “Потрачено” была написана собственная обертка для отправки запросов пакетами. Она самостоятельно занимается контролем их количества, объединением порций получаемых данных и т.п. Тут Вам и DRY , и задел для следующих проектов.

О чем забывают проектируя “волшебный интерфейс”

При синхронизации может возникать десяток коллизий. Расскажем о некоторых из них.

Коллизия “Записали время не в ту задачу”.

В отчете указали время по задаче X, синхронизировали. Опомнились, что это не та задача. Изменили задачу на Y в отчете и снова синхронизировали.

Если ничего не предпринять, время потраченное на одну и ту же работу окажется в 2-х задачах, ведь нигде не хранится информация об изменениях в отчете. Возникает коллизия если задача X больше нигде не фигурирует и приложение вообще не узнает что нужно рассматривать эту задачу при синхронизации.

В решении этой коллизии нам помогает специальное хранилище в Битрикс24. В хранилище мы складываем все задачи, которые упоминались в отчете за последние несколько месяцев.

Коллизия “Очистка строки отчета”.

В отчет можно не только вписывать свои подвиги и делать в них правки, но и удалять их из отчета вовсе (бывает по-разному). При этом, как узнать, что где-то в корпоративном портале осталась запись о затраченном времени, которую пора уничтожить?

Решение: из отчета мы забираем не только заполненные строки, но и все пустые. У пустых строк остается все тот же XML_ID, который не зависит от заполнения, а значит ему по-прежнему может соответствовать что-то в кор. портале. Дальше дело техники.

Коллизия “не положено”.

Бывает так, что все шло хорошо, задачу делали, вписывали и синхронизировали, но вдруг по каким-то причинам в Битрикс24 были изменены настройки доступа. Теперь сотрудник, а соответственно и “Потрачено” от его имени, не имеет прав вписать или отредактировать время. Синхронизация проходит не полностью, что-то упущено, состояния отчета и портала разные. Чтобы отслеживать подобные ошибки, строки отчета красятся разными цветами. Это позволяет сразу после синхронизации заглянуть в отчет и проверить, все ли прошло гладко.

Кроме того, “Потрачено” отправляет самому синхронизирующему всплывающее уведомление о проблеме, а для ускорения решения проблемы с правами доступа (если проблема в них) вычисляет постановщика задачи, которую не удалось синхронизировать, и пишет ему в чат о случившейся проблеме.

Коллизия “задача-сирота”

Если выполняемая задача не принадлежит проекту, постановщику такой задачи приходит предупреждение.

Результаты

Разработка приложения велась 2 месяца. Еще 2 месяца подчищались баги и писались обходные пути для коллизий. Весь процесс занял 205 рабочих часов. #Wasted Своих целей мы достигли и теперь намного оперативнее делаем выводы о расходе времени и ставке часа в проекте.

Разработка приложений для Битрикс24 дело не для слабонервных. Тем более если внутри интеграция с внешней системой. При этом сама платформа совсем не дружелюбна.

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