Русский
Русский
English
Статистика
Реклама

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

Строим безопасную разработку в ритейлере. Опыт интеграции с кассовым ПО GK

26.11.2020 10:08:34 | Автор: admin
Что самое сложное в проектной работе? Пожалуй, свести к общему знаменателю ожидания от процесса и результата у заказчика и исполнителя. Когда мы начинали внедрять безопасную разработку в группе GK-приложений (кассового ПО) крупного ритейлера, то на входе имели вагон времени и задачи снижения уязвимостей в коде. А вот что и как нам пришлось решать на практике, мы вам расскажем под катом.
Кстати, это уже третий пост, в котором мы делимся своим опытом выстраивания процесса безопасной разработки для крупного ритейлера. Если пропустили, можете прочитать первые две части: о безопасной разработке порталов и мобильных приложений и о безопасной разработке в группе приложений SAP.



О проекте


С этого скоупа мы начинали, когда пришли к заказчику. Согласно стартовому плану проекта, у нас были довольно вольготные сроки его реализации. Мы очень радовались, наивно думая, что сможем вести несколько проектов одновременно. В итоге мы почти все время уделяли именно кассовому ПО, потому что все оказалось гораздо сложнее. В целом, это стало самым сложным направлением интеграции, поскольку здесь требовалась наиболее серьезная автоматизация процесса.

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

GK


GK это по сути фреймворк, на основе которого можно создавать свою кастомизацию кассового ПО. Заказчик несколько лет назад выкупил у GK некоторую часть исходного кода этого софта для создания собственной версии, соответственно, это направление представляло собой очень большую группу разработки. Большая часть ПО написана на языке Java (90% проектов). Встречались и некоторые проекты, написанные на C++ с использованием довольно древних библиотек, поскольку аппаратное обеспечение было заточено под этот стек технологий. Для Windows под Windows Server 2008 и под набор библиотек для Visual Studio, для которых данная версия ОС была последней совместимой.

В группе имелись свои жесткие процессы разработки, свои релизные циклы. Процесс ветвления был похож на Gitflow с основной веткой разработки и feature-ветками под разнообразные задачи. Однако feature-ветки могли быть в статусе разработки месяцами (часто готовые к merge, но заброшенные) и вливались прямо перед релизом, в который они по плану должны были войти.

Помимо внедрения в CI/CD мы еще внедрялись и в Jira, для чего нам пришлось создать отдельную сущность для классификации задач уязвимость. Этот вид задачи позволял заводить уязвимости внутри Jira в соответствии с процессом разработки и работы с таск-трекером.

Направление GK имело длинный процесс разработки, когда создается feature на какой-либо функционал, а потом эта feature-ветка может жить очень долго отдельно от основной ветки разработки. Ее могут верифицировать, но не могут влить в master или development почти вплоть до самого релиза ввиду технических сложностей регрессионного тестирования и т.п.

Решение для интеграции


Когда мы пришли в группу GK внедрять Solar appScreener, мы были удивлены огромным количеством кода в проектах этого направления и предложили стандартный вариант сканирования основной ветки разработки. Разработчики сказали, что они тоже хотят получать информацию об уязвимостях и тоже хотят пользоваться анализатором, но не так, как офицеры безопасности. Им нужна была автоматизация проверки на уязвимости: единая точка входа в виде GitLab, где можно видеть все изменения. Чтобы на сканирование автоматически запускался код не только основной ветки разработки, но и всех побочных веток. При этом нужен был автоматизированный запуск из Jira и по просьбе заказчика полуавтоматизированный из Jenkins и GitLab.

В итоге мы решили, что самым простым способом анализа ветки (в особенности для долгих feature-веток) будет запуск сканирования таким образом, чтобы задача в Jira при ее полном завершении (финальном push-е) переводилась в статус in review. После чего она попадала к специалисту, который может принять изменения и дать добро на старт сканирования кода на уязвимости. Иначе анализ кода по каждому push-у разработчика в репозитории создал бы адскую нагрузку и на людей, и на технику. Разработчики комитили код в репозитории не реже раза в пять минут, и при этом проекты порой содержали по 3,5 млн строк кода, одно сканирование которого, соответственно, длилось 6-8 часов. Такое никакими ресурсами не покроешь.

Стек технологий


Теперь немного о том, какой набор технологий использовался в проекте. GitLab в качестве системы контроля версий, Jenkins в качестве CI/CD-системы, Nexus в качестве хранилища артефактов и Jira в качестве системы отслеживания задач. При этом сами разработчики взаимодействовали только с Jira и с GitLab, тогда как с Jenkins инженеры, а с Solar appScreener безопасники. Вся информация об уязвимостях в коде присутствовала в GitLab и Jira.

Поэтому пришлось организовать процесс сканирования следующим образом: в Jira задача переводилась в in review через Jenkins, так как была необходима сборка. Имелся целый стек из Jenkins-плагинов и скриптов, которые получали веб-хук из Jira. То есть помимо вида задачи уязвимость нам пришлось создавать в Jira еще и веб-хуки, которые при изменении проекта в GK отправлялись в Jenkins и требовали дополнительных шагов по настройке и серьёзной доработке двусторонней интеграции. Процесс был таким: когда в GK обновлялась какая-либо задача, Jira проверяла, соответствует ли эта задача тем, которые должны отправляться в Jenkins, а именно является ли это задачей разработки. И только после этого веб-хук уходил в Jenkins, который парсил веб-хук и на основе тела запроса понимал, какому репозиторию в GitLab и какой группе работ (job-ов) нужно запускаться.

Разработчики GK выставили ряд требований при заведении задач в Jira, и мы старались их использовать по полной, чтобы получить максимальное количество информации. Благодаря этому мы смогли правильно матчить репозитории в GitLab и ветку, которую мы должны были стянуть из конкретного репозитория для ее запуска на анализ. В требованиях мы жестко прописали, что ветка в GitLab обязательно должна содержать в названии номер задачи в Jira. В принципе, это best practice, который используется повсеместно в самой задаче должны быть метки, маркирующие, к какой части приложения/системы относится проблема.

На основе веб-хука, в котором содержалось название проекта, метки, поля с компонентами, а также ключ самой задачи и т.п., происходило автоматическое определение необходимости запуска всех задач. Часть проектов получала ответ всех значений удовлетворительно и после этого отправлялась на сканирование. А именно: поступал запрос в GitLab, проверялось наличие в нем данной ветки разработки, и при подтверждении система запускала сканирование новой части кода этой ветки в Solar appScreener.

Учитываем пожелания



Кадр из мультфильма Вовка в тридевятом царстве

Поскольку уязвимостей в GK-проектах было десятки тысяч, разработчики не хотели видеть их все. Меж тем в коде содержались порой критичные уязвимости: вставленные в код пароли, отраженные межсайтовые скриптинги, SQL-инъекции и т.п.

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

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

Как и для остальных проектов компании, мы выстроили для GK соответствие проекта в GitLab проекту в Solar appScreener, а дополнительно провели корреляцию с веткой разработки. Чтобы разработчикам и офицерам ИБ было проще искать, мы создали файл с реестром названия группы репозиториев, конкретного проекта из этой группы и ветки в Solar appScreener.

Кроме того, разработчики хотели видеть комментарии с изменениями сразу в GitLab, и вот как мы это сделали.

Интеграция с GitLab


Сначала мы сканировали основную ветку разработки для каждого репозитория, от которой шла ветка с изменениями. Поскольку разработчики хотели видеть комментарии с изменениями сразу в GitLab, мы договорились, что если ветка переведена в статус in review, это значит, что уже есть соответствующий merge request на ее вливание. Система проверяла, что merge request был действительно открыт, и если это подтверждалось, то Solar appScreener анализировал основную ветку разработки. Затем он сканировал ветку с изменениями, строил diff, выгружал его, получал только новые уязвимости, брал из них критичные (наш инструмент позволяет настраивать уровни критичности) и преобразовывал их описание в формат текстовых сообщений со ссылкой на данное вхождение в конкретном проекте в Solar appScreener (см.скриншот ниже). Эти сообщения отправлялись в GitLab в виде дискуссии от имени технической учетной записи. В merge request вместе с измененным кодом можно было увидеть непосредственно строку срабатывания. Её сопровождал адресованный конкретному разработчику комментарий в GitLab типа вот здесь содержится уязвимость, пожалуйста, поправьте или закройте ее.



Таким образом, между этими двумя сканированиями мы выявляли изменения, которые привнес разработчик. Если количество уязвимостей увеличивалось, это обязательно отражалось в комментариях отчёта. Такая схема была очень удобна для всех участников, потому что в GitLab сразу же появлялись неразрешенные дискуссии, а это значит, что merge request влить нельзя. И ответственный за approve merge requestа видел, что разработчик допустил уязвимости, и их нужно закрыть.

Интеграция с Active Directory


Чтобы просматривать уязвимости через Solar appScreener, разработчикам нужны были права. Поэтому помимо всей интеграции с системами разработки и со всеми тремя скоупами мы еще интегрировались и с сервисами Active Directory. Для нас некоторую сложность представляло то, что у заказчика был чудовищно большой AD с миллионом вложенных групп, что потребовало множества оптимизаций. То есть помимо внедрения CI/CD нам приходилось в процессе решать много сопутствующих задач настройки, адаптации и оптимизации (см. скриншот ниже).



Что касается интеграции с Active Directory, разработчики GK не хотели настраивать параметры доступа в ряд проектов Solar appScreener непосредственно в AD, потому что они не были владельцами этого ресурса. В компании процесс выдачи прав доступа выглядел следующим образом: если разработке нужно было внести нового человека в группу, приходилось писать заявку в техподдержку. Там определяли, кому именно отправлять данный запрос, кто отвечает за выдачу подобных прав, действительно ли можно выдать этому человеку права, авторизованы они или нет и т.п.

Это трудоемкий процесс, которым разработчики не управляли, в отличие от GitLab.Поэтому они попросили организовать интеграцию с AD следующим образом. Они разрешают видеть уязвимости не только техвладельцам системы и офицерам безопасности, как это было сделано для других направлений, но и сделать матчинг прав в GitLab. То есть если человек имеет права разработчика и выше (maintainer, владелец репозитория), то он может просматривать соответствующие проекты в Solar appScreener, которые относятся к этому репозиторию. Когда в Solar appScreener создавался новый проект, система запрашивала имена всех, кто состоит в GitLab в данном репозитории с уровнем доступа выше разработчика. Список выгружался, поступало обращение в анализатор кода, который в свою очередь отправлял запрос в AD с добавлением списка отобранных людей. Все, кто состоял в данном репозитории в GitLab, получали автоматические права через свои AD-учетки на доступ к проекту в Solar appScreener. В конце всей цепочки генерился pdf-файл с отчетом по уязвимостям из анализатора кода. В отчете содержался diff, который рассылался списку пользователей проектов GK на электронную почту.

Резюме


Реализованная интеграция с кассовым ПО GK это пример весьма масштабного проекта внедрения и автоматизации в компании процесса безопасной разработки, который был выстроен не только вокруг службы информационной безопасности, но и вокруг разработчиков. Причем в этой группе проектов так же, как и в других группах, параллельно шли сканирования основной ветки разработки: офицеры безопасности тоже заводили задачи в Jira и их верифицировали. Уязвимости заносились в бэклог и позже исправлялись.

Разработчики получили для себя удобный инструмент, встроенный в привычную среду и workflow. Так как они выбрали для себя порог из топ критических уязвимостей, которые довольно редко возникают, их нагрузка несильно возросла после внедрения. В итоге довольны оказались все участники проекта: и те, кто стремился повысить безопасность кода, и те, кому приходилось исправлять уязвимости.

Если у вас есть собственный опыт реализации практик безопасной разработки, пожалуйста, поделитесь им в комментариях!

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

Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем
Подробнее..

Перевод Как определить метрики для процесса Управления проблемами

14.11.2020 16:05:59 | Автор: admin

Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов.

Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.

Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете.

Первый шаг для определения качественных ключевых показателей (KPIs) - определить цели процесса Управления проблемами, которые его результаты должны помочь вам достигнуть. Для у правильного процесса Управления проблемами есть два ключевых результата:

  • уменьшение количества возникающих инцидентов

  • уменьшение влияния на бизнес от инцидентов, которые не смогли предотвратить

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

  • определение проблем, которые являются причиной множественных инцидентов

  • создавать среду, которая снижает влияние от инцидентов

  • инициирование изменений, которые уменьшают количество инцидентов

Стоит сказать, почему я не упомянул поиск корневых причин проблем (root cause analysis, RCA). Я видел много людей в управлении проблемами, кто думал только о поиске корневых причинах, но это не давало им особого результата, потому что RCA - это не более чем одна из техник, используемых в Управлении проблемами. Худшие ключевые показатели, которые можно придумать, - это среднее время обнаружения корневой причины, доля проблем, у которых ключевая причина была выявлена не хуже 3 дней и т.п. Использование таких показателей провоцирует участников Управления проблемами на поведение, которое мне бы не хотелось получить. Это равносильно заявлению, что в сложной многофакторной ситуации нужно искать единственную корневую причину. Для меня более правильный способ - это проведение постоянного анализа, даже если в его результате удастся идентифицировать только одну значимую причину.

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

Мое предложение нескольких ключевых показателей (KPIs), которые могут помочь показать достижение критичных факторов успешности (CSFs), которые я приводил выше. Еще раз напомню, что не стоит бездумно их копировать, используйте похожий подход для определения ключевых показателей (KPIs), которыми можно измерять ваши задачи.

CSF1 - определение проблем, которые являются причиной множественных инцидентов

  • увеличение доли инцидентов ассоциированных с записями о проблемах или известными ошибками

  • отчет о топ 5 проблем создается каждый месяц

CSF2 - создавать среду, которая снижает влияние от инцидентов

  • увеличение доли инцидентов, для которых в базе знаний есть статьи с решениями

  • увеличение доли инцидентов решенных пользователями с использованием инструментов самостоятельного решения

  • уменьшение влияния инцидентов, ассоциированных с топ 5 проблем прошлого месяца

CSF3 - инициирование изменений, которые уменьшают количество инцидентов

  • уменьшение количества инцидентов, ассоциированных с топ 5 проблем прошлого месяца

  • уменьшение беклога незавершенных проблем

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

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

PS Если тема интересна, можно познакомиться со статьями Стюарта Рейнса:

Как определять метрики для процесса Управления (перевод, оригинал)

Осторожно. Как использовать метрики процессов без вреда для здоровья процессов (перевод, оригинал)

Подробнее..

Перевод Как определить метрики для Управления инцидентами

15.11.2020 14:11:45 | Автор: admin

Я уже писал о там, как можно опеределить метрики (metrics) и ключевые показатели (KPIs) для некоторых процессов управления ИТ услугами (IT service management). В статье Как определить метрики для процесса Управления изменениями (перевод, оригинал) я рассуждал о важности идентификации заинтересованных лиц и определения факторов достижения успеха (CSFs), и дальнейшего использования этого при поиске ключевых показателей (KPIs) для измерений и отчетности. В статье Как определить метрики для процесса Управления проблемами (перевод, оригинал) продолжил тему и показал, как ключевые показатели (KPIs), предлагаемые в лучших практиках (например, ITIL), могут не подходить под реальные ситуации.

В ITIL (книга ITIL Practitioner)предлагается любопытная методика определения метрик в виде последовательного декомпозита Факторов достижения успеха процесса (CSFs) - Ключевые показатели процесса (KPIs) - Метрики (Metrics). Если очень кратко, то

  • CSFs - это качественное описание результатов успешной работы процесса

  • KPIs - количественное описание результатов успешной работы процесса

  • метрики - что именно измеряем для расчета KPIs

В ответ на эти статьи я получил несколько запросов продолжить цикл и особенно часто встречался запрос на описание метрики для процесса Управления инцидентами (Incident Management). Ниже, что я думаю о том, как можно определять метрики для Управления инцидентами (Incident Management).

Первый вопрос, на который нужно ответить: Что такое управление инцидентами? Какая у него цель?. Ответы могут не совпадать, но большинство компаний получат что-то похожее на:

  • Мы решаем инциденты со скоростью, чтобы их последствия не влияли значительно на наших заказчиков

  • Мы решаем инциденты в порядке соответствующем их влиянию и заявленной срочности

  • Мы взаимодействуем с заказчиками и пользователями так, что они понимают, что у них происходит и на какой срок решения инцидента они могут рассчитывать

  • Заказчики и пользователи удовлетворены тем, как мы устраняем их инциденты

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

  • Мы рационально используем наши ресурсы в процессе Управления инцидентами (Incident Management)

В идеале наши ключевые показатели должны помогать понимать достигнуты ли эти цели и показывают тренды, для определения, что требуется улучшить. Теперь давайте подумаем о том, что можно для этого измерять. Пожалуйста, не забывайте, что это все только пример, показывающий как можно думать об Управлении инцидентами (Incident Management).

Часть ключевых показателей (KPIs) могут идеально подойти одним компаниям и совершенно не подойти другим. Например, некоторые измеряют решение при первом контакте (First Call Resolution, FCR), т.е. какая доля обращений была решена в течение звонка на техподдержку (service desk) с обращением о наличии инцидента. Для многих компаний это отличный способ измерения того, что они быстро решают инциденты и рационально используют ресурсы, но если вы развиваете инструменты самообслуживания, то можете обнаружить, что показатель решения при первом контакте ухудшается, при том что качество услуг повысилось.

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

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

  • Мы решаем инциденты так быстро, чтобы их последствия значительно не влияли на наших заказчиков

    • процент инцидентов 1-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

    • процент инцидентов 2-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

    • процент инцидентов 3-го приоритета решенных не хуже требования в Соглашении об уровне обслуживания (SLA)

  • Мы решаем инциденты в порядке соответствующем их влиянию и заявленной срочности

    • количество инцидентов, приоритет которых был изменен после регистрации обращения

    • количество жалоб заказчиков или обращений для поднятия приоритета инцидента

  • Мы взаимодействуем с заказчиками и пользователями так, что они понимают, что у них происходит и на какой срок решения инцидента они могут рассчитывать

    • процент инцидентов, в которых заказчик запрашивал информацию о состоянии решения инцидента

  • Заказчики и пользователя удовлеитворены тем, как мы устраняем их инциденты

    • процент пользователей давших оценку 4 или 5 в опросе удовлетворенности решением инцидента

    • изменения удовлетворенности заказчиков работой процесса Управления инцидентами (Incident Management) по итогам ежегодных опросов

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

    • число проблем зафиксированных техподдержкой (service desk)

    • число проблем зафиксированных аналитиком инцидентов

  • Мы рационально используем наши ресурсы в процессе Управления инцидентами (Incident Management)

    • процент инцидентов зарегистрированных на портале самообслуживания

    • процент инцидентов решенных на портале самообслуживания

    • средняя цена решения инцидентов (в разрезе приоритетов)

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

После прочтения ответьте для себя на пару вопросов:

  • На чем основаны ваши текущие ключевые показатели (KPIs) процесса Управления инцидентами (Incident Management)?

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

  • Почему бы на пересмотреть их и не начать измерять и оценивать то, что действительно важно для вас?

На этом все надеюсь статья была интересна

Подробнее..

Перевод Сбалансированная система показателей для ключевых показателей IT

22.11.2020 18:15:46 | Автор: admin

Я ранее написал несколько статей о метриках и ключевых показателях (KPIs) для некоторых процессов Управления ИТ услугами. Вот ссылки на них в случае, если хотите с ними ознакомиться.

Очень круто иметь продуманные ключевые показатели (KPIs) индивидуально под конкретные ITSM процессы, но даже в этом случае можно получить огромный неудобный отчет, из которого не каждый сможет извлечь пользу.

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

Что такое сбалансированная система показателей?

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

  • Финансы - метрики, позволяющие понять, как используются ресурсы вашей компании

  • Клиенты - метрики, позволяющие понять, насколько удовлетворены потребности заказчиков и на сколько заказчики этим удовлетворены

  • Внутренние бизнес процессы - метрики, позволяющие понять результативность и рациональность внутренних процессов и достигают ли они требуемых от них целей.

  • Обучение и развитие - метрики, позволяющие понять, как вы готовы к будущему и позволит ли ваша процедура непрерывного улучшение оставаться вам конкурентоспособными

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

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

Например, можно в обобщающем ИТ-отчете встретить такие показатели:

  • Финансы: процент расходования годового бюджета ИТ, возврат инвестиций в ИТ проектах.

  • Клиенты: удовлетворенность ИТ-заказчиков, достижение целевых сервисных метрик сквозных процессов.

  • Внутренние бизнес-процессы: количество ITSM процессов с достигнутыми целями, количество IT-проектов, по которым были достигнуты согласованные цели.

  • Обучение и развитие: количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения (CSI), среднегодовое время обучение IT-персонала.

Далее показатели могут быть разбиты для отдельных ITSM процессов или рабочих групп. Например, деятельность технической поддержки (service desk) можно измерить и оценить:

  • Финансы: общегодовая затрат на работу техподдержки, средняя стоимость одного инцидента.

  • Клиенты: рейтинг удовлетворенности по закрытым инцидентам, процент выполненных соглашений об уровне обслуживания.

  • Внутренние бизнес-процессы: количество проблем созданных техподдержкой.

  • Обучение и развитие: число предложений на улучшение, поданных в реестр процесса непрерывного улучшения сотрудниками техподдержки и принятыми для реализации; число сотрудников техподдержки, которые потратили не менее 4 часов на обучение сотрудников бизнес подразделений.

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

В заключении автор предлагает каждому ответить для себя на несколько вопросов:

На сколько текущие метрики ваших процессов управления ИТ-услугами покрывают все 4 проекции сбалансированной системы показателей?

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

Можете исключить из отчетов несколько существующих метрик и ключевых показателей, которые используются только для менеджерами процессов, чтобы исключить перегрузку отчетов для заказчиков услуг информацией о внутренней ИТ-жизни?

Подробнее..

Перевод Оценка трудозатрат в разработке ПО для начинающих

02.12.2020 06:07:25 | Автор: admin

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

Помню, как меня впервые попросили дать оценку

Тогда это застало врасплох.

Меня завели в кабинет, где были мой начальник, его босс и кто-то из вышестоящего руководства, и мы сели за круглый стол, уставившись друг на друга.

Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.

И тут мой начальник повернулся ко мне и спросил: Сколько времени это займет?

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

И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.

Передо мной лежала бумага для заметок. Я взял один листок и начал писать какие-то числа без понятия, для чего, но точно не для этой оценки.

Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: Не знаю часов 600?

Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200часов.

Не очень люблю вспоминать тот день.

Понятно, что мне еще многое предстояло узнать, но меня мучил один вопрос: как оценивать объем предстоящей работы?

Цель проведения оценки

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

Оценка объема работы используется в основном в двух целях:

  • Планирование.

  • Выставление счета клиенту.

Планирование

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

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

Допустим, в вашей команде разработчиков три человека. Каждый работает по 40часов в неделю это примерно 160часов в месяц, или 480часов в квартал (на троих примерно 1500часов).

Представьте, что ваша команда должна выполнить пять проектов с оценками объемов работ 800, 400, 300, 200 и 50часов. Планируя загрузку, вы будете видеть, что не сможете к концу квартала выполнить все проекты. Менеджеры составят график, использующий определенный процент максимальной загрузки на случай, если разработка займет больше времени, чем предполагалось.

С оценками из нашего примера можно было бы взяться за проекты на 800, 400 и 50часов, и при этом осталась бы некоторая свобода для маневра.

Выставление счета клиенту

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

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

Примечание. Это применимо не ко всем компаниям разработчикам ПО: не все занимаются разработкой на заказ. Если вы не разрабатываете ПО на заказ, то оценки объема работ будут использоваться в основном для планирования.

Ключевые факторы при оценке

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

Фото AbsolutVision, площадка UnsplashФото AbsolutVision, площадка Unsplash

1. Не оценивайте, сколько времени понадобится ВАМ

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

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

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

2. Не занижайте завышайте

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

Если разработчики выйдут за отведенный вами срок, это нарушит график работ.

Находиться в границах 20% это нормально, но только если оценка оказалась завышена а не занижена.

К какой бы цифре вы ни пришли, добавьте к ней 20%: задачи обычно оказываются сложнее в реализации, чем кажется.

3. Повышение квалификации

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

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

Фото Matheus Frade, площадка UnsplashФото Matheus Frade, площадка Unsplash

4. Примеры аналогичных проектов

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

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

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

5. Не забывайте об аналитиках

Часто вас будут просить дать полную оценку, а она включает в себя время разработчиков, бизнес-аналитиков и специалистов по обеспечению качества.

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

Также потребуется учесть время, необходимое отделу контроля качества для тестирования. Возможно, у вас есть какая-то система автоматизации, которую нужно настроить и для этого проекта тоже? На всё это нужно время, которое также включается в оценку.

Заключение

Чтобы научиться давать оценку объему работу, нужно время. Этот навык, как и любой другой, требует практики.

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

Если резюмировать самое главное, запомните вот что:

задача всегда сложнее, чем кажется, и лучше переоценить объем работ, чем недооценить.

Никто не будет злиться, если у вас всё пойдет по плану, начальство даже порадуется! И при этом у вас останется больше времени на другие проекты.

Так что не стесняйтесь выделять побольше времени и помните, что оценка это всего лишь оценка.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Управление разработкой в горизонтальных компаниях расшифровка онлайн-встречи. Часть 2

18.11.2020 16:23:31 | Автор: admin

На прошлой неделе мы выпустили расшифровку первой части онлайн-встречи Управление разработкой в горизонтальных компаниях, где приняли участие СТО Райффайзенбанка, Mindbox и руководитель разработки в Циан.

Сегодня публикуем вторую и последнюю часть митапа: это вопросы из зала, которые задали слушатели гостям. Пост получился объемным, поэтому, если не хотите читать, то посмотреть видео можно ниже (запустится сразу с нужного момента там, где закончилась первая часть).

Гости

Темы второй части

  • Чем leadership внутри плоской команды отличается от менеджмента?

  • Как в горизонтальной структуре решаются вопросы безопасности?

  • Какие плюсы от открытых зарплат в Mindbox?

  • Как команда соблюдает technical excellence?

  • Как в горизонтальных компаниях шарятся ресурсы?

  • Есть ли у вас и как устроен Performance Review?

Чем leadership внутри плоской команды отличается от менеджмента. Как решаются вопросы безопасности. Technical excellence. Решение конфликтов

Алексей Рыбак: Давайте сейчас перейдем к вопросам из зала. Я начну зачитывать те вопросы, которые есть в текстовом чате. Первый вопрос был от Димы Кушникова. Сергей, а чем leadership внутри команды отличается от менеджмента?

Сергей Кононенко: Менеджмент command and control. Command and control никто из этих троих людей, которые входят у нас в leadership team, не занимается.

Алексей Рыбак: Понял. Следующий вопрос тоже от Дмитрия. Банковское обслуживание довольно регулируемая индустрия. Наверняка есть огромное количество требований, которые необходимо соблюдать, чтобы регулярно проходить аудит безопасности? Что случилось с политикой безопасности в процессе трансформации?

Сергей Кононенко: Ничего не случилось, они все с нами. Аудиты есть не только по безопасности, есть много других аудитов, которые мы регулярно проводим: как внутренние, так и внешние, так и групповые из Raiffeisen Group.

Алексей Рыбак: Следующий вопрос был тоже от Дмитрия. Сергей, кто и как контролирует, что команда соблюдает договоренности, technical excellence? Как происходит изменение требований technical excellence?

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

Алексей Рыбак: Хорошо, следующий вопрос. По-видимому, уже всем. Вопрос от Вадима Назарова. Отличный, кстати вопрос. Как организуется решение конфликтов, если платформенной команде в рамках своего проекта требуются какие-то доработки от продуктовых команд, а у продуктов тоже свой бэклог?

Сергей Кононенко: Мне, наверное, проще всего ответить. У нас нет платформенных команд, которым нужны какие-то особенные доработки. Платформенные команды выставляют definition of done, что значит разработка на их платформе. Если этот definition of done под продуктовые команды не соблюден, то их инкремент просто не принимается в платформу.

Алексей Рыбак: Понятно. Никита, как у вас?

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

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

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

Алексей Рыбак: У тебя есть платформенная команда, которая переходит с одной версии API или базы данных на другую. И логику надо переписать, потому что тот SQL, который я написал, или тот API, который я использую, новым софтом не поддерживается. Я должен переписать достаточно важный кусок. Я не хочу его трогать, оно поломает дофига всего. Я объяснил это продакту, который говорит: Не-не-не, вы вчера сломали что-то. И в прошлом месяце что-то сломали. Нет, сейчас мы делать не будет, потому что у нас очень важные планы, бла-бла-бла

Никита Прудников: Да, я понял, могу ответить.

Алексей Рыбак: Ну, привет! А когда? Вы встретились, сказали: Встретимся через две недели и поговорим. За две недели произошло еще что-то, через две недели тоже. Вот такой сценарий. Дальше?

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

Алексей Рыбак: Кто влезет в бизнес-логику? Платформенная команда влезет в бизнес-логику, перепишет какие-то вызовы, платформу?

Никита Прудников: В том числе она может так сделать, конечно.

Алексей Рыбак: Я понял. У вас были такие кейсы? В реальности были такие ситуации или нет? Как они разрешались?

Никита Прудников: Давай подумаем. У нас часто нет такой суперантогонизации между ролями команд. То есть, если такие кейсы возникали, чаще всего не было конфликта. Платформенная команда договаривалась с продуктовой, у которой вообще-то есть выделенный постоянно ресурс на технический долг, который она может тратить. И они решали, что эту часть чуваки сделают у себя, потому что это business critical, и они очень сильно в домене это знают, эту часть запулит себе платформенная команда.

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

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

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

Алексей Рыбак: Это применимо только для таких задач, которые ты можешь сформулировать на языке продукта. У тебя может быть конфликт вокруг задач, которые продукт даже не может понять.

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

Алексей Рыбак: Хорошо. Михаил, у вас конфликты тоже решаются больше на более ранней стадии общения? Или можешь вспомнить какие-то примеры, когда они выплеснулись куда-то, не смогли решить?

Михаил Юматов: Бывают ситуации, когда команда платформы не может договориться с продуктовой командой. В этом случае они подключают меня или это может дойти до уровня CTO, где мы можем разрешить этот конфликт. И это либо укладывается в квартальное планирование, если это какие-то большие истории, которые затрагивают много продуктовых команд, и нужно разрезать весь этот проект продуктовым командам плюс платформе. Либо это какие-то небольшие истории в рамках квартала. И, соответственно, либо продуктовые команды самостоятельно договариваются вместе с платформой, либо не договариваются и эскалируют выше. И мы уже вместе принимаем решения.

Открытые зарплаты: какие от них плюсы. Рыночные зарплаты, воронка кандидатов. Описание задач

Алексей Рыбак: Ясно, спасибо. Никита, к тебе вопросы. Два вопроса. Первый вопрос от Димы Кушникова. Какие плюсы вы получаете от открытых зарплат?

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

Алексей Рыбак: Да, но, с другой стороны, появляется в том числе и определенное давление отрицательного характера, которое никуда не деть, а так бы его могло бы и не быть.

Никита Прудников: А какого отрицательного давления?

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

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

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

Алексей Рыбак: То есть ты думаешь, что настолько все привыкают, в том числе к такого рода культуре, что и уже уходить некуда? Ты это имеешь в виду?

Никита Прудников: В каком-то смысле я это вижу. У нас компания, с точки зрения нагрузки, серьезная. Именно day-to-day workload большой. И мы даже со своей стороны, сейчас интересный минус расскажу открытых зарплат, мы до сих пор не придумали хорошего процесса, чтобы люди самостоятельно пушили свою зарплату.

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

И мы сейчас с HR, с каким-то таким вещами занимаемся. Возможно, восприму твой совет про один на один, что надо реструктурировать в этом месте. То есть такая проблема есть.

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

Алексей Рыбак: Разные бывают ситуации, особенно когда большие коллективы. Такой еще вопрос, перекликается с одним из последних, по-моему, вопросов. А как часто вы делаете рыночный обзор зарплат? И есть ли у вас процесс, который оценивает, произошел ли gap up? Или люди скромно работают, а потом в какой-то момент им поступает предложение и они находятся в ситуации, когда: Блин, нифига себе. Это почему у нас

Никита Прудников: Ну, gap большой. Но это то, про что я рассказал.

Алексей Рыбак: Вопрос был довольно прямой: рыночные ли у вас зарплаты? Я здесь развернул: как часто у вас происходит такого рода ревью? Что из себя представляет этот процесс?

Никита Прудников: Ревью обычно происходит с точки зрения вакансий. Я и еще ряд людей, мы занимаемся интерированием вакансий на HeadHunter. И нам, естественно, с учетом того, что полностью открыты зарплаты внутри компании, этот гэп понятен. То есть у нас есть какая-то вилка на HH, к нам приходят какие-то люди по воронке

Алексей Рыбак: Прости, Никита, не понял. Как он вам понятен? С HeadHunter вы взяли эту информацию?

Никита Прудников: Мы делаем вилку на HeadHunter в вакансии, и к нам в воронку приходят какие-то люди. У нас нон-стоп конвейер собеседований. У меня каждый день примерно по одному собеседованию C#, лидов, я участвую.

Алексей Рыбак: Правильно я понимаю, что вы собираете это с потока входящих?

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

Алексей Рыбак: С потоком такая проблема. Ты ошибся, ты получаешь достаточное количество людей, но не получаешь определенных людей. У тебя получается ошибка смещенной оценки. С одной стороны, ты получаешь достаточное количество людей, которые зааплаились и что-то назвали. И при этом какую-то часть не видишь.

Никита Прудников: Но я в этот момент рефлексирую вилку, с ней же тоже процесс есть, она меняется. Если я вижу, что воронка работает не на меня, в этот момент я ее меняю.

Алексей Рыбак: Хорошо. У тебя есть понимание, какая текучка внутри компании?

Никита Прудников: Если говорить, кроме людей, которые не прошли испытательный, то, дай подумаю В этом году у нас уволилось то ли один, то ли два человека. Могу ошибаться, я сейчас назад просто прокручиваю. Мне кажется, давай два.

Алексей Рыбак: То есть 2%? Если 50 человек

Никита Прудников: Я тут боюсь обмануть, честно тебе скажу. Просто я сейчас что-то из памяти вспоминаю. Кажется, оценка такая.

