All streams
Search
Write a publication
Pull to refresh

Comments 38

для бизнеса отказ от жёсткого тайм-трекинга может быть даже полезен

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


Если разработка более сложная, требует опыта, знаний, R&D - мерять её по принципам конвейера - крайне плохая идея. Эта идея обычно укореняется в умах руководителей, ни года не проработавших коммерческими разработчиками.

В сложных проектах надо беспокоится не о попадании в условные эстимейты, а об инженерной культуре. Как набирается и ротируется команда? Как именно ведётся работа с техдолгом, автотестами, документацией? Сколько времени уделяется на ресёрч, и как он проводится? Что вообще у нас за проект, его цели, польза, сильные и слабые стороны? И так далее.

Вместо этого я нередко наблюдаю как менеджеры с квадратно-гнездовым мышлением типа "час разработки = бабки" пытаются высчитать, как сократить расходы, вместо того, чтобы думать о том, как зарабатывать больше за счёт своих конкурентных преимуществ.

У нас в сбере 10 лет назад был тайм-трекинг. Вот прям в сбере, а не в галере, работавшей на сбер. Причем в каком-то древнем всратом трекере от IBM.

Поскольку разрабам заниматься этим было в падлу, то ... что бы вы думали? Наняли(!) специального(!) человека(!), который по штатке тоже был инженером-разрабом 7-8 грейда, но занимался целенаправленно вот этой околотрекерной чепухой. Ну и еще какими-то околоадминистративными вопросами со временем.

Ну что, акулы бизнеса, сэкономили? Потрекали? Проконтролировали? Организовали себе расходы на ровном месте и получили дырку от бублика вместо контроля.

Ну я Сберу чем дальше, тем больше не удивляюсь.

Статья отличная, спасибо! Из моего опыта, проблемы в трекинге никакой нет, когда сотрудники не боятся списываться на бенч. Бенчи — проблема руководителя с точки зрения организации рабочих процессов

Наняли(!) специального(!) человека(!), который по штатке тоже был инженером-разрабом 7-8 грейда, но занимался целенаправленно вот этой околотрекерной чепухой

Он было один на сколько человек?... Если один на 20-30, то вполне нормальный налог на невроз руководителя, который думает, что часы дают ему хоть какую-то полезную информацию.

Но в продуктовых компаниях время трекают редко.

А можно узнать откуда такая "статистика"?

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

А можно узнать откуда такая "статистика"?

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

А кто-то где-то утверждал что это невозможно? И что жёсткий тайм-трекинг необходим именно для того чтобы успешно делать проекты?

А можно узнать откуда такая "статистика"?

Статистики в числах нет. Есть 17 лет опыта заказной и 3 года продуктовой разработки, и то, что рассказывают коллеги из разных компаний.

А кто-то где-то утверждал что это невозможно? И что жёсткий тайм-трекинг необходим именно для того чтобы успешно делать проекты?

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

Конечно, так происходит не везде и не всегда. Статья писалась для тех, кто чувствует, что с тайм-трекингом что-то не так, но не знает как с этим быть.

Статистики в числах нет. Есть 17 лет опыта и то, что рассказывают коллеги из разных компаний.

А если у кого-то совсем другой опыт и коллеги другое рассказывают? :)

А если у кого-то совсем другой опыт и коллеги другое рассказывают? :)

Поделитесь им. Если у двух умных людей расходится опыт - это прекрасный повод поговорить. У вас другой опыт это какой? В продуктовый компаниях тоже часто трекают время?

В продуктовый компаниях тоже часто трекают время?

У нас да.

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

Или для трэкания всяких финансовых вещей вроде нематериальных активов.

А можно чуть подробнее про:

трэкать взаимодействие команд/отделов между собой

Это как? И для чего?

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

для трэкания всяких финансовых вещей вроде нематериальных активов

Это как? И для чего?

Скажем фирма делает какие-то продукты. Есть "продуктовые команды", которые собственно делают продукты.

Есть какой-то "core team", который делает какие-то базовые вещи: общие фрэймворки, библиотеки и так далее и тому подобное.

Или там есть всякие админы/девопсы, которые занимаются инфраструктурой.

Теперь нам например надо как-то определить какие "продуктовые команды" грузят core team и админов своими запросами и насколько сильно.

Интересно, что это за нематериальные активы и как время с ними связано:

Определение вот: https://ru.wikipedia.org/wiki/Нематериальные_активы

Если грубо и в отношении ИТ, то например если фирма потратила время и написала свой фреймворк, то это нематериальный актив. Потому что это упрощает/удешевляет разработку в будущем.

