Как определить, что это такое и что с этим делать
Хьюстон у нас проблема
Работа в стартапе иногда может казаться переходом от одного костра к другому. Вы никогда не поймаете перерыв, и часто одновременно происходит несколько пожаров. Постоянное тушение пожаров может привести к тому, что ваша команда будет чувствовать, что они все время крутят колеса и играют в догонялки.
В этой статье я расскажу об уроках, которые я усвоил за последние несколько лет, и о том, как я создал некоторую структуру, чтобы предотвратить перегрузку команды внешними запросами.
Наиболее ярким симптомом постоянной необходимости тушить пожары является то, что ваши задачи спринта, которые были включены во время планирования, никогда не выполняются, когда вы этого ожидаете. Иногда в худшем случае ни у кого не было времени даже начать рассказ!
Этого можно ожидать в зависимости от стадии вашей компании и мандата вашей команды. Однако, по моему опыту, командой разработчиков, которая тратит большую часть своих усилий на поддержку существующего программного обеспечения, сложно управлять, и текучесть кадров неизбежно будет высокой. Это еще больше увеличивает время между обнаружением ошибки и ее исправлением.
В этой статье мы будем исходить из того, что ваша команда не может работать над новыми функциями и активно улучшать технический долг. Я видел неспособность справиться с непредвиденными проблемами в нескольких командах, и реакция на эти проблемы может варьироваться от «давайте все перейдем к совещанию» до «давайте проигнорируем это до следующего спринта». Обе эти крайности создадут дополнительные проблемы в будущем.
Что на самом деле имеет высокий приоритет
Если все срочно, ничего не срочно. — Патрик Ленсиони
Вы наверняка уже слышали это клише. Я часто повторяю это своей команде, и разным людям нужны разные вещи. По этой причине вашей команде нужно будет разработать некоторые рекомендации, прежде чем двигаться дальше.
Давайте рассмотрим эти шаги и то, как их можно интегрировать в вашу команду. Это предполагает, что команда в настоящее время использует некую разновидность Agile со спринтами.
- Сформируйте консенсус относительно того, что представляет собой вопрос с приоритетом 1 (P1s) и вопрос с приоритетом 2 (P2s)
- Сформируйте процесс таким образом, чтобы новые заявки не требовали сортировки всей командой, а только подмножества команды.
- Отделить внутреннюю работу высокоприоритетного процесса сортировки дефектов от других команд.
- Групповое соглашение о том, какой технический долг должен быть приоритетным, чтобы срочные P1 и P2 не перегружали команду
- Если P1 выходят из-под контроля, рассмотрите возможность исправления ошибок, чтобы решить P2 и высокоприоритетные технические долги, чтобы уменьшить шансы на появление P1.
- Как только команда поймет, что следует включить в спринт помимо планирования, позвольте любому подать заявку, но убедитесь, что они упоминают об этом во время ежедневной схватки или стендапа.
В качестве отправной точки попросите команду договориться о том, что является высшим приоритетом. Для меня высокоприоритетный билет — это то, что не позволяет большому количеству клиентов получить доступ к базовым функциям. Например, классический пример P1 заключается в том, что ни один пользователь не может войти в систему.
По мере того, как вы будете двигаться вниз по шкале срочности и масштаба, вам придется где-то провести отсечку. Отсечка может зависеть от того, сколько пользователей затронуто, и от его последствий. Например, если некоторые участники не могут использовать ключевую функцию продукта, это будет иметь более высокий приоритет, чем если бы все участники не могли использовать второстепенную функцию. Чтобы сделать еще один шаг вперед, я бы сказал, что обе эти проблемы не являются приоритетными.
Затем попросите внешних участников зарегистрировать тикет против команды. Этот процесс предотвратит многие бэкдоры, которые приводят к потере билетов. Поначалу это может показаться слишком трудоемким, поскольку инженеры из разных команд могут быстро решить мелкие проблемы, не привлекая других.
Однако это может ошеломить инженеров, обладающих знаниями во многих областях продукта. Вместо этого наличие постоянного списка невыполненных задач в спринте в порядке приоритета устранит узкие места для конкретных членов команды. В то же время продукт и менеджер будут иметь более четкое представление о том, какие проблемы влияют на команду.
Когда у команды есть хороший процесс для обработки входящих проблем во время спринта, пришло время определить, соответствует ли количество времени, посвященное этим проблемам, тому, чего хочет команда. Конечно, количество времени будет сильно различаться в зависимости от типа продукта и того, насколько он может быть устаревшим. В следующих нескольких разделах мы обсудим некоторые приемы, позволяющие справиться с этим.
В качестве примечания: если ваша команда использует скрам и кажется, что он не работает, сейчас самое время пересмотреть, как можно изменить некоторые из ваших процессов, чтобы справляться с прерываниями. Я не буду слишком расходиться и углубляться в Agile и его философию здесь. Вместо этого я углублюсь в эту тему в другой статье, чтобы показать, как переход от схватки к канбану — это один из способов борьбы с необходимостью постоянно перемещать тикеты из одного спринта в другой из-за непредвиденных проблем в середине спринта.
Стартапы на ранней стадии
Когда генеральный директор и технический директор работают в тесном контакте с командой разработчиков продукта, многие отдельные участники будут хвататься за самые последние новости, исходящие от руководителя, независимо от того, насколько они малы или велики.
Я видел что-то настолько тривиальное, как сообщение об ошибке в журналах в течение длительного периода времени, которому разработчики придавали приоритет, потому что технический директор заметил и упомянул об этом при исследовании другого элемента.
На ранней стадии запуска привратнику этого процесса часто приходится делать много трудных выборов, отказываясь от некоторых фантастических функций, чтобы создать еще лучшие. Кроме того, время от времени команде придется откладывать некоторые важные технические долги. Тот, кто сделает последний звонок, должен будет достаточно знать о текущих проблемах клиентов, технологическом стеке и болевых точках разработки, а также о будущих важных функциях, чтобы выбирать и выбирать.
Когда я был единственным инженером-менеджером в компании, мы с техническим директором постоянно обсуждали расстановку приоритетов для наших инженерных команд. Многие из этих решений мы принимали вместе, а окончательный вердикт выносил он, если мы не соглашались. Однако, как только мы вошли в ритм, наше решение о том, включать что-то в спринт или нет, почти всегда было одинаковым.
Стартапы на поздних стадиях и не только
По мере того, как компании выходят за рамки одной команды, возникают некоторые проблемы с клиентами, которые трудно точно определить, из какой части технологического стека возникает проблема. В некоторых компаниях есть централизованное место для сортировки ошибок, но ни одна команда не может знать внутреннюю работу продукта, когда над ним работают десятки, если не сотни инженеров.
Я не сталкивался с серебряной пулей для решения проблем для больших систем, потому что поток данных и архитектура больших систем имеют уникальные проблемы. Однако я обнаружил, что составы команд играют большую роль.
Вот некоторые из способов, которыми я видел это:
- Буферная команда между поступающими проблемами и командой, разрабатывающей продукт (т. е. команда поддержки против команды продукта).
- Добавление необходимой гибкой комнаты для учета сбоев, таких как заполнение спринта только до 70% мощности.
- Переключайтесь между командами или отдельными членами, позволяя сосредоточить сбои и равномерно распределить нагрузку.
Я обнаружил, что третий вариант наиболее продуктивный в большинстве ситуаций. Отсутствие выделенного ресурса иногда может оставить высокоприоритетные исправления без внимания, поскольку все остальные уже заняты незавершенными задачами. Ротация также позволяет каждому участнику испытывать болевые точки в системе и проводить более плодотворные обсуждения между командами для решения вопросов технического долга.
Даже если над продуктом работает несколько команд, ротация все равно может работать, если у команд есть рабочее соглашение о том, как проблемы верхнего уровня сортируются между командами.
По мере роста компании генеральные директора и другие руководители будут все больше отдаляться от повседневных операций. Тем не менее, они будут продолжать просить об исправлении конкретных функций или ошибок. Тем не менее, оставайтесь верны своему новому процессу с четкими объяснениями принятых решений. В большинстве случаев решение и обоснование должны быть сообщены руководителю лично или по электронной почте, поскольку вряд ли он прочитает спринтерские билеты.
Подумайте о своем текущем процессе
В этой статье я рассказал о своем опыте, чтобы команда не тратила все свое время на реагирование на проблемы. Как и в любой другой разработке программного обеспечения, ваши компромиссы зависят от команды и продукта.
Когда ваша команда примет более строгий способ контроля того, что может участвовать в спринте, назначьте водителя, который возьмет на себя ответственность за вынесение суждения о том, следует ли что-то включать в спринт. В зависимости от того, как ваша команда принимает решения о приоритете заявки, это может быть технический менеджер, менеджер по продукту или скрам-мастер.
Соберите отзывы от команды о принятых решениях. Благодаря четкому процессу и практике команда научится быстро и эффективно сортировать эти отвлекающие факторы без ущерба для скорости или потребностей клиентов. Отвлекающие факторы, отвлекающие команду от запланированной работы, бывают самых разных форм и форм; ваша команда должна быть в состоянии разработать хорошее представление о том, что срочно, а что нет.
В моей следующей статье я расскажу о том, как наша команда перевела наш agile-процесс со скрам-вдохновленного на канбан-вдохновленный, что еще больше облегчило проблему, позволяющую самой последней проблеме или сбою сорвать работу команды.
Спасибо за прочтение!
