Мы тут в @ru_arc_chat затронули интересную тему целей разработки и целей бизнеса.
Пример – видеоплатформа.
Слева - бизнес, справа – разработчики. Полное деление на бизнес и IT.
Здесь Player разработкой воспринимается как продукт, являясь платформой, а продуктами являются конкретные позиционирования с конкретной ЦА и конкретными доработками для этой ЦА.
В такой структуре цели бизнеса и разработки будут отличаться.
Цель «сделать универсальный player как самостоятельный продукт» противоречит, например, цели «максимально быстро занять нишу», при том, что первая цель идет от абмиций IT и сам «бизнес» о ней даже не знает, невольно спонсируя движение к этой цели, а не к своей 🙂
Под тот же паттерн поведения подходит почти любой продукт, являющийся конкурентным преимуществом для нас, частью которого является внешний COTS.
Для внешнего продукта наши доработки будут источником финансирования для развития собственной коробки. Это не те цели, которые ставим мы, - любое универсальное решение априори сложнее и дороже, и - дольше реализуется.
В таком кейсе, если мы хотим сделать хорошую платформу, то воспринимать ее нужно как внутренний продукт для внутренних заказчиков. А у бизнес-заказчиков есть своя разработка – продуктовые команды, обладающие экспертизой в конкретной предметной области. И эти заказчики «легко» могут отказаться от внутренней платформы, если она перестает удовлетворять их потребностям. Внутренний рынок – тоже рынок.
Идет ли цель запилить микросервисы на кубере от целей бизнеса или это наша цель реализовать свои инженерные абмиции?
Требуется универсальная платформа, создающия сильные завимости и, как следствие, – колоссальную координационную нагрузку при планировании и согласовании изменений или лучше несколько простых и конкретных реализаций, но изолированно используемых конкретной бизнес-линией или продуктом?
Это важные вопросы, а ответы на них далеко не всегда лежат на поверхности.
Пример – видеоплатформа.
Слева - бизнес, справа – разработчики. Полное деление на бизнес и IT.
Здесь Player разработкой воспринимается как продукт, являясь платформой, а продуктами являются конкретные позиционирования с конкретной ЦА и конкретными доработками для этой ЦА.
В такой структуре цели бизнеса и разработки будут отличаться.
Цель «сделать универсальный player как самостоятельный продукт» противоречит, например, цели «максимально быстро занять нишу», при том, что первая цель идет от абмиций IT и сам «бизнес» о ней даже не знает, невольно спонсируя движение к этой цели, а не к своей 🙂
Под тот же паттерн поведения подходит почти любой продукт, являющийся конкурентным преимуществом для нас, частью которого является внешний COTS.
Для внешнего продукта наши доработки будут источником финансирования для развития собственной коробки. Это не те цели, которые ставим мы, - любое универсальное решение априори сложнее и дороже, и - дольше реализуется.
В таком кейсе, если мы хотим сделать хорошую платформу, то воспринимать ее нужно как внутренний продукт для внутренних заказчиков. А у бизнес-заказчиков есть своя разработка – продуктовые команды, обладающие экспертизой в конкретной предметной области. И эти заказчики «легко» могут отказаться от внутренней платформы, если она перестает удовлетворять их потребностям. Внутренний рынок – тоже рынок.
Идет ли цель запилить микросервисы на кубере от целей бизнеса или это наша цель реализовать свои инженерные абмиции?
Требуется универсальная платформа, создающия сильные завимости и, как следствие, – колоссальную координационную нагрузку при планировании и согласовании изменений или лучше несколько простых и конкретных реализаций, но изолированно используемых конкретной бизнес-линией или продуктом?
Это важные вопросы, а ответы на них далеко не всегда лежат на поверхности.