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

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

Разработчики программного обеспечения могут быть продуктивными только в том случае, если у них есть много времени «в зоне». Прерывания — это вещь номер один, которая может убить продуктивность и моральный дух разработчиков. Если вы постоянно находитесь в режиме прерывания, когда вы прерываете их для какого-то нового запроса, то вы, вероятно, делаете это неправильно.

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

Думали ли вы о том, чтобы решить, какую часть времени вы хотите потратить на техническое обслуживание и новую разработку, а затем назначить своим разработчикам соответствующий график? Например, если вы хотите тратить 25% своего времени на обслуживание/поддержку и 75% своего времени на новую разработку, у вас есть несколько вариантов: вы можете назначить каждому разработчику одну неделю в месяце, когда он находится на обслуживании/поддержке. и 3 недели месяца, когда они находятся на новой разработке. Когда приходит новый запрос на поддержку/обслуживание, он помещается в очередь, ему назначается приоритет, а затем, когда разработчик запланировал время для обслуживания/поддержки, он начинает извлекать самые высокие элементы из очереди, пока не истечет запланированное время.

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

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

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

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

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

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

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

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

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

Книга Дэвида Андерсона «Канбан» исследует эти концепции более подробно и настоятельно рекомендуется.

Немного неясно, спрашиваете ли вы об оценке или о расстановке приоритетов.

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

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

Но сначала давайте поговорим о том, что вы можете сделать.

Откуда берется эта незапланированная работа?

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

Как избавиться от незапланированной работы?

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

Измерение незапланированной работы не принесет вам пользы

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

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

Итак, как мы оцениваем, учитывая всю эту неизбежную незапланированную работу ?

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

• Детализируйте и планируйте свои итерации в деталях. Это не займет много времени, если у вас есть приличный инструмент PM. Если применимо, разбейте задачи на часовые задачи. Это позволит избавиться от многих «незапланированных» вещей.
• Отдавайте предпочтение рискованным вещам. Когда вы разбиваете вещи на мелкие кусочки, вы сразу видите, в чем заключается ваша неуверенность. Это те задачи, которые вы на самом деле не знаете, как разбить дальше, и что вы не совсем уверены в том, сколько времени они вообще займут. Начните с них, если это возможно. Таким образом, ваша оценка по-прежнему будет ошибочной, но значительно стабилизируется по мере продвижения вашей итерации. Вы не обнаружите, что в последние пару дней итерации внезапно осознаете, что вам нужно еще 10 дней, чтобы закончить то, что вы начали.
• Обсудите с менеджерами проекта/продукта работу над наиболее распространенным внешним источником незапланированной работы. например, сэкономит ли улучшенная документация вашим инженерам много времени, объясняя вещи инженерам на местах или клиентам? Затем попросите выделить на это время в рамках усилий по разработке.

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

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

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

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

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

Как я уже сказал, он ни в коем случае не идеален, но он хорошо работает для нас.

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

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

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

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

Используйте Канбан-доску и обязуйтесь каждый день выполнять от 3 до 4 задач в рамках поддержки, а остальное время использовать на разработку.

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

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

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

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

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

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

Процесс

1. Модульное тестирование — покрытие кода более 90%. Это позволит вашей команде исправлять ошибки и вносить изменения в систему, не беспокоясь о том, что что-то еще сломается. Это сэкономит ваше время, будучи автоматизированным и тщательным, а не ручным тестированием.
2. Непрерывная интеграция — автоматический запуск нового кода. Я не вижу, являетесь ли вы веб-компанией или нет. Несмотря на это, есть способы запуска кода в работающий продукт буквально через секунду после его завершения.
3. Управление задачами — измеряйте прогресс по мере выполнения. Использование одного из них гарантирует, что каждый разработчик, вы и любые другие менеджеры смогут в режиме реального времени точно видеть, что делается и кто за что отвечает. Существует несколько систем и множество адаптеров плагинов для многих IDE, в частности для Eclipse.
4. Точные оценки - при оценке времени спросите у разработчика, или все время, не делайте это самостоятельно как руководитель проекта. Не требуйте, чтобы они давали вам ответ немедленно, дайте им 1 день или больше. Если вы этого не сделаете, они бессознательно попытаются угодить вам и не смогут точно оценить, так как не продумали всех деталей реализации. Сделать торт легко за 2 часа, но при условии, что у вас есть все ингредиенты, посуда и т. д.

Культура

1. Каждый раз, когда команду сокращают, это происходит из-за «неоправдания ожиданий». У людей выше/рядом с вами явно непонимание того, на что способна ваша команда. Вы должны научить их. Наличие системы управления задачами поможет в этом. Он научит их, сколько времени требуется для выполнения данной задачи, и покажет им, что делается в данный момент. Многие люди за пределами отдела предполагают, что у отдела есть 10+ часов. за неделю «открытого времени». Покажите им, что это не так.
2. Планирование проекта должно осуществляться небольшими шагами, с расчетом на то, что 1/3 или более команды будет потрачена на другие дела. Чем дальше вы планируете проект в будущем, тем менее точной будет эта оценка. Я предпочитаю планировать на ежемесячной основе или меньше.
3. Приоритизируйте входящие запросы. Мне нравится создавать «корзину идей» и «список следующей версии» для запросов функций. Корзина идей хороша для общих идей, которые либо не являются критически важными для бизнеса, либо требуют много времени для реализации. Список следующей версии позволяет вам сократить масштаб. Если у вас есть 1 месяц на завершение данного проекта, время уходит на другие дела, вы можете перенести некоторые из менее важных функций в список следующей версии .
4. Сосредоточьтесь на обратной связи от одного отдела за раз. У любого проекта есть время на ввод в эксплуатацию, а наличие 3+ отделов, запрашивающих функции одновременно, означает, что много времени тратится на ввод в эксплуатацию, а не на запуск кода. Я обнаружил, что очень эффективно сосредотачиваться на запросах 1 отдела каждые 4 недели. Один месяц на продажи, следующий месяц на маркетинг, следующий месяц на редакцию и т. д.
5. Наймите специального сотрудника службы поддержки, даже если это стажер. Время вашего разработчика очень ценно, его нельзя прерывать, так как это выводит его из потока (режим глубокого размышления) более чем на 15 минут каждый раз, когда его просят сделать что-то новое. Разработчики умеют писать код, и у них должна быть среда, которая позволяет им это делать.
6. Сделать вики. Эта вики позволит вам и вашей команде публиковать все, что требует более 4 предложений для объяснения. Ваш ответ по умолчанию на любой вопрос теперь будет выглядеть так: Вы проверили вики? Это сэкономит время, поделится информацией и сделает всех счастливее.

Удачи!

Мы применяем два метода, чтобы взять это под контроль:

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

Затем мы делим эту емкость на фиксированные ведра : наша

• 60% Запланированное развитие : утверждены опытно-конструкторские работы по созданию нового материала (инвестиции); с этими 60% доступной мощности вы можете составить план, когда все эти новые материалы будут доставлены как можно раньше (если 60% будут сохранены).
• 20% специальных запросов клиентов : небольшие изменения и специальные конфигурации
• 20% поддержка и обслуживание

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

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

• требовалось больше поддержки, и в результате одобренные запросы клиентов выстраиваются в очередь, поэтому на следующий период мы будем выделять 30% на запросы клиентов и только 50% на разработку. Это повлияет на выполнение запланированной разработки, поэтому она перепланируется, а воздействие утверждается.
• это был низкий период для поддержки (редко, но бывает :-) ) поэтому мы добились некоторого прогресса в запланированной разработке, поэтому либо мы идем по договоренности (60-20-20), чтобы остаться с опережением, либо мы выполнить дополнительную работу по запросам Заказчика.

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

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

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

Это работает хорошо для нас. Удачи!

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

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

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

• Выделите одного или двух разработчиков для поддержки работы и меняйте их на регулярной основе, если только у вас нет людей, которые действительно хотят оказывать поддержку все время. Преимущество этого заключается в том, что очень ясно, сколько времени уходит на поддержку задач. Если вы выделяете 2 из 6 разработчиков для поддержки, и оказывается, что этого недостаточно, вы, по крайней мере, осознаете тот простой факт, что поддержка съедает 50% или более вашего времени разработки.
• Неукоснительно используйте WIP-лимиты. Жетоны/линии экспедиции — это здорово, но их нужно ограничивать, иначе все получается очень срочно. Убедитесь, что WIP-лимиты соответствуют действительности. См. предыдущий пункт о том, как определить эту реальность.
• Попытайтесь выяснить, последовательно ли развертывается ваш код, пока он все еще содержит ошибки, и исправьте это. Срочная работа — это факт жизни, если/когда есть давление, но обычно вы в конечном итоге расплачиваетесь потом. Перед лицом перегретых маркетологов, требующих немедленного внимания, мой единственный совет — сохранять хладнокровие и спокойствие, но строго придерживаться распорядка «работа, которую стоит делать, стоит того, чтобы делать ее правильно».
• Если в конце концов выяснится, что вы живете в корпоративной культуре, где скорость всегда важнее качества, вернитесь к моему первому пункту. Назначьте одного или двух разработчиков для поддержки, чередуйте их и занимайтесь действительно срочными вещами. Если бэклог начинает заполняться, объясните руководству, что вы уже тратите 1/3 своего времени на поддержку и, возможно, просто возможно, вы можете начать менять корпоративную культуру.

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ. Опубликовано автором вопроса и перемещено в ответ CW.

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

У Дэвида Эспины было несколько хороших моментов, когда он сказал: «Разработка графиков может сдвинуться, и никто не умрет. Попытка контролировать вашу реакцию на поддержку и кто-то умрет ... в переносном смысле, конечно». -- Это проблема для нас, работа по поддержке должна быть сделана, нравится это нам, разработчикам, или нет.

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

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

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

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

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

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

Первое практическое правило — рассказать историю с помощью данных. Сколько времени вы тратите на поддержку? Если не знаете, начните мерить. Здесь могут быть более глубокие проблемы, и вам нужны данные, чтобы рассказать историю.

1. Пусть каждый член команды посвящает несколько часов в каждом спринте поддержке. Например, каждый член команды выделяет 5 часов на спринт для работы над проблемами поддержки. Хитрость здесь заключается в согласовании приоритетов внутри команды. Создавайте SLA/рабочие соглашения о том, как будет управляться поддержка. Например, любая проблема с приоритетом H будет включена в текущий спринт. Заявки со средним приоритетом будут рассмотрены в следующем спринте. Измеряйте время цикла проблем поддержки по приоритету, чтобы определить объем и требуется ли больше или меньше времени для каждого спринта.

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

3. Создайте группу быстрого реагирования — работает лучше, если у вас есть большой объем запросов в службу поддержки/вопросов пользователей, на которые необходимо ответить. Работает следующим образом. 2 члена, как правило, пара dev/QA, не поручают никакой новой работе в данном спринте. На протяжении всего спринта они немедленно реагируют на любой поступающий тикет и адресуют его. Для тех проблем, которые требуют больше усилий, работа имеет приоритет как рабочий продукт (история или дефект) для предстоящего спринта.

Надеюсь, это поможет и даст вам некоторые идеи.

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

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