Типичная история тимлида. Съездил на конференцию, узнал новые вдохновляющие идеи и загорелся ими. Начал сходу внедрять то, что (по его мнению) точно сработает, и получил закономерный отпор команды: «Зачем нам вообще что-то менять?»
«Но доклад был классный! Это точно рабочий инструмент!» — думает тимлид. Он начинает поддавливать, иногда уговорами, иногда — другими способами. Команда — «в штыки». Лид получает странный опыт: пришел с благой целью, а получил негатив. Теперь он больше ничего не хочет менять, даже когда это на самом деле нужно. Команда тоже пострадала: после неумелого change-менеджмента она не готова к изменениям вообще. Знакомая история?
И что же, теперь обходить конференции и заразительные идеи стороной? Не внедрять изменения в рабочие процессы команды, пока коллеги сами их не захотят? Совсем нет. Сейчас я ведущий разработчик в облачной платформе Selectel, возглавляю команду Compute. На собственном примере расскажу, как правильно внедрять новые идеи в работу команды и можно ли собрать целый «фреймворк» для улучшений.
Когда я был еще «зеленым» лидом, информации было много, а ее практического применения мало. Приходилось все проверять самостоятельно. Тогда я работал в продуктовой команде, нашими клиентами были госзаказчики.
История про метрики
Как-то я услышал доклад про метрики эффективной команды и понял, что мне не хватает трекинга времени в задачах. Без этих данных мне было сложно делать выводы об эффективности: мы делали много, но тонкий fine-tuning в условиях нашей Jira был невозможен.
Я поделился идеей с более опытными коллегами-лидами, на что они мне задали простой вопрос: «А зачем ты это делаешь, в чем смысл?» Несмотря на боевой запал после конференции, я задумался, все ли я понимаю в том, что буду менять? И осознал, что я как молодой лид хотел внедрить эти метрики, привнести что-то новое, но в действительности не знал, как это сделать.
В поисках ответа я исследовал доклад, понимал, что мне помог бы некий чек-лист, чтобы начать внедрять то, о чем говорил спикер. К сожалению, его я не нашел, поэтому перешел к самостоятельному изучению теории.
Я выяснил, что изменения — это досконально изученный и довольно управляемый процесс. А еще они неизбежны: команда вырастет и изменится, сам проект изменится.
Есть множество книг по теории управления изменениями. Придумано много разных методов, метрик и способов их отобразить — например, ADKAR, теория изменений (модель Левина). Ответом для меня стала формула успешности изменений Бекхарда, которая выражается простым неравенством:
Если левая часть неравенства больше правой, изменения успешно внедряются. Заметьте, что в левой части неравенства показатели перемножаются, а не складываются. Все потому, что если мы не работаем с каким-то элементом, то он превращается в ноль. И тогда, даже если мы хорошо проработали остальные элементы, итоговый эффект будет нулевым.
D — Неудовлетворенность ситуацией
Я начал рефлексировать: а в чем мое недовольство текущей ситуацией? Почему у меня возникло желание что-то изменить, трекать время? Какие вообще есть проблемы в команде?
Это не про то, что «горит» прямо сейчас, а, скорее, про потенциальные риски. Чувствуется, что что-то где-то идет не так и может выстрелить. Главное — не натягивайте сову на глобус, не придумывайте проблему. Даже если вам очень хочется внедрить крутой инструмент.
Важно ответить для себя на простые вопросы:
- Какую проблему решает инструмент, о котором вы узнали?
- Есть ли вообще такая проблема у вас? Есть ли ощущение, что она есть?
- Зачем это лично вам? Что вы приобретаете от того, что в вашей команде появляется новый инструмент или что-то методически новое?
- Зачем это команде? Что она от этого получит? Это не должно быть только ваше решение или вещь, которая полезна только вам.
Если ответы есть, это добавит силы вашему изменению. Определившись с болевыми точками, вы поймете, как воздействовать на показатель D, который говорит о вашем недовольстве ситуацией.
Поделись печалью своей
После рефлексии приходит время разговора с командой. Расскажите, как вы видите проблему, четко, без воды: «Есть наблюдение, мне это не нравится. Что вы сами думаете по этому поводу?»
Выслушайте мнение команды, желательно каждого человека. Вполне возможно, они не видят проблему так же, как вы. Разговор может вылиться в дискуссию, но он даст вам новое видение на ваши опасения, поможет сформулировать, что же на самом деле является проблемой. Здесь мы не только до конца формулируем недовольство ситуацией (D), но и работаем с сопротивлением (R). Уменьшаем его за счет появления точки синхронизации, из которой все одинаково смотрят на проблему.
Как в итоге выглядела ситуация. Я хотел быть увереннее в долгосрочном планировании, но мне не хватало контекста: сколько мы реально что-то делаем. Плюс хотел удачнее закрывать спринты — на тот момент 40-50% от взятых задач не закрывались. Мы брали задачи, но никто не мог сказать, сколько времени уйдет на их решение. Даже попытки оценить сразу отбрасывались.
У команды было желание не таскать задачи из спринта в спринт и не гореть в овертайме. Процесс переноса задач между спринтами или отказ от них сильно демотивировал. Вопросов, почему мы так делаем и как к такой ситуации пришли, при этом не возникало.
В результате мы пришли к одной боли: мы хотели уменьшить страх от неизвестности объемов задач. Это было очень общее понимание проблемы, но оно неплохо у всех отозвалось. Оказалось, мы испытывали боль не от того, что не успеваем. А потому, что не понимали, какой объем займет работа — было бесконечное месиво из задач, которое сложно объять и понять.
Я тогда выскочил на белом коне: «У нас есть непонимание, так давайте трекать время! Это классная идея!» На что получил реакцию: «А зачем?»
Объясняя себе эту реакцию, я понял, что трекинг времени — это абсолютно контринтуитивная вещь, которую непросто привнести в мир IT. В заказной разработке эта история еще плюс-минус понятна, потому что заказчик выставляет бюджет и вы в рамках этого бюджета тратите время на решение поставленных задач. В продуктовой же истории вообще нет прямой связи, как работать с оценками времени.
Я вернулся к теории и понял, что наступил момент, когда мы предлагаем решение, выдвигая гипотезу.
V — Видение будущего
Мы не говорим, что точно знаем секрет успеха. Мы делаем предположение: «Вот это, скорее всего, даст нужный результат и решит нашу проблему. Наверное». Ключевое слово — наверное.
Это очень важный момент — честно сказать об отсутствии 100% уверенности, что идея сработает. Потому что ни вы, ни команда не знаете, получится ли у вас. То же самое делают продакты, когда тестируют гипотезы.
Так звучала моя гипотеза: «Может, попробуем отмечать затраченное время в задачах? Это даст нам статистику, необходимую для будущего планирования».
Так, четко проговаривая, через какие действия мы придем к цели, можно проработать Vision, или видение будущего (V).
Сбор урожая
После выдвижения гипотезы собираем первичный фидбэк и опасения. Это может быть как «Точно не сработает!», так и техническая мантра, которую мы часто себе повторяем: «Работает – не трогай!»
Часто на реакцию влияет негативный опыт, который был в другой компании или в этой же команде. Вспомнятся все вьетнамские флешбэки. Еще мы склонны возводить дурной опыт в абсолют: «Тогда пробовали, и это не сработало. Было так плохо, что повторять не хочется!»
Будет и страх изменений. Нашему мозгу энергозатратно выстраивать новые нейронные связи, создавать другие паттерны для действий, поэтому мы интуитивно избегаем изменений.
Страхи — это то, с чем нужно работать. Поэтому важно выслушивать и фиксировать все опасения. Делайте это максимально прозрачно, четко проговаривайте: «Так, я услышал это опасение и записал его». Это уменьшает сопротивление изменению (R) просто за счет того, что человек чувствует себя услышанным.
Мы с командой выявили три опасения:
- Опасение #1: Но ведь к нам потом придут и скажут, что мы не дорабатываем. Мы же не работаем 8 (16-20-40) часов в день.
- Опасение #2: Мы будем забывать отмечать время, а потом мучительно вспоминать, сколько было затрачено. И вообще, это новая история, непонятно, как и зачем трекать.
- Опасение #3: Слишком много контекстов и переключений. В мире разработки это частая история: мы постоянно переключаемся между этапами задачи и уже не можем понять, где мы делали одну задачу, а где перешли ко второй.
Мне эти опасения тоже откликались. Но на тот момент я прекрасно осознавал, что у меня нет решения, которое бы их снизили. Это самый сложный момент: вам набрасывают охапку опасений и критики, а вы не знаете, что с этим делать. Чисто интуитивно я предложил просто попробовать.
F — Первые конкретные шаги
«Я не знаю, вы не знаете, но давайте попробуем». Ни у команды не было серьезных аргументов против моего решения, ни у меня, чтобы пытаться его продавить. Удивительно, но команда согласилась. Я всего-то заменил «нужно трекать время» на «давайте попробуем трекать время». В чем же тут разница?
Волшебство «Давайте попробуем»
Я снова обратился к теории и выяснил, что «давайте попробуем» воспринимается как «интересно, безопасно и не навсегда». Мы не обязываем людей что-то делать, а проводим эксперимент. Всем интересно, каким будет результат. Некоторых подстегивает возможность доказать лиду, вернувшемуся с конференции, что он ошибается. В любом случае, эта история про новые открытия и выводы.
Здесь мы начинаем делать первые шаги (F). Волшебство работает, потому что мы проработали проблематику, Vision, и у нас еще остался большой запас инерции. Когда вы стоите на месте и вам нужно сдвинуться с него, «Давайте попробуем» отлично работает.
Но, конечно, без плана, что конкретно делать, ничего не выйдет.
Нам нужен план!
Во-первых, очень важно четко описать инициативу и зафиксировать этапы внедрения. В чем цель эксперимента, какие у него сроки? Необходимо установить контрольные точки внутри и определить метрики успеха эксперимента. Опирайтесь на ранее зафиксированные опасения — подтверждаются ли они в ходе эксперимента или нет.
Для синхронизации хорошо подходят ретроспективы. Если у вас SCRUM-like мир или просто SCRUM, который работает на 100%, такие периодические встречи очень удобны. Вам не придется проводить дополнительные мероприятия для обсуждения внедренного изменения. Вы просто «ретроспективите», как в команде изменяются процессы.
Здесь вы работаете на Vision (V), потому что есть конкретный план внедрения изменения. Также мы уделяем время первым шагам (F): мы услышали существующие опасения и рассмотрели их на первом этапе синхронизации. Все это также хорошо для уменьшения сопротивления ®. Люди видят, что все ими сказанное было учтено, что их мнение важно.
В результате у нас с командой получился следующий план:
- Цель: проверяем гипотезу, что трекинг времени даст нам статистику для планирования, то есть мы сможем собирать аналитику и делать выводы.
- Срок: 3 спринта.
- Контрольные точки: ретроспективы каждого спринта.
- Метрики. Количественная: более 80% задач, взятые в спринт, выполняются. Качественная: ощущение страха перед неизвестным уменьшилось. Страх практически невозможно измерить объективно, но можно оценить по ощущениям.
Мне бы хотелось написать, что после старта все было весело и прекрасно, но это не так. Все трудности вскрылись на первом же этапе. На первой ретроспективе я получил фидбек, что «все ломается, рушится и ничего не работает». Из трех опасений не сработало только первое, про недоработку часов. Два других проявили себя во всей красе: половина команды забывала трекать время, а множество переключений лишь ухудшали ситуацию.
R — Сопротивление изменениям
Проблемы точно будут. Это единственное, в чем можно быть уверенным на 100%. Важно не останавливаться. В какой-то момент у нас была сложная дилемма. Опасения сбывались, появились первые предложения забросить эксперимент. Здесь важно поддержать первоначальную идею: «Мы же хотим проверить нашу гипотезу. Мы столкнулись с проблемами, которые подтвердили некоторые опасения. Но давайте попробуем что-то с этим сделать».
Это «Давайте попробуем» будет с вами на протяжении всего пути внедрения изменений. Результаты можно получить, только реально пытаясь что-то сделать.
- Важно друг друга поддерживать. У некоторых ребят получалось трекать время, и они делились своим опытом. Их пример помогал разрушать опасения коллег — все поддерживали и были готовы услышать друг друга.
- Мы не изобретали сложных инструментов. Попробовали Toggle — удобно, можно быстро переключаться между задачами. Немного помогла техника Pomodoro. Она была очень просто реализована, чтобы мы могли подходить к задачам итерационно.
- Очень важно не пропускать контрольные точки, чтобы не упустить момент, когда что-то пошло не так. Не скипайте ретроспективы, иначе у вас накопится такой ворох нерешенных вопросов, что вы его не сможете разгрести и сдадитесь.
- Ведите процесс прозрачно. Это не должно быть исследование, которое вы ведете в секретных дневниках, как тайный гуру. Все договоренности и зафиксированные опасения должны быть максимально публичными.
- Будьте честны с командой и с самим собой. Важно озвучить, что вы сами не знаете, что получится в итоге. Повторяйте, что эксперимент безопасный, потому что он конечный и короткий по времени. Мы просто проверяем, получится или нет, и сделаем какие-то выводы по итогу.
Такая работа над снижением сопротивления (R) должна быть на всех этапах эксперимента. Важно, чтобы команда вам доверяла. Вы как лид этот процесс фасилитируете, но не ведете людей за ручку к целям, которые интересны только вам. Потому что проект — не лида, а команды. Вы делаете что-то вместе и меняете команду к лучшему. Дополнительные бенефиты достигаются за счет того, что вы сплачиваете команду не вокруг рабочих процессов (выполнения задач и реализации продукта), а вокруг идеи «самонастройки».
После эксперимента
В конце мы проверяем, сработало или нет. Для этого замеряем целевые метрики, которые можно собирать как в процессе, так и в конце эксперимента. Если сработало, забираем в работу.
Если не сработало, то рефлексируем почему. Здесь может возникнуть соблазн продавить изменение: «Мы уже какое-то количество времени с этой штукой поработали. Чуть-чуть не зашло, но мы же ее уже взяли, она у нас идет!» Боритесь с ним. Запишите результат и отложите изменение. Мы четко даем понять команде, что следуем договоренностям.
Так мы работаем и с сопротивлением (D), и с недовольством текущей ситуацией (R): проблема осталась, но конкретно это решение для нас не сработало.
Заключение
Конкретно эта история завершилась успешно, но опыт был разный. Что у нас получилось:
- Не рассыпались по пути. Опасения, которые мы поймали на первой ретроспективе, удалось достаточно быстро решить. Команда делилась инструментами, совместно мы научились трекать время удобным всем способом.
- Мы подошли к метрике в 70% закрытых задач за спринт. Но это не главное.
- Главное — уменьшился страх перед неизвестным объемом работы. Ребята на планировании стали четко говорить: «Так, я понимаю, что, делая такие же задачи, я затратил гораздо больше времени. Наверное, в следующий спринт я не буду брать столько задач. Лучше сделаю то, что поможет успешней закрыть спринт, и буду меньше волноваться из-за сроков».
- Появился запрос от команды: научиться декомпозировать задачи. В процессе эксперимента у команды появились вопросы, как абстрактные задачи разбивать на шаги.
- Появилась необходимая аналитика для последующих внедрений. Наработки по трекингу времени мы потом смогли использовать (и использовали) для понимания, где именно мы застревали. Без этих цифр мы бы не понимали, что происходит.
Чем усилить процесс внедрения изменений
Мощное сопротивление — больше пруфов. Если вы встречаете мощное сопротивление, не давите, а приводите больше фактов в качестве доказательств.
Напарники — для сложных изменений. Если у вас суперсложное внедрение, например, изменения, которые нужно провести в нескольких командах, то ищите себе напарников. Это не значит, что вы засылаете в команду казачков, чтобы они говорили, как вы классно все придумали. Напарники нужны, чтобы эксперимент шел одинаково для всех команд.
Fail — это на самом деле win. У вас была идея, которую вы хотели применить. Вы ее проверили и получили результат — теперь у вас больше информации, чем до эксперимента.
И самое главное: изменения в любом случае происходят. Вопрос в том, будете ли вы им просто отдаваться или же управлять этим процессом. Пробуйте, экспериментируйте, не стесняйтесь что-то менять. Это интересно!
Видео моего выступления по этой теме на конференции TeamLead Conf 2021 можно посмотреть здесь.
Конференция TeamLead Conf 2022 пройдет 21 и 22 марта совместно с KnowledgeConf. Доклады по Knowledge будут отдельным треком. Билеты продаются здесь. А если вы хотите выступить как спикер, то подать заявку на выступление можно здесь.
Комментарии (34)
Sergey-Titkov
10.11.2021 21:30+9Цель: проверяем гипотезу, что трекинг времени даст нам статистику для планирования, то есть мы сможем собирать аналитику и делать выводы.
А можно было просто вычесть из даты завершения, дату начала и получить данные для статистики
0x656b694d
10.11.2021 23:14для этого надо сперва научиться задачи разбивать до степени возможности адекватной оценки в попугаях, чтобы считать попугай/месяцы для статистики и планирования, а про это автор сразу сказал, что не получается у них.
Sergey-Titkov
11.11.2021 09:41+8Нет не надо...
Автор:Так звучала моя гипотеза: «Может, попробуем отмечать затраченное время в задачах? Это даст нам статистику, необходимую для будущего планирования».
Что имеем, как не умели декомпозировать, так и не умеем, но теперь еще и время начали записывать.
Просто по текущим задачам пройтись и посмотреть, простое действие, вычитание, потом в эксельке посмотреть.
Кстати добавлю, в общем случае между тем сколько списали и когда будет сделано, связи то нет.
iiwabor
10.11.2021 22:52+14Команда сопротивляется изменениям, если люди подозревают, что эти самые изменения, в будущем, могут негативно повлиять на их ЗП, премию или существенно добавить работы за те же деньги.
Если изменения для команды только в плюс, то все будут обеими руками за, но я за 25 лет своей карьеры таких изменений встречал настолько мало, что по пальцам можно пересчитать, может быть даже одной руки(((.
Cherrr
11.11.2021 09:54+9Нифига. Люди привыкли работать как привыкли, и очень неохотно даже что-то хорошее внедряют.
Git - зачем, у нас и так нормально все и понятно! А ветвеления в нем это же надо понимать, давайте все просто будет коммитить в мастер!
CI/CD - мы же хорошо архив руками копировали, ну нужон нам ваш CI/CD, еще и разрабатывать его сложно и технологии новые изучать!
И далее по списку.
iiwabor
11.11.2021 10:21+3Хорошее - для кого? Если для людей - то все за! А если против - то они сопротивляются почему-то(((
Когда у нас решили поставить бесплатную кофемашину, все были только рады и никто не сопротивлялся.
А вот когда стали внедрять СРМ с жесткими привязками KPI к количеству холодных звонков и поездок к клиентам ( зачастую абсолютно бесполезных и бессмысленных), оформлением бесконечных отчетов, которые потом никто не читает, и тд и тп - причем все это не только для продажников. но и для инженеров(!). Как результат внедрения - резко упала премия - и квартальная и годовая и также резко вырос объем бюрократической работы и геморроя в целом. Сотрудники сопротивлялись этому изо всех сил, саботаж был жесткий, и прямой и косвенный, ежедневные совещания с начальством - сначала с уговорами потом с угрозами, потом пошли увольнения - ничего не меняли в ситуации.
В какой-то момент генеральный не выдержал и назвал нас неблагодарными лентяями - ведь нам же потом лучше и удобнее будет работать с СРМ! Самое забавное, что он и вправду так считал)))
vrnvorona
12.11.2021 12:28Потому что кофемашину не им ставить нужно, плюс ей не сложно пользоваться. Максимальный профит за минимум потерь.
А второе это проблема начальства которое либо не разбирается и "просто руководит" либо просто отказывается слушать фидбек.
nktkz
10.11.2021 23:34+22тим лиды такие тимлиды
вместо того чтобы аргументировать перед командой зачем нужный те или иные изменения и адекватно защищать свою позицию, прибегают к каким то то хитростям, то манипуляциям, то давленияим
Vorchun
11.11.2021 10:22+1Очень разная реакция и разный подход к тем, кому (условно) 30 и тем кому недавно было 20. Не припомню, чтобы в "наше время" (простите за ворчание) мы искали наставника и уходили, потому что "не даете расти". Я не критикую, но мне сложно (пока) принять, что надо нянчится как с детьми малыми.
AlexunKo
11.11.2021 20:18Противоречиво. Защита предполагает нападение, уже. Да и хитрости - это и есть защита, просто непрямая.
Daddy_Cool
13.11.2021 12:44У тим-лидов мышление более стратегическое, а у разработчика — тактическое. На разных горизонтах планирования цели разные.
RieSet
11.11.2021 07:24+10Что люди делают с удовольствием - это закрывают задачи.
Что сложного считать когда какая задача была закрыта? И эстимейтить их?
За десяток лет в отрасли, лично для меня очевидно, что кто-то вместо грамотной декомпозиции и эстимейтов перекладывает работу на разрабов требуя в конце дня еще и время отмечать и следить сколько раз их отрывали от работы с разными вопросами и пожарами.
Разработчик эмоционально переходит в режим оправдания за потраченное время, хотя довольно честно использует все свои ресурсы на работу и старается.
Отмечание времени - это эмоционально сложный процесс. Требующий подведение итога в конце сложного дня. Итог в котором ты должен оценить себя, но так чтобы не показаться плохим разработчиком, но не уменьшить затраченное время и грамотно для "девочек" описать почему потратил несколько часов на баг созданный случайно и решеный одной строкой и которого естественно не было в эстимейте.
Не люблю когда менеджмент начинает попытки ведения статистики не со своего обучения декомпозиции, а с гипотез о том что отмечание времени другими сделает за него его работу
Много раз пробовал сам на своей команде, если нужно тщательно отслеживать прогресс - декомпозиция работает великолепно нужно не бояться даже сотен мелких задач. А все истории с отмечанием времени заканчиваются в тот момент когда на статистику забивают а разраам не показывают реального профита от возложенной на них работы
RieSet
11.11.2021 07:42+8Чтобы быть объективными
Дорогие менеджеры и тимлиды заставляющие отмечать время, покажите как выглядит ваша итоговая статистика за пол года и какие выводы она позволяет делать?
Она точно стоит 150 часов рабочего времени дорогостоящих разработчиков и дизайнеров за пол года?
15 минут * 5 участников команды * 20 дней в месяц * 6 месяцев? А это между прочим где-то от 150 000 до полумиллиона за пол года? Такая статистика точно окупается? Нельзя ли как-то автоматизировать сбор данных после выполненных задач и экономить до миллиона в год на квалифицированной команде из 5 человек?
InvisibleHand
11.11.2021 10:47А каким иным способом оценить стоимость договора на этапе пресейла и понять вышел ли он в плюс после закрытия, если только не мерять в трудоднях*ставка на всех этапах? Скрам говорит - меряйте трудоемкость в попугаях. Как перевести попугаи в деньги? Всегда был интересен этот момент...
RieSet
11.11.2021 11:47Человеческий фактор в оценке своего времени потраченного на задачу точно не лучший показатель для таких расчетов
У вас всегда есть фактическое прошедшее время и реализованый за это время функционал. Чем лучше декомпозированы задачи на старте тем точнее эcтимейт. Где-то время завышено, где-то занижено, но если при декомпозиции подумали о всех мелочах даже на 10 - 15 минут, то в среднем эстимейт при достаточном опыте будет выполняться
Если на старте у вас задачи хорошо декомпозированы. Вынести задачи на таймлайн, то всегда отлично видно как движется разработка и успеваете ли в общие обозначенные рамки рентабельности
InvisibleHand
11.11.2021 12:09Это может работать, если человек fulltime на одном типовом проекте. Если на 2-3 проектах сразу, возникают сложности. Никоим образом не утверждаю, что биллить часы на задачу - правильный подход. Но дьявол как всегда в деталях по ходу пьесы: декомпозировали недостаточно, постановка поменялась, замена задачи, проект не типовой и т. д..
RieSet
11.11.2021 12:45В такой ситуации ничто не поможет :)
Если вести задачи, то совокупные данные по ним могут закрыть потребности в аналитике рентабельности. Оговорка, если вести ихОбычно
Вам нужно измерить рентабельность проекта а не время выполнения каждой задачи, и тут простое суммирование времени выполненных задач к выделенному времени разработчиком. Ведь новые выполненные задачи ровно также влияют на это соотношение, если нет, то кто-то поленился оформить изменения в виде задач. А фильтрация по дате создания - данные для графика внесенных изменений в процессе разработки
Разработчики не роботы, задача сделанная за X весной, не будет сделана за X зимой. Разный эмоциональный фон, разный контекст, разные параллельные проекты. Оценка выполнения конкретной задачи не имеет ценности с точки зрения бизнеса
Изменилось все, поменяйте все невыполненное
Изменилась задача поменяйте эстимейт ее
Изменились приоритеты, будут сделаны сначала другие задачи, а прежние скорее всего останутся но будут отодвинуты
Выполненное - факт созданной работы в рамках выделенного на это времени разработчика. Не важно сколько именно заняла каждая. Важно укладывается ли это в общий таймлайн или надо приоритеты менять.
И есть еще не выполненное, которое тоже хорошо суммируется и показывает будущее с незавершенным проектом в оговоренные с заказчиком сроки :)
Vladivo
11.11.2021 18:34Недавно перешел из агенства в продукт и меня, честно говоря, немного раздражает, что мы не собираем статистику по затраченому времени. Все хорошие специалисты, все хотять быть максимально продуктивными с максимальной пользой для общего дела, но никто даже не представляет себе, сколько времени уходит в никуда. Ах да, декомпозиции нормальной нет и, разумеется, "у нас тут свой, особенный скрам". Лично я считаю, что для толковой оптимизации процессов объективные метрики, гипотезы и анализ абсолютно необходимы. Нужно только отдельно и ясно коммуницировать, что неудовлетворительные на данный момент результаты не выльются в негативные последствия для конкретных сотрудников. Иными словами, действительно следовать аджайловым ценностям, а не только декларировать их. В любом случае окажется, что кому-то надо подучиться программировать, а кому-то другому - общаться.
iiwabor
11.11.2021 10:39+5Я работал инженером-конструктором и у нас начальство придумало гениальное новшество - ввело KPI для инженеров и стало оценивать работу (и начислять премию) по количеству чертежей, начерченных за день.
Все инженеры сначала возмущались, ругались, жаловались вышестоящему начальству (бесполезно) и тд, а я не противился нововведениям - просто стал разбивать чертеж А1 на форматки А4. Потом также стали делать и остальные - вместо одного чертежа получалось 8 и наш KPI взлетел до небес. Но 8-микратную премию мы, почему-то, не получили((( Странно, правда?
Кончилась эта история тем, что пришел
лесникначальник цеха и натянул наше начальство на глобус за то, что количество документации увеличилось в разы, а ее читабельность в разы ухудшилась. KPI отменили, а жаль - хорошая была идея!)
derwin
11.11.2021 11:48+4работал на 3й линии тех поддержки в телекоме, отдел строительства и эксплуатации сети. Был KPI по количеству "решеных заявок". Не хватает тебе заявок для премии? не беда! Случайно выключи апстрим порт на весь микрорайон на 5 минут! Историю дальше не расскажу, потому что я уволился.
mad_nazgul
11.11.2021 15:45Время очень странный предмет. Вроде бы есть, но его как бы нет.
Сколько реально времени тратиться на задачу, зависит от кучи факторов.
И точно посчитать очень сложно.
Например я видел, что человек, который мог решить задачу 2 часа, делал её 8. Просто потому что не отдыхал нормально. Т.е. точно такую же задачу до этого он решил за 2 часа. А после двух недель дедлайна, точно такую же задачу решал 8 часов.
Т.е. как с таким разбросом в 6 часов можно планировать время. :-)
Alente1
11.11.2021 18:59Согласны с автором, изменения – это всегда болезненный процесс, но необходимый.
Но на наш взгляд, любые изменения должны внедряться тогда, когда есть какая-то проблема, или даже не проблема, а отклонение от идеальной картины. И когда находим проблему важно понять почему она возникла.
Например, у вас в идеальной картине вы всегда понимаете, какой объем займет та или иная задача, благодаря чему можете планировать загрузку. Но по факту все не так. Можно задать вопрос "почему?" и тогда появляются разные причины: может вы не трекаете время, а может быть просто задач слишком много или еще что-то. Важно дальше тоже задать вопрос: "а почему?". А почему мы не трекаем время? Может просто мы не планируем свое рабочее время? Тогда может стоит работать именно над навыком планирования. Думаем логика понятна) В общем, если с самого начала докапываться до сути проблемы, можно избежать множества неудачных гипотез при поиске ее решений.
Лично у нас такой опыт сработал.
Cherrr
Читая это, в очередной раз понимаю, как много вопросов снимает канонический скрам.
ki5e1d
вопросы то снимает, но не решает многих проблем
Cherrr
Идеальных подходов не существует.
Dmitry3A
Слова не мальчика — а скрам мастера!
Cherrr
Вообще, я разработчик, но, благодаря работе в бодишопе, насмотрелась на разное. Вся описанная здесь история изи без боли имплементируется хорошим скрам-мастером.
Проблема скарама в том, что его мало кто видел в нормальном виде. В основном везде франкенштейны под названием "Мы сохранили все, что у нас было своего в организации, и ввели три пункта из скрам гайда и теперь у нас АДЖАЙЛ!"