Комментарии 9
В целом то мысли и правильные. Понравилась фраза про горлышко, которого «могло бы и не быть».
Но проблема в том, что автор, вероятнее всего, никогда не работал кодером и не видел, что таймтрекингом занимается занимается примерно никто. Это неудобно, отвлекает, а выхлопа дает мало в большинстве случаев.
Мне кажется, ценность продукта все же должно высчитываться не только по человекочасам разработки, а еще по другим метрикам тоже. Но я некомпетентен, поэтому примеров не скажу :)
Конечно, неудобно. Но вместо того, чтобы решить эту проблему - происходит имитация использования трекеров (+покупка, "внедрение", уговоры к использованию и тд)
Людей, непосредственно производящих продукт, в большинстве случаев, интересует сам продукт, а не возня с посекундной тарификацией. Им эти цифры и процессы не нужны, их важность они не понимают. Вернее, понимают, что это просто прихоть очередного начальника, для того, чтобы оправдать свое существование иллюзией бурной деятельности.
Кровати, чаще всего, переставлять бесполезно. Нужно организовывать ротацию "персонала".
Нормально продуманный тайм-трекинг не отвлекает и не занимает много времени. Что я пониаю под "нормальный": Разработчик не должен заводить себе таски, это задача pm. Разработчик не должен думать о статусах и т.п. Он видит первый по приоритету таск, нажимает "старт" и начинает работать. При переключении - "стоп" и "старт" нового. Это занимает 20-30 секунд. Мы внедрили подобную систему более 10 лет назад, первое время для контроля матчили с табелем рабочего времени, потом, когда убедились в достаточной точности учета, перестали.
Но как рассчитать точно это время?
Для этого не надо спрашивать всякие гугли, а только немного подумать.
Как правило какая-то команда, или команды, работают над одним и тем-же продуктом месяцы, или годы, так что просим бухгалтерию дать затраты на эти команды за определенный период, вот и все точные затраты.
Вроде есть компании, где люди прыгают от проекта к проекту даже в течении дня, там такой подход не сработает, но и там не надо никого напрягать никакими таймшитами и прочим бредом. Сейчас для управления разработкой все используют Jira, или аналоги, а там у каждого тикета есть свои сторипойнты. И пусть человек за неделю закрыл всего два тикета, один на 2 сторипойнта, второй на однин, первый из одного продукта, второй из другого. Берем его рабочие часы за неделю и две трети относим к одному продукту, а треть к другому. Ну и отпускные его тоже в пропорции распределить по его недавним проектам.
Так что все легко автоматизируется уже прямо сейчас, по имеющимся данным. Не нужны никакие дополнительные трекеры, или что-то еще.
но тогда молодым менеджерам по контролю и эффективной эффективности не получится показывать свою работу!! А это ведь так просто задавать простые вопросы: - как у вас не высчитывается посекундная нагрузка рабов?? ооо.. так у вас бардак!
Мое мнение, что к менеджменту интеллектуально емких направлений нельяз подпускать людей, котоые сами не поработали руками в какой-либо подобной отрасли.
Убедить пользоваться таймшитами очень легко: достаточно платить по ним. Ребята работающие в консалтинге, там где платят по часам, отлично следят за всеми тратами, включая полеты на самолётах и стоимость такси. Вот там все цифры есть, причем их можно проверить в бухгалтерии которая по ним оплачивала счета.
Только хорошо подумайте, нужно ли оно вам? ;)
Здравый мысли есть в статье - тот, кто платит разрабам не хочет, чтобы ИТ представляло собой черный ящик, на вход которого подали 100500 денег и на выходе (как правило) получили то, что нужно.
Стоило это то, что нужно, затраченных средств? Да Бог его знает!
Возможно тот, кто платил разрабам думал "Нет "дорогого" или "дешево" - есть "Могу позволить эти расходы" и "Не могу", так как считаю, что оно того стоит и ПО/фичи нужны.
ИМХО статья написана тем, кто хочет обосновать свое место в компании и свою зарплату.
Типа смотрите какой я умный(ая) - посчитал(а), что все эти "васи" нам обходятся в круглую сумму. И далее начнется "оптимизация" "А давайте Васю поменяем на Петю, их вот в очередь стоит дофига и платить можно меньше".
Гнать таких "оптимизаторов" в шею надо, если они перед этим с десяток лет не писали код в серьезных проектах и не знают кухню создания программного продукта изнутри.
Как-то так.
абсолютно здравые мысли
Отношения с IT. Часть девятнадцатая. Где твои тайм шиты, чувак?