Software product management

Несколько встреч с компаниями, занимающимися разработкой ПО на заказ, повергли меня в уныние. Понимания того, что такое программная архитектура нет, и я думаю, уже не появится. С другой стороны, разработчиков заказного ПО остается все меньше и меньше. Тема Software product management последние пару лет раскручивается и в нашей стране. С отечественными компаниями, продающими не услуги, а продукт я плотно работаю уже лет десять. Не редки случаи, когда этот самый продукт существует только в виде презентации в PowerPoint-е. И вообще, проблем с этими самыми продуктами, они же «готовые» или «промышленные» решения очень и очень много. Тем не менее, будущее именно за ними. Отмечу два фактора:

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

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

  1. Описывают свою систему только с одной точки зрения, как правило, с точки зрения пользователя, т.е. рассказывают о функциях решения. Если со стороны заказчика присутствует хотя бы один грамотный архитектор, то у него присутствует очень полезный рефлекс: рассматривать все, как минимум с 4+1 точек зрения. Если потенциальный поставщик в этом «плавает» – с ним вежливо расстаются.
  2. Начинают проект с сбора требований, а не с обучения. Вообще говоря, использовать для кастомизации готового решения методологию разработки, придуманную для создания систем с нуля – страшная ересь. Именно из-за такого подхода существующее решение разваливается, а на его обломках создается новое. Как следствие этого – сроки и бюджет проекта вылетают в трубу
  3. Отсутствие процесса внесения изменений. Мы покупаем готовый продукт для того, чтоб сэкономить время и деньги. Если не понятно за счет чего достигается данная экономия, то всегда есть альтернатива – заказная разработка с нуля
  4. Не выделены повторно-используемые компоненты. Поставщики «готовых решений» очень любят слово core или ядро, однако очень редко могут внятно ответить на вопрос: из чего оно состоит, где начинается и где заканчивается. Очень тревожный симптом.
  5. И наконец, отсутствие работающего прототипа – большой жирный минус.

Я думаю, что актуальность темы архитектуры продуктов будет только расти. Маркетинг продукта выстроить не очень сложно. Средней руки MBA включает в себя все, что нужно знать про бостонские матрицы и теории конкурентной борьбы. А вот выстроить хорошую архитектуру и заставить заказчика в ней поверить – задача достойная.

Software product management (2) Архитектура продукта
Software product management (3) Change management

Software product management: 5 комментариев

  1. >>всегда есть альтернатива – заказная разработка с нуля

    IMHO реально почти никогда такой альтернативы нет, в том числе по причинам, которые привел автор и по которым из-за отсутствия ИТ-архитектора у компании-исполнителя жестко заточенный на “потребности” рядовых пользователей продукт лабают на коленке 2 года, а потом или шах умрет или ишак. Т.е. или ИТ-директор у заказчика сменится (2-3 года это как раз средний жизненный цикл ИТ-директора на одном месте) или ИТ-приоритеты поменяются.
    ИТ-компании, в которых есть реальный сильный ИТ-архитектор, как правило, созревают до разработки собственного продукта и перестают делать “чего изволите, то и запрограммируем”. Ну, если только это не компании, созданные 2 недели назад и уже победившие в тендере на 600 миллионов рублей на разработку в течение месяца с нуля системы электронного документооборота

    1. Согласен с тем, что путеводная звезда в карьере ИТ архитектора – построение своего продукта. Я бы лекции по программной инженерии в институте начинал бы со слов: “настанет день, когда вы построите свой программный продукт и каким он будет зависит от вас… ” =)

      1. Запутаете только голову молодому поколению 🙂 ИТ инженеры медленно но верно разделяются на два уже почти нескрещиваемых вида: те, что делают продукты или оказывают услуги, и те, что обслуживают ИТ-нужды предприятия — вроде Вас или меня. Чем скорее молодой специалист определится с тем, что ему ближе, тем ему же будет лучше. Я бы ещё в рамках обучения отправлял на стажировку в оба типа организаций для, так сказать, профориентации.

  2. Кстати, я убеждён, что можно выработать единообразный и целостный подход к интеграции как коробочных, так и заказных решений в ИТ инфраструктуру предприятия, ведь многие виды деятельности совпадают для решений любого типа. Я веду некоторую “исследовательскую” работу в этой области, в основном изучая опыт системной инженерии. По ходу пишу заметки у себя в блоге (например, http://ilobanov.wordpress.com/2011/08/18/case-for-solutions-acquisition-framework/), так что приглашаю понаблюдать и, если угодно, поучаствовать. Что Вы вообще думаете о возможности такого подхода? Если ли смысл, на Ваш взгляд.

Добавить комментарий для Максим Смирнов Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *