Слово «ретроспектива» произошло от латинского “retro” – «обратно, назад» и “spectare” – «смотреть, созерцать», то есть буквально оно означает «Взгляд в прошлое».
Ретроспектива в командах разработки не новое явление. После нее в идеальном мире следующие этапы работы точно будут лучше! Правда, правда.
Всем привет, меня зовут Саша Комбаров, я исполнительный директор в веб-студии. В материале расскажу, что такое ретро, зачем и как проводить ретроспективу и как мы проводим собрания по методу «Четырех Ч». А также расскажу, как мы внедрили ретро в отделы компании: управление, дизайн, маркетинг, продажи, тестирование и аналитика. И что это дало :)
Что такое ретроспектива простыми словами?
Ретроспектива — это периодические встречи, в ходе которых команда анализирует и оценивает рабочий процесс, самих себя и составить план улучшений на будущее. Ретроспектива поддерживает идею постоянного совершенствования и защищает от ловушек самонадеянности, заставляя выходить за рамки рабочего цикла, чтобы поразмыслить о прошлом.
Цель ретроспективны заключается в следующем:
Оценить, как прошел последний спринт, итерация или иная рабочая единица (это особенно важно в контексте динамики, процессов и инструментов команды);
Сформулировать удачные и неудачные моменты и определить их приоритет;
Составить и осуществить план по улучшению работы команды.
Ретроспектива – это не место для порки, а своеобразный разбор, где участники имеют равные права. Например, разработчик может сказать, что ему не понравилось в менеджменте, менеджер – какие были проблемы с тестированием. И затем на эти проблемы команда предлагает решения.
Конечно, для успешного проведения ретроспективы необходима атмосфера поддержки, которая поощряет вклад всех участников команды, но не принуждает вносить предложения. За атмосферу и направление команды отвечает менеджер, если у него будет боевой задор – команда будет способна на подвиги даже после неудач, если тухлость и унылость – не ждите драйва от сотрудников.
Ретроспектива должна давать вашей команде положительный опыт и заряжать ее энергией. Она помогает участникам команды делиться важными отзывами, смиряться с разочарованиями и сообща находить решения.
Бывает, что зреет невидимый конфликт в команде, его должен сковырнуть менеджер на ретро, чтобы все вопросы и обиды были разобраны совместно с командой.
Организаторы тоже могут многое узнать для себя, в том числе лучше понять, как работает команда и какие трудности и успехи она пережила на последнем. Результатом успешной ретроспективы становится список улучшений, за которые участники команды берут ответственность и к которым стремятся в следующем спринте.
Ретроспектива по методу четырех «Ч»
Четыре «Ч» — это метод проведения ретроспективы, где участники команды определяют:
Что им понравилось;
Что не понравилось
Чему они научились;
Что изменим в процессах.
Важно донести до каждого участника ретроспективы перед собранием, что:
Мы обсуждаем, как работали, чтобы понять, какие улучшения можем внести;
Мы приходим на это собрание, понимая, что каждый прилагал все старания, используя имеющиеся знания и инструменты;
Это собрание — безопасное место. То, чем вы поделитесь, не будет использовано против кого бы то ни было;
Мы собрались, чтобы анализировать, а не обвинять.
Во время ретроспективы предложите команде вспомнить пройденный этап. Какие ключевые события в то время произошли, над чем необходимо поработать? Приведите несколько примеров самостоятельно, чтобы задать тон и показать открытость мероприятия.
По завершению наметьте план внедрения изменений, зафиксируйте его письменно и затем проверяйте, что команда его соблюдает.
Как проводим ретро по отделам компании
Мы в веб-студии решили ретроспективу проводить по отделам. С некоторыми изменениями. Проводим ретро с менеджерами, аккаунтами, разработчиками, маркетингом, дизайнерами, аналитиками и тестировщиками.
Для чего это нужно? Цель ретроспективы – повысить эффективность процессов в работе, сформировать план изменений. Но важно понимать, что это не план окончательных изменений в процессе — это план эксперимента на ближайший период. Мы что-то пробуем, смотрим, что из этого вышло, и на основании этого принимаем решение.
До ретро:
1. Ставим задачу в календарь тем, кому необходимо присутствовать на ретро;
2. Ставим задачу минимум за день на подготовку к ретро. Но лучше выписывать заметки в ретро регулярно;
3. Напоминаем за неделю до ретро о дате его проведения;
4. Готовимся к ретро самостоятельно, выписываем пункты, которые необходимо обсудить.
На ретро:
1. Разбираем статус по задачам прошлого ретро. Что сделано, что не сделано, актуальны ли сейчас эти задачи. Если задача не была выполнена к конкретному сроку, то выясняем причины и обговариваем дальнейшие действия.
2. Предоставляем каждому участнику слово. Какие были плюсы, что не понравилось, какие предложения. Фиксируем это.
3. Зафиксированные итоги зачитываем в конце ретро, назначаем ответственных по задачам и направляем информацию в чат. Также выписываем в доску задач в отдельную карточку.
4. Через день проверяем, что по всем обозначенным задачам стоят задачи в трекере.
Таким образом, участвуя в ретро, сотрудники могут проявлять инициативу и внедрять изменения в процессы компании. А работа студии благодаря этому становится более продуктивной.
Прикрепляю красивый чек-лист для проведения ретро по отделам, внедряйте у себя и делитесь результатами :)
Комментарии (32)
Pitkin_zadov
26.08.2023 15:49+4Есть альтернативное мнение : это просто потеря рабочего времени никому ничего полезного неприносящая, напоминающая детский сад или клуб анонимных алкоголиков. Все сидят, поддакивают ведущему и пытаются вытащить из себя ответы на те 4 вопроса :)
sashadzen Автор
26.08.2023 15:49Есть такое мнение, да. Многое зависит от процессов и от того, как проходит сама организация.
Если команда не видит изменений и улучшений, то будут поддакивать и давить из себя хоть что-то :)
g000phy
26.08.2023 15:49+1Так не надо поддакивать и проводить ретро ради проведения. Пришли за 2 минуты сказали что все хорошо и пошли работать дальше. NB У меня так ни разу не было, но в целом я не против и такого формата.
Лучше уметь возможность обсудить и решить проблему и не иметь таких проблем. Обратная ситуация куда хуже.
Это как огнетушитель или аптечка. Их покупают, надеясь никогда не воспользоваться. Вот только если припрет эти предметы ничто не заменит.
У автора, мне кажется, желтый раздел излишний. Но если ответ "ничему, все равно" приемлем, то ок.
sashadzen Автор
26.08.2023 15:49Да, можно не отвечать на желтой вопрос, но кто-то что-нибудь да отметит :)
saboteur_kiev
26.08.2023 15:49+3Во время ретроспективы предложите команде вспомнить пройденный этап. Какие ключевые события в то время произошли, над чем необходимо поработать? Приведите несколько примеров самостоятельно, чтобы задать тон и показать открытость мероприятия.
Это главный минус, который я увидел в вашей идее.
Ретро митинг должен быть
1. доступен для всех желающих, но практически обязателен для тимлидов/техлидов/менеджмента/архитектора
2. Приходить на него нужно подготовленным. То есть уже с конкретными проблемами, в идеале заранее добавленными в нужный документ/таблицу с полями "название, описание, приоритет, и другие которые в вашем процессе используются".
3. Проводиться ретро должен не каждый спринт, а выбрать оптимальные промежутки. Причем можно через 2-3 ретро посмотреть как оно идет и снова поменять.
Тогда это будет не болтай-шатай, а просмотр предыдущих проблем, выработка решения что с ними делать. Если решение было выработано - обсуждение насколько оно удачно решает проблему. Если не решает - придумать/обсудить новое или закрыть эту тему, пока никто не предложит что-то, что работает лучше, чем сейчас.
Ну и рассмотрение новых проблем и решение, добавлять ли их в общий список.
Ретро - это вынос проблем, которые могут быть внутри определенной задачи/команды, но которые аффектят гораздо больший кусок организации, и следовательно не может быть решен внутри.
Это решение проблем вашего SDLC, подхода к работе, к инфраструктуре.
Это хорошая и важная часть, но ее нужно уметь готовить, а именно - минимизировать сами митинги в продолжительности (приходить с подготовленными вопросами, а не вкидывать их прямо во время ретро), и от ретро должна быть реальна польза - проект должен быть готов внедрять решения различного уровня сложности. Для этого менеджмент должен реально выделять ресурсы. Как капасити, так и финансы.
Но на ретро также можно и выяснить, почему есть такая проблема, и реально понять, что изменить некоторые вещи на более удобные, реально стоят дороже, чем кажется, и иногда настолько дороже, что заказчик не готов это оплачивать.sashadzen Автор
26.08.2023 15:49Вроде я так и написал, а вы сказали другими словами)
iggr63
26.08.2023 15:49Про ретро в отделах/ подразделениях зря написали. Там как раз устоявшийся коллектив которому ретро не нужны. А вот на проектах со сборной командой впоне таки требуется и именно в таком духе как описано выше.
saboteur_kiev
26.08.2023 15:49+1Вы сказали "Во время ретроспективы предложите команде вспомнить пройденный этап"
Вот именно на этом моменте, ретроспектива за пару митингов превратится из инструмента в место для нытиков, которых никто не воспринимает, в результате на него перестанут приходить, перестанут серьезно воспринимать, перестанут им пользоваться.
Ретроспектива должна проходить эффективно, иначе в проекте где больше одной команды, она будет просто переливанием различных мелочей и продолжением обсуждений спринта.
Выступающие должны прийти с готовыми темами, может даже с готовым решением, которое кратко обсудят, назначат ответственного (не исполнителя, а того кто организует/проследит/придумает решение более детально на следующий митинг), и перейдут к следующему.
В Agile может быть много разных типов митингов. Но чтобы Agile работал, каждый митинг должен отвечать за свою часть, и самоорганизованность команды и каждого игрока в ней влияют на то, как Agile работает в проекте.
vyatsek
26.08.2023 15:49+1Ретро, спринты, скрамы.
Пусть сначала авторы этого процесса покажут результат своей работы. Я не понимаю почему народ на слово верит хрен пойми кому.
Вот торвальдс делает(делал) ядро линукса через mail lists и так до сих пор происходит. При этом там нет скрама, ядро работает на сотнях миллионов устройств. Т.е. это наисложнейший универсальный мировой продукт.
Вопрос почему люди выбирают какой-то непонятный скрам, который реально не доказал свою успешность в деле, а не изучают процессы в результате, которых был сделан мировой продукт огромной кучей людей?
Да безусловно скрам содержит полезную инфу, но целиком и полностью ей доверять никак нельзя.
Я не хочу читать, что это работает, я хочу запустить и проверить что это работает.
Почему 2 недели например? у меня есть фичи которые делаются 2-3 мес, и частичная их работа бизнес не интересует, т.е. бизнес начнет зарабатывать деньги когда фича будет, а что там просиходит до этого их мало интересует.
Если мне скажут например мы ходим на ретро, я скажу, что все проблемы были озвучены своевременно и пойду работать.
Если манагер не улавливает проблемы в контексте, и выдергивает всю команду на то, чтобы ему еще раз сказали, что у него не так в команде, такой менеджер мало того что сам не работает, так еще и мешает работать другим.
Yuri_nedre
26.08.2023 15:49+1Скрам надо внедрять там, где он применим. Большая проблема, что его пихают везде, где только можно.
Но в защиту Скрама можно сказать, что его пихают везде, так как лучше ничего не придумали для проектов с высокой долей неопределенности.
venanen
26.08.2023 15:49+5Вот сижу я, условный сеньор-помидор, и делаю задачу. И понимаю, что мне что-то не нравится. Я могу пойти и сказать, что, вот, так и так, пните бек/фронт/пм, потому что вот такие проблемы есть. Или я могу эти проблемы высказать лично - обсудить директивно с тем, кто эти проблемы создает. Есть хотя бы одна причина, почему я должен ждать две недели до конца спринта, и говорить об этом там? Мы ведь взрослые люди, ведь так?
А нет, видимо не так. Не знаю, с чем связано, но разработчик в глазах менеджмента потихоньку скатывается к развитию двухлетнего ребенка с функцией писать код. Отсюда внезапно появляется тысяча статей о том, как мы начали кормить разработчиков овсяной кашей, и как это повысило нашу производительность. Другой менеджер, прочитав статью, решает, что нужно срочно внедрять такие же методы, и пишет статью на хабр, а дальше оно копится как снежный ком. Начали появляться различного рода профессии вроде неких деврелов, чтобы взаимоотношения строить - ведь логично, что взрослые люди в наукоемкой профессии не в состоянии друг с другом договориться.
Как люди 10 лет назад писали код? Задачу дали - инструмент дали - не мешают. И работало ведь.g000phy
26.08.2023 15:49+1>почему я должен ждать две недели до конца спринта
Непочему. Ждать не нужно. На ретро скажете была проблема, быстро решили, все молодцы. Делов на 2 минуты.
Или на ретро скажете была проблема, пол спринта добил чтобы решили, в итоге свою задачу доделывал впопыхах или вообще не успел.
Ретро для системных проблем, а не сиюминутных. Потому и готовиться особо не надо. Системная проблема на то и системная, что не даст о себе забытью
Mike-M
26.08.2023 15:49Как люди 10 лет назад писали код? Задачу дали — инструмент дали — не мешают. И работало ведь.
Причем работало даже лучше, чем поделия, работающие сейчас.
g000phy
26.08.2023 15:49+1Товарищ автор, вам для инфо да и в целом для расширения кругозора т.к. мнения в комментариях полярные.
В целом одни и те же принципы эксплуатируют различные методологии в различных сферах деятельности. Отличия лишь в названии и предметной области. Так например бережливое (Lean) производство предлагает выделять время (например час в неделю) на выявление проблем и улучшение процессов.
По своей сути выделение отдельного сервера для сборок, покупка дополнительного шредера архивариусу и установка отдельного крана с деионизированной водой на производстве - это решения одного порядка и к ним приходят примерно одинаковым способом. Выявляют системную проблему и борются с нею. Выявляют на ретро или любом другом аналогичном мероприятии.
SuperKozel
Дикая ненужная хренотень, заставлюяшая людей что-то из себя вымучивать. Всё моменты можно обсуждать нормально в рабочем процессе, а не вырывать людей из потока. Нет ничего хуже чем вспоминать, что ты делал раньше, даже в. Рамках двух недель. За две недели не происходит буквально ничего, что можно обсудить. И это ненормально обсуждать рабочий процесс через полгода, вы за полгода не можете поставить работу на поток, и отладить процессы в команде?
sashadzen Автор
А кто сказал про пол года?
Если обсуждать сразу, то это не выдергивание из потока?
Ретроспектива проходит тогда, когда спринт закончен. По его итогу идет разбор полетов. Это помогает каждый следующий этап работы сделать лучше.
Что касается ретро отделов — проводим их раз в два месяца. Разбираем, что было за это время. Это не значит, что остальное время все молчат, как рыбы :)
SuperKozel
Это у менеджеров спринт что-то значат, какое-то мерило, менеджерский цикл. Для человека, который работает эти две недели пролетают так, что ты уже не помнишь, что было две недели назад. Если пилишь большую фичу, ты не помнишь, сколько это заняло и сколько ещё займет. Это есть состояние потока, погружение в текущие задачи, мы не хотим хранить ненужный контекст в памяти. И как раз лучшее что может сделать менеджер - это сохранять это состояние, не давать из него выйти, помогая решать мелкие рабочие моменты, распределять задачи, координировать внутри команды и вне с другими. Но менеджеры этого не могут понять, им нужна стимуляция полезной деятельности. И за две недели ну ничего не меняется, и ни один менеджер сам никогда не сможет провести, так как сам не вспомнит точно, кто что делал. Это просто именно что вымучивание. За все время работы у нас не было ни одного полезного ретро. Все полезное уместилось бы в десяток тредов в рабочем чате. И они обожают в этот круг дрочерства вытягивать всех, не понимая, что в отличие от них, у людей есть настоящие задачи. Имхо, производительность команды увеличат не митинги, а если убрать одного тимлида и вместо него взять фулстека, который может перекидываться на ботлнеки в рамках команды. А если что, и сам протестирует, если ботлнеки на тесте. Вот такой человек будет золотой и дай тебя расцелую.
sashadzen Автор
Спасибо за развернутое мнение. Это действительно аргументировано. Я думаю, что где-то есть золотая середина и мы как раз в поиске ее.
Многое зависит от процессов и от компании. Если это органично встроено, то хождения по мукам сводятся к минимуму. Хотя я настроения, подобно вашим, иногда наблюдаю. Вероятно, еще зависит от отношения к ретро.
vmkazakoff
У вас какие-то проблемы с командой или задачами. Ну или с РО или кто там у вас.
1) за спринт должно, нет, даже не так, ОБЯЗАНО, что-то произойти. Во первых в этом смысл спринта - не просто какие-то рандомные две недели в которые что успели то и успели, а очень конкретные цели на эти две недели. Во вторых спринт средней команды на 6-7 человек стоит компании 1-1,5 млн. В самом худшем случае стоит задать себе вопрос на что их просрали и почему вместо нас не нанять голых баб на такие деньги.
2) В смысле "не помнишь" что было за две недели? У вас там ни тасктрекера, ни гита? Вообще не помнишь? Вот совсем? Про цель спринта молчу, как ее можно забыть я вообще хз.
Может быть такое, что помнишь и просто не случилось ничего, что требует обсуждения. Ну и ок, у других то не так. Им помочь не надо? Порадоваться за них. Подсказать что-то. Вообще ни у кого ничего не случилось? Так не бывает. Демо было, на нем был фидбэк от юзеров. Даже если он хороший, что никто не подумал, что если бы сделали А вместо Б, то было бы ещё лучше? Значит просто все боятся язык из жопы достать и озвучить проблемы.
3) Именно чтобы не выдергиваться из рабочего процесса и не решать проблемы сгоряча и есть ретро. А если разборка что "а мы от дизайнеров макеты поздно получили" и "а чо вы раньше не сказали что так нельзя было, мы уже так нарисовали и согласовали" решается в моменте то это как раз вырывает из процесса и не помогает никак.
4) Фуллстэк который помогает вытягивать ботлнеки и есть тимлид (ну или техлид по терминологии некоторых компаний). Только он именно помогает, а не просто решает все самые сложные ситуации, не давая развиваться другим. И нанимать второго такого - плохая идея. Для того и придумали разделение труда и экспертизу в своей области. А если за вами надо нескольким тимлидам бегать сопли потирать, то точно лучше всё-таки голых баб вместо команды, с ними и повеселее.
5) Менеджер (тимлид или РО) должны помогать решить проблемы, но для этого они должны: а) узнать что она есть, желательно без применения хрустального шара и ректальной криптографии, б) понять что это именно проблема, а не вы выдумали, для чего хорошо бы иметь все точки зрения и ещё пару наблюдений со стороны, в) понять как это чинить, для чего лучше всего подходит экспертиза тех, кто был уже внутри ситуации или шарит в ней. В итоге ретро и есть то место, где я могу узнать от команды что дизайнер нарисовал в макете что-то смог не реально было за спринт сделать, без девопса не успеваем серваки настраивать, тестировщик кейсы прописал поздно и пр.
У вас или очень очень плохая команда, или совсем плохая компания, или крайне специфичная область... но скорее всего, конечно, проблема в вас самих, если за все время прям ни одного хорошего ретро.
sashadzen Автор
Ух, очень развернуто объяснили зачем нужно ретро. Зашел вам плюсик в карму поставить, а столько минусов. Видать те, кто прячется в кокон от проблем, накидали :)
Ретроспектива — это часть процесса разработки. Не бывает, что все прошло гладко, это точно.
«Если вы ничего не сделаете, я уверяю вас, ничего и не произойдёт» ;)
avost
Ну, я сделол за спринт вторую треть сложной задачи. Что произошло? Да, ничего. И прошлый и в позапрошлый это же "произошло".
Вот именно, товарищ манагер. У вас что, нет ни трекера ни гита? Вы ленитесь туда посмотреть? Может вы вообще не владеете этими инструментами? Что могло помешать вам туда заглянуть? Зачем разводить эту мутотень и повторять то, что уже описано?
А чем это решение проблемы на ретро отличается от решения проблемы на дейлике? На дейлике я ещё помню в чём была проблема, к ретро могу и забыть.
А может у вас? Ярлыки навешивать легко.
Если вопросы решаются более оперативно, чем раз в две недели, то, с вашей точки зрения, это проблема? И именно у вашего оппонента? А мне кажется, ровно наоборот :)
sashadzen Автор
Запасаюсь попкорном :)
Вот вы говорите про дейлики — так стендап, как и ретро — часть скрама.
На стендапе принимают решения, как лучше сделать именно сейчас, а на ретро вносят изменения в процесс.
Это я сильно упростил, чтобы не писать портянку.
avost
Дейлики могуть быть частью скрама, а могут не быть частью скрама.
Дейлики вообще придумали давно. Ещё до рождения скрама. И даже до рождения авторов скрама :)
Если мерилом работы является религиозный процесс, то да. А если результат, то it depends. Во многих случаях эффективнее не ждать приседаний по команде, а решать проблемы по мере их поступления.
Ну, вот, работает команда пять лет. И вы всё это время каждые две недели вносите изменения в процесс?
Кажется, эти формализованные приседания имеют смысл в начале работы новой команды, когда коллеги ещё не привыкли друг к другу.
Сколько ни работал в разных командах, лучшее, что случалось на ретро - вынесение вопроса - давайте проводить ретро ЕЩЁ реже :)
SuperKozel
"Вот именно, товарищ манагер. У вас что, нет ни трекера ни гита? Вы ленитесь туда посмотреть? Может вы вообще не владеете этими инструментами? Что могло помешать вам туда заглянуть? Зачем разводить эту мутотень и повторять то, что уже описано?" - дай я тебя обниму)). У меня если начать задумываться, начинает пригорать, что менеджер хочет чтобы ты помнил предыдущие две недели. Это означает а: ты должен записывать и вести лог всех своих свершений за эти важные для компании две недели, либо б: постоянно держать в памяти устаревающую информацию, а к ретро все это прокрутить заново.
SuperKozel
Есть такой тест на память, ты должен с помощью любых техник запомнить максимальное количество слов-существительных из набора(около 20)
проверяется три раза - сразу после запоминания, на следующий день и через неделю и две(не помню, потому что читал про этот тест больше двух недель назад).
Так вот, с каждым разом человек почти всегда называет меньше слов, чем в предыдущий. И это в рамках пары недель. А это всего 20 каких-то несчастных слов, а не полная история мытарств за две недели.
Поэтому когда вы умные менеджеры добавляете человеку обязанность помнить предыдущие две недели, вы вносите дополнительную сложность в процесс, из-за которого
падает индивидуальная эффективность. Как понижая индивидуальную эффективность можно повысить общую для меня загадка, это какая-то скрам-магия.
Как правильно делать: пользуйтесь мать его таск трекером и любыми утилитами по анализу этих данных, разговаривайте с коллегами на дейликах, но не о прошлом, а НАСТОЯЩЕМ, о текущих проблемах.
Пока ретро не начинается с того, что тимлид проговаривает саммари за две недели(что как раз является его прямой задачей, управлять процессами и помнить их историю, как минимум в рамках своей команды) я считаю это симуляцией полезной деятельности.
novoselov
У вас ошибка в фразе "с
тимуляция полезной деятельности". В целом правильные замечания, проблема в том что чаще всего человек проводящий ретро не понимает его смысл, поэтому и получается вымучивание. У меня был только 1 раз когда скрам мастер не симулировал процессы, а реально делал полезную работу. И в этом плане ретро было время когда разработчики могли рассказать о своих проблемах, поделиться чем-то полезным и самое важное после этого ОН что-то делал, так чтобы это не пропадало в ящике отложенных (на никогда) дел.Yuri_nedre
Вы как-то всех судите по себе.
Если вы работаете на износ, что в конце спринта не помните, что было в начале - этот вопрос надо обязательно поднимать в команде. И ретро отличное место для этого.
Так и выгореть недолго...
Но я в командах давно решил эту проблему: делаю доску для ретро вначале спринта, ссылка всегда одна и та же, вся команда знает где она лежит. И если члену команды хочется что-то обсудить, чтобы не держать мысль до конца спринта - он сразу пишет ее на доске. Дальше перед ретро смотрим - есть что обсуждать или ретро можно скипать.
п.с. ни разу еще не скипывали, всегда проблемы набираются. Просто иногда проводим быстрее запланированного тайминга.
sashadzen Автор
Про доску перед началом спринта интересно, надо попробовать)
Batalmv
За стандартные две недели происходит в живой команде до фига. А если и демо прошло не очень ...
Возможно вам не повезло с командой, либо с менеджером
Потому что почти всегда есть что сказать
И да, можно кого-то позвалить. И даже не кого-то одного :)
sashadzen Автор
Неистово плюсую!
Ретроспектива — это не сколько пожурить, а отметить хорошие моменты :)
M0Peterson
А вот незнаю. Мне (и как оказалось - команде) очень нужная хренотень, потому что без ретро ловлю себя на мысли, что заканчиваю рабочий день не дорабатывая, есть какое-то ощущение незаконченности, будто весь день ничего не сделал. При этом проект перформит сильно лучше конкурентов по рынку, таски закрываются, новые продукты выкатываются, процессы улучшаются, всякие штуки по управлению командой делаются, 1-2-1 проходят регулярно, а вот я как-будто ничего и не делаю. А все потому что с конца весны ретро перестал проводить, и нет четкого осознанного и озвученного подведения итогов и результатов ни у кого.