Комментарии 34
Читая это, в очередной раз понимаю, как много вопросов снимает канонический скрам.
вопросы то снимает, но не решает многих проблем
Вообще, я разработчик, но, благодаря работе в бодишопе, насмотрелась на разное. Вся описанная здесь история изи без боли имплементируется хорошим скрам-мастером.
Проблема скарама в том, что его мало кто видел в нормальном виде. В основном везде франкенштейны под названием "Мы сохранили все, что у нас было своего в организации, и ввели три пункта из скрам гайда и теперь у нас АДЖАЙЛ!"
Цель: проверяем гипотезу, что трекинг времени даст нам статистику для планирования, то есть мы сможем собирать аналитику и делать выводы.
А можно было просто вычесть из даты завершения, дату начала и получить данные для статистики
Карго культ же
для этого надо сперва научиться задачи разбивать до степени возможности адекватной оценки в попугаях, чтобы считать попугай/месяцы для статистики и планирования, а про это автор сразу сказал, что не получается у них.
Нет не надо...
Автор:
Так звучала моя гипотеза: «Может, попробуем отмечать затраченное время в задачах? Это даст нам статистику, необходимую для будущего планирования».
Что имеем, как не умели декомпозировать, так и не умеем, но теперь еще и время начали записывать.
Просто по текущим задачам пройтись и посмотреть, простое действие, вычитание, потом в эксельке посмотреть.
Кстати добавлю, в общем случае между тем сколько списали и когда будет сделано, связи то нет.
Команда сопротивляется изменениям, если люди подозревают, что эти самые изменения, в будущем, могут негативно повлиять на их ЗП, премию или существенно добавить работы за те же деньги.
Если изменения для команды только в плюс, то все будут обеими руками за, но я за 25 лет своей карьеры таких изменений встречал настолько мало, что по пальцам можно пересчитать, может быть даже одной руки(((.
Нифига. Люди привыкли работать как привыкли, и очень неохотно даже что-то хорошее внедряют.
Git - зачем, у нас и так нормально все и понятно! А ветвеления в нем это же надо понимать, давайте все просто будет коммитить в мастер!
CI/CD - мы же хорошо архив руками копировали, ну нужон нам ваш CI/CD, еще и разрабатывать его сложно и технологии новые изучать!
И далее по списку.
Хорошее - для кого? Если для людей - то все за! А если против - то они сопротивляются почему-то(((
Когда у нас решили поставить бесплатную кофемашину, все были только рады и никто не сопротивлялся.
А вот когда стали внедрять СРМ с жесткими привязками KPI к количеству холодных звонков и поездок к клиентам ( зачастую абсолютно бесполезных и бессмысленных), оформлением бесконечных отчетов, которые потом никто не читает, и тд и тп - причем все это не только для продажников. но и для инженеров(!). Как результат внедрения - резко упала премия - и квартальная и годовая и также резко вырос объем бюрократической работы и геморроя в целом. Сотрудники сопротивлялись этому изо всех сил, саботаж был жесткий, и прямой и косвенный, ежедневные совещания с начальством - сначала с уговорами потом с угрозами, потом пошли увольнения - ничего не меняли в ситуации.
В какой-то момент генеральный не выдержал и назвал нас неблагодарными лентяями - ведь нам же потом лучше и удобнее будет работать с СРМ! Самое забавное, что он и вправду так считал)))
тим лиды такие тимлиды
вместо того чтобы аргументировать перед командой зачем нужный те или иные изменения и адекватно защищать свою позицию, прибегают к каким то то хитростям, то манипуляциям, то давленияим
Ну, с одной стороны, теперь вы хотябы понимаете, что ненужные изменения существуют и каким способом внедряются. С другой стороны, что вам мешает внедрять такиеже не шибко полезные изменения? Почему другим можно, а вам нельзя? Попробуйте
Очень разная реакция и разный подход к тем, кому (условно) 30 и тем кому недавно было 20. Не припомню, чтобы в "наше время" (простите за ворчание) мы искали наставника и уходили, потому что "не даете расти". Я не критикую, но мне сложно (пока) принять, что надо нянчится как с детьми малыми.
Противоречиво. Защита предполагает нападение, уже. Да и хитрости - это и есть защита, просто непрямая.
Что люди делают с удовольствием - это закрывают задачи.
Что сложного считать когда какая задача была закрыта? И эстимейтить их?
За десяток лет в отрасли, лично для меня очевидно, что кто-то вместо грамотной декомпозиции и эстимейтов перекладывает работу на разрабов требуя в конце дня еще и время отмечать и следить сколько раз их отрывали от работы с разными вопросами и пожарами.
Разработчик эмоционально переходит в режим оправдания за потраченное время, хотя довольно честно использует все свои ресурсы на работу и старается.
Отмечание времени - это эмоционально сложный процесс. Требующий подведение итога в конце сложного дня. Итог в котором ты должен оценить себя, но так чтобы не показаться плохим разработчиком, но не уменьшить затраченное время и грамотно для "девочек" описать почему потратил несколько часов на баг созданный случайно и решеный одной строкой и которого естественно не было в эстимейте.
Не люблю когда менеджмент начинает попытки ведения статистики не со своего обучения декомпозиции, а с гипотез о том что отмечание времени другими сделает за него его работу
Много раз пробовал сам на своей команде, если нужно тщательно отслеживать прогресс - декомпозиция работает великолепно нужно не бояться даже сотен мелких задач. А все истории с отмечанием времени заканчиваются в тот момент когда на статистику забивают а разраам не показывают реального профита от возложенной на них работы
Чтобы быть объективными
Дорогие менеджеры и тимлиды заставляющие отмечать время, покажите как выглядит ваша итоговая статистика за пол года и какие выводы она позволяет делать?
Она точно стоит 150 часов рабочего времени дорогостоящих разработчиков и дизайнеров за пол года?
15 минут * 5 участников команды * 20 дней в месяц * 6 месяцев? А это между прочим где-то от 150 000 до полумиллиона за пол года? Такая статистика точно окупается? Нельзя ли как-то автоматизировать сбор данных после выполненных задач и экономить до миллиона в год на квалифицированной команде из 5 человек?
А каким иным способом оценить стоимость договора на этапе пресейла и понять вышел ли он в плюс после закрытия, если только не мерять в трудоднях*ставка на всех этапах? Скрам говорит - меряйте трудоемкость в попугаях. Как перевести попугаи в деньги? Всегда был интересен этот момент...
Человеческий фактор в оценке своего времени потраченного на задачу точно не лучший показатель для таких расчетов
У вас всегда есть фактическое прошедшее время и реализованый за это время функционал. Чем лучше декомпозированы задачи на старте тем точнее эcтимейт. Где-то время завышено, где-то занижено, но если при декомпозиции подумали о всех мелочах даже на 10 - 15 минут, то в среднем эстимейт при достаточном опыте будет выполняться
Если на старте у вас задачи хорошо декомпозированы. Вынести задачи на таймлайн, то всегда отлично видно как движется разработка и успеваете ли в общие обозначенные рамки рентабельности
Это может работать, если человек fulltime на одном типовом проекте. Если на 2-3 проектах сразу, возникают сложности. Никоим образом не утверждаю, что биллить часы на задачу - правильный подход. Но дьявол как всегда в деталях по ходу пьесы: декомпозировали недостаточно, постановка поменялась, замена задачи, проект не типовой и т. д..
В такой ситуации ничто не поможет :)
Если вести задачи, то совокупные данные по ним могут закрыть потребности в аналитике рентабельности. Оговорка, если вести их
Обычно
Вам нужно измерить рентабельность проекта а не время выполнения каждой задачи, и тут простое суммирование времени выполненных задач к выделенному времени разработчиком. Ведь новые выполненные задачи ровно также влияют на это соотношение, если нет, то кто-то поленился оформить изменения в виде задач. А фильтрация по дате создания - данные для графика внесенных изменений в процессе разработки
Разработчики не роботы, задача сделанная за X весной, не будет сделана за X зимой. Разный эмоциональный фон, разный контекст, разные параллельные проекты. Оценка выполнения конкретной задачи не имеет ценности с точки зрения бизнеса
Изменилось все, поменяйте все невыполненное
Изменилась задача поменяйте эстимейт ее
Изменились приоритеты, будут сделаны сначала другие задачи, а прежние скорее всего останутся но будут отодвинуты
Выполненное - факт созданной работы в рамках выделенного на это времени разработчика. Не важно сколько именно заняла каждая. Важно укладывается ли это в общий таймлайн или надо приоритеты менять.
И есть еще не выполненное, которое тоже хорошо суммируется и показывает будущее с незавершенным проектом в оговоренные с заказчиком сроки :)
Недавно перешел из агенства в продукт и меня, честно говоря, немного раздражает, что мы не собираем статистику по затраченому времени. Все хорошие специалисты, все хотять быть максимально продуктивными с максимальной пользой для общего дела, но никто даже не представляет себе, сколько времени уходит в никуда. Ах да, декомпозиции нормальной нет и, разумеется, "у нас тут свой, особенный скрам". Лично я считаю, что для толковой оптимизации процессов объективные метрики, гипотезы и анализ абсолютно необходимы. Нужно только отдельно и ясно коммуницировать, что неудовлетворительные на данный момент результаты не выльются в негативные последствия для конкретных сотрудников. Иными словами, действительно следовать аджайловым ценностям, а не только декларировать их. В любом случае окажется, что кому-то надо подучиться программировать, а кому-то другому - общаться.
А в чем оцениваются задачи на следующий спринт? В часах?
Я работал инженером-конструктором и у нас начальство придумало гениальное новшество - ввело KPI для инженеров и стало оценивать работу (и начислять премию) по количеству чертежей, начерченных за день.
Все инженеры сначала возмущались, ругались, жаловались вышестоящему начальству (бесполезно) и тд, а я не противился нововведениям - просто стал разбивать чертеж А1 на форматки А4. Потом также стали делать и остальные - вместо одного чертежа получалось 8 и наш KPI взлетел до небес. Но 8-микратную премию мы, почему-то, не получили((( Странно, правда?
Кончилась эта история тем, что пришел лесник начальник цеха и натянул наше начальство на глобус за то, что количество документации увеличилось в разы, а ее читабельность в разы ухудшилась. KPI отменили, а жаль - хорошая была идея!)
Добавлю, что в Википедии эта формула также называется Формулой Глейчера
Время очень странный предмет. Вроде бы есть, но его как бы нет.
Сколько реально времени тратиться на задачу, зависит от кучи факторов.
И точно посчитать очень сложно.
Например я видел, что человек, который мог решить задачу 2 часа, делал её 8. Просто потому что не отдыхал нормально. Т.е. точно такую же задачу до этого он решил за 2 часа. А после двух недель дедлайна, точно такую же задачу решал 8 часов.
Т.е. как с таким разбросом в 6 часов можно планировать время. :-)
Согласны с автором, изменения – это всегда болезненный процесс, но необходимый.
Но на наш взгляд, любые изменения должны внедряться тогда, когда есть какая-то проблема, или даже не проблема, а отклонение от идеальной картины. И когда находим проблему важно понять почему она возникла.
Например, у вас в идеальной картине вы всегда понимаете, какой объем займет та или иная задача, благодаря чему можете планировать загрузку. Но по факту все не так. Можно задать вопрос "почему?" и тогда появляются разные причины: может вы не трекаете время, а может быть просто задач слишком много или еще что-то. Важно дальше тоже задать вопрос: "а почему?". А почему мы не трекаем время? Может просто мы не планируем свое рабочее время? Тогда может стоит работать именно над навыком планирования. Думаем логика понятна) В общем, если с самого начала докапываться до сути проблемы, можно избежать множества неудачных гипотез при поиске ее решений.
Лично у нас такой опыт сработал.
Как правильно внедрять изменения, которые никто не хочет