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

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

Появится ли Porsche у хакспейса? Интервью с Пашей Жовнером богомолом, который стал миллионером

05.09.2020 12:21:57 | Автор: admin

21 августа мы поговорили в прямом эфире с Павлом Жовнером. В прошлом месяце zhovner со своей командой запустил на кикстартере тамагочи для хакеров Flipper Zero.

Целью было $60 000, но меньше, чем за сутки, флиппер собрал миллион долларов, а к финалу собранные деньги приблизились к отметке $5 млн.

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




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

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

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

А по кому именно?


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

У меня была подруга-модель. Она всегда была гадким утенком


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

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

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

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

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

А синдром самозванца после того, как ты увидел на счету три миллиона долларов, уже прошел?


И на какой сумме он прошел?

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

Ты говорил, что на самом деле softskills гораздо важнее профессиональных навыков


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

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

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

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

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

А какую роль ты выполняешь? Саша Кулагин супер-организатор, а что делаешь ты?


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

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

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

Звучит так, как будто ты мечтатель


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

А богомолам можно под горячую воду?


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

Я имела ввиду, что ты богомол


:)

Расскажи, чему ты научился за этот год


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

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

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

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

Из практических навыков, например, в Altium могу крутить платы. Но это не так интересно.

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

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


Так получилось.

А что ты думаешь про Хабр?


Это провокационный вопрос.

Ну, нам же нужны острые темы


Я люблю Хабр. Чисто технически, это лучшая площадка из всех, что сейчас существует. Можно посмотреть на разные зарубежные платформы. Slashdot это что-то тяжеленное, перегруженное, я не понимаю, как там вообще кто-то сидит. Medium херня, там нет даже комментариев, в один экран текста влезает одна картинка, сверху и снизу приложение это для кого сделано, для брутальных свиборгов? Reddit это просто ссылки на другие ресурсы, там нет лонгридов, нет нормальных комментариев, куда можно было бы вставить картинку. То есть, по какой-то необъяснимой причине других задротских коллективных блогов такого уровня, как Хабр, не было создано.

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

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

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

То есть, если бы была функция предложения pull request в статью, от этого бы выиграли все. Конечно, автор должен быть жив, чтобы его принять. Мне часто пишут, что у меня в статье от какого-то 201Х года есть неактуальная информация, но я туда даже не захожу, я не могу постоянно перелопачивать старые статьи и поддерживать их в актуальном состоянии. А вот сообщество могло бы это делать. Если бы мне могли присылать pull request по старым статьям, чтобы я их принимал, было бы круто. Было бы что-то среднее с вики-движками.

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

Все-таки обошел все острые углы :) Как тебе аудитория Хабра? Тебе нравится там общаться в комментариях?


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

Ну, я как бы не $100, чтобы нравиться всем.

Ты как арахисовая паста, тебя либо обожают, либо ненавидят. Как такого достичь?


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

Люди мне постоянно пишут, что я работаю на Кремль, Израиль и почему-то MI-6. Это льстит. В Twitter мне писали, что вы сейчас своим Flipper переформатируете поп-культуру и всё будет такое же я ответил, что мне очень лестно, что кто-то считает мои поделки такими влиятельными. Ну Хейтеры, чмоки :)

Еще вопрос про деньги. У вас не было денег, когда вы начинали, а теперь стало очень много


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

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

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

Это можно проследить в очень многих вещах. Например, есть ребята, чья культура мне достаточно близка: разные GNUтые красноглазые товарищи, поклонники open source, которые считают, что деньги убивают всё нужна только швабодка!

Но, к сожалению, те штуки, которые выходят из-под их пера, невозможно нормально использовать. Например, можно взять Desktop Linux, посмотреть на KDE, GNOME; еще недавно был open source-ноутбук на Crowd Supply во-от такая по толщине байда с торчащими проводами. Или мессенджер Jabber XMPP это дерьмо же! Пишешь в одно место, сообщения приходят на компьютер, но не приходят на телефон, надо выставлять посылку на телефон. И так с любой opensource-поделкой, которую как бы делает комьюнити без денег сравните с тем, как Павел Дуров со своими миллионами денег за пару лет выдал продукт, на десятилетия опережающий все остальные.

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

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

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

Ну, ты же откуда-то взял профессионалов, которые инвестировали свое время в эту идею? Как это делается?


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

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


Это же ты их мотивировал, Flipper Zero это твоя мечта. Ты их собрал вокруг себя в хакспейсе.

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

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

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


Через 8 минут.

Это было потрясающе. Я радовалась, как будто мой ребенок в космос полетел


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

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


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

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

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

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

А как это? Если бы все умели генерировать маленькие победы из ничего, то у всех бы не было никаких проблем


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

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

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

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


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

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

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

То есть, ты себе даже Porscheне купишь?


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

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

Я буду следить за наличием Porsche у хакспейса :)


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

Напоминаем вам о двух вещах:

  • На тариф Turbo действует скидка 54% и можно еще получить сверху 10%, если вы хабровчанин.
  • Паша и его команда ищет новых разработчиков, чтобы делать флиппер вместе.



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
  14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM

Подробнее..

Елена Мышенкова о курсе Продакт-менеджер от ProductStar

09.09.2020 14:04:11 | Автор: admin

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

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

Елена Мышенкова

Кем вы работаете?

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

А что из этого, по-вашему, относится к продакт-менеджменту?

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

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

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

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

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

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

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

Как долго вы работали в этой области до прохождения курса?

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

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

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

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

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

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

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

Оставляй заявку на наш годовой курс Профессия: Продакт-менеджер и прокачивай свои навыки ? Узнать подробности!

Подробнее..

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

17.09.2020 10:15:44 | Автор: admin
Некоторое время назад мы закончили строить процесс безопасной разработки на базе нашего анализатора кода приложений в одной из крупнейших российских ритейловых компаний. Не скроем, этот опыт был трудным, долгим и дал мощнейший рывок для развития как самого инструмента, так и компетенций нашей команды разработки по реализации таких проектов. Хотим поделиться с вами этим опытом в серии статей о том, как это происходило на практике, на какие грабли мы наступали, как выходили из положения, что это дало заказчику и нам на выходе. В общем, расскажем о самом мясе внедрения. Сегодня речь пойдет о безопасной разработке порталов и мобильных приложений ритейлера.


Для начала в целом про проект. Мы выстроили процесс безопасной разработки в крупной торговой компании, в которой ИТ-подразделение имеет огромный штат сотрудников и разделено на множество направлений, минимально коррелирующих между собой. Условно эти направления можно разделить на 3 основные группы. Первая, очень большая группа, это кассовое ПО, которое написано преимущественно на языке Java (90% проектов). Вторая, самая обширная с точки зрения объема кода группа систем это SAP-приложения. И наконец, третий блок представлял собой сборную солянку из порталов и мобильных приложений: разного рода внешние сайты для клиентов компании, мобильные приложения к этим сайтам, а также внутренние ресурсы мобильные приложения и веб-порталы для персонала ритейлера.

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

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

Но, как всегда, из любого правила бывают исключения: общий подход не везде мог быть применен as is по ряду причин. Во-первых, наш инструмент (анализатор кода) имеет несколько ограничений, обусловленных тем, что мы хотим иметь возможность при необходимости делать наиболее глубокий анализ некоторых языков программирования. Так, в случае с Java анализ по байткоду гораздо более глубокий, чем по исходному коду. Соответственно, для сканирования Java-проектов требовалась предварительная сборка байткода и лишь затем его отправка на анализ. В случае с C++, Objective C и приложениями для iOS анализатор встраивался в процесс на этапе сборки. Также мы должны были учесть различные индивидуальные требования со стороны разработчиков всех проектов. Ниже расскажем, как мы выстроили процесс для порталов и мобильных приложений.

Порталы и мобильные приложения


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

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

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

Интеграция по стандартной схеме


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


Настройка интеграции с GitLab

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

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

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


Настройка интеграции с Jira

В редких случаях тим-лиды сами смотрели результаты сканирования и заводили задачи в Jira вручную.


Создание задачи в Jira

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

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


Результаты анализа и созданные в Jira задачи на исправление уязвимостей

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

Нестандартное в стандартном


В этом, на первый взгляд, не таком уж и сложном процессе имелось два серьезных ограничения. Во-первых, для анализа Android-приложений (то есть написанных на Java) нам нужна была сборка. А во-вторых, для iOS нужны были машины с MacOS, на которых устанавливался бы наш агент и имелась бы среда, которая позволяла бы собирать приложения. С Android-приложениями мы разобрались довольно просто: написали свои части в уже имеющиеся у разработчиков скрипты, которые запускались так же по расписанию. Наши части скриптов предварительно запускали сборку проекта в наиболее широкой конфигурации, которая направлялась в Solar appScreener на анализ. Для проверки же iOS-приложений мы устанавливали на Mac-машину наш MacOS-агент, который производил сборку кода и так же через GitLab CI отправлял код в анализатор на сканирование. Далее, как и в случае с другими видами ПО, офицер безопасности просматривал результаты анализа, верифицировал их и заводил задачи на исправления в Jira.

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

