Наверх ▲

Эффективное управление продуктом или что важно в реальной жизни

Георгий Баркан Георгий Баркан Руководитель разработки технологической стратегии развития пользовательских продуктов «Лаборатории Касперского».
Wr2011 баркан
View more presentations from Ontico

Георгий Баркан: Меня зовут Георгий Баркан. Очень приятно вас всех видеть. Два слова о себе. Я начинал на заказных проектах разработчиком, кем только ни был… Потом постепенно перешел в разработку продуктов. Работал в "Quest Software" – это очень большая ориентированная на продукты компания, работающая для корпоративных заказчиков и производящая очень много разных продуктов.

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

Потом я работал в российском представительстве "Microsoft". Там было много всего интересного. Сейчас я работаю в "Лаборатории Касперского", занимаюсь потребительскими (англ. consumer) продуктами в основном.

Хотел бы сказать, что в целом я здесь выступаю по своей инициативе. Во многом мысли в докладе – это некое обобщение своего опыта, каких-то наблюдений. Не обязательно может совпадать с точкой зрения "Лаборатории Касперского". Совершенно не обязательно!

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

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

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

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

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

Если посмотреть уже подробнее в этих направлениях, что же здесь самое главное? Что, на мой взгляд, непосредственно несет в себе по существу функция управления продуктом? То, что, наверное, нельзя делегировать куда-то или очень сложно. Мне показалось, что это самое главное. 

Это видение продукта с точки зрения непосредственно управления продуктом и координация с командой. А еще важнее коммуникация – люди должны вас слышать, должны понимать, что за продукт мы делаем.

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

Задачи, которые делегировать нужно – это, конечно, управление или вообще построение модели продаж вашего продукта, это требования, это user experience, это разбор обратной связи от ваших пользователей. Делегировать эти задачи нужно, но лучше, конечно, если такое делегирование будет под неким административным прямым управлением. Это очень важные задачи.

Еще задач очень много других, которые, на мой взгляд, можно делегировать вообще любым способом. Главное здесь – результат. Это рыночные исследования, это работа с экосистемой либо продаж, либо… Могут быть очень разные здесь. Зависит от моделей продаж вашего продукта. 

Собственно маркетинговые задачи, формулирование меседжей, донесение их до пользователя, планирование разработки, планирование запуска продуктов. Это такой… Видите, сколько много всего. Это все управление продуктом. Что же тут самое главное?

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

Если взять некую усредненную Hi-Tech компанию… Я в одной из них работал, я ее примерно беру как модель. Есть такой уже не роль, а все-таки человек, который называется product-manager.

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

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

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

Если взять "Google", то видно, здесь почти то же самое. Действительно, "Google" рассказывает, что product-manager у них занимается всем. Но при этом у них нет никаких конкретных инструментов. Человека выпускают в свободное плавание. Таких людей набирают специальным образом. 

При этом технические роли у "Google", они сами по себе тоже очень такие сильные люди, очень smart-люди. Есть такой (у них называется это techniсal lead) человек, который управляет небольшой группой разработки. Поскольку они… Там разработчики сами по себе smart, а techniсal lead еще больше. Конечно, этот человек может существенно больше помогать с точки зрения [инвижининга] (?), планирования продукта, понимания, что нужно продукту.

"Microsoft". Здесь, если вы обратили внимание на разницу, многое становится наоборот. На самом деле у них появляется такая роль как program-manager. Это некая особенность терминологии. 

На самом деле program-manager – это главный человек в продуктовой разработке "Microsoft" в отличие от product-managerа. Здесь это видно. У product-manager’а остаются по существу только маркетинговые функции и все, что связано с организацией продаж продукта. А весь объем задач управления продуктом, понимания, что это за продукт, исследований, разработки и, самое главное, приведение всего этого в единый работающий механизм – все это делает человек, который называется program-manager.

Я забыл сказать, что для примеров "Google", у меня есть ссылочки, в конце вы их сможете в слайдах скачать, почитать. В случае "Google" есть человек Пунит Сони (Punin Soni), он ведет блог. У него есть рассказ про то, кто такой product manager в "Google". 

Про "Microsoft" на само деле… Такой человек Стивен Синофски (Steven Sinofsky), который сейчас руководит разработкой "Windows 8". Он на самом деле очень интересный человек в том смысле, что ему досталась "Windows" в том состоянии, в котором ее очень многие не любят. Примерно где-то "Windows Vista". 

Это человек, который принимает колоссальные усилия по перестройке вообще организации и бизнеса "Microsoft". У него есть блог-пост, очень большой, очень подробный и интересный, который рассказывает, кто такой program manager "Microsoft". Если вам интересно, тоже ссылочка у меня есть, потом можно будет почитать.

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

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

При этом известно, что фактически ключевые люди в разработке продуктов "Apple" – это дизайнеры. Люди, которые в первую очередь отвечают за формирование видения продукта и детализацию требований, проработку user experience (здесь это самая, пожалуй, важная часть), driver(?)-исследования, разработку и, в общем, координирующую функцию тоже выполняют. Это "Apple". 

Про "Apple" не очень много, но есть некая интересная информация. Так же ссылочку можно посмотреть будет.

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

Основные действующие лица в разработке продуктов: конечно, пользователь, люди, занимающиеся продажами, люди, занимающиеся поддержкой, люди, которые делают продукт, разработка. Еще может быть экосистема – это уже не часть компании, это внешние либо партнеры, либо специальным образом построенный канал продаж, который что-то делает.

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

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

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

Еще есть интересный момент. Разработкой нужно управлять. 

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

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

Конечно, механизму поддержки нужно помогать. Это очень важно, потому что от этого зависит удовлетворенность ваших пользователей.

Еще что важно с экосистемой. Нужно понимать, что это внешние люди. Они приносят пользу. У вас вообще бизнес-модель может быть во многом на этом построена. Но влияние на управление продуктом, влияние на разработку (прямое влияние) не желательно. 

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

Поэтому контролировать коммуникации и взаимодействия – очень важно. Это одна из самых основных функций управления продуктом.

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

Я попробовал нарисовать, как примерно выглядит организационно, административно некая усредненная компания, занимающаяся разработкой каких-то hi-tech продуктов. Программных продуктов, конечно.

Как правило, есть R&D, причем это отдельная большая ветка, которая начинается сразу прямо под главным руководителем компании. Дальше в таком случае, как правило, внутри R&D принят проектный подход. 

Продукт, выпуск новой версии продукта – это всегда проект. У него есть project manager, и project manager’у подчиняются разработчики. Там может быть более матричная структура, менее матричная структура, но в целом некое достаточно сильное административное прямое подчинение: разработчики имеют своего именно такого проектного руководителя. 

Другая ветка – управление продуктом. Это собственно функции формирования scope(?) продукта, маркетинговой составляющей. 

В такой ситуации объем здесь функциональных задач очень большой, как правило, один человек не способен это все охватить. Поэтому как минимум маркетинговые задачи всегда выделяются в отдельную роль. Чаще всегда она называется product marketing manager. А product-manager – это все-таки scope(?) продукта…

Здесь и возникает наибольшее затруднение: как сказать разработчикам, как сказать R&D, что же нужно делать?

На слайде сразу возникает очень много пунктирных стрелочек, dotted line.

Иногда (как-то так исторически выстраивается) product manager все-таки завоевывает доверие команды разработки: команда ему доверяет и делает то, что product manager предлагает делать в продукте. 

Иногда это не работает. Причины… Чаще всего – общий язык сложно найти. Product manager – это бизнес, маркетинговый человек. Технари – это технари. 

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

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

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

У них есть фактически все, кроме канала продаж и совсем специальных функций типа поддержки и маркетингового продвижения (рупора маркетингового). Это, как правило, называется Business Division

Пример такого Business Division – "Windows", которым Стивен Синофски руководит полностью. По количеству человек в масштабе "Microsoft" это, наверное, 6 – 8 тысяч человек всего. 

Внутри Business Division есть продуктовые группы, в продуктовых группах есть продукты. Дальше – основная административная вертикаль в Business Division "Microsoft", которая называется program manager. Помните, я говорил, что у них самый главный человек – program manager. 

Так вот. Эти самые программ менеджеры, поскольку у них много задач, покрывают и scope(?) продукта, коммуникации и координации, и еще техническую часть разработкво многом и. 

Конечно, такой человек, один конкретный человек, может заниматься только очень небольшим scope’ом(?) большого продукта. Либо он должен делегировать. 

Таким образом, у них получается довольно глубокая прямая административная вертикаль program management, в котором постепенно доходят до конечных program manager’ов, каждый из которых занимается какой-то небольшой фичей в продукте либо группой фич. 

Команды разработки во многом дальше просто принадлежат своей продуктовой группе. Это просто большой пул, там никакого особого административного подчинения… Оно довольно плоское, в общем-то.

А product management начинается довольно высоко, идет отдельно. Он идет от такого бизнес-дивизиона отдельного. Там административная вертикаль тоже не очень глубокая. Но это люди, которые занимаются непосредственно уже только бизнес-составляющей и маркетинговой. 

Видите, что здесь интересно получается. Каждый programm manager, занимающийся своей областью, фактически руководит своей маленькой командой разработки. Он для них и project manager тоже – отвечает за выпуск определенного функционала. 

С другой стороны, эти самые programm managers должны понимать, что за продукт они делают, в конце концов. Им для этого надо в какой-то момент понимать, что там с рынком, как это вообще продать можно будет. Поэтому они общаются и с product managers тоже. Не просто общаются. Они во многом должны определенным образом сформировать "лицо" продукта. За это отвечают programm managers. 

Product manager – это в достаточной степени уже маркетинговый ресурс. Они говорят, сможем мы это продать или нет. У них, конечно, тоже есть свое мнение. Поэтому на них требуется оказывать определенное влияние. Там, конечно, тоже возникают конфликты. Там есть инерция определенная. Но их разрешению способствует то, что в этих "ветки" programm management много уровней. Фактически для решения каких-то проблем не надо высоко это дело эскалировать. До Синофски там ничего не доходит. Там все решается на более низких уровнях. В целом, более-менее эффективно получается. 

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

Не могу удержаться, чтобы вас немножко не развлечь. Мне очень нравится это место в книжке Артура Хейли "Отель"

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

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

На менеджера продукта навешано, конечно, очень много. Он отвечает за успех. Его "подвесят" первым, если продукт не достигает своих целей. Поэтому он должен быть еще и очень ориентирован на результат. 

Как этого всего добиться. Невозможно, чтобы у менеджера продукта были все функции, прямое административное управление вообще всеми. Тогда он должен быть заведующим вообще всего в компании. Он вынужден полагаться на то, что люди доверяют ему. Он не является их прямым начальником. Но то, что он их просит сделать – это то, что, на самом деле, нужно. Этот человек должен завоевывать доверие людей в компании. У него должна быть определенная политическая воля. Он должен понимать, что многие вещи, которые он делает, могут… 

У меня есть коллеги, которые этим занимаются. Они считают, что product manager – это не то что бы «расстрельная» должность, но незавидная участь. На самом деле, это есть в этом некий сермяжный смысл, потому что человек должен понимать, что политическая воля нужна. Тут, конечно, хорошо, если он такой поддержкой политической может заручиться от руководства.

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

Мне хочется еще раз вернуться к функциональным областям, о которых мы говорили. Если посмотреть в правой части – это та составляющая необходимейшая, которую никак никому нельзя делегировать. Это фактически то, что человек делает, чтобы ответить на вопрос "как мы строим продукт". Он должен всем это рассказать и всех организовать правильным образом, чтобы добиться определенного результата. С другой стороны, это человек, который отвечает на вопрос "Почему мы делаем именно это в продукте". Эти две составляющие, одна и другая, не менее важны. 

Со стороны человека "почему" требования к продукту – на мой взгляд, ключевой момент. К сожалению, за 45 минут очень сложно все здесь рассказать. Я позволю себе вас отослать к своему докладу на "Software People". Я там немножко пофилософствовал на тему того… 

Какое самое правильное слово в управлении требованиями? По мнению многих, требования – это что? Спецификация – это "как" мы что-то делаем. А требования – это "что". Чаще всего, это не совсем правильно. Требования – это "почему", а не "что"

"Что" уже получится само. Надо сначала ответить на вопрос "почему"

Тут у меня возникло очень интересное философское наблюдение. Есть замечательная книжка (она у меня в ссылках есть). Кэрри Паттерсон (и там много еще авторов). Книжка называется "Influencer: The Power to Change Anything". Она есть, к сожалению, только на английском. Но ее можно на "Amazon" спокойно купить. Я вам ее крайне-крайне рекомендую, если вы собираетесь заниматься управлением продуктами, и прочитать. Там очень подробно… Там вообще целая теория (научная, я бы сказал) того, как влиять на людей. Даже необязательно на людей. Вообще влиять на изменения, где угодно (в мире, в организации, в каком-то процессе). 

Одна из самых сильных методик или принципов влияния называется… Ее авторы называют "tall stories". Людей словами убедить невозможно, когда вы их пытаетесь именно убедить. Но влиять словами на людей можно, и можно очень успешно. Для этого надо их не убеждать, а просто рассказывать им, как хорошо будет. Им нужно рассказать историю. Это должны быть не лозунги, а именно история. О том, что так хорошо, наш продукт должен делать вот это и это. Тогда пользователь его возьмет и решит сразу кучу своих проблем, и мы будем успешны. Нужно рассказывать историю.

Если посмотреть на эти два крайних, в кружочках, которые у нас были (две сферы функционального наполнения роли product manager) – это коммуникационная составляющая и видения или требования к продукту. Нужно использовать возможности коммуникации для того, чтобы людям рассказывать, что делает наш продукт. Тогда они вам поверят и будут делать то, что вы хотите. 

Тут очень интересно перекликаются требования и вообще видение продукта – это на самом деле "user stories". Вам надо рассказывать истории того, как пользователь будет использовать ваш продукт. Тогда люди за вами пойдут. 

В заключение мне очень хочется вам пересказать еще одну интересную историю. Есть такой интересный человек – Simon Sinek. Он написал очень интересную книжку. У него было выступление на TEDx (это конференции, сериями проходящие). Он там рассказал (ссылочку тоже очень рекомендую вам посмотреть) очень интересную историю о том, как, собственно, происходят…

Он там начал очень провокационно. Говорит: "Все говорят, что "Apple"– это не продуктовая компания. Это вообще не компания и не бизнес. Это религия. Компания, которая делает то, что нравится одному человеку – Джобсу. При этом как-то умудряется то, что они сделали, всем продавать". 

Многие люди, которые занимаются product management и рассказывают об этом… Вот они вам что-то говорят-говорят, потом спросить их: "А как это в "Apple" работает?". Очень часто можно реакцию увидеть, прямо скажем, весьма негативную: "Да перестаньте вы спрашивать про "Apple"! У них вообще нет product management. Они непонятно что вообще делают". 

Вот этот Simon Sinek как раз подметил крайне интересную вещь, на мой взгляд, что "Apple" как раз все делает правильно, и product management у них есть. Просто нужно начинать с определенных правильных вещей. 

Он говорит: "Давайте сравним, как свой продукт продвигают обычные компании. Что если "Apple" был бы компанией обычной, как все – как бы они продвигали свой продукт. Сначала мы отвечаем на вопрос "как". Как же. У нас самые лучшие разработчики, самые лучшие технологии. Поэтому мы делаем самые совершенный продукт в мире. Что мы делаем. Естественно, мы решаем ваши проблемы. Почему мы их можем решить. Потому что у нас самые лучшие технологии. А почему мы это делаем. Ну, как же. Мы же хотим вам продать свой продукт. Он самый лучший. Хотите у нас его купить? Почему вы до сих пор еще в этом не уверены?". 

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

Он говорит: "На самом деле, "Apple" делает совершенно по-другому". Послушайте, что говорит "Apple": "Мы верим, что дизайн спасет мир. Мы уверены в том, что мы, "Apple", являемся носителем этого знания и света прекрасного. Поэтому мы считаем, что продукты должны иметь прекрасный дизайн, быть бескомпромиссно спроектированы. Для этого мы нанимаем самых лучших дизайнеров и самых профессиональных инженеров. Для этого мы постоянно бросаем вызов существующим технологиям и создаем новые. Хотите купить наш продукт?".

Такая правильная последовательность задавать вопросы – это в определенном смысле то, что очень часто бывает пустым звуком. Говорят: "У компании, продукта должна быть миссия". На мой взгляд, это ключевой момент. Product manager должен нести миссию своего продукта. А миссия очень просто формулируется. Это просто ответ на вопрос, почему мы делаем наш продукт. 

Это ссылочки, которые я вам обещал. Спасибо. У меня есть еще несколько минут, можно подискутировать. С удовольствием отвечу на вопросы. 

Вопрос из зала: Скажи, пожалуйста. Насколько правомерным ты считаешь использование опыта таких компаний, как "Microsoft", "Apple", "Google" и других, которые перевалили за десяток миллиардов, компаниям размера 25, 30, 100, 200 человек?

Георгий Баркан: Я думаю, что напрямую копировать их не нужно. Во многом проблемы, с которыми они сталкиваются, это совсем не те проблемы, которые действительно возникают у маленькой компании. Но в то же время у них есть и чему поучиться. 

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

Все, что связано с ответом на вопрос "почему" – это очень важно. Это то, на что нужно ответить в первую очередь. Без четкого ответа на этот вопрос и, главное, без носителя ответа на этот вопрос в компании любого размера будут определенные сложности, мне кажется.

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

Вопрос из зала: Такой вопрос. Project manager живет в этих построениях –время, сроки, ресурсы, все такое. Но есть параметр "качество продукта". При этом, если мы говорим, что project manager отвечает за бизнес, он говорит: "Такие-то вещи могут быть поставлены к такому-то сроку". Он подгоняет всех.

Как разрулить этот конфликт? Как ты его разруливаешь, когда есть вопрос качества, который должен решаться совершенно независимо от человека, принимающего решение о сроках поставки продукта. Вы говорите: "Так, ребята. Стоп. Мы никуда не торопимся, фрукт не срываем до тех пор, пока он не созрел".

Георгий Баркан: Мне кажется, что у разных компаний это может быть по-разному. Как это правильно решать – нужно для себя, в первую очередь, ответить на вопрос, что для вас продукт. Если вы, как "Apple", стремитесь к бескомпромиссности во всем, значит, и в этом будете то же самое. Это все сверху вниз транслируется, дальше уже понятно, каким образом.

Вопрос из зала: Как вы решаете этот вопрос? 

Георгий Баркан: Как мы решаем? У нас "time to market". Если говорить про "Лабораторию Касперского", у нас очень четко время и ресурсы. Поэтому качество такое, какое получается. 

Вопрос из зала: "Good enough"?

Георгий Баркан: Да, "good enough", конечно. В этом тоже нет ничего плохого. У нас есть четкий ответ на вопрос. У пользователей, грубо говоря, кончается срок предыдущей лицензии. Они хотят получить новую версию продукта. Поэтому мы должны ее сделать к этому сроку. Если у нас нет большего числа ресурсов, и это наше ограничение – значит, "good enough".

Вопрос из зала: Добрый день. Меня зовут Кирилл. Вы сказали, что вы работали какое-то время в "Quest Software". У вас было некое противоречие между кастомизацией продукта заказчиков и вашим собственным видением его отслеживания.

Георгий Баркан: Точно.

Вопрос из зала: Как вы это противоречие решали?

Георгий Баркан: Была ситуация такая. У "Quest Software" продукты ориентированы на корпоративных заказчиков разного размера. Их продавали, в том числе, и очень крупным заказчикам. Очень крупные – это одна сделка в лицензии продукта может до миллиона долларов доходить, например. 

Понятно, что такой заказчик, когда покупает коробочный продукт, не церемонится с вами. Он говорит: "Я хочу свою задачу решить и все. Меня не волнует, что у вас коробочный продукт. Наймите кастомизаторов, которые все сделают, как нам надо". Колоссальное давление со стороны канала продаж на продуктовую группу: "Давайте, делайте, как хотите. Неважно. Возьмите еще ресурсов. Мы вам отсыплем денег. Из этого миллиона мы вам дадим легко". Это приводило к тому, что ресурсы… 

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

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

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

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Михаил Радченко

Михаил Радченко

Директор компании "SoftPatent".

Михаил Радченко дает обзор своей практики патентования интернет-разработок.

Андрей Пантюхин

Андрей Пантюхин

В 2010–2012 построил Dream Industries в качестве первого CTO. Последние годы работает с ранними стартапами в России и за рубежом над продуктом и стратегией роста.

Андрей Пантюхин рассказывает об особенности работы с сообществами Open Source с применением коммерческого подхода.

Ольга Павлова

Ольга Павлова

Владелец 80% компании «Собака Павлова»

Ольга Павлова (Usability Lab) объясняет, как выбрать одного-единственного из миллиона потенциальных заказчиков.