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

Да, лучшие 10% программистов умеют управлять собой. Это часть того, что делает их лучшими 10%. Но реальность такова, что в большинстве компаний программисты не входят в 10% лучших. Большинству программистов нравится притворяться, что они рок-звезды, заслуживающие особого отношения, но на самом деле большинство из них таковыми не являются.

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

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

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

Я думаю, что ваш лучший выбор, учитывая смехотворную свободу действий, которую вы им предоставили, — это начать с ежедневных стендап-встреч, которые должны посещать все, и основных часов, в которые все должны присутствовать (может быть с 11 до 3, не обязательно с 9 до 6). . Каждый день каждый человек должен встать и сказать, какого прогресса он добился накануне, какие проблемы у него есть в настоящее время и как это может повлиять на дедлайн. Вы получаете то, что ожидаете, и, честно говоря, вы ничего не ожидали.

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

Но также, вероятно, верно и то, что оценки времени неверны. Поэтому вам также нужно обратить внимание на то, как вы оцениваете задачи. Вы также должны понимать, что оценка времени сложна и что вам может потребоваться вести учет оценок по сравнению с фактическим временем, чтобы улучшить оценку. Групповые оценки также имеют тенденцию быть более реалистичными, поскольку переоценивающие, как правило, отвергаются недооценивающими. Чтобы получить эти данные, вам нужно указать время по задачам, чтобы вы могли сравнить его с оценкой. Сделайте простую систему отчетности, заполнение которой занимает не более 5 минут в день. И пусть они знают, что он используется для улучшения оценок будущих спринтов. Вам также может потребоваться специально изменить форму оценки времени, чтобы включить время на модульное тестирование, общение, контроль качества и исправление ошибок контроля качества, развертывание и т. д.

Теперь, поскольку вы отказались от своих обязанностей в качестве менеджера, у вас будет некоторое сопротивление тому, что является разумными ожиданиями. Ну, любой, кто не будет тратить пять минут на заполнение табеля или кто не может проводить ежедневные собрания (даже Agile-магазины делают это) и основные часы, в любом случае не тот, кого вы хотите нанять в долгосрочной перспективе. Это не необоснованные ожидания. Работа состоит не только в том, чтобы делать то, что вы хотите, когда вы хотите это делать, и если вы работаете в команде, вы не можете позволить примадонне (которая на самом деле всего лишь средний программист и вполне заменим) помешать вам выполнить свою работу. .

у меня тут несколько мыслей

1. Вы думаете, что лидируете, но лидирует ли команда?Причина, по которой я спрашиваю, заключается в том, что однажды я заключал контракт с компанией, где мой менеджер прямо сказал мне, что все разработчики были на одном уровне, но один из разработчиков считал себя ведущим, когда дело доходило до одной проблемы и одной проблемы. только — он хотел, чтобы все использовали пробелы вместо табуляции и ставили комментарии после строки кода, а не над ней. Никто из других разработчиков этого не поддержал, но он счел себя вправе настаивать на том, чтобы мы это сделали (и отказался обсуждать этот вопрос). Однако, когда лидерство действительно было необходимо, его нигде не было. Например, он попросил меня стать владельцем подсистемы и отказался принимать чью-либо сторону, когда другой разработчик хотел вырвать мою хорошо спроектированную систему для чего-то, что, по IMO, было менее ремонтопригодным. Так что в данном случае я проигнорировал его "руководство" по форматированию кода. Ведите, следуйте или уходите с дороги, но не настаивайте на лидерстве только тогда, когда это что-то тривиальное/глупое. Кроме того, убедитесь, что вы действительно занимаете руководящую роль, которую, как вам кажется, вы занимаете.
2. Существуют ли другие факторы, влияющие на их оценки, которые находятся вне их контроля? Ваши разработчики обременены кучей дрянного кода, который нужно поддерживать/дорабатывать? В таких условиях невозможно хорошо оценить. Возможно, по какой-то причине (и будем надеяться, что это не вы) вашим разработчикам не позволяют устранять болевые точки, когда они встречаются. Если им мешают устранять основные проблемы, и они чувствуют, что их ноги держат в огне, чтобы соответствовать оценкам, которые никто не может сделать точно, тогда они будут неохотно излагать это в письменной форме, что это то, что происходит. .
3. Достаточно ли вы делаете, чтобы убедиться, что препятствия устранены? Я обнаружил, что в компаниях, которые заявляют, что обвинять неприемлемо, это означает «не поднимайте шум, когда вы не получаете необходимых ресурсов», а не «вас не будут обвинять, если вы не можете добиться успеха». сроки, потому что кто-то не дал вам то, что вам нужно». Следите за экспертами в предметной области, дизайнерами и т. д., которые находятся на более высоком уровне, чем ваши разработчики. Когда ресурс не поступает по расписанию, он может иметь огромноевлияние даже на разработчиков, которые могут переключать задачи в ответ. Кроме того, я обнаружил, что некоторые дизайнеры понятия не имеют, что я делаю с файлом, когда он покидает их руки, поэтому их работа требует дополнительного времени. Многие разработчики не примут это во внимание, особенно если это неприемлемо для вашей команды, или если они никогда раньше не работали с этим дизайнером.
4. Действительно ли разработчики срывают сроки? Я был в ситуациях, когда спецификации были действительно туманными, и мои просьбы о разъяснении не были встречены с большим ответом. Как только что-то было создано, появилось больше требований, и о них сообщалось как об «ошибках» по сравнению с функциями, которые я уже создал, а не как о новой функциональности. Кроме того, каждый может настаивать на том, что способ, который, по словам разработчика, будет наиболее трудоемким, является единственным способом его создания. Как только люди увидят это, они решат, что в конце концов это было нехорошо, и захотят вернуться и построить это каким-то другим способом. Создание функции дважды — это создание двух функций, и вы должны видеть это таким образом.

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

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

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

Вы затрагиваете много разных вопросов в вопросе.

Цель

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

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

Знание работы

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

Более того, они веселые. Это означает, что обычно довольно легко представить их в команде. Хитрость, однако, заключается в том, чтобы заставить людей работать с доской последовательно. Собственно, самый большой риск работы с платой в том, что она не обновляется . Разница между инструментом управления задачами, тайм-трекером и доской задач/канбан заключается в том, что в последнем случае вы узнаете о новых задачах с доски, поэтому все равно идете туда — появляется естественный стимул обновлять задачу при изменении ее статуса.

Управление командой

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

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

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

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

Награды

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

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

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

Еще хуже, если вы основываете вознаграждение на работе, проделанной членами команды индивидуально, вы не поощряете помощь, копание в проблемах и совместную работу. Если я сделаю 90%, я, скорее всего, буду бороться с остальными в одиночку, вместо того, чтобы просить о помощи (даже если это будет самое разумное и эффективное действие), поскольку я боюсь, что это не будет «моим» успехом, а "наш". Другая точка зрения может заключаться в том, что я не желаю помогать, поскольку у меня есть своя собственная работа, и я не уверен, что то, о чем вы меня спрашиваете, не является чем-то вроде болота, в котором я потрачу много времени впустую.

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

Я хотел бы отметить, что, хотя вы использовали некоторую терминологию Agile/Scrum (спринты, оценка) и указали, что вы не используете ежедневные стендапы, тем не менее, некоторые аспекты того, что вы делаете, кажутся более командными/контролирующими (« Ставлю задачи разработчикам/выношу или ставлю задачи..")

Если вы хотите иметь самоорганизующуюся команду, которая (более критично) выявляет и устраняет свои собственные недостатки (например, выполняет 50-60% работы в спринте), то вам, вероятно, придется пойти дальше по пути Agile/Sprint. , что означает дать команде больше контроля.

Ключевыми моментами будут:

• команда должна установить свои цели спринта (а не вы)
• команда должна вместе оценивать (а не отдельные лица)
• команда должна следить за своей производительностью (а не за вами)

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

Я подозреваю, что из того, что вы сказали, вы сочтете потерю контроля весьма пугающей. С моей стороны:

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

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

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

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

Незаполнение простой карты учета рабочего времени не связано с тем, что вы являетесь разработчиком. Это приходит только от понимания того, что это необходимо. Если вы являетесь подрядчиком правительства США, это необходимо. Они могут делать по запросу проверки табель учета рабочего времени. Большинство компаний в настоящее время установили автоматизированные системы, которые отправляют электронные письма, если они не заполнены до полуночи каждый день.

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

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

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

Я также оспариваю ваше заявление о том, что вы не "PHB". Вы управляете 10 разработчиками, но по-прежнему назначаете индивидуальные задачи для всех разработчиков. Это кажется мне слишком большим количеством микроменеджмента. Я бы подумал о том, чтобы позволить разработчикам самим решать свои проблемы и организовывать их между собой. Мой опыт показывает, что разработчик будет чувствовать себя более ответственным за проблему, если он или она выберет ее, а не поручит ей. Попробуйте сделать оценки на групповом сеансе планирования, а не раздавать их отдельным лицам, как вы делаете сегодня. Опять же, по моему опыту, это сделает оценки более точными и с меньшими отклонениями с течением времени. Это также укрепит ощущение того, что вы работаете как команда, а не как группа отдельных лиц на организационной схеме.

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

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

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

Сейчас в этом стендапе, как руководитель проекта, ты не являешься активным участником. Вы курица". Разработчики и любой ваш бизнес-аналитик или персонал QA — «свиньи». Аналогия взята из анекдота:

Свинья и курица идут по дороге. Цыпленок говорит: «Эй, Свинья, я подумал, что нам следует открыть ресторан!». Свин отвечает: «Хм, может быть, как бы мы это назвали?». Цыпленок отвечает: «Как насчет ветчины и яиц?». Свинья на мгновение задумывается и говорит: «Нет, спасибо. Я бы согласился, но ты бы только участвовал!»

В результате вы «вовлечены» в процесс, но члены команды — это те, кто «привержен» выполнению работы. Стендап — это их инструмент, чтобы убедиться, что они могут что-то сделать, и поэтому им управляют они, а не вы. Ваше единственное требование — убедиться, что он у них есть, и, при необходимости, убедиться, что он не растворяется в большом обсуждении (стендапы должны длиться максимум 5-10 минут). Это может быть сложной концепцией для менеджера, но вы, кажется, в парадигме самоуправляемых команд, так что, надеюсь, это будет более легкий переход.

Другие советы:

• Сделайте оценку проекта во время встречи всех разработчиков. Это совещание по оценке и планированию спринта имеет основополагающее значение, и его корпоративное проведение гарантирует получение всех оценок; человек прямо здесь, и вы должны запрашивать оценки небольших фрагментов с четко определенным объемом; разработчику никогда не следует назначать «эпический» (большой, сложный проект) без его предварительного разделения на более мелкие части. Как съесть слона? Один укус за раз.
• Неважно, сколько времени они тратят (если только они не работают по 12 или 3 часа в день); важно то, сколько они делают каждый день, и помогает ли это им выполнять свои обязательства. Если, проработав два 8-часовых дня, они находятся на пути к тому, чтобы отклониться от своей первоначальной оценки наполовину, то происходит одно из двух: они откусывают больше, чем могут прожевать, или они бездельничают и не выполняют свою работу. Переоцените рабочую нагрузку для спринта и, если она все еще кажется выполнимой, удерживайте ее.
• Обычно лучше иметь команды, каждая из которых работает над одним проектом. Команда не должна состоять из одного человека, работающего над проектом А, и другого, работающего над проектом Б. Даже если А и Б являются подпроектами суперпроекта С, команды, тянущиеся в разные стороны, в конце концов распадутся. Команды могут состоять из одного человека и, как правило, хорошо работают до дюжины (после этого обычно хорошо разделить большие команды на более мелкие).

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

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

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

Я вижу пару проблем.

Во-первых, кажется, что ваши «задачи» слишком велики. Разбейте их на более мелкие части — предпочтительно те, которые должны быть выполнены за один день.

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

Главное, чего я хочу здесь, это то, что если команда не может правильно оценить задачи, которые длятся дольше одного дня, нам нужно их обучить. Лучший способ добиться этого — попросить их оценить небольшие задачи. Одно из дополнительных преимуществ заключается в том, что людям нравится показывать прогресс. Во-вторых, если у вас есть люди, которые постоянно не могут выполнить простые задачи за один день, вы знаете, кого заменить. Кстати, «творческий» не означает «когда они до него доберутся».

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

Есть еще, но я думаю, что это то, где вам нужно начать.