У меня была статья в которой я уже начал описывать структуру компании, так как я ее вижу.
Сегодня хочу дополнить один штрих к той статье, хотя безусловно, она заслуживает продолжения и более детального расписывания.
То, что я видел в нескольким компаниях в штатах, это достаточно странный метод выбирания, что делать. Само собой идеи сыпятся со всех сторон — от заказчиков, от менеджмента, от разработчиков, что в целом нормально.
Вопрос только, заключается в том, что
а) Нету человека или отдела, который отвечает за то, что идет в производство, а что нет. Чаще всего решение происходит полураспределенным путем, то есть где-то что-то замкнулось и выстрелило и новую функциональность поставили на конвеер для выпуска.
б) Нету четкого метода оценки насколько идея «интересна» компании. То есть продукт представляет собой такое, размытое облако и поэтому тяжко сказать, другое размытое облачко сильно соприкасается с ним или нет.
в) Метод выбора идей зачастую базируется на том, кто «громче кричит» (и тем самым привлекает внимание менеджмента).
Возвращаясь к той структуре, которую я нарисовал.
Именно поэтому я считаю, что
а) Должен быть отдел, который занимается сбором всей информации и решением, что идет таки на производство.
б) Этот отдел должен иметь достаточно четкий критерий оценки идей (например, учитывая количество заявок от заказчиков, потенциальные стоимость реализации функциональности, потенциальный размер рынка, нахождение функциональности внутри направления развития продукта).
В этом случае, вполне понятно, кто в конечном счете отвечает за принятие решений и на основе каких параметров они принимаются.
Именно так. У нас этот отдел называется Product Development Department (и я им до недавнего времени рулил).
Кстати, а чем ты сейчас занимаешься? Общий business development? За пределы продукта вышло?
Я сейчас занимаюсь почти тем же самым, но без собственно объяснения людям, что требуется. Преобразование инновационных требований в спецификации продуктов уже вне моего контроля.
Понял.
На самом деле этот одел есть, пусть даже официально не внесен в структуру предприятия.
В компании всегда есть человек (группа людей), который принимает это решение. В очень мелких компаниях — это директор. В более крупных — это его зам. В еще более крупных — это специальный человек, который только этим и занимается. В уж очень больших компаниях — это целый одтел.
В трех, описанных, проблемах — я не вижу ничего проблематичного, с организационной точки зрения. Если это делает директор, то он сам для себя должен решить слушать того, кто громче кричит или подумать своей головой. По мере роста компании, директор дилегирует свои обязанности и полномочия другим людям/отделам/etc.
ИМХО: проблема зашита в самом подходе принятия решений, а не в организационной структуре.
>В компании всегда есть человек (группа людей), который принимает это решение.
Если четко не известно, кто должен принимать решение
а) Люди тратят на принятие решение больше времени
б) Принимают решения иногда таки не те люди
>проблема зашита в самом подходе принятия решений, а не в организационной структуре.
ok. Я придерживаюсь принципа — хоть горшком называйте, только в печь не садите.
Так, что если официально известно, кто принимает решения и в разумной мере известны принципы принимаемых решений, то пусть это даже не будет в организационной структуре, но оно будет работать.
Организационная структура нужна для того, чтобы не оказывалось тысчи вещей «висящих» в воздухе. Так как они быстро накапливаются и становится непонятно, кто что делает.
Похоже, тебе просто так повезло с компаниями 🙂
По проблеме А — действительно, этим должен заниматься director of product development или, если есть такой отдел, то люди из него. Собственно, этот человек должен быть мостом между клиентами и разработчиками и работы там немеряно. У нас этот чувак работает по 12 часов ежедневно 🙂
Б — формального может быть и нет. Опять таки, у нас это происходит путем общения product owner’a с командой и с клиентами, оценкой критичности пожеланий клиента, важности самого клиента и стоимости (естессно effort, а не просто физические деньги) добавления новой фичи для команды. Взвесив эти три критерия, принимается решение о (не)добавлении идеи в backlog и ее приоритете.
В — все зависит от правил игры в компании. Product owner отвечает за проект, поэтому он принимает решение, делать или не делать. Если он принимает это решение на основании «кто громче кричит», то это просто плохой оунер 🙂
>Похоже, тебе просто так повезло с компаниями 🙂
Одна — случайность, две — возможность, три — закономерность 🙂
Думаю, что дело ни только в невезении.
>Собственно, этот человек должен быть мостом между клиентами и разработчиками
Я бы даже сказал больше мостом между фактически всеми (sales, marketing, клиенты, директора) и разработчиками.
>Б — формального может быть и нет.
> оценкой критичности пожеланий клиента, важности самого клиента и стоимости (естессно effort, а не просто физические деньги)
Ты только что фактически формализировал подход. Естественно, я не говорю о математической формуле. Я скорее говорю, о известном списке того, что влияет на решение и разумной приоритетности параметров этого списка.
В основном, это нужно для того, чтобы приоритет не выставлялся просто на основе, того, что кто-то громко кричит.
>Если он принимает это решение на основании “кто громче кричит”, то это просто плохой >оунер 🙂
Безусловно. Он действительно плохой owner в таком случае. С другой стороны, когда нету а) и б), то получается, что зачастую вообще отсутствует один овнер проекта.
а) Соглашусь с Максом Крайнов — это действительно Product Development Department. Если же, как в случае моей компании, продукт — это набор нескольких категорий, то в этот департамент добавляется Portfolio Office Management (РМО), который определяет приоритет каждой категории в конкретном релизе(происходит это потому, что дев департмент нерезиновый и как всегда не хватает девелоперов, чтобы сделать все). Я, как продакт менеджер, представляю все данные почему это должно быть сделано и какие бенефиты получим, а портфолио, на основании предоставленных данных, делает вывод какой проект им принесет больше денег либо лояльность клиента (хотя как показали последние юзер тестирования — о лояльности клиентов можно забыть :)).
б) насколько идея интересна компании обычно судят по тому сколько эта идея принесет компании денег или сколько денег поможет сэкономить.
в) почему же нет? Один из методов оценки предложил Brian Lawley (the former President of the Silicon Valley Product Management Association ) в своей книге Expert Product Management™. Оценка производится на основании следующих критериев:
«Pain for User (0 — 5)»
«% of customers impacted (0 — 5)»
«Upsell revenue from existing customers (0 — 5)»
«Revenue from new customers (0 — 5)»
«Key product differentiator (0 — 5)»
«Competitive necessity (0 — 5)»
Можно добавить еще несколько необходимых вам категорий и проставить вес каждой категории, что бы суммарно вес всех категорий был 100.
Потом, по предложенной Brian Lawley формуле, высчитывается total score каждой фичи — вот вам и приоритеты. Все получается очень просто и красиво и рассматривает фичу с разных сторон. Я попробывала со своим продуктом — мне понравилось и необходимость фичи получается очень обоснованной, что опять же помогает в разговоре с РМО.
Собственно со всем согласен. :))
Единственное, я был бы осторожен с весами в категории. Хотя формула получается полностью математическая, но все же могут быть неучтенные параметры. Поэтому хотя бы один из параметров должен быть «Other», который можно регулировать с заметками, почему он выбран большим или маленьким.
Кстати, очень важная фраза «помогает в разговоре с РМО». Именно это и является ключевой идеей формализации процессов, что когда общаешься с одной группой, а потом с второй не надо весь спор или обсуждение повторять по кругу, а вполне можно показать готовые выкладки.
То есть процесс обсуждения из кто громче крикнет становится направленным.
Можно и other. Как говорится, ваш продукт, вы что хотите с ним, то и делайте :). Единственно, что не стоит делать так — это слишком гранулированное оценивание. То есть, 5-7 критериев оценки — этого достаточно. Проверено на собственном опыте :). Ну а то, что мы посчитали необходимым обязательно добавить — это временные затраты, причем в обратной связи, то есть с увеличением временем разработки приоритет проекта понижается.
Да, я согласен, что 5-7 критериев достаточно. Очень люблю фразу «без фанатизма». Она и тут тоже применима.
А почему достаточно именно 5-7 разве тут не действует схепа чем больше тем лучше
Как показала практика — не действует. Получается слишком гранулированно, а грануляция искажает результаты. Когда пытаешься учесть все возможные интересы и стороны, то начинаешь торговлю сам с собой и самому же сложнее сделать выбор. С другой стороны, сделав подробную грануляцию и намучавшись, нам было легче определить какие параметры наиболее важные.
Согласен с Анной, увеличивая гранулярность, уменьшаются размеры каждого фактора. А чем меньше размеры, тем сложнее учесть их важность. По крайней мере относительно этой проблемы.
Да и просто, с помощью 5-7 пунктов, можно оценить в течении 10 минут, насколько важна новая функциональность.
А если иметь 5 листов с 100 пунктами, то надо будет убивать несколько часов на подсчеты.
Как по мне то каждая компания должна работать как человеческий организм, есть даже такая теория, только я сейчас не помню как она называется. Ведь человеческий организм это самая сложная «компания» но в тоже время нет компании в мире которая работала бы четче чем он…
Звучит может хорошо. Но, что это значит на практике? Как построить компанию, котороая будет работать как организм.
Плюс, человеческий организм и бизнес компания преследуют абсолютно разные цели.
На основе эволюции, основная задача человека (как и любого другого животного) является максимальное репродукция своего генного набора.
Цель компании — максимизация прибыли на длительном промежутке времени.
Единственное общее — это слово «максимизация», но вот функции максимизации абсолютно различны.