Алексей Рыбак: В любом случае это какие-то части. Давай двинемся дальше. Был еще вопрос, тоже, Никита, тебе. У нас минута Mindbox. Вадим Назаров спрашивает. Чем занимаются архитектор? Есть ли он? Кто ему ставит задачи? Кому подчиняется? Взаимодействует ли он с командой?

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

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

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

Алексей Рыбак: Понял. Никита, спасибо большое. У нас есть первый смелый. Спасибо большое, Георгий. Поднял руку, оказался на панели среди спикеров. Георгий, у вас вопрос. Прошу вас. Только включите, пожалуйста, микрофон.

Георгий: Всем привет. Во-первых, спасибо, Алексей, за такое мероприятие, интересно послушать, как бывает у людей. У меня вопрос к ребятам, к коллегам. Много было сказано по поводу задач. А кто занимается описанием задач? Участвуете ли вы в этом? Насколько глубоко описываются у вас задачи?

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

Алексей Рыбак: Спасибо большое. Кто хочет ответить из вас?

Сергей Кононенко: Давайте я отвечу. Задачи прорабатываются внутри команды. Если задача не имеет понятного acceptance-критерия, то есть критерия, по которому мы поймем, что задача сделана, то, скорее всего, она будет сделана не сразу, не очень качественно, и у нас будут сюрпризы. Поэтому, пока команда не поймет, что они понимают, что нужно сделать, скорее всего, задача в работу не пойдет.

Алексей Рыбак: В связи с этим у меня вопрос. Это искусство описывать задачи, в том числе это искусство Мы это всегда называли PRD, спеки не важно. Спеки более технический текст, PRD более продуктовый. Там идет взаимодействие с дизайнером, там идет взаимодействие, может быть, не с одним продактом. Продакт, если будет описывать задачу, зашьется. Дизайнер не всегда готов описывать. UX-человек, если есть отдельный UX-специалист или UX-дизайнер, то он, может быть, каких-то аспектов продуктовых не знает. То есть это всегда магия.

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

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

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

Сергей Кононенко: Команда собирается с продактом, закрываются в переговорке или в Zoom и смотрят, что нужно сделать, решают. Либо сразу понятно и договариваются между собой, либо кто-нибудь берет на себя задачку пойти поинвестигировать что-нибудь, с кем-нибудь поговорить, какую-то дополнительную информацию принести. Потом это в команде обсуждается. Если понятно, берем, делаем, если непонятно, смотрим, что нужно еще.

Алексей Рыбак: Спасибо, Сергей. Михаил, ты включал микрофон, видимо, хотел что-то ответить.

Михаил Юматов: У нас все опять же зависит от команды. Где-то, может быть, в наиболее сложной предметной области есть project-менеджер, который берет какую-то идею сырой от продакта и описывает уже более детально. И с этим детальным описанием уже выходит к команде разработки, где вся команда ревьюит это дело.

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

Как решаются вопросы безопасности

Алексей Рыбак: Следующий вопрос был Уже вопросы из Youtube пошли. Вопросы безопасности как решаются в ваших структурах? Я так полагаю, что так или иначе вопросы безопасности идут через платформенные команды. И они есть как в Mindbox, так и в Циане.

А есть ли платформенные команды все-таки у вас, Сергей? И вопросы безопасности каким макаром решаются? Потому что команда собралась и сама решила, как делать с точки зрения безопасности это не самый лучший set up.

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

Алексей Рыбак: У меня в связи с этим следующий вопрос. Во-первых, резюме. Достаточно мощная служба безопасности, автоматизация процесса деплоя таким образом, чтобы происходили почти все проверки автоматически.

Ревью. Означает ли это, что это какой-то процесс фоновый, или означает ли это, что каждый коммит должен пройти ревью безопасника?

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

Алексей Рыбак: Вы не практикуете забыл, как это называется у безопасников эмуляцию атаки, причем иногда вслепую, когда люди даже не предупреждены. Практикуете такие вещи?

Сергей Кононенко: Chaos Monkey?

Никита Прудников: Я думаю, скорее, пентест ты имеешь в виду.

Алексей Рыбак: Больше пентест, но нормальный пентест, когда никто не предупрежден.

Сергей Кононенко: Пентесты и BCP практикуем обязательно. Но совсем без предупреждений мы не можем, потому что банк работает 24/7. Вы, извините, приедете на заправку, а у нас пентест, и вы не сможете заплатить карточкой.

Алексей Рыбак: Почему пентест приведет к тому, что я не могу заплатить карточкой.

Сергей Кононенко: А мало ли, пенетрейшн удастся, и система упадет.

Алексей Рыбак: Ах, в этом смысле. Хорошо. Давайте дальше, про безопасность сообразили.

Как в горизонтальных компаниях шарятся ресурсы. Performance Review. Как техлиды оценивают разработчиков не из своего стека

Алексей Рыбак: Михаилу вопрос. Как вы шарите ресурсы между командами, если шарите?

Михаил Юматов: Ресурсы это люди, наверное? Если люди, то стараемся этого не делать. Вот такой ответ. Иногда такое бывает, но это ад и для команд, и для человека.

Алексей Рыбак: Использует ли кто-то таймшиты? Если нет, то почему? Я не знаю, что такое таймшиты. Видимо, какая-то диаграмма или какое-то расписание?

Михаил Юматов: Это, видимо, отчетность по времени, как я понимаю.

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

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

Практика заставлять людей писать, сколько времени они чем занимались, порочная. Мы стараемся этого не делать, конечно.

Алексей Рыбак: Кто-нибудь еще хочет ответить?

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

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

Алексей Рыбак: Хорошо. Ребята, еще быстрый вопрос всем. Просто давайте да или нет. Есть ли у вас performance review? Никита?

Никита Прудников: Все сложно. Что ты подразумеваешь под performance review?

Алексей Рыбак: Performance review это когда у тебя есть процесс, когда ты оцениваешь работу каждого человека в отдельности.

Никита Прудников: Если этот человек заводит карточку на повышение зарплаты, а это происходит автоматически, публично. В смысле, он же там пишет цели и то, чего он достиг.

Алексей Рыбак: Если он не завел эту карточку?

Никита Прудников: Если он работает как работает, в смысле нет вопросов с точки зрения стейкхолдера и других чуваков, то регулярного performance review нет. Если есть вопросики, тогда да, поехали. То есть on demand.

Алексей Рыбак: Сергей, как у вас?

Сергей Кононенко: Есть performance review команды. У команды есть performance-цели. И раз в год команда оценивается, и от этого зависит, получит команда бонус или не получит команда бонус.

Алексей Рыбак: Раз в год и всей командой?

Сергей Кононенко: Да.

Алексей Рыбак: Понял, спасибо. Как у вас, Михаил?

Михаил Юматов: Есть как оценка вовлеченности команды. Но это, скорее, больше про здоровье команды. И конкретного сотрудника тоже в том числе.

Алексей Рыбак: То есть у конкретного сотрудника есть performance review?

Михаил Юматов: Да.

Алексей Рыбак: Раз в какое время?

Михаил Юматов: Если говорить про какой-то общий процесс, то это может быть раз в полгода или год. Но на регулярной основе с лидом на one-to-one это постоянный процесс скорее.

Алексей Рыбак: Окей, то есть он такой Процесс performance review, если этот процесс, то у него есть определенный таймлайн, подготовка, заранее известные сроки, сколько раз в год. У кого-то один раз, у кого-то четыре раза. Хорошо, ладно.

Алексей Рыбак: Давайте двинемся дальше. Опять два вопроса Никите. Как техлиды оценивают технический уровень разработчиков не из своего стека?

Никита Прудников: У нас практически full stack. Просто из-за специфики компании У нас нет мобильной разработки, у нас очень ограниченный фронт, по сути, ограниченный облачной админкой нашего продукта. И очень много бэка. И большой проблемы с тем, что человек не разбирается в соседнем стеке, нет. Нам буквально только-только потребовались фронтенд-heavy истории. И в одной из команд появился выделенный фронтенд-лидер, который формулирует архитектуру фронта и все такое. И есть точка экспертизы и с точки зрения другого стека. Тут большой проблемы нет: ни в тех командах, где нет фронта, ни в той команде, где есть фронт. А с ним самим работаем совместно.

Алексей Рыбак: И следующий еще был вопрос, тоже, Никита, тебе. Про T-shape. В процессе работы компании возникает специалист с уникальным набором навыков. Как и надо ли это как-то выравнивать с рынком?

Никита Прудников: Если честно, я не совсем понял вопрос. В смысле, что он недооценен становится или в смысле, мы не понимаем, сколько ему платить? Давайте на какой-нибудь из этих вопросов отвечу.

Мне кажется, с этой точки зрения сильно помогают как раз открытые зарплаты. Просто из-за того, что мы не можем сформулировать суперформальные критерии, что такой человек с таким набором навыков стоит вот столько. Это случается органически, потому что этот человек работает в команде с другими людьми. И по сути вопрос в ценности. То есть насколько этот конкретный T-shaped ценен для команды и компании. Это и элайнится с зарплатой в итоге.

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

Сторипоинты. Системы премирования, мотивационные схемы. Перерасход людей

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

Никита Прудников: У нас нет сторипоинтов. У нас пулятся карточки одинакового размера.

Алексей Рыбак: То есть мы примерно посчитали, что это недельная задача или на несколько дней задача, и мы просто оценили, что в неделю таких карточек команда может взять не больше пяти.

Никита Прудников: Это уже команда внутри делает. Скрам-мастер изобретает любой удобный ему процесс с командой, как ему удобнее ставить себе совместно с PO на следующую каденцию. Но обычно они ориентируются: Мы прикинули, вот сколько карточек. Обычно мы столько делаем.

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

Алексей Рыбак: Михаил, Сергей, у вас есть сторипоинты?

Сергей Кононенко: Есть, работаем по классике. То есть команда, planning poker, все дела.

Алексей Рыбак: Какие есть варианты сторипоинтов? Сколько: 1 2, 1 5, 1 48?

Сергей Кононенко: Обычно это исправленное Фибоначчи, то есть: 1, 2, 3, 5, 8, 10, 20.

Алексей Рыбак: Мы когда-то давным-давно, более десяти лет назад, когда пробовали, степени двойки использовали. Короче, что-то тоже похожее.

Сергей Кононенко: Можно использовать все что угодно, главное, чтобы команде было комфортно квантифицировать свой got feeling сделаем или не сделаем, много или мало.

Алексей Рыбак: Понял. Что у вас, Михаил? Сторипоинты есть?

Михаил Юматов: Нет, у нас сторипоинтов нет, у нас часы обычные.

Алексей Рыбак: Окей, вопрос от Коли Крапивного. Что происходит, если при текущих приоритетах бизнеса какая-то команда оказывается перегружена, какая-то недогружена? Есть ли процесс ребалансировки? Если есть, то как часто за последний год менялись составы команд в связи с изменением нагрузки?

Сергей Кононенко: Мне, наверное, проще всего ответить. Никакой ребалансировки нет, потому что каждая команда отдельная структура, которая живет в своих реалиях.

Алексей Рыбак: Вопрос, мне кажется, задан больше в предположении, что какая-то есть в компании смесь между какая-то именно матрица, когда есть какая-то большая функциональная часть, у нее есть какие-то подчасти. Как-то побили, а потом оказалось, что побили неверно, потому что что-то куда-то навалилось. Если, с другой стороны, стримы продуктовые разбили изначально и достаточно жестко поделили, то кажется, что и такой ребалансировки быть не должно.

Алексей Рыбак: Следующий вопрос. Евгений Волк спрашивает. Как работают мотивационные схемы, система премирования, распределение премий между командами, внутри команд? Попробую по-другому задать вопрос. Тут получается так. Есть ли премии? Как часто? На команду или внутри команд? Сергей, давай с тебя начнем.

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

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

Второй подход такой, что у меня есть мой персональный план в зависимости от того, какой на меня фидбэк или еще что-то и какой у меня грейд, назовем это так. Это какая-то часть. И еще есть какая-то часть командная. Как у вас?

Сергей Кононенко: У нас есть определенный бюджет, который из всех переменных складывается. И он по определенным формулам раскидывается по командам. Внутри команд это история, связанная с грейдами.

Алексей Рыбак: Понял. Михаил, как у вас?

Михаил Юматов: У нас, кроме повышения в рамках роста между грейдами или внутри грейда, нет никаких премий.

Алексей Рыбак: А как у вас в Mindbox, Никита?

Никита Прудников: Профшаринг.

Алексей Рыбак: Не понимаю, разъясни, пожалуйста.

Никита Прудников: Часть прибыли компании распределяется среди команд. Там тоже формула непростая: частично мы учитываем выручку продуктов или иногда рост выручки, если мы понимаем.

Внутри команд обычно рулит стейкхолдер, именно распределением ПШ. В некоторых командах полная демократия, они голосуют и как-то договариваются. В командах, в которых я больше заказчик, я стараюсь выделить себе какую-то часть, которую я сам распределяю, и часть распределяет сама команда. С одной стороны, чтобы учесть усилия, за которыми я не уследил, с другой стороны, у демократии есть плохая специфика, что она размазывает все. Если возник какой-то outstanding performance, в смысле долгосрочной ответственности, то он недостаточно премируется. И на этот случай я себе кусочек отжимаю и напрямую конкретным людям отдаю в своих командах.

Алексей Рыбак: Понятно. Тогда еще один вопрос от меня, важный, который не затронули. Смотрите, а перерасход людей? Это больше вопрос, наверное, Никита, к менее гетерогенным командам, когда много: мобильщики такие, сякие, фронт, бэк. Начинаешь компоновать микрокоманды вокруг продукта, и оказывается, что если ты вокруг каждого продукта, а не семейства продуктов собрал команду, то получается, что обязательно там должны быть тестировщики, обязательно такие роли, сякие.

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

Запускаем новый продукт и говорим: Ладно, мы продуктовая компания, нам нужна микрокоманда вокруг этого продукта. Кто нам для нее нужен? Очевидно, нам нужен тот человек, который будет делать фронт. Если мы делаем при этом какое-то мобильное приложение, значит, нам нужен и iOS, и Android. Нам нужен бэк, обязательно нам нужен QA, QA на все. Одного QA на такое количество людей мало. Ой, bus factor, давай по два. Ой, раз два, давай еще добавим QA. В результате команда разрастается.

Сталкивались ли с подобными вещами при планировании структуры? Как это решали? Наверное, в первую очередь вопрос, Сергей, к вам.

Сергей Кононенко: Мы стараемся нанимать людей широкого спектра. То есть, если QA, хорошо бы, чтобы он умел программировать и писать автотесты, помогал разработчикам. Если разработчик, то а как же он не будет писать автотесты? Если он бэкендер, а давайте он будет еще и на фронте уметь писать. Таким образом мы контролируем безразмерные разрастания команды.

Алексей Рыбак: Но все-таки

Никита Прудников: Я, кстати, соглашусь, у нас похожая история. В смысле, мы стараемся

Алексей Рыбак: Но iOS разработка и бэкенд совсем разные.

Сергей Кононенко: Да-да-да, все правильно, поэтому у нас команды, которые прямо совсем full stack, допустим R-Mobile какой-нибудь, банковское приложение клиентское, там, пожалуйста и Java, и Scala, и Kotlin, и iOS, и базы данных, и DB2 чего там только нет. Но в момент один собирается по одному одному человеку из каждой экспертизы. А до конца года у них цель, чтобы каждый освоил еще две экспертизы.

Алексей Рыбак: Понятно. Михаил, что-нибудь можете добавить?

Михаил Юматов: Я немножко прослушал сам вопрос. Цель собрать команду, подсосать откуда или что?

Алексей Рыбак: Нет. Когда мы делаем новые направления, бывают команды, которые выпускают консюмерные продукты не в каком-то стриме большом, а например, игры делает или какие-то социальные приложения. Делают какие-то небольшие кусочки, эксперименты. И, когда запускается программа, команда, у которой есть мобильная история, веб-история, то у тебя появляется сразу же определенное количество мобильщиков, фронтендеров, QA. И команда сразу становится достаточно большой. Хотя кажется, что для того, чтобы выполнить такой проект, его можно было бы подмешать к какой-то другой команде, более большой, или нужно было бы выделять целую отдельную команду?

Михаил Юматов: Мы не очень верим в идею подсосать этот проект куда-то в другое направление, у которого свои фокусы и свои цели. Скорее всего, это будет действительно отдельная команда, которую мы соберем просто из существующих ребят. Может быть, на такой период для того, чтобы сделать и разойтись. Либо, если долгосрочные перспективы, то, скорее всего, это будет полноценная команда навсегда.

Да, действительно есть проблемы с тем, что, условно, разработчик iOS, он умеет только iOS. Есть у нас и мы поощряем это ребята, которые развиваются из С# во фронт, с фронта в Python, с Python в C#, и так далее. Но это, наверное, такие кандидаты, которых нужно как раз рассматривать для того, чтобы не раздувать ее.

Алексей Рыбак: Георгий снова тянет руку. Георгий, еще раз вас включу, и, наверное, это будет последний вопрос.

Георгий: Да, у меня есть еще два небольших вопроса. Первое насколько, как у CTO в организациях, ваши возможности ограничены? Что вы можете сделать, что нет? Какие-то есть у вас ограничения или нет?

И второй вопрос про команды. Есть у вас удаленные команды? Вы нанимаете только русскоговорящих или у вас есть иностранцы? Есть ли какие-то ограничения с этой стороны?

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

