Рубрика «Управление продуктом» - 69

Привет! Сегодня мы расскажем о том, как разные команды в JetBrains “готовят” Agile и работают с Agile досками.

За продуктами JetBrains стоит множество команд: продуктовые, команды маркетинга, технической документации, дизайна и многие другие. Каждая команда придерживается собственного процесса, в зависимости от целей, ресурсов и особенности самой команды. На примере нашей компании и продукта YouTrack, мы расскажем о том, насколько гибкие бывают процессы, как найти подходящий для своей команды, и как настроить свою Agile доску.

Читать полностью »

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

image
Читать полностью »

Фреймворк Jobs-To-Be-Done: наш опыт использования - 1

Outcome-driven innovation — это фреймворк, в основе которого приоритизация планов разработки компании на основе задач, для которых клиенты эти продукты покупают — Jobs to be done. Фреймворк дает хорошее методическое описание и обоснование идей и практик, которые каждый product owner, по идее, и так применяет или должен применять, но обычно — интуитивно и на менее системном уровне.

На Codefest 2017 Аркадий Рушкевич, product-manager Wrike, рассказал о собственном опыте использования Jobs to be done и ODI — как и зачем Wrike начал заниматься этим, какие плюсы и минусы мы увидели, чего добились.
Делимся видеозаписью и презентацией доклада. Надеемся, что интересно будет и продакт оунерам с опытом, и тем, кто только начинает думать, как расставлять приоритеты и находить новые точки роста продукта.

Читать полностью »

Чем малайский отличается от индонезийского, или рассказ о том, как мы переводили приложение на 35 языков - 1

Человек человеку — друг, товарищ и переводчик. И особенно тот переводчик товарищ, который работает с локализацией. Как правило, проще всего локализировать мобильные приложения: объем текста небольшой, специальных терминов мало. Это если языков перевода немного, скажем, десять. А вот мы недавно делали локализацию на 35 (!) языков.

О том, как искали исполнителей, преодолевали трудности и какие были забавные моменты, — эта статья.
Читать полностью »

Метапоисковик — это не так просто, как кажется. Почему мы не можем подгружать сразу все туры? Почему так часто меняется цена? Кто виноват, когда тур “ушёл”, и как выкрутиться перед клиентом?

Об этих и других проблемах и багах сайта Travelata.ru я рассказал в первой части. Продолжаем публичную порку самих же себя.

Отельная страница

Когда открывается серп, направляется запрос в кеш, который хранится от 15 минут до нескольких часов. В момент открытия отельной страницы, если на отель из кеша пришло менее 3 туров, к ТО отправляется новый запрос на поиск по названию отеля. И могут приехать новые цены. Актуальные.

Почему вообще приходится так часто отправлять запросы к ТО?

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

Вторая причина — туры просто быстро раскупают.

image
Читать полностью »

image

Привет! Меня зовут Евгений Лисовский, я руковожу проектом MAPS.ME — это международный проект, интересный и очень амбициозный. Наша задача — конкурировать с Google, Apple и несколькими компаниями второго эшелона. Сегодня я кратко расскажу о своём трудовом пути, чтобы затем подробнее остановиться на самых интересных этапах.

До института я подрабатывал, собирал компьютеры на заказ. А свой компьютер у меня появился в 1995 году, в 13 лет — спасибо родителям, это было реально очень круто. В институте я начал сам изучать PHP, MySQL, соорудил собственный движок для интернет-магазина. Сделал три сайта, брал по 300 долларов за каждый. С 2004 года я работал в международной компании Radmin.com, которая создаёт b2b-продукт для удалённого управления компьютерами, там я провёл шесть лет. Потом ломанулся в стартапы: KupiBonus, детские товары BabyBoom. Там было интересно! Важны не только успешные проекты, но и фейлы: надо хорошо анализировать, почему они происходили. Потом был Litres. Очень интересный бизнес — продавать электронные книги при уровне пиратства 96 %. В 2015 году мы заработали 15 млн долларов, с 2011 года выручка выросла в 18 раз. Затем я вместе с партнерами запустил собственный проект MoikaMoika.ru. Не то чтобы основатели сразу стали миллионерами, но это интересный опыт. Проект жив и развивается. А дальше про всё это — более подробно.

Читать полностью »

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

10 инструментов для стартаперов и стартапов - 1

Startup Graveyard

Учимся на горьком, но полезном опыте предшественников. Strartup Graveyard — это каталог стартапов, которые потерпели неудачу и вынуждены были выйти из игры. Цель проекта, как уверяют авторы, вовсе не в том, чтобы клеймить людей за ошибки — напротив, объективный безоценочный анализ факторов, которые привели ту или иную компанию к печальному исходу, позволит «снять стигму с неудачи» и выстроить более открытое, вдумчивое сообщество. История болезни излагается в лаконичной, ясной форме: название, ниша, годы жизни, инвесторы и бюджет, конкуренты, основные причины краха. Посетителям также предлагается внести свою лепту — произвести вскрытие такого рода над известным им проектом (возможно, даже своим собственным) и отправить результаты администрации.
Читать полностью »

Всем привет!

Меня зовут Лариса. Я работаю в Google и веду блог на larrr.com, где я изначально и опубликовала эту статью.

Сегодня я предлагаю вашему вниманию статью, которая изначально была написана исключительно для внутреннего пользования Google. Мне очень понравилась, так что я связалась с автором, с ее разрешения я ее немного переделала, и получила разрешение от Google Press на публикацию. Перевод мой.

На всякий случай – это не официальный Google документ, и Google не несет ответственности за его содержание. Он субъективный, и написан сотрудником для сотрудников.

Советы для инженеров
15 апреля 2013
Отредактировано 21 мая 2014
Переведено 31 августа 2015
Gretta Bartels, Software Engineering Manager at Google

Уважаемый читатель,

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

Один из моих более опытных коллег научил меня тому, что для менеджера очень важно быть предельно предсказуемым. У менеджера должен быть какой-то набор простых правил, о которых знают все его подчиненные, и которым они могут следовать даже когда менеджера рядом нет. Поэтому моя цель – чтобы программисты в моей команде могли задать сами себе вопрос “Что бы на это сказала мой менеджер?”, и сами себе на него правильно ответить. Тогда команда сможет работать практически самостоятельно, без моего руководства. А я буду сидеть дома и кушать пирожные :).

Вот список моих основных правил:Читать полностью »

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

Любой этап заказчику системы стоит времени, дополнительных работ персонала и финансовых затрат, поэтому я представлю особенности, согласно которым можно пропустить тестовый период из жизни проекта.
Читать полностью »

Скрам в реальном мире. Обзор встречи для скрам-мастеров - 1

23 мая в питерском офисе Wrike прошла встреча для scrum-мастеров и project-менеджеров. Мы поговорили о реальном применении скрама в IT-разработке, инструментах scrum-мастера, взамоотношении компонентных команд с бизнесом, о целеполагании в условиях разработки по Agile и многом другом. Спешим поделиться видеозаписями докладов.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js