Comments 6
В современных реалиях нужно заносить число митингов в неделю в KPI любого менеджера. Неважно что выхлоп нулевой, главное что человек всё время при деле и не отвлекает сотрудников от работы. Это тот самый уровень абстракции что отделяет бизнес от разработчиков. Если ещё без потерь транслирует информацию туда сюда - вообще замечательно.
Другое дело что всё это заменяется бордой в джире и страничками в Confluence, но это же непорядок когда в офисе тихо и все пялятся в мониторы, где же движ и активность, без них инвестору идею не продать.
Есть правда продукты типа nginx или Μοzilla которые делались программистами для программистов безо всякого менеджмента, но ведь там денег никто не заработал, так что несчитово.
Это тот самый уровень абстракции что отделяет бизнес от разработчиков
Ключевая роль руководителя (например, продукта) быть как раз этим связующим звеном и иметь контекст обеих сторон и давать возможность по минимуму участвовать в различных синках с другими командами (например, с другим отделов разработки, аналитиками, локализаторами и тд)
Другое дело что всё это заменяется бордой в джире
Уверены, что заменяется? Дополняется и облегчает работу - да. Вы пытались когда-нибудь сами организовать работу по проекту в который входит 10+ команд из разных отделов, с 10 разными проектами в джире, разными процессами поставки задач и SLA на их выполнение?
Если да, буду рад выслушать ваш вариант как все сделать правильно и не про...ть сроки и не получить на выходе что-то вообще не похожее на изначальное ТЗ.
Есть правда продукты типа nginx или Μοzilla
Есть стартапы из 10 человек, кто пилит здоровенный продукт сидя в одном подвале, и есть банковское подразделение из 1000+ сотрудников сидящих по всему миру. И цель у обоих продуктов одна - заработать денег. Основатель Nginx кстати заработал, продав это все дело... а теперь опять вышел со своих Free Nginx. Что-то пошло не так?
"день состоит на 80% из митингов."
Что же это за митинги?
"Синк с ..."
"Синк по ..."
"Синк по статусу"
"Промежуточный синк по планам"
"Первичный обзор решений"
Итого, почти все ваши митинги - это мусор. Самое правильное решение:
1. Перестать самому создавать бесполезные митинги. Статусы задач вы можете сами посмотреть в Jira и других тикетных системах.
2. Если нужно задать вопрос, то лучше отправить e-mail, чем создавать митинг. Асинхронные коммуникации намного дешевле и удобнее.
3. Внедрите в компанию "культуру митингов", когда митинги будут создавать только в том случае, когда других вариантов нет. У митингов должен быть план проведения с перечислением вопросов, которые там будут обсуждаться. Будет внедрено ограничение на время проведения митинга и на количество приглашённых людей. По итогам митингов появится список решений, которые были приняты с указанием того, кто должен реализовать их, а также список вопросов, которые обсуждались. Идеальный вариант, когда напротив каждого пункта в плане митинга будет указано, к какому решению по итогу вы пришли.
4. Научитесь уже делегировать задачи и принятие решений своим подчинённым. Хватит быть затычкой в каждой бочки. Пусть люди сами принимают решения и получают за это награды, а не ждут вашего "ценного" мнения или приказа. Это ускорит принятие решений в 2 раза и упростит многие процессы в отделе.
5. Выполнив перечисленные выше рекомендации вы неожиданно обнаружите, что оказывается, у вас появилось много свободного времени на стратегические задачи, появились большие куски времени по несколько часов для сосредоточенной работы.
6. Любая хорошая книга по тайм-менеджменту начинается со слов, что вам нужно работать НЕ больше, а эффективнее. Задумайтесь над этим. Правило Паретто (20% усилий дают 80% результата) не просто так было придумано.
Вот статус-митинги меня больше всего выбивают из себя - часовая встреча где РП докладывает о том что сделано и что осталось и куча других бесполезных слов.
Имхо, в большинстве случаем это можно заменить письмом: план прошлого спринта выполнен, новый спринт распланирован и у задач расставлены приоритеты.
Ну или свести встречу до 15 минут что бы обсудить только проблемные задачи.
Короче в большинстве таких совещаний лично я параллельно или занимаюсь другой задачей, по которой сраки сроки подгорает, или зависаю в соцсетях смотря мемчики чтобы немного расслабиться и очистить мозг.
Если можно заменить письмом или статусом в чате - почему не просите ПМа сделать именно так? Просто вижу несколько причин
Нет доверия у ПМа к команде
ПМ хочет контролировать все и вся
Процессы не настолько автоматизированы/настроены и приходится руками собирать статусы
Или же статус не интересен вам, но интересен и важен остальным присутствующим, кто может задать вопросы в онлайне и почувствовать ответственность за результаты. командный дух и все такое. Но это больше про спринт ревью/демо и тд (которые тоже спокойно можно увести в оффлайн режим и заменить отпиской в чате, но в скраме как-то до этого недодумались)
Попробую прокомментировать по пунктам.
Итого, почти все ваши митинги - это мусор
К сожалению, не все события именовались корректно в этом случае и синк может означать совместно принятие архитектурного решения, проработка стратегии тестирования по проекту и так далее. Бывают онлайн синки, которые носят характер дать статус, но это скорее связано, что не всегда легко понять по джире в чем проблема, почему что-то не двигается и почему одна команда не предупредила другую завершив свою часть работ. Это решает автоматизацией процесса (к этому надо придти на уровне всей компании)
Статусы задач вы можете сами посмотреть в Jira
Тут ответил частично выше. В идеале - да. Стараюсь по максимум делать под сложные проекты отдельный роадмап (джира план) + джира дашборд. Тут видим и все статусы команд, и процент завершения и потенциальные блокеры. Но это не покрывает 100% кейсов.
Асинхронные коммуникации намного дешевле и удобнее.
100% согласен, это используем по максимуму. Но сразу скажу бывают кейсы когда несколько сотрудников общаются уже пару часов в чате и каждый вообще не понимает друг друга, или когда сложно объяснить словами, а проще пошарить экран и показать на практике.
Внедрите в компанию "культуру митингов"
Вот эта часть наверно самая сложная. Можно долго про это рассказывать, но пока нет инструмента для автоматической валидации, это все же будет не правилом, а рекомендацией. Про вариант, когда против каждого пункта указан исполнитель, я по сути упомянул в секции про Постмиты (то что вы мусором назвали), под каждый спойлером там именно такой список с действиями, сроками и исполнителями.
Научитесь уже делегировать задачи
Мы не в идеальном мире живем, не все задачи можно делегировать и не все подчиненные хотят этими задачами заниматься. Что к этому нужно стремиться - согласен.
5 и 6 правило примерно соответствуют решению - нормально делай, нормально будет. Вроде и не поспоришь, но покажите мне где это работает на 100 процентов?
Хорошо писать книжки и статьи на тему эффективного управления, там много можно замести под коврик и не показывать исподнего. Строить процессы лучше всего на примере сферического коня в вакууме, когда нет людей. Как только появляются люди (причем с самыми разными навыками и характерами) все резко становится не таким красивым и не таким простым.
Как не про…пустить все дедлайны. Автоматизируй, властвуй, сохраняй