Мы это сделали. Сегодня провел первый workshop на тему Software Product Engineering. Безусловно, очень многое еще надо доработать. Прежде всего, формат. Очень сложно за полдня нащупать в груде софта, написанного в разное время под требования различных людей, тиражируемое решение. Но, смотрю сейчас заполненные участниками воркшопа шаблоны, и думаю что направление выбрано верное. Задумка удалась. Вообще говоря, тема «продуктизации» программного обеспечения, перехода от услуг по разработке с нуля, по требованиям заказчика, к разработке программных продуктов очень старая. Упоминания о ней можно найти еще в легендарной книжке Брукса «Мифический человеко-месяц». Собственно говоря, с рассуждений, чем отличается программный продукт от написанной в гараже парой друзей программы, эта книжка и начинается. Но тема до сих пор актуальная.
Несколько лет назад интерес к этой теме обрел новую силу. Может разработчикам нечем было заняться в кризис, а может быть многие просто почувствовали очередную волну смены технологий. Но в современной волне интереса большинство материалов (презентаций, статей, тренингов) касаются маркетинговой составляющей программных продуктов. В лучшем случае, адаптаций традиционного цикла разработки под разработку продуктовую. Мы же в большей степени делаем акцент:
- на архитектуре, в технологической составляющей продукта;
- в части процессов, на разделении цикла реализации пользовательских требований и цикла непосредственного развития продукта;
- и в продуктовой составляющей – на формировании из фич продукта ценностного предложения (value proposition).
Пару лет назад я написал в этом блоге несколько своих соображений относительно инжиниринга программных продуктов:
- Software product management
- Software product management (2) Архитектура продукта
- Software product management (3) Change management
А вот здесь Различия кастомизируемых программных продуктов и заказной разработки мы даже интересно подискутировали на эту тему. Но одно дело пара заметок в блоге и совсем другое полноценный воркшоп. Воркшоп, в первую очередь интересен тем, что в отличии от тренинга предполагает работу не на вымышленных упражнениях, а на реальных задачах заказчика. Во-вторых, в воркшопе участвуют люди с разными навыками и исполняют они разные роли(подробнее см., например Software architecture workshop) Для «продуктового» воркшопа эту тему надо еще попрорабатывать, но перспективность её сомнений у меня не вызывает. Кстати, и на тренингах команды, в которых распределены роли и зоны ответственности, действуют на порядок эффективней. Я даже подозреваю, что в командных упражнениях традиционных тренингов есть доля лукавства. То, что один человек может сделать за пять минут, команда с трудом реализует за полчаса. И, наконец, на воркшопах совершенно другой уровень ответственности. Если после традиционного тренинга от упражнений остаются только легкие воспоминания цирк уехал, то не решенные на воркшопе вопросы остаются вместе с его участниками. В лучшем случае, они преобразуются в задачи и поручения.
В общем, тема инженерии программных продуктов интересная, форма мастерской – подходящая, буду рад вашим содержательным комментариям и надеюсь на полезную дискуссию.