Rambler's Top100

Новый закон с ограничением платежей. Статистика платежей по электронным кошелькам.

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

Итак… сколько же платежей больше 1000 рублей? Чуть меньше 15% от общего количества платежей с электронных кошельков. Средняя сумма такого платежа немногим меньше 4000 рублей. Основные получатели таких платежей: благотворительность, онлайн-сервисы (подписки, хостинги, всевозможные SaaS) и магазины. Среди платежей меньше 1000 рублей (средний примерно 235 рублей) основную массу составляет оплата игр.

Таким образом, пострадают наиболее полезные сервисы. Игры это не заденет, а вот магазины, сервисы и благотворительность… да, им достанется. Понятно, что часть этих денег никуда не денется, и эти платежи будут проходить через другие каналы, прежде всего банковскими картами, но… какая-то доля неизбежно пропадет. Больше всего снизятся выплаты за “необязательные” вещи, скажем, благотворительность.

 

Страсть и её продолжение — метрики…

Я всегда считал, что хороший проджект, прежде всего, — человек, которому больше всех надо. Человек, которому не всё равно, который любит свой проект, готов пахать и долбить ради него, зажигать людей вокруг, показывать, объяснять, тащить проект к запуску на зубах, через “не могу”. Я любил очень многие свои проекты и, наверное, именно это помогало мне. И до сих пор люблю. И за многие я горд, а за многие мне очень больно, очень обидно смотреть, что с ними происходит, хоть и есть некоторая доля злорадства. Ну как же, не смогли без меня…

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

Недавно я говорил с одним из своих pm-ов и натолкнулся на странное: он не видел своего результата, не мог сам себе доказать правильность и нужность того, что он делает. И я предложил посчитать. Посчитать наивно, в лоб, с точки зрения владельцев.

Любая коммерческая компания в конечном итоге имеет только одну метрику своей успешности: прибыль. Всё, что мы делаем, так или иначе нацелено на увеличение прибыли. Это не обязательно прибыль сиюминутная, но это всё равно прибыль. И тут важно помнить, откуда она берётся. А это крайне простая вещь — разница между доходами и расходами. И вы можете работать наружу, на клиентов, тогда, практически наверняка вы главным образом наращиваете прибыль за счет увеличения входного потока, а можете — внутрь, на своих сотрудников, на продукт, на процедуру его эксплуатации. И это всё равно увеличение прибыли, только через снижение расходов. И даже если не видно внешнего результата… просто смотрите на метрики и верьте в себя. И в цифры.

Пьеса, которой, конечно же, не могло быть, и которая не имеет отношения к разработке ПО

Действующие лица:

  • Важный-важный менеджер по продажам, радеющий за дело и kpi
  • Начальник склада, тупая бюрократическая гнида и формалист
  • Самый важный менеджер по продажам, человек возвышенный и стремящийся в деталях разобраться в происходящем
  • Директор автосалона
  • Массовка (продажники, складские, девочки на ресепшене)

Акт 1

Давным-давно в одной далекой галактике… Как-то раз один важный-важный менеджер по продажам большого автосалона пришел на склад.

— Эй, ребята, я тут продал клиенту машину. Вон ту.

— Ну… здорово, поздравляем, можно забирать.

На следующий день на склад (почему на склад? ну… у продажника надо спросить) позвонил покупатель:

— А крыло к машине уже приделано?

— ?!! Какое крыло?

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

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

— Да, разузнайте, но мне очень срочно, и мне уже обещали.

читать далее »

Задача без сроков не решается

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

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

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

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

Я не говорю о том, что и здесь надо биться за запуск в срок любой ценой: если функционал откровенно сырой или ненужный, в чем смысл его запускать?! Но цель и срок должны быть, должны быть всегда, даже если позабыть про внешние факторы в духе уже назначенной даты старта проплаченной рекламной компании, прописанных в законодательстве сроков сдачи отчетности и т.д. и т.п. Да, я против навязанных сроков, но объем надо оценить, поставить дату и держаться за неё, держаться максимально точно. Это нужно всем. Да, и вам тоже.