Проверяйте факты. Всегда

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

Приведем свежий пример - некое агенство сделало простую инфографику с топовыми социальными сетями. В нем - сюрприз - отечественная социальная сеть VKontakte весьма обогнала по числу пользователей модный Instagram. 228 млн vkontakte прости 150 млн Instagram. Такой сюрприз вызвал определенное бурление.

Нам это сейчас должно быть интересно не с точки зрения степени влияния социальных сетей, а с точки зрения простого упражнения на проверку фактов. Само число 228 млн очень велико - это намного больше населений всей РФ (140 млн) или сравнимо с населением всего СНГ (280 млн). Это внушает сомнение. разве кто-то видел вконтакте толпы пенсионеров или иностранцев?

Теперь проверяем - откуда взяты эти цифры? Совершенно не секрет - подпись внизу инфографики говорит "Wikipedia". Wikipedia надо пользоваться с осторожностью. Действительно, для Instagram вики дает цифру 150 млн как число активных пользователей в месяц. А для Vkontakte вики дает цифру 228 млн как общее число ID в каталоге. Методически эти цифры совершенно несравнимы. Некоторые ID могли вообще никогда не быть живыми пользователями.

Любопытства ради ищем аналитику по пользователям Вконтакте и выходим на неутомимых "хабровцев", которые просканировали каталог в 2011м году. С результатами - менее 70% живых учетных записей в каталоге и менее 30% активных. Это позволяет оценить активную аудиторию Вконтакте в 70 млн пользователей на сегодня, что уже на что-то похоже, хоть точность и минимальная. 

Не исключено, что подобное нормирование всех соц.сетей в списке к общему знаменателю могло бы их значительно перетасовать, но такой цели мы не ставим. Просто первый попавшийся под руку пример. Работа program manager'а требует постоянных поиска и проверки данных.

Какой у нас статус? Красный? Желтый? Зеленый?

Меня всегда смущала необходимость раставить цветовые статусы по задачам - красный/желтый/зеленый. Мы же разработкой софта занимаемся - какой к черту "зеленый" и "все в порядке". Здесь все и всегда не в порядке, и порядка не предвидится. Соответственно все задачи имели статус "желтый" - есть проблемы, но мы боремся. То есть трех-цветная система не работала, все было "не в порядке" и вице-президенту было грустно. Но при чтении книги "Pacific" / "Тихоокеанский фронт" вышел на статьи по армейский жаргон и все прояснилось:

1. Зеленый SNAFU - Situation Normal, All F*cked Up. "Все порядке, полный п..ц." Фраза означает ситуацию худшую, чем хотелось бы, но, по всей видимости, нормальную (в смысле распространенную и общепринятую). В каком вообще смысле ситуация может быть нормальной на войне :) Грубо говоря, проблемы есть, но мы пока справляемся и в целом контроллируем ситуацию

2. Желтый TARFUN - Things Are Really F*cked Up Now.  "Хьюстон, у нас проблема". Ситуация не в порядке даже для того экстрима, которым мы сейчас занимаемся. Мы можем с этим не справится.

3. Красный FUBAR - F*cked Up Beyond All Recognition. "Восстановлению не подлежит". А вот теперь точно хана. Мы уверены и убеждены, что исправить ситуацию самостоятельно не можем.

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

Пирамида Маслоу для пользовательских потребностей в софте

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

Maslow piramide of consumer requirements in Software

Поясню простые соображения за расстановкой приоритетов:

1. Function - функциональность. Пока софт не делает нечто нужное, потребности в нем нет вообще.
2. Reliability - надежность и качество. Следующим критерием будет вероятность корректного выполнения необходимой функции. Если софт свою работу делает через раз - то прочие характеристики этого софта уже не важны.
3. Security - безопасность. Предполагается что при реальной и осознанной угрозе лишиться чего-то ценного, пользователь предпочтет не-комфортное и не-прикольное (см.ниже), но безопасное приложение. В свою очередь, безопасный софт, которые не выполняет свою функцию (Function и Reliability, см.выше) также не нужен.
4. Comfort - после удовлетворения первичных потребностей, пользователю становится важен комфорт. А именно - объем усилий, которые он должен потратить не поддержание Function, Reliability и Security.
5. Fancy - и наконец в последнюю очередь пользователю важны всякие "вкусняшки" и "красивости", не относящиеся к первым четырем потребностям.

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

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

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

Первый взгляд на iOS 6

Не имея пока возможности попробовать iPhone 5, решил посмотреть iOS 6 на своем iPhone 4S.

Воспользовался инструкциями и ссылками по апгрейду на "утекший" финальный билд iOS 6. Апгрейд прошел гладко. Среди незначительных неприятностей были
- 2GIS забыл карту Новосибирска (хотя Яндекс.Карты оффлайн карту Новосибирска не потеряли)
- все приложения разлогинились и пришлось мучительно вспоминать явки и пароли

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

Dropbox перспективы?

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

Берем 100Gb для примера. Цена в месяц составит — 
Dropbox $20 
SugarSync $15
Google Disk $5
SkyDrive ~$4

Коммерческий GoDaddy Online File Folder предлагает 100 Gb от $2.49 до $1.74 в месяц (в зависимости от оплачиваемого периода). И по начинке он вполне адекватен — веб-доступ + десктопный клиент + mobile app + sharing + online backup выбранных папок + FTP + WebDAV. На мой взгляд достаточно вкусно. 

Я cам им сейчас уже не пользуюсь (сижу на SkyDrive и MozyHome), но если бы нужны были большие объемы — то платить $20 dropbox'у счел бы не разумным.


Похоже, Dropbox - намного больше социальная сеть, чем хранилище. Поскольку в моем окружении в нем никто ничего интересного не шарит, то я им и не пользуюсь. Однако 43% пользователей habr пользуются именно им. 


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


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


Действительно, быть первым не значит быть лучшим.

Управление рисками

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

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

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

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

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

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

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

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