Примерно 19:00. Про ответственность БА за внешние изменения. Крайне важно, про кого речь. Про роль или "должность". Ответственность за продукт несёт Product Owner. А вот кто играет его роль (ещё раз - РОЛЬ) - тот и отвечает. Или есть выделенный PO, или сам заказчик настолько погружён, или ПМ с любой стороны, или, действительно, БА. В общем случае это не обязанность БА. Есть же в инетах хорошие сравнения обязанностей PO и БА, всё давно придумано. Если есть риск с этой стороны, то про ответственность надо договариваться на берегу. Для этого и придумали умные люди методики, матрицы ответственности, которые надо использовать при создании проекта
Продолжаю садо-мазо. Примерно 10:00. В случае с вашим Зибелем нет изменения требований. Есть новое требование на подключение новой (для Кафка) системы. Это было бы измением, если бы была последовательность во времени: подключить З. к Кафке - (пока чесались) наступили санкции - меняем требование на другое решение. А если вдруг было так: наступили санкции - подключить З. к Кафке -..., то огромный профессиональный вопрос к аналитику, как он оформил заранее неисполнимое требование (помним же критерии требований?)
Уважаемый Вадим, приходите к нам, пожалуйста, и расскажите как правильно и профессионально управлять требованиями. А то мы зовем-зовем, но что-то никто не приходит. Хорошо, что у нас есть смелый Олег!
Тут была последовательность такая: была отрисована и согласованна архитектура, на тот момент вопроса с кафкой не было, но проект отложили на долгий срок и к моменту финального согласования (через почти год) когда должна была уже стартовать разработка, выяснилось что с кафкой зибель синтегрироваться уже не может, так как санкции догнали.
Минут 10 слушаю, как-то всё в кучу, скомкано. Зачем рассматривать нарушения процессов разработки (разраб сделал не по задаче) применительно к требованиям? Ну так сюда столько можно приплести этих нарушений, что не на один вебинар. Разраб не требование выполняет, а, как это прозвучало, "ТЗ", иначе - постановку на разработку Почему в рассматриваемом примере требования по безопасности - НФТ? Безопасник по отношению к вашей системе - стейкхолдер. Это его требование. И оно нефункциональное? А ведь в системе появится (или есть) модуль/компонент/сервис, который будет решать функциональность безопасности
Требования к безопасности - НФТ, да. Нефункциональные требования - это ограничения или требования, предъявляемые к системе (например, производительность, безопасность, цвет, шрифт и т. д.).
Требования по безопасности могут влиять на стек и должны учитываться при проработке архитектуры. Требования по безопасности могут дать целый набор интеграций, которые будут в ТЗ. Безопасник как стейкхолдер даёт требования формата: все файлы, полученные из вне должны проходить через песочницу до попадания во внутренний контур. Как вы это сделаете это ваше. По поводу разраб сделал не по ТЗ, это не всегда ошибка, возможно он нашел решение лучше, тут нужно понимать, что тут есть два варианта, либо править код, либо править документацию, соответственно это решается в общении разработчик-аналитик и тут надо выстраивать процесс коммуникации, иначе в итоге все ушло в прод все работает, но не так как в документации и следующий разбор как это работает станет проблемным.
Далеко не всегда функционал безопасности решается каким-то одним модулем, безопасность может дать требования, которые можно решить разными путями и выбор пути это как раз задача аналитика
@@user-jt1xg1ez5m тут вопрос в том что нфт это неотъемлемая часть документации, соответственно за описание в конкретной реализации нфт отвечает тоже аналитик, документация не заканчивается ТЗ в чистом виде.
@@user-yq5oc9ip7qУ меня огромное количество вопросов к вашим словам, но вы почему-то отвечаете на вопросы и темы, которые я не затрагивал, но не отвечаете на мои. Зачем вы про архитектуру, интеграции..? Вопросы были крайне конкретны - про требования, в контексте вебинара. Вначале я недоумевал, сейчас я разочарован. Грамотное управление требованиями немыслимо без системной логики, а не вот это всё
прикольно - бардак в компании перекладывается на голову аналитика... разраб там что то нарефакторил без согласованного релиза - аналитику прилетает и ему раз в месяц перелопачивать как его система работает (большая система или большое количество мелких, на мелкие и на мало аналитики нахрен не нужны). Регулятор что то поменял - оказывается аналитик должен следить что бы бизнес процессы компании соответствовали законам... Простите, но либо бред либо сломанная картина смысла аналитика по причине долгой работы в бессистемном рашн бизнес. Хотя если зп в районе 5000$ тогда наверное можно работать в таком бардаке
Почему бардак? Разработка не обязана делать все ровно как в документации если они видят что можно сделать лучше, в данном случае задача аналитика выстроить коммуникацию так, чтобы это делалось не в тихушку, а нормально, с обсуждением с аналитиком. По поводу законодательства, если человек является и БА и СА (90% случаев в компаниях РФ) тогда это нормально, так как именно БА отвечает в том числе за то, чтобы поддерживать законодательство.
Примерно 19:00. Про ответственность БА за внешние изменения.
Крайне важно, про кого речь. Про роль или "должность". Ответственность за продукт несёт Product Owner. А вот кто играет его роль (ещё раз - РОЛЬ) - тот и отвечает. Или есть выделенный PO, или сам заказчик настолько погружён, или ПМ с любой стороны, или, действительно, БА. В общем случае это не обязанность БА. Есть же в инетах хорошие сравнения обязанностей PO и БА, всё давно придумано.
Если есть риск с этой стороны, то про ответственность надо договариваться на берегу. Для этого и придумали умные люди методики, матрицы ответственности, которые надо использовать при создании проекта
Продолжаю садо-мазо. Примерно 10:00. В случае с вашим Зибелем нет изменения требований. Есть новое требование на подключение новой (для Кафка) системы.
Это было бы измением, если бы была последовательность во времени: подключить З. к Кафке - (пока чесались) наступили санкции - меняем требование на другое решение.
А если вдруг было так: наступили санкции - подключить З. к Кафке -..., то огромный профессиональный вопрос к аналитику, как он оформил заранее неисполнимое требование (помним же критерии требований?)
Уважаемый Вадим, приходите к нам, пожалуйста, и расскажите как правильно и профессионально управлять требованиями. А то мы зовем-зовем, но что-то никто не приходит. Хорошо, что у нас есть смелый Олег!
Тут была последовательность такая: была отрисована и согласованна архитектура, на тот момент вопроса с кафкой не было, но проект отложили на долгий срок и к моменту финального согласования (через почти год) когда должна была уже стартовать разработка, выяснилось что с кафкой зибель синтегрироваться уже не может, так как санкции догнали.
@@user-yq5oc9ip7q это упомянутый вариант "пока чесались" :), понятно
Минут 10 слушаю, как-то всё в кучу, скомкано.
Зачем рассматривать нарушения процессов разработки (разраб сделал не по задаче) применительно к требованиям? Ну так сюда столько можно приплести этих нарушений, что не на один вебинар. Разраб не требование выполняет, а, как это прозвучало, "ТЗ", иначе - постановку на разработку
Почему в рассматриваемом примере требования по безопасности - НФТ? Безопасник по отношению к вашей системе - стейкхолдер. Это его требование. И оно нефункциональное? А ведь в системе появится (или есть) модуль/компонент/сервис, который будет решать функциональность безопасности
Требования к безопасности - НФТ, да.
Нефункциональные требования - это ограничения или требования, предъявляемые к системе (например, производительность, безопасность, цвет, шрифт и т. д.).
Требования по безопасности могут влиять на стек и должны учитываться при проработке архитектуры. Требования по безопасности могут дать целый набор интеграций, которые будут в ТЗ. Безопасник как стейкхолдер даёт требования формата: все файлы, полученные из вне должны проходить через песочницу до попадания во внутренний контур. Как вы это сделаете это ваше. По поводу разраб сделал не по ТЗ, это не всегда ошибка, возможно он нашел решение лучше, тут нужно понимать, что тут есть два варианта, либо править код, либо править документацию, соответственно это решается в общении разработчик-аналитик и тут надо выстраивать процесс коммуникации, иначе в итоге все ушло в прод все работает, но не так как в документации и следующий разбор как это работает станет проблемным.
Далеко не всегда функционал безопасности решается каким-то одним модулем, безопасность может дать требования, которые можно решить разными путями и выбор пути это как раз задача аналитика
@@user-jt1xg1ez5m тут вопрос в том что нфт это неотъемлемая часть документации, соответственно за описание в конкретной реализации нфт отвечает тоже аналитик, документация не заканчивается ТЗ в чистом виде.
@@user-yq5oc9ip7qУ меня огромное количество вопросов к вашим словам, но вы почему-то отвечаете на вопросы и темы, которые я не затрагивал, но не отвечаете на мои. Зачем вы про архитектуру, интеграции..? Вопросы были крайне конкретны - про требования, в контексте вебинара.
Вначале я недоумевал, сейчас я разочарован. Грамотное управление требованиями немыслимо без системной логики, а не вот это всё
прикольно - бардак в компании перекладывается на голову аналитика... разраб там что то нарефакторил без согласованного релиза - аналитику прилетает и ему раз в месяц перелопачивать как его система работает (большая система или большое количество мелких, на мелкие и на мало аналитики нахрен не нужны). Регулятор что то поменял - оказывается аналитик должен следить что бы бизнес процессы компании соответствовали законам... Простите, но либо бред либо сломанная картина смысла аналитика по причине долгой работы в бессистемном рашн бизнес. Хотя если зп в районе 5000$ тогда наверное можно работать в таком бардаке
Почему бардак? Разработка не обязана делать все ровно как в документации если они видят что можно сделать лучше, в данном случае задача аналитика выстроить коммуникацию так, чтобы это делалось не в тихушку, а нормально, с обсуждением с аналитиком. По поводу законодательства, если человек является и БА и СА (90% случаев в компаниях РФ) тогда это нормально, так как именно БА отвечает в том числе за то, чтобы поддерживать законодательство.
Представляю как радуются работодатели человеку, который способен работать в сложной ситуации не называя ее бардаком.