Наверняка каждому из вас приходили в голову идеи новых интересных полезных продуктов – услуг, приложений или устройств. Возможно, кто-то из вас даже что-то разрабатывал и публиковал, может даже пытался на этом заработать.
В этой статье я покажу несколько методик работы над бизнес-идеей – о чем стоит задуматься сразу, какие показатели рассчитать, какие работы спланировать в первую очередь чтобы проверить идею в короткие сроки и с минимальными расходами.
Читать полностью »
Перфекционизм — ласковый убийца. Он убил больше нервов, отношений и проектов, чем кухонный нож, автомат Калашникова и твой заказчик вместе взятые.
В этой статье я объясню, почему тебе не нужно идеальное решение.
Читать полностью »
Служба поддержки — это то место, в которое пользователи обращаются, чтобы помочь вам создать лучший продукт. Конечно, в том случае, если вы готовы их слушать. Ежемесячно нам поступает более 175 000 обращений в поддержку, что можно сравнить с населением целого Петропавловска-Камчатского.
Естественно, хочется снизить эту цифру, так как продукт с идеальным пользовательским опытом не нуждается в поддержке. Кроме того, отдельной статьей расходов компании является содержание нескольких колл-центров, каждый звонок обходится в определенную сумму. Анализ этих проблем может стать серьезной базой для наполнения продуктового беклога задачами улучшения процессов, функциональной логики и внедрения новых фич.
Летом 2018 команда QIWI Кошелька — разработчики, тестировщики, дизайнеры — разделилась на две группы и отправилась в колл-центры Калуги и Челябинска для того, чтобы узнать, с какими проблемами сталкиваются наши пользователи. Проводя аналогию, можно сказать, что прямой контакт команды разработки с пользователем это не тушение горящего пожара, это создание системы пожарной безопасности.
На работу в поля
Жюль Бретон
Под катом я коротко расскажу о том, как это было, и почему полезно выбираться из офиса и смотреть, как твоим продуктом пользуются люди.
Читать полностью »
Честно говоря, Иван часто посмеивался над тщетными усилиями коллег из отдела мониторинга. Они прилагали огромные усилия для реализации метрик, которые им заказывало руководство компании. Они были настолько заняты, что больше никому ничего не хотели делать.
А руководству всё было мало – оно постоянно заказывало всё новые и новые метрики, очень быстро переставая пользоваться тем, что были сделаны ранее.
Последнее время все только и говорили про LeadTime – время поставки бизнесовых фич. Метрика показала сумасшедшее число – 200 дней на поставку одной задачи. Как же все охали, ахали и воздевали руки к небу!
Через некоторое время шум постепенно затих и от руководства поступил заказ на создание еще одной метрики.
Ивану было совершенно понятно, что и новая метрика точно также тихонько помрёт в тёмном уголке.
Действительно, размышлял Иван, знание числа совершенно никому ни о чём не говорит. 200 дней или 2 дня – нет никакой разницы, потому что по числу невозможно определить причину и понять, хорошо это или плохо.
Это типичная ловушка метрик: кажется, что новая метрика расскажет суть бытия и объяснит какой-то тайный секрет. Все так на это надеются, но ничего почему-то не происходит. Да потому что секрет надо искать вовсе не в метриках!
Для Ивана это был пройденный этап. Он понимал, что метрики – это просто обычная деревянная линейка для измерений, а все секреты надо искать в объекте влияния, т.е. в том, что эту метрику формирует.
Для интернет-магазина объектом влияния будут его клиенты, приносящие деньги, а для DevOps – команды, создающие и раскатывающие дистрибутивы с использованием конвейера.
Однажды, устроившись в холле в удобном кресле Иван решил как следует продумать как бы он хотел видеть метрики DevOps с учётом того, что объектом влияния являются команды.
Понятно, что всем хочется уменьшить время поставки. 200 дней – это, конечно, никуда не годится.
Но как, вот в чем вопрос?Читать полностью »
«Agile мёртв». Люди всё время так говорят. Но обязательно добавляют: «Мы просто шутим». Они типа имели в виду, что это у тебя такие неправильные и глупые практики, что это для тебя Agile мёртв. Но «настоящий» Agile не мёртв. Просто все его делают неправильно. Так что я понял: настоящий Agile — это, знаете ли, Agile в теории. Даже я его внедрял. И знаете что? Мне надоело.
Недавно я видел в статьях ту же самую старую защиту: «Но-но-но, проблема в водопаде, скраме и неправильной реализации Agile, несоблюдении Манифеста… бла-бла-бла». Тогда Боб Маршалл сказал мне правду. Он сказал: «Заткнись, Чарльз. Манифест Agile — это кувшин, который мы наполняем». Он сделал несколько замечаний, с которыми мне пришлось согласиться. Я задумался. Результатом стала эта статья.
Читать полностью »
Большие компании частенько печалятся от проблемы адаптируемости и маневренности. Точнее, почти от полного отсутствия и того, и другого.
Представьте: все платформенные команды заняты одной фичей, а у бизнеса появляется срочное требование сделать что-то другое или скорректировать уже разрабатываемый функционал. И в этот момент останавливается работа над одной фичей и начинается работа над другой. В следующий момент появляются уже новые требования от бизнеса, а фича так и остается недоделанной. Разработчики в обиде и бизнес страдает.
Вот еще ситуация: меняется API, нужно срочно бежать в отдел бэкенда узнавать подробности, потом обратно к фронтам (iOS / Android / web). Дальше, обсудив с фронтами свои корректировки, нужно идти обратно к бэку и говорить наши требования. Это очень изнуряло, терялось время команд, отдельного разработчика и нервы всех заинтересованных людей.
Меня зовут Валерий, наша команда занималась QIWI Кошельком под iOS. Но всегда нужно было держать коммуникации с другими командами, иначе получался полный рассинхрон. Что касается наших неудобств, то бизнес всегда идет навстречу и дает свободу для экспериментов. Поэтому встал вопрос об изменении существующей структуры. Благоприятной средой для тестирования наших идей по изменению был скрам. Каждые две недели мы внутри платформы могли редактировать курс, чтобы это хоть как-то согласовывалось с другими командами. На проверку теорий давалось много времени. От месяца до полугода. Какие варианты мы перепробовали:
Читать полностью »
В интернете большое количество информации о том, как правильно паблишить мобильные игры, как делать для них маркетинг, что размещать на страницах магазинов, однако большое количество нюансов незаметны сразу. В данной статье я поделюсь своими заметками и инсайтами, которые были выведены из результатов рекламных экспериментов. В частности о поведении пользователей на страницах мобильных игр в app store. Очень надеюсь, что заметки помогут не наступить на грабли молодым разработчикам, вкладывая деньги и время в наполнение страниц игр в магазине.
Читать полностью »
Сканирование документов по сети с одной стороны вроде бы есть, но с другой стороны не стало общепринятой практикой, в отличие от сетевой печати. Администраторы по-прежнему ставят драйвера, а настройка удаленного сканирования индивидуальная для каждой модели сканера. Какие же технологии есть на данный момент, и есть ли у такого сценария будущее.
Ряд моих коллег сталкиваются с проблемой, что для расчета какой-то метрики, например, коэффициента конверсии, приходится кверить всю базу данных. Или нужно провести детальное исследование по каждому клиенту, где клиентов миллионы. Такого рода квери могут работать довольно долго, даже в специально сделанных для этого хранилищах. Не очень-то прикольно ждать по 5-15-40 минут, пока считается простая метрика, чтобы выяснить, что тебе нужно посчитать что-то другое или добавить что-то еще.
Одним из решений этой проблемы является сэмплирование: мы не пытаемся вычислить нашу метрику на всем массиве данных, а берем подмножество, которое репрезентативно представляет нам нужные метрики. Это сэмпл может быть в 1000 раз меньше нашего массива данных, но при этом достаточно хорошо показывать нужные нам цифры.
В этой статье я решил продемонстрировать, как размеры выборки сэмплирования влияют на ошибку конечной метрики.
В прошлом году команда Program Manager-ов Plesk получила возможность пройти онлайн-курс GoPractice! Simulator от Олега Якубенкова, и теперь мы хотим поделиться своими впечатлениями.
Кто мы?
Program Manager в Plesk может быть наиболее точно описан как «технический» менеджер продукта. Это значит, что помимо собственно продуктовых компетенций, каждый ПМ имеет технический бэкграунд и погружен в предметную область настолько, чтобы в общих чертах понимать специфику работы с хостингом, облачными сервисами и веб-разработкой. Часть из нас больше сфокусирована на работе непосредственно с продуктовыми фичами, а другая больше занимается аналитикой и статистикой. Я сама совмещаю обе эти роли.
В этом отзыве будут и мои личные впечатления от Симулятора GoPractice!, и фидбек, которым со мной поделились коллеги.
Читать полностью »
