Комментарии 126
А вы как думаете? Надо ли продолжать трекать задачи по минутам? Или пора перестать играть в контроль и строить доверие?
Вот не надо такое спрашивать - отвечать начнут.
Кому надо ли? Может трекать - цель, а не средство? Может кто-то за него надеется спрятать свою задницу, если что? Может работники обманывают и руководство обманывает и компания обманывает клиента - и он платит больше, ко всеобщему удовольствию?
Структура проблемы (кажущиеся нелогичными но предпринимаемые действия) встречается часто. И часто объясняется как карго культ. Я вот не могу сказать какая доля всей псевдо-IT деятельности вокруг является органичной. Общество же не обязано предаваться развитию и стремиться к прогрессу, в СССР вот и за качество и за внедрение достижений науки и техники велась борьба, это официально, а не официально - позорно слитая битва…
Результаты треканья сами по себе точно являются данными не зависимо от степени их искажённости, а пользоваться данными получается всё лучше.
К всякой глупости можно подстроиться, единственный минус - ускоренное размножение крыс по Гаррисону. Вот в том же СССР научные исследования велись по плану. Трекание скромно стоит в сторонке и молится чтобы никто не обратил внимание на ничтожество его тупости. И то, сам видел решение - в план вносились только уже выполненные, разумеется успешно, работы.
Ту трекать or нот ту трекать - очередное проявление Принципа Неопределённости, аналогично таковому в воспитании детей - либо будешь знать но не будешь действовать (по крайней мере обнаружимо для ребёнка), либо будешь действовать, но не будешь знать.
Беря паттерн с одного хорошего врача, которого видел в действии, даю совет
Ну и трекайте, если помогает.
Вот в том же СССР научные исследования велись по плану
Почему же только в СССР? Я уже писал об этом, но ещё раз повторю - в IBM каждому программисту не так давно вписывали (вероятно, и сейчас вписывают) в индивидуальный план развития на год обязательство подать заявки на 2 патента минимум. Бред? Конечно.
Не обязательно бред. Среди сотен бесполезных идей будет пара-две дельных. Да и общая тенденция к улучшательству создает правильный рабочий настрой.
Вы знаете, что такое сделать заявку на патент? Сколько там документов и прочего? Это кроме самой идеи, которая по плану в голове не рождается. Вот вы пилите фичу за фичей в большом проекте, и откуда у вас открытия или изобретения?
Ну не увольняют же инженеров за отсутствие патентов, просто премии большой не будет. В чем проблема?
А того, кто умный и много успевает, премируют и продвигают вверх.
КПИ в котором учитывается количество поданных патентов - одно из лучших изобретений в менеджменте.
Это еще японцы в 70-х поняли.
Даже умные программисты не делают изобретений на работе, особенно если это работа над коммерческим продуктом. Там просто нет ни денег, ни времени на исследования и изобретения.
Вы знаете, что такое сделать заявку на патент? Сколько там документов и прочего?
Я знаю, подавал, помогал другим, работал в оценке заявок внутри фирмы. Зависит от конторы. В той, где мне случилось этим заниматься заявкой об изобретении был 1 документ в котором нужно было заполнить два поля по существу - пять строк описания проблемы и двадцать строк описания решения плюс прикрепить схематический рисунок. Саму патентную заявку от вашего имени на 10-20 страниц в случае ее подачи пишет патентным вырвиглазным языком патентный адвокат. Вы ее проверяете, вносите правки. Далее вас привлекают при получении оценки патента от экзаменатора, на предмет новизны и отличия от ранее известных патентов и общедоступной информации. Если в ИБМ было сравнимо, то написание первичной заявки по такому сценарию занимает около часа, вычитывание окончательной заявки от адвокатов - несколько часов, так как она длинная и написана совершенно адовым канцеляритом.
Как хорошо и просто вы все описали. Наверняка вы в совете директоров IBM)
Я вам описал как это работает в средней руки компании которая подаёт 10-20 патентных заявок в год. У ИБМ, скорее всего, процесс похож, потому что этот процесс организован крупной фирмой патентных адвокатов, которая работает с множеством клиентов включая крупных. Если вы где-то видели гораздо более скверный процесс, где написание 100 страничного вырвиглазного канцелярита возложено на инженеров совершивших изобретение - ну бывает. Где-то вместо ERP системы используют в ручную обновляемый файлик экселя. Это не значит что так везде, или что так надо.
Нет, совершенно не бред.
Вы считаете, что патент это и изобретение, и новизна, и Нобелевская премия заодно. Однако огорчу - нет.
Патент - это способ защиты от троллей, которые выставляют иск на что-то слегка похожее на вашу технологию. И вы либо начинаете оправдываться, либо выкатываете встречный иск на десяток патентов, которые якобы нарушает тролль и все расходятся. То есть вам надо иметь достаточное число разных патентов для таких маневров. А так как американская система позволяет патентовать практически что угодно, то подобные патенты писать весьма легко.
В крупных компаниях достаточно сделать заявку в специальный отдел с невнятным описанием, поговорить с юристом, а потом пару раз перечитать заявку и переписку с патентным бюро.
За свою очень длинную карьеру программиста я даже близко не видел чего-либо, что можно было бы защитить патентом. И у себя, и у коллег. А уж как патентами защищается фирма, не моё программистское дело.
Figma запретила компании Lovable использовать в своих продуктах слова Dev Mode, потому что, оказывается, им принадлежит патент на них и никто теперь не в праве их больше использовать.
😊 И такое бывает
За свою очень длинную карьеру программиста я даже близко не видел чего-либо, что можно было бы защитить патентом.
В США алгоритмы патентуемы. Что много головной боли местами доставляет. Смотри, скажем, разные видео и аудиокодеки.
просто надо дальше развивать кругозор, и подумать "а зачем трекают?"
а затем чтобы знать сколько будут затраты, чтобы сравнить их с прибылью и решить а надо оно или не надо (выбрать правильное надо из нескольких вариантов)
только много ли вы видели задач в jira, где по саязям можно дойти до цели, посмотреть профит компании (и себя - премии например)?
и опана, оценку ты уже делаешь совсем с другим подходом;)
ну и классика таких статей - если эстимейтим задачи, то обязательно до минут и еще отчет каждый день в ворде. ну примите правило что минимальная оценка 1д, неужто так трудно в конце дня в задачу кликнуть за 30 сек часы.
Было у меня пара эпизодов, когда я трекал рабочее время. Это всегда отнимало больше ресурсов, чем 30 секунд в конце дня. Потому что блин, когда реально работаешь, то за временем не следишь, это все состояние потока.
И в итоге я время рисовал примерно правдоподобно и часто вообще забывал трекать, потом меня менеджер пинал, просил дописать. А по факту, я вообще не увидел, чтобы это на что нибудь влияло. Просто бесполезное давление на мою психику.
Чем это лучше простого соблюдения дедлайнов я так и не понял.
так менеджеры были выше такого качества, что толку от часов не могли показать. но причем тут вывод - вносить часы это плохо?
люди делают управление наполовину, ясен пень оно не работает, но вывод что первая половина от этого плохая - оно не от большого ума ))
Похоже, вы тот самый хороший менеджер (или, по крайней мере, знаете таковых) и можете объяснить, что вам дает этот подсчет времени (если вы работаете в продукте, а не продаете жопочасы разработчиков в розницу)
Вот заканчивается апрель, плохой менеджер команды смотрит какие задачи были сделаны за этот период (месяц.. или надо меньше) в целом. Хороший менеджер получает полную (и главное достоверную) почасовую разбивку по каждой из выполненных (или еще нет) задач суммарно и по каждому дню. Какие такие полезные продукту умозаключения может сделать хороший менеджер по этой разбивке, которая окупает 220 минут (22 дня * 10 минут) каждого разработчика и который нельзя сделать по списку задач?
Вот в точку, а ещё хотелось бы сразу понять какие же такие полезные решения на основании этих умозаключений можно сделать
вы не поймете ответа, потому что в вашей картине мира есть только занесенные часы... и все))
ну почитайте ответы выше то.
часы дают профит если есть не только они, но и связи с целями, которые имеют оценку хоть в каких то числах. часы должны с чем то сравниваться на старте, на ходу и по завершению.
ну классика - метод освоенного обьема. любой проект FP так работает. пообещали эпик сделать через полгода ценой 2 человек? ну вот вам и часы бюджета этого эпика, трекинг будет позволять видеть сколько часов вы уже сьели из своего обещания (тупо в jira забираете оценки часов задач в эпике из самого эпика) - действует очень отрезвляюще))
но пока в голове "писать код - это искусство" то этого не понять(( ЗП то капает и откуда взять бабло это задача СЕО, пусть он и отдувается.
часы дают профит если есть не только они, но и связи с целями, которые имеют оценку хоть в каких то числах. часы должны с чем то сравниваться на старте, на ходу и по завершению.
ну вот разрабатываешь ты какую то уникальную фичу, которая будет в одном экземпляре в твоем продукте. Что именно тебе покажет сколько часов на ее реализацию было потрачено ? Потратил ты X часов или X+100, дальше с этой информацией что будешь делать ?
Пытаться время потраченное на уникальную фичу на эрланге или коболе интерполировать на js/c++ ? )))
ну опять 25.
есть только занесенные часы? нет, с ними потом НИЧЕГО не сделать! епт ну читаем текст то.
если есть первоначальная оценка фичи в часах и потом фактически потраченные часы, да, можно посмотреть и если факт в 3 раза больше плана, есть смысл больше не связывать свои фичи с таким разрабом, пусть он с кем то другим интерполирует, если не может понять примитивов.
простой вопрос: сколько вам нужно времени, в часах, чтобы выкопать яму 1мх1мх1м ?
зависит от грунта, моего состояния, какая лопата, есть ли кирка, надо заложить риски что прихватит спину или еще чего.
это срок от 30 мин до 2 дней
и если всего этого не учел разраб при оценке эпика(фичи) мы с большой долей вероятности понятия не имеем, когда ее запилим. зато ЗП 10 числа все захотят в полном обьеме, не обращая сделана фича в срок или нет. а если контора делала фиче под кредит СЕО то продолжения тупо не будет
вопрос ни разу не прост
А теперь тот же вопрос но на марсе. Или как вам ниже предложили. Например работа моего отдела часто состоит в том, чтобы изобретать интерфейсы, которые подглядеть неоткуда, таких в природе никогда не существовало.
И да, за все захотят, потом зп, а грузить специалистов чужими заботами не нужно (кредиты итп), они не соучредители, не акционеры итд итп Мир вот таков, вы можете оценки делать только обладая чудовищным опытом, и то с допущениями и если задачи уже подобные делались.
PS а если он не прост какого ж черта всех программистов заставляют играть в эту сомнительную угадайку? Чтобы переложить ответственность ценной стресса исполнителей.
а что, хочется быть безответственным исследователем в коммерческой конторе?
и часы защита от таких нахлебников, но я понимаю что им от этого больно)) все таки их денюжек чужих на халяву лишают))
каких нахлебников? Работа разработчика - разрабатывать. Если PM сам неспособен оценить сроки и управлять ресурсами то замените его попугаем, а ставку отдайте разработчикам и они с радостью за дополнительные средства будут в предсказателей играть. И по такой же логике вверх до бесконечности. Если у вас все кто не играет в вангу - нахлебники, то вы один из менеджеров среднего звена и по идее как раз от вас стоит избавиться.
работа токаря - точить, сборщика - собирать.
и чего к ним нормы по времени предьявляют)
что, остановим часы на конвеере тайоты с ее бережливым производством?)
и только разрабы делают научный труд и все как один могут за денюжки ПМа оценить задачи пальцем в потолок. так и оценивайте, а то как виноват в сроках и увольняют, так ПМа. разрабы в этот момент как у Чуковского "под мосток и молчок")))
я был по обе стороны барикад
это срок от 30 мин до 2 дней
А потом оказывается, что яму надо на болоте и чтобы водой не заполнилась после того, как выкопали. Да, вот прямо в верхнем плавающем по воде слое.
ну да, управление требованиям никто не отменял.
правда те кто ноют про часы, требования обычно на входе хотят, еще и зафиксированные))
такие двойные стандарты
Мы в конторе пришли к тому, что записываем допущения, прямо в эстимейтах.
То есть во прямо заказчику и выкатываем в таком формате:
Если яма на земле
Если грунт твёрдый
Если есть лопата и кирка
То выкопать яму займёт 1-2 дня.
Если какое-то из допущений инвалидируется - надо делать переоценку
Чисто теоретически.
Можно оценить затраты времени с разбивкой по типам задач — Bug / QA / Story. Это даёт прозрачность того, сколько часов команда тратит на исправление дефектов, тестирование и разработку новых фич а также динамику этой метрики. Чего не достать просто из списка выполненных задач.
Было бы круто, если бы в трекере была простая кнопка: начал работать над задачей — закончил работать над задачей. Это можно было бы даже совместить с техникой Pomodoro (тогда не нужна кнопка "Закончил работу") - чтобы разработчику не приходилось вручную логировать время.
У нас в Джире есть такая кнопка. Постоянно её нажать забываю, бесит. Всё равно приходится руками в конце дня или в конце недели поправлять.
Но я полу-тимлид, бывает за день могу "потрогать" 10 разных задач - где-то код-ревью, где-то помочь разрабу, где-то емейл написать, где-то созвониться обсудить. Из-за частых переключений контекста для меня в целом трекание времени - ад.
это примитивно автоматизируется в жире на основе статусов. но там есть риск, что не получится ровно 40 часов в неделю.
У меня задача, как у манагера, поддерживать уровень billable (на клиента) работы на уровне 60% и больше на человека. Остальное стратегические задачи, внутренние проекты, обмен опытом и административка. В итоге достаточно удобный инструмент трекинга плюс выгрузки с работящих систем дают мне полную картину того, кто чем занимался и как я могу раскидать «платные» задачи. Сколько уходит времени я и сама знаю, но и «за руку» никого не ловлю. Люди сами на f2f говорят, что нужно больше billable работы.
Честно говоря, ни разу не видел сурового контроля по задачам. Обычно он требуется раз в неделю или в конце месяца. При хотя бы относительной точности (сколько полу-дней ушло на задачу) вполне полезен для себя, тимлида и выше. Времени на это тратится минимально в конце дня. Короче, не надо ударяться в крайности и всё будет ок.
В тоже время видел, как люди трекают время для себя - для оценки своей эффективности, для последующего применения в планировании. Сколько потрачено времени на рабочие задачи, сколько на созвоны, сколько на сон, еду, видео с котиками. Может быть полезно для рефлексии:)
Сам не сторонник треканья сотрудников, хоть иногда и хочется :D
В тоже время видел, как люди трекают время для себя
Кстати, крайне полезная привычка. Я в конце дня всегда прикидываю, уложился ли в график. Просто так, самодисциплина. Если нет — смотрю, что мешало и даю себе по голове.
Я кстати сам себя трекаю, правда очень вяло
Самотрекинг особенно хорошо работает, когда у вас проблемы с самодисциплиной
Буквально "несколько комментариев назад" люди писали про разбухшие уровни исполнения - когда программист вообще не в зуб ногой, что именно за продукт он делает, про бег ради бега, про то, что задачей разработчика становится освоение нового инструмента разработки (и впихивание его везде - новый же, красивый такой!)
Ну а чем менеджеры хуже?
На мой взгляд в статье Вы прекрасно описали последствия, в случае если результаты таймтрекинга приравниваются руководством к результатам работ. Весьма распространенное заблуждение.
Однако, в своей деятельности я тоже пришел к необходимости таймтрекинга. Однако, в нашем случае таймтрекинг используется только для того, чтобы превентивно выявить риски и адекватно спланировать работу сотрудников так, чтобы не было переработок и срыва сроков. Как я пришел к такой жизни и как у нас в команде используются результаты таймтрекинга я подробно описал здесь и здесь. Буду рад конструктивной критике.
Не понятно как вы оцениваете скорость выполнения задач. Задачи же разные бывают, на одну надо полдня, на другую три. При этом пишете, что не измеряете чистое время по задаче. Значит, на выполнение даже пустяшной задачи может уйти целый день, потому-то были созвоны, другие горящие задачи и много чего еще. В итоге показатель скорости будет сильно не объективен. А время выполнения всеравно знать важно, т. к. как иначе оценить трудозатраты по будущему проекту?
Очень бывает весело сам трекинг и превентивную оценку и совещания и прочий треп тоже включить в трекинг.
Все рассказывают про планирование, оценку затрат и приоритизацию и, мол, топам виднее. Ну, здрасьте, вот он я человек который десятилетиями с топами в обнимку. Еще ни разу даже отдаленно не слышал чтобы тайм трекинг приносил какую то пользу. А вот награждение непричастных и наказание невиновных - это постоянно. Рязанское чудо и прочие катаклизмы - запросто.
На самом деле, прежде чем серьезно обсуждать сей вопрос, сначала надо как то избавиться от бесполезных менеджеров, коих доля запросто доходит до 80%. Я за 20 лет практически не видел руководителя низшего и среднего звена, который бы четко понимал, что первая его задача - НЕ МЕШАТЬ.
Первая задача не мешать
Вторая задача решать типовые проблемы (и низкая производительность это проблема)
Третья задача устранять риски будущих проблем
4я это постановка задач, приоритеты и коммуникации
Ну а стратегией этот уровень менеджмента не занимается
Я за 20 лет практически не видел руководителя низшего и среднего звена, который бы четко понимал, что первая его задача - НЕ МЕШАТЬ.
Дельного менеджера с таким пониманием собственной роли быть не может. Ибо если этим его функции исчерпываются, то умный человек должен сознавать, что эта должность вовсе не нужна, и искать другую работу. Я своим всегда говорю, что моя работа – им помогать. Согласитесь, совсем не одно и то же.
Вы слушаете но не слышите
Вы слышите но не слушаете
Польщён. Это какой-то прям запредельный уровень эмпатии. Вот если человек слушает, но не слышит – тогда дело действительно плохо.
Ахах, очепятка, да, исправил, но мысль вы все же поняли
мысль вы все же поняли
Мысль-то понял – а вот её связь с моим комментарием нет.
Я написал что задача первая но не сказал что единственная. Ну и если в остальном вы не правы так же, поскольку большая часть ТН менеджеров только мешает
Я написал что задача первая но не сказал что единственная.
Первая – она же, вероятно, и основная? Во всяком случае, я так услышал. Если да, то не согласен, и написал, почему.
поскольку большая часть ТН менеджеров только мешает
Тут есть два варианта:
Вам сильно не повезло.
Вы на своей позиции не видите, в чём ценность деятельности менеджеров. Как в политике: "Очень жаль, что все, кто умеет руководить государством, уже работают таксистами и парикмахерами".
Есть ещё третий: вам очень нужно оправдать тех кого я описываю, ну например, вы один из них.
А я сам из менеджеров в том числе, CTO
Есть ещё третий: вам очень нужно оправдать тех кого я описываю, ну например, вы один из них.
Менеджер, безусловно. Но не один из – ибо задачи у меня совсем иные, под описание никак не подхожу.
А я сам их менеджеров в том числе, CTO
И видите свою задачу в том, чтобы не мешать? Гм.
И видите свою задачу в том, чтобы не мешать? Гм.
Как я вижу свою задачу рассказывать долго, команда у меня работает сильно иначе, чем обычно принято.
Но, кроме всего прочего, да, регулярно нужно просто не лезть в работу людей. Особенно с учетом, что большая часть UX спроектирована лично мной.
Попробуйте вот эту историю прочитать https://www.anekdot.ru/id/874395/
PS Кстати, по вашей же ссылке
команда у меня работает сильно иначе, чем обычно принято
В том смысле, что у вас там полно нижне-средних менеджеров, которые постоянно лезут не в своё дело, мешая другим работать? Сочувствую, но не стоит экстраполировать этот свой опыт на весь остальной мир. Тем более, сознавая, что оно у вас работает "иначе, чем обычно принято".
У меня в команде 2 менеджера высшего звена и все.
Слушайте, я правда пытаюсь вам объяснить, но ваша манера вести беседу "а вот у вас наверно все плохо, да", вместо того чтобы послушать, мне не нравится, посему я пожалуй пас. И, конечно, вы вольны думать как вам будет угодно.
PS хотя на мой взгляд, вы отлично иллюстрируете один из типов менеджеров "мне неизвестны детали, и вникать я не буду, лучше поосуждаю"
вы отлично иллюстрируете один из типов менеджеров "мне неизвестны детали, и вникать я не буду, лучше поосуждаю"
Почему же неизвестны-то? Я опытный менеджер, и вполне могу обсуждать утверждения, какие именно задачи для менеджеров приоритетны. И считаю, что если менеджер озабочен(а) по большей части тем, чтобы не мешать – это означает, что свои прямые менеджерские обязанности он(а) не выполняет, или что эта должность вовсе не нужна.
А обсуждаю я ровно то, что Вы написали – ни больше, ни меньше. На продолжении дискуссии не настаиваю, разумеется.
Вы который раз подряд приписываете мне то, что я не говорил. Нигде ни разу не было слов "основная", "по большей части" и так далее.
Вы считаете эту мысль ошибочную? (Она не только моя, вон цитата). Приводите аргументы, тогда составим разговор. Я вам привел и свою картину мира и историю с описанием итд. Вы в свою очередь как настоящий корпоративный политик вызываете к эмоциям ("если он умный человек", "я вам сочувствую" и ТД)
Автор вообще не понимает смысл и принцип работы трекинга времени. Трекинг нужен именно на глаз. А зарплата от него может зависеть только если у тебя закрыто по пару часов в день. И я не понимаю, что тут не так? Если офисный работник будет в офисе по два часа в день, ему не срежут зарплату?
Сделал за день до обеда две задачи, после обеда начал ещё одну - ставишь время 2, 2 и 4 часа. Да, туда попадут все чаепития и походы в туалет, и это правильно, потому что такие перерывы входят в рабочее время. И никто не устаёт от такого трекинга.
То есть в ситуации, где важна скорость, поощряется затягивание
Полный бред. У любой задачи есть эстимэйт, если будешь систематически затягивать, то это первое, что всплывёт на твоём performance review.
И теперь к вопросу, зачем это нужно: обычно в спринте две недели, это значит, что 80 часов задач - это максимум, который можно выдать на одного сотрудника. На практике это ещё меньше, т.к. есть ещё всякие совещания. Длинные совещания, кстати, тоже надо трекать в отдельную задачу, либо в ту задачу, по которой совещаешься. Так вот, единственный способ соблюсти дедлайн - это достаточно точно спрогнозировать время выполнения задач и взять в спринт столько задач, сколько может выполнить твоя команда. И если ты не знаешь фактического времени, затраченного на задачу, ты не сможешь оценивать качество прогнозирования. Кроме того, если трекинг ведётся своевременно, то проблемы, что кто-то где-то застрял можно локализовать как только они появляются, а не тогда, когда сроки уже поджимают.
Качество — это не только «сделал задачу», но и как сделал. Чем меньше исправлений, тем выше уровень.
Исправления точно так же трекаются. Если ты сделал задачу за час, а потом три раза по два часа исправлял, в итоге будет 7 часов. Плюс время, потраченное на ревью и тестирование. Обычно те, кто думает, что можно сделать тяп-ляп и быстро, со второго или третьего раза понимают, что надо делать сразу нормально и не торопиться.
И по поводу завышения оценок времени выполнения задач: в этом и есть ключ к успеху планирования. Если у тебя остаётся запас, его можно потратить на закрытие технического долга или обучение.
Если вдруг интересен мой личный опыт: я 5 лет работал без трекинга времени и выгорел к свиньям собачьим. После этого я уже почти 4 года работаю с трекингом, и у меня за всё это время не было ни одной переработки дольше 15 минут. И проблема дедлайнов у нас вообще никак не стоит - в конце спринта некоторым сотрудникам начинает не хватать задач, и тогда раздают задачи типа тут напиши документацию, тут пакеты обнови, ну или дают задачу из бэклога.
Обычно те, кто думает, что можно сделать тяп-ляп и быстро, со второго или третьего раза понимают, что надо делать сразу нормально и не торопиться.
Обычно "тяп-ляп и быстро" делают исключительно из-за сроков, назначенных руководством, которому хочется "вот прям завтра поразить заказчика вот такой крутой функцией" (у получить от заказчика денежку). А результат фундаментальной работы (грамотно спроектированной БД, хорошо читаемого и документированного кода...) виден далеко не сразу, заказчика им не поразишь, так что всё это переносится "на потом, когда будет свободное время" (а его никогда не будет).
Заниженные сроки - это действительно проблема. Но опять же, эту проблему невозможно решить, если ты не ведёшь учёт фактически затраченного времени
заказчика им не поразишь
Вот тут есть практически неразрешимая задача: берёшь, считаешь сроки, получаешь цифру, умножаешь на зарплаты, получаешь стоимость проекта. И понимаешь, что никто тебе за этот проект столько не заплатит. Очень часто такое бывает у фрилансеров или небольших веб-студий. Начинаешь думать, вот тут ужмёмся, тут подвинемся, а в итоге сорванный дедлайн, переработки, кассовый разрыв. Я не знаю ни одного примера, чтобы кто-то из этого выбрался. Выход один - уволиться или закрыть контору. А разработчик, набравшись опыта, может пойти в одну из тех самых контор, которые пилят сайты не под ключ, а по 300к$ в год.
Я против жёсткого контроля, что б вот получалось 40 часов в неделю. Но. Фиксировать реальное время, затраченное на задачу нужно. Особенно если это задача не из серии "составить план для разработки плана".
Во-первых ты понимаешь реальную скорость работы человека. Кто-то работает быстрее, кто-то медленнее (ну вот каждый человек индвидуален). Иногда случается, что при анализе затраченного времени выясняется, что есть э какие-то устоявшиеся телодвижения, которые уже не несут какой-то ценности, а человек желает уже по привычке и тогда нужно решать - продолжаем это делать или нет. Иногда всплывают пробелы в знаниях, их надо устранять. Иногда просто подсказать лайфхаки, что б можно было сделать быстрее.
Во-вторых - сохранена история затраченного времени помогает делать хотя бы первичную оценку будущей задачи, особенно если речь идёт о крупных изменениях.
Но вот этот микроменеджмент с мнением, что 8 часов в день должны быть расписаны, приводит к тому, что да, пишут от балды, лишь бы отстали.
Во-первых ты понимаешь реальную скорость работы человека
Я и без этого понимаю. Для этого всего-то и нужно, что следить за выполнямыми командой задачами. Имея при этом в голове некоторое понимание сложности каждой, и при случае не стесняясь спросить исполнителя, в чём у него затык и нужна ли помощь.
При больших объёмах работы и на большом отрезке времени это уже не так просто держать все в голове (да и смысла нет).
Ещё состав команды может меняться. Или вы переходите в новую команду в роли лида.
При больших объёмах работы и на большом отрезке времени это уже не так просто держать все в голове
Если объём превышает возможности одного человека, то пора дробить команду на более мелкие, и делегировать контроль низовым менеджерам. А больших отрезков при грамотной декомпозиции задач и вовсе быть не должно.
Трекинг времени полезен в том плане, что в конце отчетного периода можно сделать конкретный отчёт по задачам, где была работа. Объективная оценка своего труда вместо слов 'я молодец'.
Время - это ваш персональный, ограниченный ресурс. Всегда полезно знать, на что уходят ресурсы и как эффективно они расходуются. Вам лично полезно. И если вы сами трекаете своё время, то другим дать отчёт, на что уходит ваше время - проще простого.
Чем больше работаю со всеми этими скрамами, тем больше тоскую по старым жутко неэффективным, б-гомерзким практикам. Раньше тебе давали какую-то задачу, срок на ее выполнение, причем сроки там нарезались не часами а неделями, а то и месяцами. И ты просто работал над задачей. Тебе не клевали мозг каждый день всякими митингами, созвонами, таймтрекерами и прочей микроменеджерской тряхомудией. Тебе, блин, доверяли! И я не припоминаю каких-то особо лютых факапов при такой работе, да, не всегда все было гладко, так оно и со скрамами не идеально все. Зато ты спокойно и размеренно работаешь, не занимаясь по полдня всякой фигней, что-бы продемонстрировать менеджменту свое трудолюбие.
Раньше тебе давали какую-то задачу, срок на ее выполнение, причем сроки там нарезались не часами а неделями, а то и месяцами
Скорее всего, там были проблемы с проектированием. При грамотно проведённой декомпозиции задач такой длительности просто не должно быть. По крайней мере, как системы – какие-то редкие исключения возможны.
А "все эти скрамы" отнюдь не предписывают поминутный учёт времени. Сам работаю в режиме недельных итераций, и тайм-трекинг не использую. Зато имею уверенность, что каждая из выполняемых в данный момент задач действительно актуальна для бизнеса, и даже если потом окажется, что идея была ошибочной – потеряю всего неделю, а не месяцы.
Задачу отдавали на реализацию специалисту, который сам для себя и делал декомпозицию.
А Скрам - это про конвейер, кто-то умные декомпозирует задачи, которые скидываются на конвейер. Да, это м.б. и эффективно выглядит, но это тоже еще вопрос - выглядит или является. При такой работе чудовищные издержки на организацию всего этого конвейера. Вместо того что-бы просто сделать часть работы и тут-же начать новую, конвейерный труженик тратит кучу времени на трекинги, на митинги, на созвонинги, на двигание тикетов и прочее-прочее. И мотивация у него как правило типично конвейерная - взял задачу, сделал задачу, отрапортовал, взял задачу, сделал задачу, отрапортовал.. Весело до одурения!
Скрам - это про конвейер
Встречал и такие реализации – очень плохо, и в целом свидетельствует о непонимании сути технологии. SCRUM в чистом виде никогда не использовал, но смысл любой эджайл технологии именно в повышении степени информированности и вовлечённости исполнителей – когда они понимают конечную задачу и стремятся её реализовать максимально эффективно. Это прямо в манифесте записано, и всё, что этому противоречит, есть ересь.
С этой точки зрения каскадная модель (тебе написали ТЗ и сиди, выполняй в строгом соответствии с написанным) гораздо ближе к конвейеру. Только он очень медленный.
Я не силен в терминологии. Просто хорошо помню как оно раньше было, м.б. и не так все приятно и понятно для менеджмента, но разработчику было намного комфортнее работать, как по мне.
Задачу давали достаточно крупную, ТЗ обычно не конкретизировало все заклепки, у исполнителя было довольно много свободы в реализации, и было время на спокойное планирование, анализ и погружение в задачу, если что-то было непонятно, то всегда была возможность уточнить и как-то обсудить проблему. Общения тоже хватало, но оно по делу было, а не в виде каких-то там ритуалов. Вовлеченности было через край, потому что ты делаешь большую задачу, знаешь что и как там работает, у тебя кругозор просто больше, ты, условно говоря, не обтачиваешь напильником пару заклепок, а собираешь двигатель, понимаешь как и для чего он работает..
Да, наверное, отчасти это у меня уже старческое брюзжание начинается :) Но как-то мне все эти современные аджайлы (или ересь на их основе, уж не знаю) в какую-то тоску и уныние загоняют, осточертели уже эти ритуальные танцы вокруг заклепок и напильников.
Просто хорошо помню как оно раньше было, м.б. и не так все приятно и понятно для менеджмента, но разработчику было намного комфортнее работать, как по мне.
Жизнь тогда была совсем другая. Прежде всего – темп жизни. Эджайл – ответ именно на это, сейчас невозможно пилить систему годами до её выхода в продакшн – обязательно найдётся кто-то другой, кто сделает раньше и снимет все сливки. Именно с этой точки зрения жизнь была более комфортной (не только у разработчиков) – не было этой непрекращающейся гонки. Вообще конкуренции как таковой не было – каждый проект делала одна конкретная организация. Зато и прогресс сейчас идёт гораздо быстрее – что, разумеется, хорошо, но тоже в каком-то смысле добавляет дискомфорта, ибо и самому нужно за ним успевать.
Мне эджайл нравится, уже 20 с лишним лет по-другому не работаю. Но у меня он без фанатизма: беру только то, что на самом деле помогает конкретно в моём случае. Одно неизменно: короткие итерации и непрерывная обратная связь. Это действительно помогает раннему выводу продукта и внесению корректив в разумные сроки. Коммуникации по необходимости, обязательных встреч всего две: по пятницам внутрикомандные, подбить результаты прошедшей недели, и по понедельникам общая, с обзором состояния в целом по проекту и корректировкой приоритетов. Нам достаточно для того, чтобы все были в курсе происходящего и видели своё место в общей картине.
Да вот я не уверен что все эти практики с микроменеджментом это точно про высокую скорость разработки. Вы неминуемо тратите кучу времени и сил на всю эту сопутствующую деятельность - митапы, передвижение тикетов, планирование, учет часов, отчеты и т.д. и т.п. С точки зрения менеджмента это понятно, им так комфортнее и приятнее - у них создается иллюзия контроля за процессом. А вот именно с точки зрения комфорта и скорости разработки - это очень спорно.
Когда задачи нарезаются и решаются большими кусками, с декомпозицией и решением более мелких подзадач сами исполнителем, то вся эта суета не отнимает столько времени и сил. Но тут нужно что-бы менеджеры доверяли разработчикам, и разработчики нужны не плана - легкозаменяемый юнит - крудошлеп-джейсоноукладчик, нужен ответственный и профессиональный сотрудник, которого нет необходимости пинать на каждом шагу, как ленивую и уставшую лошадь.
Вы совсем не понимаете, как работает эджайл. Очевидно, это вина тех "эффективных менеджеров", которые внедряли модные технологии, совершенно не разобравшись в их сути, и в результате испортили им репутацию у множества разработчиков. В настоящем эджайле нет буквально ничего из Вами описанного, это совсем иначе работает.
Не скрою, когда году в 2002 один заказчик (друган аж самого Кента Бека) принёс нам на хвосте хР, тоже сначала подумал: что за дичь такая. Но вскоре проникся – ибо результаты говорили сами за себя, нужно было быть дураком, чтобы не увидеть преимуществ. С тех пор сам несколько раз сам организовывал такую трансфомацию – и всегда это приводило к улучшениям. В том числе и к повышению удовлетворённости разработчиков. Например, сейчас у меня в команде средний период трудоустройства превышает 10 лет. Было бы такое возможно при наличии всех описанных Вами ужасов? Согласитесь, вряд ли.
И я не припоминаю каких-то особо лютых факапов при такой работе, да,
Коротки спринты позволяют непрерывно отслеживать состояние проекта и прогресс сотрудников.
Далекий 2005ый. Имеем талантливого разработчика с невероятной эрудицией и познаниями. Познания эти сегодня бы названли олимпиадными. Он очень хорошо помнил и разбирался в матане, алгоритмах, нюансах яызка, ОС, памяти и т.п.. К нему постоянно ходили посоветоваться, включали во всевоможные брейнштормы. Совершенно заслуженно! Назначенные ему таски(небольшие) закрывал исправно.
И вот ему доверили такую вот большую задачу и отвалили. Задача на 3 месяца.
В основную ветку его версия подсистемы попала через 5 месяцев. Позже её всю пришлось выкидывать и переписывали другие люди. Просто оказалось тердые и глубокие знания матана и С++ не помогли в дизайне крупного куска функциональности. Там были совершенно дурацкие решения, нерасширяемый код. Рефаторинг невозможен.
Конечно у него не было такого опыта.
Кроме того, в 2005 все существовашие решения подобные его задаче у всех компаний были самописными и пределов студий не покидали, т.е. подходов и типовых решений\библиотек\фремворков просто не существовало. В паблике или книгах что-то найти невозможно. Золотые времена велосипедостроения =).
Чат гпт, напиши мне статью о вреде трекинга
Одно из самых вредных в трекинге это предположение об одинаковой производительности все 8 часов рабочего дня. А ещё предположение о нулевом времени переключения между задачами. И в статье это не указано
Приходилось поработать там, где трекинг времени используют менеджеры для оценки и планирования, так вот совпадение или нет менеджмент был не просто не в курсе, как происходит разработка, а вот вообще ни сном не духом. Поэтому руководству нужны были формальные ориентиры. Там, где менеджмент не условные "из продавцов обуви в разработку сервисов" таких проблем не было и трекинг если и был, то просто чтобы вспомнить, что делалось и в каком порядке, если забудется.
Если я не буду трекать задачи, мне навалят их на 8 рабочих часов каждый день и будут требовать выполнения. А так — я сделал мало, но вы мне и заплатите только за 4 часа, всё честно. А больше сделать я просто не могу, меня вырубило до утра.
Мне время трекать не тяжело. Сел за работу — кликнул один раз в углу экрана. Закоммитил — списал кусок времени, перезапустил таймер. Очень редко в моей работе бывает, что нужно посреди работы одного таймера переключиться на другой, но на этот случай у меня есть секундомер в наручных часах, а в самых плохих ситуациях — секундомеры в телефоне.
Знаю, что есть люди, которые могут забыть, что у них на плите суп жарится, но я обычно не забываю про кнопку.
На самом деле, я бы с удовольствием перешёл на работу с фиксированной зарплатой, потому что 4 часа в день — это очень бедно. Например, на этой неделе у меня упадок, я смог выдавить только 15 часов. Вот только, я боюсь, что с фиксированной зарплатой будут спрашивать за 40 часов.
Трекание потраченного времени -- ересь полная. Я трекаю остаток оценок по задачам, и то только для burndown'а, чтобы понять заранее, что спринт пошёл не так. А кто там сколько потратил -- нафиг мне это вообще знать? Когда кто-то халявит, это и так видно, а гестаповскими методами проверять каждого -- только ухудшать ситуацию. Команда, с которой ты враг и для которой ты источник постоянных проверок, не будет работать эффективно. И зачем тогда этот разрушающий контроль? Дела испортить?
Не, ну, конечно, бывает разное. Низкооплачиваемый низкоквалифицированный труд, высокая текучка, человек -- винтик, всех легко заменить. Но это совершенно особый случай, и обычно работать в таком месте не слишком интересно, скорее всего, я, как аджайл-коуч, туда просто не пойду. Кому из нормальных людей интересно быть надсмотрщиком в концлагере?
Буквально неделю назад уволился с такой работы, где микроменеджмент и борьба с ветряными мельницами победили над здравым смыслом. И таймтракинг ради таймтракинга стал одним из пунктов почему я предпочел уйти.
Эту проблему обнаружили лет так 20 назад, и давно уже обсосали со всех сторон.
Вкратце, она формулируется так: "вы можете использовать формальные показатели для оценки прогресса/готовности, но как только от формальных показателей начинает зависеть оплата/повышение, люди найдут способ их фальсифицировать".
Учёт времени, потраченного на задачу - важен и нужен. Он позволяет руководителю (и вам!) оценить, какие задачи уже далеко продвинулись, а какие - конь не валялся.
Учёт времени на задачи - позволяет более-менее адекватно оценить и запланировать необходимое время на аналогичную задачу, когда она непременно возникнет в будущем.
Учет времени для задачи, разбитой на подзадачи - позволяет продемонстрировать менеджменту, что на задачу "сделать охрененно" действительно надо потратить 5000 часов, а не "ну, что там делать-то, за неделю соорудите быстренько".
Для непосредственного начальника, он таким образом может оценить, какова нормальная производительность разных сотрудников. И учесть при планировании.
Но - как только "часы на задачу" будут непосредственно учитываться для установки зарплаты, или для повышений - люди немедленно найдут способ фальсифицировать систему учёта.
Что мешает менеджменту сказать что на эту задачу ты затратил через чур много времени? Порой одну задачу ты делаешь день и туже самую в следующий раз делаешь неделю. Предсказание сроков что по трекеру времени что по результату прошлого спринта будет плюс минус одинаково хреновой. Только во втором случаи не нужна вся это возня со списанием
Если одну и ту же задачу делал день, а потом неделю, это повод сделать определенные выводы, если нет объективных причин, то такого быть не должно.
Трекинг это довольно простой способ оценивать время выполнения задач и эффективность работы сотрудников. Проблема в том, что другие метрики более сложные. Если мы хотим как-то оценивать сотрудников между собой и время от времени их повышать, то нужны прозрачные метрики, и трекинг времени тут может помочь. Хотя бы можем видеть, сколько времени уходит на решение схожих задач у разных сотрудников, а так же оценить кто и чем примерно занимался за последний месяц/квартал.
Да все очень просто, проблема стара как мир. Самая "мякотка" подобных процессов - это то, что авторы "процессов" - это те, кто НЕ следуют своим правилам. Ботинок должен прочно стоять на голове подчиненного, это их мораль. А движут этим банальные страх, жадность, тщеславие, и т д. Прослойка "отлетевших" продолжает разлагаться и пределов этому нет, здесь наивность опасна. Если за вами пассивно-маниакально "бегают" с линейкой и одержимостью измерять все и вся - это уже беда общая. Всегда должно быть интересно вот что - а что я вообще здесь еще делаю?
До айти работал в электрических сетях, была у меня такая задача - звонить на электростанцию вечером и записывать почасовую мощность в журнал за день. Иногда я забывал это делать, и опытный коллега подсказал, что можно просто вчерашние часы в журнал проставить. Ну или по желанию что-то поменять.
А я думаю, что зависит от сотрудников, которых ты себе нанимаешь. Если гиперответсыенных, то трекая и контролллируя, загонишь в стресс, а они и сами в него загоняться горазды. Если таких, которым вообще все равно, чтоттам с бизнесом, только деньги плати, то контроль нужен, но они знают как и под контролем не переусердствовать.
Был я в ситуации, когда в компании был отличный трудолюбивый коллектив, нормальное руководство. А потом поставили руководителя, который никому не доверял, и считал, что все только и хотят получать деньги и не работать. Начались все эти штуки с контролем. Что сейчас: меня там нет, как и большинства сотрудников, которые работали усердно и без контроля. Ну приходили новые, и задерживались, в основном, те, кто умеет не перенапрягаться, отлично делать видимость работы, присваивать себе результат чужого труда и понравиться руководителю
Но если копнуть глубже, становится видно: оба хотят одного и того же — чтобы дела компании шли хорошо, потому что в компании с финансовыми проблемами плохо всем
Идеалистические представления о бизнес-процессах. Согласно пирамиде Маслоу, желание (в данном случае у менеджмента) самоутвердиться (даже за счет других) будет превалировать над простой финансовой выгодой (к тому же еще не факт, что она вообще будет). Это проблема не слабее классового антагонизма Маркса, и трекингом (или его отсутствием) она не решается.
Это проблема не слабее классового антагонизма Маркса
Так это он и есть.
Объективный интерес предпринимателя - в том, чтобы получить от труда разработчика результат за как можно меньшие деньги. Один из способов, как это можно сделать - побудить разрабочика работать как можно быстрее, ибо обычно разработчику платят за потраченное им время, т.к. по-другому не получается.
Объективный интерес наемного работника - разработчика - получать как можно большие деньги за тот же уровень интенсивности, т.е. напрягаться, чтобы сделать работу быстрее, разработчик объективно не заинтересован.
Вот это - две стороны того самого антагонистического противоречия по Марксу.
Ну, а менеджер - он посредине. С одной стороны, он объективно заинтересован действовать в интересах предпринимателя: сделать так, чтобы разработчик давал больше результата за те же деньги - менеджеру за это как раз и платят. С другой стороны, менеджер - он тоже наемный работник, а потому тоже объективно заинтересован в том, чтобы лично работать менше и/или менее интенсивно.
Всё это - объективная основа отношений участников процесса: в одном и том же они объктивно не заинтересованы, наоборот, имеет место борьба противоположностей их интересов. Но и единство противоположностей тоже имеет место - если участники процесса не будут работаь совместно, то они рискуют ничего не получить. Такая вот диалектика: единство и борьба противоположностей.
А субъективные факторы уже наслаиваются сверху. И их можно считать в конечном итоге вторичными, поскольку люди приспосабливаются к своему объективному положению и субъективные факторы меняются в сторону соответствия этому объективному положению. Но это - именно что в конечном итоге, в конкретном моменте может быть всякое разное. А потому толку от марксизма на практике мало.
Почасовая оплата с трекингом — часто единственный рабочий вариант для фриланса и удалёнки, особенно с клиентами, которые не могут чётко сформулировать задачу или меняют требования на ходу. Фиксированная оплата за результат в таких условиях либо требует сверхточной оценки (что почти нереально), либо ведёт к бесконечным переговорам о доплате за новые задачи. Почасовая модель позволяет просто работать и выставлять счёт за фактическое время, не тратя силы на постоянные переоценки. Трекинг даёт прозрачность для клиента и избавляет от необходимости угадывать объём работы, фиксируя затраты по мере выполнения. Это особенно актуально в долгосрочных проектах с высокой неопределённостью.
Трекать задачи полезно, если задачи повторяющиеся, в повторяющихся проектах. Из этого складывается понимание «а сколько на самом деле стОит задача».
Можно сделать ретроспективу и отловить убыточный проект.
В любом случае, в «недисциплинированном треканьи» правды больше, чем в «недисциплинированном нетреканьи» (что эквивалентно «прикинуть на глаз»)
В нормальных компаниях время не трекают.
Это база.
Если в описании вакансии увидели такое - вам туда не надо, значит там и с остальными процессами всё плохо.
Надо ли продолжать трекать задачи по минутам? Или пора перестать играть в контроль и строить доверие?
Вопрос неверный в своей сути. Правильный вопрос здесь: "Зачем трекать задачи по минутам?". Иногда это вещь, вообще не связанная с недоверием: к примеру, я прочил некоторых людей в команде трекать задачи с квантом 10-15 минут. Мы с ними так разбирались куда утекает время. Порой три-десять дней такого трека - и, вуаля! - паразитные активности выявлены, есть план по их устранению, и перформанс человека существенно вырастает. Больше скажу, я сам порой так трекаю время для себя, когда начинаю ощущать что трачу время не в том направлении. Так что оно не всегда про контроль
Мы занимаемся IT аутсорсом, и у нас в основном техподдержка и сисадмины. И у нас ввели трекинг времени по двум причинам:
1) менеджерами у нас никогда не ставят самых опытных, потому что они больше пользы приносят как специалисты. А так как все на ставке, то нужно следить как-то чтобы работники не шланговали. Это конечно давно уже сформировало круговую поруку в отделах.
2) Заказчик хочет видеть за что он платит деньги. Т.к. качество человеков на позициях, которые отчитываются клиенту такое себе, то у клиента есть доступ в систему, где он сам может почитать time entries по своим тикетам.
У меня была работа, где всё было хорошо налажено без таймтрекера. Там начальство понимало что мы делаем и помогало в работе. Там ценность работника определялось тем, сколько на себе работы тянет чел и что он умеет. Тому кто инициативно брал на себя самое сложное и его не нужно было контролировать, со временем отдавали самые интересные задачи. И лучшим способом расти как профессионал было инициативно прилепиться к такому человеку, забирая на себя рутинную часть на его задачах. В благодарность тебе показывали как задача была решена и на следующий раз доверяли всё большую часть этих задач. Так люди сами становились "китами". А тот, кто хотел просто тихо отсидеть своё время и не напрягаться, тоже находили себе место.
предлагают один KPI, заменить другим. По мне все вы одинаковы.
Трекаю время сотрудников, ибо участились без него случаи, когда сотрудник не справляется с дедлайнами и предоставляет мало работы, ссылаясь на её сложность. Трекать начали, работа ускорилась на порядок.
Автор вообще руководит людьми или просто набрасывает фактов из интернета?
Личный опыт то какой?
Трекинг это просто один из инструментов учёта. Надо это принять и жить с этим
Теоретически трекинг нужен. Как еще руководитель может оценивать сложность и планировать ход процесса?
Но это теоретически. А практически лично я всегда сталкивался с ситуацией, когда сначала просят оценить примерно, а потом эта оценка превращается в жесткие рамки. Особенно смешно, когда просят оценить задачу сходу. "Ну ты примерно скажи, потом скорректируем". А потом: "Ну ты же сказал, что неделя, почему не уложился".
Честно говоря, везде куда прихожу внедряю трекинг. И всем вначале совсем не нравится ещё одна обязанность. Но цели трекинга у меня вообще другие. Я не переношу kpi для разработчиков, слишком много факторов. И если честно предварительную оценку трудозатрат делаю с учётом конкретных людей и типов задач. Где-то задачи нудные но их много, где разработчик быстрый но не внимательный. При трекинге прошу заполнить 8 рабочих часов, перекур, игры в ps тоже входят в проекты, точность не требуется. В целом, мне нужно понять реальные трудозатраты по проектам. Когда клиент один, то конечно не заморачиваюсь, все затраты на одного и не нужно трекинга. Как бонус, понял что слишком много пустых собраний, где люди говорят одно и тоже. Теперь собрания только по необходимости. И состав тоже.
Штош. Недавно расстались с одним таким героем трудовой доблести. Вообще трекинг времени в команде не принят - и без этого понятно, что люди работают с большой ПЕРЕработкой и грузить их дополнительными контролями, мягко говоря, контрпродуктивно. Но один, видимо, решил, что "взломал систему": даёшь поручение, даже с запасом по срокам - не выполнено (потому что %перечень причин%). И так раз, другой, третий. Плюс ещё кое-какие факторы трудовой дисциплины. И итоге потребовали отчёт по задачам и ввели рабочую машину в контур мониторинга рабочего времени. Оказалось, что 80% того времени человек тратил на чтение развлекательных ресурсов и общение на форумах по его хобби. Предложили расстаться по-хорошему
По опыту скажу, такое решение — удел слабых менеджеров, которые не в состоянии не то, чтобы вести за собой команду, но даже здраво мыслить :(
Был опыт офисной работы, где по итогу начались угрозы кипиаем, мол наш отдел ни черта не работает. А мы работали втроем, но с нагрузкой за десятерых. Даже был другой опыт работы с кипиаем, с прописыванием выполненных задач: каждый день одно и то же в чат с гендиректором, какая тупость ... До сих пор передергивает от этих опытов.
ПС.
Работать надо, товарищи, не мешать, а не визжать с пеной у рта и угрозами — это я обращаюсь к самодурам, которых назначили по кумовству, а не реальным способностям.
По моему мнению, трекать время нужно, но есть нюанс.
Если на выполнение задачи было выделено, условно, 3 часа, и по какой-то причине ты не успел выполнить её. Тебе нужен ещё час, ты после выполнения объясняешь, в чем причина задержки и получаешь ответ: "принято, в будущем сделайте то и это, можете также ознакомиться с Х ресурсом, будет полезно". Такой ответ будет полезным для сотрудника. Тот будет знать, что если в будущем сроки будут также поджимать, он спокойно соберётся с мыслями и сделает как нужно.
Если же он получит ответ в роде: "понятно, Вы когда сюда пришли, на что рассчитывали? Вы не выполняете свои обязанности и за это мы реплика про штраф и иные взыскания. Тут сотрудник мало того, что получит удар по кошельку и репутации, так ещё и будет чувствовать себя беспричинно наказанным. И в дальнейшем он будет то и дело смотреть на часы, тут уже и задача не будет выполнена качественно, и менталка полетит.
Трекинг, если без программ слежения за курсором и привязки к зп, в целом вещь хорошая для работодателя, но так как так делают далеко не все, то нужно платить выше рынка за доп. стресс. И учитывать, что текучка увеличится.
С программами слежения - сильно выше рынка, чтобы предотвратить сильную текучку, и сотрудники будут выгорать от сильного стресса. Мало кто из крутых специалистов согласится даже за большую зп.
Учитывая это, имеет смысл 10 раз подумать, перед тем как что то подобное вводить - может дейли с компетентным менеджером вполне хватит.
Мне вот всегда было интересно, как вы простои по вине Заказчика будете считать, банальная итерационная задача, где с точки зрения Заказчика два состояния - задача поставлена/задача решена, а с точки зрения программиста это будет 10-15 итераций, по простой причине - Заказчик не в состоянии сразу сформулировать все требования и выдает корректировки в n шагов, причем не смотря на жесткий временной регламент на время реакции, регулярно завышает сроки ответа на уточняющую информацию. Дальше имеем побочные артефакты, как время переключения с другой задачи со стороны программиста при получении очередного уточнения от Заказчика, это я еще не упоминал в этой цепочке парочки аналитиков и ПМ. В результате данные, которые выдаст лобовой трекер фиксации времени, будут также полезны, как потолочные данные. Фиксация времени имеет смысл для решения типовых операций с заранее прогнозируемым лимитом на их решение, только для таких операций и системы не нужны, если менеджер в состоянии в уме 17 на 15 умножить-))
Лично знаю одного тимлида, который два года заносил свои задачи сначала в блокнот, а потом в субботу тратил час-два-три времени на перенос этого дела в мандей (иногда треккинг за неделю+). И нет, он не мог сразу заносить в мандей это дело, это отвлекало и порождало кучу доп. процессов. Что всплыло? Кол-во часов переработки на неадекватную компанию. Результат: увольнение и оффер в нормальную компанию.
Трекинг времени отлично работает и приносит пользу всем. Но для этого необходимо, чтобы соблюдались 2 условия:
Отчетный период должен быть не менее недели. В идеале - месяц (это зависит от сложности задач). Детализация отчетов должна быть соответствующей.
Основные накладные расходы трекинга на общий процесс должен брать на себя специально выделенный сотрудник. В идеале - ИИ. Идеальный источник данных - git.
Трекинг по часам силами самих разработчиков - это хрень полная, которая как назойливая муха только мешает работать. Чем выше уровень задач - тем хуже это будет влиять на тонус команды и результат в целом.
Соответсвенно, если вы компания подрядчик - не продавайте работу по часам, продавайте неделями и месяцами (месяц - это удобно тк привязано к выплате ЗП). И будет вам счастье.
По предлагаемым в статье советам, как нужно делать, можно написать еще одну статью, как делать не нужно.
> Скорость закрытия задач... смещаем фокус с «дольше работаем - больше денег”, на “быстрее работаем - больше денег”.
К бабке не ходи, итогом будет потеря качества, х+х=прод, все дела.
> Чем меньше исправлений, тем выше уровень.
Продолжаем усиливать эффект х+х=прод.
> Удовлетворённость клиентов.
Спросите клиента, как ему лучше - подождать еще денёк и больше не вспоминать о проблеме или регулярно натыкаться на проблемы, по которым ему уже рапортовали, что они закрыты.
> Соблюдение дедлайнов.
Этот пункт про качественную оценку времени на задачу и контроль. Дедлайн ради дедлайна - тоже такое место, где легко внедряется политика отмены гибкости и здравого смысла. Ну и снова эффект х+х=прод
> Проактивность.
Либо дергающийся глаз менеджера от бегающих вокруг суперсоников, либо текучка кадров, либо и тем и тем по-барабану, поэтому x+x=прод.
Так-то да, стремиться к балансу, обращать внимание на перекосы - да, это всё нужно, рецепты только вряд ли универсальные.
Именно это "треканье" заставило выгореть и уйти со старой работы из QA, когда начальство ввело всё это. Тестишь задачу 3 часа - претензии, что "долго", делаешь побыстрее - вылезает куча багов и начинаются претензии что "плохо протестировано" + накидывают ещё задач. Проработала в таком режиме 1,5 года, после чего свалила в другую компанию на должность сисадмина. Тишина и спокойствие.
Вcё ещё трекаете? Почему контроль часов мешает работе команды (и что с этим делать)