TwitterПродукты и платформы в корпоративной среде
Posted on February 14th, 2011 by Max Kraynov
Любой опытный продуктовод сталкивался с практически нерешаемой задачей, состоящей в необходимости построить новый продукт на новой (как правило – специально построенной для этого продукта в надежде на переиспользование) платформе. Основная сложность тут в том, что разрабатывать платформу и продукт одновременно практически невозможно, и поэтому их пути разойдутся очень скоро. Почему?
- Платформа редко монетизируется напрямую, поэтому крайне сложно доказать её приоритет перед продуктом.
- За исключением владельца платформы её полностью не понимает никто, несмотря даже на постоянную коммуникацию с менеджерами продуктов, использующих эту платформу.
- Смысл функционала платформы трудно доказать, т.к. каждая функция требует примера прибыльного продукта конкурента, использующего такую функцию. Т.к. все конкуренты смотрят друг на друга и ждут, когда кто-то что-то реализует, вполне возможен deadlock.
- (Вариант 1) Набор функций продукта, базирующегося на ещё не построенной платформе, постоянно “плавает”, т.е. воображение менеджера продукта не может связать идеи с реальностью.
- Судить менеджера продукта за это нельзя.
- (Вариант 2) Безынициативный менеджер продукта может просто сделать обёртку над функциями платформы и назвать её функцией продукта.
- Это вредит всем, т.к. в бизнес-кейсе будет тяжело показать, из какого бюджета делалась данная функция.
- Хуже, когда менеджер продукта, не знающий, как работает функция на самом деле, обещает, что обёртка будет делать что-то отличное от функции платформы.
- (Вариант 3) Разработчик платформы может столкнуться с тем, что к моменту выпуска платформы продукты, базирующиеся на этой платформе, были либо отменены, либо реализованы с использованием скотча и жвачки.
- Платформа почти никогда не разрабатывается в срок и в нужном объёме. Любой продукт, зависящий от платформы, будет страдать.
Что делать?
- Сначала разработать платформу, а потом продукты.
- Разработку можно вести параллельно, если: а) можно сделать заглушки для ряда важных функций, а интегрироваться по-живому позже; б) сделать заглушки для низкоприоритетных функций.
- Купить или лицензировать платформу и строить на ней продукты.
- Разработать платформу и заставлять кого-то другого строить на ней продукты. Потом стороннего разработчика можно купить.
Filed under: Бизнес, Мысли вслух
Подписаться по Email
[..] новый продукт на новой (как правило – специально построенной для этого продукта в надежде на переиспользование) платформе[..]
Исходя из своего более чем 10-летнеего опыта айтишника в прошлой жизни – могу сказать, что такого рода ситуаций надо только всячески избегать.
Типичная управленческая ошибка. Я называю это – ‘проект схлопнулся в точку’ – когда и работа вроде как бы кипит – люди что-то делают, задерживаются на работе, мечутся, срывают дедлайны… но и результата никакого, в терминах конечного (т.е. прикладного) функционала не видно.. все силы уходят на разработку т.н ‘платформы’, которая в 99.9 случаев оказывается потом все равно – на помойке.
Такой вот родовой дефект у made-in-russia программистов – кулибинство.. умные слишком чтоб просто кодить 😉
Если продукт вместе платформой выживают, то себестоимость разработки следующего продукта в разы дешевле первого. В моем опыте как раз была платформа которая окупилась за счет создания следующих аналогичных продуктов правда с другой тематикой.
Но то, что в 99% случаях платформы выкидываются лежит не на программистах, а на инициаторах продукта, т.е. управленцах, которые просто перекидывают планирование разработки на программистов, при этом забывая им сказать истинную цель продукта, да и вообще много чего умалчивают. Отсюда программисты делают не верные выводы.
Т.е., например, управленцы хотят готовый продукт через, скажем, пол года, а окупаемость через год. И как правило добавляют, а если это выстрелить то будем развиваться, богатеть и весело жить.
Программисты это понимают как “раз уж планируется создание продуктов аналогичных заказанному, то разумней создать платформу которая _потом_ позволит нам клепать _любые_ продукты за 5 минут”. Доносят эту мысль до управленца, тот соглашается, потому что нихрена в этом не понимает, и работа начинается. Таким образом, с точки зрения программиста решение создать платформу было правильным, но с точки управленца ошибочным.
Ну, а когда все разваливается управленцы просто заявляют, что программисты его обманули и вообще вся вина на них.
2 Alexander Dobrolyubov,
В большинстве проектов с которыми я имел дело платформы тупо представляли собой вариации (и дааалеко не лучшие) чего-то существующего – то кэш (любимая тема!), то object-relational mapping, то какой-то универсальный SQL, то поиск по объектным деревьям в памяти (ну типа – в базу это ведь не круто, это ж медленно), то model-view-container, то (даже!) парсинг XML, то свои транзакции, то еще уйма каких-то библиотечек, оберток итп.. Что не проект – то платформа..
При том, что базовая технология – J2EE – сама по-себе весьма богатая на эти дела вещь. Там все есть.
Почему проекты ‘схлопываются’? Программистов несет, а менеджмент не рубит (тоже правда) – где то так в кратце..
[..]Что делать?[..]
2 Max: Макс, а ты на какой стадии ‘проблемы продукт-платформа/ находишся – на стадии принятия решения ДО начала разработок или преддедлайна, когда уже надо что-то выатить и показать?
Это не я, это “мой знакомый” 🙂 Посередине, когда песец уже издалека машет хвостом.
Alexander Dobrolyubov +1
Базовая, классическая ошибка (сам на этих граблях стоял по молодости) – попытка создать конструктор (ох, простите, платформу), а потом из него чего-то собирать.
Не работает. Причин тому масса. Во-первых, заказчики не знают чего они хотят. Во-вторых, менеджмент не знает, чего хотят заказчики и не знает чего хочет сам. В-третьих, программист не рубит в предметной области и будет разбираться в ней “по ходу дела”, влезая в детали. В результате: чего собирались написать и чего сдали заказчику это, как говорят в Одессе – “две большие разницы”. Единственный практичный путь создания платформы – создавать ее путем реинженеринга из удачного, пусть даже и сыроватого продукта.
Говорят, что любой разработчик мечтает переписать готовую программу. Ибо именно теперь он наконец-то понимает как ее следовало писать. Не знаю, каждый ли, но я других не встречал. Да и сам такой же. (Пусть и был им в прошлом) Вот только переписывать не надо. Надо факторизовать и превращать в платформу.
Преобразование продукта в платформу по затратам составляет около четверти затрат на разработку продукта и чаще всего весьма точно прогнозируется по времени. И это оправданные затраты, при наличии перспектив и продукта. У опробованного и внедренного продукта!
Критерии, согласно которым можно переходить к созданию платформы из продукта, могут быть разные. Мы используем очень простой – три успешных внедрения (с доработкой напильником под каждое ), и еще минимум два в перспективе. Однако не смею порекомендовать такой критерий всем: у нас довольно специфичная область, всего 750 клиентов на весь рынок. Все друг друга знают, все друг друга не любят. У всех свои собственные требования (штамповка исключена, или, как минимум, сильно затруднена).
Еще в конце семидесятых родился подзабытый сегодня принцип разработки: Make it run, make it right, make it fast, make it small. Беда случается когда эта последовательность действий нарушается. В случае с платформой, например, “make it right” вытягивается на первую позицию. В случае с переписывание XML парсера (см. выше), первым становится “make it fast”. Хотя с другой стороны, и того хлеще, мне приходилось переписывать работу с текстовым буфером. Но это была оптимизация работающего продукта. Внедренного и находящегося в эксплуатации. А не подход типа: “как было бы круто, если …”
В любом случае, создание платформы это формализация совместного опыта разработчиков и менеджмента, а не реализация их мечтаний.
Чуствую, что большинство сталкиволось с разработкой нового продукта на новой платформе. 🙂 🙂 🙂
Весьма сомнительное удовольствие.
Буквально на днях столкнулся с этим. Результат? Отказались от разработки платформы и взяли приемлемый готовый вариант.
Так, как 10% функционала решают 90% задач. Остальными 10% практически не пользуются.
А из за этого иметь геморой с согласованиями между командами разработчиков как то не хочется.
А делать и платформу нужно если ты первый. В противном случае – центрироваться а продукте.
Пример?
Заклятые друзья французского автопрома Ситроен и Пежо.
Ситроеновцы бросили все силы на создание узлов и агрегатов своей 308 модели. А Пежо – использовал базу 308 модели и уделил всё внимание (финансовое) дизайну модели С4.
Результат: С4 оказался более продуманой машиной и попал в большинство списков, как рекомендованый для сдачи в аренду.
Я пропагандирую следующий принцип: волатильность функционала продукта на этапе анализа в разы выше волатильности функционала платформы. Поэтому их нельзя разрабатывать одновременно.