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

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

Сколько стоит сделать ролик об игре своими силами

29.06.2020 16:21:22 | Автор: admin


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

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

Написано в Alconost

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

Ролики об играх бывают очень разные. Иногда это нарезка видеозахватов, а иногда анимация персонажей или 3D-моделей или даже мультипликация. Безусловно, разная сложность это и разные трудозатраты, поэтому ролики об играх могут в разы отличаться друг от друга по стоимости. Звучит логично, но уж слишком абстрактно, правда?

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

Начнём с трёх допущений: какой именно ролик вам нужен, какими именно сотрудниками вы располагаете и как именно вы выстроите процесс производства видео.

  • Ролик: допустим, вам нужен ролик-трейлер, длительностью не больше минуты, для размещения на сайте игры и в Google Play. Пусть ролик будет на английском, с озвучкой диктором-носителем английского языка, с музыкой и звуковыми эффектами.
  • Команда: предположим, что в команде есть ребята, у которых достаточно знаний, навыков и квалификации, чтобы написать сценарий, создать графику для ролика и анимировать её, а также сделать звуковое оформление видео. Также предположим, что в команде полное взаимопонимание, и каждый в команде может выделять на эту задачу половину рабочего дня без ущерба прочим обязанностям.
  • Процесс: возможно, вы решите следовать процессу создания роликов в Alconost: написать сценарий, сделать раскадровку, записать озвучку, подобрать фоновый трек, собрать анимацию, смонтировать музыку, добавить звуковые эффекты. Не исключено, что в вашем случае процесс нужно подтюнинговать, но как именно можно судить, только зная особенности конкретной игры и конкретной команды. Раз сама ситуация, ролик и команда у нас условные, пусть хотя бы процесс будет конкретный и универсальный.

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


Фото: StartupStockPhotos, Pixabay

Сценарий


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

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

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


Фото: Free-Photos, Pixabay

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

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

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

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

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

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

Раскадровка


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


Фото: VitalikRadko, Depositphotos

Первым делом художник проникается сценарием, смотрит референсы и подбирает арт из уже отрисованных ассетов (находит графические исходники персонажей и, конечно, наручей испуганной нимфы в архиве игровой графики). Затем разрабатывает визуальный стиль: готовит фон, рисует плашки, подбирает шрифт. Так как по сценарию предусмотрено кадрирование видеозахватов, художнику нужно подумать, как компенсировать разницу пропорций между соотношением сторон кадрированного видео (может получиться, например, 1:1) и высотой и шириной кадра (обычно 16:9).

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

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

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

Анимация


Аниматор знакомится со сценарием, смотрит референсы и анимирует раскадровку, подготовленную художником. Также аниматор монтирует видеозахваты: менеджер проекта (о нём далее) их уже отснял и предоставил аниматору вместе с таймкодами удачных фрагментов и инструкциями по их кадрированию и улучшению.


Фото: sonerbakir, Depositphotos

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

Предположим, что анимация графики займет 30 часов, а работа с захватами 10. Допустим, полная черновая сборка в целом понравится команде, но без улучшений не обойтись. Пропустим черновик анимации через три цикла правок (пусть они займут 4, 3 и 2 часа: чем ближе к финальной версии, тем меньше корректировок) и дадим аниматору ещё часок на шлифовку финальной версии. При таком ходе работ трудозатраты аниматора составят 50 часов.

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

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

Звукорежиссура


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

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

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


Фото: princeoflove, Depositphotos

Будем считать, что на монтаж музыки, подбор звуковых эффектов и сведение у звукорежиссёра уйдет около 4 часов, и ещё час понадобится на внесение правок после согласования с командой (бдыщь не подошел надо буммм, и тому подобное). Итого 5 часов.

Остаётся только попросить аниматора свести финальное видео с финальной аудиодорожкой и ролик готов.

Менеджмент


Менеджер делает всё, чтобы процесс работы над роликом шёл продуктивно и был команде в кайф. Иначе зачем это всё?

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


Фото: ilixe48, Depositphotos

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

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

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

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

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

Суммируем время


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

  • Сценарий: 10 ч.
  • Раскадровка 20 ч.
  • Анимация: 50 ч.
  • Звукорежиссура: 5 ч.
  • Менеджмент: 30 ч.

Итого: 115 часов.

Условной геймдев-команде понадобилось около 115 часов, чтобы сделать условный видеоролик о своей игре. Безусловно, наши воображаемые ребята могли где-то справиться быстрее, а где-то залипнуть надолго. Может быть, команда поторопилась со сценарием и при создании раскадровки выяснилось, что не всё получается показать так, как задумано? Или при сборке анимации оказалось, что в сценарии не упомянули что-то важное, и пришлось вернуться на пару шагов назад? А может, ребятам удалось подключить разработчиков к созданию ролика, снять с движка идеальный геймплей и времязатраты на сборку анимации и монтаж захватов удалось сократить?

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

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

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

Переводим в деньги


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

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

Для этого воспользуемся исследованием компании InGame Job, которая в 2019 году опросила 2000 сотрудников геймдев-компаний из России, Беларуси и Украины и высчитала медианную зарплату специалистов на разных должностях.

Роли, которые сотрудники геймдев-студии исполняют в нашем условном проекте, мы соотнесём с должностями, упомянутыми в исследовании. Чтобы выяснить, сколько стоит один час работы каждого специалиста, разделим медианное значение зарплаты за месяц на 21 рабочий день, а полученное число разделим на количество часов в рабочем дне 8.
Роль в проекте / Должность в списке InGame Job Медианная зарплата, $ Стоимость 1 рабочего часа, $ Затрачено времени на ролик, ч. Стоимость часов, затраченных на ролик, $
Копирайтер / Narration Designer 1100 6,5 10 65
Художник / 2D Artist 950 5,6 20 113
Аниматор / Animator 1420 8,5 50 423
Звукорежисcёр / Sound Engineer 1200 7,1 5 36
Менеджер проекта / Project Manager 1800 10,7 30 321
Итого 958

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

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

Прочие расходы



Фото: Arek Socha, Pixabay

  1. Перевод: $20. Столько стоит перевод 1000 знаков с русского на английский в исполнении английского носителя языка в сервисе профессиональных переводов Nitro. 1000 знаков это как раз 120 слов озвучки (идеально для минутного видео) и 8 коротких слоганов.
  2. Дикторская озвучка: $100. Цены на озвучку зависят и от объема текста, и от конкретного исполнителя и его условий, в том числе от минимальной стоимости заказа. Предположим, что мы выбрали опытного диктора из США, который записывается в профессиональной студии и в списке услуг которого есть как раз то, что нам нужно: озвучка роликов для Интернета, длительность до 1 минуты за фиксированную ставку.
  3. Стоковый трек: $30. Бывают треки и по $15, и по $50, а ещё цена в разы увеличивается, если нужна лицензия расширенного типа например для использования в ролике, который будет размещаться на ТВ. Допустим, мы выбрали не самый дорогой трек по стандартной лицензии, которая как раз подходит для публикации ролика на Youtube.

Прибавим эти затраты ($150) к ранее вычисленной сумме. $960+150 = $1110.

Выводы


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

Заказать ролик на аутсорсе или всё же сделать самостоятельно? Каждая геймдев-команда решает на своё усмотрение.

Если вы решите аутсорсить видео посмотрите, какие ролики об играх делают в Alconost.

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

Об авторе


Статья написана в Alconost. Мы уже 8 лет создаём рекламные и обучающие видео, в том числе трейлеры, тизеры и прероллы для игр и приложений. А ещё мы занимаемся локализацией приложений, игр и сервисов на 80+ языков.

Подробнее: alconost.com. Подпишитесь на нас ВКонтакте, Фейсбуке или Твиттере, чтобы первыми увидеть наши свежие работы и анонсы новых публикаций.

Другие наши статьи о создании видеороликов


Подробнее..

Как мы пересмотрели стандартный подход к тендерам и получили 300 дизайн-проектов интерфейса medtech-сервиса по 3000 руб

23.06.2020 20:12:31 | Автор: admin
Мы в Globosphere Russia работаем над тремя медтех проектами. Один из них MY DATA. Это электронная медицинская карта нового поколения на основе big data. Сервис будет собирать информацию о здоровье человека из разных источников, анализировать данные, находить корреляции и приводить информацию к единому формату, выдвигая гипотезы о состоянии здоровья.

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

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

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



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


image

Когда мы размышляли, как поступить с поиском исполнителя. Поняли, что стандартные методы нам не подходят. Вот почему:

Агентствам нужно четкое ТЗ, у нас его не было и пока не может быть.

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

Аутсорс это всегда риски.

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

Найм приносит мало идей.

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

Тендеры отсеивают многих.

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

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

Но мы прикинули рентабельность, взвесили все за и против. Выходило, что на предыдущие варианты мы потратим аналогичное количество времени и ресурсов, но при этом получим меньше идей, чем если проведем конкурс. Так мы решились запустить конкурс для UX/UI на создание электронной медицинской карты нового поколения Future Health Design 2020.

Механика конкурса


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

Условия

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

Призовой фонд

Чтобы сделать конкурс максимально привлекательным, мы объявили общий призовой фонд в 2 600 000 рублей. Из него 600 000 рублей распределяются между 1, 2 и 3 местом. А победителю гарантируется контракт на сумму не менее 2 000 000 рублей.

ТЗ

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

  • Интерфейс врача
  • Интерфейс пациента
  • Анализ данных
  • Хранилище информации
  • Взаимодействие с клиниками и врачами
  • Телемедицина
  • Лекарства


Необязательные блоки для конкурсной работы:

  • Расписание
  • Визуализация человеческого тела


На втором этапе мы отбирали ТОП-15 самых перспективных работ и отправляли исполнителям детальные комментарии для доработки.

Система оценивания

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

Мы поступили следующим образом: первые этапы отбора проходили внутри компании. Силами своей команды мы отобрали из 300 проектов сначала ТОП-15, а потом ТОП-10 финалистов. А вот уже победителей из ТОПА-10 выбирало внешнее жюри, в которое мы пригласили основателей известных российских medtech-проектов (Best Doctor, Третье мнение, Doc+, Мобильные Медицинские Технологии, Кнопка жизни), фарм-проектов (Pharma.Global), экспертов в сфере дизайна (специалисты Skillbox, Дизайн государственных систем).

image

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

image

Продвижение

Мы использовали два основных направления в продвижении:

  • таргетинговая реклама
  • pr-инструменты


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

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

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

С рекламных источников мы получили 53% заявок, с pr-активнсотей 47%.

Этапы

1 этап: 1 28 апреля прием заявок на участие, выполнение ТЗ 1. Отбираем ТОП-15 работ.

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

2 этап: 1 25 мая выполнение ТЗ 2. Отбираем ТОП-10.

На этом этапе мы отправляли ТЗ с уже конкретизированными рекомендациями по доработке проектов тем, кто прошел в ТОП-15. После новой итерации правок отобрали ТОП-10 финалистов.

3 этап: 25 31 мая голосование членов Жюри из разных областей. Выбор ТОП-3.

Определение 1, 2 и 3 места путем общего голосования жюри.

Что мы получили?


Нам прислали около 2300 заявок дизайнеры из 15 стран, из которых мы получили 320 дизайн-проектов конверсия из заявки в конкурсную работу почти 14 %.

Работы оценивались по 10-бальной шкале. Из 320 дизайн-проектов, больше всего работ набрали по 4-5 баллов 33%. А самые высокие баллы получили 9%.

Вот так выглядит полная картина оценки качества работ:
плохо. Баллы: 1-4: 82 работы
средне. Баллы 5-6: 104 работы
хорошо. Баллы 7-8: 74 работы
отлично. Баллы: 9-10: 30 работ


Когда мы планировали конкурс, мы рассчитывали на 1000 заявок и около 150 работ. Исходя из текущей конверсии, выходит, что на 1000 заявок в конкурс со сложным проектом реально получить около 6-7% работ. Мы же перевыполнили KPI в два раза!

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

1 место Нестерова Мария

image
Пример экрана интерфейса из конкурсной работы

2 место Сидорец Кирилл

image
Пример экрана интерфейса из конкурсной работы

3 место агентство Nimax

image
Пример одного экрана интерфейса из конкурсной работы

Со всеми работами финалистов можно познакомиться на сайте конкурса.

Что можно улучшить?


Предусмотреть больше времени на работы

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

Хотя бы за 1 день до окончания: 11%
Последний день: 89%
Последний час: 62%


А по результатам опроса почему на первом этапе дизайнеры не стали принимать участие большинство ответили, что не хватило бы времени сделать хорошую работу 42%.

Давать больше обратной связи участникам

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

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

Статический анализ baseline файлы vs diff

25.06.2020 12:16:27 | Автор: admin

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


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



baseline или так называемый suppress profile


Этот метод имеет несколько названий: baseline файл в Psalm и Android Lint, suppress база (или профиль) в PVS-Studio, code smell baseline в detekt.


Данный файл генерируется линтером при запуске на проекте:


superlinter --create-baseline baseline.xml ./project

Внутри себя он содержит все предупреждения, которые были выданы на этапе создания.


При запуске статического анализатора с baseline.xml, все предупреждения, которые содержатся в этом файле, будут проигнорированы:


superlinter --baseline baseline.xml ./project

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


Обычно, мы хотим достичь следующего:


  • На новый код выдаются все предупреждения
  • На старый код предупреждения выдаются только если его редактировали
  • (опционально) Переносы файлы не должны выдавать предупреждения на весь файл

То, что мы можем конфигурировать в этом подходе это какие поля предупреждения формируют хеш (или "сигнатуру") срабатывания. Чтобы уйти от проблем смещения строк кода, лучше не добавлять номер строки в эти поля.


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


  • Название или код диагностики
  • Текст предупреждения
  • Название файла
  • Строка исходного кода, на которую сработало предупреждение

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


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


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


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


Хорошо подобранный набор признаков увеличивает эффективность baseline подхода.


Коллизии в методе baseline


Допустим, диагностика W104 находит вызовы die в коде.


В проверяемом проекте есть файл foo.php:


function legacy() {  die('test');}

Предположим, используются признаки {имя файла, код диагностики, строка исходного кода}.


Наш анализатор при создании baseline добавляет вызов die('test') в свою базу исключений:


{  "filename": "foo.php",  "diag": "W104",  "line": "die('test');"}

Теперь добавим немного нового кода:


+ function newfunc() {+   die('test');+ }  function legacy() {    die('test');  }

По всем используемым признакам новый вызов die('test') будет распознаваться как игнорируемый код. Совпадение сигнатур для потенциально разных кусков кода мы и называем коллизией.


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


Что делать, если вызов die('test') был добавлен в ту же функцию? Этот вызов может иметь одинаковые соседние строки в обоих случаях, поэтому добавление предыдущей и следующей строки в сигнатуре не поможет.


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


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


Метод, основанный на diff возможностях VCS


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


Утилита revgrep принимает на stdin поток предупреждений, анализирует git diff и выдаёт на выход только те предупреждения, которые исходят от новых строк.


golangci-lint использует форк revgrep как библиотеку, так что в основе его вычисления diff'а лежат те же алгоритмы.

Если выбран этот путь, придётся искать ответ на следующие вопросы:


  • Как выбрать окно коммитов для вычисления diff?
  • Как будем обрабатывать коммиты, пришедшие из основной ветки (merge/rebase)?

Вдобавок нужно понимать, что иногда мы всё же хотим выдавать предупреждения, выходящие за рамки diff. Пример: вы удалили класс директора по мемам, MemeDirector. Если этот класс упоминался в каких-либо doc-комментариях, желательно, чтобы линтер сообщил об этом.


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


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


diff режим в NoVerify


NoVerify имеет два режима работы: diff и full diff.


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


Full diff запускает анализатор дважды: один раз на старом коде, затем на новом коде, а потом фильтрует результаты. Это можно сравнить с генерацией baseline файла на лету с помощью того, что мы можем получить предыдущую версию кода через git. Ожидаемо, этот режим увеличивает время выполнения почти вдвое.


Изначальная схема работы предполагалась такая: на pre-push хуках запускается более быстрый анализ, в режиме обычного diff'а, чтобы люди получали обратную связь как можно быстрее. На CI агентах полный diff. В результате время от времени люди спрашивают, почему на агентах проблемы были найдены, а локально всё чисто. Удобнее иметь одинаковые процессы проверки, чтобы при прохождении pre-push хука была гарантия прохождения на CI фазы линтера.


full diff за один проход


Мы можем делать приближенный к full diff аналог, который не требует двойного анализа кода.


Допустим, в diff попала такая строка:


- class Foo {

Если мы попробуем классифицировать эту строку, то определим её как "Foo class deletion".


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


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


Переименования не требуют дополнительной обработки. Мы считаем, что символ со старым именем был удалён, а с новым добавлен:


- class MemeManager {+ class SeniorMemeManager {

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


Выводы


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


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


baseline diff
+ легко сделать эффективным + не требует хранить файлов
+ простота реализации и конфигурации + проще отличать новый код от старого
- нужно решать коллизии - сложно правильно приготовить

Могут существовать гибридные подходы: сначала берёшь baseline файл, а потом разрешаешь коллизии и вычисляешь смещения строк кода через git.


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

Подробнее..

Перевод Обдумывая стори поинты

23.06.2020 18:09:52 | Автор: admin
image

Мне нравится говорить, что я, возможно, изобрел стори поинты (story points) и если действительно изобрел, то сегодня мне жаль. Давайте рассмотрим подробнее, что я думаю о стори поинтах сейчас. По крайней мере один из нас точно заинтересован в моих мыслях.

Идея историй (stories) конечно же пришла из XP, а не из Scrum. Неким образом скрам-практики адаптировали эту идею в свою работу. Хотя официальный скрам-гайд говорит лишь об элементах бэклога (backlog items), использовать пользовательские истории в качестве элементов бэклога очень распространенная в скраме практика.


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

В экстремальном программировании (ХР), истории изначально оценивались во времени: времени, которое потребуется на завершение разработки истории. Мы быстро начали использовать то, что сейчас называется идеальные дни, которые неофициально означали сколько дней потребуется паре до завершения, если их наконец-таки оставят в покое. Мы перемножали идеальные дни и фактор нагрузки, чтобы получить реальное время до завершения разработки. Фактор нагрузки обычно составлял примерно три: три реальных дня тратилось, чтобы завершить работу одного идеального дня.

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

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

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

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

Я ответил, что:
  • Я точно осуждаю их неправильное использование
  • Я думаю, что использовать их для прогнозирования когда работа будет сделана это в лучшем случае плохая идея
  • Я думаю, что сравнивать как реальные трудозатраты накладываются на оценки это в лучшем случае пустая трата времени
  • Я думаю, что сравнивать команды на базе качества оценок или скорости (velocity) это вредно
  • Давайте взглянем более подробно


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

Сравнение


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

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

Отслеживание


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

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

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

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

Давление


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

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

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

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

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

Предсказывая готовность


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

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

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

Декомпозиция


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

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

Кроме того, есть одна хитрость. Я упоминал ее в Getting Small Stories и в Slicing, Estimating, Trimming. Я выучил ее у Нила Киллика (Neil Killick): декомпозируйте истории, пока они не станут размером с один приемочный тест. После небольшой тренировки, ваши истории станут самого подходящего размера.

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

Предсказывая будущее


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

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

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

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

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

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

Подытожим


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

За перевод огромное спасибо Максиму Фролову
Подробнее..

Перевод Трехступенчатый фреймворк для решения проблем

26.06.2020 18:17:05 | Автор: admin


От автора перевода

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



Уверен, что с аналогичными проблемами сталкивается абсолютное большинство продуктовых компаний. В качестве рабочего инструмента для решения этих проблем полезным представляется подход, описанный в статье Ленни Рачитски, product lead Airbnb.

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

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


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

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



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

  • Шаг 1. Кристаллизация проблемы
  • Шаг 2. Согласование проблемы с командой и стейкхолдерами
  • Шаг 3. Постоянный возврат к проблеме



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

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



Шаг 1. Кристаллизация проблемы


Начните с ответа на эти вопросы о своем проекте.

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

Описание: что это за проект?


Это краткое описание идеи. Люди, читающие его, смогут быстро понять суть. Будьте кратки.

Проблема: какую проблему он решает?


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

Назовем ключевые характеристики правильной постановки проблемы.

  1. Проблема кратка. Цель описать проблему одним предложением. Чем больше вам требуется объяснений, тем менее ясной становится проблема в конечном итоге.
  2. Сфокусирована. У нас есть единственная ясная проблема, которая может быть решена одной командой и в разумные сроки. Часто очень полезно привести несколько примеров других проблем, которые вы НЕ решаете.
  3. Связана с неудовлетворенной потребностью. Сосредоточьтесь на потребностях пользователя или бизнеса. Тут крайне полезно использовать вот этот фреймворк.
  4. Включает ответы на вопрос что и почему. Что идет не так и почему это проблема? Возможно, вам придется вернуться сюда в следующей секции.
  5. Не зависит от решения. Подавляйте в себе желание слишком быстро перейти к решению проблемы.

Хорошие примеры постановки проблемы

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

Плохие примеры постановки проблемы

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

Почему: как мы поняли, что это реальная проблема и ее нужно решать?


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

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

Несколько советов для этого шага.

  1. Изучите количественные и качественные доказательства. Соберите все данные, которые указывают на то, что это действительно реальная и важная проблема.
  2. Качество важнее количества. От 3 до 5 прямых фактов лучше дюжины косвенных. Во втором случае ваши выводы будут слабее, так как они будут основаны на второстепенных и не имеющих отношения к делу фактах, выглядящих как куча доказательств. Лишний перфекционизм также ни к чему.
  3. Сыграйте сами с собой в адвоката дьявола. Попытайтесь убедить себя, что это совершенно незначимая проблема. Какие пробелы имеются в ваших доказательствах? Действительно ли доказательства соответствуют тому, что вы думаете? Проверьте себя.

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

Успех: как мы узнаем, что проблема решена?


Вы достигли того, что планировали достичь? Как вы узнаете? Ответьте на этот вопрос и запишите ответ.



Этот критерий становится невероятно важен на протяжении всего проекта, так как он помогает принимать решения и расставлять приоритеты. Фича X увеличивает шансы достичь поставленной цели? Если нет, не делаем ее.

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

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

  • Постарайтесь получить конкретное число, например: 10% прирост показателя X; 50% уменьшение показателя Y.
  • Цель должна быть достижима, но амбициозна. Достижение какой цели приведет вашу команду и руководителей в восторг?
  • Если вы не смогли придумать метрику для своей цели (думать нужно долго и напряженно), опишите, как будет выглядеть мир в случае успеха проекта. Сделайте это критерием успеха.

Аудитория: для кого мы делаем это?


Тут все довольно очевидно. Мы редко делаем что-то сразу для всех. Это для новых или вернувшихся пользователей? Это для случайных или постоянных пользователей? Это для пользователей сайта или мобильного приложения? И тому подобное.

Что: как будет выглядеть реализация в продукте?


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

Шаг 2. Согласование проблемы с командой и стейкхолдерами


Видели ли вы билборды Чиптолле вдоль шоссе (картинка ниже)? Год назад мой коллега Питер указал на хитрость этой рекламы каждый из нас представляет свой идеальный буррито внутри фольги. Мы все видим то, что хотим увидеть.



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

Я обычно подхожу к этому шагу так.

  1. Возьмите документ, созданный на первом этапе (это может сделать и любой член вашей команды, вовлеченный в эту проблему).
  2. Поделитесь им со всей командой. Соберите обратную связь. Доработайте документ с учетом полученной обратной связи и снова предоставьте его на общее обозрение.
  3. Если обратная связь сходится и команда выглядит синхронизированной отлично. Если нет, соберите всех вместе и обсудите разногласия.
  4. Когда согласие внутри команды будет достигнуто, синхронизируйтесь в понимании проблемы со стейкхолдерами. Важно, чтобы ваша команда и люди, которые будут оценивать результаты, одинаково понимали проблему, которую вы решаете, до того, как вы плотно приступите к работе по проекту.
  5. Соберите команду и снова произведите ревью постановки проблемы. Отыщите ответы на нерешенные вопросы и убедитесь, что у команды есть все необходимое, чтобы начать работать.

Шаг 3. Постоянный возврат к проблеме


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

image

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

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

Избежать этой ловушки помогут полезные привычки.

  1. При каждом ревью проекта удостоверьтесь, что исполнитель начинает с постановки проблемы. Если это не очевидно, задайте вопрос: Какую проблему мы пытаемся решить?.
  2. При каждом отчете о ходе проекта перед стейкхолдерами возвращайтесь к постановке проблемы. Убедитесь, что у всех остается одинаковое ее понимание.
  3. Перед финализацией проекта спросите себя: Чувствую ли я уверенность в том, что мы готовы решить проблему, которую планировали решить изначально?.

И в заключение


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

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

Марк Менсон. Тонкое искусство пофигизма

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

Очень рекомендую прочитать следующие 5 книг.



  1. Deep Work (Кэл Ньюпорт. В работу с головой. Паттерны успеха от IT-специалиста)
  2. The Subtle Art of Not Giving a F*ck (Марк Менсон. Тонкое искусство пофигизма)
  3. Good Strategy, Bad Strategy (Ричард Румельт. Хорошая стратегия, плохая стратегия. В чем отличие и почему это важно)
  4. Measure What Matters (Джон Дорр: Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR)
  5. Lean Analytics (На момент написания статьи не переведена на русский)

От автора перевода

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




Взял фреймворк себе на вооружение. Для удобства использования разработал форму для кристаллизации проблем.

Выражаю благодарность нашему журналисту Анисимовой Татьяне и арт-директору Забегалову Алексею за помощь в редактировании и оформлении статьи.
Подробнее..

Из песочницы Что делать, если в вашей команде появился эффективный менеджер?

02.07.2020 18:23:23 | Автор: admin

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


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



Дано: продуктовая команда удаленщиков с почасовой ставкой, выстроенными и отработанными процессами пятый месяц работает над MVP мобильного приложения в сфере geo-dating. Работа движется по плану, в соответствии с согласованными требованиями, с еженедельными демо-показами без критических отставаний по срокам. Команда сильная, все ребята из топовых IT-компаний. Координатор со стороны инвестора, не технический человек, помогает нам в административных делах и коммуникацией с инвестором. Я выступаю в роли проджект/продакт менеджера, отвечаю за реализацию продукта, его качество и соответствие ожиданиям инвестора. Казалось бы, все более-менее идеально, через месяц должен быть первый публичный релиз.


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


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


В итоге, вместо месяца до релиза MVP внедрение эффективных менеджеров, стоило компании половины продуктовой команды, увеличение сроков выпуска продукта еще на полгода и увеличение ежемесячных расходов ровно в 2 раза!


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



Шаг 1. Внутреннее умиротворение


Если вы попали в такую ситуацию, первое, что нужно сделать, перестать нервничать как можно раньше.


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


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


Шаг 2. Принятие


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


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


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


Шаг 3. Сохранение целостности команды и ограждение от деструктивного воздействия


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


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


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


Шаг 4. Обеспечение максимальной открытости и доброжелательности к новоприбывшим


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


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


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


У нас такая сессия заняла 3 часа. Была перевернута вся документация, проверены все метрики, просмотрена каждая функция приложения. Под конец встречи наши новые руководители не знали, к чему придраться и признали, что вся работа ведется на должном уровне (хотя многих слов в объяснениях даже не поняли), однако заявили, что смогут усилить нашу команду и сделать продукт еще прекраснее.


Шаг 5. Утверждение обязанностей


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


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


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


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


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


Шаг 6. Интеграция в процессы


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


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


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


Шаг 7. Определение канала влияния


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


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


Шаг 8. Переход к совместной работе


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


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


Тут нас ждали первые потери со стороны команды: ушли люди, которые не захотели участвовать в этом цирке. Их можно понять. Но проблема состояла в том, что ушли все back-end разработчики. Причем уволили их одним днем за проявление неуважения к новому руководителю, о чем я писала выше.


Таким образом, мы остаемся с минимальной документацией по инфраструктуре и без переданных дел. Эффективно, не правда ли?


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


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


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



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


Эту работу я взяла на себя. Хорошо, что все ведется в таск-трекере и настроить выгрузку отчетов было несложно. До этого мы просто не тратили время команды на отчетность, так как таск-трекер доступен всем, и информацию о проделанной работе можно узнать в любой момент времени.
Здесь эффективные менеджеры первый раз выстрелили себе в коленную чашечку. На шаге 6 мы установили, что все равны перед процессами. Соответственно, если команда должна подавать детальные отчеты о своей деятельности, то и они тоже. Тут пришло осознание, что у нас отсидеться на фиксированной зарплате, ничего не делая, не получится.


Таким образом, задачи на новоприбывших в таск-трекер ставятся, результатов нет, отчеты выгружаются с нулями. Это видит координатор. На что приходит парирование: Мы будем подавать свои отчеты и готовить их отдельно. Хорошо, работаем дальше.


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


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


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



Шаг 9. Работа над продуктом


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


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


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


Шаг 10. Подведение итогов


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


За это время у нас получилось восстановить всю инфраструктуру приложения и организовать мониторинг и поддержку. Постепенно начали реализовывать согласованные функции. Даже наладился классический процесс: Хотите руководить? Ставьте задачу и приоритет, а мы решим как это сделать. Выстроили регламенты на звонки и обсуждения. В начале нашего знакомства встреча могла затянуться на четыре часа, и никакие методы фасилитации не помогали уменьшить это время, потому что все должны знать поток сознания своего руководителя. Все уже более-менее адаптировались, и состояние команды из критического трансформировалось в и так сойдет.


Тут наступает день Х, когда возвращается координатор, а инвестор запрашивает показ результатов работ и отчеты.


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


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


Выводы


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


И, конечно, честность перед командой, честность перед инвестором ключевые моменты при построении рабочего процесса.


Безвыходных ситуаций нет, есть тернистые пути, которые приходится проходить.


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


  1. Сохраняйте доброжелательность, в данный момент они тоже они часть команды.
  2. Презентуйте и подводите руководителей к нужным решениям, как будто это их идеи. Покажите, что они нужны и вносят ценный вклад в развитие продукта.
  3. Рассказывайте о достижениях, результатах работ и планах на следующий этап. Создавайте видимость, что эффективные менеджеры полностью контролируют процесс разработки и при желании могут на него повлиять.
  4. Постройте канал общения с эффективными менеджерами отдавайте ту информацию, которую они хотят получить, без вреда для основных процессов.
  5. Оставьте внутренний процесс разработки и техническую реализацию в зоне ответственности команды решайте все возникающие вопросы внутри команды и работайте, как работали раньше.

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

Подробнее..

Эх, айти, куда ж ты котишься?

04.07.2020 14:10:42 | Автор: admin
Ну что, Хабр, прошло полгода какого-то очень неприятного 2020, до конца десятилетия ещё чуть-чуть и уже сегодня я могу сказать: это десятилетие прежде всего стало золотым веком IT-сферы. Накопленный опыт, новые эксперименты и крутое железо сделали своё дело. Казалось, что айти стало новым рок-н-роллом, но как-то быстро оно приблизилось к тому, чтобы стать новой попсой. Все хотят в айти, неважно кем: менеджерами всего и по всему, переводчиками, деврелами, пиарщиками, копирайтерами, ну и собственно программистами, тестировщиками, инженерами. А отрасль тем временем сильно видоизменяется. Предлагаю вам поговорить о нас, о нашем айти и о том, куда всё катится.


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

Глава 1. Программисты


Культ программирования


Программисты это космонавты нашего времени, ими хотят стать буквально все: профессия кажется модной, перспективной и высокооплачиваемой. Самое интересное, что культ распространяется не только на школьников, студентов и их родителей, но и на компании. Года так с 2015-го формируется интересное поветрие: все компании стремятся назвать себя ИТ-компанией. Банки, ритейл, интернет-магазины и даже пиццерии позиционируют себя именно как технологические. Здесь происходит подмена понятий: если компания вооружилась крутыми технологиями и предоставляет технологичные услуги своим клиентам, это не ИТ-компания, а продвинутые в плане технической трансформации банки, ритейлеры, рестораны и т.д. ИТ-компания это всё же те организации, которые разрабатывают, внедряют, развивают и поддерживают технологии: хостинги, ЦОДы, разработчики ПО, производители железа, системные интеграторы и т.д.

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

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

  • Веб-разработчики всех мастей, которые делают сайты на коленке и на популярных CMS и даже умеют сотворить CRM на заказ за месяц. Понятно, что здесь не идёт речи ни о качестве, ни о кастомизации, а сами ребята не знают ни алгоритмов, ни правил рефакторинга, ни паттернов и лучших практик говнокодят от души, и всё. Опасная группа, так как с ними небольшие компании часто влетают на деньги и, обжегшись на молоке, дуют и на воду перестают доверять ИТ-отрасли в принципе, начинают отрицать автоматизацию.
  • Следующая группа очень безобидная это мечтающие питонисты. Python покорил мир не хуже, чем котики и в итоге его понемногу учат аналитики, переводчики и даже политологи, чтобы с возрастом уйти в дата сайнс. Понятное дело, что всё учение чаще всего сводится к чтению Лутца и просмотру онлайн-курсов, никакой практики и даже претензий на стажерство. Отдельные маргиналы отвергают Python и учат JavaScript, потому что он простенький и понятный (в этом месте у нормальных разработчиков сводит скулы и выступает пот).
  • Просто образованцы, которым всё равно что учить в текущий момент времени сейчас мода на программирование, значит, программирование. Программисты из них получаются редко, а вот достойные тестировщики встречаются.

Образованцы и образованные


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

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


  • Заменители технического образования (прикладная информатика, бизнес-информатика и т.д.) слабые факультеты в нетехнических вузах, которые открываются для целей набора большого количества студентов, не прошедших в профильные. Образование в большинстве случаев откровенно слабое, преподаватели предлагают устаревшие программы. Исключений мало, правда, они есть.
  • Корпоративные университеты и курсы направление, которое в последнее время ощутимо выросло в качестве и подходах (появились бесплатные слоты, узкие и комплексные программы по разработке и менеджменту, встречаются даже программы для детей). Преподают сами сотрудники, поэтому максимум практики, минимум болтовни. Ощутимых недостатков два: 1) компания обучает под свои требования и шаблоны; 2) такое образование не может заменить высшее и подходит для начинающих готовых специалистов. По сути это исключительно дополнительное образование.
  • Комплексные коммерческие университеты слабые учреждения для понтов и сбора денег. Без комментариев. Но народ идёт, потому что доступно и иллюзорно просто (читай ни о чём).
  • Онлайн-курсы, школы, университеты колоссальная часть индустрии, которая выглядит как джентльмен во фраке, который три месяца не мылся. Вроде и прилично, но при ближайшем знакомстве чёрт побери! Да, хорошие и даже именитые преподаватели, внятные и поэтапные программы, но это низкий уровень подготовки, не соизмеримый с потраченными деньгами. Это же время лучше потратить на просмотр курсов MIT и активное самообучение.

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

Зарплатный коллайдер


Заплаты на ИТ-рынке перегретые во многом из-за того, что компании не-айтишной сферы имеют ресурсы, чтобы устраивать гонку за разработчиками. Условный банк готов заплатить за готового бэкенд-программиста гораздо больше, чем условный поисковик или разработчик ПО, который предпочтёт вырастить себе разработчика из junior-а. Ещё больше платят проектные компании и аутсорсинговые компании (особенно зарубежные). Программисты ощущают себя новыми рок-звёздами, и вот уже сопляк выпускник после окончания мехмата с опытом тестирования 0,5 года закидывает ногу на ногу и требует соточку чистыми.

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

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

Чёрные дыры IT-мира


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

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

Интроверт, характер мерзический


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

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

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


А вы знаете ответы на эти вопросы? Народ хочет знать :-)

Глава 2. Деловое окружение


Охотники за головами


Конечно, на поле боя за айтишников важная роль отводится HR-специалистам, которые уже давно переросли стандартную должность кадровика и превратились в HR, специалистов по развитию персонала, DevRel (специалистов по связям с разработчиками и внутреннему HR PR) и проч. В некоторых компаниях даже есть отдельные HR для найма в R&D и отдельные для всего остального. Они не брезгуют никакими средствами, лишь бы добиться своего и заполучить специалиста, но нередко губят своё же дело на собеседованиях (просьбами написать код на листочке, speak in english with me, вопросами из первых позиций выдачи гугла и психологическими задачками).

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

Они почему-то не понимают, что основной стресс нового сотрудника происходит нет от неудобных тапочек или грустных рыбок в аквариуме, а от сложности вхождения в рабочий процесс, в правила разработки, code style, особенности проектов и т.д. В employee orientation (информирование новичка) должно входить прежде всего ознакомление с обязанностями, функциональными особенностями должности, с сотрудниками команды (в первую очередь связанными с рабочими задачами). И на первом этапе самый ценный человек не формальный, а включённый коллега-наставник по профильной деятельности, который всё объяснит, всему обучит, разъяснит и безболезненно включит в разработку. А тапочки и из ИКЕИ сойдут.

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

Отдельным отрядом за ИТ-специалистами охотятся кадровые агентства, которые умеют продать своим клиентам не очень качественного работника как супер senior-а. В принципе, правило простое: хороший специалист в любой сфере крайне редко становится объектом отношений с агентством, он способен трудоустроиться самостоятельно. А сами агенты не унывают получая отказ от очередного целевого разработчика, они ничтоже сумняшеся просят предоставить контакты коллег или друзей, которые ищут работу или даже которых вы бы хотели трудоустроить в другую компанию (вот это, я понимаю, мотивация трудоустрой коллегу-конкурента и расчисти карьерный путь!).

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

Охотники за кошельками


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

  • Профессиональные конференции. Как вам стоимость билета в 20 или 40 тыс. руб.? И это не первая и не единственная проблема, которая связана с конференциями. Целые специализированные компании устраивают огромные конференции, настоящие фестивали, цель которых во многом собрать деньги за билеты и за места с компаний-участников, которые будут вас завлекать на стенды, а на самом деле хантить всеми возможными способами (квестами, задачками, конкурсами, розыгрышами призов и т.д.). При этом работодатели нередко выступают против участия в таких мероприятиях, т.к. боятся потерять специалистов, за которых они дорого заплатили и которые уже вжились в проект.

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

Да и ковид внёс свои коррективы. Вопрос, надолго ли?

  • Школы английского языка. Хотите с носителем, хотите с преподавателем, хотите в мобильном приложении без общения. Очень много школ языка, которые ориентируются именно на айтишников, справедливо полагая, что в их профессиональной деятельности без английского никуда даже по Хабру это очень заметно. Между тем, мало кто говорит, что проку от таких школ именно в профессиональной сфере мало, здесь больше подойдёт погружение в среду, приоритетное использование иностранного на работе и в переписке, чтение книг и статей на английском. Школы больше помогут раскрепоститься и начать разговаривать, но профессиональная сфера зависит от вас и не так проста, как кажется.
  • Курсы программирования. Их просто сотни в любом городе, онлайн, при крупных компаниях и в вузах. Из них сильных и реально полезных единицы и, как правило, они оффлайновые и связаны с реальной практикой. Онлайн-курс может сориентировать вас, стоит идти в эту технологию или нет, понять, заходит или нет, но конечный результат будет зависеть от вашей практики, книг перед вашим носом и количества разобранных мануалов. Никакие потраченные деньги не помогут, если вы будете просто слушателем максимум вы научитесь отличать код на своём языке от всех остальных и выучите крутые разработческие словечки. Стоимость годового курса популярных онлайн-академий можно инвестировать в себя гораздо выигрышней.
  • Курсы повышения квалификации (в ИТ, менеджменте и т.д.) ещё один слой онлайн и офлайн образования. Scrum, Agile, управление проектами, курс продуктового менеджера всё для вас. Не буду рассуждать о том, что это даёт, скажу так: в книгах написано лучше. А для карьеры гораздо полезнее будет MBA (но и эта тема имеет кучу нюансов).
  • Эксклюзивные услуги трудоустройства. Сервисы поиска работы это вообще для лохов, как бы намекают нам эксклюзивные рекрутеры и обещают трудоустроить в Google, Apple и Microsoft с пол пинка. Но за это придётся заплатить либо вам либо работодателю (который потом при первом же случае вас этим попрекнёт), пройти платный курс, оплатить особое оформление и наполнение резюме. К слову, гарантии почти никто не даёт. Думаю, вы поняли, как устроен этот бизнес. Ваш опыт в любом резюме прекрасен, не стоит переплачивать там, где в этом нет необходимости.
  • Издательства профессиональной литературы. Есть офигенные зарубежные и отечественные издательства, которые выпускают классные книги (выделю Питер как лучшее из российских), а есть издательства, которые делают не очень хорошие переводы, публикуют не лучшие отечественные труды и при этом активно продвигают себя как лучших помощников на пути становления тимлидом, менеджером проекта, ведущим разработчиком. Здесь помогает только внутренний фильтр: пролистать книгу, почитать отзывы, оценить важность контента.

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

Охотники за идеями


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

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

Акулы всего


Сложившаяся индустрия спасла множество специалистов, которые в силу своего образования были обречены на сомнительное будущее. Да, я говорю о наших ненаглядных антагонистах гуманитариях. Помнится, в 2002-2007 гг. абитуриенты уже поняли, к чему идёт дело, и боялись поступать на филфак, в иняз, в педагогический, полагая, что это сулит им безвыходное будущее. Но прошло менее 10 лет и все эти акулы пера и языка нашли себя в HR, переводческой среде ИТ (техписы, маркетологи, продажники), в копирайтинге (управление контентом, редактура блогов и блогов на контент-площадках), в event-менеджменте (организаторы многочисленных мероприятий), особо наглые и уверенные в себе пролезли в управление проектами. И это всё та же самая ИТ-сфера.

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

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

Глава 3. Войти в айти


Мнимая простота


Кажется, что работа в ИТ-сфере это просто. В самом деле, что такого-то? Во всех языках программирования очень ограниченное количество команд и вполне внятный синтаксис, задачи системного администратора тоже конечны, не говоря уж о тестировщиках подумаешь, пользоваться программой и искать баги. Именно так ты думаешь, когда идёшь на свой первый курс вуза или курс корпоративного университета для смены специальности. А спустя некоторое время ты же лежишь на клавиатуре и чуть не плачешь, потому что компилятор выдал 314 Errors, команда bash не существует, скрипт PowerShell делает не то или не делает ничего, а ты в довершение всего назначил всей аудитории 127.0.0.1 по DHCP. А дороги назад уже нет, и это только начало.


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

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

Увы, миф о простоте вхождения в ИТ будет расти и дальше, во многом благодаря многочисленным школам программирования, готовым за ваши же деньги и ваше время убедить вас в том, что вы уже труЪ кодер и заоблачная зарплата почти что зачислена на карту. Самое удивительное, что упомянутых HR-ов нередко восхищает наличие таких сертификатов, это работает по принципу ого, насколько мотивирован человек и как он заставил себя засесть за учёбу в свои 33. Я был свидетелем совершенно потрясающей истории, как парня с семилетним опытом работы в ИТ-проекте не взяли менеджером проектов в большую региональную ИТ-компанию, а отдали предпочтение девушке без единого дня опыта в ИТ, которая на собеседовании рассказала, что проходит курс JavaScript в одной из онлайн-школ. Курс она бросила, а работа с оплатой выше рынка осталась.

Кто хочет быть миллионером?


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


Да, программисты получают заработную плату выше, чем средняя по рынку, но и трудозатрат и способностей такая профессия требует несравнимо больше. Фактически это непрерывный, напряжённый интеллектуальный труд. Иначе хорошо не получится, получится ниже среднего во всех смыслах. Условно говоря, если вам сейчас 35, вы получаете 60-80 тыс. руб., работая менеджером по чему-нибудь, линейным руководителем или инженером, и вы решите перейти в айти (разработку), то к своему уровню заработной платы вы придёте через 2 года минимум. А эти два года вы будете учиться и стажироваться, как обычный junior.

К тому же, в профессии программиста, тестировщика или системного администратора (здесь и DevOps, и сетевики, и т.д.) нет ничего романтичного. Как только вы погрузитесь в работу, вы заметите, что всюду та же рутина, что и везде, только относится она уже к другим процессам. А до разнообразной и интересной должности тимлида, системного архитектора, проектировщика ПО ещё нужно дорасти и то при условии наличия у вас желания и возможностей это сделать.

Стартап, это фальстарт


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

  • Настоящие ИТ-стартапы компании, созданные небольшими командами, которые предлагают инновационные технологические продукты и разработки (например, приложения для слабовидящих, уникальные туристические гиды, медицинские устройства и т.д.). Они в меньшинстве, но интересные всем: и потребителям, и инвесторам и порой даже гос. структурам.
  • Новые ИТ-компании, которые не совсем стартапы обычные разработчики офисного ПО, игр, мобильных приложений. Ничего особо инновационного и интересного, но своё место на рынке находят. Таких больше, но всё равно не очень много.
  • Дети крупных корпораций и интеграторов, которые создаются для привлечения инвестиций, распределения рисков, снижения влияния сложившегося имиджа, продажи инвестору и т.д. У каждой такой компании свои цели и неплохое финансирование.
  • Конторы-дилеры различных вендоров офисного ПО, CRM-систем, CMS и т.д. партнёрские организации, которые берут готовый продукт, методику продвижения и пытаются выжить на рынке. Среди таких встречается совсем уж экзотика: студии растяжки и фитнеса продают CRM-системы, магазин товаров для детей пилит сайты на известной CMS и т.д. Это, конечно, не стартапы и не айти, но называют они себя именно так :-)

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

Глава 4. Что будет дальше?


Куда вырастет отрасль


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

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

Отрасли нужны все


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


Какая **** сделала этот запрос?!

Образование должно меняться


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

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

Технологии будут слабо меняться


Сегодня есть технологии практически для всего любая ваша идея легко обретёт свой технологический стек. Вряд ли что-то будет активно меняться в среде языков программирования, принципиально сдвинется в сетевой инфраструктуре, в вебе, в энтерпрайзе. Обученные сегодня программисты при относительно стабильном интересе к развитию своего стека будут востребованы и через 5 лет, и через 10 лет. К тому же, многие продукты ещё долго будут требовать поддержки и обслуживания (и да, сегодняшний современный, крутой и чистый код скорее всего через 10 лет будет геморройным легаси ;-) Подумать только!).

Технологии будут взрывно меняться


Всё, что касается мобильной разработки, нейросетей, искусственного интеллекта, VR/AR и IoT будет меняться с огромной скоростью. Многие современные реализации несовершенны и понятно, что разработка ищет новые пути, чтобы решить сложные задачи каждой из этих технологий. Развитие мобильной разработки будет определяться изменением форм-факторов гаджетов: гибкие экраны потребуют инноваций. Таким образом, в скором времени нас ждёт перелом в привычном стеке. Быть одним из первых в освоении новых методик по-настоящему перспективно, интересно и несомненно доходно.

IT станет попсой


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

Цикл возобновится


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

Перечитал текст мрачновато вышло В принципе, в будущее IT в частности и высоких технологий в целом я смотрю с огромным оптимизмом. При любых раскладах развития мировой политики и экономики (кроме уничтожения мира фантастика так фантастика даже по состоянию на июнь 2020) технологический шаг назад уже невозможен: всё больше элементов нашей повседневной жизни и трудовой деятельности будут базироваться на всё более продвинутых технологиях. Железо нужно будет проектировать, интерфейсы дизайнить, код писать в том или ином виде. Поэтому будет интересный рынок труда, будут разные зарплаты, будут запросы и будет спрос на всё, что сделано. IT-сфере жить и жить и я не буду говорить пафосных слов о том, что какой ей быть, определяем мы. Все мы люди и для нас работает вечная пирамида Маслоу, поэтому менять что-то за идею не получится только если очень локально. Но мы можем другое достойно и честно делать свою работу. Вот это реально определит состояние отрасли. А те, кто делают из отрасли поп-реалити-шоу, так и останутся мишурой. Они тоже просто делают свою работу.

Подискутируем?
Подробнее..

Scrum и Fixed Price в аутсорсинге совместить нельзя разделить

06.07.2020 12:10:38 | Автор: admin
Мало кто находит выход, некоторые не видят его, даже если найдут, а многие даже не ищут.
Из Алиса в стране чудес

В статье поднимаются следующие вопросы.

  1. О противоречивости компонентов аутсорсинговой формулы Scrum + Fixed Price.
  2. Об одной, из возможных, ошибке (корневой причине), предшествующей неверному выбору инструмента Scrum.
  3. Об одной ситуации, когда действительно стоит вопрос о совмещении Scrum и Fixed Price, требующий глубокого анализа и поиска компромиссов для ее разрешения.


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




Как говорилось в статье С чего начинается псевдо-Scrum в аутсорсинге, в большом количестве аутсорсинговых проектов, команды которых совмещают (или, не исключено, выдают желаемое за действительное) Scrum и Fixed Price, не верно идентифицирован жизненный цикл (ЖЦ) проекта. Т.е. совершена ошибка в выборе между итеративным инкрементным или гибким ЖЦ. И, как результат, не верно выбран управленческий инструмент фреймворк Scrum. И уже следствием этого выбора является возникновение ряда проблем, неверных выводов об Agile, Scrum и попыток (от слова пытка?) совместить эти два взаимоисключающих понятия.

Взаимоисключающих?!

Сейчас аргументирую.

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

Scrum + Fixed Price это то же самое, что идти одновременно вперед и назад?


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


При заключении контракта на оказание аутсорсинговых услуг клиент практически всегда настаивает на Fixed Price (схема под ключ). Его пожелание зафиксировать Product Scope (или объем работ), увидеть бюджет, сроки. Он хочет видеть, что покупает. На Time & Material клиенты соглашаются редко.

Таким образом, ключевой момент: потребность клиента зафиксировать в контракте, а провайдера услуг выполнить обязательства по контракту и гарантировать, что параметры будут неизменными с прогнозируемой погрешностью (в силу некоторой степени неопределенности и рисков на этапах продаж и заключения контракта) после начала разработки. Вопрос понижения степени неопределённости и рисков это вопросы возможности проведения и качества фазы Discovery (Pre-sale, диагностики) в отношении Product Scope.

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

Fixed Price просто обязывает нас поставить в приоритет управление планом. Иначе, зачем нам что-то фиксировать, заведомо зная, что оно изменится, и мы на самом деле не планируем этим управлять? Чтобы просто заключить контракт? Критическая ошибка устоявшихся процессов продаж: фиксируем, заведомо зная, что будем менять, лишь для того, чтобы подписать контракт!

Почему будем менять? Потому что Scrum это ведь всегда про неопределённость и ее результат изменения. Это про приоритет управления изменениями. И ведь не исключено, что они могут появиться уже после первого спринта. Почему?

Отступление о возможных причинах изменений

В чем может быть причина изменений? Она, например, может быть в некачественно проведенной фазе Discovery (Pre-sale, диагностики) в ситуации, когда Product Scope может быть определен в той или ной мере (для примера см. п. 3 из Case Study в статье), но по каким-то причинам этого не сделано. В таком случае, это проблема фазы и внутренних процессов, а не причина выбора Scrum для контракта с Fixed Price, гибкого ЖЦ вместо итеративного с целью компенсации допущенной ошибки.

Хотя, справедливости ради, отмечу, что в продажах (Pre-sale-активностях бизнес-аналитиков) в аутсорсинге (одна из самых проблемных фаз с точки зрения Product Scope!) не все так просто как в магазине, когда покупается готовый товар с конкретными свойствами (функциональностью). А фаза Discovery сложно продаваемая активность бизнес-аналитиков и команды. Но минимизация в той или иной степени неопределенности и оценка рисков одна из главных задач грамотно выстроенного процесса продаж. Как и формирование понимания у клиента о необходимости и важности этих активностей (бывает очень сложно!). Но для этого существует достаточное количество техник и инструментов. И это сводится к вопросу качества оказываемых услуг, а не продажи кота в мешке.

Другая причина может быть в невозможности определить Product Scope & Vision на текущий момент (для примера см. п. 2 из Case Study в статье). И это действительно очень непростая и невыгодная для обеих сторон ситуация, когда возникает серьезное противоречие и поднимается вопрос о совмещении Scrum и Fixed Price при оказании аутсорсинговых услуг. Она требует тщательного анализа, дополнительных действий по формированию всестороннего понимания клиента (зачастую технически и идеологически далекого от реалий процессов разработки) о возможных сложностях и рисках и поиску компромиссных решений.

Итак, почему же выбирается Scrum? Чтобы управлять изменениями, которые, например, возникают в результате неверно проведенной фазы Discovery (Pre-sale, диагностики) либо когда Product Scope не может быть определен на данной фазе? В первом случае, на мой взгляд, это ошибочно. Во втором сложно реализуемо при Fixed Price.

Третий возможный вариант выбора Scrum как инструмента Agile, гибкого ЖЦ вместо итеративного инкрементного в ситуации, когда Product Scope проработан и зафиксирован на фазе Discovery (Pre-sale, диагностики), а в контракте Fixed Price, тоже на мой взгляд не рационален: зачем выбирать инструмент для управления изменениями (уводить из фокуса явно более приоритетную вещь план), когда их вероятность минимизирована?

Возращение к главной мысли статьи.

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

Но контракт с Fixed Price задает приоритет в управлении планом!

Таким образом формула Scrum + Fixed Price трансформируется в управление изменениями + управление планом одновременно. Задача менеджера управлять в разных степенях и планом, и изменениями, но в приоритете может быть только что-то одно: либо план, либо изменения.

Либо управление планом, либо управление изменениями это, своего рода, аксиома, заложенная в основы менеджмента и бизнес-анализа. Она отражена в базовых (и не только) руководствах для менеджеров (PMBOK) и бизнес-аналитиков (BABOK). А классификация ЖЦ (и их идентификация в отношении конкретных проектов) опирается на нее: есть ЖЦ, предназначенные для управления планом (например, Waterfall, итеративные инкрементные (IID)) и гибкие, Agile для управления изменениями. Выбор ЖЦ (а в последствии и инструментов) строится из того, чему в управлении отдается приоритет.

Гибкий ЖЦ это разновидность итеративного инкрементного ЖЦ для проектов с определенными доминирующими признаками/особенностями (список контрольных вопросов приведен в вышеназванной статье), позволяющими идентифицировать его как отдельный ЖЦ и направить все силы на управление изменениями. К этим признакам могут быть отнесены: невозможность здесь и сейчас достичь некоторой степени определенности Product Scope (самое важное!), поиск бизнес-решения (или его быстрая поставка бизнесу для формирования обратной связи), которое выстрелит, формирование списка ключевых функций продукта (Key Features), короткие итерации, изменчивость, эксперимент, постепенное наращивание функционала, ретроспективы, совершенствование не только продукта, но и процессов с целью получить лучший вариант продукта. Возможно ли в таких условиях получить адекватные оценки бюджета и сроков?

Дьявол всего в одной детали или все дело в Product Scope


Во всем есть своя мораль, нужно только уметь ее найти!
Из Алиса в стране чудес

Что вы можете сказать об определенности (возможности ее установить) в отношении Product Scope & Vision на этапе продаж, фазы Discovery, на старте проекта в аутсорсинге?

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

Однако, для аутсорсинга данная ситуация значительно осложняется пожеланием клиента использовать схему Fixed Price при заключении контракта и предстает в невыгодном свете для обоих сторон. В какой-то мере с некоторыми допущениями можно достичь компромисса при заключении контракта и при управлении таким проектом. Важно сформировать правильное понимание и верные ожидания клиента (инвестора), оценить риски, рассмотреть по возможности иные схемы финансового взаимодействия, а в процессе реализации проекта постоянно работать с лояльностью клиента и т.д. Углубляться в вопрос не буду, так как он выходит за рамки статьи.

В аутсорсинге чаще всего вопрос в первую очередь заключается в грамотном проведении фазы Discovery (Pre-sale, диагностики) в отношении Product Scope и выборе верного ЖЦ. И если выбирается Agile и Scrum в ситуации, когда Product Scope зафиксировать можно (и тем более, когда этого не было сделано по каким-то причинам вовремя, с ожиданием/предположением его проработки в будущем), и при этом в контракте Fixed Price, на мой взгляд, совершается ошибка, которая ставит под сомнение положительный исход проекта.

Спасибо за внимание!
Подробнее..

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

22.06.2020 18:15:30 | Автор: admin
Перевод статьи подготовлен в преддверии старта курса Team Lead 2.0.



Как я отмечал в статье Why metrics dont matter in software development unless you pair them with business goals", выбор метрик нужно продумывать очень тщательно, чтобы дать ответы на вопросы, которые ставит перед собой бизнес. Вот эта критическая точка: измерения должны быть спроектированы так, чтобы отвечать на вопросы бизнеса. И эти вопросы никогда не будут звучать как Сколько у нас сейчас тысяч строк кода в проекте?

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

Начните с измерения правильных вещей


Здесь представлены 9 объективных показателей (или метрик), которые необходимо постоянно отслеживать, чтобы инкрементально улучшать процессы и производственную среду. Улучшение этих показателей не гарантирует, что уровень удовлетворенности ваших клиентов будет расти не по дням, а по часам. Однако, это те показатели, которые действительно нужно мониторить. В одном из последующих разделов Собираем все вместе, вы узнаете почему.

Метрики Agile-процесса


Для agile и lean-процессов основными метриками будут leadtime, cycle time, velocity команды, и open/close коэффициент. Эти показатели помогают в планировании и принятии решений по улучшению процессов. Несмотря на то, что они не измеряют успешность или добавочную ценность, не имеют ничего общего с объективным качеством программного обеспечения, вам все равно нужно их отслеживать. Ниже я объясню почему.

  • Leadtime время, которое проходит от появления идеи до поставки программного обеспечения. Если вы хотите быстрее реагировать на нужды своих клиентов, работайте над уменьшением leadtime, зачастую посредством упрощения процесса принятия решений и сокращения времени ожидания. Leadtime включает в себя cycle time.
  • Сycle time количество времени, которое требуется на внесение изменений в систему ПО и доставку этих изменений на продакшн. Команды, использующие continuous delivery, могут измерять cycle time в минутах или даже секундах вместо месяцев.
  • Velocity команды количество единиц программного обеспечения, которое команда обычно выполняет в одну итерацию (спринт). Это число следует использовать только для планирования итераций. Сравнивать команды по показателю velocity идея бессмысленная, поскольку метрика основана на необъективных оценках. Рассматривать velocity как показатель успешности тоже бесполезно, да и постановка цели вроде придерживаться определенной velocity искажает ценность этой метрики для мероприятий по оценке и планированию.
  • open/close коэффициент количество появившихся и закрытых issue в единицу времени. Общая тенденция будет иметь большее значение, чем конкретные цифры.

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

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

Аналитика продакшена


  • Средняя наработка на отказ (Mean time between failures, MTBF)
  • Среднее время восстановления (Mean time to recover/repair, MTTR)

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

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

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

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

Помимо MTBF и MTTR, более точные метрики основаны на отдельных транзакциях, приложениях и т.д., и они отражают доставленную бизнес-ценность, а также стоимость устранения сбоев. Если ваше приложение для обработки транзакций падает один раз из ста, но при этом поднимается через 1-2 секунды без критических потерь информации, то и с частотой сбоев в 1% можно жить. Но если с такой частотой падает приложение, которое обрабатывает 100 000 транзакций в день, теряет по 100$ за сбой и восстановление стоит 50$, то исправление этого 1% будет в приоритете. И такое исправление в итоге сильно повлияет на итоговую ситуацию.

Метрики безопасности


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

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

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

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

Вы найдете больше способов применения метрик безопасности в разработке программного обеспечения в статьях Application Security for Agile Projects и Security Threat Models: An Agile Introduction.

Заметка о метриках исходного кода


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

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

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

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

Соберем все вместе: Успех универсальная метрика


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

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


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

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

Разве не все у всех проектов есть некоторый набор инвариантных целей, вопросов и гипотез, а следовательно, и метрик?

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

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

Как сформулировать ценностную гипотезу


Ценностная гипотеза это утверждение о том, что, по вашему мнению, произойдет в результате добавления определенной функции. Взаимосвязь между программным обеспечением, желаемым результатом и метриками формирует ценностную гипотезу для функции (или системы, истории, обновления и т.д.). Гипотеза должна выражать ожидаемое изменение целевой метрики в течение определённого промежутка времени, а также понятие о ее эффективности. Вам нужно будет поговорить с командой и с Product Owner-ом, чтобы как минимум выяснить, что именно это функция или история может создать или улучшить применительно к бизнесу, чтобы сформулировать относительно нее ценностную гипотезу. Возможно, задать вопрос почему вам придется несколько раз (как ребенку), чтобы избавиться от невысказанных предположений, поэтому будьте терпеливы. Когда вы поймете, какой должна быть ценность для бизнеса, вы можете начать задавать вопросы, которые приведут вас к метрикам, дающим на них ответы.

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

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

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

Шесть эвристик для эффективного использования метрик


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

  1. Метрики не расскажут вам всю историю, а вот команда расскажет (снимаю шляпу перед Тоддом Декапула);
  2. Сравнивать снежинки это бесполезная трата времени.
  3. Вы можете измерить практически все, но не всему можете уделить внимание.
  4. Метрики успеха бизнеса способствуют улучшению программного обеспечения, а не наоборот.
  5. Каждая функция добавляет ценность, измеряете вы ее или нет.
  6. Измеряйте только те показатели, которые имеют значение в данный конкретный момент.

Еще





Узнать подробнее о курсе
Подробнее..

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

02.07.2020 16:18:36 | Автор: admin
Весна 2020 показала, что благодаря DevOps-практикам многие бизнесы смогли быстро перестроить продукты и перейти в онлайн, сохранив работоспособность. Оказалось, что от зрелости практик DevOps зависят не только результаты бизнеса, но и само его выживание.

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

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



Основные измеряемые характеристики DevOps это стабильность работы приложений и производительность IT-команд, от идеи до выкладки фичи на продакшн. Поэтому мы много говорим о time to market и мониторинге и продолжаем технический трек.

А ещё IT-команды состоят из живых людей, которые не только могут выдавать хорошие KPI, а ещё и делают заведомо полезную работу. Ведь если DevOps-подход завоевал популярность в мире, то, наверное, это кому-то нужно. Для вас мы повстречались с Product Owners и бизнесменами, которые не всегда знают, что такое DevOps (как будто мы знаем :D) и расспросили их о том, что же им важно получить от технарей. В чём эта самая польза.

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

Вот какие гипотезы мы проверяли на встречах:

  • TTM важен для интересов Product Owner-а.
  • Стабильность работы приложения влияет на бизнесовые показатели.
  • Разработчики зачастую не согласны с мнением PO о том, что и как делать.
  • TTM помогает проводить CustDev. Речь не о технике интервью, а о поиске и подтверждении потребностей клиентов и построении компании.

Я беседую через с Zoom со своей давней знакомой, которая убеждена, что человеку, который ни разу в жизни не продавал, нечего делать в профессии Product Owner. Она часто появляется в передачах на радио и ТВ, проводит семинары по своей предметной области. Как только режим самоизоляции был облегчён, они с мужем и ребёнком арендовали дом на берегу великолепного озера и на всё лето переехали жить и работать туда. Её компания почти 20 лет на рынке онлайн-услуг. На первом месте по рейтингам в своей предметной области.

Скажи пожалуйста, проводишь ли ты специальную работу по сокращению цикла разработки и запуска фич в продакшн в своей команде?

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

Погоди, 6 часов?! Это...

От первой беседы с командой до пользователя. Т.е. уже на проде.

Зачем тебе такая скорость?

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

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

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

Внезапно я стал экспертом по удалёнке этой весной! (смеётся)

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

Когда мы с техдиром начали эту работу, ещё не были в ходу такие термины, как LTV, customer retention или unit economy. Просто мы представили, что пользователи не очень довольны падением приложения 20% времени...

Во, NPS!

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

Тебе именно это отношение важно?

Мне важен рост аудитории. Т.е. её лояльность и приверженность к моему продукту.

Что-то ещё? Как маркетинг связан с аптаймом?

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

Т.е. для тебя сейчас важно, чтобы приложение было доступно.

Сейчас я спокоен, потому что наш аптайм 4,5 девятки. В течение месяца приложение исправно отвечает на 99,995% запросов.

DevOps сделал своё дело, DevOps может...

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

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

Да, из палок и синей изоленты. (Игорь морщится, потому что я на громкой связи, а рядом дети)

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

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

Значит ли это, что за оставшиеся полгода ребята будут уже 40% времени заниматься рефакторингом, изменением архитектуры и выпиливанием костылей, а также работать с производительностью приложения?

Абсолютно.

Дальше Игорь рассказал, что у него появилась возможность работать на опережение. Значительная часть задач направлена на освоение новых технологий и интерфейсов. Первые результаты экспериментов уже доступны пользователям, например общение на естественном языке. При этом на сегодняшний день скорее можно говорить о Research части R&D. Компания осваивает технологии заранее, чтобы использовать момент зрелости технологий искусственного интеллекта для получения конкурентного преимущества.

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

  • Продуктовые. Product owner может включить или отключить фичу, а также раскатать её на заданный процент пользователей или даже конкретный список.
  • Настройки взаимодействия сервисов это зона ответственности разработчиков.
  • Админские, их крутит команда, которая занимается инфраструктурой.

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

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

Мы обнаружили, что находки нашего исследования подтверждают те выводы, которые есть в в отчете Google The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling (версия на русском).

Мы выделили четыре основные ценности для Product Owner-ов при использовании DevOps:

  • Предсказуемость времени реализации фичи и уверенность в качестве софта это необходимая база для активных экспериментов.
  • Надёжность работы прода = деньги. Когда трафик попадает на работающее приложение, то это не только позволяет рационально использовать бюджет на продвижение, но ещё и повышает лояльность пользователей, а значит и долю на рынке.
  • Скорость экспериментов определяет успех как для стартапа, так и для бизнеса со зрелым продуктом. Если стартапу важно быстро обнаружить предпочтения пользователей и удачные ответы на них, то зрелому продукту нужно удержание пользователей, стабильность массовой выручки и research работа на будущее технологий.
  • Доверие к разработчикам и взаимное доверие разработчиков к продакту. Партнёрские отношения между IT подразделением и бизнес юнитами, когда заключается контракт о способах взаимодействия и этот договор исполняют обе стороны. В терминах DevOps это управление техдолгом, поддержка кода в порядке и вовлечение команды в интерес своих пользователей.

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

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

Большинство активностей на конференции сделаем интерактивными, потому что говорящих голов достаточно в интернете. Ведь каждый сознательный инженер может не только найти видео докладов по нужной ему тематике, но и прочитать статьи (например, статьи по следам всех DevOpsConf в профиле Александра Титова).

Наша цель этой осенью дать каждой компании возможность высадить виртуальный десант из Product Owner-ов, техлидов и инженеров всех мастей. Так, чтобы IT-спецназ сориентировался на местности и вернулся в работу с разработанным планом захвата Вселенной!

В следующих статьях расскажем про CTO, разработчиков и безопасников зачем конференция им.
DevOps Live пройдет онлайн 29-30 сентября и 6-7 октября 2020. В онлайне будет всё, за что сообщество любит наши конференции, и при этом мы вместе исследуем новые возможности онлайна.

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

Из песочницы Как определить функционал MVP и влюбить клиента в пилотную версию продукта

04.07.2020 00:19:48 | Автор: admin

Итак, MVP. Достаточно заезженная тема, на мой взгляд. Каждый, кто хоть как-то связывал себя с разработкой программного обеспечения за последние 5 лет, с 99% вероятностью слышал эти 3 буквы. Но даже несмотря на обилие информации, народ все равно наступает на грабли идеального продукта при создании проектов.


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


Начну с вирусной зарисовки пути развития стартапа по принципу MVP, которая гуляет по интернету и которую вы наверняка встречали.


image


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


Разберем?


Верхняя строка ничего общего с MVP не имеет. Это понятно. На ней изображен классический цикл разработки. Автор использовал его как преувеличение ради контекста в примере ниже. Разумеется, ни о каком минимально жизнеспособном продукте на первом этапе с колесом речи и быть не может. Продукт прошел 3 стадии разработки (колеса, кузов, двигатель), прежде чем смог выполнить свое предназначение ехать.


Но и вторая строка, на мой взгляд, также не совсем корректно отображает принцип MVP.


Почему мое внутреннее понимание минимально жизнеспособного продукта не сходится с такой концепцией? Если предположить, что она отражает путь разработки какого-то продукта, становится очевидно, что он претерпел 4 коренных перестройки. В итоге его создатели получили три группы товарно-родовых конкурентов: 1 скейт-самокат-велосипед; 2 мотоцикл; 3 автомобиль.


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


У автомобиля более широкий охват: пожилые и молодые люди, те, кто путешествует в одиночку или в компании, кто ездит на работу или мотается в другой город им нужна скорость, комфортное размещение и езда при любых погодных условиях. Скейт предназначен исключительно для одного человека, чаще ребенка или подростка, да и цель езды носит больше развлекательный характер. Аудитория скейта воспримет в штыки перспективу трансформации продукта в машину, которой нужно топливо, дорогостоящее ТО и возраст 17+, не говоря уже о цене самого автомобиля. А те, кому нужна машина, изначально не обратят на ваш самокат никакого внимания. Да, каждый из этих продуктов может иметь MVP, но они не являются MVP друг для друга.


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


А эта переосмысленная версия MVP мне больше пришлась по душе:


image


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


Что завернуть в MVP, чтобы его захотели попробовать?


С концепцией MVP разобрались. Теперь поговорим о том, как определить начинку пилотного продукта, приоритезировать функционал и сделать первую версию продукта востребованной.


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


image


Принцип Парето


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


MVP = обязательно + просто


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


  1. Сложно это или легко для реализации?
  2. Желательно это или обязательно для пользователя?

image


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


Формула Rice Score


Еще один эффективный метод приоритезации идей и фич для MVP. Вам нужно оценить каждую функцию по четырем факторам и подставить значения в простую формулу.


  • Охват скольким пользователям вы улучшите жизнь?
    (Оцените в течение определенного периода времени и берите цифры из метрик, а не с потолка)
  • Влияние насколько вы улучшите жизнь пользователям?
    (Очень сильно = 3х, сильно = 2х, хорошо = 1х, слабо = 0,5х, совсем немного = 0,25х)
  • Уверенность насколько вы уверены, что гипотеза окажется верна и продукт выстрелит?
    (100% = высокая уверенность, подтвержденная опросами или исследованиями, 80% = средняя уверенность, 50% = слабая уверенность, 50% и ниже = много сомнений)
  • Усилия сколько человеко-часов, человеко-дней или просто дней уйдет на реализацию?
    (1 человеко-день = это день работы одного разработчика)

Рассчитайте оценку для каждой фичи, согласно формуле:


image


Вместо итога


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

Подробнее..

Метод Jobs To Be Done как решать задачи пользователей с помощью продуктов?

03.07.2020 14:20:11 | Автор: admin
Если вы смотрели выпуск Вдудя про кремниевую долину, то понимаете, что в год там рождается огромное количество новых стартапов или идей продуктов. И это только малая часть всего мира. Но лишь небольшой процент из них придет к успеху.

image

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

Знакомьтесь, теория Jobs To Be Done она позволяет копнуть глубоко в сознание потребителей и понять, что движет ими при совершении покупки. На выходе вы имеете продукт, который решает задачу своего владельца, а не просто нашпигован разным крутым функционалом.

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

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

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

Кому может помочь JTBD?


У теории нет ограничений по областям применения. Вы можете быть маркетологом, разработчиком, SMM-специалистом на фрилансе используйте JTBD, чтобы сделать продукт/услугу, которая решает задачи потребителя. Например, вы сммщик. Спросите у клиента, почему он решил обратиться к специалисту? Допустим чтобы не тратить на это свое время. То есть, клиент хочет тратить время на что-то другое более важное, так он чувствует себя лучше. То есть вам нужно построить процесс своих СММ-услуг так, чтобы клиент был минимально вовлечен, но получал хороший результат. Маркетологам теория найма продукта на работу дает огромное поле возможностей. Даже после пары интервью может выясниться, что ваш продукт идеально отвечает на задачи потребителей. Но вы не транслируете это в рекламной коммуникации, поэтому продажи падают.
Вернемся к любимому пылесосу девушка хочет чувствовать себя хорошей хозяйкой в глазах свекрови и ваш продукт помогает в этом. Но в рекламе вы делаете акцент на 10-видах насадок, уровне мощности продукта и тд. Можно сместить фокус и сказать, что все эти преимущества помогут быстро убрать квартиру перед приходом свекрови. И вот вы уже решили задачу клиента.

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

Инструменты и подходы JTBD


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

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

Job Story


Сформировать гипотезу для исследования поможет метод Job Story. Его придумала компания Intercom, поэтому все подробности есть в их книге. В сокращенном варианте job story это предложение, построенное по принципу: Когда ___, я хочу ____, чтобы____

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

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

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

Интервью


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

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

Найти неочевидных конкурентов


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

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

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

Понять мотивации потребителей


В целом, на этом строиться вся теория Jobs To Be Done. Мы рассматриваем не процесс использования продукта, а момент, когда появилась в нем необходимость. То есть, что привело к мысли о покупке.

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

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

Пример:
Антон хочет купить новое приложение для тренировок. Ему не нравится, что в старом преподает только один тренер (1 фактор), а в новом разные тренера и бесплатный подбор питания (2 фактор). Но он переживает, что упражнения в новом приложении ему не понравятся/не получатся (3 фактор), все-таки в старом он уже все пробовал и отработал технику (4 фактор).

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

Определение вектора дальнейшего развития


Выяснить, в какую сторону компании стоит развиваться, поможет сравнение предполагаемой job story и реальной. У компании Intercom для этого есть отличный пример.

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

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

Ключевые моменты JTBD интервью


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

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

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

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

Катализаторы


  • Когда вы впервые начали искать что-то, чтобы решить вашу проблему?
  • Где вы были?
  • Вы были с кем-то? Что они сказали?
  • Что заставило вас задуматься об этом?

Момент покупки


  • Когда вы приобрели продукт?
  • Где вы были?
  • В какое время дня это было? (днем / ночью?)
  • Кто-нибудь еще был с вами в то время?
  • Как вы приобрели продукт?

Поиск решений


  • Расскажите мне, как вы искали продукт для решения вашей проблемы.
  • Какие решения вы пробовали/не пробовали? Почему?

Эмоции


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

  • Каким был разговор, когда вы говорили о покупке продукта со своим <супругом / другом / родителями>?
  • До того, как вы приобрели, представляли, как будет выглядеть продукт? Где ты был, когда думал об этом?
  • Были ли у вас беспокойства по поводу покупки?
  • Вы слышали что-то о продукте, который заставил вас нервничать? Что это было? Почему это заставило вас нервничать?

Резюмируем


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

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

Главный инструмент JTBD интервью с пользователями. Но прежде чем его провести, необходимо обозначить цель исследования и сделать несколько гипотез job story.
Job story то, как потребитель нанял продукт на работу. Она строится по схеме: Когда __, я хочу __, чтобы __

Главный плюс подхода Jobs To Be Done в том, что он фокусируется не на продукте, а на решении задач своих пользователей. Это и помогает перевести задачи из режима to do в статус done.

Ещё больше тонкостей работы маркетолога вы узнаете на нашем шестимесячном онлайн-курсе Профессия: Интернет-маркетолог. Узнать подробности!

Подробнее..

Из песочницы О важности исследований на старте проекта

25.06.2020 20:11:16 | Автор: admin
Привет! Меня зовут Стася, я UX-lead Центра Развития Финансовых Технологий в Россельхозбанке.
Наша команда разрабатывает экосистему для микро, малых и средних фермерских хозяйств, цель которой объединить в одном месте все услуги и товары, которые необходимы фермерам.

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

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

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

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

Кейс 1. Пакетные предложения


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

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

Первый вариант пакетных предложений:


Результат

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

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

Кейс 2. Формирование пула сервисов для MVP1


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

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

На основе получившегося списка мы составили первую карту сервисов и снова отправились в поля.

Теперь мы строили интервью вокруг нашей карты: давали ее фермерам и просили отметить наиболее интересные направления и зачеркнуть наиболее неинтересные; затем просили объяснить свой выбор.


Результат

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

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

  • Маркетплейс с товарами для с/х производителей
  • Подбор персонала
  • Новости агросектора
  • Подборщик культур

Кейс 3. Тестирование прототипа сервиса для подбора персонала


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

Самая первая версия страницы резюме выглядела так:


В процессе тестирования мы выяснили:

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

Результат

Исходя из результатов исследования, мы внесли следующие изменения:

  • Переработали карточку резюме и отошли от традиционной концепции, когда есть название резюме (оно же название желаемой должности) и, второстепенно существует список навыков кандидата (как, например, реализовано на hh). Мы вынесли навыки на видное место в поисковой выдаче и на странице резюме, а также добавили функцию поиска по навыкам.
  • Добавили возможность для работодателя указать наличие жилья и условия проживания; для соискателя указать потребность в жилье на время работы.
  • Добавили возможность при создании резюме указать количество человек, которые ищут работу. А также добавили фильтр для работодателя теперь фермер сразу может указать, какое количество персонала ему необходимо.

Переработанная карточка резюме:


Кейс 4. Тестирование прототипа сервиса Новости


Неожиданные инсайты обнаружились даже при тестировании, казалось бы, довольно простого в реализации новостного сервиса.

Первая версия сервиса выглядела так:


Мы выяснили следующее:

  • Главная страница нашего новостного портала не цепляла выглядела как обычный новостной сайт, где обычно не публикуются аграрные новости.
  • Фермеры интересуются новостями (даже должны быть в курсе новостей, чтобы не пропустить новых законов и изменений), но редко располагают временем, чтобы их читать. Они постоянно на бегу и часто у них нет даже пары минут, чтобы полистать ленту в соц. сетях или новостной сайт, в отличие от городских жителей, которые могут выкроить на это время, например, пока спускаются в лифте или стоят в очереди.
  • Из-за образа жизни на бегу, вся жизнь фермера сосредоточена в смартфоне. Соответственно картина фермер читает новости с компьютера явно нереалистична.
  • Опять же, из-за недостатка времени, есть потребность в том, чтобы максимально быстро узнать новости по нужной тематике. Бесконечные ленты новостей совсем не впечатлили наших практичных и рациональных пользователей :)

Результат

Что поменяли после переработки главной страницы новостного портала:

  • Ввели гибкую систем тегов, которые выполняют сразу несколько функций: 1. Показывают, что на портале освещаются актуальные именно для фермеров темы новостей; 2. Дают возможность быстро создать нужную выборку новостей по интересующей теме.
  • Почистили страницу, сделали ее более четкой и лаконичной, убрали большие картинки.
  • Чтобы фермеры могли не тратить время на чтение всей ленты новостей добавили быстрый фильтр по популярности Часто читают, содержащий все главные агроновости за последний месяц.

Новый вид новостного портала:

Подробнее..

Из песочницы Разбор UIUX на примере прототипа в Figma и основные принципы

24.06.2020 16:09:31 | Автор: admin

Кому адресована статья


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

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

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

Вместо введения


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

image

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

То что написано выше относится к любому виду продукта, как физическому, так и электронному. Далее мы будем говорить о прототипах в сфере ИТ (сайты, приложения, корпоративные информационные системы и т.д.), определим, что такое UI и UX, какием критериям должен отвечать прототип в продуктовой разработке, рассмотрим некоторые особенности среды для создания прототипов Figma.

Что такое прототип ИТ продукта? Каким он должен быть?


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

image

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

Основные принципы прототипирования:

  1. Прототип создается только после того как определена целевая аудитория, маркетинговая стратегия, каналы сбыта.
  2. В прототипе должны быть учтены основные пользовательские сценарии. При тестировании хорошей идеей является озвучить задачу и отойти подальше от пользователя. Если у последнего в ходе использования прототипа возникают множественные вопросы, то это означает, что необходимо пересмотреть и переработать сценарии использования.
  3. Прототип является интерактивной моделью, так как он направлен на проверку возможных действия пользователя, а не на согласование картинки.
  4. В основе любого прототипа должна лежать гипотеза, которую необходимо проверить. Необходимо сформулируйте гипотезу так, чтобы на нее можно было четко ответить да или нет и прописать, как именно прототип даст вам ответ на этот вопрос.
  5. При тестировании прототипа необходимо давать минимум информации потенциальному пользователю. Причина проста чем больше он наломает дров, тем лучше для продукта, так надо тестировать, а не валидировать сценарии.
  6. Проверять все, даже если есть уверенность в том или ином функционале будущего продукта.
  7. Дизайн прототипа должен быть максимально лаконичным без отвлекающих внимание пользователя ярких картинок, цветовых акцентов или перечеркнутых квадратов. Конечно, если они не являются частью проверяемой гипотезы. В этом случае, есть риск того, что пользователь зациклится на наполнении визуального интерфейса.
  8. Если есть возможность сделать прототип похожим на реальность, то именно так и стоит сделать.
  9. При тестировании необходимо просить пользователя проговаривать вслух все мысли и действия и вести видеозапись самого процесса тестирования.

image

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

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

Что такое UI/UX?


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

image

Так, что же представляют собой UI и UX дизайн?

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

UX или User Experience переводится как пользовательский опыт. То есть это про то, как работать с интерфейсом, удается ли пользователю достичь цели, легко это или сложно. UX дизайнер перекладывает клиентский опыт на интерфейс, строит и проверяет гипотезы взаимодействия пользователя с системой.

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

image

Связь прототипа и UX/UI дизайна


Является ли прототип информационной системы UX/UI дизайном? На мой взгляд, является.
Является ли UI/UX дизайн прототипом? Да, но только в случае, если бизнес логика наложена на интерфейс пользователя тем или иным способом. Если пользовательский опыт описан где-то на бумажке и его невозможно продемонстрировать клиенту на интерфейсе, то у нас есть отдельно UI и UX дизайны, но прототип отсутствует.

image

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

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

Но, что будет, если убрать экспериментатора и оставить пользователя наедине с листами бумаги? Останется UX/UI дизайн, а прототип работать не будет. А значит, будет невозможно протестировать логику работы системы.

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


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

Инструмент


Описание


inVision, Marvel, Flinto
Позволяют указать по клику, на какую область одного макета страницы
нужно отобразить другую.
Prott, POP
Самые простые инструменты для быстрой проверки гипотез. Достаточно нарисовать скетчи карандашом, сфотографировать и указать области, при нажатии на которые необходимо перейти на следующую страницу.
Proto.io, Framer, Origami, Form
На основе макетов страниц позволяют анимировать отдельные объекты (слои) и делать более сложные и интересные переходы.
Axure, Wireframe
При создании прототипа используются простые фигуры и ссылки на макеты, если их много.При создании прототипа используются простые фигуры и ссылки на макеты, если их много.
Webflow, Figma
По факту являются конструкторами сайтов. С их помощью можно создать первую версию продукта. Отлично подходят для прототипирования в случаях, когда вам нужно сильно больше, чем переходы между статичными экранами.
Wix, WordPress, Tilda
Конструкторы сайтов. Удобные инструменты для создания рабочих прототипов людьми, непосредственно взаимодействующими с клиентом, без привлечения профессиональных UX и UI дизайнеров.

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

Что такое Figma?


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

Плюсы и минусы Figma


К плюсам работы в Figma можно отнести:

  1. Бесплатна в случае, если над проектом работают не более 2х пользователей.
  2. Создание и отрисовка макета в одной программе
  3. Существует огромное количество уже готовых шаблонов сайтов
  4. Для работы с Figma требуется свежая версия браузера, а десктопная версия не требует мощного и современного компьютера.
  5. Сохранение версий проекта до 30 дней на бесплатной версии

Минусы Figma:

  1. Отсутствие русификации. Работать в Figma приходится на английском языке.
  2. Figma не работает оффлайн, так как требуется синхронизация с облаком.

Пример создания простейшего прототипа в Figma


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

Шаг 1. Регистрация


Не обязательно регистрировать отдельный аккаунт в Figma. Если у Вас есть Google-почта, то можно зайти в сервис с ее помощью. При первичном открытии Figma сразу предложит пройти краткое обучение работы с программой.

Шаг 2. Создание проекта


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

Шаг 3. Создание рабочей области страницы


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

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

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

image

Шаг 4. Добавление картинки


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

image

Шаг 5. Добавление текстового поля


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

image

Шаг 6. Создание меню


В данной статье я не преследую научить читателя всем аспектам работы с Figma, поэтому меню у нас будет самое простое двухкнопочное. Кнопки представляют собой прямоугольники, объединенные с текстовым полем. Можно объединить объекты в группу, нажав CTRL+G, а потом отцентрировать текстовое поле по центру будущих кнопок.

Шаг 7. Дублирование основы страницы


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

image

Шаг 8. Добавление внешних ссылок


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

image

Шаг 9. Добавление ссылок между страницами


Добавление ссылок на объекты внутри Figma аналогично добавлению ссылок на внешние источники за исключением того, что надо где-то взять ссылку на внутренний объект. Для этого надо кликнуть правой кнопкой мыши по объекту и выбрать в выпадающем меню Copy/Paste и Copy Link.

image

Шаг 10. Демонстрация прототипа


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

image

Результат


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

Видеоуроки по реализации прототипов в FIGMA


В качестве заключения хочу приложить ссылку на видеоуроки, созданные телеграмм-каналом Наука и дизайн. Всего 2,5 часа в 15ти уроках по использованию FIGMA, в которых рассмотрены все основные функции и кнопки.

Еще хороший ресурс с видеоуроками по созданию прототипов в Figma.
Подробнее..

SCRUM стоит ли прогибаться под изменчивый мир?

02.07.2020 14:05:51 | Автор: admin
Scrum методология гибкой работы команды. На сегодняшний день пользуется большой популярностью, применяется во многих крупных компаниях. В этой статье разберемся, когда и при каких обстоятельствах возникла техника, на каких базовых принципах строится ее реализация, что важно учитывать при работе и многое другое.

image

История появления Scrum


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

  • определение требований к проекту;
  • планирование операций от начала и до конца;
  • написание кода;
  • тестирование.

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

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

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

  1. Люди важнее инструментов.
  2. Качество продукта важнее документации.
  3. Взаимодействие с заказчиком важнее контракта.
  4. Готовность к изменениям важнее установленного плана.

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

  1. Главное хорошее ПО и довольный заказчик.
  2. Готовность к изменениям в любой момент.
  3. Добиваться работающего ПО по итогам разработки как можно чаще.
  4. Встреча команды лучше всего для обмена информацией.
  5. Заказчик и команда разработки должны работать вместе.
  6. Доверять людям делать свою работу.
  7. Есть рабочее ПО есть прогресс.
  8. Гибкие процессы непрерывное развитие.
  9. Внимание к качеству способствует гибкости.
  10. Простота процесса позволяет не делать лишней работы.
  11. Самоорганизующаяся команда лучше работает.
  12. Постоянное стремление к большей эффективности.

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

В 2001 году они детально описали принципы своей методологии и выпустили книгу Agile Software Development with SCRUM. На сегодняшний день этот подход считается одним из самых популярных среди разработчиков.

Базовые принципы Scrum


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

Базовые принципы Scrum:

  1. Работа короткими циклами (спринтами). Проект делится на части (спринты) и реализуется поэтапно. Спринт длится до момента окончания работы над определенной частью продукта.
  2. Гибкость. После окончания каждого спринта проводится тестирование. При наличии ошибок меняется стратегия реализации или пересматривается список текущих задач (бэклог) по продукту.
  3. Пользователи и заказчик участвуют в разработке. В любой скрам-команде есть владелец продукта заказчик или его представитель. Через него команда взаимодействует с пользователями, которые участвуют в тестировании проекта по окончанию каждого спринта. Владелец продукта собирает фидбэк, передает команде и на основе этих данных принимаются решения по дальнейшему развитию.
  4. Взаимодействие команды. Scrum-team это несколько человек, которые взаимодействуют друг с другом и стремятся к достижению общей цели.


Scrum-команда


Scrum-команда в большинстве случае состоит из 5-9 человек, реже из 3-4. В рамках скрама коллектив не может быть больше, потому что усложняется взаимодействие между каждым звеном, что негативно сказывается на эффективности работы.
Состав

В команде есть три основные роли:

  1. Владелец продукта (Product Owner).
  2. Скрам-мастер (Scrum Master).
  3. Разработчики (Delivery Team).

Рассмотрим все роли подробнее.

Владелец продукта


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

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

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

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

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

Скрам-мастер


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

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

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

Примерный перечень обязанностей скрам-мастера:

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

Разработчики


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

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

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

Примерный перечень команды разработчиков:

  • оценка элементов бэклога продукта;
  • разработка продукта и предоставление его заказчику;
  • отслеживание своего прогресса (совместно со скрам-мастером);
  • предоставление результата владельцу продукта.

Принципы работы Scrum-команды


Успешная работа по методологии Scrum возможна при соблюдении трех принципов:

  1. Постоянное самосовершенствование. Опытные разработчики рассказывают, что совершенствование продукта, доведение до идеального состояние невозможно без самосовершенствования каждого члена команды.
  2. Автономность. Все сотрудники должны отвечать не только за общий результат и уметь работать в коллективе, но и выполнять многие обязанности индивидуально.
  3. Кросс-функциональность. Любая команда самодостаточна, так как в нее входят специалисты с разными навыками.

Процесс работы Scrum-команды


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

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

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

2. Проведение регулярных совещаний. Ежедневно или еженедельно команда проводит короткие совещания (не более 15-30 минут). В них участвуют владелец продукта, скрам-мастер и все разработчики. Цель встреч получить от каждого ответы на три вопроса:

  1. Что сделано с момента прошлой встречи?
  2. Какие планы на сегодня?
  3. Есть ли препятствия к достижению цели?

Scrum-мастер в ходе совещания выявляет текущие проблемы и помогает команде решить их.

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

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

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

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

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

Артефакты Scrum


Scrum-проекты включают в себя три важных документа, их еще называют артефактами:

  1. Журнал продукта (Product Backlog).
  2. Журнал спринта (Sprint Backlog).
  3. График спринта (Burndown Chart).

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

Журнал продукта


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

Бэклог продукта должен включать в себя не только технические аспекты, необходимые для реализации, но и функциональные. Для каждого требования определяется приоритет (например, от 1 до 5). Самые приоритетные описываются детально, чтобы команда смогла оценить их и протестировать.

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

Журнал спринта


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

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

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

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

График спринта


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

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

Как правильно внедрить Scrum-методологию


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

Если вы решились на изменения, проводите внедрение поэтапно:

  1. Соберите команду. Основной шаг, от которого зависит успех продукта в будущем. Подбирайте квалифицированных специалистов, имеющих практический опыт в своей сфере. Не жалейте времени и помните: сбор кросс-функциональной команды непростая задача.
  2. Назначьте владельца продукта. Эту роль отдайте заказчику или его представителю. Важно, чтобы человек имел опыт работы в этом направлении, так как от него зависит взаимодействие внутри команды и между заказчиком.
  3. Выберите скрам-мастера. Найдите человека, который хорошо знаком с методологией и имеет практический опыт ее внедрения в команду разработчиков. От него зависит, насколько комфортно будет протекать реализация нового продукта.
  4. Создайте список требований к продукту. Обдумайте требования к проекту. Желательно, чтобы в обсуждениях участвовал весь коллектив. Это позволит определить самые важные моменты. Должно получиться что-то вроде технического задания, которое направит разработку в нужное русло.
  5. Запланируйте спринты. Разделите разработку на несколько мелких и последовательных этапов. Изначально уделите внимание только первым итерациям. Не стоит планировать сразу всю реализацию, так как впоследствии потребуется внесение правок.
  6. Анализируйте и оценивайте результаты. После окончания каждого спринта проводите анализ и оценивайте результаты. К следующему этапу разработки приступайте только при полной удовлетворенности итогами предыдущего.

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

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

Подведем итоги


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

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

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

Ещё больше о методологиях эффективной работы команды вы узнаете, если запишетесь на наш шестимесячный онлайн-курс Профессия: Продакт! Узнать подробности!

Подробнее..

MVP что это такое и как работает?

30.06.2020 12:04:28 | Автор: admin
Читая новости про новые проекты и сервисы, вы могли часто сталкиваться с понятием MVP. Но что скрывается под этой аббревиатурой и почему MVP так часто используют на начальных этапах развития продукта? Давайте прямо сейчас вместе разберемся в этом.

Что собой представляет MVP


image

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

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

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

Полезность разработки MVP доказывают примеры крупных на данный момент компаний. Например, Даниэль Эк и Мартин Лорентсон в 2006 году запустили небольшой сервис с одной функцией потоковая передача музыки. Сегодня их продукт Spotify оценивается в $21 миллиард, сотрудничает с крупными звукозаписывающими студиями и имеет 50 миллионов человек активной аудитории.

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

MVP и PoC одно и то же?


Proof of Concept (PoC) доказательство правильности концепции и некоторые новички часто путают его с минимально жизнеспособным продуктом. PoC описывает процессы выяснения технической жизнеспособности концепции программного обеспечения (или любого другого продукта).

Да, эти определения взаимосвязаны, но не взаимозаменяемые. Proof of Concept описание процессов на начальной стадии развития продуктов, которые потом реализуются фактически, из чего получается MVP.

Виды MVP


image

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

MVP Флинстоуна


image

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

Изначально у этого подхода было много критиков, мол, как можно что-то проверить, если ничего нет? Состоятельность метода доказал Ник Свинмерн основатель интернет-магазина Zappos, стоимость которого в 2015 году пробила отметку в $2 миллиарда.

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

Консьерж MVP


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

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

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

Разрозненный MVP


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

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

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

Продукт с одним параметром


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

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

Когда и для чего нужно делать MVP?


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

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

Как сделать MVP правильно


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

Нулевой этап: определяем основные принципы создания MVP


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

В ходе общего собрания обсудите следующие вопросы:

  1. Как потратить минимум ресурсов? Помните, что на MVP должно быть потрачено минимум времени и сил. Вместе с командой разберитесь, как потратить мало денег, но при этом провести эффективное тестирование бизнес-идеи. Как правило, обсуждение этого вопроса помогает выбрать функции для реализации на начальном этапе развития продукта.
  2. Как взаимодействовать с пользователями? Одна из главных целей создания MVP тестирование гипотез, определение спроса и востребованности продукта. В этом помогает обратная связь от первых пользователей продукта. Чтобы не упустить ни капли важной информации, заранее продумайте все каналы взаимодействия с целевой аудиторией: отзывы, опросы, прямые интервью и т.п.
  3. Как сделать первые продажи продукта? Первые продажи продукта дадут средства для начала разработки и покажут, интересна ли кому-то разработанная концепция. Хороший вариант организовать сбор средств (предпродажи) на краудфандинговой площадке Kickstarter (международная), Boomstarter (Россия), Planeta (Россия) и т.п.
  4. Как будем продвигать продукт? На старте планируйте рекламную кампанию и используемые каналы. Основные инструменты контекстная реклама Яндекс и Google. Далее осваивайте социальные сети Facebook, ВКонтакте и Instagram. Создайте официальные страницы, запустите таргетинг. Кстати, брендированные сообщества один из каналов сбора обратной связи. Разработайте продающий лендинг: опишите продукт, расскажите о функциях, пользе для клиента, дайте пользователям возможность выбора между платной и бесплатной версиями продукта. После обсуждения этого вопросы вы должны знать, по каким каналам будете продвигаться и сколько денег потратите.

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

Первый этап: поиск проблемы, которую решит MVP


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

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

Второй этап: находим целевую аудиторию


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

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

Не торопитесь на этом этапе! Лучше потратить несколько часов для формирования портрета ЦА, чем потом слить весь рекламный бюджет и получить минимальную конверсию. И не забывайте про то, какую проблему решает MVP (это определяется на первом этапе).

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

  • 25-34 лет;
  • мужчины;
  • 40 000-80 000 рублей в месяц;
  • хотят погасить кредиты, накопить денежные средства, повысить качество жизни;
  • пользуются ПК и смартфон;
  • испытывают нехватка заработной платы до конца месяца.

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

Третий этап: определяем основных конкурентов


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

Эту гипотезу подтверждает история с разработкой радио. В России считают, что его изобрел Александр Попов, а вот в Италии лавры отдают Гульельмо Маркони. Оба начали работать над реализацией идеи в 1894 году, но Попов свою разработку презентовал в марте 1896 года (но при этом не запатентовал), а Маркони в июне 1896 года подал документ на патент. Кстати, есть еще несколько ученых в разных странах, которые также претендуют на звание создатель Радио.

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

  1. Соберите максимум информации об основных конкурентах. Проанализируйте трех самых крупных игроков рынка: изучите историю развития, посмотрите предлагаемые продукты, ознакомьтесь с конкурентными преимуществами и оцените способность предложить что-то лучше.
  2. Определите рыночные доли основных конкурентов. Рассмотрите деятельность компаний со всех сторон, определите их стратегии, объемы продаж, рассчитайте рентабельность и т.п. Так вы поймете, насколько они успешны и как можно опередить их в конкурентной борьбе (а главное, сколько на это придется потратить ресурсов).
  3. Изучите первичные источники информации. Все, что публикуют конкуренты о своей деятельности, первичные источники данных. Поэтому посмотрите их официальные сайты, презентации, белые книги, годовые отчеты, рекламные материалы и т.п. Это поможет разобрать деятельность конкурентов по кирпичикам и даст новые идеи для развития продукта.
  4. Изучите вторичные источники информации. Новости, видео, обзоры, интервью, оценки и т.п. вторичные источники информации. Их публикуют СМИ, независимые отраслевые сайты и многие другие. Сбор информации из вторичных источников поможет глубже понять выбранную отрасль и изучить правила игры. Но при этом не забывайте, что далеко не все дают достоверную информацию.
  5. Посетите отраслевые мероприятия. Ваши конкуренты презентуют продукцию или услуги на конференциях, выставках и любых других подходящих для этого площадках. Чтобы собрать максимум информации и задать интересующие вопросы, посещайте такие мероприятия. В большинстве случаев они бесплатны, поэтому потратить придется только свободное время.

В сборе информации помогут специальные аналитические инструменты: Similar Web, Ahrefs, Quantcast, App Annie, AppFollow и другие. Соберите данные о популярности конкурентов, ежемесячном трафике, основных интересах целевой аудитории, географическом расположении клиентов и т.п.

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

Четвертый этап: проводим SWOT-анализ


SWOT-анализ представляет собой таблицу, состоящую из четырех блоков:

  • сильные стороны;
  • слабые стороны;
  • возможности;
  • угрозы.

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

image

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

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

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

Пятый этап: создаем карту пути пользователя


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

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

Кстати, не забывайте корректировать карту пути пользователя (user flow) после получения обратной связи от первых клиентов. Они расскажут, что хорошо, а что плохо или неудобно. На основе этого корректируйте карту, чтобы конечный потребитель получал то, что хочет.

Например, для сервиса по финансовому планированию сделали такую карту:

  • выбор периода планирования;
  • добавление активов, пассивов, доходов и расходов;
  • аналитика финансового плана;
  • постановка целей и отслеживание прогресса достижений.

Провели первые тестирования, за два месяца в поддержку написали несколько человек: у нас были финансовые планы в Excel, пришлось потратить часа два, чтобы все данные перенести в ваш сервис. Что делаем? Правильно! Добавляем функцию экспорта существующих в Excel финансовых планов.

Шестой этап: составляем перечень функций продукта


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

image

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

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

Дальше расставьте все функции по приоритету. Самые востребованные (которыми пользуются чаще всего) ставим в начало списка, редко используемые в конец. Должна получиться вот такая карта:
image

Седьмой этап: определяем функции MVP


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

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

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

image

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

Восьмой этап: выберите метод управления и разработки


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

  • Lean.
  • Scrum.
  • Канбан.
  • Экстремальное программирование (XP).

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

Девятый этап: проводите тестирования


Тестируйте MVP короткими итерациями: альфа- и бета-тестированием. Альфа внутренний этап: закончили разработку, пользуйтесь продуктом внутри команды несколько дней. Если все окей, запускайте бета-тестирование внешний этап, дайте доступ к проекту первым пользователям. Длительность: 7-14 дней.

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

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

Еще раз поговорим всю последовательность этапов:

  1. Определение основных принципов создания MVP.
  2. Поиск проблемы, которую решит MVP.
  3. Поиск целевой аудитории.
  4. Определение и анализ основных конкурентов.
  5. Проведение SWOT-анализа.
  6. Создание карты пути пользователя.
  7. Составление перечня функций продукта.
  8. Определение объема MVP.
  9. Выбор метода управления и разработки.
  10. Проведение тестирований.

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

Самые распространенные ошибки при создании MVP


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

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

Попытки достигнуть идеала


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

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

Небрежная работа


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

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

Отсутствие обратной связи


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

Пустые обещания


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

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

Отказ от анализа и аналитики


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

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

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

Ещё больше о MVP можно узнать на нашем годовом курсе Профессия: Продакт (с 0 до PRO) Узнать подробности

Подробнее..

Бизнес-модель Остервальдера что это такое?

01.07.2020 12:12:44 | Автор: admin
Стратегическое планирование важно для каждого бизнеса. Один из самых популярных инструментов бизнес-модель Остервальдера. Он простой и эффективный, подходит как для развивающихся, так и уже давно работающих компаний. В этой статье поговорим о истории появления модели и подробно разберем каждый блок.

image


Что такое бизнес-модель Остервальдера?


Бизнес-модель Остервальдера (Business Model Canvas) инструмент стратегического управления, используемый для описания бизнес-моделей новых или уже работающих предприятий. Представляет собой схему из 9 блоков, описывающих разные бизнес-процессы организации.

Модель создали Александр Остервальдер и Ив Пинье. Подробное описание схемы они дали в книге Alexander Osterwalder & Yves Pigneur: The Business Model Generation.

Работающие фирмы используют модель для поиска новых точек роста, анализа конкурентов и определения лучших практик развития бизнеса. Существует заблуждение, что инструмент применяют в стартапах и маленьких фирмах, но на самом деле его используют такие гиганты, как IBM, Ericsson, Deloitte и многие другие.

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

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

Что нужно сделать перед построением бизнес-моделей?


Перед составлением первой бизнес модели сделайте следующее:

  1. Проанализируйте разные направления деятельности. Регистрируясь в качестве индивидуального предпринимателя, создавая компанию или планируя новый продукт, выбирают несколько видов деятельностей. Как правило, исходят из планов на будущее: чем планируют заниматься. На этом этапе подумайте, в каких сферах будете работать с наибольшей долей вероятности.
  2. Выберите приоритетное направление. Из обилия рассматриваемых сфер деятельности выберите приоритетную ту, от которой планируете получать большую часть прибыли. Вокруг нее выстраивайте долгосрочную стратегию развития бизнеса.
  3. Составьте ассортимент предлагаемой продукции. Проанализируйте рынок, узнайте, какие товары пользуются спросом, а какие продаются плохо. Для достижения наиболее эффективного результата рассматривайте первую группу продукции, от второй откажитесь.
  4. Продумайте и сформируйте рекламную стратегию, выберите инструменты продвижения продукции и методы конкурентной борьбы. Подумайте о маркетинговой стратегии: как продвигать товар на рынке, кому продавать (ваша целевая аудитория), на какие конкурентные преимущества обращать внимание клиентов, чтобы обойти конкурентов и т.д.

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

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

Как заполнять бизнес-модель Остервальдера?


image

Модель состоит из 9 блоков:

  1. Потребительские сегменты.
  2. Ценностные предложения.
  3. Каналы сбыта.
  4. Отношения с клиентами.
  5. Потоки доходов.
  6. Ключевые ресурсы.
  7. Ключевые виды деятельности.
  8. Ключевые партнеры.
  9. Структура издержек.

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

Потребительские сегменты (Customer Segments)


image

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

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

В заполнении блока помогут ответы на вопросы:

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

Ценностные предложения (Value propositions)


image

Определите, почему потребители должны покупать ваш продукт (товар, услугу), а не обращаться к конкуренту. Ценностное предложение должно решать какую-то проблему клиента или закрывать одну из потребностей. Как правило, оно представляет собой совокупность товаров или услуг для конкретного сегмента.

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

В заполнении блока помогут ответы на вопросы:

  • Какую ценность мы предоставляем потребителям?
  • Какие проблемы помогаем им решить?
  • Какие потребности удовлетворяем?
  • Из чего состоит продукт/товар/услуга?

Каналы сбыта (Channels)


image

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

  • Информирование. Как доносится до потребителя ценностное предложение?
  • Оценка. Как позиционируется продукт на фоне конкурентов?
  • Продажа. Как происходит продажа?
  • Доставка и адаптация. Какими методами осуществляется доставка до клиента и формирование первого позитивного впечатления о товаре?
  • Обслуживание. Как обеспечивается послепродажное обслуживание?

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

В заполнении блока помогут ответы на вопросы:

  • Какие каналы взаимодействия позволят пообщаться с нашими клиентами?
  • Как мы взаимодействуем с ними сейчас?
  • Какие из них наиболее эффективны?
  • Какие наиболее выгодны?

Отношения с клиентами (Customer relationships)


image

Отношения с клиентами методы взаимодействия с потребителями. Подумайте, как вы строите общение с целевой аудиторией? И строите ли вообще? Выделяют несколько типов взаимоотношений с клиентами:

  • персональная поддержка;
  • самообслуживание;
  • бесплатное или условно-бесплатное пользование;
  • совместное создание;
  • индивидуальное или групповое обучение.

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

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

То есть сначала определить текущие задачи, а затем думайте о типе отношений с клиентами и как с ними взаимодействовать.

В заполнении блока помогут ответы на вопросы:

  • Каких отношений ждут клиенты?
  • Какие отношения есть сейчас?
  • Почему отношения стали такими?
  • Сходятся ли они с текущей бизнес-моделью?

Потоки доходов (Revenue streams)


image

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

  • Продажа товаров. Самый популярный источник заработка компаний. Сводится к продаже товара/продукта конечному потребителю, дилерским сетям и т.п.
  • Плата за использование услуги. Клиент пользуется услугой и платит за время или объем. Например, создание сайта в соответствии с техническим заданием. Организация определяет необходимое количество времени для выполнения заказа, исходя из этого формируется конечная стоимость.
  • Оплата подписки. Фиксированная плата за использование чего-либо на протяжении определенного промежутка времени. Например, месячная подписка за доступ к онлайн-кинотеатру.
  • Аренда. Временное использование актива по фиксированной ставке без уплаты его полной стоимости. Например, дата-центр сдает в аренду сервера. Потребитель не платит полную стоимость оборудования, а лишь некоторую часть в зависимости от срока использования.
  • Лицензия. Доход возникает в результате временной передачи клиенту интеллектуальной собственности.
  • Комиссия. Бизнес выступает в роли посредника и получает за это определенную комиссию. Например, площадка для продажи сайтов взимает 3% от суммы каждой сделки за то, что выступает в роли гаранта и защищает обе стороны от мошенничества.
  • Реклама. Продажа целевой аудитории рекламодателям. Например, размещение рекламных баннеров на страницах сайта.

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

В заполнении блока помогут ответы на вопросы:

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

Ключевые ресурсы (Key resources)


image

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

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

Ориентируйтесь на 4 популярные категории активов:

  • Материальные ресурсы. Физические объекты сырье, станки, транспортные средства, недвижимость, точки продаж и т.п.
  • Интеллектуальные ресурсы. Знания технологии, патенты, программный код, бренды, товарные знаки и т.п.
  • Персонал. Люди маркетологи, менеджеры, программисты, механики, столяры, маляры и т.п. Те, кто отвечают за создание продуктов, оказание услуг, производство.
  • Финансы. Деньги оборотные средства, кредиты, инвестиции и т.п.

В заполнении блока помогут ответы на вопросы:

  • Какие ресурсы нужны для создания и реализации ценностных предложений? Отношения с намиши клиентами? Каналы сбыта?

Ключевые деятельности (Key activities)


image

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

Упростим задачу описанием классификаций основных видов деятельности:

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

В заполнении блока помогут ответы на вопросы:

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

Ключевые партнёры (Key partners)


image

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

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

В заполнении блока помогут ответы на вопросы:

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

Структура издержек (Cost structure)


image

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

Дополнительно разделите издержки на фиксированные (которые не зависят от объемов производства) и фиксированные (которые зависят от объемов производства).

В заполнении блока помогут ответы на вопросы:

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

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

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

Ещё больше информации о бизнес-моделях можно узнать на нашем шестимесячном онлайн-курсе Профессия: Продакт! Узнать подробности

Подробнее..

Recovery mode Техника определения MVP

02.07.2020 12:23:15 | Автор: admin

Привет!


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


Для всех кто готов мирится с сыроватостью идеи, добро пожаловать под кат)


Введение


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


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


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


Критерии


Критериями для задачи определения MVP функциональности являются критерии, взятые из методологии WSJF а также дополнительная декомпозиция Job Duration на составляющие:


Cost of delay


  • User-Business Value: Насколько громко просят об это пользователи? Как это отразится в деньгах, если эта штука НЕ будет сделана? Какой потенциально негативный эффект будет, если это выполнить позже, а не раньше?
  • Time Criticality: Как это влияет на общий поток поставки? Задерживает ли реализацию чего-то еще? Нужно ли это выпустить к определенной дате? Есть ли риск того, что опоздание с этим умножит на ноль весь смысл проделанной работы?
  • Risk Reduction: Снижает ли это какие-то риски? Будет ли это позитивно влиять на качество в других областях? Будет ли эффект сиюминутным или долгосрочным?
  • Opportunity Enablement: Откроет ли эта штука новые возможности для продукта или всего бизнеса? Поможет ли выйти на новые рынки сбыта/привлечь других клиентов?

Job Duration


  • Job Duration Оценка времени на реализацию, производится по предварительному анализу Features с участием Тех Лидера команды разработки или Архитектора. Выполняется верхнеуровнево, без декомпозиции Features на более низкие уровни
  • Job Complexity- Оценка сложности реализации, выполняется совместно с Тим Лидером команды разработки индивидуально, с учетом опыта и навыков команды, которая работает над данным продуктом. Данная оценка также включает в себя оценку степени неопределенности Features, которая в свою очередь прямо пропорционально влияет на сложность этих самых Features.
  • Job Cost Оценка стоимости реализации, высчитывается исходя из необходимых человеко-часов на определенную задачу, и перемножения его на стоимость человеко-часа в команде. Данная оценка является относительной и не подлежит для использования в расчетах стоимости реализации продукта, и нужна только для приоритизации бэклога.

Процесс оценки


Оценка выполняется с помощью числового ряда Фиббоначи от 1 до 21. (1, 3, 5, 8, 13, 21). Данный способ оценки универсален с точки зрения использования его при оценке задач в Story Points при планировании, и для групповой оценки критериев также возможно использования Scrum-poker.


Также, оценка с помощью ряда Фиббоначи обусловлена тем, что каждый шаг значений увеличивается не линейно, а значит будет сложнее сложить все в одну оценку. Так же чувствуется разброс, например сразу видна разница в бизнес ценности между задачей в 3 и 21 Story Points.
Оценки по критериям из группы Jobs Duration выполняются командой разработки, а оценки по группе критериев Cost Of Delay только с привлечение бизнес-заказчика и Владельца Продукта.


Итогом оценки будет матрица следующего вида:




Сведение задачи определения MVP к решению задачи многокритериальной оптимизации.


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


Для свертывания критериев в суперкритерий необходимо также проставить весовые коэффициенты:



Для бизнес критериев и критериев разработки необходимо устанавливать отдельные весовые коэффициенты.


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


Cost Of Delay = User-Business Valuek11+ Time Criticalityk12+ Risk Reductionk13+ Opportunity Enablementk14
Jobs Duration = Job Durationk21+ Job Complexityk22+ Job Cost*k23
K11+K12+K13+K14=1
K21+K22+K23=1
Общий критерий оптимизации (Mutual Criteria) = Cost of Delay/Jobs Duration.


Таким образом мы получаем матрицу следующего вида:



Итоговой целевой функцией является Максимизация по Mutual Criteria.


Определение MVP Функциональности с помощью ABC анализа.


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


ABC-анализ анализ бэклога (набора Features) путём деления на три категории:


А наиболее ценные, 20% от количества; 80% удовлетворения потребностей
В промежуточные, 30% от количества; 15% удовлетворения потребностей
С наименее ценные, 50% от количества; 5% удовлетворения потребностей


Группа А является группой функциональности входящей в MVP.


По сути, ABC-анализ это ранжирование бэклога по разным параметрам. Результатом АВС анализа является группировка объектов по степени влияния на общий результат.


АВС-анализ основывается на принципе дисбаланса, при проведении которого строится график зависимости совокупного эффекта от количества элементов. Такой график называется кривой Парето, кривой Лоренца или ABC-кривой. Таким образом, 20% функциональности, закрывают 80% потребностей. Исходя из данного принципа, производим АВС анализ для бэклога, для определения MVP.


Для этого:


  1. Определяем цель анализа Ранжирование Бэклога для определения первых 20% функциональности, из которой будет сформирован MVP.
  2. Объект анализа Набор Features из бэклога.
  3. Берем перечень функциональности, ранжированный по многокритериальной модели (MC).
  4. Разделяем ранжир на 2 класса первые 20% (A), оставшиеся 80% (B+C).
  5. Первый класс (A) определяет MVP.

Важное замечание: Необходимо также учитывать CORE функциональность. Группа А может совпадать c CORE, но в случае не совпадения, результаты АВС анализа должны быть дополнены Core функциональностью.


CORE функциональность это основа функционирования продукта, которая состоит из функциональности, без которой функционирование продукта невозможно. (Например, авторизации).


Выводы


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

Подробнее..

Где продакту найти ментора?

02.07.2020 14:05:51 | Автор: admin
Начинающим продактам часто не хватает совета от более опытного коллеги. Ценную информацию можно получить на курсах и от наставников, но это разовое мероприятие, которое не поможет принять верное решение в форс-мажорных ситуациях.

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

image

Кто такой ментор?


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

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

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

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

Никогда не путайте ментора со следующими специалистами:

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

Для чего нужен ментор?


Менторство начало набирать популярность с развитием стартапов. Ведь что такое стартап по сути? Это предприимчивый человек с идеей и (в большинстве случаев) отсутствием какого-либо бизнес-опыта или специального образования. Он знает что, но понятия не имеет как.

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

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

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

Нужен ли мне ментор, если я уже 3 года работаю продактом?


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

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

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

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

Сколько стоят услуги ментора?


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

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

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

Где найти ментора?


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

А вот несколько мест, до которых можно сузить круг поиска:

  • Бизнес-акселераторы. Хорошие проекты всегда привлекают внимание. Используйте акселератор в качестве трамплина: подготовьте презентацию и покажите ее сразу сотне потенциальных менторов. Как минимум, один из ста заинтересует точно.
  • Профессиональные сообщества. Развитие продакт-менеджера невозможно без участия в тематических мероприятиях. Посещайте конференции, выставки, форумы и т.п. Будьте активным участником и тогда заинтересуете более опытного коллегу.
  • Специальные площадки. Существуют специальные онлайн-сервисы (например, www.my-mentor.ru), которые помогают встречаться менторам и наставникам. Площадка открывает возможность пообщаться с большим количеством опытных продактов и выбрать того, с кем найден общий язык.
  • Курсы. Проходя обучающие программы, можно после завершения обучения попросить одного из преподавателей стать ментором. Например, в ProductStar за каждым учеником закреплен преподаватель, к которому в любой момент можно обратиться с вопросом или просьбой.
  • Список продуктовых компаний. Сбор всевозможных организаций, занимающихся созданием проектов, помогает найти контакты опытных продакт-менеджеров. Далее личный диалог через Facebook или LinkedIn с предложением стать ментором.

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

Настя Костюшкина
Product Manager, SplitMetrics


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

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

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

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

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

Хочешь найти ментора? Записывайся на наш шестимесячный онлайн-курс Профессия: Продакт! Узнать подробности!

Подробнее..

Что такое Lean Canvas?

03.07.2020 12:17:33 | Автор: admin
Продакт-менеджеры, планирующие запуск нового продукта, не всегда понимают его до конца и не могут грамотно презентовать другим. Тогда берутся за составление большой презентации с кучей графиков и текста в PowerPoint. Но нужно ли тратить на это время, если в первую очередь понять суть проекта надо самому?

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

image

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

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

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

История появления Lean Canvas


Модель разработали не с нуля. Эш Маурьей адаптировала ее с модели Bussiness Model Canvas, разработанной Александром Остервальдом. При адаптации Эш руководствовалась бережливым подходом.

Если вы посмотрите на Bussiness Model Canvas, то увидите очевидные сходства. Но этот инструмент больше подходит для инвесторов, а не создателей новых проектов. Основная разница между ними заключается в четырех блоках.

Суть Lean Canvas


Lean Canvas таблица на 9 блоков. За каждым закреплено определенное значение. Ее можно нарисовать на бумаге или в какой-нибудь программе (например, miro.com/templates/lean-canvas) на компьютере.

image

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

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

Как правильно заполнить таблицу?


Давайте детально рассмотрим каждый блок. Это поможет вам при заполнении Lean Canvas для своего продукта. Но сначала важное уточнение: не торопитесь и не пытайтесь заполнить блоки за 15-20 минут. Лучше соберитесь всей командой (если она есть) и устройте мозговой штурм. Тогда заполнение займет несколько часов, но и результат получите соответствующий.

Блок 1. Определяем целевую аудиторию


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

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

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

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

Блок 2. Проблема и альтернативные решения


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

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

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

Блок 3. Уникальная ценность продукта


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

Заполнить этот блок поможет уникальное торговое предложение (УТП). Уникальная ценность продукта должна быть описана кратко и четко (до 140 символов).

Блок 4. Как продукт решит проблемы


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

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

Блок 5. Способы продвижения


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

Блок 6. Как продукт принесет доход


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

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

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

Блок 7. На что тратим деньги


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

Блок 8. Ключевые показатели


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

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

Блок 9. Скрытое преимущество


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

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

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

Еще более подробно про работу с Lean Canvas мы рассказываем на нашем шестимесячном онлайн-курсе Профессия: Продакт-менеджер. Узнать подробности!

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru