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

61

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

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

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

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

Брайан Бруннер
источник
5
Об этом лучше спросить на рабочем месте.
Mattnz
39
@mattnz - я не знаю. Ответ будет значительно отличаться между программистом, баскетболистом и почтальоном.
Теластин
17
Это должно быть замаскировано в ежедневном приеме. Там, где я работаю, каждый из нас, разработчик, указывает, над чем мы сейчас работаем, и над чем мы будем работать завтра. Хитрость заключается в том, что участники не должны чувствовать, что их «отслеживают», если вы чувствуете, что разработчик отстает, НЕ поднимайте это в режиме ожидания, вместо этого держите этот разговор закрытым.
ЮСТДАН
5
@mattnz - Ладно, замените примеры бухгалтером и юристом. Или доктор и политик. Или сантехник и секретарь. В конце концов, нет единого ответа «как отследить, что делает команда профессионалов», потому что разные профессии нуждаются в разных подходах - и, следовательно, не подходят для рабочего места.
Теластин

Ответы:

108

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

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

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

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

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

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

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

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

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

Telastyn
источник
31
+1 Команды, которые не общаются, не являются командами и не выполняют работу.
11
Мне это нравится. «Вы там, чтобы устранить препятствия в их повседневной жизни. Вам нужна информация, чтобы сделать это». Мы могли бы быть лучше в этом, где я работаю.
Роберт Харви
33
Ух ты. Революционная! Должен ли я на самом деле говорить? Или я могу иметь приложение для этого?
andy256 9.09.14
7
@ Снеговик: Ваш комментарий - не что иное, как ложная банальность. За эти годы я участвовал во многих, разных командах и не видел, чтобы ваша банальность была ключевым фактором успеха или неудачи любой из этих команд. Некоторые команды были чрезвычайно эффективными и успешными в том, что касается успеха, делайте это, не мешайте мне (на самом деле, самые успешные команды, в которых я принимал участие, были именно такими). В то время как другие команды были полнейшими неудачами в общении по Инь-Ян.
Данк
5
RE: «Если у них нет проблем всю неделю? Проблема». - Может быть и так, что вы не подходите для решения проблемы. Может быть, другой разработчик, Интернет или что-то еще уже работает, чтобы устранить препятствие.
sixtyfootersdude
143

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

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

Роберт Харви
источник
27
К сожалению, у меня есть только один голос за это! «Если вы начнете измерять их ежедневно, они будут реструктурировать свою работу так, чтобы они всегда создавали заметные артефакты, которые вы могли бы видеть каждый день». Для сложных задач даже еженедельная контрольная точка (однонедельные спринты) может иметь такую эффект: в конечном итоге вы работаете, чтобы получить видимый результат, а не сосредотачиваетесь на решении реальных проблем.
Джорджио
4
Придет время, я проведу первый день, собирая низко висящие фрукты, чтобы поиграть в игру с числами. Посмотрите, как много мы сделали за один день! Я немного экономлю, так что в другие дни я могу с утра вырубить некоторые требования / отзывы, а затем провести остаток дня, работая над важными вещами.
6
Можно утверждать, что работа без заметного артефакта бесполезна для ваших клиентов и, следовательно, для вашей компании </ devil's адвокат>
Теластин,
14
@Telastyn: Очевидно, вам нужны заметные артефакты, чтобы быть полезными для ваших клиентов. Дело в том, как часто они нужны вам и вашему клиенту. Не существует общего правила, но слишком тщательный мониторинг процесса разработки может нарушить сам процесс, замедлить его и снизить качество результатов. В качестве провокационного примера, когда вы идете, проверяете ли вы, что вы движетесь в правильном направлении после каждого шага?
Джорджио
3
Я согласен с содержанием этого, но я не согласен, что это ответ на вопрос. Я отслеживаю ежедневный прогресс, но управление - это интерактивный процесс. Это взаимодействие я обычно оставляю на конец спринта. Даже если вы управляете статистикой высокого уровня, эта статистика создается путем сбора отдельных точек данных. Они волшебным образом не появляются на моем столе.
MSalters
9

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

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

Тем не мение:

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

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

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

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

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

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

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

Пит
источник
6

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

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

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

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

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

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

Петерис
источник
1
Мы (пытались) использовать idonethis в течение примерно 2 месяцев, это не сработало - потому что вам пришлось потратить некоторое время, чтобы перейти куда-то еще, и только для того, чтобы обновить свой статус, большинство из нас забыли о его существовании
Izkata
Я, конечно, использую наши системы отслеживания проблем и системы управления изменениями при составлении отчетов о том, чем я занимался в середине / конце года, и мы используем «панель управления» Jazz для управления деятельностью как отделов, так и проектов в целом. Встречи Scrum сообщают о том, над чем мы работаем в данный момент, но не сохраняют подробную историю. Я также считаю полезным для себя собрать небольшой инструмент командной строки, который позволяет мне быстро набросать для себя записку с одной строкой и меткой времени; это полезно для записи действий и деталей, которые не легко увидеть в других системах.
Кешлам
@Izkata Я чувствую то же самое по отношению к программному обеспечению для управления временем, которое я использую на своем текущем месте, в конечном итоге я установил напоминание, чтобы запускаться в 4 часа дня (для дней, когда я начинаю рано) и в 6 часов вечера (для дней, когда я начинаю поздно), чтобы напомни мне обновить систему. До сих пор я забыл гораздо реже обновлять систему. Возможно, стоит подумать, хотите ли вы продолжать использовать такую ​​систему.
scragar
5

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

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

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

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

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

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


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

  1. Вы могли бы предложить своему лидеру разбить задачи больше
  2. Если ваша работа блокируется или зависит от работы другого члена команды, не стесняйтесь проконсультироваться с ним об этом и при необходимости выполнить другое задание.
DoubleDouble
источник
1
Разбиение вещей на иерархию более мелких частей и отслеживание зависимостей между ними - это одна из вещей, которую хорошо умеет Jazz / RTC.
Кешлам
3

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

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

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

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

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

архиватор ARJ
источник
2

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

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

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

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

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

Майкл Даррант
источник
2

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

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

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

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

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

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

Bryan 'BJ' Hoffpauir Jr.
источник
4
ОП указывает, что они следуют дайджестам github, и это ошеломляет. По моему опыту, это очень поверхностный взгляд на вещи, который дает ложное чувство безопасности.
Теластин
2
Это достаточно верно, если вы будете следить за всеми действиями на GitHub. Если честно, мы используем BitBucket для нашей компании, и он, похоже, предлагает достаточно детальный контроль над уровнем обновлений электронной почты для наших небольших команд. Не уверен, что GitHub предлагает такой же уровень детализации, возможно, кто-то мог бы сравнить его с BitBucket, если они использовали оба, чтобы помочь определить конфигурацию и размеры команды, которые делают его подходящим? Будут ли следующие выпуски обновлений в GitHub действительно вызывать слишком много активности? Похоже, в BitBucket этого нет ... и этого достаточно для наших менеджеров и ведущих
Брайан 'BJ' Хоффпауир-младший
Добавлен комментарий о последних событиях, связанных с использованием RSS-клиентов (или даже Outlook в некоторых случаях), чтобы уменьшить объем электронной почты и позволить пользователям самостоятельно фильтровать свои данные, но при этом сохранять их как в режиме реального времени, так и в виде итога / конца дня / конца. недели, как они хотят. Кажется, хорошо работает для тех, кто не хочет, чтобы постоянный поток электронной почты добавлялся в их существующие почтовые ящики ...
Брайан 'BJ' Хоффпауир-младший
0

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

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

shadowtalker
источник
Я хотел бы знать, почему это было понижено. Я понимаю, что вопрос задает о «стратегиях», а не «инструментах», но разве «использовать хороший инструмент» не является жизнеспособной стратегией?
теневик
см. Как ответить . «Внимательно прочитайте вопрос. Что, в частности, задает этот вопрос? Убедитесь, что ваш ответ дает это - или жизнеспособную альтернативу ... Краткость приемлема, но более полные объяснения лучше ...»
комнат
Я пришел сюда, чтобы предложить использовать Slack . Это отличный инструмент для отслеживания того, что команда делает изо дня в день . Что, кстати, как раз и есть вопрос. Но, посмотрев на этот ответ и комментарии, возможно, я просто не понимаю, как работает programmers.stackexchange.com (хотя у меня много репутационных очков на других сайтах).
Денилсон Са Майя,
@gnat что еще вы хотели бы получить от этого ответа? Я не вижу здесь много того, что допускает «более полное» объяснение
shadowtalker