Продукты и платформы в корпоративной среде

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

  • Платформа редко монетизируется напрямую, поэтому крайне сложно доказать её приоритет перед продуктом.
    • За исключением владельца платформы её полностью не понимает никто, несмотря даже на постоянную коммуникацию с менеджерами продуктов, использующих эту платформу.
    • Смысл функционала платформы трудно доказать, т.к. каждая функция требует примера прибыльного продукта конкурента, использующего такую функцию. Т.к. все конкуренты смотрят друг на друга и ждут, когда кто-то что-то реализует, вполне возможен deadlock.
  • (Вариант 1) Набор функций продукта, базирующегося на ещё не построенной платформе, постоянно «плавает», т.е. воображение менеджера продукта не может связать идеи с реальностью.
    • Судить менеджера продукта за это нельзя.
  • (Вариант 2) Безынициативный менеджер продукта может просто сделать обёртку над функциями платформы и назвать её функцией продукта.
    • Это вредит всем, т.к. в бизнес-кейсе будет тяжело показать, из какого бюджета делалась данная функция.
    • Хуже, когда менеджер продукта, не знающий, как работает функция на самом деле, обещает, что обёртка будет делать что-то отличное от функции платформы.
  • (Вариант 3) Разработчик платформы может столкнуться с тем, что к моменту выпуска платформы продукты, базирующиеся на этой платформе, были либо отменены, либо реализованы с использованием скотча и жвачки.
  • Платформа почти никогда не разрабатывается в срок и в нужном объёме. Любой продукт, зависящий от платформы, будет страдать.

Что делать?

  1. Сначала разработать платформу, а потом продукты.
    1. Разработку можно вести параллельно, если: а) можно сделать заглушки для ряда важных функций, а интегрироваться по-живому позже; б) сделать заглушки для низкоприоритетных функций.
  2. Купить или лицензировать платформу и строить на ней продукты.
  3. Разработать платформу и заставлять кого-то другого строить на ней продукты. Потом стороннего разработчика можно купить.

Ещё о бизнесе.

Подписаться по Email

8 комментариев to “Продукты и платформы в корпоративной среде”

  1. [..] новый продукт на новой (как правило – специально построенной для этого продукта в надежде на переиспользование) платформе[..]

    Исходя из своего более чем 10-летнеего опыта айтишника в прошлой жизни — могу сказать, что такого рода ситуаций надо только всячески избегать.

    Типичная управленческая ошибка. Я называю это — ‘проект схлопнулся в точку’ — когда и работа вроде как бы кипит — люди что-то делают, задерживаются на работе, мечутся, срывают дедлайны… но и результата никакого, в терминах конечного (т.е. прикладного) функционала не видно.. все силы уходят на разработку т.н ‘платформы’, которая в 99.9 случаев оказывается потом все равно — на помойке.

    Такой вот родовой дефект у made-in-russia программистов — кулибинство.. умные слишком чтоб просто кодить 😉

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

    Но то, что в 99% случаях платформы выкидываются лежит не на программистах, а на инициаторах продукта, т.е. управленцах, которые просто перекидывают планирование разработки на программистов, при этом забывая им сказать истинную цель продукта, да и вообще много чего умалчивают. Отсюда программисты делают не верные выводы.

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

    Программисты это понимают как «раз уж планируется создание продуктов аналогичных заказанному, то разумней создать платформу которая _потом_ позволит нам клепать _любые_ продукты за 5 минут». Доносят эту мысль до управленца, тот соглашается, потому что нихрена в этом не понимает, и работа начинается. Таким образом, с точки зрения программиста решение создать платформу было правильным, но с точки управленца ошибочным.

    Ну, а когда все разваливается управленцы просто заявляют, что программисты его обманули и вообще вся вина на них.

  3. 2 Alexander Dobrolyubov,

    В большинстве проектов с которыми я имел дело платформы тупо представляли собой вариации (и дааалеко не лучшие) чего-то существующего — то кэш (любимая тема!), то object-relational mapping, то какой-то универсальный SQL, то поиск по объектным деревьям в памяти (ну типа — в базу это ведь не круто, это ж медленно), то model-view-container, то (даже!) парсинг XML, то свои транзакции, то еще уйма каких-то библиотечек, оберток итп.. Что не проект — то платформа..

    При том, что базовая технология — J2EE — сама по-себе весьма богатая на эти дела вещь. Там все есть.

    Почему проекты ‘схлопываются’? Программистов несет, а менеджмент не рубит (тоже правда) — где то так в кратце..

  4. [..]Что делать?[..]

    2 Max: Макс, а ты на какой стадии ‘проблемы продукт-платформа/ находишся — на стадии принятия решения ДО начала разработок или преддедлайна, когда уже надо что-то выатить и показать?

  5. Это не я, это «мой знакомый» 🙂 Посередине, когда песец уже издалека машет хвостом.

  6. Alexander Dobrolyubov +1

    Базовая, классическая ошибка (сам на этих граблях стоял по молодости) — попытка создать конструктор (ох, простите, платформу), а потом из него чего-то собирать.

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

    Говорят, что любой разработчик мечтает переписать готовую программу. Ибо именно теперь он наконец-то понимает как ее следовало писать. Не знаю, каждый ли, но я других не встречал. Да и сам такой же. (Пусть и был им в прошлом) Вот только переписывать не надо. Надо факторизовать и превращать в платформу.

    Преобразование продукта в платформу по затратам составляет около четверти затрат на разработку продукта и чаще всего весьма точно прогнозируется по времени. И это оправданные затраты, при наличии перспектив и продукта. У опробованного и внедренного продукта!

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

    Еще в конце семидесятых родился подзабытый сегодня принцип разработки: Make it run, make it right, make it fast, make it small. Беда случается когда эта последовательность действий нарушается. В случае с платформой, например, «make it right» вытягивается на первую позицию. В случае с переписывание XML парсера (см. выше), первым становится «make it fast». Хотя с другой стороны, и того хлеще, мне приходилось переписывать работу с текстовым буфером. Но это была оптимизация работающего продукта. Внедренного и находящегося в эксплуатации. А не подход типа: «как было бы круто, если …»

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

  7. Чуствую, что большинство сталкиволось с разработкой нового продукта на новой платформе. 🙂 🙂 🙂

    Весьма сомнительное удовольствие.
    Буквально на днях столкнулся с этим. Результат? Отказались от разработки платформы и взяли приемлемый готовый вариант.
    Так, как 10% функционала решают 90% задач. Остальными 10% практически не пользуются.
    А из за этого иметь геморой с согласованиями между командами разработчиков как то не хочется.
    А делать и платформу нужно если ты первый. В противном случае — центрироваться а продукте.

    Пример?
    Заклятые друзья французского автопрома Ситроен и Пежо.
    Ситроеновцы бросили все силы на создание узлов и агрегатов своей 308 модели. А Пежо — использовал базу 308 модели и уделил всё внимание (финансовое) дизайну модели С4.
    Результат: С4 оказался более продуманой машиной и попал в большинство списков, как рекомендованый для сдачи в аренду.

  8. Я пропагандирую следующий принцип: волатильность функционала продукта на этапе анализа в разы выше волатильности функционала платформы. Поэтому их нельзя разрабатывать одновременно.