Консультант по развитию бизнес-приложений

file63714064_5f6d2b74В прошлом году нас в очередной раз стали учить передовым методикам сокращения времени вывода на рынок новых продуктов и услуг, т.е. пресловутому уменьшению Time to Market. Делала это одна известная консалтинговая компания, и выглядело это довольно слабо. Никто толком не разобрался в том, как у нас сейчас обстоят дела. Не потряс перед нашим носом хоть какими-нибудь эталонами моделями, не обозначил gaps. В общем, не поставив диагноз, сразу прописали agile и отпустили лечиться. Чего стоит рекомендация: «не дожидаться завершения разработки интегрируемых приложений, а использовать при тестировании вместо реальных интерфейсов заглушки». Прямо скажем, откровение из арсенала «Капитана очевидность». Одним словом, все как в анекдоте про коров, которых надо меньше кормить и чаще доить.

Естественно, мне не очень хотелось выглядеть похожим на этих персонажей при проведении Мастерской по инженерии программных продуктов. Поэтому, в декабре я потратил некоторое время на то, чтоб поразбираться с подходами к развитию программных продуктов. Не скажу, что со времен глобального увлечения CMMI что-то принципиально изменилось, но некоторые интересные моменты удалось не только узнать, но и попробовать. 

Напомню, что Capability Maturity Model придумали в Software Engineering Institute (SEI) для оценки зрелости процессов разработки программного обеспечения. Затем этой штукой много кто занимался, CMM преобразовался в CMMI (Capability Maturity Model Integration) и к 2010 году мы имели три документа версии 1.3:

  • Product and service development — CMMI for Development (CMMI-DEV),
  • Service establishment, management, — CMMI for Services (CMMI-SVC),
  • Product and service acquisition — CMMI for Acquisition (CMMI-ACQ),

причем последний документ рекомендован к применению не только для оценки приобретаемых компаний, но и для оценки аутсорсеров и поставщиков услуг и продуктов. Впрочем, все эти стандарты разрабатывались именно для оценки подрядчиков в процедуре закупок программного обеспечения. Лет 7-10 назад оценка зрелости поставщика была очень популярна, большинство компаний успели оцениться на уровень от 3-го до 5-го, но сейчас закупки немного обо всем этом забыли. В некоторой степени идея себя скомпрометировала. Слишком много было пустых предложений на рынке по проведению оценки уровня зрелости.

С другой стороны сам подход имеет право на жизнь. Особенно, если применить к нему пару-тройку улучшения. Первое, оценивать не организацию в целом, а конкретную практику, команду, развивающую определенный программный продукт. Второе, не мешать все в одну кучу: процессы, управление требованиями, управления конфигурациями, проекты, обучение, контроль качества и технологии. Очевидно, что когда продукт захватывает рынок вредно думать об оптимизации процессов его развития и эффективном использовании ресурсов. И третье. Конечно, CMM — это динозавр, не испорченный гибкими методологиями разработки и совершенно не ориентированный на создание ценностей для клиента. Какие-либо маркетинговые параметры в нем просто отсутствуют (какой может быть маркетинг при госзакупках).

Вернемся к конкретике. Для того, чтоб знать что делать, иметь внятную продуктовую стратегию нам необходимо обладать «идеальным» представлением о нашем программным продукте. Построить в голове образ того, чего мы хотим, что-то в роде: наш продукт имеет небольшую четкую концепцию, состоит из ядра, развиваемого командой из 5-7 человек, вслед за которой идет десяток консультантов по внедрению и несколько десятков прикладных разработчиков, дотачивающих продукт для конкретного клиента; в экосистему продукта вовлечены… ну и т.д.

На основании  такого видения можно уже определять гэпы между тем, что есть и тем чего хочется. Я бы делал это в виде опросника, включающего, в частности, следующие темы:

  • Начинаем, безусловно, с клиента. Прежде всего, необходимо иметь ценностное предложение (value proposition). На B2B рынке ценностное предложение лучше сразу представлять себе как набор опций, выбираемых для конкретного клиента. Подробнее об этом у того же Software Engineering Institute в концепции Software Product Line
  • Далее идет команда разработки. Не тот батальон людей, что вьется обычно вокруг любой программной системы, а именно команда создающая продукт. Здесь, конечно, есть место для мифотворчества как, например, в истории о том, что: « In March 2010, Tom Baeyens and Joram Barrez, the two key developers for jBPM left Red Hat and started Activiti as employees of Alfresco…» (см. Process Developments Blog), но почему бы и нет? На самом деле, от того как сложится такая команда, насколько четко в ней будут заданы роли, как часто и на какую тему она будет ругаться внутри себя и как она выстроит взаимодействие с внешним миром зависит все. Создание программного обеспечения до сих пор остается индивидуальной практикой людей, способных договариваться друг с другом.
  • Только третьим пунктом возникает процесс разработки. Даже, скорее, не разработки, а доставки программного обеспечения. Как и какие решения принимает владелец продукта, как он взаимодействует с командой, в каких вопросах мнение заказчика учитывается, а в каких игнорируется и кто будет за это утешать заказчика плюшками. Как часто у нас релизы, что у нас в роадмэпе(дорожной карте), как мы избавляем заказчиков от необходимости стоять в длинной очереди релизов и т.д.
  • Четвертое. Технологии. Здесь очень много аспектов. Есть технологии времени разработки, а есть времени исполнения. Одно время между ними образовался внушительных размеров водораздел, но сейчас все движется в обратную сторону. Технологий не должно быть слишком много, но они должны оставаться достаточно современными и в то же время поддерживаемыми большим сообществом разработчиков, не очень дорогими (когда наша система рухнет, у вас хоть останутся лицензии Oracle/IBM/SAP), достаточно высокоуровневыми (иначе не добиться хорошей производительности труда), ну и т.д.
  • Все это вряд ли получится реализовать без внятной архитектуры. Архитектура только на пятом месте. Возникает она в результате множества противоречий между обозначенными выше требованиями. Главные вопросы архитектуры: в каком контексте живет наш продукт, как мы ограничиваем глубину изменений, не обидев при этом заказчиков, что нам позволяет масштабировать команду разработки, да и сам продукт. В общем, все слова про мобильный front-end и облачный back-end, Web APIs и Multitenancy рассматриваются в этом разделе.

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

pg024

Удачи нам всем в Новом году!

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s