Марти Каган и Крис Джонс, авторы книги «Transformed» в недавней заметке рассуждают о том, чем отличаются традиционные ИТ-подразделения от продуктовых, и о том, применима ли продуктовая модель (продуктовый подход) к традиционным компаниям, которые всё чаще проявляют интерес к этой модели.

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

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

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

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

Культурные нормы в традиционном ИТ часто подчеркивают необходимость «обслуживания бизнеса», что может создать барьеры для предоставления командам возможности сотрудничать с бизнесом для обслуживания клиентов.

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