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

Джеймс Шуровьески

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

Поэтому, советую начать знакомство с нашей историей с первой части статьи.

— Сколько нужно дейта-сайентистов, чтобы закрутить лампочку?
— Один, если историческая выборка успешно закрученных лампочек достаточна.

Это, конечно, шутка, но когда в какой-либо компании речь заходит о том, чтобы приручить big data для улучшения бизнес-показателей, далеко не все понимают, кто именно будет приручать. Классическое мнение: нужен дейта сайентист (data scientist) — аналитик данных, который умеет строить модели, разбирается в искусственном интеллекте и машинном обучении. И этот человек в одну голову всё порешает.

Также, есть тренд, что когда в компании формируется подразделение Big Data, то Data Scientistы это те, кого в первую очередь нанимают.

В реальности все сложнее. Без дейта сайентиста, конечно, нет и работы с big data, однако он — один в поле не воин. Кто же еще должен воевать плечом к плечу с ним, лучше понять на примерах.

Разработка программного обеспечения и эксплуатация уже реализованного софта (например, приложения) находится в особом положении в контексте анализа расходов. Особенность в том, что типичный цикл производства товара и его продажи не существует в ИТ отрасли. Вместо этого мы имеем фактически бесплатно размножаемые копии продукта, но высокие издержки на само создание этого продукта и его поддержание. По этой причине экономика ИТ компании сильно отличается от экономики “свечного завода” или магазина.

Давайте детальнее рассмотрим ситуацию с издержками в ИТ компании. К сожалению не получится обобщить все ИТ компании в одну схему. Я попробую выделить несколько распространенных схем работы и рассмотреть их. Возможно кто-то из читателей добавит еще какие-то схемы, интересные для рассмотрения.

Я хочу выделить следующие типы ИТ компаний, хотя этот список, конечно, не полный:

1. Аутсорсинговая разработка — команда пишет софт под заказ и под требования заказчика. В дальнейшем софт чаще сопровождается самим заказчиком. Отношения фокусируются только на разработке и по сути продажи часов работников (как в форме прямой продажи часов, так и fix price, когда риски изменения сроков проекта ложатся на разработчика)
2. Вендор B2B софта — команда пишет софт для дистрибуции B2B, осуществляет внедрение, поддержку и разработку нового функционала.
3. B2C продукты — сюда я отнесу все компании, занимающиеся созданием B2C приложений и продуктов, работающих с массовым клиентом.
4. Провайдеры инфраструктуры — хостеры, дата центры, серверные мощности, сервисы обработки транзакций и т.п.

Какие расходы имеет первый тип компании? Давайте разделим на разные кучки расходы по основным типам, которые не зависят от предприятия:

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



Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.

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

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

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

Disclaimer:
У стартапа есть свои особенности. Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью. При этом мы должны держать качество продукта на таком уровне, чтобы за него было не стыдно. [Место для флейма про отсутствующую у некоторых совесть]. Замечу, что высокая скорость доставки фич подразумевает в том числе поддержание достаточно высокого качества кода. Иначе продукт рано или поздно захлёбывается в багах.

Все пункты ниже так или иначе выстраданы, практически на каждый есть кейс из реальной жизни.

Качество кода и архитектура

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

Более 5 лет я занимаюсь анализом продуктов, маркетинга, управленческих решений в ИТ компаниях или компаниях с большой опорой на ИТ. Я решил систематизировать свои знания и написать серию статей об организации и проведении анализа продукта. Я затрону темы оценки экономики, эффективности фич, обустройстве взаимоотношений с маркетингом, базами данных, оценке клиентского поведения и всего такого.

Ключевая задача — пройтись по всем инструментам управления и оценки продукта, обсудить используемые управленческие, маркетинговые и аналитические инструменты. Погрузится в применении Big Data и Machine Learning в развитии продукта, определить возможности этих решений и их применимость. Эта статья открывает серию статей по анализу продуктов.

Экономика продукта

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

Определение контура для анализа является ключевой задачей. Экономика продукта исключает множество финансовых явлений, характерных для экономики предприятия. Мы начнем с ядра формирования прибыли постепенно нарастим на него “мясо”.

Финансы продукта начинаются с простой формулы:

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

Введение
Что такое DoR
Зачем нужен DoR
Где применять DoR
Когда применять DoR
INVEST модель
Заключение
Список литературы

Введение

Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.

Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.

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

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

На основе этого плана мы ставим задачи разработчикам и «аудиторам» — коллегам из других отделов, которые проводят ревью решения (да, это тоже лайфхак). Надеемся, эта шпаргалка пригодится для подготовки к релизу продукта в прод.

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

В 2014-м году я присоединился к небольшой команде в Schibsted Media Group в качестве 6-го специалиста по Data Science в этой компании. С тех пор я поработал над многими начинаниями в области Data Science в организации, в которой теперь таких уже 40 с лишним человек. В этом посте я расскажу о некоторых вещах, о которых узнал за последние четыре года, сперва как специалист, а затем как менеджер Data Science.

Этот пост следует примеру Robert Chang и его отличной статьи «Doing Data Science in Twitter», которую я нашел очень ценной, когда впервые прочитал ее в 2015-м году. Цель моего собственного вклада ― поведать настолько же полезные мысли специалистам и менеджерам Data Science по всему миру.

Я поделил пост на две части:

• Часть I: Data Science в реальной жизни
• Часть II: Управление командой Data Science

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

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

Проходя собеседование на позицию Product Owner я понял, что у меня серьезный пробел по бизнес метрикам в Agile проекте, т.к. работаю в госструктуре. В русском сегменте информация достаточно скудная. В английском сегменте очень понравилась статья Ashwinee Kalkura. Поэтому решил сделать немного вольный перевод. Оригинал статьи здесь.

Что значат метрики для Agile команд?

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

Организации склонны копировать «то, что сработало для других», даже не заботясь об ограничениях и условиях, в которых конкретная метрика работала на «других».

Тогда, что измерять? На мой взгляд, организации, которые поняли, что и сколько измерять в продукте, выжили и процветают до сих пор. Они в конечном итоге стали Agile-организациями. Когда у них несколько продуктов, у них разные подходы для каждого из них. Некоторым продуктам потребуется много статистики и данных, в то время как некоторым понадобиться лишь пара метрик!

И как тогда понять, что именно нужно измерить? Для меня ближайший путеводитель — это 7-й принцип в Agile Manifesto — «работающее программное обеспечение — лучший измеритель прогресса». Если Вы можете определить, что является для Вас рабочим программным обеспечением, становится легче измерить прогресс.

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

От переводчика: оригинал статьи написан Александром Шапородом для блога его компании Django Stars. Они разрабатывают мобильные приложения, а своим опытом делятся с читателями.

Аутсорсинг в ИТ имеет ряд достоинств: например, он позволяет экономить средства и при необходимости получать помощь экспертов в тех или иных областях. Тем не менее есть и проблемы, риски, которых избежать очень сложно, если вообще возможно. Но если о них знать, то можно значительно снизить их влияние. Как? Об этом и поговорим.

Осенью 2016 года нам с коллегой поручили улучшить документацию и контент в моей бывшей компании. Мы потратили год на все виды документации: справочник по API, руководства, учебные пособия, сообщения в блогах. До этого я 5 лет писала доки, но официально не обучалась этому. Но и неопытной меня нельзя назвать: кроме документирования API для проектов и стартапа, я ещё преподавала Python Flask на семинарах во время учёбы на последних курсах в университете. Но сейчас выпала возможность сосредоточиться только на любимом деле: помогать специалистам всех уровней через техническую документацию.

В этом году я многому научилась в сообществе Write The Docs, у других провайдеров API, а также методом проб и ошибок. В прошлом году я поделилась опытом в докладе «Что мне хотелось бы знать о написании документации» на конференции API Strategy and Practice в Портленде. Эта статья — обзор полученных знаний.

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

Мы решили освежить летний сезон карьерным мероприятием «Чем живёт Product Manager», ну и разобраться в теме продуктового менеджмента.



Отдел маркетинга Alpha UX провел онлайн-исследование, чтобы выяснить, как проходит обычный день Product Manager'a. В опросе приняли участие более 100 продактов из 500 различных компаний. Давайте посмотрим, что получилось:

Product manager – позиция неоднозначная. На постсоветском пространстве еще не сложилось полноценной культуры управления продуктом, хотя продуктовых компаний уже в общем-то немало. «Продактами» становятся бывшие бизнес-аналитики, проектные менеджеры, маркетологи и другие специалисты, каждый из которых по-своему подходит к своим новым задачам. Я хотел бы поделиться несколькими тезисами о работе с новыми фичами продукта, которые кажутся важными с моей колокольни.


Это тоже в своем роде управление продуктами, но речь пойдет о другом.

Disclaimer:

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

Вероятно, вы уже слышали про применение lean-принципов к выводу новых продуктов на рынок. По мнению Эрика Риса (Eric Ries), главного идеолога такого применения, самое неэффективное, что стартап может делать при разработке продукта, – это создавать то, что никому не нужно.

Чтобы избежать этого, Рис предлагает тривиальную в теории идею: как можно скорее понять, что же все-таки нужно вашим потенциальным клиентам. Но как это сделать? А главное – причем тут lean, и научный подход?

Как перезагрузить отдел маркетинга за 7 дней и получить первый значимый рост уже через 30 дней?
Сервис кратного роста hopox позволит наладить работу Growth Team и тестировать гипотезы роста непрерывно.
В статье теория, практика и интрумент собраны в единую Технологию кратного роста.