Теперь актив у нас есть, но его ценность-стоимость нам неизвестна. Для расчёта существуют куча вариантов. Самый простой из них это просто посчитать расходы на создание. То есть кроме всего прочего например время, потраченное на разработку.

Теперь нам например надо как-то определить какие "продуктовые команды" грузят core team и админов своими запросами и насколько сильно.

Понятно. Трекать время админов и разносить его по разным запросам.
Кстати, если число запросов относительно большое (измеряется десятками), то можно просто измерять эти запросы в штуках. И без всякого тайм-трекинга получить результаты не менее точные.

Да-да-да, запросы бывают разные, бывают сложные и простые... Но Центральная Предельная Теорема все это сгладит.

Теперь актив у нас есть, но его ценность-стоимость нам неизвестна. Для расчёта существуют куча вариантов. Самый простой из них это просто посчитать расходы на создание.

А чем плох метод "грубо и на глаз"?... Ну типа N человек, X месяцев его пилили (примерно). Тоже, кстати, обошлось без тайм-трекинга. Ну да, не точно. А кто сказал, что тайм-трекинг - это точно?

Да-да-да, запросы бывают разные, бывают сложные и простые... Но Центральная Предельная Теорема все это сгладит.

А это уже зависит от ситуации.

А чем плох метод "грубо и на глаз"?...

Например тем, что он далеко не всегда устраивает инвесторов, акционеров и налоговую :)

А это уже зависит от ситуации.

Не понял этого. Вы не верите в Центральную Предельную Теорему? Что именно зависит от ситуации?

Я не верю что она одинаково хорошо работает во всех ситуациях.

В каких-то ситуациях достаточно считать количество обращений. В каких-то нужно трэкать именно потраченное время.

В каких-то нужно трэкать именно потраченное время.

Например, в каких? В каких ситуациях нельзя полагаться на ЦПТ и важно трекать именно потраченное время?

Ну хотя бы парочку примеров таких ситуаций.

Вы это сейчас серьёзно?

Вы же сами написали что запросы бывают сложные и простые.

Допустим у вас в этом году одна команда сделала 1000 простых запросов и на них в сумме потратили 100 часов.

А у другой команды один запрос, но на 1000 часов.

В реальной жизни вы эти ситуации и без тайм-трекинга увидите, да? ;-) Ну эти крайние.

А если запросов минимум десятки и они примерно одного порядка сложности (при оценке на глаз), то штуки дают удивительно точный прогноз. У нас с @anton_nix лет 5 назад стрим был, где он исторические данные по своим командам показывал.

Короче, все это контр-интуитивно, но... Хотите верьте, хотите нет, тайм-трекинг можно упразднить и многие моменты станут только лучше. И точнее. Если, конечно, экспертизы хватит.

Но можно не изучать, и просить с сотрудников заполнять отчеты о потраченном времени. Это проще. И привычнее. Новому не надо учиться, тоже для кого-то облегчение.

В реальной жизни вы эти ситуации и без тайм-трекинга увидите, да? ;-) Ну эти крайние

А если они не совсем крайние?

А если запросов минимум десятки и они примерно одного порядка сложности

А если нет? Почему вы постоянно пытаетесь исходить из best case?

Хотите верьте, хотите нет, тайм-трекинг можно упразднить и многие моменты станут только лучше. И точнее. Если, конечно, экспертизы хватит.

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

Но точно так же можно просто понимать что мир он разный и ситуации разные.

Это проще. И привычнее. Новому не надо учиться, тоже для кого-то облегчение.

Ну у нас это как раз таки скорее что-то новое. То есть лет двадцать назад таким вообще практически никто не заморачивался. Но со временем всё больше и больше фирм начали это делать.

Ну у нас это как раз таки скорее что-то новое. То есть лет двадцать назад таким вообще практически никто не заморачивался. Но со временем всё больше и больше фирм начали это делать.

Боюсь расстроить, но тайм-трекинг - это попытка переложить принципы научного менеджмента Фредерика Тейлора, которым больше 100 (прописью - ста) лет на интеллектуальную работу. Модели, которые хорошо описывали станки и механизмы с людьми работают как-то не очень. По крайней мере с теми людьми, кто не похож на станки и механизмы.

Идея учета рабочего времени вообще пошла века с 18-ого, когда началась индустриальная революция.

Так что и 20 лет назад этим занимались и 50 и даже 200...

Так что и 20 лет назад этим занимались и 50 и даже 200...