В тех проектах, где не было CI/CD, что было обязательным для нас условием, мы просто говорили: Ребята, хотите анализировать собирайте в ручном режиме и загружайте в сканер сами. Если у вас нет Java или JVM-подобных языков Scala, Kotlin и прочих, то можете просто загружать код в репозиторий по ссылке, и все будет хорошо.

Сложности проекта


Как видно из вышесказанного, в этом стеке приложений основной проблемой было отсутствие во многих проектах CI/CD. Разработчики часто делали сборки вручную. Мы начали интеграцию нашего анализатора с порталов Sharepoint на языке C#. Сейчас C# более-менее перешел на Linux-системы, хотя и не совсем полноценные. А когда проект был в самом разгаре, этот язык еще работал на Windows, и нам приходилось ставить агент на Windows для GitLab. Это было настоящим испытанием, поскольку наши специалисты привыкли использовать Linux-команды. Необходимы были особенные решения, например, в каких-то случаях нужно было указывать полный путь до exe-файла, в каких-то нет, что-то надо было заэкранировать и т.п. И уже после реализации интеграции c Sharepoint команда проекта мобильного приложения на PHP сказала, что у них тоже нет раннера и они хотят использовать C#-овский. Пришлось повторять операции и для них.

Резюме


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

  • внедряемое нами решение достаточно взрослое, чтобы проявлять нужную гибкость для построения процессов DevSecOps в кардинально разных средах внедрения. Гибкость достигается за счёт большого набора встроенных и кастомных интеграций, без которых трудозатраты на внедрение возросли бы в разы или сделали бы его невозможным;
  • настройка нужной автоматизации и последующий разбор результатов не требуют необъятного количества трудозатрат даже при огромном скоупе работ. Согласование и построение внедряемых процессов и полная их автоматизация возможны усилиями небольшой экспертной группы из 3-4 человек;
  • внедрение средств автоматической проверки кода и практик DevSecOps позволяет выявить недостатки текущих процессов DevOps и становится поводом для их настройки, улучшения, унификации и регламентирования. В конечном счёте получается win-win ситуация для всех участников процесса от рядовых разработчиков до топ-менеджеров отделов инженерии и ИБ.

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

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

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

Архитектура Пизанской башни

11.09.2020 20:19:02 | Автор: admin
Всем привет. Находясь на удаленке дома, сложно не вспоминать о прошлых путешествиях и не уйти в философию. Своими размышлениями делюсь в преддверии курса Agile Project Manager, в создании которого участвовал.





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

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

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

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

Поделится ли кто-нибудь успешным опытом внедрения нового бизнес-процесса сразу на десятки тысяч клиентов и сотни сотрудников, в режиме двухнедельных спринтов? Кто-то скажет, легко это по agile. Но я не про разработку интерфейсов, не про добавление бизнес-правил, не про A/B-тестирование, а непосредственно про релиз процесса с нуля и мы обнаруживаем, что платформу сложно создать по Scrum, но последнему надо обеспечить нормальное функционирование в прикладных сферах. Платформа не состоит из одних пользовательских историй примерно также, как успех онлайн ритейла не так сильно зависит от веб-сайта. Параллельно представим пример из другой сферы: на сколько сильно обрадуются CEO или CFO рекомендациям списать лишнее оборудование и арендовать место в новом дата-центре с созданием гибридного облака. Почему вы не подумали об этом раньше, обязательно спросят они с серьезным видом. В итоге, конечно, нужна инфраструктура-по-запросу, но затраты на такой сервис будут зависеть от нашей предусмотрительности.

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

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


Читать ещё:


Подробнее..

Из песочницы Пользовательские истории это не требования

13.09.2020 16:10:25 | Автор: admin
Привет, Хабр! Представляю вашему вниманию перевод статьи User stories are not requirements автора Пер Лундхольм (Per Lundholm).

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


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

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

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

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

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

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

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

И все же, требования детально описывают Систему, возможно, в подобном описании есть какая-то ценность для нас? К примеру, как определить является ли некоторое поведение системы багом или нет, если у нас отсутствуют представленные в том или ином виде формальные требования? Здесь нам поможет техника Specification by Example. Итак, принято решение, что некоторая функциональность должна быть реализована. Вы пишите бизнес правила и серию примеров в таком виде, чтобы это было: а) удобно для восприятия; б) реализуемо. Из данного описания должно быть понятно, что должна делать Система. А так же, если что то пойдет нет так вследствие внесения изменений нарушение какого бизнес правила явилось причиной данной дисфункции.

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

Контракт


(автор Маттиас Скарин)

Итак, что мы будем использовать вместо спецификации требований? Ведь нам нужно понимать реализовали ли мы именно то, что было нужно? Мы будем использовать agile контракты. Agile контракты это возможность увидеть лес за деревьями, они позволяют сфокусироваться на сути проекта и совместном достижении цели, реализация которой удовлетворит потребности пользователей.

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

Резюме


  • Несмотря на то, что и слон и жираф имеют по четыре ноги, это разные животные.
  • Пользовательские истории это не требования, а инструмент планирования.
  • Наиболее близкое к требованиям Specification by Example.
Подробнее..

Об устаревании кода и жизненном цикле ПО

17.09.2020 22:09:55 | Автор: admin


Стартап, новые технологии, современные языки и фреймворки. Всё это так волнительно, когда мы начинаем делать что-то с нуля. И обязательно стараемся выбрать современные, популярные, любимые миллионами технологии для нашего проекта. Но время не останавливает свой неумолимый бег, и вдруг мы оглядываемся назад и видим, что нашему стартапу уже 15 с лишних лет. И мир вокруг давно изменился. А у нас в проекте всё тот же Basic/Delphi/Fortran/whatever. И как с этим жить?



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

И становится интересно, а сколько же в среднем вообще живет успешный проект. Если посмотреть вокруг, то в принципе проектов с бородатой историей довольно много. Это и WinRAR, и Microsoft Office, и AutoCAD, и Photoshop, и 3DSmax и множество других. Причем это проекты для массовой аудитории. А сколько существует различных банковских систем, КИС, CRM и прочих корпоративных систем различного уровня. И многие из них писались далеко не в последнюю пятилетку.

Хотелось бы конечно идти в ногу со временем, но мигрировать крупный проект с одного языка на другой, на мой взгляд, тяжёлая задача. Мало того, что пока идет эта миграция и написание нового кода, старый проект должен тоже продолжать работать, жить и развиваться. В новом проекте надо повторить всю логику старого, а она не всегда четкая. В старом проекте много логики может быть построено на библиотеках, которые давно уже не поддерживаются своими разработчиками. В новом проекте этим библиотекам надо искать замену. Если это визуальные компоненты, то с этим еще сложнее, потому что помимо поиска замены нужно еще учитывать, как переписать код работы с этими визуальными компонентами, чтобы новый компонент повторял поведение старого. Конечно, всё решаемо и нет цели повторить работу проекта на 100%, но даже на 50% сделать это очень и очень сложно и в процессе такого переписывания может оказаться, что та платформа/язык, на которую решили переписывать, чем-то не подходит или уже теряет популярность.

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

Хотелось бы узнать мнение здесь присутствующих, сталкивались ли вы с подобными проблемами и как поступали в подобных ситуациях?

Какие решения вы бы посоветовали применить при разработке, чтобы через 10-15 лет не было желания перевести проект на другую платформу?

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

Discovery бэклог как не упустить важное

18.09.2020 12:15:01 | Автор: admin
Всем привет! Меня зовут Юля, я отвечаю за развитие продукта Social Trading в Exness. Немного обо мне. Работаю в продуктовой разработке восемь лет в роли продакта. Начинала заниматься этим, когда эта роль в российских компаниях так даже и не называлась. Сейчас мы вместе с командой делаем продукт, который позволяет трейдерам с небольшим опытом инвестировать на финансовом рынке. Если кратко, суть в том, что эти трейдеры копируют понравившиеся стратегии более опытных трейдеров.

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



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

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

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

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

Теперь расскажу, какие источники используем мы. Итак, поехали.

image

Первый пункт плана послушать клиента


Пожалуй, самый очевидный источник, но это не уменьшает его ценность.

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

На а как получить фидбек клиентов по конкретному вопросу? Здесь помогут исследования лично, по телефону или online; глубинное интервью, опрос, UX-тестирование. Все зависит от задачи и наличия времени. Исследование можно легко провести самому online: множество сервисов вам в помощь или же попросить саппорт, продажи. Последние с радостью примут предложение, ведь какой sales откажется от позитивного повода для контакта с клиентом?

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

Так, одним из самых популярных пожеланий инвесторов было добавление Stop Loss и Take Profit (автоматическое закрытие инвестиции при достижении определенной суммы). Мы запустили эту фичу в августе. Посмотрим, как отразится это на общем уровне NPS, и какое пожелание будет в топе в сентябре.
Там же запускаем быстрые опросы инвестиционный профиль, предпочтения по рынкам и так далее.

image

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

Интервью проводим по фреймворку Job to be done, он позволяет получить максимум инсайтов юзера. Каждый раз узнаем массу нового, так как продукт развивается, а клиенты все разные, и они также развиваются вместе с нами.

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

Данные не умеют говорить, но задают вопросы


У продуктов обычно существуют целевые метрики, по которым измеряется его успех. Если метрик нет, то лучше сделать так, чтобы они появились. Метрики и цели по ним часто являются результатом каскадирования метрик компании, измерителями достижения цели продукта (например, в виде OKR, Objectives and Key Results) или же синтезом этих двух вещей. Например, число активных пользователей, время, проводимое в приложении одним пользователем за период, доход на одного пользователя, NPS.

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

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

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

Покажу на примере. Наша цель в 5 раз увеличить число активных пользователей (активный пользователь имеет открытую инвестицию на 7 день после регистрации и позднее). Мы смотрим на конверсию скачивания в первую инвестицию, сравниваем с аналогичным показателем в другом продукте Exness (мобильное приложение для самостоятельного трейдинга). Видим, что там конверсия в полтора раза выше, хотя по идее наш продукт более простой и направленный на массового потребителя. Начинаем смотреть глубже: для разных стран, разных типов трафика разница почти везде есть, особенно большая для рекламного трафика. Берем самую популярную страну и рекламный трафик, строим воронку по каждому шагу и видим, что самое большое отличие на шаге пополнения баланса. Встречаемся с коллегами, просим поделиться секретом успеха, и все оказывается просто. Все мы изначально внедрили стандартный процесс: клиент кликает в Сделать депозит, заполняет анкету о себе, прикрепляет документы, потом выбирает платежное средство. Коллеги сделали A/B тест, где просто поменяли местами эти шаги и сначала дали выбрать платежное средство. Пользователь на первом шаге видит, что есть удобный для него способ пополнения (клиентам это очень важно, так как в разных странах распространены совершенно разные способы). И дальше он уже готов потратить время на заполнение анкетных данных. А/В тест показал свой эффект, коллеги раскатали на всех. Уже через неделю мы запустили аналогичный тест у себя, который также показал статистически значимый прирост в конверсии.

Конкуренты формируют ожидания, или куда движется рынок


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

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

А что в это время делают ведущие digital-сервисы?


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

О чем могут рассказать коллеги


image

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

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

Стратегия компании


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

А что за продукт мы вообще строим


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

Сотрудничество внутри компании


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

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

Продуктовой команде тоже есть, что добавить


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

Подытожим


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

Ну и небольшие заметки по тому, как фиксировать идеи наилучшим образом:

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

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

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

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

Организация работы в креативной команде опыт Wrike, Miro, Revolut

18.09.2020 16:04:09 | Автор: admin


Мы в Wrike решили сделать встречу для сотрудников креативных команд дизайнеров, маркетологов, проджект-менеджеров чтобы поговорить об эффективных процессах там, где рутина может убить творчество. Позвали дизайн-лидов из Revolut, Miro и Wrike, чтобы они поделились своим опытом, наработками и секретами.
24 сентября, в 18:00 по Москве. Онлайн.


Спикеры:





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



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

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



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

Регистрация

Подробнее..

Change Management 3 Колесо изменений и борьба с партизанами

24.09.2020 12:15:14 | Автор: admin

Привет, Хабр! Это мой заключительный пост на тему Change Management, в котором я хочу рассказать о модели Change Well и ее пользе для бизнеса. Мы рассмотрим, чем в партизан отличается от саботажника (в контексте внедрения изменений, конечно), как кувалда может помочь ускорить изменения в организации и чему мы можем научиться у создателей компьютерных игр.

Одним из подходов к управлению изменениями в организациях и не только является модель Колеса Изменений (Change Well) Розабет Мосс Кантер. По замыслу известной ученой из Гарвардского университета, для успешного внедрения изменений мы должны сконцентрироваться на активностях из 10 категорий. Как и среди спиц колеса, из них нельзя выделить более или менее важные. Но если одна или несколько спиц деформированы, далеко уехать будет непросто. То же можно применить и к внедрению изменений.

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

  1. Символизм отличный помощник при продвижении изменений. Один из ярких примеров символических действий продемонстрировал руководитель компании Haier, на данный момент одного из крупнейших мировых производителей бытовой техники. В 80-х Haier был небольшой компанией, которая выпускала холодильники. Одним из первых шагов ее руководителя Чжан Жуйминя был разворот к качеству. Но заявление так и осталось заявлением, пока директор не пришел с проверкой на завод. Когда ревизия выявила значительное количество брака, директор взял в руки кувалду и начал громить некачественные холодильники, а потом поручил сотрудникам делать то же самое. Работники были шокированы, ведь стоимость каждого холодильника составляла их двухлетнюю зарплату. Это был яркий символ отказа от прошлого и нового подхода к производству, в том числе благодаря которому компания изменилась и стала тем, чем она является сейчас. Кстати, кувалда до сих пор выставлена в музее в штаб-квартире компании Haier.

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

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

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

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

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

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

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

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

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

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

Например:

  • Символы и сигналы не могут быть распространены без коммуникаций

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

  • Чемпионы должны быть награждены и получить общественное признание

Личный опыт

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

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

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

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

Весь спектр мотиваций

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

  • В число миссионеров и визионеров входят топ-менеджеры и менеджеры, которые знают, зачем нужны изменения и продвигают их;

  • Активные последователи это Чемпионы. Они готовы работать по-новому;

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

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

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

  • Явные противники выступают против изменений открыто. Они отстаивают свое мнение, и с ними очень важно общаться. Именно они могут указать на ошибки, недочеты и другие нюансы;

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

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

Островной подход к внедрению изменений.

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

Так, мое подразделение в Acronis в какой-то момент было переименовано из Performance QA в Performance Engineering, чтобы явно показать, что мы уходим от ручного тестирования производительности к более сложным автоматизированным решениям. В производстве, например, можно выдать людям белую униформу и назвать отдел Белым в контраст с остальными отделами, а может быть купить черные футболки и сделать спецов по безопасности Черной командой.

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

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

Заключение

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

Подробнее..

Перевод Многие дедлайны придумывают специально с целью заставить инженеров работать бесплатно

26.09.2020 20:04:42 | Автор: admin
Работа инженера сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

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

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

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

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

Вы можете спросить, разве это законно? Да, это законно в Соединенных Штатах, поскольку инженеры получают фиксированную зарплату, а не почасовую оплату. Работнику выдают одинаковую сумму каждую неделю независимо от того, сколько часов он фактически работает. Почему это законно? Вероятно, это связано с тем, что крупные ИТ-компании могут позволить себе нанимать лоббистов, а инженеры нет.

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

Как продуктовому дизайнеру оценить свою работу

21.09.2020 10:09:24 | Автор: admin

image
Photo by Brooke Cagle on Unsplash


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


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


Дни после релиза


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


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


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


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


Как сравнить метрики до и после


Реальное значение метрики против замеренной


У каждой метрики есть её реальное значение назовем его R (реальное), а есть значение, которое мы получили через замеры Z (замеренное).


И первое, с чем нам надо справиться это понять, что R Z.


Разберемся на примере


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


Допустим, теоретически мы могли бы опросить каждого человека в России, силовик он или нет, и получить реальное значение, то есть R.


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


Так мы получаем Z, то есть замеренную метрику. Думаю, теперь стало понятно, что почти всегда Z R.


Как из замеренной метрики получить реальную?


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


Вернемся к примеру с силовиками. Предположим, что после опроса 300 человек, 5 из них ответили, что являются сотрудниками силовых структур, то есть приблизительно 1,7%.


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


  1. Замеренное значение метрики в случаем с силовиками это 1.7%
  2. Количество выборки, на которой сделан замер 300 человек
  3. Количество потенциальной выборки (не обязательно) в нашем случае наслеление России 146 млн человек.
  4. Выбрать точность, с которой мы хотим получить результат. Обычно используют 90, 95 и 99%

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


На выходе мы получим промежуток, в котором содержится R с вероятность 90, 95 и 99% (в зависимости от того, какой процент мы выбрали при расчёте).


Если вернуться к примеру с силовиками, то после этих расчётов можно сказать, что R находится в промежутке (или доверительном интервале) от 0% до 3,59% от всего населения России.


А значит, если умножить этот процент на население России, то получим интервал от 0 человек до 5 268 274 человек. (В этом интервале действительно содержится верный ответ в реальности это 2,6 миллиона).


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


А как же все-таки сравнить метрики до и после


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


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


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


Разберемся на примере маркетинговой компании


Допустим, мы подготовили 2 креатива, и их посмотрели по 5 000 пользователей. Первый показал значение CTR 2% (это процент нажавших на креатив и перешедших на лендинг), а другой 3%. Можно ли сказать, что второй лучше первого?


Чтобы ответить на этот вопрос, нам надо собрать все данные для измерения доверительного интервала:


По первому банеру:


  1. Значение метрики 2%
  2. Сколько людей увидело этот банер 5 000
  3. Опускаем потенциальную выборку
  4. Выбираем точность 95%

Получаем, что R по первому креативу с 95% вероятностью находится между [ 1,61% 2,39% ]


Тоже самое проделываем по второму банеру (его посмотрело тоже 5 000 человек) и получаем интервал [ 2,53% 3,47% ]


image


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


Подытожим


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

Что дальше


Это была 3 и последняя статья из серии Дизайнер и метрики.


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

Подробнее..

Из песочницы Для чего и как проводить исследование клиентов?

15.09.2020 12:21:41 | Автор: admin
Тестирование идей на их жизнеспособность играет важную роль в развитии и разработке продукта, а также его продаж. Для этого нужны навыки и опыт, которые приобретаются только при участии в боевых условиях.

Путь нашей компании


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

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

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

Как мы проверяем идеи?


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

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

Немного о самом CustDev


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

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

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

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

Guide по CustDev из нашего опыта


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

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

Перевод Использование семи смертных грехов для мотивации персонала

22.09.2020 18:18:39 | Автор: admin
Привет, Хабр! Представляю вашему вниманию ироничную вариацию на тему семи смертных грехов. На этот раз, в контексте управленческих практик. Перевод статьи Evil Coach.

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

image


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

Гордыня


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

Жадность


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

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

Зависть


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

Чревоугодие


Разработчики питаются колой и пиццей, правильно? Убедитесь, что ваши команды имеет постоянный доступ к этим столпам здорового питания. (Время от времени можно раздавать витамины, если у них начнут выпадать зубы, или жидкость для полоскания полости рта с фтором, если зубы начнут разрушаться, ну, вы поняли идею.) Если вы обеспечите их едой и напитками, им будет не нужно ходить на обед. Если в офисе установить узкие дверные проемы, дополнительным бонусом через некоторое время станет то, что они вообще не смогут оттуда уйти. А значит у вас появятся ДЕЙСТВИТЕЛЬНО преданные своему делу сотрудники.

Гнев


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

Лень


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

Похоть


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

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

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

Удачи!
Подробнее..

Recovery mode Кайф трекерства в экспансии. Интервью с трекером Дмитрием Безнасюком

20.09.2020 10:09:00 | Автор: admin
Зачем вообще стартапу нужен трекер? Они сами не справятся?
Трекер помогает стартапу расти в акселераторе. Он как старший товарищ, который поддержит и направит. У трекера обычно две основные задачи: задавать вопросы о развитии бизнеса и помогать с тактическими расчетами своей экспертизой и связями. Чаще всего трекер сам предприниматель или топ-менеджер, знающий бизнес изнутри. Действующих трекеров (тех, кто ведет проекты постоянно, хотя бы 3+ в месяц) не более 150 на весь рынок, по оценке Дмитрия.



Чтение займет 10 минут
Текст: Иван Сурвилло



Дмитрий Безнасюк, трекер программы StartupDrive: Я IT-предприниматель. Не люблю слово серийный, хотя иногда его использую. У меня два действующих бизнеса, первый это компания SEARADAR, это международная платформа аренды яхт, зарегистрированная в Эстонии и Литве. Работает уже три года. Проходил акселератор литовский Baltic sandbox, то есть в роли стартапера бывал и нахожусь. Вторая компания Турбодилер, где я не участвую в операционке, только член совета директоров. Это SaaS-платформа для автодилеров. Компания проходила акселератор ФРИИ. Первый бизнес компания ЭмПрана про подарки и впечатления. Я ее в 13-м году продал партнерам и вышел оттуда.


Кто такой трекер?


Трекер это смесь ментора и управленца для стартапа. Трекер помогает команде и отдает часть собственной экспертизы. Делается это не какой-то магией, есть такие методики, как Lean Startup или HADI-циклы.

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

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

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

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

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

Ты сам выбираешь команду?


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

Бывало, что химия, которая была с самого начала, потом давала сбой?


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

Кто идет в акселератор?


StartupDrive корпоративный акселератор. Туда идут команды, которые предполагают, что их бизнес можно сработать с бизнесом большой компании. Условно, у сети АЗС Газпромнефть есть клиентская база, которую они готовы предоставить, и для стартапа это быстрый вход на большое количество B2B-клиентов или на частников. Нужна база? Вот тебе база! Иди попробуй что-нибудь поделать.

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

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

Кому точно не стоит идти в акселератор?


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

А тебе, как трекеру, зачем акселератор?


Началось все как хобби. Я проходил акселератор ФРИИ (friifond), и спустя какое-то время ребята говорят: Можешь помочь продиагностировать команду? Похожа на твой бизнес. Я согласился. Раз, второй, третий.

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

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

Еще один момент практики, которые работают в чужих стартапах, можно применять к себе. Есть этика, что конкурентные или близкие сферы не берешь. Я не могу быть трекером для яхтенного бизнеса: это мой основной доход. Но то, что работает в B2C-маркетинге для доставки еды, может часто срабатывать и в других отраслях. Например, в одном стартапе ребята искали каналы для B2B софта. Классический маркетинг работал не очень хорошо, и мы придумали для них тематический чат в Telegram. Штука классно сработала, я ее применяю у себя на сборы клиентов на вебинары по яхтингу. Оказалось, что чат в Telegram интересный канал, на который я раньше не смотрел.

Сложно ли тебе, как трекеру, работать в акселераторе?


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

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

Стартапу тяжело в акселераторе?


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

Акселератор = большое напряжение ресурсов всей команды и еще бльшее напряжение твоих ресурсов как фаундера. Когда я проходил акселератор во ФРИИ, у них был очный набор в Москве, а я сам из Питера. У меня только родился ребенок, которому было 6 месяцев. Я жене говорю: Тут такое дело, я улетаю в Москву на 3 месяца, но вернусь. Улетел, а она осталась одна.

В Москве я был часто недоступен, потому что работал во время акселератора 24/7. Потом остался в столице еще на год, потому что мы открыли московский офис и я не мог уехать. Такая ситуация длилась полтора года.

Ты думал, насколько оправданы для тебя эти жертвы?


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

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

Нужно ли какое-то образование трекеру?


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

Насчет образования: есть школа трекеров. Даже не одна. Это интересный феномен, который родился только в России. Знакомые ребята ездили в Y Combinator в Калифорнию, там прям интересовались: Мы не поняли, расскажите? Что такое школа трекеров? Кто такой трекер?

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

У тебя, как у трекера, есть что-то, чем можешь похвастаться?


Есть.

У меня было две команды в акселераторе StartupDrive. Первая это Ucar. Команда работала в B2B, а в акселераторе со мной они вышли в новый сегмент B2C. Команда выросла десятикратно по выручке с учетом ковида, локдауна и ограничений. Считаю, в этом есть доля моего результата.

Вторая команда Rental Club. Ребята делают маркетплейс для строительной техники. Мы им поменяли модель и пересобрали продукт. Они были ориентированы на владельцев техники, сейчас пошли со стороны клиента. Ребята увеличили средний чек с 180 до 2700 рублей. В 15 раз.

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

Кстати, их пример как раз хорошо показывает, до чего доводит слаженная работа трекера и стартапа в акселераторе. У Rental Club был call-центр, который занимается подбором спецтехники. Схема такая. Заказчик говорит: Мне нужна техника на объект. Ее быстро ищут, подгоняют и живут на комиссии. Хороший большой растущий бизнес.

Дальше они сделали IT-платформу для аренды спецтехники. Забирали с рынка имеющиеся заказы и туда закидывали. Заказов было мало, заказ мало стоил, потому что он не уникальный. Бизнес не заводился.

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

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

Как думаешь, насколько востребованы трекеры на рынке?


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

Пока востребованность есть.

Ты работаешь со стартапами как психолог?


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

В чем для тебя кайф быть трекером?


Экспансия. Такое мужское желание.

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

Бывало, что стартапы приходили к тебе после акселераторов?


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

Есть какой-то этический кодекс трекера?


Есть.

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

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

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

Как распознать хорошего трекера?


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

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

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

Какие, на твой взгляд, плюсы и минусы у акселератора StartupDrive?


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

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

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

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

У Газпром нефти акселератор StartupDrive реально работающая история.


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

22 сентября, Онлайн-митап Product Engineering Meetup 2 Культура разработки

17.09.2020 16:18:03 | Автор: admin
22 сентября мы проводим онлайн-митап Product Engineering Meetup #2 Культура разработки в продуктовых компаниях.

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

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

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

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

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



Доклады


История эволюции фичи: от MVP до одной из основных функциональностей продукта Евгений Жуков, Backend Developer (ManyChat)

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

Как перестать беспокоиться и начать верить А/Б тестам 2 Максим Кислов, Frontend Engineering Manager (Badoo)

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

  • как организовать работу с А/Б тестами внутри компании;
  • как дать бизнесу ответ на вопрос ну как там наш тест?;
  • как определить границу ответсвенности техлида и разделить ответственность с продактом.

Инициатива не наказуема. Почему разработчика важно погружать в продуктовую жизнь Лаша Харчилава, Ведущий Менеджер Продукта (Работа.ру)

  • Что нужно сделать в первый день новому продакту, чтобы жизнь разработчика стала лучше.
  • Что такое продуктовый онбординг и зачем он разработчику.
  • Для чего нужны разработчики в краткосрочном и среднесрочном планировании продуктовых задач.
  • План к действию: есть проблема сначала спроси у разработчика.
  • Какая связь между разработчиками и результатами АБ-теста.

Как релиз продукта вышел на полгода позже, а пересмотр процессов разработки научил нас попадать в сроки Борис Герн, B2C Product Lead (Додо Пицца)

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

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

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

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

Участие


Встреча пройдёт онлайн, 22 сентября. Начало в 19:00.

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

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

Личный опыт Переехать в Штаты и устроиться в компанию мечты советы от продакт-менеджера

16.09.2020 00:04:05 | Автор: admin
На вебинаре g-mate рассказала про переезд в Америку, сложности при устройстве на работу за границей, если ты не инженер, отличия менталитетов и собеседований в двух странах. Эта статья дополнение предыдущей, привожу ответы на вопросы в тексте.



Что повлияло натебя итвой выбор карьеры?


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

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

Стого момента началась моя карьера вIT. ВОдноклассниках япроработала 10лет, познакомилась сосвоим мужем. Онвпоследствии выиграл грин-карту это привело меня вСША, мыпереехали вместе. Яустроилась вFasten вБостоне, штат Массачусетс. Компания занималась райдшерингом, они работали вдвух городах: вБостоне иОстине. ВОстине уних тоже был офис, якак-то съездила вкомандировку ивлюбилась вэтот город, решила обязательно вернуться. Вернулась через три года.

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

Долголи искала работу вАмерике?


Уменя никогда небыло желания переехать вСША, вMail.ru всё шло очень хорошо натот момент работала вОдноклассниках. Уменя был прекрасный проект, прекрасная команда, язанималась приложением Подарки. Просто муж очень хотел переехать, так что яподумала: нуладно, буду хорошей женой, перееду сним. Ябыла настолько уверена всебе, что ничего неделала попоиску работы.

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

Чтобы найти первую работу, мне непотребовалось много времени. Хотя предсказывали, что ябуду полгода ееискать, потому что это нормальный срок поиска. Ноунас нет денег наполгода жизни вАмерике. Ссобой 15тысяч долларов насемью издвоих взрослых ималенького двухлетнего ребёнка. Мыпереехали впригороды Нью-Йорка, при очень скромных расходах унас уходило вмесяц 3тысячи долларов. Ярассчитала, что при минимальной стоимости жизни вСША должна найти работу месяца за4 это максимум. Унас есть деньги на5месяцев, аиначе всё, нужно валить.

Янашла работу через 2месяца. Это очень быстро, все говорили так небывает. Помог нетворкинг.

Посчастливой случайности меня нашли ребята, тоже изРоссии: Fasten стартап сроссийскими корнями. Содним изоснователей мыработали лет 78назад, делали комедийное шоу вКраснодаре: спонсором были Одноклассники, яработала вмаркетинге. Основатель Fasten сказал мне: Ань, ятебя помню, мыстобой классно работали. Как раз ищем продакта впроект, давай кнам. Япрошла все этапы собеседования, сделала задание, ичерез 2месяца мыпереехали вБостон. Так что нетворкинг решает всегда ивезде, это очень важно.

Как искать работу вАмерике?


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

СВасилием изBitClave мыпознакомились наStarta это стартап-акселератор вНью-Йорке. Пока жила там, яходила навсе митапы, куда только можно. Вакселераторе Василий как раз сосвоими ребятами запускал проект. Мысним познакомились, ичерез полтора года онменя нашёл иговорит: Ань, мыкак раз ICO запускаем, иди кнам работать. Ияпереехала.

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

Второе: Linkedin. Если выищете работу вАмерике это обязательно, всегда должен быть хорошо заполненный профиль, естественно, наанглийском. Много сайтов типа российских джоб-бордов: Indeed, AngelList сайт для стартаперов, хорошо искать работу внебольших компаниях, ещё Hired, Glassdoor. Уменя хорошо сработал AngelList, было много хороших интервью, свою последнюю компанию Zello янашла сего помощью.



Что уменя точно несработало Monsters. Наверное, онхорош недля технологических компаний, аесли выищете работу вресторанном бизнесе, например. По-моему, онсамый популярный вСША, нослишком широкий: снего приходит много спама инерелевантных предложений.

[Немного дополню. Когда ябыл вШтатах иобщался сразработчиками изразных компаний: Фейсбука, Амазона, Гугла, понял, что рекомендации очень востребованы, потому что вбольшинстве компаний заних платят. Идаже если человеку, скоторым тыпросто водном вузе учился вРоссии, написать: Друг, привет, мыстобой учились водном вузе, анепорекомендуешьли тыменя, они все отвечают исоглашаются, потому что ему заплатят бонус ипотому что вцелом непротив сделать хорошее идоброе дело комментарий Алексея Исаева состороны g-mate]

Можно посмотреть пример резюме?


Моё резюме ввиде гуглдока.

Как проходит интервью надолжность продакт-менеджера? Вчем отличия собеседования вАмерике иРоссии?


Как кто-то писал вкомментариях кмоей статье, успех прохождения интервью иполучения оффера вСША зависит на30% отрезюме, на30% оттехнических скиллов ина30% отcultural fit. Уменя очень небольшой опыт собеседований вРоссии. Комне приходили спредложением, стоило поговорить соснователем или СЕО, ивсё было хорошо. ВСША япроходила миллиард этапов, тут смотрят наcultural fit насколько тывообще подходишь команде. Это первое отличие.

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

Когда яработала вРоссии, все говорили: хороший человек, всё здорово. Eсть минусы нуничего, возьмём, обучим, приспособим. ВСША нетак. Тут тыуже должен быть идеальным кандидатом обученным, приспособленным, ипроекты могут позволить себе выбирать.

Второе, что сильно отличается отроссийских собеседований: прозрачность процесса. ВСША все вопросы известны заранее, можно зайти наGlassdoor, вбить: интервью Фейсбук, или Гугл, или любая другая компания, ипосмотреть, какие вопросы задают. Покрупным компаниям вообще книги написаны. Например:


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

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

Где искать вопросы?




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


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

Яслушала лекции TED, уменя был учитель-нейтив, яочень долго сним занималась, свободно общалась стеми, укого хорошая речь. Поэтому считала, что санглийским всё прекрасно. Нокогда переехала вСША ипошла вБруклине вбанк делать себе карту, комне подошла тётя, которую явообще непонимала.

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

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

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

Как отличаются тестовые задания вАмерике ивРоссии?


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

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

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

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

Кстати, большое отличие продактов вСША иРоссии: вРоссии чаще общаются вчатиках, спомощью писем. Продакты вСША на80% общаются вербально. Поэтому тестовые задания повод проверить твои communication skills: насколько тычетко умеешь описывать ход мыслей.

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

Как подтянуть свои навыки коммуникации ипрезентации?


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

Япрактикуюсь наStellarPeers это сайт для практики продактов изкрупных компаний, тут решают design questions: задизайньте ютуб для космонавтов, решите проблему сфейковыми новостями нафейсбуке. Могут быть вопросы поexecution: определите цель для сториз винстаграме, что будете делать, если увас упала такая-то метрика. Есть 30минут, чтобы ответить наэтот вопрос, потом выссобеседником меняетесь местами, икак интервьюер слушаете его идаёте обратную связь.



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

Ещё узнаешь всякие инструменты. Раньше тренировки проходили оффлайн, итымог рисовать схемы надоске или бумажке сейчас всё онлайн. Яузнала, например, про карандаш, который транслирует твои записи наэкран, когда тыпишешь вобычном блокноте. Называется Neo SmartPen N2. Яспросила девочку, которая имрисовала, почему она неиспользует какие-то программы. Она ответила, что связь мозга срукой гораздо сильнее. Поэтому если утебя сложная задачка иидёт тяжелый мозговой процесс, писать рукой гораздо полезнее.

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

Ещё ресурсы для тренировки mock interview:



Как переговариваться оденьгах сработодателями?


Любую зарплату вСША можно найти наGlassdoor. Это вообще очень крутой ресурс для понимания рынка. Если вбить, кпримеру, Senior Product Manager, Texas, Austin выпримерно поймете, какая уменя зарплата. Доход сильно зависит отгорода. Обычно, когда звонят рекрутеры, они сразу спрашивают вилку. Конечно, если это неФейсбук: мне кажется, Фейсбук иногда может диктовать свои условия. Крупные компании истартапы спрашивают вилку, атыдолжен сказать: моя зарплата от120 до150 тысяч долларов. Снижать ипревышать вилку нельзя.

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

Что касается переговоров: воффере бывает еще куча других бенефитов-вознаграждений: стоки, акции, страховки, компенсация обучения, возмещение запокупку ноутбука илюбой другой техники, релокационный пакет, sign-on bonus когда тебе дают деньги зато, что тыподписал оффер. Получается достаточно большой документ, изарплата только его часть. Поэтому когда оффер приходит, есть смысл торговаться вСША это считается хорошим тоном. Даже если условия кажутся прекрасными, просто покажите, что вызнаете себе цену, что выуверены всебе. Торговаться надо аргументированно, врамках приличий. Ненадо просить зарплату в3раза больше или безумное количество акций. Напишите: Ясделал рисёрч, для тех требований, которые вывыдвигаете, мне кажется, зарплата должна быть на10% больше, имне нужно переехать ссемьей, ваша компенсация в5000 долларов непокроет расходы напереезд, яхочу 10000долларов. Будьте определенными вцифрах, американцы любят эту специфичность: хочу+10%, хочу +10000, анесколько-нибудь.

ВСША, кстати, доход чаще всего годовой без вычета налогов, иэто тоже надо понимать. Когда говорят: зарплата 100 тысяч долларов, ясэтих 100 тысяч30% заплачу налог, ивсё будет нетак радужно. Либо бывает часовая зарплата. Здесь могут спросить, какая зарплата годовая икакая часовая. Первое время часовая ставка меня сильно смущала, потому что яже работаю нечас, ацелый день. Еёнужно высчитать отдельно. Ясвою высчитывала через какие-то калькуляторы: брала годовую, делила наколичество часов, сколько проработаю без учета отпуска ичуть-чуть добавляла.

Можноли удалённо изРоссии найти работу вШтатах?


Язнаю, что инженерам нетак сложно найти удалённую работу. Поопыту моих друзей-инженеров: они находились вРоссии, проходили собеседования, получали оффер, делали визу H1B ипереезжали вСША. Сейчас, наверное, сэтим будет немного сложнее, потому что Трамп ужесточил требования.

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

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

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

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

[Подтверждаю это на100% нашей практикой. За10лет мыпомогали переехать вразные страны сотням разработчиков итехнических специалистов. Было всего несколько продуктовых менеджеров А.И.]

Вкаких компаниях искать работу?


Думаю, надо смотреть нарусские стартапы. Сомневаюсь, что американские стартапы захотят перевезти человека изРоссии, это действительно надо иметь уникальные знания, которых нет вАмерике. Арусские компании могут проверить опыт, они знают российский рынок, они знают, например, что Mail.ru хорошая сильная компания. Когда яздесь устраивалась иговорила, что яработаю вMail.ru, крупнейшей IT-компании Европы, меня спрашивали: выбыли владельцем?. Настолько американские рекрутеры порой незнают, что происходит запределами США, изадают глупые вопросы.

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

Какие впечатления отнайма как уинтервьюера?


Янанимала ивРоссии, ивАмерике, собеседовала как разработчиков, так ипродакт-менеджеров.

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

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

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

Какие фреймворки нужно использовать в ответах на интервью?


  • SAR (orSTAR) behavioral questions
  • CIRCLE product design questions
  • HEART success metrics (Google framework)
  • AARRR success metrics (startups)
  • RICE (или ICE) prioritization
  • PURSUIT


4совета, что надо сделать впервую очередь, если появилось желание переехать вдругую страну?


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

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

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

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

[Заметил это, когда был вШтатах: много виделся синженерами, ибыл безумно удивлён, как они замотивированы встретиться сомной. Навстрече они радовались, что встретили человека изРоссии, спохожей культурой. Видно, многим этого нехватало. Поэтому совет стем, чтобы заводить знакомства заранее, очень дельный А.И.]

Что ещё полезного можно почитать/посмотреть продактам?


Книги про карьеру:


Каналы наЮтубе:



Полную запись моего вебинара смотрите вот здесь.

Cледующим гостем g-mate будет Денис, Staff Android Engineer из Lyft, который живёт и работает в Сан-Франциско. Он сменил 5 стран за 8 лет карьеры в разработке и расскажет, стоило ли оно того.
Подробнее..

Личный опыт Как устроиться в компанию мечты в США советы продакт-менеджера

16.09.2020 06:13:58 | Автор: admin
На недавнем вебинаре g-mate я рассказала про сложности при устройстве на работу в США, если ты не инженер, отличия менталитетов и собеседований в двух странах. Эта статья дополнение предыдущей, привожу ответы на вопросы в тексте.



Что повлияло натебя итвой выбор карьеры?


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

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

Стого момента началась моя карьера вIT. ВОдноклассниках япроработала 10лет, познакомилась сосвоим мужем. Онвпоследствии выиграл грин-карту это привело меня вСША, мыпереехали вместе. Яустроилась вFasten вБостоне, штат Массачусетс. Компания занималась райдшерингом, они работали вдвух городах: вБостоне иОстине. ВОстине уних тоже был офис, якак-то съездила вкомандировку ивлюбилась вэтот город, решила обязательно вернуться. Вернулась через три года.

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

Долголи искала работу вАмерике?


Уменя никогда небыло желания переехать вСША, вMail.ru всё шло очень хорошо натот момент работала вОдноклассниках. Уменя был прекрасный проект, прекрасная команда, язанималась приложением Подарки. Просто муж очень хотел переехать, так что яподумала: нуладно, буду хорошей женой, перееду сним. Ябыла настолько уверена всебе, что ничего неделала попоиску работы.

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

Чтобы найти первую работу, мне непотребовалось много времени. Хотя предсказывали, что ябуду полгода ееискать, потому что это нормальный срок поиска. Ноунас нет денег наполгода жизни вАмерике. Ссобой 15тысяч долларов насемью издвоих взрослых ималенького двухлетнего ребёнка. Мыпереехали впригороды Нью-Йорка, при очень скромных расходах унас уходило вмесяц 3тысячи долларов. Ярассчитала, что при минимальной стоимости жизни вСША должна найти работу месяца за4 это максимум. Унас есть деньги на5месяцев, аиначе всё, нужно валить.

Янашла работу через 2месяца. Это очень быстро, все говорили так небывает. Помог нетворкинг.

Посчастливой случайности меня нашли ребята, тоже изРоссии: Fasten стартап сроссийскими корнями. Содним изоснователей мыработали лет 78назад, делали комедийное шоу вКраснодаре: спонсором были Одноклассники, яработала вмаркетинге. Основатель Fasten сказал мне: Ань, ятебя помню, мыстобой классно работали. Как раз ищем продакта впроект, давай кнам. Япрошла все этапы собеседования, сделала задание, ичерез 2месяца мыпереехали вБостон. Так что нетворкинг решает всегда ивезде, это очень важно.

Как искать работу вАмерике?


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

СВасилием изBitClave мыпознакомились наStarta это стартап-акселератор вНью-Йорке. Пока жила там, яходила навсе митапы, куда только можно. Вакселераторе Василий как раз сосвоими ребятами запускал проект. Мысним познакомились, ичерез полтора года онменя нашёл иговорит: Ань, мыкак раз ICO запускаем, иди кнам работать. Ияпереехала.

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

Второе: Linkedin. Если выищете работу вАмерике это обязательно, всегда должен быть хорошо заполненный профиль, естественно, наанглийском. Много сайтов типа российских джоб-бордов: Indeed, AngelList сайт для стартаперов, хорошо искать работу внебольших компаниях, ещё Hired, Glassdoor. Уменя хорошо сработал AngelList, было много хороших интервью, свою последнюю компанию Zello янашла сего помощью.



Что уменя точно несработало Monsters. Наверное, онхорош недля технологических компаний, аесли выищете работу вресторанном бизнесе, например. По-моему, онсамый популярный вСША, нослишком широкий: снего приходит много спама инерелевантных предложений.

[Немного дополню. Когда ябыл вШтатах иобщался сразработчиками изразных компаний: Фейсбука, Амазона, Гугла, понял, что рекомендации очень востребованы, потому что вбольшинстве компаний заних платят. Идаже если человеку, скоторым тыпросто водном вузе учился вРоссии, написать: Друг, привет, мыстобой учились водном вузе, анепорекомендуешьли тыменя, они все отвечают исоглашаются, потому что ему заплатят бонус ипотому что вцелом непротив сделать хорошее идоброе дело комментарий Алексея Исаева состороны g-mate]

Можно посмотреть пример резюме?


Моё резюме ввиде гуглдока.

Как проходит интервью надолжность продакт-менеджера? Вчем отличия собеседования вАмерике иРоссии?


Как кто-то писал вкомментариях кмоей статье, успех прохождения интервью иполучения оффера вСША зависит на30% отрезюме, на30% оттехнических скиллов ина30% отcultural fit. Уменя очень небольшой опыт собеседований вРоссии. Комне приходили спредложением, стоило поговорить соснователем или СЕО, ивсё было хорошо. ВСША япроходила миллиард этапов, тут смотрят наcultural fit насколько тывообще подходишь команде. Это первое отличие.

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

Когда яработала вРоссии, все говорили: хороший человек, всё здорово. Eсть минусы нуничего, возьмём, обучим, приспособим. ВСША нетак. Тут тыуже должен быть идеальным кандидатом обученным, приспособленным, ипроекты могут позволить себе выбирать.

Второе, что сильно отличается отроссийских собеседований: прозрачность процесса. ВСША все вопросы известны заранее, можно зайти наGlassdoor, вбить: интервью Фейсбук, или Гугл, или любая другая компания, ипосмотреть, какие вопросы задают. Покрупным компаниям вообще книги написаны. Например:


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

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

Где искать вопросы?



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


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

Яслушала лекции TED, уменя был учитель-нейтив, яочень долго сним занималась, свободно общалась стеми, укого хорошая речь. Поэтому считала, что санглийским всё прекрасно. Нокогда переехала вСША ипошла вБруклине вбанк делать себе карту, комне подошла тётя, которую явообще непонимала.

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

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

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

Как отличаются тестовые задания вАмерике ивРоссии?


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

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

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

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

Кстати, большое отличие продактов вСША иРоссии: вРоссии чаще общаются вчатиках, спомощью писем. Продакты вСША на80% общаются вербально. Поэтому тестовые задания повод проверить твои communication skills: насколько тычетко умеешь описывать ход мыслей.

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

Как подтянуть свои навыки коммуникации ипрезентации?


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

Япрактикуюсь наStellarPeers это сайт для практики продактов изкрупных компаний, тут решают design questions: задизайньте ютуб для космонавтов, решите проблему сфейковыми новостями нафейсбуке. Могут быть вопросы поexecution: определите цель для сториз винстаграме, что будете делать, если увас упала такая-то метрика. Есть 30минут, чтобы ответить наэтот вопрос, потом выссобеседником меняетесь местами, икак интервьюер слушаете его идаёте обратную связь.



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

Ещё узнаешь всякие инструменты. Раньше тренировки проходили оффлайн, итымог рисовать схемы надоске или бумажке сейчас всё онлайн. Яузнала, например, про карандаш, который транслирует твои записи наэкран, когда тыпишешь вобычном блокноте. Называется Neo SmartPen N2. Яспросила девочку, которая имрисовала, почему она неиспользует какие-то программы. Она ответила, что связь мозга срукой гораздо сильнее. Поэтому если утебя сложная задачка иидёт тяжелый мозговой процесс, писать рукой гораздо полезнее.

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

Ещё ресурсы для тренировки mock interview:


Как переговариваться оденьгах сработодателями?


Любую зарплату вСША можно найти наGlassdoor. Это вообще очень крутой ресурс для понимания рынка. Если вбить, кпримеру, Senior Product Manager, Texas, Austin выпримерно поймете, какая уменя зарплата. Доход сильно зависит отгорода. Обычно, когда звонят рекрутеры, они сразу спрашивают вилку. Конечно, если это неФейсбук: мне кажется, Фейсбук иногда может диктовать свои условия. Крупные компании истартапы спрашивают вилку, атыдолжен сказать: моя зарплата от120 до150 тысяч долларов. Снижать ипревышать вилку нельзя.

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

Что касается переговоров: воффере бывает еще куча других бенефитов-вознаграждений: стоки, акции, страховки, компенсация обучения, возмещение запокупку ноутбука илюбой другой техники, релокационный пакет, sign-on bonus когда тебе дают деньги зато, что тыподписал оффер. Получается достаточно большой документ, изарплата только его часть. Поэтому когда оффер приходит, есть смысл торговаться вСША это считается хорошим тоном. Даже если условия кажутся прекрасными, просто покажите, что вызнаете себе цену, что выуверены всебе. Торговаться надо аргументированно, врамках приличий. Ненадо просить зарплату в3раза больше или безумное количество акций. Напишите: Ясделал рисёрч, для тех требований, которые вывыдвигаете, мне кажется, зарплата должна быть на10% больше, имне нужно переехать ссемьей, ваша компенсация в5000 долларов непокроет расходы напереезд, яхочу 10000долларов. Будьте определенными вцифрах, американцы любят эту специфичность: хочу+10%, хочу +10000, анесколько-нибудь.

ВСША, кстати, доход чаще всего годовой без вычета налогов, иэто тоже надо понимать. Когда говорят: зарплата 100 тысяч долларов, ясэтих 100 тысяч30% заплачу налог, ивсё будет нетак радужно. Либо бывает часовая зарплата. Здесь могут спросить, какая зарплата годовая икакая часовая. Первое время часовая ставка меня сильно смущала, потому что яже работаю нечас, ацелый день. Еёнужно высчитать отдельно. Ясвою высчитывала через какие-то калькуляторы: брала годовую, делила наколичество часов, сколько проработаю без учета отпуска ичуть-чуть добавляла.

Можноли удалённо изРоссии найти работу вШтатах?


Язнаю, что инженерам нетак сложно найти удалённую работу. Поопыту моих друзей-инженеров: они находились вРоссии, проходили собеседования, получали оффер, делали визу H1B ипереезжали вСША. Сейчас, наверное, сэтим будет немного сложнее, потому что Трамп ужесточил требования.

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

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

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

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

[Подтверждаю это на100% нашей практикой. За10лет мыпомогали переехать вразные страны сотням разработчиков итехнических специалистов. Было всего несколько продуктовых менеджеров А.И.]

Вкаких компаниях искать работу?


Думаю, надо смотреть нарусские стартапы. Сомневаюсь, что американские стартапы захотят перевезти человека изРоссии, это действительно надо иметь уникальные знания, которых нет вАмерике. Арусские компании могут проверить опыт, они знают российский рынок, они знают, например, что Mail.ru хорошая сильная компания. Когда яздесь устраивалась иговорила, что яработаю вMail.ru, крупнейшей IT-компании Европы, меня спрашивали: выбыли владельцем?. Настолько американские рекрутеры порой незнают, что происходит запределами США, изадают глупые вопросы.

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

Какие впечатления отнайма как уинтервьюера?


Янанимала ивРоссии, ивАмерике, собеседовала как разработчиков, так ипродакт-менеджеров.

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

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

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

Какие фреймворки нужно использовать в ответах на интервью?


  • SAR (orSTAR) behavioral questions
  • CIRCLE product design questions
  • HEART success metrics (Google framework)
  • AARRR success metrics (startups)
  • RICE (или ICE) prioritization
  • PURSUIT

4совета, что надо сделать впервую очередь, если появилось желание переехать вдругую страну?


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

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

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

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

[Заметил это, когда был вШтатах: много виделся синженерами, ибыл безумно удивлён, как они замотивированы встретиться сомной. Навстрече они радовались, что встретили человека изРоссии, спохожей культурой. Видно, многим этого нехватало. Поэтому совет стем, чтобы заводить знакомства заранее, очень дельный А.И.]

Что ещё полезного можно почитать/посмотреть продактам?


Книги про карьеру:


Каналы наЮтубе:


Полную запись моего вебинара смотрите вот здесь.

Cледующим гостем g-mate будет Денис, Staff Android Engineer из Lyft, который живёт и работает в Сан-Франциско. Он сменил 5 стран за 8 лет карьеры в разработке и расскажет, стоило ли оно того.
Подробнее..

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

09.09.2020 10:06:55 | Автор: admin
Запуская свои первые эксперименты, я считала, что все эти три / пять / семь самых популярных ляпов, о которых читала в статьях и слушала на конференциях уж точно не про меня. Тем более в дизайне теста помогал большой красивый шаблон исследований, принятый в компании.



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

Хотела нанести пользу новым пользователям, но они вели себя естественно не так, как задумано


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


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

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

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

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


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

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

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


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

Два этапа слились в один, и оказалось, что мы не можем их разделить. Пришлось перезапускать тест и логировать ключевой этап зашли в квест. Мы узнали, что в него заходили около 10% пользователей. Значимого роста метрики не случилось: квест канул в лету, саму проверку оборудования в итоге встроили в онбординг при глобальном редизайне. А я теперь проверяю на старте, будут ли у меня данные обо всех ключевых этапах воронки.

Не спрашивала себя А раскатить-то сможем?. Или история про звонок, который и правда очень важен для нас


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

Поэтому перед каждым занятием методисту нужно найти ученика, который готов к созвону: для этого система выдает ему несколько контактов, и преподаватель их обзванивает. Это отъедает 12-15% времени, которое человек может потратить на что-то более полезное или приятное.

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

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

Мы хотели сделать опыт пользователя максимально бесшовным.


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

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


В пиковые моменты ситуация напоминала классическую игру) За фото спасибо Википедии и ее контрибьютору perepelin30.

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


Запускала тест, проверяла, что все идет нормально, шла разгребать кучу текущих задач


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

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


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

Рост числа вводных уроков без срывов не значит роста конверсии в оплату. Нужно прикинуть ROI. Для этого проведем эксперимент:

  • рандомно поделим все заявки по детскому направлению на две группы,
  • родителям в первой группе не отправим ничего у них обычный флоу,
  • родителям в другой группе отправим два смс-напоминания: за 24 и за 1-2 часа до начала урока.

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

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



Если мы хотели делить 50 на 50, то красный график явно говорит что-то пошло не так.

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

p.s. Я очень надеюсь, что этот текст поможет кому-то совершить меньше ошибок в своих тестах. Скорее всего у вас будут или уже есть свои забавные кейсы: будет круто, если вы когда-нибудь тоже ими поделитесь!

p.p.s. Пост основан на докладе в ростовском ИТ-комьюнити RnDTech если вы живете где-то на юге страны, присоединяйтесь, ребята делают отличный движ.
Подробнее..

Кто такой продакт-менеджер?

09.09.2020 14:04:11 | Автор: admin

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

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

Кто такой продакт-менеджер

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

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

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

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

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

Так выглядит типичный менеджер продукта Так выглядит типичный менеджер продукта

Какую роль выполняет product manager

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

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

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

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

Продакт-менеджер придумал что-то крутое Продакт-менеджер придумал что-то крутое

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

Какими навыками должен обладать менеджер продукта

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

Стратегическое мышление

Один из ключевых скиллов product manager, который применяется для генерации идей и создания стратегии развития.

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

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

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

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

Построение коммуникаций

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

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

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

Ведение документации

Создание продуктов не обходится без ведения документации. Продакт, как руководитель, должен уметь ориентироваться в ней и составлять новую. Чаще всего, product manager сталкивается со следующими типами документов:

  • предпроектная описание идеи, круг обязанностей, техническое задание;

  • проектная план выполнения работ, технический контроль, график;

  • рабочая / исполнительная подробное описание продукта, отчеты о выполненных работах, чертежи, графики, дополнительные планы, отдельные задачи;

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

  • бухгалтерская (редко).

Работа с подрядчиками

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

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

Какие обязанности выполняет продакт-менеджер

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

  • сбор информации;

  • формирование практических выводов;

  • выведение требований к продукту;

  • создание рабочего плана, распределение ролей между персоналом;

  • продвижение и реализация продукта.

Зона ответственности продакт-менеджера:

  • проведение рыночных исследований, анализ рынка для определения основных потребностей клиентов;

  • реализация продуктовых линеек, тестирование новых идей;

  • проведение конкурентного анализа, сравнение аналогичных продуктов по многочисленным характеристикам;

  • проработка маркетинговых коммуникаций;

  • взаимодействие с директором по продажам для создания стратегии продаж;

  • работа с клиентами и отделом продаж для оценки результатов реализации;

  • формирование долгосрочных и краткосрочных прогнозов продаж, предоставление аналитики руководству;

  • вывод новых продуктов на рынок, анализ рентабельности (ROI);

  • создание маркетинговой стратегии совместно с маркетологами;

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

  • составление графика и определение эксплуатационных требований;

  • C62C

  • C63C

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

  • Анализ рынка мобильных платформ, определение самых востребованных.

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

  • Планирование основных этапов разработки в соответствии с первоначальной концепцией.

  • Сбор команды, определение проджект-менеджеров на каждый этап.

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

  • Контроль и оценка выполненной работы.

  • Выход на рынок, запуск рекламной кампании приложения.

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

Как оценивается эффективность работы продакт-менеджера

Работу product manager оценивают по нескольким критериям, которые разделены на две группы: внутренние и внешние.

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

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

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

KPI

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

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

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

  • Активные пользователи. Оценивают, сколько людей ежедневно используют продукт.

  • Customer Retention Rate (CRR). Коэффициент удержания новых пользователей, ведь важен не только прирост, но и количество оставшихся людей.

  • ROI. Показатель рентабельности доходов по отношению к рекламным расходам. Показывает, окупились вложенные средства или нет (показатель должен быть больше 100%).

Некоторые компании дополнительно оценивают эффективность работы product manager по срокам разработки, успешности запуска пилотной версии продукта и т.п.

Рынок профессии

В начале статьи говорили о популярности профессии и ее востребованности. Рассмотрим некоторые статистические данные:

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

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

Еще больше о том, как стать продакт-менеджером, можно узнать на нашем годовом курсе Профессия: Продакт-менеджер

Узнать подробности!

Подробнее..

Recovery mode Как понять, что новая фича принесет пользу продукту, а не навредит ему?

10.09.2020 16:11:14 | Автор: admin

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

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

Что такое Feature/Product Fit?

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

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

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

Определяя product/market fit есть три основных компонента:

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

  • Монетизация. Возможность и конкретные способы заработка на привычке пользователей.

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

Кстати, недавно мы подробно рассказывали, что такое product/market fit, для чего он нужен и как измеряется. Советуем почитать для лучшего понимания определения ценности и полезности новых функций.

Feature/product fit показывает, вписывается ли новая фича в общую концепцию продукта:

  • У функционала должен быть свой механизм возвращения.

  • Должна быть своя измеримая активация.

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

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

Поэтому задача команды еще на стадии планирования определить, как повлияет новая функция на продукт в целом. Поможет ему вырасти или нет. Для оценки этого используют показатель feature/product fit.

В чём заключается работа команды?

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

Хороший пример работы ориентирование на продукт, поиск подходящего места новой фичи в приложении или сервисе. Иными словами определение своего feature/product fit.

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

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

Чего команде стоит избегать в работе?

Более подробно остановимся на ошибках, которые чаще всего совершают команды. Избегайте их и тогда сможете достичь feature/product fit.

Рассылки обзора нового функционала всей базе клиентов

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

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

Рассказывать всем о новой функции

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

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

Преждевременная публикация новостей о новой фиче

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

Многие фичи не пройдут отбор

Не все функции, реализованные командой, приживаются в продукте и работают долгое время. Если новая фича не соответствует feature/product fit, удаляйте ее без угрызений совести. Росту продукта она не поможет, тогда в ней нет смысла.

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

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

Но со временем аудитория ВКонтакте поняла, что в этом нет никакого смысла. Когда фича перестала соответствовать feature/product fit, ее убрали (это было аж в мае 2011 года!).

До 2016 года в социальной сети Pinterest в каждой карточке были кнопки Like и Save. Но многие пользователи не понимали разницы между ними, думая, что нажатие Like автоматически сохраняет изображение в их галереи. Это приводило к неудовлетворенности некоторой части аудитории, поэтому в компании приняли решение удалить кнопку Like.

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

Каким был Instagram раньше (сложным и непонятным) и каким простым стал Каким был Instagram раньше (сложным и непонятным) и каким простым стал

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

В физических продуктах feature/product fit также имеет место. Например, раньше все iPhone выпускались с физической кнопкой разблокировки экрана. Но в 2017 году в компании от нее отказались, отдав предпочтение Face ID (разблокировка сканером лица). Этому решению способствовала тенденция дисплеев с минимальной или полностью отсутствующей рамкой. Чтобы улучшить продукт в целом, Apple отказались от старой фичи.

Как найти фиче место в продукте или Feature/Product Fit?

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

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

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

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

Аналогичным образом действовал Instagram перед запуском IGTV. Одной из проблем сервиса были короткие видео. Из-за этого хромала вовлеченность, а часть аудитории отдавала предпочтение YouTube из-за своих кумиров, которые там размещали длинные видео.

Так появился IGTV, который сегодня используют для публикации длинных роликов (более 60 секунд). То есть изначально компания провела анализ, узнала, чего не хватает пользователям, а затем придумала функционал для закрытия потребности. После нескольких тестов и достижения feature/product fit фичу растянули на всех пользователей.

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

The Feature/Product Fit чеклист

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

  • Какие есть данные по использованию этой фичи?

  • Что говорят пользователи об этой фиче?

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

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

  • Какие стимулы я могу использовать, чтобы активировать в фичу?

  • Как люди могут помочь активировать в фичу?

Когда вы убедились в соответствии feature/product fit, задайте себе еще несколько вопросов:

  • Какой у этой функции retention? Достаточный ли?

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

  • Как сделать этот функционал доступным только для них?

  • Какую измеримую стратегию активации в эту фичу можно применить для этих пользователей?

  • Как эта фича влияет на возвращение, вовлечение и монетизацию основного продукта?

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

Для нового и старого функционала измеряйте feature/product fit. Это можно делать примерно так же, как с product/market fit. Об этом мы подробно рассказывали ранее.

Перед выкатыванием новых фич на всю аудиторию проверяйте, повышают ли они ценность продукта в целом. Если нет, отказывайтесь от внедрения. Пользуйтесь описанным выше чеклистом для упрощения проверки. А если у вас остались какие-то вопросы по feature/product fit, пишите их в комментарии, мы с радостью ответим.

Еще подробнее о Feature/Product Fit можно узнать на нашем годовом курсе Профессия: Продакт

Узнать подробности!

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru