Как вы отслеживаете то, над чем вы и ваша команда работаете ежедневно?

Я борюсь с тем, как следить за тем, что на самом деле делают я и люди в моей команде каждый день. Я получаю хорошую общую картину, перебирая заполненные карточки каждую неделю, и кое-что помогает немного, но мне кажется, что я не очень хорошо разбираюсь в повседневной работе моей команды. Карты будут работать в течение многих дней без обновления на ежедневной аптеке, и некоторые инженеры - моя команда, не самая общительная.

Я думал о создании какой-то ежедневной записи, которую все заполняют (через список рассылки или общий документ Google), но это кажется довольно громоздким и ручным.

Мониторинг активности GitHub работает хорошо, но может быть немного ошеломляющим из-за того, сколько писем он отправляет каждый день. Я думал о том, чтобы попытаться создать для него дайджест-систему, но у меня нет свободного времени.

Какие стратегии вы реализовали, чтобы оставаться в курсе того, что ваша команда делает каждый день, чтобы вы могли измерить работу над «выполняемыми» задачами?

Я говорю с ними.

Технология не может решить социальные проблемы. У вас короткие утренние заезды. Что ты делал вчера? Что ты будешь делать сегодня? Есть препятствия?

Если что-то звучит подозрительно (или мне любопытно), я останавливаюсь и задаю вопросы: «Вы работали над XYZ вчера, как это получилось?». Это заставляет людей обращать внимание и на самом деле знать, что происходит. Это также держит вас лидером команды в курсе (и обращая внимание, и на самом деле зная, что происходит). Это должно быть вовремя и коротко ( максимум 10 минут ). Что-нибудь еще, и люди не будут "откладывать" работу. Они остановятся и подождут ожидания, а затем займут время, чтобы начать снова. Некоторые все равно это сделают, но в основном это неизбежно.

Затем я захожу к столу у всех во второй половине дня. Не каждый день (хотя это может быть больше, чем каждый день для новых людей), не в одно и то же время, но примерно в одно и то же время (так что это и неформально, и регулярно). "Есть проблемы? Есть препятствия?"

Вы будете удивлены, как часто вы будете сталкиваться с проблемами, когда люди один на один.

Если у людей нет проблем, замечательно; возвращайся к работе. Если у них нет проблем всю неделю ? Проблема. Вы не бросаете им вызов, или они не раскрываются. Спросите, как продвигается XYZ (что они упоминали в standup) Заставь их объяснить вещи.

Это не микроуправление. Вы не говорите им, как делать свою работу. Вы не присматриваете за ними. Вы там, чтобы устранить препятствия в их повседневной жизни. Вам нужна информация, чтобы сделать это. Пока вы не пускаете свою команду на совещания, а руководители проектов - на свои кубики, один человек, который останавливается, чтобы помочь раз в день, не вызовет у них горе. Но все эти взаимодействия должны исходить из вены «Я здесь, чтобы помочь вам».

Еще одна вещь, которую я сделаю, это обзор наборов изменений (самостоятельно, неофициально). Затем я могу увидеть, как часто люди регистрируются, насколько велики их наборы изменений, насколько они соответствуют тому, что они сообщили, как часто они делают что-то новое, сколько исправлений у них есть и так далее. Изменение рабочего элемента на «выполнено» практически бессмысленно. Посмотри на код. Кажется ли это сделано?

примечание: один чрезвычайно серьезный аспект: насколько велика ваша команда? Это более 7 человек? Конечно, вы не сможете отслеживать все происходящее, если ваша команда слишком большая.

Не управляйте своими разработчиками на микроуровне!

Продуктивная разработка программного обеспечения требует длительных умственных усилий. Нереально ожидать, что они будут производить постоянную продукцию. Если вы начнете измерять их ежедневно, они будут перестраивать свою работу так, чтобы они всегда производили какие-то заметные артефакты, которые вы могли бы видеть каждый день. Это может или не может иметь положительное влияние на качество вашего программного обеспечения. Это почти наверняка окажет негативное влияние на эффективность ваших разработчиков.

Как подсказывает Роберт Харви , не управляйте своей командой на микроуровне. Дайте команде несколько приоритетных задач с конкретной бизнес-ценностью и позвольте вашей команде лучше понять, как обеспечить эту бизнес-ценность.

Если команда обеспечивает ценность для бизнеса, то вы должны быть счастливы. То, как они добиваются того, чтобы они предоставляли запрошенные функции, должно зависеть от них.

Тем не мение:

Карты будут оставаться в работе в течение нескольких дней без обновления в ежедневном режиме ожидания

Это может указывать на недостаток процесса.

Это может быть команда, которая на самом деле не функционирует как команда, и не вмешивается, чтобы помочь друг другу, когда они застряли. Это также может быть общение с бизнесом. Задачи слишком большие, поэтому становится трудно понять, что нужно. Технические характеристики не ясны.

Также может быть, что реальной проблемы нет вообще. Может быть, команда просто отлично работает с карточками, представляющими основные работы, на выполнение которых уходит несколько дней, и, возможно, команда работает хорошо, чтобы добиться этого.

Я думаю, что это правильно использовать ретроспективу в качестве платформы для выражения вашей озабоченности. Иногда полезно получать наблюдения извне.

Но пусть команда выяснит, есть ли проблема, и какова причина этого. И будьте готовы согласиться с тем, что, возможно, вам нужно настроить способ, которым задачи доставляются команде.

Помните, что ежедневное вставание - это инструмент для команды, помогающий им организовать работу; Это НЕ инструмент для менеджеров, чтобы следить за тем, что делает команда.

«Push-сообщения», а не «Push-сообщения»

Разработчик часто попадает в одно из следующих для вас состояний:

1. Даааа, я сделал X!
2. Я работаю над X, но, похоже, это займет много времени ...
3. Я застрял в проблеме Y, изучаю ее, но, возможно, понадобится совет;
4. Я заблокирован, потому что я жду A, B и C.

В идеале вы хотите иметь достаточно актуальную информацию об этих статусах без ущерба для фактической производительности. Константа "Мы уже там?" является контрпродуктивным, но может случиться так, что вы можете сделать что-то полезное для состояний 2-4, поэтому вам необходимо получить информацию о них.

То, что будет работать, это культура «push-сообщений», предпочтительно в автоматическом режиме. Возможно, вам не нужно просматривать весь журнал коммитов, но вы можете создать «панель управления», где вы увидите последний коммит или последний решенный тикет (для ошибок или функций) каждого члена команды. В остальных ситуациях вы можете заставить их по электронной почте предварительно проинформировать вас с такими обновлениями (надеюсь, они встречаются реже, чем коммиты) или спросить их, не видите ли вы непрерывного прогресса на какой-либо панели инструментов - если у вас есть согласно внутреннему соглашению о необходимости застрять (может быть, что какая-то функция не нужна, если выясняется, что это стоит 80, а не 8 часов), тогда либо они будут держать вас в курсе событий, либо вас беспокоит.

В качестве альтернативы вы можете создать культуру, похожую на https://idonethis.com/ ежедневные отчеты, предназначенные для всей команды - это гарантирует, что другие пользователи также будут на той же странице.

Альтернатива некоторым другим ответам (сфокусированным на общении) заключается в том, что, возможно, задачи на ваших карточках с заметками можно разбить на более мелкие части, о которых вы сможете получить обратную связь раньше.

С небольшими фигурами команда чувствует, что каждый день что- то добивается, что должно отражаться в бою.

Недостатком является то, что эти отдельные карты, скорее всего, будут полагаться друг на друга. Команда, которая может очень легко общаться друг с другом, здесь выгодна, или части могут не объединяться так, как должны. Вам также может понадобиться удержать некоторые карты обратно, если вам нужны определенные действия в первую очередь.

При этом люди все равно будут застревать или обнаруживать, что задача намного сложнее, чем они или вы, время от времени ожидали. Вот почему по-прежнему полезно открыто обсуждать проблемы, когда другие могут дать совет, не судя о человеке, имеющем проблемы.

Чтобы ответить на вопрос о микроуправлении, как это уже упоминалось в некоторых других ответах: даже если люди будут выполнять небольшие задачи каждый день, потребуется более широкое представление о своей проделанной работе, чтобы понять, сколько фактически выполняет каждый человек, вместо того, чтобы судить их по их ежедневным достижениям.

Я предлагаю это, потому что я работаю в команде из 8 человек, где общение очень легкое и люди очень доступны. Нам даны задания, которые, как ожидается, никогда не будут занимать более двух дней работы. Иногда эти задачи тесно связаны между собой, и мы должны постоянно информировать друг друга о том, как каждый из нас делает свою собственную работу. Каждый из нас несет ответственность за то, чтобы сообщать нашему менеджеру о том, что мы делали каждые две недели.

После прочтения вопроса я понимаю, что вы, возможно, спрашиваете об этом как член команды, а не как лидер, и поэтому вы можете не контролировать свои задачи.

1. Вы могли бы предложить своему лидеру разбить задачи больше
2. Если ваша работа блокируется или зависит от работы другого члена команды, не стесняйтесь проконсультироваться с ним об этом и при необходимости выполнить другое задание.

Прежде всего вам нужно проанализировать себя с точки зрения вашего времени и навыков. Если вы технический специалист с некоторым опытом работы на практике, это может отличаться от ситуации в том случае, если вы просто менеджер (не обладающий глубокими техническими знаниями о том, над чем на самом деле работают ваши разработчики), которому нужно только следить за соблюдением сроков. ,

Общая точка в обоих случаях является то , что вы должны быть в состоянии облегчить вашу команду и создать ощущение , что вы доверяете им. Вы не оцениваете их эффективность, но стараетесь быть чуткими и полезными, чтобы сделать их опыт веселым и легким.

Теперь предположим, что вы просто менеджер, как я уже сказал выше, в этом случае, даже если какой-то разработчик действительно сталкивается с серьезной проблемой, связанной с развитием, вы не сможете помочь ей / ему. Актуальная проблема может занять много времени и потребует концентрации. Далее предположим, что разработчик действительно искренен в своей работе и уделяет все свое время (даже дополнительное время) решению этой проблемы, но, к сожалению, все еще не в состоянии ее решить. И в такой ситуации (когда вы даже не в состоянии полностью понять проблему) вы продолжаете спрашивать о проблеме, принимая прогресс каждый день и даже неофициально два раза в день. Результатом будет крайнее разочарование и беспокойство для разработчика. Будь то приложение для сбора ежедневного прогресса или просто ежедневная встреча, оба могут быть разочаровывающими.

С другой стороны, сохраняя все остальные факторы одинаковыми, просто предположите, что у вас сильный технический опыт и вы работали над теми же технологиями в прошлом. В этом случае, ежедневный прогресс или регулярные встречи очень полезны. Разработчики, несомненно, будут доверять вам и вашим экспертным знаниям, и им будет удобно обсуждать большие проблемы, с которыми они сталкиваются. Вы предоставите некоторые предложения, которые могут быть полезны, или даже если они не являются непосредственно полезными, они помогут в предоставлении некоторых альтернативных подходов.

Тем не менее, в любом случае ежедневные встречи должны создавать ощущение, что вы член команды, а не руководитель / ведущий / менеджер. Если члены вашей команды не считают вас на том же уровне, что и они, они не смогут сообщить о своих проблемах / предложениях / проблемах / отзывах и т. Д.
Еще один момент, который следует учитыватьЭто размер вашей команды и время, которое у вас есть на управление ею, прежде чем подумать об использовании какого-либо программного обеспечения для автоматического отслеживания прогресса или расширения вашего взаимодействия. Вы должны убедиться, что все вопросы, которые были подняты вашей командой, вы сможете решить их как можно скорее. Основным демотивирующим фактором для члена команды является то, что его проблемы / предложения / отзывы не принимаются всерьез или не оцениваются. Знание ежедневного прогресса важно, но только в том случае, если вы полностью вовлечены в командную работу. Если вы также вовлечены в какой-то побочный бизнес, не пытайтесь больше взаимодействовать с вашей командой. Подумайте о ситуации, в которой реакция вашей команды ошеломляющая, и они представляют свои задачи задолго до времени, вызывая проблемы и запросы, но вы не можете своевременно предоставить отзывы и отзывы. В такой ситуации

Создавайте и пользуйтесь различными чатами для различных конфигураций. Некоторые могут быть широкими, как @engineers, а некоторые могут быть конкретными, такими как @newFeatureA

Подумайте о том, чтобы сделать ежедневную стоянку включенной в обзор билетов на самолет.

Используйте открытую среду, которая поддерживает совместную работу, и убедитесь, что QE и основной владелец продукта находятся в центре внимания разработчиков. Вы много подслушаете и получите представление, увидев экраны вокруг вас.

Как указывает Роберт, прежде всего нельзя считать микроуправлением (обратите внимание на использование «быть увиденным», т.е. независимо от ваших реальных намерений).

В конечном счете мы отслеживаем то, что достигнуто с течением времени, и видим, какова наша скорость от этого. Сосредоточение внимания на дневном прогрессе контрпродуктивно, поскольку люди деморализуются и / или уходят.

Я удивлен, что никто здесь еще не упомянул «отслеживаемые» или «помеченные» сообщения хранилища, встроенные в такие системы, как GitHub или BitBucket.

Наши технические заинтересованные стороны (руководители проектов, менеджеры по развитию и поддержке) все следят за нашей проблемой и фиксируют истории обновлений в своих соответствующих проектах. У нас небольшая команда (15 подрядчиков FTE +), но, похоже, это поможет нам

Никто не оценивает ни одну из этих вещей, но в дополнение к еженедельным отчетам о состоянии от премьер-министра, это дает ежедневное представление о проекте, чтобы, по крайней мере, держать всех в курсе, над какими областями ведется работа, поэтому никто не останется без наглядности.

Это также помогло повысить прозрачность для разработчиков и подрядчиков, а также для наших деловых кругов, что помогает каждому быть подотчетным в своих графиках поставок.

В сочетании с RSS-лентами, связанными с определенными репозиториями или во всей нашей организации, мы смогли ограничить количество электронных писем (там, где это необходимо) и предлагать аналогичный набор данных в режиме реального времени и в виде сводки через устройства чтения RSS. Для некоторых пользователей это Outlook, поэтому в основном это электронная почта для них, хотя и немного другая, но для других пользователей они используют полноценный RSS-клиент со всей дополнительной фильтрацией, необходимой для его настройки в соответствии с их потребностями.

Сначала мы столкнулись с похожими проблемами, связанными с объемом электронной почты, но наши конечные пользователи придумали систему RSS без необходимости в технической организации, кроме того, чтобы предлагать клиентам тех, кто не использует Outlook. Работали для нас, снова около 20-30 подрядчиков FTE + в течение года в нескольких офисах и часовых поясах. YMMV, очевидно.

Это очень незначительное дополнение (и оно не зависит от программиста), но у меня был хороший успех с Асаной в последних проектах.

Для интеграции с существующими онлайн-инструментами для совместной работы не стоит забывать о Slack . Он построен вокруг чата, но служит довольно минималистичным центром для других инструментов, включая Asana, GitHub и Bitbucket. Он имеет приличную коллекцию эти «интеграции,» как готовые и сообщества сделали , используя API , который, конечно , позволяет построить свой собственный.