А про удаленные команды у нас сейчас нет. Нет опыта, и нет команд удаленных, вся локация в офисе.

Михаил Юматов: Про ограничения мне довольно сложно ответить. Тут, мне кажется, любое решение это будет, скорее всего, результат какого-то обсуждения, навряд ли я буду какие-то истории единолично принимать, но я не CTO.

Если говорить про удаленку, то мы нанимаем ребят со всей России. И планируем продолжить после локдауна и коронавируса оставаться на удаленке, мы и до этого так были.

Алексей Рыбак: Русскоговорящая?

Михаил Юматов: Да.

Алексей Рыбак: Окей, мультиязычных команд нет. Ещё быстрый вопрос. Ребята, когда последний раз писали код? Из YouTube вопрос.

Никита Прудников: Вчера.

Михаил Юматов: Сегодня. Но я должен оговориться, что это просто какие-то автоматизации своих

Алексей Рыбак: Понятно. Хорошо, ребята вышли уже даже за время, два часа пролетели. Спасибо вам огромное за эту встречу. Постарались ответить на все вопросы.

Еще раз спасибо огромное всем, кто поучаствовал, гостям. Тема нашего митапа была Управление разработкой в горизонтальных компаниях. Сегодня у нас в гостях были Никита Прудников из Mindbox, Михаил Юматов из Циан и Сергей Кононенко из Раффайзенбанка. Спасибо вам большое.


Если у вас остались вопросы, то можете задать их прямо под этим постом.

У нашего сообщества есть Фейсбук-группа Управление и разработка крупных IT-проектов и канал @feedmeto с интересными публикациями из корпоративных (преимущественно забугорных) техноблогов, и канал автора @rybakalexey про управление разработкой в продуктовых компаниях.

Подробнее..

Из песочницы 17 хороших и 4 плохих способа ускорения проекта

22.11.2020 00:21:34 | Автор: admin

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


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


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


Рассмотренные меры ускорения проектов являются дополнением к другим важным аспектам ведения ИТ-проектов, таким как качество сбора и анализа требований, качество выработанного решения, качество производства кода и т.п.


Модель влияния параметров проекта на его длительность рассматривается в отношении среднестатистического ИТ-проекта, который характеризуется следующими параметрами:


  • длительность от 6 мес.;

  • количество участников проектной команды от 7-8 чел. со средним уровнем задействования в проекте 50% (участники команды проекта могут быть задействованы в других конкурирующих активностях);

  • количество участников проекта со стороны заказчика от 2-3 чел.;

  • проект предполагает некоторую гибкость содержания (например, возможность корректировки приоритетов и сроков реализации функций или возможность изменения детальных требований к функциям).


Качественная модель влияния параметров проекта на его длительность может быть представлена следующим образом:


,


где


T длительность проекта;


S содержание (scope) проекта, объем реализуемых функций (фичей) и выполняемых работ;


L потери различного рода, которые могут быть выявлены и устранены;


C сложность реализуемого решения, сложность решаемых в проекте задач;


W объем человеческих ресурсов, задействованных в проекте;


E персональная эффективность участников проекта;


O оптимальность реализуемого плана с точки зрения приближенности к объективному критическому пути.


Модель указывает на то, что для ускорения проекта (уменьшения длительности проекта T), необходимо стремиться уменьшать S (содержание), L (потери в процессе), C (сложность решения) и увеличивать W (объем человеческих ресурсов), E (эффективность участников проекта), O (оптимальность плана работ).


В качестве практических мер влияния на параметры проекта можно рассматривать следующие:


Наименование меры


Описание


Степень влияния


Условия применения


Возможные последствия


S (содержание)


S.1. Отказаться от бесполезных задач


Пересмотреть целесообразность и приоритет задач проекта, исключить задачи низкой или сомнительной полезности


высокая


Адекватность заказчика, адекватное экспертное мнение


Снижение бюджета проекта


S.2. Делать наиболее важные задачи в начале проекта


Пересмотреть целесообразность и приоритет задач проекта, перенести на будущее задачи низкой или сомнительной полезности


высокая


Адекватность заказчика, адекватное экспертное мнение


S.3. Пересмотреть решение


Пересмотреть подход к решению проблемы в проекте, выбрать более простое, дешевое, костыльное решение


высокая


Наличие приемлемых альтернативных решений


Снижение качества результатов проекта.



Необходимость переработки некоторых готовых результатов


L (потери в процессе)


L.1. Исключить задержки в коммуникациях


Своевременно и четко доносить до команды необходимую информацию (в том числе, через актуальные планы, роадмапы и т.п.).


Обеспечить эффективные процессы обмена информацией между участниками команды.


высокая


Наличие управленческих и организаторских компетенций и ресурса


L.2. Сократить задержки принятия решений заказчиком за счет наличия компетентного представителя


Обеспечить на стороне заказчика наличие компетентных лиц, принимающих решения (ЛПР), имеющих необходимые ресурсы для участия в проекте


средняя


Наличие адекватных ЛПР, готовых принимать участие в проекте.


Возможность влиять на состав участников проекта со стороны заказчика


L.3. Сократить задержки принятия решений заказчиком за счет уменьшения количества ЛПР


Снизить количество ЛПР на стороне заказчика


средняя


Возможность влиять на состав участников проекта со стороны заказчика


Пропуск важных требований.


Принятие и реализация конфликтующих решений


L.4. Сократить задержки принятия решений заказчиком за счет сегментирования заинтересованных стороны


Декомпозировать содержание проекта на условно независимые части, в рамках которых меньше группы ЛПР (2-3 чел.).


высокая


Пропуск важных требований.


Принятие и реализация конфликтующих решений


L.5. Отказаться от лишних документов и операций в рабочем процессе проекта


Отказаться от лишних документов, разделов документов.


Отказаться от лишних согласований, согласующих.


Отказаться от лишних операций в процессе производства продукта проекта


высокая


Наличие лишних операций, отсутствие которых не приведем к недопустимому снижению качества результатов проекта или смежных активностей


Снижение качества результатов проекта.


Проблемы внедрения изменений в рабочий процесс


L.6. Снизить фрагментацию задействования участников в проекте


Повысить долю участия в проекте ключевых членов команды (>>50%).


высокая


Наличие ресурсной возможности


L.7. Выбрать адекватную схему ведения проекта


Пересмотреть процесс ведения проекта на предмет изменения подхода (водопад FixPrice-> набегающая волна Time & Material -> agile и т.п.)


высокая


Наличие подходящих альтернативных технологий.


Наличие компетенций для альтернативных технологий


Дополнительные затраты на изменение схемы ведения проекта.


Дополнительные затраты на привлечение экспертов-консультантов.


Срыв сроков поставки некоторых результатов проекта.


L.8. Устранить токсичных и неэффективных участников проекта


Выявить и заменить или исключить из проекта токсичных и неэффективных участников (в том числе, со стороны заказчика)


высокая


Наличие замены.


Техническая возможность продолжать работу без токсичного участника


Срыв сроков поставки некоторых результатов на периоде перестройки команды


C (сложность решения)


C.1. = S.3 Пересмотреть решение


Пересмотреть подход к решению проблемы в проекте, выбрать более простое, дешевое, костыльное решение


высокая


Наличие приемлемых альтернатив-


ных решений


Снижение качества результатов проекта.


Необходимость переработки некоторых готовых результатов


C.2. Пересмотреть технологии


Пересмотреть применяемые технологии и подходы в пользу более простых (отказаться от новых сложных технологий в пользу старых освоенных технологий)


средняя


Наличие альтернативных простых технологий


Необходимость переработки некоторых готовых результатов.


Снижение технологичности, качества, современности результатов проекта


C.3. Перераспределить задачи между участниками по сложности и компетенциям


Передать сложные операции (части операций) и задачи (части задач) опытным и компетентным участникам проекта.


Передать рутинные операции (части операций) и задачи (части задач) менее опытным участникам.


высокая


Наличие процессного потенциала для перераспределения задач


Дополнительные затраты на координацию частей операций и задач.


Демотивация менее опытных участников проекта


W (объем человеческих ресурсов)


W.1. Добавить новых участников в проект


Увеличить объем человеческих ресурсов по направлениям с нехваткой ресурсов


средняя


Наличие дополнительных ресурсов.


Потенциал увеличения числа участников с точки зрения сохранения управляемости.


Наличие запаса времени на погружение в процесс новых участников


Дополнительные затраты на погружение в процесс новых участников.


Дополнительные затраты на управление большим числом участников проекта.


Дополнительные затраты на коммуникации большего числа участников проекта


W.2. = L.6. Снизить фрагментацию задействования участников в проекте


Повысить долю участия в проекте ключевых членов команды (>>50%).


высокая


Наличие ресурсной возможности


W.3. Увеличить объем ресурсов за счет сверхурочной оплачиваемой работы


Договориться с участниками проекта о выполнении части работ сверхурочно


средняя


Наличие бюджета на оплату сверхурочной работы.


Согласие сотрудников


Дополнительные затраты бюджета.


Перегруз сотрудников с возможным снижением эффективности и качества работы


W.4. Увеличить объем ресурсов за счет сверхурочной не оплачиваемой работы


Договориться с сотрудниками на сверхурочную бесплатную работу.


Заставить (путем давления, манипуляций) сотрудников работать сверхурочно без оплаты.


средняя


Административный ресурс, готовность сотрудников на сверхурочную работу


Снижение лояльности участников проекта, риски увольнения.


Перегруз сотрудников с возможным снижением эффективности и качества работы


E (эффективность участников проекта)


E.1. Привлечь высококвалифицированного эксперта/коуча


Включить в состав команды проекта высококвалифицированного специалиста (коуча) для помощи участникам проекта в улучшении своей работы


средняя


Наличие ресурса на привлечение дополнительного участника.


Наличие потенциала улучшения процесса.


Готовность и лояльность команды к участию эксперта в проекте


Дополнительные затраты на привлечение специалиста (возможно, не оправданные).


Демотивация участников команды, конфликты.


Дополнительные затраты на перестройку процесса


E.2. = L.8. Устранить токсичных и неэффективных участников проекта


Выявить и заменить или исключить из проекта токсичных и неэффективных участников (в том числе, со стороны заказчика)


высокая


Наличие замены.


Техническая возможность продолжать работу без токсичного участника


Срыв сроков поставки некоторых результатов на периоде перестройки команды


E.3. Повысить эффективность команды за счет обучения


Создать условия для улучшения индивидуальной работы участников проекта путем обучения (прокачки)


средняя


Наличие времени и ресурсов на обучение.


Наличие экспертов или учебных материалов


Дополнительные затраты на обучение (возможно, не оправданные).


Возможные срывы сроков поставки некоторых результатов работы из-за отвлечения на обучение


E.4. Повысить эффективность команды за счет мотивации


Мотивировать участников проекта к повышению личной эффективности (самообучению и прокачке в личное время).


Мотивировать участников проекта к повышенной трате жизненных сил на проекте (путем материальной и нематериальной мотивации)


средняя


Наличие потенциала развития у участников проекта.


Наличие потенциала скрытых жизненных сил у участников проекта.


Наличие ресурсов на материальную мотивацию


Дополнительные затраты на материальную мотивацию (возможно, не оправданные).


Дополнительные ресурсы на нематериальную мотивацию


E.5. Повысить эффективность команды за счет давления


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


средняя


Наличие потенциала скрытых жизненных сил у участников проекта


Снижение лояльности участников проекта, риски увольнения.


Перегруз сотрудников с возможным снижением эффективности и качества работы


O (оптимальность плана работ)


O.1. Обеспечить оптимальность плана (роадмапа)


Постоянно анализировать план проекта на предмет потенциала оптимизации (приближения к объективному критическому пути).


Снижать зависимость и блокировки работ. Увеличивать количество параллельно выполняемых работ


высокая


Наличие ресурсных возможностей для корректировки плана работ


Дополнительные затраты на анализ плана, перепланирование и организацию изменений





Предложенная модель позволяет добавлять параметры и уточнять перечень мер ускорения проектов с учетом специфики организации и конкретного проекта.


Практика применения указанных мер ускорения проектов позволяет условно разделить их на хорошие и плохие. Хорошие меры (субъективно) можно приоритезировать в части последовательности их рассмотрения и проработки в проекте следующим образом (в порядке уменьшения эффекта):


  1. S.1. Отказаться от бесполезных задач

  2. S.2. Делать наиболее важные задачи в начале проекта

  3. L.1. Исключить задержки в коммуникациях

  4. S.3. Пересмотреть решение

  5. L.8. Устранить токсичных и неэффективных участников проекта

  6. L.2. Сократить задержки принятия решений заказчиком за счет наличия компетентного представителя

  7. L.3. Сократить задержки принятия решений заказчиком за счет уменьшения количества ЛПР

  8. L.4. Сократить задержки принятия решений заказчиком за счет сегментирования заинтересованных стороны

  9. L.5. Отказаться от лишних документов и операций в рабочем процессе проекта

  10. O.1. Обеспечить оптимальность плана (роадмапа)

  11. L.6. Снизить фрагментацию задействования участников в проекте

  12. L.7. Выбрать адекватную схему ведения проекта

  13. C.2. Пересмотреть технологии

  14. W.1. Добавить новых участников в проект

  15. C.3. Перераспределить задачи между участниками по сложности и компетенциям

  16. W.3. Увеличить объем ресурсов за счет сверхурочной оплачиваемой работы

  17. E.1. Привлечь высококвалифицированного эксперта/коуча

Подробнее..

Как я научился получать удовольствие от pet-проектов

01.12.2020 00:06:56 | Автор: admin

Скрин последнего pet-проекта

Термин pet-проект каждый трактует для себя по-своему, сам я его объясняю следующим образом: разработка, отличная от работы.

Классификаций pet-проектов тоже предостаточно. Я определил для себя следующие:

  • краткосрочные/долгосрочные
  • коммерческие/некоммерческие

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

Понятно, что две эти классификации можно и нужно между собой комбинировать: краткосрочные & коммерческие, долгосрочные & некоммерческие и т.д.

В жизни, я сталкивался со всеми из перечисленных типов pet-проектов. В основном, это как раз таки краткосрочные & некоммерческие как самые простые в плане реализации и затраченного времени. Как правило, это проекты направленные на изучение того или иного модуля, технологии, подхода, алгоритма и т.д. Тут все просто: быстро сделал, быстро порадовался. Можно использовать на боевом проекте для решения реальных задач. В общем, все тоже самое, за что я люблю хакатоны (надо уже наконец собраться и написать статью про хакатоны).

Но были конечно и долгосрочные проекты (об одном из них я уже писал пост) и вот с ними то у меня большие проблемы, а именно с мотивацией. Помимо того, что вы до конца не уверены, что проект окупится(если речь конечно идет про коммерцию), так и сам проект превращается в рутинную вторую работу: все те же таски, бэклог, приоритеты и т.д. Не знаю, как на других, но на меня это очень сильно давит. Хоть я лично и встречал людей, которые делают свои pet-проекты в одиночку по 6 лет, свои долгосрочные проекты я либо сразу забрасывал, либо даже не начинал делать, зная чем это закончится. Исключением из правил для меня являются проекты, в кооперативе с кем-то: так и интереснее и процесс быстрее идет, да и ответственность как никак появляется не только перед собой.

Проблему поставили: как начать и не забросить разработку долгосрочного некоммерческого pet-проекта в одиночку?

В моем случае, мне помогли 2 вещи, которые мне посоветовали 2 товарища:

  1. книга Вы, конечно, шутите, мистер Фейнман!
  2. спонтанное планирование

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

Спонтанное планирование, как и pet-проект, тоже каждый определяет для себя по-разному, для себя я охарактеризовал это следующим образом: делай то, что нравится. Т.е. при таком подходе я сохранил бэклог, но избавился от приоритезации задач: настроение сегодня реализовать расширение для редактора, а не пилить основную игровую механику пожалуйста, нет сил напрягать мозги можно заняться подготовкой иконок к релизу под различные экраны, бессонница иди разбираться, как накатить новейший Xcode на MacBook 8-летней давности, а заодно и почистить его и т.д.

Понятно, что я не открыл Америку и такой подход вряд ли можно заюзать на работе (хотя я где-то слышал, что Valve так когда-то делали), но в рамках долгосрочного одиночного некоммерческого pet-проекта почему бы и нет?

Мне эти 2 кейса сильно помогли: я зарелизил продукт, который в одиночку делал 3 месяца. Да, не слишком долго, но начало положено и останавливаться пока не собираюсь.

Надеюсь, моя история будет кому-нибудь полезна, поможет и замотивирует на создание собственного pet-проекта.

Делитесь своими историями и методами которые помогли именно вам сдвинутся с мертвой точки.
Подробнее..

Корпоративные опросы всех бесят, но я знаю, как это исправить

01.12.2020 18:05:13 | Автор: admin


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

Такая проблема обычно возникает, потому что опросы присылают на почту, которую проверяют в лучшем случае раз в день. Результаты приходят через несколько недель и часто представляют из себя скучную числовую оценку по шкале.

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

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

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

Откажитесь от почты


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

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

Просите команду пройти опрос лично и тогда, когда для этого созданы подходящие условия. Если вы обычная Agile-команда, у вас наверняка есть ретроспективы, когда все анализируют результаты спринта. Это идеальное место, чтобы провести опрос о настроении. Выделите для него пару минут и пришлите ссылку в чатик, либо расшарьте экран с QR-кодом.

