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

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

Несколько лет назад интерес к этой теме обрел новую силу. Может разработчикам нечем было заняться в кризис, а может быть многие просто почувствовали очередную волну смены технологий. Но в современной волне интереса большинство материалов (презентаций, статей, тренингов) касаются маркетинговой составляющей программных продуктов. В лучшем случае, адаптаций традиционного цикла разработки под разработку продуктовую. Мы же в большей степени делаем акцент:

  • на архитектуре, в технологической составляющей продукта;
  • в части процессов, на разделении цикла реализации пользовательских требований и цикла непосредственного развития продукта;
  • и в продуктовой составляющей – на формировании из фич продукта ценностного предложения (value proposition).

Пару лет назад я написал в этом блоге несколько своих соображений относительно инжиниринга программных продуктов:

А вот здесь Различия кастомизируемых программных продуктов и заказной разработки мы даже интересно подискутировали на эту тему. Но одно дело пара заметок в блоге и совсем другое полноценный воркшоп. Воркшоп, в первую очередь интересен тем, что в отличии от тренинга предполагает работу не на вымышленных упражнениях, а на реальных задачах заказчика. Во-вторых, в воркшопе участвуют люди с разными навыками и исполняют они разные роли(подробнее см., например Software architecture workshop) Для «продуктового» воркшопа эту тему надо еще попрорабатывать, но перспективность её сомнений у меня не вызывает. Кстати, и на тренингах команды, в которых распределены роли и зоны ответственности, действуют на порядок эффективней. Я даже подозреваю, что в командных упражнениях традиционных тренингов есть доля лукавства. То, что один человек может сделать за пять минут, команда с трудом реализует за полчаса. И, наконец, на воркшопах совершенно другой уровень ответственности. Если после традиционного тренинга от упражнений остаются только легкие воспоминания цирк уехал, то не решенные на воркшопе вопросы остаются вместе с его участниками. В лучшем случае, они преобразуются в задачи и поручения.

В общем, тема инженерии программных продуктов интересная, форма мастерской – подходящая, буду рад вашим содержательным комментариям и надеюсь на полезную дискуссию.

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

  1. мб я что то упустил нить мысли, но вставлю свои пять копеек 🙂

    не знаю как там у гигантов, а у нас в малом бизнесе нащупалась интересная тема…
    1. из закрытых продуктов с малым функционалом быстро вырастаешь и аппетит приходит во время еды, который не уталяется базовыми фишками
    2. брать заказную разработку – дорого и рискованно

    и вот тут здорово начинает работать кейс менеджмент на базе открытых платформ.

    Сейчас есть серия продуктов, где мы встречаемся раз в неделю или раз в месяц, в зависимости от внутреннего ритма организации.
    Обсуждаем текущую ситуацию, результаты, показатели. Устраиваем мозговые штурмы на тему того что можно улучшить.
    Движение как правило связано с тем что участники совместно определяют задачи и разбирают их.
    Это можно назвать воркшопами? 🙂

    Ранее не удавалось получить такую ситуацию по 2м противоположным причинам:
    1. в закрытых продуктах нечего обсуждать. Ты заперт в ограниченном функционале.
    2. в заказной разработке как правило все скатывается в обсуждения без действий и прогресса.

    в кейс менеджменте нащупалась какая то середина. Одновременно нет рамок для развития, и в то же время настройка происходит достаточно быстро, без сложных задач.

    Построили одну схему работы системы. Поработали, поняли что можно добавить какие то реквизиты или чек листы в шаблон. Добавили и снова работаем – смотрим что получается. Причем как правило это происходит прямо в ходе совещания. Менять то шаблоны там не сложно. Мышкой тока тыкать надо уметь 🙂

    А где тут архитектура? Про архитектуру на этих воркшопах ни слова.
    Есть спорные решения. Они в ходе мозговых штурмов по возможности отсекаются. Если то или иное решение явно имеет минусы и их можно заметить на этапе проработки решения.
    Но вот что действительно дает возможность работу в таком формате, это механизмы адаптивного кейс менеджмента и веб-платформы. Мне так кажется.
    Ранее так не получалось 🙂

  2. Кстати, за книжку спасибо! Уже много раз слышал ее упоминание тут. Как раз закончил читать книги Голдратта и думал чем бы еще занять свой мозг на ночь глядя 🙂 И тут оппа! Почитаю 🙂

Добавить комментарий для Анатолий Юмашев Отменить ответ

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