Несколько встреч с компаниями, занимающимися разработкой ПО на заказ, повергли меня в уныние. Понимания того, что такое программная архитектура нет, и я думаю, уже не появится. С другой стороны, разработчиков заказного ПО остается все меньше и меньше. Тема Software product management последние пару лет раскручивается и в нашей стране. С отечественными компаниями, продающими не услуги, а продукт я плотно работаю уже лет десять. Не редки случаи, когда этот самый продукт существует только в виде презентации в PowerPoint-е. И вообще, проблем с этими самыми продуктами, они же «готовые» или «промышленные» решения очень и очень много. Тем не менее, будущее именно за ними. Отмечу два фактора:
- В облаках без продукта делать нечего
- После кризиса организации экономят на ИТ. Из-за этого, в результате разного рода тендеров и конкурсов рейты программиста приближаются к рейтам гастарбайтеров. В тендерах всегда есть желающие подемпинговать. В общем, нормальных экспертов на эти деньги привлечь нереально.
Возможно, эта тенденция опечалит разработчиков, зато именно наличие продуктов делает востребованной специальность архитектора. Почему-то эту тему я не затрагивал в своем блоге, но она крайне интересная. Тем более что все компании, представляя свой продукт, допускают одни и те же ошибки, а именно:
- Описывают свою систему только с одной точки зрения, как правило, с точки зрения пользователя, т.е. рассказывают о функциях решения. Если со стороны заказчика присутствует хотя бы один грамотный архитектор, то у него присутствует очень полезный рефлекс: рассматривать все, как минимум с 4+1 точек зрения. Если потенциальный поставщик в этом «плавает» — с ним вежливо расстаются.
- Начинают проект с сбора требований, а не с обучения. Вообще говоря, использовать для кастомизации готового решения методологию разработки, придуманную для создания систем с нуля – страшная ересь. Именно из-за такого подхода существующее решение разваливается, а на его обломках создается новое. Как следствие этого – сроки и бюджет проекта вылетают в трубу
- Отсутствие процесса внесения изменений. Мы покупаем готовый продукт для того, чтоб сэкономить время и деньги. Если не понятно за счет чего достигается данная экономия, то всегда есть альтернатива – заказная разработка с нуля
- Не выделены повторно-используемые компоненты. Поставщики «готовых решений» очень любят слово core или ядро, однако очень редко могут внятно ответить на вопрос: из чего оно состоит, где начинается и где заканчивается. Очень тревожный симптом.
- И наконец, отсутствие работающего прототипа – большой жирный минус.
Я думаю, что актуальность темы архитектуры продуктов будет только расти. Маркетинг продукта выстроить не очень сложно. Средней руки MBA включает в себя все, что нужно знать про бостонские матрицы и теории конкурентной борьбы. А вот выстроить хорошую архитектуру и заставить заказчика в ней поверить – задача достойная.
Software product management (2) Архитектура продукта
Software product management (3) Change management