Правильно задавайте вопросы


Задавайте не больше шести вопросов только самое важное. Если переборщите с количеством, это перестанет быть увлекательно и всем будет тупо лень, а ответы если и будут, то очень поверхностные. Если спросите слишком мало, то не покроете важные темы. Подумайте, что вам важно: продуктивность, переработки, удовольствие?

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

Скомкано Развёрнуто
Тревожился? Как часто ты испытывал тревогу за задачи или проект?
Как тебе задачи? Ты получал удовольствие от задач?
Устал? Как часто ты чувствовал, что у тебя не осталось сил выполнять задачи?

Вопросы можно изменять ситуативно: однажды мы отказались от всех встреч и сразу узнали мнение через опрос.

Вот список вопросов, которые я задаю команде:

Как часто ты чувствовал, что у тебя закончились силы выполнять задачи?

  • Ни разу
  • Один раз в неделю
  • Два-три раза в неделю
  • Почти всю неделю

Ты получал удовольствие от задач?

  • Да
  • Скорее да
  • Задачи как задачи
  • Скорее нет
  • Нет

Как часто ты испытывал тревогу за задачи или проект?

  • Ни разу
  • Один раз
  • Два-три раза в неделю
  • Почти всю неделю

Сколько часов ты переработал? (сумма за неделю)

  • 0
  • До 2х
  • От 2х до 4х
  • От 4х до 8ми
  • От 8ми до 12ти
  • Более 12ти

Тебе понравился спринт?

  • Лучший спринт
  • Хороший спринт
  • Норм
  • Ну такое
  • Это провал


Одно время вместо вариантов ответов я просил дать оценку от 0 до 10, но это абсолютно плохая идея, не делайте так. Оценка цифрой очень относительна, ведь человек, который привык овертаймить, поставит от 4 до 7 баллов за тот же набор задач, за который обычный сотрудник смело ставит больше 8. Но ещё сложнее сделать выводы и обсуждать средние значения из таких данных.

Проанализируйте ответы


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





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




Бонус. Личная динамика


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



Розовый это тот самый флажок, который нужно обсудить на личной встрече с тимлидом.
Бывает, что вроде всё ок, работа работой, а по графикам у тебя второй месяц растёт усталость и падает удовольствие от задач. Чтобы не допустить выгорания, переутомления или потери интереса, нужно следить за трендами и обсуждать проблемы, пока они свежие.



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

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

Пишите, что думаете, какие вопросы вы бы добавили, ставьте плюсы и шэрьте эту статью авторам ваших корпоративных опросов.
Подробнее..

Перевод Мы всё переписали на HOTLANG, но стартап всё равно провалился

02.12.2020 20:12:10 | Автор: admin
Сегодня завершается наше невероятное путешествие. Но не всё так плохо. После нашего стартапа осталась отличное технологическое наследие и команда, готовая к следующему вызову. По хорошей стартаперской традиции, я публикую этот отчёт, дабы остальные могли научиться на наших ошибках.

Начало


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

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

Получив достаточное финансирование, мы приступили к работе. Найм персонала фундаментальная часть успеха. Поэтому мы установили высокую планку: на собеседования приглашали только разработчиков с популярными опенсорсными проектами. Главная метрика количество звёзд на GitHub работала замечательно.

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

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

Но на этом мы не остановились. Мы переписали наши микросервисы с Node на Go, потом на C++, а затем обратно на Node. На каждом этапе мы наблюдали 20-процентное улучшение производительности. Просто дух захватывало, на что способна наша команда.

Мы отложили запуск на два месяца, чтобы довести до совершенства систему сборки. Теперь мы использовали Github Actions, конвейеры Bitbucket, GitLab CI и кластер AWS на инстансах Jenkins. Мы разработали собственную распределённую систему управления, чтобы всё идеально скоординировать. Сама система управления базировалась на той же инфраструктуре, что и сборка. Это было поистине волшебно.

Технические задачи были невероятные, но команда справилась с задачей. За несколько недель до старта мы поднажали. Все работали по 10 часов в день без выходных, пока не довели систему до ума. Итак, день запуска.

Признаки проблемы


Мы открыли все шлюзы. Опубликовали ссылку в Twitter и Instagram, разместили на HN, написали статью на Medium. Но как ни старались, ни один пользователь так и не зарегистрировался.

Настроение было подавленным большой запуск, над которым мы так упорно работали, так и не состоялся. Экстренные совещания. Трудные разговоры. И было принято решение.

Нам пришлось всё переписать на $HOTLANG.

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

Ещё пару месяцев работы по 12 часов в день, и мы закончили. Все знали, что это наш последний шанс. Это наш момент славы.

Мы запустили вторую версию с большими фанфарами. Шумная кампания в социальных сетях, прямые трансляции, платное спонсорство. Мы бросили на раскрутку все имеющиеся ресурсы.

Но этого оказалось недостаточно. Зарегистрировалось несколько пользователей из числа друзей и родственников, но клиентов не было. Для нас игра закончилась. Мы вернули инвесторам то немногое, что у нас осталось, и начали сворачивать лавочку.

Извлечённые уроки


Со времени этих роковых событий прошло несколько месяцев. Теперь мы знаем, в чём была критическая ошибка. Дело в том, что идеальный технический стек не остаётся таким долго. К тому времени, как вы выйдете на рынок, идеальный стек изменится а вместе с ним и ваши шансы на успех!

Мы просто опоздали с выходом. К моменту запуска второй версии $HOTLANG уже вышел из моды. Если найти дополнительное финансирование, то мы перепишем приложение на $ELITELANG. И вот тогда наш стартап может стать единорогом.
Подробнее..

Перевод Мы переписали всё на КРУТОЙЯЗК, но стартап всё равно не взлетел

26.11.2020 12:17:06 | Автор: admin
Сегодня наше невероятное приключение подходит к концу. Но всё было не напрасно. Мы оставим после себя наследие в виде превосходных технологических решений и команды, которая готова к следующему вызову. Следуя славной традиции стартапов, я решил написать эту статью, чтобы другие разработчики смогли сделать выводы из наших ошибок.

Начало


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

Мы вели дискуссии с сотнями разработчиков, занятых в индустрии, анализировали тренды, читали Hacker News как одержимые, пока наконец не определили идеальный стек для своего стартапа. Сказать, что мы серьёзно подошли к сбору информации это ничего не сказать.

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

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

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

Но мы не собирались останавливаться на достигнутом. Мы переписали микросервисы, изначально созданные на Node, на Go, затем на C++, а потом обратно на Node. На каждом этапе производительность улучшалась на 20%. Возможности нашей команды просто потрясали!

Мы отложили релиз на два месяца, чтобы довести до совершенства систему сборки. В окончательной версии использовались Github Actions, Bitbucket Pipelines, Gitlab CI и кластер инстансов Jenkins, размещённых на AWS. Мы своими руками сделали распределённую систему управления во избежание малейших сбоев в координации. Деплой этой системы проводился при помощи всё той же инфраструктуры сборки. Просто магия какая-то.

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

Собираются тучи


Мы подняли занавес: объявили о релизе на Твиттере и в Инстаграме, разместили новость на Hacker News, написали статью на Medium. Но, как мы ни старались, пользователи не шли.

Команда упала духом ведь мы столько труда вложили в триумфальный дебют, а он сорвался. После серии срочных сборов с невесёлыми обсуждениями было принято решение. Мы должны переписать всё на $КРУТОЙЯЗК.

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

Спустя пару месяцев работы по двенадцатичасовым сменам мы завершили процесс. Все понимали: этот шанс будет для нас последним. Пришло время показать миру, на что мы способны.

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

Этого оказалось недостаточно. Кто-то из родственников и друзей купил продукт, но других пользователей так и не появилось. Песенка для нас была спета. Мы вернули те немногие деньги, которые ещё оставались, инвесторам и стали сворачивать дела.

Чему мы научились


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

Мы просто не сумели угнаться за темпами развития рынка. $КРУТОЙЯЗК уже стал клониться к закату, когда подоспела вторая итерация нашего продукта. Если бы нам удалось привлечь больше инвестиций, мы бы не стали торопиться и переписали приложение сразу на $ЭЛИТНЙЯЗК. Наш стартап мог бы стать единорогом.
Подробнее..

75 лекций на русском от Y Combinator (из 172)

26.11.2020 20:11:58 | Автор: admin
image


Патрик и Джон Коллинсон, основатели Stripe (в 22 года и в 21 год), с капитализацией $35 млрд.

Y Combinator лучший в мире акселератор для стартапов по количеству единорогов (21), по объему привлеченных инвестиций ($27 млрд) и по капитализации выпускников ($155 млрд). Важно отметить еще то, что среди выпускников YC было несколько основателей моложе 18 лет (и один 20-летний из России).

А ещё Y Combinator выкладывает все свои учебные материалы бесплатно, уже более 10 лет.

Основатели и техдиры миллиардных стартапов Amazon ($1.55 трлн), Facebook ($720 млрд), PayPal ($127 млрд), AirBnb ($40 млрд), Pinterest ($38 млрд), Stripe ($35 млрд), LinkedIn ($26.2 млрд), Slack ($23 млрд), WatsApp ($19 млрд), Doordash ($16 млрд), Twitch ($15 млрд), Netscape ($10 млрд), Sun Microsystems ($7.4 млрд), Zenefits ($4 млрд), Segment ($4 млрд), Box ($2.76 млрд), Quora ($2 млрд), Asana ($1.5 млрд), Zappos ($1.2 млрд), Docker ($1.2 млрд), Pebble, Jawbone, Opsware, Weebly, Yahoo!Mail, Gmail, Mixpanel, Scribd и пр, а так же основатели венчурных фондов Andreessen Horowitz, Cowboy Ventures делятся своим опытом со всем миром. Это контент невероятного качества для тех, кто хочет играть в высшей лиге, на международном уровне.

Сейчас у Y Combinator 172 видео-лекции в плейлистах: 2012, 2013, 2014 NY, 2014 Europe, 2014 SV, How to Start a Startup (2014 Lectures), 2016, 2017, 2018, Startup Investor School 2018, 2019, 2020. Ниже приедены переводы, субтитры и транскрипты 75 из них.

YC Startup Library на русском


В 2020 году YC выложил в публичный доступ все самые важные наработки за 15 лет, опыт работы более чем с 2000 стартапов, рефлексию, интервью, советы, руководства.

На русском языке время от времени появлялись переводы нескольких текстов, корпоративные и волонтерские переводы/озвучка/субтитры/транскрипты лекций Startup School. Пришло время систематизировать все материалы и доперевести недостающие.

Все новости систематизации и русификации библиотеки в телеграм и в фейсбуке.

Английский Язык


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

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

Положение дел со стартапами в России


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

2014 How to Start a Startup (Stanford)


Lecture 1 How to Start a Startup (Sam Altman, Dustin Moskovitz)/ Как начинать стартап


image

Спикеры Сэм Альтман (основатель Loopt) и Дастин Московиц (сооснователь Facebook).



Lecture 2 Team and Execution (Sam Altman) / Команда и Исполнительность (Сэм Альтман)


image

Спикер Сэм Альтман (основатель Loopt).



Lecture 3 Before the Startup (Paul Graham) / Перед стартапом (Пол Грэм)


image

Спикер Пол Грэм (основатель Y Combinator).



Lecture 4 Building Product, Talking to Users, and Growing (Adora Cheung) / Созлание продукта, разговоры с пользователями, рост (Адора Ченг)


image

Спикер Адора Ченг (партнер YC).



Lecture 5 Competition is for Losers (Peter Thiel) / Конкуренция удел неудачников (Питер Тиль)


image

Спикер Питер Тиль (основатель PayPal, первый инвестор Facebook).



Lecture 6 Growth (Alex Schultz) / Рост (Алекс Шульц)


image

Спикер Алекс Шульц (директор по росту в Facebook).


Lecture 7 How to Build Products Users Love (Kevin Hale) / Как создавать продукт, который полюбят пользователи (Кевин Хейл)


image

Спикер Кевин Хейл (основатель WuFoo).



Lecture 8 How to Get Started, Doing Things that Don't Scale, Press /


image

Спикеры Стэнли Танг (основатель Doordash), Волкер Вильямс (основатель Teespring), Джастин Кан (основатель Twitch).



Lecture 9 How to Raise Money (Marc Andreessen, Ron Conway, Parker Conrad) / Как привлекать инвестиции (Марк Андриессен, Рон Конвей, Паркер Конрад)


image

Спикеры Марк Андриессен (создатель Netscape и основатель инвест-фонда Andreessen Horowitz), Рон Конвей (топовый инвестор Долины), Паркер Конрад (основатель Zenefits).



Lecture 10 Culture (Brian Chesky, Alfred Lin) / Культура (Брайан Чески, Альфред Лин)


image

Спикеры Брайан Чески (основатель AirBnb), Альфред Лин (CEO Zappos, партнер Sequoia Capital).



Lecture 11 Hiring and Culture, Part 2 (Patrick and John Collison, Ben Silbermann) / Найм и Культура


image

Спикеры Патрик Коллисон (основатель Stripe) и Джон Коллисон (основатель Stripe), Бен Сильберман (основатель Pinterest).


Lecture 12 Building for the Enterprise (Aaron Levie) / Разработка B2B-продуктов


image

Спикер Аарон Леви (основатель Box).



Lecture 13 How to be a Great Founder (Reid Hoffman) / Как стать великим основателем (Рейд Хоффман)


image

Спикер Рейд Хоффман (основатель LinkedIn).



Lecture 14 How to Operate (Keith Rabois) / Как заниматься операционной деятельностью


image

Спикер Кит Рабуа (член PayPal-мафии, инвестор PayPal, LinkedIn, Slide, Square, Yelp, Xoom, партнер в Founders Fund).



Lecture 15 How to Manage (Ben Horowitz) / Менеджмент (Бен Хоровиц)


image

Спикер Бен Хоровиц (основатель Opsware и основатель инвест-фонда Andreessen Horowitz).



Lecture 16 How to Run a User Interview (Emmett Shear) / Как проводить интервью с пользователями (Эммет Шир)


image

Спикер Эммет Шир (соонователь и CEO Twitch).



Lecture 17 How to Design Hardware Products (Hosain Rahman) / Как разрабатывать Hardware продукты (Хосейн Рахман)


image

Спикер Хосейн Рахман (основатель и CEO Jawbone).



Lecture 18 Legal and Accounting Basics for Startups (Kirsty Nathoo, Carolynn Levy) / Юридические и финансовые вопросы (Кирсти Нату, Кэролайн Леви)


image

Спикеры Кирсти Нату (Partner, CFO at Y Combinator), Кэролайн Леви (Managing Director, Legal and People Ops).



Lecture 19 Sales and Marketing; How to Talk to Investors (Tyler Bosmeny; YC Partners) / Продажи и маркетинг; Переговоры с инвестором (Тайлер Босмени и компания)


image

Спикер Тайлер Босмени (основатель и CEO Clever).



Lecture 20 Later-stage Advice (Sam Altman) / советы стартапам на поздних стадиях (Сэм Альтман)


image

Спикер Сэм Альтман (основатель Loopt).



2017


1. How and Why to Start A Startup (Sam Altman & Dustin Moskovitz) /Как и почему запускать стартап (Сэм Альтман и Дастин Московиц)


image

Спикеры Дастин Московиц (cооснователь Facebook и сооснователь Asana) Сэм Альтман (основатель Loopt).



2. Startup Mechanics (Kirsty Nathoo) / Финансовая механика стартапов


image

Спикер Кирсти Нату (партнер и финансовый директор YC).



3. How to Get Ideas and How to Measure (Stewart Butterfield, founder and CEO of Slack, and Adam D'Angelo, founder and CEO of Quora) / Как генерить идеи и что измерять (Стюарт Баттэрфилд, Адам Ди Анджело)


image

Спикеры Стюарт Баттэрфилд (основатель Slack) и Адам Ди Анджело (основатель Quora).



4. Live Office Hours with Yuri Sagalov and Sam Altman


image

Спикер Юрий Сагалов (основатель AeroFS).



5. How to Build a Product I (Michael Seibel, Steve Huffman, Emmett Shear) / Как создать продукт, часть 1/4


image

Спикеры Майкл Сибель и Эммет Шир (сооснователи Twitch), Стив Хаффман (основатель Reddit).



6. How to Build a Product II (Aaron Levie) / Как создать продукт, часть 2/4 (Аарон Леви)


image

Спикер Аарон Леви (основатель Box).



7. How to Build a Product III (Jason Lemkin, Solomon Hykes, Tracy Young and Harry Zhang) / Как создать замечательный продукт, часть 3/4 (Соломона Хайка, Трэйси Янги Гарри Жанг)


image

Спикеры- Соломон Хайк (основатель Docker), Трэйси Янг (основательница Plangrid) и Гарри Жанг (основатель Lob).



8. How to Build a Product IV (Jan Koum) / Как создать продукт, часть 4/4, (Ян Кум)


image

Спикер Ян Кум (основатель WhatsApp).



9. How to Get Users and Grow (Alex Schultz) / Где брать пользователей (Алекс Шульц)


image

Спикер Алекс Шульц (директор по росту в Facebook).



10. Live Office Hours with Adora Cheung and Avichal Garg/ Консультации стартапов


image

Спикер Avichal Garg (директор по Product Management в Facebook).



11. How to Invent the Future I (Alan Key) / Как изобрести будущее, часть I (Алан Кей)


image

Спикер Алан Кей (ментор Стива Джобса, создатель концепции ООП и ноутбука).


12. How to Invent the Future II(Alan Key) / Как изобрести будущее, часть II (Алан Кей)


image

Спикер Алан Кей (ментор Стива Джобса, создатель концепции ООП и ноутбука)



13. How to Find Product Market Fit (Peter Reinhardt)/ Как найти Product Market Fit (Питер Райнхардт)


image

Спикер Питер Райнхардт (основатель Segment).



14. How to Think About PR (Sharon Pope) / Как стартапу делать пиар (Шерон Поуп)


image

Спикер Шерон Поуп (глава маркетинга в YC Continuity).



15. Diversity + Inclusion at Early Stage Startups / Разнообразие и вовлеченность в стартапах ранней стадии


image



16. How to Build and Manage Teams (Vinod Khosla) / Создание и управление командами (Винод Хосла)


image

Спикер Винод Хосла (сооснователь Sun Microsystems).



17. Live Office Hours with Kevin Hale and Dalton Caldwell / Офисные часы с Далтоном Колдуэллом


image



18. How to Raise Money, and How to Succeed Long-Term(Jess Lee, Aaron Harris) / Как привлекать деньги и преуспеть в долгосрочной перспективе (Аарон Харрис, Джесс Ли)


image

Спикеры Аарон Харрис (главный по Раунду А в YC), Джесс Ли (основательница Polyvore
и партнер в Sequoia Capital)



2018


1. Geoff Ralston And Adora Cheung Introduction To Startup School


image


2. Sam Altman How to Succeed with a Startup / Как стартапу добиться успеха Сэм Альтман


image

Спикеры Сэм Альтман (основатель Loopt).



3. Carolynn Levy And Panel (Jon Levy, Jason Kwon) Startup Legal Mechanics / Юридическая мехника стартапа Кэролин Леви, Джон Леви и Джейсон Квон


image

Спикер Каролайн Леви (Managing Director YC, Legal and People Ops ), Джон Леви и Джейсон Квон (партнеры YC).



4. A Conversation with Paul Graham Moderated by Geoff Ralston / Беседа с Полом Грэм о том, как приходят идеи, как находить основателей и первых сотрудников


image

Спикер Пол Грэм (основатель Y Combinator).



5. David Rusenko How To Find Product Market Fit / Дэвид Русенко, Weebly как найти рыночную нишу


image

Спикер Дэвид Русенко (основатель Weebly).



6. Michael Seibel Building Product / Майкл Сибел Как создать востребованный продукт


image

Спикер Майкл Сибель (основатель Twitch).



7. A Conversation with Ooshma Garg Moderated by Adora Cheung


image



8. Suhail Doshi How to Measure Your Product / Сухаил Доши Как и что измерять в вашем продукте


image

Спикер Сухаил Доши (основатель Mixpanel).


9. Gustaf Alstromer How to Get Users and Grow / Как найти пользователей и развиваться Густав Альстромер


image

Спикер Густав Альстромер (Product Lead on the Growth team Airbnb).



10. A Conversation About Crypto-currencies and ICOs with Andy Bromberg


image



11. Design for Startups by Garry Tan (Part 1) / Дизайн для стартапов. Гэри Тан. I


image

Спикер Гэри Тан (основатель Posterous и Posthaven).



12. Design for Startups by Garry Tan (Part 2) / Дизайн для стартапов. Гэри Тан. Часть Вторая


image

Спикер Гэри Тан (основатель Posterous и Posthaven).



13. PR + Content for Growth by Kat Maalac and Craig Cannon / PR и контент для роста


image

Спикеры Кэт Маньялак (Managing Outreach Officer at YC) и Крэйг Кэнон (директор по маркетингу YC).



14. A Conversation with Aileen Lee / Беседа с Эйлин Ли


image

Спикер Эйлин Ли (основатель Cowboy Ventures).



15. How to Sell by Tyler Bosmeny / Продажи и создание команды по продажам


image

Спикер Тайлер Босмени (основатель и CEO Clever).



16. Building an Engineering Team by Ammon Bartram and Harj Taggar / Создание команды технарей опыт Аммона Бартрама и Хардж Таггара


image

Спикеры Хардж Таггар (основатель TripleByte) и Аммон Бартрам (основатель TripleByte).



17. How to Apply and Succeed at Y Combinator by Dalton Caldwell / Как подать заявку в YC и преуспеть Далтон Калдуэлл


image

Спикер Спикер Далтон Колдуэлл (основатель imeem и App.net).



18. Running Your Company by Patrick Collison / Как рулить стартапом Патрик Коллисон


image

Спикер Патрик Коллисон (основатель Stripe).



19. A Conversation with Elizabeth Iorns Advice for Biotech Founders


image



20. Startup Technology Technical Founder Advice / Советы от технических директоров стартапов


image

Спикеры Lillian Chou (COO, Second Measure), Diana Hu (CTO, Escher Reality), Calvin French-Owen (CTO, Segment) and Ralph Gootee (CTO, PlanGrid).



21. Fundraising Fundamentals By Geoff Ralston / Основы привлечения финансов Джеф Ральстон


image

Спикер Джеф Ральстон (основатель RocketMail, которая позже стала Yahoo! Mail).


22. A Conversation on Hard Tech with Eric Migicovsky


image



23. Understanding SAFEs and Priced Equity Rounds by Kirsty Nathoo


image



24. How to Get Meetings with Investors and Raise Money by Aaron Harris / Как проводить встречи с инвесторами и убеждать их вложить деньги в вас Арон Харрис


image

Спикер Арон Харрис (главный по Раунду А в YC).



25. A Conversation with Elad Gil


image



26. The Path to $100B by Paul Buchheit / Путь к 100 млрд Пол Букхайт


image

Спикер Пол Букхайт (создатель Gmail и основатель FriendFeed).



27. After PMF: People, Customers, Sales by Mathilde Collin


image



28. How to Win by Daniel Gross / Как победить и не умереть на пути к успеху Дэниэл Гросс


image

Спикер Дэниэл Гросс (основатель Сue, бывший Greplin).



29. A Conversation with Werner Vogels (CTO of Amazon)


image

Спикер Вернер Фогельс (техдиректор и вице-президент Amazon).



2019-2020


1. Kevin Hale How to Evaluate Startup Ideas / Как оценивать и выбирать идеи для запуска стартапа Кевин Хейл


image

Спикер Кевин Хейл (партнер Y Combinator, основатель WuFoo).



2. Eric Migicovsky How to Talk to Users / Как разговаривать с пользователями Эрик Мигиковский


image

Спикер Эрик Мигиковский (основатель Pebble).



3. Startup School Q&A Week 1 / Вопросы и ответы


image



4. Adora Cheung How to Set KPIs and Goals / Как ставить цели и KPI Адора Ченг


image

Спикер Адора Ченг (партнер YC).



5. Ilya Volodarsky Analytics for Startups / Аналитика для стартапа Илья Володарский


image

Спикер Илья Володарский (основатель Segment).



6. Michael Seibel How to Plan an MVP / Как правильно спланировать создание MVP Майкл Сибель


image

Спикер Майкл Сибель (основатель Twitch).



7. Anu Hariharan Nine Business Models and the Metrics Investors Want / Девять бизнес-моделей и какие метрики хотят видеть инвесторы Ану Харихаран


image

Спикер Ану Харихаран (YC Continuity Partner).



8. Anu Hariharan and Adora Cheung How Investors Measure Startups Q&A / Вопросы и ответы


image



9. Kat Maalac How to Launch (Again and Again) / Как стартапу быстро запуститься, а потом еще раз и еще раз Кэт Маньялак


image

Спикер Кэт Маньялак (Managing Outreach Officer at YC).



10. Gustaf Alstrmer Growth for Startups / Механика роста и масштабирования стартапа Густав Альстромер


image

Спикер Густав Альстромер (Product Lead on the Growth team Airbnb).



11. Kirsty Nathoo Managing Startup Finances / Как стартапу не попадать в кассовые и другие финансовые разрывы Кирсти Нату


image

Спикер Кирсти Нату (партнер и финансовый директор YC).



12. Tim Brady Building Culture / Как заложить фундамент здоровой и сильной культуры в стартапе Тим Брэди


image

Спикер Тим Брэди (основатель Imagine K12, CEO QuestBridge).



13. Dalton Caldwell All About Pivoting / Что такое пивоты, когда и как их делать и как Далтон Колдуэлл


image

Спикер Далтон Колдуэлл (основатель imeem и App.net).



14. Kevin Hale How to Improve Conversion Rates / Как улучшить показатели конверсии и как это влияет на рост Кевин Хейл


image

Спикер Кевин Хейл (партнер Y Combinator, основатель WuFoo).



15. Kevin Hale Startup Pricing 101 / Как устанавливать цены и как это влияет на рост стартапа Кевин Хейл


image

Спикер Кевин Хейл (партнер Y Combinator, основатель WuFoo).



16. Kevin Hale How to Work Together / Как в стартапе наладить коммуникацию между со-основателями Кевин Хейл


image

Спикер Кевин Хейл (партнер Y Combinator, основатель WuFoo).



17. Adora Cheung How to Prioritize Your Time / Как выставлять интервалы и приоритеты задачам Адора Ченг


image

Спикер Адора Ченг (партнер YC).



18. Kevin Hale How to Pitch Your Startup / Как питчить ваш стартап Кевин Хейл


image

Спикер Кевин Хейл (партнер Y Combinator, основатель WuFoo).



19. Carolynn Levy Modern Startup Funding / Рассказываем о реалиях современного инвестирования Каролайн Леви


image

Спикер Каролайн Леви (Managing Director YC, Legal and People Ops).



20. Jared Friedman Advice for Hard-tech and Biotech Founders / Советы наукоемким и биотех-стартапам Джаред Фридман


image

Спикер Джаред Фридман (основатель Scribd).



21. Ali Rowghani How to Lead / Как стать лидером и вести за собой людей Али Рогани


image

Спикер Али Рогани (финансист Pixar).



22. Kevin Hale and Adora Cheung Startup School 2019 by the Numbers


image



23. Geoff Ralston Parting Advice / Заключительные советы президента Y Combinator Джефа Ральстона


image

Спикер Джеф Ральстон (основатель RocketMail, которая позже стала Yahoo! Mail).



P.S.


Ron Conway Startup Investor School Day 4


image





9 ноября 2020 стартовала бесплатная Школа стартапов для будущих основателей (Startup School for Future Founders от Y Combinator) от лучшего в мире акселератора и мы будем публиковать полезные переводы для тех, кто планирует стать основателем стартапа международного уровня.

Следите за новостями YC Startup Library на русском в телеграм-канале или в фейсбуке.

Полезные материалы


Подробнее..

Типичные ошибки в тестовых заданиях стажёров-исследователей

20.11.2020 10:22:07 | Автор: admin

Привет, меня зовут Ксения, яисследователь вUXlab Авито. Некоторое время назад мызапустили стажёрскую программу сразу внесколько направлений: искали продуктовых дизайнеров идизайнеров коммуникаций, редакторов иисследователей.


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



Кого мыискали


UX-лаборатория Авито помогает продуктовым командам проверять гипотезы, используя качественные методы исследований. Восновном это интервью июзабилити-тесты. Чтобы помочь бизнесу хорошими качественными данными, важно разбираться влюдях ипонимать, как проводятся исследования.


Нужно знать, как подобрать метод подзадачу, сформулировать гипотезы исформировать выборку. Понимать, как задавать вопросы, чтобы неполучить искажённые данныеи, конечноже, как врезультате сделать корректные прикладные выводы.


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


Чтобы это случилось быстрее, мыискали вкоманду человека, вкотором сошлисьбы три основных фактора:


  1. Есть база: психологическое или социологическое образование либо релевантный опыт работы.
  2. Есть мотивация, которая понятна потестовому заданию иопыту. Мыпредполагали, что если человек действительно увлечён профессией, тоонуже пробовал применить свои навыки.
  3. Есть навыки проведения исследований.

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


Тестовое задание


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


Наше тестовое задание
Задание1.

Мызапустили новую функцию оценку стоимости авто спробегом. Благодаря оценкам покупатели могут быстрее заметить выгодные предложения.

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

После запуска мыхотим провести тестирование, которое ответит навопросы:
  1. Замечаютли покупатели оценки?
  2. Помогаютли они выбрать автомобиль, упрощаютли процесс поиска?
  3. Как покупатели понимают, что это заотметка, что непонятно вновой функции, какой информации нехватает?


Проведите юзабилити-тест функции:
  1. Подготовьте дизайн исследования: опишите цели, задачи иаудиторию, сформулируйте гипотезы, составьте сценарий тестирования.
  2. Проведите исследование сучастием хотябы двух респондентов.
  3. Сформулируйте выводы, попробуйте ответить навопросы исследования.


Задание2.

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

Мыдобавили истории наАвито. Чтобы сделать ихмаксимально полезными, нужно исследование, которое ответит навопросы:
  1. Какие задачи пользователи решают, просматривая истории вдругих приложениях?
  2. Как люди используют истории вне социальных приложений?
  3. Начём стоит сфокусироваться при создании историй вАвито?
  4. Что важно учесть при создании этого продукта?


Вам нужно:
  1. Подготовить дизайн исследования, которое поможет ответить навопросы выше: описать цели, задачи иаудиторию, сформулировать гипотезы, составить сценарий.
  2. Провести исследование, сформулировать выводы иответы навопросы.


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


Неверный выбор метода исследования


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


Для решения второго задания состориз кандидаты выбирали:


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

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


Отсутствие гипотез или неверные формулировки гипотез


Сгипотезами был целый набор проблем.


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


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


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


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


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


Вторая гипотеза впримере грешит ещё итем, что сформулирована нечётко. Изнеё непонятно, оподаче какого материала речь.


Несколько гипотез водной. Важно, чтобы гипотеза была сформулирована ввиде одной законченной мысли. Тогда будет легко однозначно ответить, верна она или нет. Кроме того, всоставе сложной гипотезы могут оказаться предположения, которые нужно проверять разными методами.


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


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


Ещё пример гипотезы сподобной проблемой: есть положительная зависимость между уровнем знания (восприятия) функции ирешением опокупке автомобиля.


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


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


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


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


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


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


Бесполезные гипотезы. Взаданиях встречались гипотезы, оторванные отреалий изадач бизнеса. Такие предположения нет смысла проверять, потому что они непомогут развитию продукта. Можно легко придумать много таких гипотез, незная внутреннюю кухню компании. Но, если взять например, такую гипотезу: сториз вАвито теряются нафоне сториз вдругих сервисах, тостановится понятно, что:


  • она сформулирована так, что неочевидно, как еёпроверить;
  • поскольку Авито несоциальная сеть, товрядли убизнеса будет задача сделать лучшие вмире сториз.

Некорректное формирование выборки


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


Вэтих критериях самих посебе нет проблем, они могут быть дополнительными. Ноглавное для формирования выборки впервом задании опыт респондента виспользовании Авито иего текущая потребность впокупке авто.


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


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


Ошибки всценарии исследования


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


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


Посамим вопросам всценарии были такие ошибки:


  • Закрытые вопросы. Например, замечалили выинформационные блоки санализом уровня цены иотметками хорошая цена или отличная цена?. Во-первых, натакой вопрос легко ответить просто да или нет, что малополезно вкачественном интервью. Во-вторых, онсодержит всебе подсказку, из-за которой мынеузнаем, сказалбы сам человек про эти отметки или нет.
  • Вопросы или задания втесте сподсказкой. Например, кандидаты просили найти авто сценой ниже рыночной. Такая постановка вопроса уже фокусирует внимание респондента нацене ивсём, что сней связано.
  • Сложные формулировки вопросов. Например, вопрос былили какие-либо аспекты системы, которые помогли выполнить задачи?. Для респондента исследование это беседа набытовые темы, вкоторой неместо сложным конструкциям ипрофессиональной терминологии. Если человек непоймёт ваш вопрос, тоонвлучшем случае почувствует неловкость, авхудшем непереспросит, ивынеполучите точный ответ. Намного лучше задавать простые вопросы, такие как ачто вам помогло при поиске?.

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


Чек-лист для самопроверки


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


  1. Проверьте, что вашу работу легко посмотреть: желательно, чтобы она открывалась поссылке, ненужно было ничего скачивать или где-то регистрироваться. Помните, что задания смотрят нетолькоHR, ноиспециалисты повашему треку.
  2. Подумайте отом, как оформить тестовое задание. Когда нужно проверить десятки работ, идеально, если работа каждого человека находится вотдельном файле, подписана его именем иаккуратно структурирована. Также, лучше неиспользовать для работы исследователя Фигму. Основной результат работы здесь текст. Его логичнее оформить вгугл-документе, Notion или любом другом инструменте для работы стекстом, аФигму оставить дизайнерам.
  3. Старайтесь избегать ошибок, опечаток ислишком сложных предложений. Лучше перечитать работу насвежую голову, или показать другу, чтобы убрать лишнее ипереформулировать непонятное.
  4. Стоит выполнять задания так, как указано втестовом. Если вырешили сделать по-другому, поясните, почему. Конечно, висследованиях зачастую нет единственного верного ответа, нонам важно понять, как вымыслите.
  5. Описывая выполнение задачи, постарайтесь дать всю необходимую информацию для оценки работы: параметры выборки, гипотезы, сценарий, тоесть список вопросов креспондентам, расшифровки интервью итестов, результаты ивыводы.
  6. Втоже время помните, что исследование для компании это некурсовая. Лучше опустить лишние подробности повыполнению заданий, например даты, объект ипредмет исследования. Добавляя информацию, спрашивайте себя, точноли она будет полезна или это просто следование стандартам.
  7. Продумывая гипотезы, помните, что они должны быть сформулированы чётко, однозначно ипредполагать ответ да или нет. Они должны быть именно предположениями, требующими проверки, анеочевидными утверждениями. Отформулировки гипотезы зависит выбор метода иформирование выборки, поэтому перечитайте еёдважды испросите себя: ясмогу проверить это предположение тем методом, который указан втестовом? или какой метод лучше всего поможет проверить такую гипотезу?, если это задача отзаказчика. Также убедитесь, что результат проверки гипотезы будет полезен продукту ипоможет продвинуться вего улучшении.
  8. При формировании выборки держите вголове тех людей, которые смогут лучше всего ответить наваши гипотезы, исходя изсвоего опыта ипотребностей. Кстати, когда яхотела понять, насколько хороша эта статья, япопросила еёпосмотреть людей сразным опытом изнашей команды: самого опытного эксперта, чтобы оценить верность выводов, инашего стажёра, как представителя ЦА.
  9. Когда составляете сценарий, начинайте разговор изадания среального опыта респондента.
  10. При составлении сценария фокусируйтесь наоткрытых вопросах, чтобы ненаводить человека наответы. Конкретизировать всегда успеете походу теста.
  11. Помните, что всценарии неместо сложным конструкциям ипрофессиональному жаргону. Говорите среспондентом наего языке.

Вместо заключения


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


  • Упоминание общения спродуктовой командой, которая ставит задачу.
  • Анализ конкурентов перед исследованием.
  • Кабинетный этап исследования. Например, некоторые изучили аудиторию нашего сервиса пооткрытым источникам ииспользовали это при обосновании выборки.
  • Протоколы интервью итестов.
  • Видеозаписи тестов.

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

Подробнее..

Эволюция работы с техническим долгом

24.11.2020 10:23:43 | Автор: admin

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

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

Немного теории

Технический долг справа внизуТехнический долг справа внизу

Что такое технический долг?Технический долг - работы, если их не сделать, несут ущерб невидимый для пользователя (ручная настройка фичи, нечитаемые/отсутствие логов).

Результат погашения технического долга не виден пользователю, но повысит качество продукта (надежность, безопасность, скорость разработки, стабильность).

Каждый берет, то, что ему ближе

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

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

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

Из-за отсутствия механизма ранжирования задач, каждый брал то, что интересно ему. А из-за отсутствия процесса, который позволял бы задачам дойти до боевых серверов, такие задачи часто застревали где-то в районе code-review или тестирования (ведь основные задачи всегда более приоритетны!)

Собственный велосипед для ранжирования

Мы не стали брать какую-то готовую систему оценки, которую кроме того, что применить, нужно еще и подстроить для себя, а сделали собственную.

Каждую из задач технического долга мы оценивали по 4 критериям:

  • Повторяемость - как часто мы сталкиваемся с этой проблемой. (0 - очень редко, раз в полгода, 5 - каждый день)

  • Скорость доставки - как данная задача повлияет на скорость доставки других фичей. (скорость разработки, время тестирования, время деплоймента, предсказуемость разработки) (0 - не влияет, 5 - экономит очень много времени)

  • Влияние на время оперирования (расходы на эксплуатацию, нагрузка на сервер, безопасность) (0 - не влияет, 5 серьезно снижает расходы и риски оперирования)

  • Уровень технической инвестиции (0 - это не инвестиция, 5 - технический энейблер для большого ряда задач)

Каждую задачу мы оценили в привычных для нас story points, чтобы оценить сложность.

Исходя из этих параметров, мы можем посчитать условное TechDebt Value, на основе которого задачи ранжируются (чем больше, тем важнее).

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

Таким образом, мы смогли отсортировать задачи на доске технического долга от наиболее важных, до наименее важных.

Самое сложное в этом процессе - собрать команду и вместе оценить все задачи тех. долга по каждому критерию.

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

Упрощаем процесс

Поняв, что текущая оценка достаточно сложная и долгая, мы решили отказаться от неё.

Но чем заменить?

Решили оценить влияние на техническое состояние продукта одним числом, так, как делаем это с оценкой в story point - на основе сравнения с другими задачами. Не важно, влияет это на оперирование или на скорость доставки, если влияют одинаково, то и оценка будет одна и та же.

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

Процесс погашения тоже претерпел изменения.

Среди задач, всегда есть какие-то совсем простые. Чтобы не занимать место в спринте (оно ограничено нашим capacity), решили собрать из них новую доску. В рамках любой продуктовой задачи, можно сделать и какую-нибудь маленькую задачу, улучшив продукт.

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

А дальше?

Мы находимся на последнем из описанных этапов. Пока рано делать выводы, насколько он успешен, главное, что механизм есть, он работает и приносит пользу команде и продукту.

Подробнее..

Перевод YC Startup Library на русском Чем питч для инвесторов отличается от питча для клиентов (Майкл Сибель)

17.11.2020 20:16:29 | Автор: admin
9 ноября 2020 стартовала Школа стартапов для будущих основателей (Startup School for Future Founders от Y Combinator) и мы будем публиковать полезные переводы для тех, кто планирует стать основателем стартапа международного уровня. Следите за новостями в телеграм-канале YC library на русском.

image

Майкл Сибель сооснователь (в 25 лет) стартапов Justin.tv/Twitch (капитализация $15 млрд) и Socialcam, член правления Reddit. На данный момент исполнительный директор (CEO) Y Combinator.

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

image

Общение с клиентами


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

image

Где можно использовать питч для клиентов.
Если вы не знаете, как и где разместить питч для своих клиентов, то вот пара вариантов:

  • коммерческие обзвоны
  • главная страница сайта (если есть)
  • раздел помощь или часто задаваемые вопросы
  • опросы пользователей

Во всех этих случаях обильное употребление сленга будет уместно.

Питч для инвесторов


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

  • меньше сленга
  • понятный язык без витиеватых оборотов
  • меньше маркетинга в речи

К сожалению, инвестора не интересует ваша маркетинговая речь, он попросту ее профильтрует, чтобы понять, что же на самом деле скрывается за всем этим продающим текстом. Мне нравится приводить питчинг Google в качестве примера. Предположим, что я представляю Google и рассказываю следующее: Google организует мировую информацию. Инвестору это ни о чем не говорит. Если, конечно, он вдруг понял о чем речь то просто бесподобно. Но если все же люди не знакомы с работой Google, то эта фраза им никак не поможет, и даже не даст представления. Гораздо лучше сказать, что Google это новый тип поисковой системы. С помощью Google вы заходите на наш веб-сайт, в поле поиска вводите то, что хотели бы узнать, нажимаете enter, и мы даем вам упорядоченный список сайтов, которые, по нашему мнению, могут помочь вам найти нужную информацию. Чем мы отличаемся от других: сайты ранжируются по количеству ссылок, сделанных на них, поэтому результаты поиска получаются более актуальными.

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

Где можно использовать питч для инвесторов:

  • точно не на вашем веб-сайте
  • не во время переговоров с клиентами
  • только в инвестиционной презентации

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

Что важно инвесторам


Обычно инвесторов интересуют следующие вопросы:

  • над чем вы работаете (изложите наипростейшим языком)
  • как далеко вы продвинулись (только на стадии идеи? создаете продукт? запускаете продукт? уже есть большой прирост клиентов?)
  • насколько велика ваша ниша и целевая аудитория
  • как планируете взимать плату со своих пользователей
  • что, по вашему мнению, вы знаете такого об этом рынке, чего не знают другие
  • кто конкретно входит в вашу команду? кто является основателем? есть ли у вас возможность произвести продукт, который вы пытаетесь вывести на рынок?

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

Конечно, в каждом случае есть свои исключения. Но большинство основателей, чьи стартапы проходят через Y Combinator, мы все-таки учим разграничивать эти вещи. Забавно, что на это уходит некоторое время, и требуется практика. В течение первого месяца основатели в YC все еще пытаются понять, как объединить питч для инвесторов с клиентским. Только после нескольких попыток нам все же удается убедить их создать два различных питча.

Резюме


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



(Мы готовим полный перевод всех учебных материалов Startup School и YC Library, следите за новостями тут)

Полезные материалы


Подробнее..

Перевод YC Startup Library на русском Создавать продукт как небольшой стартап (Майкл Сибель)

19.11.2020 14:19:12 | Автор: admin
9 ноября 2020 стартовала бесплатная Школа стартапов для будущих основателей (Startup School for Future Founders от Y Combinator) от лучшего в мире акселератора и мы будем публиковать полезные переводы для тех, кто планирует стать основателем стартапа международного уровня. Следите за новостями YC Startup Library на русском в телеграм-канале или в фейсбуке .

image

Майкл Сибель сооснователь (в 25 лет) стартапов Justin.tv/Twitch (капитализация $15 млрд) и Socialcam, член правления Reddit. На данный момент исполнительный директор (CEO) Y Combinator.

Многие проблемы, с которыми я столкнулся в начале развития своей компании, появились потому что я не смог понять, как выпустить продукт в свет. Вместо этого, у меня и моих сооснователей были долгие споры, превращающиеся в ссоры о том, что мы не напишем четкие спецификации, о том что мы не уложимся в сроки, мы теряли мотивацию действовать. Через некоторое время я осознал, что лишь небольшое число людей может действительно научить тому, как выпустить продукт. Они говорят о том, что важно выпускать, но не объясняют как. И вот способ быстрого запуска продукта, который мы придумали во времена моей последней компании. Разумеется, нет необходимости все в точности повторять. Фактически вам необходимо повторить любую часть этого процесса. Но вот, что я вам скажу, более формальные первые шаги, которые есть у хороших стартапов, это те, которые способствуют запуску продукта.

Вот, что мы сделали. Сначала мы пришли к тому, что хотим выпускать наш продукт раз в две недели. У нас было приложение для iOS, которое требовало подтверждение от Apple, что занимало какое-то время. Поэтому такой двухнедельный цикл разработки имел больше всего смысла. Второе: мы назначили человека, ответственного за продукт, и это был я. Если быть точным, когда вы ответственны за продукт, это не значит, что вы решаете, что создавать, это значит, что вы ответственны за то, что мы достигнем цели в нашем цикле разработки и выпустим продукт. В-третьих: мы выяснили, какие у нас ключевые показатели эффективности. Первым показателем было создание нового продукта, вторым новые пользователи, третьим сохраненные пользователи. Следующий шаг: кто бы не был во главе, мы придумывали тему для этого цикла разработки продукта основанную на ключевых показателях эффективности, о которых мы говорили ранее. Итак, на этой неделе мы поговорим о том, как удерживать пользователей.

Мы собирали всех людей компании вместе, на том этапе их было всего 4-5 человек. Мы проводили вместе мозговой штурм. Наш цикл разработки продукта начинался со встречи, и это была единственная формальная встреча. Но она длилась столько, сколько требовалось для того, чтобы прийти к определенному выводу. Всего одна встреча, но мы должны были решить, что будем создавать. В начале встречи на большой доске мы расписывали три разные категории: новые функции, баги и тесты, которые мы хотели проводить. Затем мы ходили по кругу и каждый озвучивал идею, которая даст толчок нашему ключевому показателю эффективности, что помогло бы нам удержать пользователей. Каждая идея была написана на доске. Ни одна идея не обсуждалась, не было времени на критику. Если возникали вопросы, кто-то мог прояснить, но все идеи попадали на доску. Конечно, все записывалось в одну из категорий: новая это функция или повторение уже существующей, возможный баг или тест. Это здорово заносить баги в список, так как часто баги это то, что препятствует росту и сохранению пользователей. Они часто идут в странную категорию обслуживания и их удается избежать. У нас ошибки фактически добавлялись непосредственно в цикл разработки продукта отлично. Итак, как только этот мозговой штурм был проведен, наша доска была заполнена функциями, вещами, которые мы можем сделать.

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

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

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

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

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

В частности для нас как для мобильной компании завершающим этапом цикла развития продукта были тесты. Тяжело выпускать исправления ошибок в мобильном приложении, так как уходит какое-то время на подтверждение от Apple, поэтому приходится быть более внимательными на этапе тестов. Для нас тестирование было работой всей команды, потому что все это ненавидели. У нас был длинный список того, что нужно проверить. Это был исторический момент. Каждый раз, когда у нас был новый релиз, мы пополняли наш список для проверки. У нас было высказывание: Тестирует каждый. В результате все инженеры и остальная часть команды, мы все тестировали то, что было в списке. Как только мы находили баги, мы их выписывали и старались понять, как их повторить. Затем после всех тестов проводилось исправление ошибок. В итоге, все прочувствовали, насколько это болезненно проводить тесты.

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



(Мы готовим полный перевод всех учебных материалов Startup School и YC Startup Library, следите за новостями в телеграм или фейсбуке )

Полезные материалы


Подробнее..

Перевод Основы цикла разработки продукта (Майкл Сибель, основатель Twitch)

26.11.2020 14:19:49 | Автор: admin
image

Майкл Сибель сооснователь (в 25 лет) стартапов Justin.tv/Twitch (капитализация $15 млрд) и Socialcam, член правления Reddit.

Прежде чем Justin.tv превратился в Twitch и Socialcam, у нас много лет было неправильное понимание того, как создавать продукт. Мы проводили несвязные совещания по продуктам, и не записывали наши решения. Мы невнимательно относились к новым продуктам, поэтому у членов команды часто были различные представления о том, что мы разрабатываем. Мы всегда хотели создавать полностью готовые к использованию продукты вместо MVP (продуктов с минимальным функционалом). Мы редко делали аналитику новых продуктов, поэтому мы не знали, как они работают после запуска.

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

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

Определите длину цикла разработки


На цикл разработки влияет сам продукт. Мы разрабатывали Socialcam для iOS, поэтому выбрали двухнедельный цикл, во время которого мы успели тщательно протестировать приложение, прежде чем выложить его в App Store. Если вы разрабатываете веб-приложение, ваш цикл может быть короче, если вы делаете железо длиннее. Главное спланируйте цикл так, чтобы команда оставалась заинтересованной, и люди видели, что они всё ещё могут придумывать новые идеи для проектов.

Определите свою цель (цели) и выберите старшего продакт-менеджера


Мы проводили одно и только одно собрание. Оно было посвящено продукту и происходило в первый день цикла разработки. Иногда оно могло длиться пять часов (извините).

Каждое собрание было сфокусировано на одной из трех целей:

  1. Увеличение создания контента
  2. Увеличение числа новых пользователей
  3. Удержание пользователей


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

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

Организованные и всеохватывающие мозговые штурмы


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

Затем все предложенные идеи оценивались присутствующими на собрании разработчиками как простые (несколько таких можно воплотить за один день), средней сложности (осуществление займёт полдня для одного человека), и сложные (займут бОльшую часть всего цикла разработки). Ни одна предложенная для разработки идея не была настолько сложной, что занимала часть от следующего цикла, но если такая идея и возникала, то её разбивали на несколько этапов. Обычно такой разбивкой занимался специалист с самым большим опытом в этой сфере. Функции iOS оценивались разработчиками iOS и так далее и тому подобное. Это очень помогало не-технарям понимать, какие из их идей было легко сделать, а какие сложно. Эта реализация помогала им придумывать всё более и более лёгкие MVP для своих идей. Потом мы разрабатывали простые идеи и, если они работали, то выполняли на них итерации.

Достижение единого мнения


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

Чёткие требования и расчёт вероятности успеха


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

Работа на протяжении цикла разработки


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

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

Результаты


Но в итоге Socialcam не воплотил нашу мечту, так и не став Инстаграмом для видео. Более того, то, что нам нужно было сделать, куда больше похоже на Snapchat. Но этот проект всё же помог нам делать итерации невероятно быстро. В результате мы очень быстро смогли составить список крутых функций, которыми хотелось заняться: видеофильтры, границы видео, титры к видео, звуковые дорожки к видео, оптимизация видеопотока, многочисленные визуальные изменения, профили пользователей, рекомендуемые каналы, переключение между передней и задней камерой во время просмотра видео и многое другое. К тому же это позволило нам экспериментировать с функцией роста, которая стала причиной того, что программу скачали 16 миллионов раз за 3 месяца, и за тот же период времени видео на нашем сайте посмотрели 100 миллионов человек. Но важнее то, что мы сделали всё это быстро, продуктивно, без серьёзных споров, проблем с участием руководства и каких бы то ни было проблем с командой. Иногда я задумываюсь, что случилось бы, если бы вместо того, чтобы продать компанию, мы продолжали работать над ней ещё год Но это уже совсем другая история.



9 ноября 2020 стартовала бесплатная Школа стартапов для будущих основателей (Startup School for Future Founders от Y Combinator) от лучшего в мире акселератора и мы будем публиковать полезные переводы для тех, кто планирует стать основателем стартапа международного уровня.

Следите за новостями YC Startup Library на русском в телеграм-канале или в фейсбуке.

Полезные материалы


Подробнее..

Перевод Пользователи, которые наносят вред на начальном этапе стартапа (Майкл Сибель, основатель Twitch)

29.11.2020 04:09:36 | Автор: admin
image

Майкл Сибель сооснователь (в 25 лет) стартапов Justin.tv/Twitch (капитализация $15 млрд) и Socialcam, член правления Reddit.

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

Майкл: Думаю, что justin.tv был угнан по определению. Изначально мы создали продукт, позволяющий людям жить в прямом эфире своей жизни, и в течение года его использовали для стриминга контента по всему миру, то есть он совершенно по определению был угнан. И что интересно, я немного боюсь что-то говорить здесь. Я бы не хотел говорить, что эти угонщики не те пользователи, которые вам нужны, потому что, как оказалось, так иногда происходит.

Как оказалось, причина, по которой у нас возникло намерение создать Twitch, заключалась в том, что некоторый процент пользователей-угонщиков были геймерами. И кажется, будто бы сообщество могло быть намного больше, если бы мы ему помогли. И в последствии оно таким и стало. Пользователи используют ваш продукт для самых разных целей. Мне нравится думать об этом, скорее, как о некоем спектре. Есть пользователь, который использует ваш продукт по назначению. Да, это здорово, и мне хорошо от этой мысли. А может быть, там есть какой-то бизнес, может быть, пользователь использует ваш продукт необычным способом, с неким потенциалом.

Изучите этих пользователей, эти пользователи очень важны. Например, геймеры на сайте justin.tv. Есть пользователи, которые используют ваш продукт так, что не принося долгосрочной пользы (хотя с них можно выжать краткосрочную пользу, например, монетизировать при помощи рекламы).

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

У нас в Justin.tv были такие пользователи, которые стримили совершенно ужасные вещи, и это не есть хорошо.

Когда я общаюсь со стартаперами в YC, я вижу, что они не знают, как распознать этих (конструктивных) угонщиков, они просто выгоняют их. Нужно уметь распознать негативных угонщиков и выгнать их. Они наносят вред.

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

Инт: Как бы вы классифицировали тех, кто просто забирает на себя все время поддержки клиентов?

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

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

Давайте подумаем об этом на секунду. С одной стороны, они платят.

Инт: Платят за большие апартаменты.

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

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

Иногда угонщики это платящие клиенты и это приносит боль. Их неудобно выгнать.

Инт: Особенно в контексте того, что у вас есть некие показатели, которые вы хотите достичь, и вы

М: Да, да, боже мой, это действительно так, это как будто

Инт: ставит на всем крест. Вы красиво с этим справились, сосредоточившись на решении одной проблемы очень хорошо. Вы сделали ставку на то, чтобы сделать небольшое количество людей очень счастливыми. Если вы впускаете абсолютно всех пользователей, в конечном итоге вы сделаете дерьмовую работу, наполовину решив кучу проблем.

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

Тогда совершенно нормально исследовать, экспериментировать и так далее. Но нельзя позволять организаторам нарковечеринок управлять продуктом для Airbnb и его показателями. Предлагать им A/B-тесты.






9 ноября 2020 стартовала бесплатная Школа стартапов для будущих основателей (Startup School for Future Founders от Y Combinator) от лучшего в мире акселератора и мы будем публиковать полезные переводы для тех, кто планирует стать основателем стартапа международного уровня.

Следите за новостями YC Startup Library на русском в телеграм-канале или в фейсбуке.

Полезные материалы


Подробнее..

Перевод Как заставить руководство проникнуться техническим долгом

18.11.2020 12:16:11 | Автор: admin

Руководство не даёт мне заняться рефакторингом legacy-кода! Знакомая ситуация? Раздражает жутко. Большинство разработчиков рано или поздно сталкивается лбами с менеджером, который совершенно не заинтересован в том, чтобы совершенствовать уже готовое. То нужно реализовать что-то новое, то срочно потушить пожар, то исправить какой-то баг В общем, причина отложить рефакторинг запущенной кодовой базы у них всегда найдётся.

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

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

Менеджеры не программисты


Решение проблемы состоит в том, чтобы донести до менеджеров, какое влияние низкое качество кода оказывает на бизнес. В конечном счёте, деятельность компании нацелена на получение денег. Прибыли. Соответственно, руководство ищет оптимальные пути урезать расходы и привлечь доходы. А значит, чтобы реабилитировать в их глазах рефакторинг, придётся говорить на их языке.

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

Пять аргументов, которые вы можете привести


1) Рефакторинг поможет снизить волатильность предельных издержек на единицу функциональности ПО

Это точная цитата из замечательного выступления Дж. Б. Рейнсберга на конференции на тему Экономика в разработке ПО. Стойте, не уходите! Всё, что здесь сказано, вам прекрасно известно, просто оно сформулировано в абстрактно-заумном духе.

Пойдём по порядку:

  • Рефакторинг поможет снизить пока что всё нормально
  • волатильность иными словами, непредсказуемость
  • предельных издержек то есть сколько ресурса потребует производство ещё одной дополнительной единицы
  • на единицу функциональности ПО она же фича, имеющая ценность для бизнеса. Ура! Ценность для бизнеса это как раз то, что нам нужно.

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

2) За последние месяц 63% ресурса разработки ушло на исправление проблем с качеством продукта

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

Вот несколько метрик, на которые вы можете обратить внимание:

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

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

Как-то я присутствовал на post-mortem бага, которого можно было бы избежать, если бы была проведена проверка типов данных. Код писался на JavaScript. Как раз в то время в компании велись споры о том, стоит ли переходить на TypeScript.

Разработчики, которые разбирались в случившемся, не поленились поднять данные и сумели оценить урон, который баг нанёс бизнесу. Оказалось, что за несколько месяцев своего существования баг высосал из компании миллион канадских долларов. Миллион! Одного этого с головой бы хватило, чтобы окупить стоимость перехода на TypeScript.

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

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

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

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

4) Если инвестировать 10% рабочего времени в качество кода, текучесть кадров существенно снизится.

До сих пор мы говорили об очевидных последствиях низкого качества кода. Но есть одна коварная вещь, которую легко упустить из вида: текучка.

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

А теперь давайте зададимся вопросом: во что компании обходится замена уволившегося разработчика? Нового специалиста нужно найти, провести через процесс найма, ввести в курс дела. Это требует вложений, занимает время и затормаживает всю команду. Руководство однозначно предпочло бы не заниматься подобными перестановками каждый год. Поэтому снижение текучести может стать серьёзным аргументом. А сам факт наличия плана по устранению технического долга сразу даст всей команде +100 к мотивации.

5) Если вложить 20% ресурса в рефакторинг, FRT сократится вдвое и для производительности разработчиков ROI будет положительным

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

Здесь мы проделываем следующее:

  • Выбираем метрики, которые имеют большой вес в техподдержке;
  • Находим пару проблем, которые возникают регулярно и требуют вмешательства разработчиков;
  • Предлагаем план по сокращению числа обращений в техподдержку за счёт устранения исходной причины.
  • Если проблемы такого рода разрешатся, разработчиков реже будут привлекать к задачам, связанным с поддержкой пользователей. То есть у них освободится больше времени, чем было затрачено на рефакторинг, а значит, вложение окупится тот самый положительный ROI.

В конечном счёте, решать им


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

Проводите рефакторинг по ходу дела

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

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

Исправляете баг? Потратьте лишний час на написание автоматического теста. Готовитесь выкатывать новую фичу? Потратьте лишний день, чтобы подчистить код. День изо дня старайтесь, чтобы изменения происходили безболезненно. Через несколько месяцев вы заметите, что эта привычка оказала огромное влияние на вашу производительность. А знаете почему? Потому что рефакторинг помогает снизить волатильность предельных издержек на единицу функциональности ПО.
Подробнее..

Как не купить свою органику гайд по инкрементальности в маркетинге

26.11.2020 00:18:58 | Автор: admin

Привет, читатель! Меня зовут Артём Сайгин, я веду проектGrowth Lab, в котором рассказываю о digital-маркетинге и росте IT-продуктов.

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

О чем поговорим в статье:

  • Что такое инкрементальность.

  • Как её рассчитать.

  • Инкрементальность и атрибуция.

  • Где чаще всего встречается инкрементальность.

Приступим.

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

Что такое инкрементальность

Инкрементальность показывает, сколько в действительности новых пользователей (продаж, дохода) вы получили, показатель измеряется в процентах; чем процент инкременетальности выше, тем чище результат вы получите.

Для большего понимания давайте представим себя на месте Product Owner.
У нас есть продукт (приложение или веб-сайт не важно), и этот продукт имеет постоянный поток продаж из органики. Далее мы решаемся увеличить число продаж и подключить платные каналы.

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

Спустя 6 месяцев после запуска платного канала пришло время подвести итоги. Маркетологи показывают позитивный отчет: продажи растут, CAC (Customer Acquisition Cost) в пределах плана, придраться не к чему хорошая работа.

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

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

Мы закупаем собственную органику, т.е пользователи и так бы пришли к нам, даже если бы мы за них не заплатили. И тут нужно выяснить, а какая часть из привлечённых нами с помощью рекламы пользователей не пришла бы по органике. Это и есть основное понятие инкрементальности (Incrementality).

На графике ниже мы видим, как в действительности распределялись продажи.

Incrementality показывает, сколько реально новых продаж мы смогли получить из платного канала.Cannibalization продажи, которые мы перекупили у нашей органики.

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

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

Закрепим. Чем чище трафик, тем он инкрементальнее, т.е лучше.
И это нужно понимать и считать при запуске нового канала, источника.

Думаю, с понятием инкрементальности разобрались, теперь перейдём к более сложной части расчёту.

Как рассчитать инкрементальность

Инкрементальность (Incrementality) рассчитывается по формуле:

Incremental в нашем случае число инкрементальных продаж.
Paid число продаж из платного канала.

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

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

Прежде чем рассчитать процент инкрементальности, нужно найти переменную Incremental т.е число инкрементальных продаж.

Формула расчета Incremental выглядит так:

Чтобы найти инкрементальные продажи, из платных продаж отнимем продажи, которые были каннибализированны из органики, назовем эту переменную cannibalization.

Cannibalization = число, на которое уменьшился ваш постоянный поток продаж из органики.

В нашем примере cannibalization выглядит так:

Получив значение Cannibalization, легко рассчитать Incremental продажи с платного канала (переменная Paid) минус cannibalization.

Получив все нужные нам переменные, можем перейти к финальной стадии расчёта, и вычислить % Incrementality (по формуле: Incremental / Paid):

Рассчитав Incrementality, можем сделать вывод, что с увеличением продаж из платного канала падает процент инкрементальности этих продаж.

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

Основная сложность расчёта это найти Incremental (число инкрементальных продаж), так как получив это число, мы сможем рассчитать % инкрементальности. Давайте посмотрим на разные способы расчета Incremental.

1. Выявляем incremental через A/B-тест

Такой формат хорошо подходит для выявления инкрементальности платного трафика в соц.сетях, медийных и ремаркетинговых кампаниях.

В ремаркетинге особенно важно считать инкрементальность чем более горячая аудитория (ремаркетинг на продление продукта, брошенная корзина и т.д.), тем менее она инкрементальна. По моему опыту, редко когда инкрементальность ремаркетинговых кампаний достигала > 35%.

Как выглядит эксперимент:

Создаются две идентичные аудитории А и B.
Обе группы одинаковы во всех отношениях, за исключением того, что группе A мы показывали рекламу, а группе B нет.
Далее, измерив конверсии в обеих группах, мы сможем стат. значимо посчитать, как влияет и влияет ли вообще маркетинговая кампания на продажи.

2. Отключение канала

Простой, но при больших объёмах платного трафика рискованный способ расчёта инкрементальности. Методология заключается в том, что мы останавливаем все маркетинговые активности и находим базовое значение органики (константу органики, как в нашем примере). Потом один за другим включаем каналы и считаем их инкрементальность.

Этот вариант не подойдет, если у вас нестабильный трафик из органики или вовсе его нет.

Подойдите к этому варианту с максимальной осторожностью.

3. Корреляция каналов

Хороший, но не во всех ситуациях применимый способ. Берем органику и платный канал и смотрим, как они коррелируют, чем выше корреляция тем выше вероятность каннибализации. Часто корреляцию можно увидеть в контекстной рекламе на бренд и мобильных (UAC) кампаниях.

С расчётом разобрались, идём дальше.
Разберём ещё один подводный камень инкрементальности атрибуцию.

Инкрементальность и атрибуция

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

Прежде чем приступить к основной информации, напомню, что такое атрибуция.

Атрибуция это присвоение ценности конверсии различным событиям, происходящим на пути к этой конверсии, например показам объявлений и кликам

Модель атрибуции это правило или набор правил, определяющих принцип распределения ценности. Бывает много моделей атрибуции, на иллюстрации ниже представлены основные из них.

Post-view часто модель атрибуции по показам искусственно завышает показатели источника.

Представим, что мы закупаем трафик в источниках A и B.
Один пользователь увидел рекламу каждого из источников с одинаковой частотой (всего один раз за выбранный период) и, кликнув по объявлению B, совершил покупку. При post-view аналитике источник A может засчитать себе продажу, т.к пользователь взаимодействовал с рекламой.

Посчитав инкрементальность с учетом атрибуции, мы бы поняли, что источник A неинкрементален (можно его отключить без потерь для компании).

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

Окно атрибуции в разных продуктах и типах бизнеса влияет по разному, в B2B/SMB окно атрибуции может учитывать больший период времени и при этом сильно не влиять на инкрементальность, но увеличение окна атрибуции в b2c продуктах может заметно влиять на инкрементальность.

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

Теперь поговорим о разных ситуациях, где подсчёт инкрементальности важен, но на первый взгляд таковым не кажется.

Где встречается инкрементальность

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

1. Акции

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

Представим, что у нас интернет-магазин электроники.
Чтобы привлечь новых клиентов, мы подготовили скидку в 30% к Black Friday. Как и большинство кампаний, мы начали анонсировать акцию за определенной период до её старта (в нашем примере за 2 месяца). В день акции мы видим всплеск продаж и засчитываем всё в успех акции, но давайте посмотрим подробнее на график:

revenue по месяцамrevenue по месяцам

За месяц до акции и месяц после видим отчетливое падение, и акционный всплеск не смог компенсировать это. Тот же график, но более наглядно.

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

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

Акцией мы не привлекли новых клиентов, показатели остались те же, как если бы мы не запустили кампанию, но из-за скидки мы потеряли 30% revenue.

2. Контекстная реклама по брендовым запросам

Часто контекстная реклама по брендовым запросам в веб-продуктах имеет низкую инкрементальность (при условии, что у продукта хорошо проработана брендовая семантика в SEO), в среднем, % Incrementality ~ 10-30%.

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

3. Ремаркетинговые кампании.

Я уже затрагивал ремаркетиновые кампании в статье, но выделю еще раз.
Чем более горячая аудитория в ремаркетинге (кампании на продление продукта, брошенная корзина и т.д.), тем менее она инкрементальна.

Приведу пример горячей аудитории для понимания.
Давайте представим, что у нас продукт по подписке с ежемесячной оплатой и низким Churn Rate ~ 10%. Мы решили запустить ремаркетинговую кампанию на всех пользователей у которых истекает подписка осталось 5 дней.

Пользователь видит рекламное объявление и кликнув по нему, продлевает подписку. В таком примере процент инкрементальности будет низким, т.к. имея Churn Rate 10% большая часть пользователей (90%) продлит подписку и без ремаркетинговой кампании, т.е. инкрементальность равняется 10%.

4. OEM канал.

К OEM каналу я отношу предустановку софта (как app, так и web) на девайсы производителей и дальнейшую работу по разным моделям CPI, CPA и т.д. В таких каналах чем узнаваемее бренд (продукт), тем ниже инкрементальность.

Представим, что мы занимаемся дистрибуцией мессенджера WeChat в Китае и договорились с Meizu о предустановке приложения на 1 млн. новых смартфонов. За каждую установку на заводе (CPI) мы будем платить N-сумму.

Не зная про инкрементальность, мы засчитаем все устройства, как абсолютно новую привлеченную нами аудиторию пользователей, но это не так. Знание о WeChat в Китае огромное, и с вероятностью в 70-80% (цифры выдуманные, их нужно считать для каждого конкретного случая) пользователей этих девайсов и так бы установили мессенджер из стора бесплатно.

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

Примерный расчёт зависимости цены от инкрементальностиПримерный расчёт зависимости цены от инкрементальности

Получается, мы привлечем от сотрудничества с Meizu только 20-30% новой аудитории, при таком проценте инкрементальности мы не сможем (экономически невыгодно) платить производителю стоимость, как за 100% инкрементальных пользователей.

Если за 10 пользователей с 100% инкрементальностью мы можем заплатить $1000 (CPI - $100), то при инкрементальности в 20% CPI должен быть равен $20. При тех же затратах в $1000 мы получим 20 пользователей, но из них только 10 будут инкременатльными, т.е CPI на нового пользователя останется тем же $100.

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


На этом всё. Надеюсь, статья была полезной, и полученные знания помогут вам сделать маркетинговую стратегию эффективнее. Больше подобных статей можно читать на моём telegram-каналеGrowth Labили насайте.

Не забудьте поделиться с коллегами или просто с теми, кому может быть интересна статья.

Инкрементальных вам продаж!

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru