Как мне представить свою работу, если я постоянно сталкиваюсь с неожиданными препятствиями?

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

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

Пример:

Вчера я столкнулся с этим препятствием, связанным с этой технической темой.

Я учу то, то и это.

Сегодня я продолжу реализовывать эту функцию.

Мы пытаемся вовремя не фиксировать, просто констатируя факт: «Я работаю над этой фичей» вместо «Эта задача будет сделана завтра».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, если проблемы, с которыми вы сталкиваетесь, вызваны ошибками в используемой вами библиотеке, вы можете сказать:

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

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

Еще один момент о стендап-встречах: они предназначены не только для обсуждения статуса, но и для обмена информацией (например, о проблемах с библиотекой X, описанной выше), а также для просьбы и предложения помощи. Стоит сказать, когда вы сталкиваетесь с проблемами: «Если у кого-то здесь есть какие-либо мысли о том, как лучше с этим справиться, пожалуйста, свяжитесь со мной после встречи, чтобы мы могли обсудить детали». (Это особенно верно, если вы недовольны своими методами смягчения последствий; может быть трудно придумать хорошие, и другие в группе могут дать хороший совет по этому поводу или даже захотят поработать над этим.)

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

Не будь. Стендап-встречи — это не обзор производительности. Они предназначены для передачи статуса.

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

Вы просто коротко передаете статус в понятной для всех форме.

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