Управление продуктом *

В первой части статьи мы остановились на шаге 8 (Напомню, звучал он как “Формализация и дизайн”). Давайте с него и начнем: разделим этот шаг на несколько и распишем, что же происходит дальше, когда канва игровой идеи и список референсов у вас уже имеется.

Подчеркну, что в разных командах и в работе над разными играми (мобилки, ААА, браузерные платформеры, VR и т.п.) эти пункты могут отличаться. Сказывается как особенности платформы, для которой пишется игрушка, так и специфика жанра и аудитории. Могут появляться дополнительные шаги, что-то поменяется местами или вовсе будет пропущено. Поэтому не воспринимайте это как 100% руководство к действию, скорее как совет при ответе на вопрос “А что делать дальше?”. Надеюсь, многим из вас это действительно будет полезно=)

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

Перевод достаточно свободный, но сохраняет суть. При переводе ни один ИИ не пострадал.

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

Разработка сильного ценностного предложения — база в процессе развития бизнеса. Это основа, на которой строятся стратегии маркетинга и продаж. Вот вы четко сформулировали эту ценность, что делать дальше?

Следующим шагом должно быть использование наработок. И тут может встретиться одна из наиболее распространенных ошибок —  неспособность тщательно интегрировать ценностное предложение во все аспекты деятельности компании. Такое упущение  называется «интеграционным пробелом». Оно может значительно снизить эффективность даже самых сильных ценностных предложений.

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

Привет! Я Юля, менеджер продукта в Тинькофф Кассе. Мы делаем интернет-эквайринг для бизнеса, и в разработке продукта участвуют 30 команд. При создании новой фичи какие-то команды могут действовать обособленно, но это редкость. В большинстве случаев командам при разработке нужна помощь друг друга. Расскажу, как у нас получилось сделать так, чтобы не было очередей из команд.

Привет, Хабр! В этой статье подробно расскажем о том, как и почему Страховой Дом ВСК пришла к необходимости создания виртуального личного кабинета страхового агента. А также поделимся описанием функционала ЛКА.

 Начнем с небольшого предисловия: Страховой Дом ВСК – это одна из самых известных компаний страны. Более 840 филиалов и отделений дают возможность предоставлять услуги, обеспечивать поддержку и производить выплаты по всей России независимо от часового пояса клиента и места заключения договора.

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

Обычное дело — на этапе обсуждения будущего проекта студия выясняет, что на стороне заказчика нет лица, принимающего решение. Точнее он есть, но до него не добраться. Вместо него дела ведет доверенный менеджер. Брать ответственность за принятие окончательного решения он не может, но и выхода на ЛПР не дает.

Проблема в том, что это не выгодно никому — ни ЛПРу, ни менеджеру, ни подрядчику.

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

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

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

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

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Знакома ли вам такая ситуация: вы разработали модель машинного обучения и попытались оценить эффект, но эксперимент показал, что модель не принесла никакого экономического эффекта?

Значит ли это, что модель действительно неэффективна? Или причина низких результатов все-таки в чем-то другом? И если так, то в чем именно?

Нечто подобное случилось с командой Альфа-Банка, и мы – GlowByte Advanced Analytics – отправились к ним на помощь, захватив с собой разработанную нами библиотеку A/B-тестирования Kolmogorov ABacus (что в переводе означает “счеты”)!

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

Но далеко не все осознают важность принципа адекватности решения поставленной задаче. Мне довелось поработать с такими людьми — превосходными специалистами и притом безнадежными идеалистами. Под катом я расскажу о своем опыте, объединив черты нескольких человек в один собирательный образ.

Привет, Хабр! На связи снова я, Павел Анисимов — бизнес-трекер, совладелец нескольких ИТ-компаний и... любитель сложных, но интересных вызовов.

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

Наверняка, многим знакомо это ощущение: вроде есть бешеное желание развивать своё дело, энергии — хоть отбавляй, да только есть одно «но», в которое всё упирается.

