вторник, 4 октября 2011 г.

Как понять приоритеты клиентов?

 Если продукт действует на рынке сколько-либо долго, сколько-либо сложен и имеет сколько-либо значимую базу клиентов - то объем известных клиентских пожеланий в разы превышает возможности команды разработчиков. Пожелания превращаются в некий фон - все чего-то хотят, но что мы  должны делать? Что НА САМОМ ДЕЛЕ нужно клиентам?

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

Если вы пытаетесь понять приоритеты и задаете клиентам вопрос - "хотите ли вы X?", большинство ответят "было бы неплохо". Может и не особо нужно, но для них это ничего не стоит, так что почему бы и нет. Могут быть несколько человек, кто настолько озабочен какими-то острыми проблемами, что резко отреагирует на попытку двинуться в каком-либо ином направлении, кроме решения этих конкретных проблем - но в целом это не приближает нас к решению.

Решение - это вынудить клиента увидеть цену своих хотелок, выбирать разумно и обозначать приоритеты. Как это можно сделать -

  1. ограничить длину списка. "Какие TOP5 вещей вы бы хотели добавить?" Будучи ограниченными в объеме, люди выберут наиболее важные для них. 
  2. указать цену. "Сколько ваших клиентов готовы платить 2x за Y?" Недавно применил такой прием и спрос с 35% сократился до 15%
  3. дать ложный выбор. "Вы бы хотели X или Y?" Оба кажутся нужными, но видя необходимость выбирать, клиент четко задает приоритет (1) и как правило объясняет причины (2).
  4. потребовать детали. "Какие выгоды вы видите от X? Какие проблемы?" Если люди не готовы обсуждать какой-то вопрос, вероятно он им не сильно важен, они им не особо интересовались.

четверг, 23 июня 2011 г.

Станислав Протасов (Parallels) о Program Management

Слушать пользователя, безусловно, надо. Это как в семейной жизни. Надо ли слушать жену? В принципе, надо. Но если все делать, как просит жена, скорее всего, она будет еще более недовольна. Ровно так же и с пользователем. Проблема в том, что невозможно слушать пользователя, если речь идет о новом продукте, которым он никогда не пользовался. Вот представьте, приходим к нему и спрашиваем:
― Хочешь ли ты, чтобы на нашей новой машине можно было разгоняться до 100 км\ч за 3,5 секунды?
― Да, ― отвечает он.
― Хочешь, чтобы все материалы были натуральные?
― Да!
― Хочешь, чтобы на дачу можно было отвезти блок кирпичей?
― Да!
В итоге мы делаем пикап с реактивным мотором, отделанный кристаллами Swarovski. И его никто не покупает. Потому что для фермера это дорого, а для того, кто предпочитает кристаллы Swarovski, это уродливо, к тому же состоятельные люди не хотят покупать те же машины, которые позиционируются для фермеров.
Слушать пользователя ― это нечто на грани науки и искусства. Людей, которые умеют слушать пользователей и доказали это на успешных продуктах, их очень мало. В России их практически нет, потому что у нас просто меньше людей в IT-индустрии. У нас приходится делать все на ощупь, из своих соображений, поэтому ошибок делается огромное количество.
...
Тут вопрос в здравом смысле. Надо уметь разделять wishful thinking, когда человек открывает чакры и вещает все, что ему приходит в голову, и реальную его нужду. Для этого в софтверных компаниях существуют продакт-менеджеры и програм-менеджеры, задача которых и заключается в том, чтоб определять «начинку» софта. 

пятница, 17 июня 2011 г.

Когда клиент хочет странного

Иногда приходят клиенты со странными запросами. Им очень нужна поддержка какой-то технологии. Чего-то сомнительного, непонятного, необщепринятого и маловостребованного. Зачем?

На свои вопросы мы слышим - это будущее, это стандарт, это must-have. Но смотрим шире и все это, скажем так, не вполне подтверждается. На самом деле клиент скорее всего кривит душой (хотя может и добросовестно заблуждается).

Просто многим нашим клиентам нашего продукта важно отличаться от других поставщиков подобных услуг. Кто-то пойдет по пути другой цены, другого уровня сервиса, других сервисов и т.д. А кто-то хочет отличаться уникальными предложениями - bleeding edge, innovation, top notch, быть вперед других. Разумеется, попытка быть впереди всех приводит людей в "серую зону" непроверенных технологий.

Что с этим делать? 

  • В первую очередь даже странный запрос желательно проверять, рассматривать и интересоваться у более широких кругов. Быть может в ответ вы услышите "а кстати да..." и тогда появляется шанс "опередить паровоз". 
  • Не менее важно посмотреть самим. Малоизвестная и маловостребованная технология сегодня, может и правда оказаться очень перспективной для вашего продукта. Если она помогает решать актуальные нам проблемы - берем и продвигаем, "толкаем паровоз". :)
  • Посмотрите в корень проблемы. Данный конкретный запрос ("быть таким!") в целом для продукта не актуален, НО его обобщение ("быть другим!") вполне актуален. Клиенту на рынке важно отличаться от других - значит необходимы инструменты кастомизации и расширения функционала. В стандартную комплектацию не включим, а вот слоты расширения предоставим.
  • Ну и если ничего из этого не подошло - время сказать "Извините, нет". Массовый продукт не должен сбиваться с выбранного курса без серьезной причины.

вторник, 7 июня 2011 г.

Say "No!"

Попалась статья с многообещающим названием Leadership: How to Say ‘No’ While Also Inspiring People и началом (цитата С.Джобса):
People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things.’
К концу впрочем автор свалился в благоглупости о том, как "правильно" говорить "No!":
  • Yes! (без комментариев)
  • Lets explore... (неплохо, давайте подумаем потом)
  • What if? (давайте еще подумаем)
и по сути вывернул все наизнанку написав статью о том, как говорить "Да!".

Я бы с большим интересом посмотрел на Стива Джобса говорящего 1000 раз"Lets explore..." и "What if?..." вместо "No!"и с не меньшим интересом посмотрел на результаты.

Если лидер имел ввиду настоящий "Yes!" - то статья ни о чем. "Yes!" никак не отменяет необходимости разобраться дополнительно. Если же лидер имел ввиду "No!" - то оба дополнительных варианта банальная манипуляция и увертка, а вовсе не adult-adult разговор, который подается в статье как большое достижение.

Изначальный посыл Джобса именно о том, что надо говорить "No!". Простой и честный "No!". 1000 идей могут иметь какую-то гипотетическую пользу (совсем бесполезную идею тяжело найти в реальной жизни). И им всем надо будет сказать "No!" ради 1001й. Просто не надо "вилять". Объясните цели и отметайте идеи, которые им не соответствуют - вменяемые люди поймут.

понедельник, 30 мая 2011 г.

Резкие изменения

Практически во всяком продукте есть необходимость развиваться как вширь, так и ввысь. "Вширь" - это добавление каких-то новых возможностей без изменения основных принципов продукта. Добавили еще один художественный фильтр в Picasa - это "вширь". Не каждый такое добавление и заметит. "Ввысь" - это существенное изменение принципов работы с пользователем.   Введение ribbon в MS Office 2007 - это было "ввысь".

Мотивация для развития "вширь" проста и очевидна - ежедневно продуктовая команда получает пачки запросов типа "а можно еще вот чтобы так...". Мотивация для изменения "ввысь" немного сложнее и сама она скорее характерна для retail продуктов, чем для "заказных":

  • хотим выглядеть другими. Иногда нужно дистанцироваться от мрачного прошлого, иногда нужно подчеркнуть динамику. Обычно исходит от отдела маркетинга. 
  • хотим лучше соответствовать своей (или еще не своей) аудитории. Пытаемся стать удобнее и тем привлечь правильную аудиторию. Может быть просто пытаемся следовать моде - в конце концов понятие удобства субъективно. :)
  • просто пришлось в конце концов. Старые концепции становятся неадекватными новым задачам. Дальнейший рост без смены модели слишком труден.

По каким-бы причинам такое радикальное изменение не произошло - понравится оно не всем. Этих "не всех" может быть много. Можно их условно разделить на две группы

  • Иррациональная. Те, кто уже привык и не хочет разбираться с новым. Оно им не нравится, просто потому, что оно другое. Скорее всего, не существует конечного списка исправлений, которые могли бы исправить ситуацию, не уничтожая новую модель полностью. Отсутствие такого списка позволяет точно идентифицировать таких клиентов.
  • Рациональная. Кто-то использует продукт таким образом, что в новой модели ему объективно жизни нет или она очень трудна. Есть вполне конкретные сценарии и есть вполне конкретные проблемы, хотя выделить их за потоком возмущения может быть не просто. Почему-то интересы этой группы не учли при планировании изменений или учли и сознательно проигнорировали. Эти сценарии могут быть вполне вменяемыми, просто их не учли. Или совершенно странными и вы их даже вообразить не смогли.

А теперь интересный вопрос - что с ними делать и что они теперь будут делать с вами?

С иррациональной группой сделать ничего нельзя, кроме как предоставить старый интерфейс обратно (лучше, конечно, об этом с самого начала подумать). Но это не всегда возможно и не всегда разумно. Попытки сгладить отдельные углы ничего принципиально не изменят. Если не будет совместимого интерфейса, то многие уйдут. Чем легче уйти, тем больше уйдут. Иррациональность проявится также в том, что конкурентное решение не обязано быть лучше, или хотя бы более похожим на утерянное. Ниже отличная иллюстрация на примере уважаемого человека, недовольного Firefox 4:

Message #1:
... в продукт вносятся ЗАМЕТНЫЕ изменения. Не значимые, а именно заметные, бросающиеся в глаза. 
И все. Жопа.

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

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

Хочется стукнуть по рукам и сказать:"ничего не трогай, гад!" 

...


Message #2:

... привыкнуть к этому новому уродству у меня не получилось. Поэтому я решил ... установить Гугл-Хром...Во-вторых, если уж и привыкать к новому интерфейсу, то лучше к совсем новому. Лису я не простил. 


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

Не следует, конечно, полагать, что иррациональное здесь синоним неправильного, просто всегда есть место субъективным симпатиям и привычкам. К примеру, мне когда-то очень нравилось ACDSee 2.9(?), а при апгрейде ее до ACDSee 3.2 мне она стала так неприятна, что у меня до сих пор где-то есть старый добрый дистрибутив. Обновленный продукт не нравился, категорически. Может быть он не был плохим, но мне не подходил совсем - тем более, что никаких собственных причин для апгрейда у меня не было.

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


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

А как же урок не делать радикальных изменений? Так без необходимости их бы и не делали. :)

среда, 25 мая 2011 г.

Проблемы и узкие места

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

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

Обсуждая эту книгу на кухне, прозвучала мысль, что где-то узкого места может и не быть. К примеру, у нас имела и имеет место ситуация, когда производительность системы неудовлетворительна, но узких мест в ней нет. Система тормозит однородно, если так можно сказать. Однако, если подумать, то узкое место выявить можно - хотя для этого необходимо перейти в другую плоскость анализа. Общая медленность системы есть результат ее архитектуры в какой-то степени и в пожалуй даже больше степени, результат повседневно применяемых практик программирования - они скорее определяются используемыми инструментами (библиотеками и фреймворками), чем собственно архитектурой. Очевидно, применяемые практики не удовлетворительны, однако изменить их, предложить новые, предложить политику перехода от старых практик к новым - на это банально нет времени. Пилить надо. Итак узкое место в производительности системы все-таки есть - это нехватка времени разработчиков. Возможно, что это узкое место не есть истинная причина - копая глубже, можно искать и найти причины нехватки времени. Для знакомства с методами анализа систем в поиске узких мест можно посмотреть другую книгу: Эли Шрагенхайм, Управленческие дилеммы. Теория ограничений в действии

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

суббота, 9 апреля 2011 г.

Счет-фактура

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

Итоговый рейтинг простоты ведения бизнеса -
#1 Американская модель отчетности
#2 Европейская модель отчетности
#3 Российская модель отчетности
А вот если мерить в сложности, то мы, безусловно, окажемся в лидерах :)