Комментарии 9
А еще лучше создайте общий глоссарий с правильными названиями объектов
Всеми руками за такое, но сразу возникает вопрос: как заказчика уговорить/убедить/заставить говорить на языке глоссария?
Вопрос внутренних договоренностей (сразу оговорюсь, что серебряной пули тут тоже нет). Можно постоянно использовать правильные термины из глоссария/ссылаться на глоссарий и заказчик рано или поздно привыкнет.
Важно помнить, что эта дорога идет в два направления, поэтому разработке тоже стоит использовать правильную терминологию)
Статья очень в тему, спасибо автору!
Будем использовать этот чек-лист при работе с заказчиками, т.к. с БТ постоянно возникают трудности (
А еще лучше создайте общий глоссарий с правильными названиями объектов, и тогда таблицы на фронте останутся таблицами, не превращаясь при этом в загадочные ящики (для вас) и непонятные гриды (для заказчика).
Из личного опыта. Когда кто-то на встрече говорит "давайте поговорим о терминах", и после этой фразы реально обсуждаются термины - я понимаю, что на этой встрече дела не будет и надо просто работать в ноутбуке
Создайте шаблон бизнес-требований
Мама, мама, я смогла съесть кашу вилкою, почти всю :) Какая я молодец :)
Внесите обязательность показателей в шаблон бизнес-требований,
грабьте, воруйте, но критерии эффективности проекта должны быть зафиксированы.
Таки стоит говорить о терминах, так как у нас не рабочее совещание. Критерии эффективности проекта не меняются уже много веков. Бюджет, скоуп, сроки. Вписали во все три? Красавчик, это удается немногим. Вписались в два. Тож неплохо. Если нет - ищите другую работу.
Ну и идея в БТ фиксировать критерии эффективности проекта - это уже за гранью. Ну либо у вас ПМ/БА - одно лицо и ему проще все писать в одном месте.
Один из самых популярных конфликтов в истории человечества не мог не докатиться и до ИТ. Заказчик что-то хочет, но не может объяснить, что именно. Разработка старается понять пожелания заказчика, но в итоге понимает не то, делает не так и вообще «вы не понимаете, это другое». Где-то рядом бродит печальный менеджер, который пытается всем помочь, но в итоге получает с двух сторон свою порцию лучей добра и позитива и с дичайшим выгоранием отправляется лечить нервы в ближайшем доме с желтыми стенами.
Можно нанять аналитика + архитектора, которые это решат :) Ну или найти людей, которые называются по другому, но делают именно это :)
Соберите пожелания к формату и структуре требований от всех, кто участвует в процессе разработки: системных аналитиков, разработчиков, QA, сопровождения, РП.
И потом выкиньте это в урну :) Не, я не против, если у меня, к примеру, кто-то попросит чего-то добавить в architecture vision / solution документ. Но ходить и собирать пожелания ... разве что если задаться целью показать всем, что на этот проект выделили архитектора дегенерата, который не знает, в чем заключается его работа
Если с такими же вопросами будет ходит условный БА (что мне писать в БТ), или QC (как мне писать тест кейсы) - то вопрос только один. Как такие чудесные кадры вообще попали в организацию, и что тогда я ту делаю
Скажите «Нет!» технической реализации в бизнес-требованиях
Вот это наверное единственное светлое пятно в этой статье
Но ходить и собирать пожелания ... р
А всегда ли БА эффективно и в удобной для остальных участников процесса разработки виде формализует требования? Я понимаю, что это навык и важнейшая функция БА. Но если команда приняла решение работать по BDD паттерна или QA недавно внедрили AI, которые определенный формат требований превращает в тест-кейсы, к примеру?
По BDD паттерну не скажу, почитать конечно в инете могу, но вы и без меня можете сделать тоже самое. Если вы раскроете эту мысль своей практикой - я наверное смогу что-то прокомментировать
Про QA - и что, теперь все должны под это подстроиться? Я так себе представляю, приходит QA lead на стенд ап и говорит: мы тут внедрили AI, и теперь вы должны работать по другому :) В реальной жизни лучшим раскладом для QA будет уйти с такой встречи без своих идей, распечатаных на бумаге в каком-то из отверстий своего организма
Ну а если серьезно ... команда на то и команда, чтобы работать слажено. Задача BA выдавать то, что могут потреблять остальные, а не только собирать требования. БА - это часть маршрута, а не тупик, где оседают артефакты
А как именно - во всех командах чуть-чуть да по разному
Отличная статья, большое спасибо за чек-лист! Отдельно хотелось бы спросить про
Скажите «Нет!» технической реализации в бизнес-требованиях
Что делать, если всё таки требования есть? По типу "реализуйте на этом инструменте, чтобы я мог разобраться в нём если что/после вас"?
Спасибо за комментарий!
Появление технической реализации в бизнес-требованиях обычно связано с дополнительными факторами (затраты на разработку, лицензии, стоимость владения, риски, etc). Например - во всей компании/функции используется один и тот же инструмент, и заказчик хочет сделать на нем, чтобы не изучать новый/не переучивать людей. Тут скорее важно понять, что именно и почему хочет заказчик (отталкиваться от потребности), а как именно это решить технически - будет прорабатываться на уровне дизайна системы, архитектуры, аналитики и разработки. Большинство заказчиков в итоге соглашаются с таким подходом, т.к. на самом деле для них не имеет значения, как именно задача будет реализована, если в итоге она будет реализована с тем функционалом, который они хотели и в срок.
А для того, чтобы помочь, "разобраться после вас" можно использовать руководство пользователя/аналогичную документацию.
Что такое бизнес-требования и как с ними (не) бороться