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

Tолько без глупостей

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

Tолько без глупостей

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

Tолько без глупостей

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

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

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

Tолько без глупостей

Согласна!

Tолько без глупостей

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

Есть еще системная архитектура, это то, что Алла под инфраструктурой понимает:)

А что вы понимаете под бизнеслогикой?:)

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

Тестер и бизнес-аналитик - это разные mindset. И у них разные обязанности. И разный подход. И разные задачи они ставят перед собой. И как вообще их можно перепутать :).

Бизнес-аналитик полезен в бета-тестировании, в роли пользователя, но это не совсем то, как бизнес-логику тестирует тестировщик.

Так кто же выходит в вашем понимании разработчик? А то вы как-то ловко подменили не понравившееся другим слово ит-шник на разработчика и он же архитектор в одном лице? Ещё какие-то роли у этого особенного человека будущего?

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

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

кстати, хороший аналитик это хороший тестер

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

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

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

А тестеры они скорее технические, тестируют нагружаемость, выполняемость, но не бизнеслогику, как ее понимаю я:)))

Тест бывает разный: фах, технический и прочие. Учите матчасть!

Это вам фолия с воркшопа по архитектуре ПО этого года. Народа было много, но с титулом архитектора единицы. Их обычно для консультаций приглашают нынче, все грамотные пошли. Как бы вам иначе не хотелось:)

Да любой хороший специалист на вес золота..

ну это вы погорячились.

Или чтобы писали тест-сценарии для тесторов, тоже вариант.

Вот это плохо. Очень-очень плохо. Пусть лучше не лезут не в свое дело, а занимаются своими требованиями.

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