Вы тоже устраиваетесь в кресле поудобнее, когда создатель крупного продукта рассказывает о своих ошибках? Тогда читайте продолжение занятного интервью с исполнительным директором Trello. Майкл Прайор честно поведал о сложностях позиционирования, о тонкостях монетизации, о неожиданных открытиях и о том, что бы он изменил в прошлом. А потели над переводом этой беседы переводчики компании-локализатора Alconost.
Читать полностью »
Нет сомнений, что вы слышали о Trello — как-никак, у него уже более 16 миллионов пользователей. Каково это – разработать, запустить и продвигать такой массовый продукт? Как правильно приоритизировать фичи продукта со столь широким спектром вариантов использования? Как проводить монетизацию по принципу ценности для потребителя? Об этом и о многом другом соучредитель сервиса Intercom поговорил с исполнительным директором Trello Майклом Прайором. А мы, компания-локализатор Alconost, все это перевели.
Публикуем перевод без сокращений и изменений, а если у вас совсем нет времени, вот вам пять ключевых выводов:
Читать полностью »
Данная публикация — местами вольный перевод статьи за авторством Julie Zhuo, продукт-дизайнера в Facebook. Приятного чтения.
Если несколько десятилетий назад вы бы захотели сделать что-то уникальное, вы бы сели, сделали глубокий вдох, закрыли глаза и обратились бы с молитвой к оракулу под названием «интуиция».
Но, как наши предки когда-то укротили силу огня, так и мы научились использовать возможности метрики и аналитики. Мы уже не блуждаем во тьме, задаваясь вопросом «неужели хоть кто-то читает эти электронные письма, рассылаемые каждые два дня?». Мне даже интересно, сколько людей пыталось найти ответ на этот вопрос до этого момента, до наступления созданного всеми нами будущего. Ведь теперь мы просто погружаемся в сокровищницу чисел и выуживаем оттуда ответ.
Увы, несмотря на обретенный нами свет, в углах сохраняются экзистенциальные тени. Я слышал их в обсуждениях в залах офиса, в бормотании над стаканом после работы, видел набранными заглавными буквами в блуждающих по сети тредах обсуждений стиля:
«Делаем ли мы это просто для получения метрики?»
«Как мы можем сбалансировать полученные цифры и сделать при этом что-то достойное?»
И мой фаворит: «Вы, те, кто управляет данными, на самом деле заботитесь о пользователях и UX?»
Ох! Сильные слова и жгучие обвинения!
Может, хотите продуктивно поговорить о метриках и позитивном опыте? Вот что знаю я.
Читать полностью »
Как узнать, когда выгоднее всего лететь на юг, какие дополнительные сборы существуют при перелёте и как найти самую низкую цену на авиабилет? В этом посте мы расскажем о нескольких секретах сервиса momondo, знание которых сэкономит клиентам не только время, но и деньги.
В начале работы над проектом или на этапе радикальных изменений в продукте трудно удержаться от искушения опросить всех своих пользователей, чтобы определиться с положением дел. Обычно это ошибка. Вообще-то есть целый ряд общих ошибок, которые происходят снова и снова. Мы в Alconost перевели для вас пять подсказок по сбору отзывов о продукте.
Читать полностью »
На прошлой неделе мы добавили новую возможность, которая не только делает социальные «лайки» полезными для программиста, но также позволят открывать для себя важную и полезную информацию. Мы назвали эту возможность звучным английским словом Discover.
Философия продукта основана на том, что мы классифицируем информацию на интересную или нет через социальный «лайк». Если Ваш коллега, друг или человек с близкими интересами «лайкает» какую нибудь статью, возможно она понравится и Вам. Исходя из этого, мы решили попробовать добавить что-то на подобии «френдов» или «фолловеров» из социальных сетей и дать возможность другим людям видеть, что интересно Вам.
Читать полностью »
Итак, вы задумали делать продукт. Не проект, а именно продукт, который через Х месяцев должен появиться в сторах и начать свое движение к звездам. Вы уверены в своих силах и знаниях, а количество новых идей, которые могут превратиться в настоящие киллер-фичи, просто зашкаливает. Самое время сказать себе “стоп!” и разобраться в том, что должно войти в комплект вашей самой первой релизной версии.
После того как вы расписали все характеристики будущего продукта, необходимо определить приоритеты в разработке. Первое желание – ранжировать по сложности реализации. Логично, тем более если ресурс ограничен – нет смысла строить “Титаник”, когда для первого преодоления Рубикона нужна просто шустрая и устойчивая лодка. Следуя заветам customer development, вы в будущем будете только наращивать функционал: главное – в архитектуре не промахнуться.
Итак, делаем шуструю лодку. Но выбор все еще непрост – даже из относительно простых деталей нужно определить тот набор, который и станет вашим release candidate. И здесь вам на помощь придет модель, которую придумал в 70-е годы прошлого века японский ученый Нориаки Кано. На “Хабре” уже был текст об использовании его модели для решения задач UX. Этот подход вполне применим и к продуктовым функциям – ведь они тоже отвечают за эмоциональные реакции потребителей. Кано предположил, что таких реакций бывает пять типов: от полной неприязни до прямо-таки восхищения. Эти типы японец изложил на одном графике, где по вертикальной оси отобразил эмоциональную реакцию пользователя (неприязнь – восхищение), а по горизонтальной – “количественное” значение характеристики (нет – много).
То понятие, для которого на английском языке достаточно одного слóва «workflow», на русский приходится переводить словосочетанием — «рабочий процесс». Ничего лучше не знаю ни сам я, ни при помощи гуглоперевода — так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.
Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций на производстве» — и стану говорить именно о «внедрении» новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи о каком-либо «развёртывании» их.
К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.
Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.
Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.
Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.
Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.
Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.
Простота его имеет несколько достоинств. Во-первых, людям проще понять его, так что они быстрее начинают использовать его, реже (или вовсе никогда не) допускают ошибки, требующие отката. Кроме того, не требуется скрипт-обёртка, помогающий следовать процессу, так что употребление GUI (и т. п.) не создаёт проблем.
Так получилось, что в последнюю неделю сентября и первые две недели октября я провёл 6 мастер-классов по Windows 8 для «Кампус-экспертов» — студентов немецких ВУЗов, которые оказывают техподдержку по основным пользовательским продуктам Майкрософт (операционная система, офис и пр.) у себя в ВУЗах. В рамках подготовки к этим мастер-классам я составил небольшой список показавшихся мне интересными и несколько неочевидными. Еще несколько фич мне подсказали сами студенты. Этот небольшой список со скриншотами я решил оформить в виде небольшого обзора. Конечно, не каждая из этих фич является новой или совсем неизвестной, но я постарался выбрать то. что мне показалось интересным.
Читать полностью »
