1-й в Украине сертификационный курс по UX от UXQB — крупнейшего в мире комьюнити UX специалистов
×Закрыть

Зачем сервисной компании делать свой продукт

Сколько раз доводилось слышать о том, что «стране нужно больше стартапов!», «продуктовые компании — добро, аутсорсинг — зло»... Можно долго спорить о преимуществах и недостатках разных бизнес-моделей, если не принимать во внимание тот факт, что продуктовая экосистема — иногда логичное продолжение экосистемы сервисной. Хороший пример — IT-рынок Израиля. Еще 15-20 лет назад это был аутсорсинговый придаток США. Сегодня же — одна из наиболее инновационных экономик мира, которую часто сравнивают с Кремниевой долиной.

На самом деле подобная трансформация происходит на уровне многих стран и даже отдельных компаний. Чтобы не быть голословным, расскажу про проект, который мы создавали последние полгода в GlobalLogic.

Немного истории

Есть у нас один уникальный клиент, с которым мы работаем уже 8 лет — компания Avid. Это известный производитель решений для телевизионной, музыкальной и киноиндустрии. Создание многих фильмов, записи и трансляции концертов и других событий (например, Олимпийских игр или мировых турне звезд) не обходятся без участия Avid.

Чтобы лучше понять, для чего нужны решения Avid, возьмем, как пример, один из многих сегментов, где компания предлагает свои продукты. Итак, представьте студию, заточенную на полный цикл производства телевизионных новостей. Для того, чтобы выпустить в эфир одну 30-секундную историю, скажем, о победе Джамалы на Евровидении, студия проделывает колоссальную работу по трансформации данных.

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

Звучит достаточно сложно. Но решения вроде тех, что предлагает Avid, существенно автоматизируют весь рабочий процесс. Правда, они же и вносят в процесс некоторые технические ограничения. Условно, нельзя вот так просто взять и в обход описанной выше процедуры использовать в новости видеоролик, который вы принесли в студию на «флешке» или только что сняли на камеру своего смартфона.

В Avid знали о существовании такой проблемы, но не могли решить ее в рамках существующего роадмапа продукта и глобальных планов. Поэтому у нас возникла идея создать собственный продукт для решения такой проблемы. Нам очень помогло то, что какое-то время назад Avid объявил о запуске инициативы по строительству экосистемы для сторонних разработчиков (по сути, аналог рынка приложений, который сегодня есть у многих крупных игроков, например, Apple или Google). В результате появился наш продукт под названием FileSystem Connector.

Идея очень проста: используя API платформы, мы можем добавлять в производственный процесс обычные медиа-файлы, индексировать и искать их на внешних носителях или в сетевых хранилищах, автоматически конвертировать в нужный формат и регистрировать в системе. Звучит несложно, но только потому, что вся рутинная работа происходит под капотом, вдали от пользовательских глаз :)

Интерфейс FileSystem Connector

От идеи к решению

В свое время мы смогли донести нашу задумку руководству компании и заручиться поддержкой нашего плана. Мы получили некоторый карт-бланш — команду из 6 человек и несколько месяцев времени. В этот срок сумели сделать полностью функциональное приложение. Его суть не в каком-то принципиально новом подходе, но в удачной комбинации существующих возможностей решений Avid, автоматизации и упрощении операций по работе с файлами, и, как сейчас модно говорить, в более простом и привычном user experience.

Результат порадовал не только нас самих, но и Avid. Поэтому нас пригласили показать FileSystem Connector на Avid Connect в Лас-Вегасе. Это огромная конференция для тысяч партнеров и клиентов Avid со всего мира (среди них такие гиганты как NBC или FOX). Мы представляли продукт сразу после выступления CEO компании Avid на открытии конференции, после чего провели подробную техническую сессию среди заинтересованных клиентов и партнеров:

Сразу после Avid Connect мы, уже совместно с Avid, представляли продукт для телевизионной индустрии на крупнейшей в мире выставке для бродкастеров — NAB. Результатом стал большой интерес со стороны потенциальных клиентов. Многие пользователи давно мечтали о такой достаточно очевидной возможности. Но быстро реализовать ее в сложном продукте и большой компании редко представляется возможным. Именно поэтому наш небольшой стартап пришелся как нельзя кстати.

Стартап внутри сервисной компании

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

Нужно понимать, что GlobalLogic — сервисная компания, и выпуск собственных продуктов не является ее приоритетом (ее организационная структура попросту не адаптирована для выпуска собственных продуктов). Нам нужно как-то менять восприятие наших менеджеров по продажам, чтобы строить адекватный канал сбыта готового решения. Нужно тесно работать с юридическим отделом, чтобы составить пользовательское соглашение и проконтролировать лицензионную чистоту конечного продукта. Нужно взаимодействовать с отделом маркетинга, чтобы вместе придумать эффективное позиционирование и стратегию продвижения отдельного продукта, а не самой компании и ее услуг. Руководить процессом создания промо-роликов и других материалов, необходимых для продвижения и продаж. И конечно же, нам важно работать с восприятием руководства компании, для которого наш проект — это небольшой эксперимент, который может «выстрелить», а может и нет.

Команда проекта

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

Планы и промежуточные выводы

Несмотря на множество вызовов, планы у нас, я бы сказал, наполеоновские. Хотим развивать эту инициативу и в других областях, где уже есть опыт и понимание бизнес-составляющей продуктов, которые мы делаем. И, как следствие, вывести такие проекты на более высокий уровень, объединить их в единую практику и предлагать еще один вид партнерства нашим заказчикам. Это может быть развитие их экосистем за счет сторонних и независимых приложений, revenue-sharing-контрактов на разработку, консалтинг и т. п. И это первая причина делать свои продукты.

Вторая причина — развитие инженерных талантов. Уже сейчас очевидно, что этот проект — отличный опыт для команды, получившей навыки создания собственных продуктов и хорошую тренировку product development mindset. Способность понимать бизнес заказчика и самостоятельно находить технические решения бизнес-задач — наверное, это главное, что сегодня отличает «кодеров» от инженеров, в западном понимании этого слова. И я убежден, что важность и востребованность этих качеств будет только расти.

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


Ну и напоследок. Конечно же, я не хочу сказать, что этот проект в одночасье изменит бизнес GlobalLogic или что в один прекрасный момент все сервисные компании вдруг станут продуктовыми. Скорее всего, сервисная модель будет доминировать на нашем рынке еще многие годы, во многом из-за несовершенства юридической и законодательной базы. Но я убежден, что специализация в определенных перспективных областях (как в нашем случае, это media asset management) открывает перед компаниями интересные перспективы развития бизнеса на основе собственных решений. Для инженеров это хорошая перспектива профессионального роста, возможность полноценно участвовать в создании собственного продукта или решения, учиться не просто выполнять техническую задачу, а браться в первую очередь за решение бизнес-задачи.

Уверен, что в других сервисных компаниях тоже есть свои примеры подобных продуктовых инициатив. Буду рад, если поделитесь вашими историями в комментариях.

LinkedIn

22 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Для инженеров это хорошая перспектива профессионального роста, возможность полноценно участвовать в создании собственного продукта или решения, учиться не просто выполнять техническую задачу, а браться в первую очередь за решение бизнес-задачи.

К сожалению, таким образом вы гробите инженеров.
Условно, у программиста есть 8 часов на работу каждый рабочий день.
Если задачи приходят к нему в виде уже отформатированных тасков и он просто их имплементит, он может, скажем, часа 2 обдумать архитектуру решения, определиться с используемыми для него технологиями, за 3 часа заимплементить, потом оставшиеся 2 часа потестировать, поубирать косяки, навести красоту. В итоге, к концу дня:
1) Инженер освоил на практике новый паттерн/архитектурный подход. Выявил его +/- и научился более-менее с ними бороться.
2) Сделал фичу из состояния TODO в Ready for test.

В итоге: плюс для проекта, фича сделана по графику, плюс для инженера, он освоил новое, его уровень вырос.

По вашей модели.
Из 8 часов инженер потратит сначала 3 на обсуждение идеи с ПО, потом с дизайнером, пот ом с коллегами, пока поймёт, что от него в общем хотят. Предложит свои правки ибо «так пользователю будет лучше» (хотя подобные суждение — вне его компетенции как программиста), выработает совместно с командой новое, более полное видение фичи.
Теперь у него в голове всё правильно уложилось, он может приступать к имплементации. Времени на выбор технологий уже нет, он использует те подходы, к которым привык и плевать, что они увеличивают технический долг, хуже тестируемы, чем существующие, сложнее поддерживаются, главное, что юзер оценит. У него всё равно только 3 часа на имплементацию и 2 часа на отладку/полировку.
В итоге мы получаем реализованную фичу, которая нигде не документирована (логика придумана в результате устного обсуждения с ПО и дизайнером и нигде в истории не осталась) и реализована на устаревших технологиях. Зато сделана с заботой и любовью о конечном пользователе, ага. Но инженер через годик работы в таком режиме уже отстал от своих коллег на год. Т.к. индустрия на месте не стоит, а он не фреймворки изучал и с подходами экспериментировал, а бизнес-логику с клиентом и дизайнером обсуждал в это время. В результате, «инженер» становится экспертом по бизнес-логике и юзер-экспириенсу конкретно вашего продукта, не знает новых подходов и тенденций в разработке и уже не может конкурировать на аутсорсе.

ну а кто мешает вместо 8 часов взять 16? чтобы было качественно спешки быть не должно вообще, она многих отвлекает, поэтому эстимейтить нужно чтобы точно хватило времени, если инженер справится раньше, то возьмет другую таску или отдохнет, потом отдохнувший быстрее сделает следующую таску => не выгорит, не отстанет от коллег, поучаствовал везде (это вероятно понравится следующему работодателю, да и собственно текущий рад будет), задача сделана не хуже, чем если бы инженер занимался только инженерией

да, в 2 раза больше эстимейт, но и работы-то в 2 раза больше и адекватный кастомер это понимает

ну а кто мешает вместо 8 часов взять 16

То есть, берём 2 дня работы инженера на задачу, которую он спокойно сделает за 1 день?
Ради чего?
Первый день будет потрачен по факту на обсуждение бизнес-логики. Не лучше ли на это потратить день не инженера, та-дам! Проджект-менеджера?
Который сам всё обсудит с кастомером и напишет документацию, создаст в джире тасочки. Инженер утром придёт на работу, сделает себе кофе, откроет джиру и просто сделает то, что там, не задавая лишних вопросов?
Разделение труда изобрели ещё древние люди. Крупные компании для того и создаются, чтобы на одно направление был один отдел, на одни задачи — один сотрудник. Какие выгоды в том, чтобы делать из инженера также и эксперта по продукту, специалиста по коммуникациям с клиентами, вместо разделения этих задач между разными людьми?
Смысл погружать инженера в бизнес-логику конкретного проекта?
Завтра он нужен будет на другом проекте, послезавтра на третьем, это должен быть легко заменяемый винтик в корпоративной машине, эксперт по технологиям с минимальным временем входа в любой проект. А не эксперт по работе с конкретным клиентом/проектом.

Первый день будет потрачен по факту на обсуждение бизнес-логики. Не лучше ли на это потратить день не инженера, та-дам! Проджект-менеджера?

ради чего?) не нужен он

Который сам всё обсудит с кастомером и напишет документацию, создаст в джире тасочки. Инженер утром придёт на работу, сделает себе кофе, откроет джиру и просто сделает то, что там, не задавая лишних вопросов?

таких проджект менеджеров не бывает

Разделение труда изобрели ещё древние люди. Крупные компании для того и создаются, чтобы на одно направление был один отдел, на одни задачи — один сотрудник. Какие выгоды в том, чтобы делать из инженера также и эксперта по продукту, специалиста по коммуникациям с клиентами, вместо разделения этих задач между разными людьми?

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

Смысл погружать инженера в бизнес-логику конкретного проекта?

...

Завтра он нужен будет на другом проекте, послезавтра на третьем, это должен быть легко заменяемый винтик в корпоративной машине, эксперт по технологиям с минимальным временем входа в любой проект. А не эксперт по работе с конкретным клиентом/проектом.

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

ради чего?) не нужен он

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

таких проджект менеджеров не бывает

Как говорил мой первый начальник «если ты в жизни чего-то лично не видел, это ещё не означает, что этого нет. Ты сына моего видел? Нет. А он, прикинь, существует.»

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

А ему пофиг на техническую реализацию. Ему поведение с точки зрения пользователя описать и согласовать надо.

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

Программисты и так не будут знать, что делать без представителя клиента и дизайнера.
Ни тот, ни другой расписывать в джире поведение не будут, то есть, на программиста ложится задача ещё и записывать за ними лично то, что они говорят, детализировать, заводить в джиру.
Теперь простой вопрос — эту шелуху точно должен делать человек, стоящий от 12 до 25 долларов в час с навыками программирования и знанием технологий, архитектур и фреймворков? Неужели это не может сделать менее оплачиваемый человек, не имеющий всех этих знаний, который освободит программиста для выполнения его задач?

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

с точки зрения программиста ты прав, только те кто решают как будет обычно не программисты

Как говорил мой первый начальник "если ты в жизни чего-то лично не видел, это ещё не означает, что этого нет. Ты сына моего видел? Нет. А он, прикинь, существует."

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

А ему пофиг на техническую реализацию. Ему поведение с точки зрения пользователя описать и согласовать надо.

этого практически всегда недостаточно

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

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

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

мне в роли программиста приходилось сталкиваться с обратным — когда в джире уже все расписано как делать или спецификации выданы в которых все утверждено, это называется микроменеджмент и это ужасно

Теперь простой вопрос — эту шелуху точно должен делать человек, стоящий от 12 до 25 долларов в час с навыками программирования и знанием технологий, архитектур и фреймворков? Неужели это не может сделать менее оплачиваемый человек, не имеющий всех этих знаний, который освободит программиста для выполнения его задач?

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

этого практически всегда недостаточно

Этого достаточно в 90% случаев. Остальные 10% — уже можно через этого же пиэма спросить у клиента.

если программисты не могут работать из-за того что менеджера нет это решается увольнением программистов

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

мне в роли программиста приходилось сталкиваться с обратным — когда в джире уже все расписано как делать или спецификации выданы в которых все утверждено, это называется микроменеджмент и это ужасно

А что в этом ужасного?
У меня так было на большинстве проектов. Приходишь, открываешь джиру, берёшь оттуда таск, делаешь, как там описано. Есть вопросы — заглянул в спеку, почитал, всё ясно. Сделал — берёшь следующий.
Лучше, чем полдня бегать и выяснять методом перекрёстного допроса, как там должно быть на самом деле.

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

Имел удовольствие делать такой проект.
В итоге, можно даже троллить тестировщика в ответ на любой тикет:"А где написано, что это поведение неправильное? Я это вижу именно так«.
И дальше карусель с привлечением «экспертов» и «авторитетов». Вместо того, чтобы просто посмотреть в спеку и согласиться. А багом то, что нигде никогда никем не описано, быть не может.
Когда ничего нигде не описано — одна и та же логика переписывается по 5 раз, пока её сделают.

ну я считаю что этим должен заниматься человек, который получает больше 25 долларов в час, потому что его ошибка приведет к тому что весь спринт вся команда будет делать не то что нужно

Решается простой верификацией представителем клиента того, что этот человек нагенерит. Которая происходит как раз в процессе создания всех спек. Буквально — проговорили юзкейс, обсудили, договорились, в присутствии клиента записали, он одобрил.

Этого достаточно в 90% случаев. Остальные 10% — уже можно через этого же пиэма спросить у клиента.

не сочиняй статистику на лету

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

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

А что в этом ужасного?
У меня так было на большинстве проектов. Приходишь, открываешь джиру, берёшь оттуда таск, делаешь, как там описано. Есть вопросы — заглянул в спеку, почитал, всё ясно. Сделал — берёшь следующий.
Лучше, чем полдня бегать и выяснять методом перекрёстного допроса, как там должно быть на самом деле.

похоже тебе программирование не интересно вообще, в этом случае все сходится

Имел удовольствие делать такой проект.
В итоге, можно даже троллить тестировщика в ответ на любой тикет:"А где написано, что это поведение неправильное? Я это вижу именно так«.
И дальше карусель с привлечением «экспертов» и «авторитетов». Вместо того, чтобы просто посмотреть в спеку и согласиться. А багом то, что нигде никогда никем не описано, быть не может.
Когда ничего нигде не описано — одна и та же логика переписывается по 5 раз, пока её сделают.

спека точно так же переписывается по 5 раз, а за ней и код

Решается простой верификацией представителем клиента того, что этот человек нагенерит. Которая происходит как раз в процессе создания всех спек. Буквально — проговорили юзкейс, обсудили, договорились, в присутствии клиента записали, он одобрил.

ну и при косяке типа кастомер сам виноват?) и кастомер точно знает что ему нужно?)

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

Этот человек не оставил документации? Если оставил, его можно без проблем заменить другим. Если нет, то весь процесс был построен неправильно. Нет документации — нет проекта.

похоже тебе программирование не интересно вообще, в этом случае все сходится

Мне как раз интересно программирование. А не общение с людьми. Тем более с позиции просителя «ну расскажи мне, что надо сделать, ну пожалуйста. Это ж мне нужен проект, а не кастомеру».

спека точно так же переписывается по 5 раз, а за ней и код

Ключевое слово «за ней».
И тебя никто не морочит вопросом:"Какого хрена ты это так сделал?"
Так было в спеке и все это знают. А новая спека, или доработка старой — какая разница. Главное, что спека есть.

ну и при косяке типа кастомер сам виноват?) и кастомер точно знает что ему нужно?)

Если кастомер сам не знает, что ему нужно, программист — тем более.
К примеру, если приложение фармацевтическое, я за кастомера должен придумать параметры для фильтров препаратов? Может, мне для этого ещё второе образование получить?
А если приложение для таксистов, я должен потаксовать недельку, чтобы понять, какие функции самые востребованные?

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

Этот человек не оставил документации? Если оставил, его можно без проблем заменить другим. Если нет, то весь процесс был построен неправильно. Нет документации — нет проекта.

конечно неправильно, только вот этот процесс предлагаешь ты :) или как ты думаешь все будет работать, если в разработку будут вовлечены будут люди, которые с ней не связаны?

Мне как раз интересно программирование. А не общение с людьми. Тем более с позиции просителя "ну расскажи мне, что надо сделать, ну пожалуйста. Это ж мне нужен проект, а не кастомеру«.

а так получишь не «что делать», а «как делать»

Ключевое слово «за ней».
И тебя никто не морочит вопросом:"Какого хрена ты это так сделал?"
Так было в спеке и все это знают. А новая спека, или доработка старой — какая разница. Главное, что спека есть.

не отвечай на этот вопрос и его перестанут задавать

Если кастомер сам не знает, что ему нужно, программист — тем более.

дык никто не знает, поэтому требования меняются постоянно

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

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

или как ты думаешь все будет работать, если в разработку будут вовлечены будут люди, которые с ней не связаны?

Не нужно быть программистом, чтобы описать, что и как программа делать будет.

а так получишь не «что делать», а «как делать»

Нет. Получишь ровно то же самое, только разбитое на юзкейсы и зафиксированное документально.

дык никто не знает, поэтому требования меняются постоянно

Кастомер знает, зачем ему программа. Значит, может описать какие его проблемы и как она будет решать. Этого достаточно для программиста. Как сделать такую программу он уже сам знает.

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

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

В процессе чтения статьи, возникло ряд вопросов, комментариев и пожеланий


чтобы выпустить в эфир одну 30-секундную историю, ... студия проделывает колоссальную работу по трансформации данных.
Step 1
Step 2
...
нельзя вот так просто взять и в обход описанной выше процедуры использовать в новости видеоролик, который вы принесли в студию на «флешке» или только что сняли на камеру своего смартфона.

... у нас возникла идея создать собственный продукт для решения такой проблемы.

... используя API платформы, мы можем добавлять в производственный процесс обычные медиа-файлы, индексировать и искать их на внешних носителях или в сетевых хранилищах, автоматически конвертировать в нужный формат и регистрировать в системе. Звучит несложно, но только потому, что вся рутинная работа происходит под капотом, вдали от пользовательских глаз :)

Парни, похоже у Вас «слабый» бизнес-аналитик, который «пропустил» (или специально пропустил) существование некоторых сценариев использования в основном бизнес-процессе производства у клиентов компании Avid.

Это подтверждает Ваша фраза:


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

Нужно понимать, что GlobalLogic — сервисная компания, и выпуск собственных продуктов не является ее приоритетом (ее организационная структура попросту не адаптирована для выпуска собственных продуктов).

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

Именно, сервисная компания — это не продуктовая компанияи не должна ей быть.
Поэтому грамотный менеджер крупной компании типа GL, создал бы дочернюю ПРОДУКТОВУЮ компанию в рамках холдинга и передал бы на нее задачи развития продукта и менеджмент продукта. А вот аутсорсить разработку можно было бы как раз в сервисной компании.
Т.е. сервисная компания остается сервисной, но наконец-то в Украине появляется еще одна продуктовая компания которая знает и понимает своих клиентов, и содержит в себе менеджеров разных направлений для развития продуктового направления.

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


Конечно же, я не хочу сказать, что этот проект в одночасье изменит бизнес GlobalLogic или что в один прекрасный момент все сервисные компании вдруг станут продуктовыми. Скорее всего, сервисная модель будет доминировать на нашем рынке еще многие годы, во многом из-за несовершенства юридической и законодательной базы. Но я убежден, что специализация в определенных перспективных областях (как в нашем случае, это media asset management) открывает перед компаниями интересные перспективы развития бизнеса на основе собственных решений.
Классическая стратегия начала большинства стартапов — это начать «подбирать крошки» за крупной компанией.
Часто со временем эти крохи будут становится все больше и больше.

Крупная компания с удовольствием (в смысле здесь только вопрос торга) отдаст на аутсорсинг все что НЕ относиться к ее основному бизнес-процессу.

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

Вот это молодцы. Рома, успехов вашей команде в развитии продукта!

PS: Не останавливайтесь на достигнутом :)

Приятной неожиданностью было увидеть одноклассника на командном фото=)
Молодцы

Хорошая история! Удалось ли уже найти первых покупателей для этого продукта?

Пока еще рано говорить про успехи в продажах. Продукт ориентирован на корпоративный сектор, где покупка не происходит быстро. Сейчас пока еще ведем переговоры, согласовываем юридические аспекты сделок и тп.

Да, продажи — непростое дело. Будет очень интересно узнать, как все будет развиваться. Удачи!

Успехов! Но знаете, западные продукты не называют «File System Connector» ;)

File SC и уже + 100500 к солидности

Соглашусь. Но в данном случае подстраивались под терминологию среды, где понятие «коннектора» является естественным и понятным большинству.

ну, молодцы, коллеги, че :)

Подписаться на комментарии