Comments 15
Поздравляю, вы придумали ежедневные отчёты сотрудников в Битрикс, по закрытии смены.
"Не хотите ли заменить емейл созвоном". Ага, "защитили" емейл. Вот если бы вопрос был "не стоит ли отменить еще и этот отчет" -- то ответы были бы совсем другими, да? :)
Из моего опыта польза от дейликов внутри команды больше в том, чтобы поделиться проблемой, в которую сейчас уперся, и спросить советов от тиммейтов. Очень полезно и экономит время, когда ты собираешь грабли, по которым кто-то уже прошелся. В этом я полностью согласен с вашим коллегой:
Внутри конкретного проекта дейлики — это благо. Внутри команды по куче разных проектов — ооочень сомнительно.
Скажите, а в чем цель этого ежедневного отчета о проделанной работе? На первый взгляд кажется, что он просто дублирует информацию из Jira. Спрашиваю не с посылом "ща научу всех процессам", правда хотелось бы понять. А в статье ответа не нашел.
На первый взгляд кажется, что он просто дублирует информацию из Jira.
В jira надо менять статус по статусу из коммитов, а уже из jira можно сконсолидировать автоматом для ответа на первый вопрос.
Для ответа на второй вопрос из гугл формы, надо добавить три чекбокса. Первый - тоже что вчера. Соответсвенно автоматом берём из вчерашней формы. Второй следующий тикет из очереди. Соответсвенно берём автоматом первый тикет из очереди отсортированный по критериям. Ну и третий - жду ЦУ от тимлида.
После чего собираем всё вместе - показываем пользователю и просим подтвердить или добавить/изменить.
Для особо микроменеджных руководителей, можно ещё автоматом собрать все вчерашние письма/IM сообщения и через LLM сделать выжимку. Пущай наслаждается.
Соглашусь, что это могло быть дублированием Jira, если бы мы использовали ее или аналог для ежедневного трекинга задач :)
В нашей специфике какие-то проектные команды (участники Stand-up report) работают в ITSM для L3 Incidents и Change Requests, какие-то в Kanban-досках для проектов, статус которых отслеживается в основном раз в неделю.
И как раз в Stand-up report нашли компромисс для ежедневной синхронизации и решения следующих задач:
сокращение времени всех сотрудников на участие в рутинном утреннем созвоне, эффективность которого в нашем контексте стала сомнительной
инструмент самоорганизации (реже возникает вопрос "а чем важно заняться сегодня?")
фокусирование на выполнении плана, чтобы меньше отвлекаться на другие менее важные задачи/просьбы "здесь и сейчас"
прозрачность "done yesterday и to do tomorrow" по всем сотрудникам и для всех сотрудников (что, как вы верно заметили, могло бы быть в Jira, которую мы не стали внедрять только для функционала решаемого через Stand-up reporting)
По моему наблюдению, де факто, эти созвоны в большинстве команд являются вредной и не эффективной активностью. А куда более эффективно определить примерное время в которое PM обзванивает коллег в команде и они один-на-один выясняют как дела, и при необходимости могут ситуацию обсудить подробнее, не отвлекая еще десяток человек в команде. Рассказы в маркетинговых материалах по Аджайл, что всей команде полезно слушать что там творится у коллег, по факту в большинстве команд не работают -- все тупо ждут чтобы оттарабанить о своем прогрессе, а остальное время просто в пустую тратят время, слушая в пол уха (или не слушая вовсе, если уже отчитались).
А куда более эффективно определить примерное время в которое PM обзванивает коллег в команде и они один-на-один выясняют как дела, и при необходимости могут ситуацию обсудить подробнее, не отвлекая еще десяток человек в команде.
Не видите ли риск попасть в большую зависимость от такого РМ? И с удаленной командой в ±10 человек есть вероятность, что РМ только и будет, что проводить весь свой рабочий день на ван-ту-ванах, как мне кажется
Рассказы в маркетинговых материалах по Аджайл, что всей команде полезно слушать что там творится у коллег, по факту в большинстве команд не работают -- все тупо ждут чтобы оттарабанить о своем прогрессе, а остальное время просто в пустую тратят время, слушая в пол уха (или не слушая вовсе, если уже отчитались).
О да! Мы признались себе в этом, что как раз послужило одной из причин отказа от голосовых Stand-up в пользу инструмента, описанного в статье
Ну в рекламных проспектах Аджайл рекомендуют стенд-ап митинги умещать в 15 минут. Ок, в реальной жизни это часто пол часа .. час. Если один-на-один PM будет обзванивать, то будет тот же час в день (для него), при этом с одними подчиненными можно будет спокойно обсудить их вопрос, не беспокоясь что остальные ждут своей очереди, а кого то можно легко пропустить. На самом деле каждый день каждого человека какой вообще смысл опрашивать? Таски есть в JIRA, там же люди отмечают прогресс, если это квалифицированный товарищ то можно и раз в 2-3 дня общаться голосом, а в промежутках просто в чате пингануть типа "вопросы есть?". А какой нибудь джуниор -- так с ним с одним можно минут 15 беседовать о том что он и как делает. Так что никакого целого дня тут нет. А коммуникации с командой это и есть работа PM. Плюс планирование и коммуникации с заказчиком. Если на каждую из этих трех активностей выделить по 2 часа в день, еще и 2 часа на смузи останется.
С точки зрения эффективности инструмента также важно насколько регулярно и качественно непосредственный менеджер отслеживает контент, находится в контексте Stand-up reporting своей команды. На это, конечно, требуется время руководителя, но уже не требуется время 15 человек команды, ранее ожидавших своей очереди “Stand-up” на утренней встрече.
У вас не совсем (вернее, совсем не) верное представление о назначении стендапов в аджайл-методолгиях. Это вовсе не отчётная встреча для информирования своего менеджера.
Задачи стендапа ровно две:
Поддержание осведомленности команды на достаточном уровне (чтобы Петя представлял, что сегодня собирается делать Вася)
Выявление проблем на ранних стадиях (Петя собирался интегрировать свой модуль с модулем Васи, но оказалось, что Вася столкнулся с проблемами и ещё не закончил свою часть работы)
Ваш подход не решает ни одну из этих задач: давайте будем честны -- вряд ли все участники команды внимательно прочитают, что зарепортили другие, да ещё напишут куда-то, в чем видят проблемы.
Я вполне допускаю, что ваш подход в каких-то условиях может оказаться эффективным, только не надо противопоставить его скрамовским стендапам: это совершенно не про то.
Давайте будем честны -- вряд ли все участники команды внимательно прочитают, что зарепортили другие, да ещё напишут куда-то, в чем видят проблемы.
Давайте будем честны - вряд ли все участники команды внимательно слушают всех спикеров на стендап-созвонах :)
Как мне кажется, если Пете надо получить информацию, то он получит ее в обоих вариантах. Если Пете не до чужих стендапов по каким-то причинам, то даже крик Васи (а тем более "тихая речь на фоне очередного созвона") может не донести важную информацию.
Для всего остального по-прежнему есть тимлид и полная свобода Васи и Пети так же созвониться/встретиться в любое время
Если фронтедер Дима ждёт дизайна от Ани , будьте уверены: и послушает внимательно, и вопросы задаст. А завтра Дима будет интегрироваться с Петей и не будет внимательно слушать Аню, но будет внимательно слушать Петю.
"Если надо получить информацию -- то он ее получит" очень напоминает аргумент противника онбординга новых сотрудников, типа "если захочет -- сам разберется". Конечно получит, и конечно разберется, вопрос лишь в том, сколько времени это займет.
Ещё раз: ваш подход никоим образом не является заменой стендапов, ибо решает совсем другую задачу -- сбором отчёта для менеджера. Это ни хорошо, ни плохо, это просто про другое.
На прошлой работе у нас был выделенный канал в слаке, где каждое утра каждый член команды писал статус из 3-х пунктов: что сделал вчера, что будет делать сегодня, с какими проблемами столкнулся. При необходимости что-то обсудить или прояснить прямо в том канале и обсуждали.
Пусть скрипт работает, а вы спите: автоматизация Stand Up Meetings