Деньги — конечно же, речь о них. Где их раздобыть, когда уже вложено всё, что имелось; когда взято множество кредитов, но этого всё равно недостаточно для быстрого роста? Остается один вариант — привлечение инвестиций. И вот тут-то многие предприниматели начинают «буксовать», особенно новички. В голове куча вопросов: «А как? А что? В какой далёкой галактике этого инвестора выискивать? Его же ещё надо убедить вложиться в моё дело — ну нет уж, это совсем невыполнимая миссия...»

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

Привет! Сегодня наш разговор пойдет про сертификацию ФСТЭК и про тонкости этого процесса. Этот пост — не про теорию, а про практику, которая позволила нам получить одобрение ФСТЭК на версию 2.32 (на тот момент являлась новейшей - сейчас есть еще 2.33). Мы расскажем о том, что все это значит для пользователей нашей BI-платформы (из первых уст), а также почему мы уверены, что сертификация — это правильная практика не только “для бумажки”, но и для реальной пользы дела. Надеюсь, многое из этого текста окажется полезно как разработчикам российского ПО, так и его пользователям. Все подробности процесса нашей сертификации, в том числе мучительные — под катом!

В этой статье мы рассмотрим проблематику, с которой часто сталкиваются специалисты при подготовке опросов: некачественные или неправильно сформулированные вопросы. Какие вопросы следует исключить из своего опроса, чтобы не исказить результаты и не снизить эффективность исследования?

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

Привет, меня зовут Дима, я ведущий ИТ бизнес-партнёр в Петрович-Тех. Сегодня расскажу вам историю о том, как мы запускали продуктовый подход в инхаус-разработке.

В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные, с умножением на «пи» или на «е».

Эта статья о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.

Недавно мы с моим другом оплакивали странную смерть OKCupid. Семь лет назад, когда я впервые попробовал онлайн-знакомства, он работал следующим образом: нужно было написать длинный рассказ о себе и о том, что ты ищешь. Ты отвечал на сотни вопросов о своей личности, мечтах, о том, что хочешь увидеть в партнёре, о том, что для тебя недопустимо. Затем тебе показывали самых совместимых с тобой пользователей с «показателем соответствия» от 0 до 100%. Эти показатели работали пугающе хорошо. Почти каждый раз, когда я читал профиль пользователя с показателем соответствия 95% или выше, я как будто немного влюблялся. Каждое свидание было интересным; «химия» возникала не всегда, но мне казалось, что мы, по крайней мере, можем стать отличными друзьями.

Сегодня я достаточно скептически отношусь к количественным оценкам романтики и к идее о том, что схожесть обеспечивает хорошие отношения. Да и в то время я был довольно скептичен. Чего я не ожидал, так это того, что OKCupid образца 2016 года окажется лучшим, на что будут способны сервисы онлайн-знакомств. Что инструменты, при помощи которых люди будут пытаться искать самые важные отношения в своей жизни, будут становиться всё хуже, и хуже, и хуже. OKCupid, как и другие проекты, купленные Match.com, сегодня стал просто ещё одним клоном Tinder — видишь лицо, свайпаешь влево, видишь лицо, свайпаешь вправо. Цифровой ночной клуб. А я не хочу искать себе жену в ночном клубе.

И это касается не только приложений для знакомств. Почти все популярные потребительские приложения двигаются в сторону минимального участия пользователя, лент с бесконечным скроллингом и мусорного контента. Даже самое драгоценное в Интернете, поиск в Google, настолько испортился, что его нельзя использовать для сложных запросов. Reddit и Craigslist остаются невероятно полезными и ценными именно потому, что их ПО замерло в своём развитии. Как старые викторианские дома в Сан-Франциско, они стоят, защищённые причудами судьбы от ветров капитала, напоминая нам о более гуманной эпохе.

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

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

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

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

Думаю, наш опыт будет полезен тем, кто работает с бизнес-данными, занимается их анализом и хранением – словом, всем, кто активно вовлечен в проект или может на него влиять, принимая важные решения в опоре на данные. Поехали!

Как настроить коммуникацию с заказчиком, какие для этого использовать инструменты и приёмы, на что обратить внимание и чего точно нельзя делать, а самое главное – как сделать проект более успешным? Обобщила свой опыт в статье.