Да хоть 1000. Дело то не в том что этим где-то кто-то когда-то занимался. Речь о том, что для кучи фирм это сейчас как раз таки является чем-то новым и непривычным. Но они это у себя вводят.

И что жёсткий тайм-трекинг необходим именно для того чтобы успешно делать проекты?

Посыл статьи, как я

Посыл статьи, как я понял, что тайм-трекинг вообще бесполезен и не решает никаких задач.

Это однозначно не так. Он может решать кучу разных задач. Другое дело что эти задачи могут иметь мало отношения к разработке как таковой.

Он может решать кучу разных задач.

Интересно. Расскажите какие задачи и как именно.

Например использоваться для всевозможных финансовых отчётностей. Для планирования. Для управления ресурсами.

Для управления ресурсами.

А что вы подразумеваете под этим? И как тайм-трекинг там используется?

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

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

Естественно это не единственный вариант, но один из.

Надеюсь, сейчас придет @anton_nix и расскажет, что это всё можно сделать и без тайм-трекинга. Проще и точнее :-)

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

А вот будет ли это действительно проще и точнее это отдельный вопрос.

Важный момент: проще - для кого?

Руководителю проще не будет. Там надо немножечко математики и статистики вспомнить. Её хорошо бы всякому управленцу понимать, особенно учение о вариабельности... Там есть некоторые вещи, которые не всем ложатся в мозг. По этому да, проще не будет. Но, скорее всего, будет точнее.

Будет ли проще сотрудникам? К ним не будут приходить с требованиями заполнять тайм-шиты. Наверное им от этого немного проще станет.

Руководителю проще не будет.

Почему? Если трэканием занимаются подчинённые, а он получает автоматизированные отчёты и прикидки?

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

Будет ли проще сотрудникам? К ним не будут приходить с требованиями заполнять тайм-шиты. Наверное им от этого немного проще станет.

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

Кроме того сотруднику это в общем-то всё равно. Это же работа, которая делается в рабочее время и за которую ему платят. В чём проблема?

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

Руководство, как правило, не интересует масштаб часов и даже десятков часов. Руководство интересует масштаб сотен и, скорее, тысяч часов (нормальная команда 6-8 человек за месяц легко тратит на проект тысячу часов). А на таком масштабе уже можно не менее точно прикинуть в FTE.

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

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

У меня сейчас на это уходит ну максимум 5 минут в день. По хорошему ещё меньше.

Это вот прямо настолько нерационально с точки зрения фирмы?

Руководство, как правило, не интересует масштаб часов и даже десятков часов. Руководство интересует масштаб сотен и, скорее, тысяч часов (

С чего вы это решили?

Или таблицу распределения по проектам, если нужна разбивка по проектам.

Котоой тоже кто-то должен заниматься. И что в отдельных ситуациях, например у нас, как раз таки может занимать кучу времени.

Потому что проекты у нас маленькие и их очень много.

У меня сейчас на это уходит ну максимум 5 минут в день. По хорошему ещё меньше.

Это вот прямо настолько нерационально с точки зрения фирмы?

Если умножить 8 человек команды на 5 минут в день, то это выходит больше 3х часов в неделю. Мне, как руководителю, нужно 10 минут, чтобы посмотреть, сколько человек вообще в команде — и это мне даст достаточно информации о принятии решений по проекту. Поэтому не рационально.

С чего вы это решили?

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

Котоой тоже кто-то должен заниматься.

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

Если умножить 8 человек команды на 5 минут в день, то это выходит больше 3х часов в неделю

И это всё равно где-то 1% времени.

Мне, как руководителю, нужно 10 минут, чтобы посмотреть, сколько человек вообще в команде — и это мне даст достаточно информации о принятии решений по проекту

И если у вас это так, то это у всех будет так? Вам не надоело экстраполировать свой личный опыт абсолютно на всех?

Я имею ввиду планы по тому, кто на каком проекте будет работать. Такое в любом случае, конечно, нужно.

И как вы из этой информации получите информацию кто сколько времени в реальности потратил на каждый проект?

Вот у вас у человека-команды 50-100 проектов за месяц. Как вы узнаете сколько времени было потрачено на каждый отдельно взятый?

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

Это не означает, что Вася завышает оценку. Это означает, что Вася начал видеть проблемы, шероховатости и даёт более точную оценку в которую он уложится. Он стал более экспертным, так как уже делал проекты и понимает внутрянку.

Да, известная проблема. Поэтому лучше оценивать относительный объем (например, в поинтах или идеальных днях), а потом считать сколько сделано работы в неделю или за спринт, чтобы прогнозировать сроки.

Sign up to leave a comment.

Articles