Таймтрекер на Google Scripts, Docs и Spreadsheets



    В предыдущей статье речь шла о подходе к техническому заданию в Decart IT-production. Когда мы внедрили эти изменения, проекты велись в облачной Jira, но ее потенциал использовался на минимальном уровне. Для небольшой компании достаточно грамотной постановки задач, таймтрекера, багтрекера и статистики по проекту и команде. Команде было намного удобнее работать с ТЗ, как единым документом, чем с отдельными задачами в Jira, хотя бы из-за простоты навигации в Google Docs(далее — Docs). Еще в самом начале работы по новому ТЗ появились мысли упростить процесс работы, как-то “доделав” Docs, но череда проектов не оставляла времени на погружение в этот вопрос. И вот, когда время все же нашлось, я составил список целей, которых мы хотели достичь:

    1. Учет времени в самом Docs
    2. Составление отчетов по трудозатратам сотрудников
    3. Составление отчетов по работам над проектами
    4. Уменьшение времени на работу с самой системой по ходу реализации проектов
    5. Избежать дублирования одной информации в разных местах
    6. Потратить минимум ресурсов компании

    Но для начала давайте поговорим о технологии.

    Google Scripts


    Google Apps Script (далее GAS) — диалект JavaScript для создания автоматизирующих скриптов и расширений для сервисов Google. Хоть GAS и не сильно популярен в русскоязычном интернет-сообществе, но сомневаться в его полезности не приходится. GAS является хорошим инструментом для автоматизации различных бизнес-процессов, так как имеет широкий набор интеграций. На данный момент у языка есть классы и методы для работы со следующими сервисами: Таблицы, Документы, Формы, Диск, Gmail, Календарь, Контакты, Карты, Группы, Переводчик.

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

    Также с помощью Google Apps Script можно создавать полноценные веб-приложения с графическим интерфейсов на HTML/встраивать Google Apps Script на свои сайты. Простейший пример: сделать на сайте форму загрузки файлов с компьютера на Google Drive

    В итоге хочется отметить следующие плюсы:

    1. GAS довольно прост в использовании.
    2. Широкий набор интеграций с различными сервисами
    3. Работает в облаке
    4. Удобные средства для отладки и логирования
    5. Возможность тонко настраивать права доступа

    Как ограничения отметим следующее:

    1. Лимиты на количество запросов, количество создаваемых документов и т.д. Лимит на максимальное время исполнения может заставить потратить больше времени на оптимизацию кода, чем хотелось бы
    2. Имеет некоторые ограничения c CSS
    3. Вы должны иметь аккаунт Google для разработки и использования расширений

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

    Теперь перейдем непосредственно к реализации.

    Структура


    Для хранения и визуализации данных мы решили использовать Google Spreadsheets и построили простую архитектуру на основе трех таблиц.

    Таблица “Трудозатраты”


    Мы сделали ее сразу на год. Листы — месяцы. Столбцы:

    1. Число месяца
    2. Кто
    3. Проект
    4. ID задачи
    5. Отмеченное время
    6. Комментарий



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

    Таблица “Отчет за месяц”


    Она нужна, чтобы и сам сотрудник, и руководство видели в какой день над какими проектами и сколько было отработано. Листы — сотрудники. Столбцы:

    1. Число месяца
    2. Отработано за день
    3. Проект
    4. ID задачи
    5. Задача
    6. Отмеченное время
    7. Комментарий



    Число и суммарное время за это число на отдельной строке, ниже сами трудозатраты.

    Таблица “Работы по Проекту”


    Позволяет понять отведенное на задачу время, сколько уже потрачено, сколько осталось часов у каждого из отделов (дизайн, front-end, back-end). Листы — версии продукта. Столбцы:

    1. Раздел ТЗ(заголовки h1)
    2. ID задачи
    3. Задача
    4. По 2 столбца на каждый отдел: отработано и оценка(в часах)
    5. Всего
    6. Баланс. Оценка минус отработанные
    7. Кто работал над задачей и сколько потратил



    Последней строкой идет подведение итогов по столбцам D-L.

    Как это работает


    Мы написали это дополнение на google scripts, которое после установки можно использовать в любом Google Документе с помощью вкладки “Дополнения”. Когда все документы с заказчиком подписаны, мы делаем копию ТЗ, с которой и будем в дальнейшем работать. При инициализации проекта проверяется была ли уже создана таблица “Работы по Проекту”. Если нет, создается новая. Если да, то в старую добавляется новый лист. Для корректной работы, конечно, необходимо называть файлы по выбранному нами шаблону, но это можно опустить.



    Все задачи должны иметь следующее наименование:
    Название_задачи(Оценка_времени_дизайна+Оценка_времени_фронта+Оценка_времени_бэка)[ID_задачи].
    ID генерируется автоматически при инициализации проекта.

    Теперь файл готов для работы. Чтобы отметить время, нужно поставить курсор на заголовок задачи, а в меню выбрать пункт “Добавить трудозатраты”, при клике на который откроется окно.



    Трудозатраты сразу добавляются во все перечисленные выше таблицы. Под заголовком задачи в Docs появляется строка “Участники”, где перечислены все, кто работал над ней с указанием отмеченных часов.



    Багтрекер


    Для каждого проекта, помимо файлов с версиями ТЗ, мы создаем файл с ошибками, который в терминах системы является такой же версией. Оценкой задач(временем, оплачиваемым Заказчиком) будут нули.

    Но в отличие от файла с ТЗ, он будет постоянно пополняться. На этот случай мы реализовали одиночное добавление задачи, а также изменение названия/оценки задачи в таблицах, если они поменялись.

    Чтобы баги не терялись в этом файле, заголовки всех свежих задач мы дублируем в отдельный чат в телеграме с указанием проекта, степени важности и ответственного разработчика. Когда баг поправлен, разработчик отвечает на нее плюсом, а ПМ проверяет и удаляет из чата все сообщения, касающиеся этого бага. Таким образом, цель — пустой чат.

    Да, в плане багтрекера можно было бы придумать более изящное решение, но этот подход не потребовал от нас никаких доработок, и при этом уже хорошо себя проявил.

    Планы на будущее


    На данный момент мы сделали MVP, а в дальнейшем реализуем как минимум статусы задач(сейчас это просто выделение цветом) и базовую финансовую статистику, не превращая при этом проект в чудовище Франкенштейна.

    Спасибо, что прочитали до конца, и хорошего дня!

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 5

      +1
      Интересно. Если надо немного улучшить работу в проекте по старой методике — вполне неплохо.
      Однако можно сделать иначе: перейти на Wrike (или на похожие системы управления проектами). У них есть один существенный плюс от таблиц и построенных на них системах, типа Gantter и подобных.
      Это многомерная классификация. Каждая задача (как единица информации) может быть соотнесена с несколькими проектами, папками. Причем одновременно, без дублирования, с любым уровнем сложности связей. Что-то подобное — OLAP отчеты, сводные таблицы.
      Тогда можно работать в методологии системного подхода, особенно в инженерных проектах. Несколько аспектов системы видны одновременно, причем все синхронизировано. Аспекты и методология по ISO 81346.
      Да, сначала сложно перестроится на многомерную классификацию и работу в нескольких аспектах представления системы. Но сама методология системного подхода — намного проще и удобнее, чем обычная классическая редукционистская методология. Да и для разработки программ системный подход ближе и логичнее. Ну и применяют его уже почти везде, как стандарт де-факто…
      На практике это дает такие результаты (примеры):
      1. Создание комплекта документов для финансирования проекта 64 нормочаса, вместо 260 нормочасов по обычным методам.
      2. Создание технической документации на продукт — 12 нормочасов, против 67 в обычной методологии.
      3. Разработка проекта производства краски (базовое проектирование, целый завод) — 80 нормочасов, вместо 600. Но тут ускорение не только за счет методологии, а еще за счет использования походих инструментов в управлении проектом (Wrike) и системы проектирования (ePlan). Логика работы похожая, плюс наработанные типовые элементы. Кстати, технический проект существует и ведется одновременно на 2 языках, оказывается это несложно.
        +1
        Я правильно понимаю, что ваш бизнес не состоит в автоматизации Google Docs и т.п?
        В этом случае разумнее вопользоваться существующим решением вроде этого clockify.me/integrations.
          0
          Да, это был первый опыт в данных технологиях.
          Мы рассматривали готовые решения, полностью ничего не подошло. Но спасибо за ссылку, кому-то может быть полезно
          +1
          Очень интересно, спасибо за статью. Только я бы доработал данную концепцию так:

          1. Внесение задач работает через телеграм-бота, задачи вносятся с определенными метками (например сокращенными названиями проектов)
          2. Все задачи вносятся в одну таблицу, которая является общим хранилищем
          3. Есть одна буферная таблица, в которую импортируются задачи и там, определенным образом фильтруются
          4. С помощью импорта и фильтрации, задачи раскидываются по докам, каждая из которых представляет собой отдельный проект
          5. У каждого сотрудника есть собственная таблица, в которую импортируются доступные ему проекты и задачи по ним. Там же происходит анализ
          6. У тимлида, есть собственная таблица, в которую импортируются сводки по активности всех сотрудников

          Таким образом, достигается многомерность (одна и та же задача может быть раскидана по разным проектам путем меток, по которым происходит фильтрация), а также возможность простой коллективной работы, когда все проекты собраны в одном месте (как в избранном в той же Asana, например).
            0
            Да, в дальнейшем мы будем дорабатывать систему, спасибо за советы!

          Only users with full accounts can post comments. Log in, please.