Рубрика «учет времени»

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

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

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

Но для начала давайте поговорим о технологии.
Читать полностью »

Биометрия это такая тема, которая сопровождается мифами и легендами. Про 99% точность, надёжность, про прорывные технологии, про распознавание людей Вконтакте. Пару дней назад была статья про Сбербанк, например. Рассказывая про биометрию очень просто манипулировать информацией: мало кто из людей чувствует статистику.
Куда движется современная биометрия - 1
Лет пять назад я уже писал на Хабре серию статей про биометрию и то как она устроена (1, 2, 3). Как ни странно, за эти годы достаточно мало что изменилось, хотя изменения и произошли. В этой статье я попробую как можно более популярно рассказать про сегодняшние технологии, про то какой прогресс идёт и почему к словам Грефа о том, что к словам «карта, основная задача которой состоит в идентификации, уходит в прошлое» стоит относится с скептицизмом.
Читать полностью »

В данной статье хочу описать свой метод учета времени.

Начну с того, зачем мне это нужно. Не секрет, чтобы что то получить, нужно что то отдать. Зачастую (практически всегда) приходится тратить свое время. Так и мне года 4 назад понадобилось знать куда я его трачу, с целью повышения эффективности его использования. С тех пор желание не ослабло, а только усилилось. И все хорошо, если бы не одно НО. Учет времени сам по себе отнимает время, и кроме того — требует волевых усилий. Читать полностью »

Удобный учет рабочего времени. UPD

Добрый день, уважаемые хабрапользователи!

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

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

Я попробовал поставить эксперимент — взял свой обычный рабочий день и начал записывать на бумажку отчет о том, что и сколько времени делаю. Цифры получились не очень-то и приятные. Со временем стал каждый день записывать такие отчеты, и как не удивительно — дела пошли в гору. Даже, если эти отчеты никто кроме меня не увидит — я же их отлично вижу и осознаю проблему. Когда это крутится в голове, то можно просто взять и отмахнуться от этих мыслей. А вот когда вы читаете отчеты за весь месяц и видите, что дела действительно идут не очень хорошо, то тут никуда не денешься и начинаешь осознавать, что нужно что-то менять.

Спустя какое-то время я начал вести отчеты в Emacs (org-mode). Попользовался, изучил на базовом уровне и спустя какое-то время забросил — показалось не очень удобным, т. к. этими отчетами бывает нужно делиться с начальством или заказчиками, а экспорт в тот же HTML не так уж приятно выглядит.

Собственно как-то вот так и появилась идея сделать свой тайм-трекер с блэкджеком и удобным интерфейсом и подробными отчетами.

Читать полностью »

В своей работе мне довольно часто приходится обсуждать вопросы подходов к учету времени, потраченного на разработку программного обеспечения. Нужно ли учитывать время по каждой задаче? Нужно ли отчитываться каждый день? Полезны ли «таймшиты» и как они должны выглядеть? Кто должен заполнять отчёты и когда? И т.д. Иногда разговор уходит к противостоянию Agile-методологий и более строгих методов управления.
Бывает, такие обсуждения переходят в спор, противостояние точек зрения, а заканчиваются примиряющей фразой: «конечно же, каждая компания имеет свою специфику и особенности, свою модель бизнеса, а значит и свои подходы к учету ресурсов». И это правильно, потому что, по большому счету, принципы учета ресурсов зависят от модели бизнеса, но я всё же хочу собрать в одном месте накопленные аргументы разных сторон и подходов, а главное — попробовать сделать «открытую статью», статью в виде диалога, в виде противостояния аргументов и точек зрения, на которую повлияют комментарии и голоса читателей.
На мой взгляд, различные варианты сводятся к трем базовым подходам:

  1. Учёт потраченных человеко-часов с разбивкой по задачам
  2. Учёт реализуемого функционала (backlog/requirements) и общая оценка стоимости работ
  3. Творческая работа без списка функционала и контроля ресурсов

Давайте рассмотрим различия и аргументы в выборе подходов для следующих аспектов:

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

Обсуждать и противопоставлять мы будем первые два подхода, потому что про третий я рассуждать не могу. Мне приходилось работать в разных компаниях и в разных проектах, на разных технологиях и в разных управленческих схемах…
И самые интересные, технологически сложные и продвинутые, самые необычные проекты делались именно по третьему подходу. Именно про эти проекты я рассказывал на собеседованиях, именно в них создавались принципиально новые продукты, а не всякая надоевшая обыденность типа база данных→бизнес-логика→бизнес-процессы→клиентские представления→отчёты. Работой в этих проектах я горжусь, вспоминаю с ностальгией, не стесняюсь сказать «вот эти архитектурные решения принял я», и именно про эти проекты обычно слушают с большим интересом. Но с другой стороны, именно эти проекты были очень дорогими и экономически сомнительными. Сейчас никакие аргументы за или против таких проектов я приводить не готов, поэтому рассмотрим только два подхода:
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js