Метка: Software product management

Чему ИТ может научить бизнес. Пара замечаний о Product Development.

лиса и журавльВ компании, из которой я недавно уволился, я не все время работал Главным ИТ архитектором. Несколько лет я проработал менеджером по запуску новых продуктов (value added services). Правда, в определенный момент пришло осознание того, что мы делаем все не очень правильно. Собственно,  потому я и перешел в ИТ на позицию архитектора. Архитектор, особенно архитектор предприятия (Enterprise Architect) — это тот человек, который может исправить некоторые ошибки бизнеса (я оставлю за скобками вопрос, кто такой EA и почему в отечественных реалиях такая должность не встречается в бизнес-подразделениях). Я надеюсь, что в будущем компания успешно справится с болезнями роста и скорректирует процессы развития и управления продуктами, но во время моей работы этот процесс был таким, каким он был.   Продолжить чтение «Чему ИТ может научить бизнес. Пара замечаний о Product Development.»

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

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

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

Мастерская инженерии программных продуктов

massive-multi-toolМы это сделали. Сегодня провел первый workshop на тему Software Product Engineering. Безусловно, очень многое еще надо доработать. Прежде всего, формат. Очень сложно за полдня нащупать в груде софта, написанного в разное время под требования различных людей, тиражируемое решение. Но, смотрю сейчас заполненные участниками воркшопа шаблоны, и думаю что направление выбрано верное. Задумка удалась. Вообще говоря, тема «продуктизации» программного обеспечения, перехода от услуг по разработке с нуля, по требованиям заказчика, к разработке программных продуктов очень старая. Упоминания о ней можно найти еще в легендарной книжке Брукса «Мифический человеко-месяц». Собственно говоря, с рассуждений, чем отличается программный продукт от написанной в гараже парой друзей программы, эта книжка и начинается. Но тема до сих пор актуальная. Продолжить чтение «Мастерская инженерии программных продуктов»

Software product management (3) Change management

Продолжаю серию заметок о различиях заказного ПО и программного продукта. Я уже упоминал о том, что причиной долго времени внесения изменений в ИТ системы может являться сам процесс внесения изменений. Все мы учились на унифицированном процессе разработки ПО. Потому верим в цикл разработки, включающий сбор и анализ требований, проектирование, разработку, тестирование и развертывание решения. Большинство попыток оптимизации этого цикла сводятся к сокращению времени этих фаз. Гибкие методологии, такие как SCRUM предлагают зафиксировать вместо объема работ длительность итерации, т.е. цикл (sprint) разработки составляет всегда X недель (2 или 4), а объем требований для каждого цикла разработки определяется исходя из их сложности. В любом случае, внесение изменений в систему осуществляется только посредством разработки. Продолжить чтение «Software product management (3) Change management»