Мы тут в @ru_arc_chat затронули интересную тему целей разработки и целей бизнеса. Пример – видеоплатформа. Слева - бизнес, справа – разработчики. Полное деление на бизнес и IT. Здесь Player разработкой воспринимается как продукт, являясь платформой, а продуктами являются конкретные позиционирования с конкретной ЦА и конкретными доработками для этой ЦА. В такой структуре цели бизнеса и разработки будут отличаться. Цель «сделать универсальный player как самостоятельный продукт» противоречит, например, цели «максимально быстро занять нишу», при том, что первая цель идет от абмиций IT и сам «бизнес» о ней даже не знает, невольно спонсируя движение к этой цели, а не к своей 🙂 Под тот же паттерн поведения подходит почти любой продукт, являющийся конкурентным преимуществом для нас, частью которого является внешний COTS. Для внешнего продукта наши доработки будут источником финансирования для развития собственной коробки. Это не те цели, которые ставим мы, - любое универсальное решение априори сложнее и дороже, и - дольше реализуется. В таком кейсе, если мы хотим сделать хорошую платформу, то воспринимать ее нужно как внутренний продукт для внутренних заказчиков. А у бизнес-заказчиков есть своя разработка – продуктовые команды, обладающие экспертизой в конкретной предметной области. И эти заказчики «легко» могут отказаться от внутренней платформы, если она перестает удовлетворять их потребностям. Внутренний рынок – тоже рынок. Идет ли цель запилить микросервисы на кубере от целей бизнеса или это наша цель реализовать свои инженерные абмиции? Требуется универсальная платформа, создающия сильные завимости и, как следствие, – колоссальную координационную нагрузку при планировании и согласовании изменений или лучше несколько простых и конкретных реализаций, но изолированно используемых конкретной бизнес-линией или продуктом? Это важные вопросы, а ответы на них далеко не всегда лежат на поверхности.
Мы тут в @ruarcchat затронули интересную тему целей разработки и целей бизнеса.…
Из этого канала
- #287Про совместную работу заказчика и разработки можно процитировать Кента Бека,…
Про совместную работу заказчика и разработки можно процитировать Кента Бека, книга Экстремальное Программирование, глава «on-site customer»: «Иногда менеджерам…
- #288На пробу. A simple measure of software dependency freshness. It is a single…
На пробу. A simple measure of software dependency freshness. It is a single number telling you how up-to-date your dependencies are. https://libyear.com #tools
- #289Продолжается прием заявок на доклады конференции по архитектуре IT-решений…
Продолжается прием заявок на доклады конференции по архитектуре IT-решений ArchDays 2022! В этом году мы возвращаемся в офлайн! Конференция пройдет 21 октября…
- #284Напишите, пожалуйста, в комментариях, какие статьи (всех времен) вы считаете…
Напишите, пожалуйста, в комментариях, какие статьи (всех времен) вы считаете фундаментальными в области архитектуры и разработки (на русском или английском)?…
- #283Monolith First строится вокруг простой идеи — восприятие монолита как прототипа.
Monolith First строится вокруг простой идеи — восприятие монолита как прототипа.