Как преодолеть конфликты между бизнес -аналитиками (управление продуктами), программисты и QA (P)
Команды по разработке программного обеспечения состоит из людей, которые могут иметь разные менталитеты, происходят из разных сред, имеют разные навыки и опыт и т. Д. Часто появляются конфликты и горячие дебаты, тем самым достигая напряженных моментов, чтобы быть частью ежедневной работы. Ключ заключается в том, чтобы определить области, где могут возникнуть проблемы, и найти для них четкие решения, экономить время, энергию и нервы, а также помочь команде работать вместе. В идеале, не было бы недоразумений, но если это произойдет, нам нужно найти способы решить и прояснить их. Вот некоторые примеры конфликтов, а также решения, с которыми мы столкнулись в Cognyte.
1. Это не ошибка, но это даже не функция.
Один из членов команды QA обнаруживает и поднимает ошибку (ошибка программного обеспечения) в JIRA (инструмент отслеживания проблем и управление проектами).
Ведущий команды: Это работает хорошо. Я не понимаю, почему вы говорите, что это ошибка. Это было указано, что это должно работать.
QA: На самом деле, это сценарий, который вы не рассмотрели, когда написали код. Клиент прислал нам несколько сценариев, которые они используют, и, к сожалению, он не работает с тем, что мы их доставили.
Программист: Хорошо, я могу понять, что есть новые сценарии, но нам не сказали, когда были сделаны спецификации. Для нас есть что -то новое.
QA: Я понимаю, к сожалению, эти сценарии поступают от клиента, и им нужны эти функции. Давайте посмотрим, что говорит аналитическая бизнес -команда.
Бизнес -аналитик: Я понимаю, что вы говорите, кажется, я не рассматривал сценарии. Каковы оценки этих изменений?
Программист: Мы оцениваем 200 часов работы, и нам придется повторить то, что мы делаем сейчас, потому что ясно, что у нас будут задержки.
Бизнес -аналитик: Хорошо, я понимаю. Давайте поговорим, чтобы мы могли найти решение.
Ответ, который может раздражать тех, кто из QA, а иногда и клиенты: «работает в соответствии со спецификациями». По сути, это означает, что продукт работает в соответствии со спецификациями, но не полностью отвечает потребностям клиента. Мы можем измениться, но мы должны учитывать затраты: часы, которые задержит другие разработки в ухудшении нескольких систем (особенно когда речь идет о сложном продукте, богатых данных, компонентах и интеграциях, а также активных пользователей по всему миру).
Мы определенно можем внести необходимые изменения, но мы также должны принять во внимание затраты, которые они связаны. Существует сверхурочное время, чтобы иметь в виду, тогда могут быть неблагоприятные последствия, возможно, влияние на другие области продукта, которые могут сделать другие функции больше не идти. Это очень возможно, когда мы говорим о сложном продукте, со многими компонентами и интеграциями, со значительным объемом данных, клиентов со всего мира и особенно индустрии нулевой терпимости (нулевая терпимость к простоям), как мы имеем в Cognte.
Все эти аспекты должны быть рассмотрены.
Важно понимать, что мы не говорим о «обвинительной игре». Мы никому не показываем ваш палец. Если команда QA поднимается и, наконец, подтверждает ошибку, это только после консультации с командой программистов. Если, с другой стороны, это более сложная проблема, то также называется Busizins (бизнес -аналитик), тот, который ведет продукт с функциональной точки зрения.
Что такое яЭто происходит, когда все правы?
Важно понимать, что любое изменение имеет стоимость, что не всегда легко оценить. Только те, кто знает, как работает вся система, ее инфраструктура и возможное влияние, могут оценить реальную стоимость реализации сложных изменений. И даже в этих случаях в оценке нет безопасности. Оценка — это просто … оценка. Наконец, решения о реализации новых требований зависят от приоритетов, и здесь участвует команда по управлению продуктами (управление продуктами). В особых случаях решения также могут достигать C-уровня. Однако перед каким -либо решением мы инициируем открытое обсуждение, когда все вовлеченные стороны могут придумать плюсы и минусы, пытаясь принять решение, которое поможет нам в будущем, как с точки зрения нынешнего клиента, так и других существующих или потенциальных клиентов.
Обсуждение этого типа может привести к двум результатам: либо новое требование будет решено как фиксированная ошибка, либо мы решим, что это ограничение текущей версии, и мы будем реализовать ее в будущей версии.
Еще один подход, который у нас есть,-это определить план тестирования, согласованный с командой QA, прежде чем начать код (тестовое развитие). Это помогает четко определить ожидания и позволить программистам знать, какие сценарии будут проверены, чтобы они могли написать код как можно более правильным. Кроме того, план испытаний утвержден командой, которая координирует функциональные требования. Этот метод помогает уменьшить ошибки и обеспечивает хорошее согласование между командами с точки зрения понимания новых требований.
2. Основные изменения или незначительная коррекция?
Мы упомянули, что наши продукты сложны. Некоторые из них настолько сложны, что новая версия может возникнуть только один раз в четверть или даже меньше, иногда через шесть месяцев или даже больше. Даже обновление версии на внутренних платформах (локально) является значительным процессом. Это не просто «нажмите на кнопку». Тем не менее, это не мешает клиентам все это время отправлять нам новые требования. Эти запросы являются нормальными и законными. Чтобы быстро реагировать на всех клиентов, мы создали новый отдел под названием «Услуги». Через этот отдел существует команда программистов, посвященных решению ошибок и реализации небольших исправлений и обновлений, которые не являются частью глобального стандартного продукта. Они первыми взаимодействуют с клиентами, когда возникает проблема.
Иногда команда продукта (управление продуктом) поставляется с новым требованием, которое они считают простым и быстрым внедрением, и для которого нет смысла проходить весь процесс одобрения, анализа, планирования и т. Д. и «тратить» время для многих коллег. Обсуждение звучит так:
П.М.: Это просто небольшое изменение для клиента, и я не хочу возвращаться к нему, сказав, что ему приходится ждать еще шесть месяцев, чтобы что -то так просто.
Программист: К сожалению, дела идут не так. Небольшое изменение, подобное этому, может оказать влияние во многих других компонентах, и нам нужно время для анализа последствий.
П.М.: Так говорили ли мы клиенту ждать шесть месяцев?
Программист: Я боюсь, что нам придется сделать это, только если в плане нет никаких других вещей, и мы можем отложить.
П.М.: ХОРОШО. Я разговариваю с клиентом, объясняю ситуацию, и мы видим, как мы делаем.
В стартапах или компаниях, у которых не так много клиентов или много проектов одновременно, такие ситуации могут появляться не очень часто. Но в крупной организации, многонациональные, со многими параллельными проектами, такие ситуации неизбежны.
Что такое яЭто происходит, когда все правы?
И здесь решение состоит в том, чтобы приблизиться к «Выберите свои битвы», распределить и договориться о том, где это необходимо. Компромисс может быть моментным решением, когда приоритеты могут противоречить. Благодаря диалогу вы всегда можете достичь компромиссного решения и баланса между потребностями клиента и компании.
3. Иногда мы не видим лес из -за деревьев. Как мы можем найти ответственного человека?
В целом, каждая функциональность предоставляется компоненту, модулю, потоку, сегменту, группе и т. Д. Например: менеджер потока данных от пользователя в базу данных, оборудование или декодирование данных и т. Д. Но есть ситуации, когда функциональность может принадлежать к нескольким сегментам, компонентам и т. Д., Которые в этом случае ответственность за эту функциональность, к кому мы делаем, когда у нас есть вопросы, или ошибки или ошибки?
Что такое яЭто происходит, когда все правы?
Или когда у каждого ответственность? Обычно команда/сегмент должна взять на себя ответственность за эту функциональность. Но даже в этом случае может быть неизвестно и много ситуаций для этой команды для этой команды. К сожалению, не так много коллег, которые в целом смотрят на всю систему, особенно когда область, в которой они работают, уже довольно загружена различными проблемами, проблемами или ситуациями. И в этом случае, что вы делаете, если нет «добровольцев» для этой новой ответственности? Просто выдвигайте ответственный сегмент, команду, которая позаботится. Выдвижение обычно выполняется с учетом некоторых критериев, таких как соответствующий сегмент, о кодексе, могут проверить более соответствующие дома, количество людей, технические знания и т. Д. И даже если это не привычка, иногда практикуется что -то политическое.
4. горячий картофель
Название, которое я выбрал для этой последней части статьи, связана с общей ситуацией в наших исследованиях и разработках (исследования и разработки и разработка). Часто спецификации для новых функций недостаточно ясны. Иногда они даже минимальны, и тогда много вопросов рождаются от программистов, например:
Ни дизайнер UX (UX Experience), ни архитектор не понимает, что он хотел сказать для продукта, бизнес -аналитика. Мы остаемся, читаем, обсуждаем, читаем, заново переоцениваем и задаемся вопросом, что автор хотел сказать. Иногда нам кажется, что те, кто находится в отделе продукта, оставляют вещи очень высокоуровневыми, более абстрактными, точно поддающимися интерпретации. Мы помещены в горячий картофель, и мы решаем, что с ним делаем.
Конечно, то, что я сказал выше, является преувеличением, но есть случаи, когда задержки и недоразумения могут вызвать головные боли, или тестовую группу, и которые, наконец, могут привести к неудовлетворенности и разочарованию. Более того, в том числе команда продукта может почувствовать определенный уровень неудовлетворенности и разочарования, потому что они считают, что все ясно, хорошо задокументировано, обсуждается и согласовано с клиентом, и внезапно, вдруг, они понимают, что требования в пункте 5 и 9 не применимы, или они направляются с другими более старыми требованиями.
Мы люди, мы профессионалы, и подобные разочарования появляются, особенно при обсуждении сложных систем, систем, разработанных в течение многих лет, систем, которые уже много лет находятся в производстве и для чего вам нужно окружать людей, каждый из которых знает произведение, чтобы вы могли иметь обзор. К сожалению, есть немногие коллеги, которые могут сказать, что я знаю и знаю систему в 100%.
Каждая функциональность, каждый компонент, каждый модуль имеет свое значение. Те, кто пишет только код или просто тест, должны понимать нетехническую часть. Он должен понимать цель, мотивацию, для которой появилось требование, и особенно какая ценность для клиента, как клиент будет использовать. Это очень помогает избежать противоречивых дискуссий, траты времени в бесконечных дискуссиях, недоразумениях и, конечно, ошибок и ошибок, которые появляются позже. Вот почему очень важно, чтобы в спецификациях нового требования мы включали мотивацию, ценность, которую она приносит клиенту, и как оно интегрировалось в существующий продукт. Это устраняет много вопросов позже в процессе разработки.
И, наконец, если есть изменения, или если есть определенные ограничения, они должны быть указаны в описании новой функции (EX в EPIC). И если это не произойдет как команды программистов, так и тестирование в какой -то момент, что они работали и расставляли приоритеты, вещи, которые больше не имеют отношения. Мы решили подобные проблемы простым способом, и в целом мы документируем их в Джире.
Короче говоря: будьте хорошими коллегами, не позволяйте эго контролировать вас! Вы доверяете друг другу, внимательно слушаете и всегда работаете на благо продукта, компании и успеха команды.
