Розыгрыш хорошей книги

UPD: Книга разыграна

Мы с друзьями из издательства «Альпина Паблишер» предлагаем вам в подарок супер-полезную книгу об UX-писательстве «Этой кнопке нужен текст».

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

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

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

Вы получаете отличную книгу в подарок + промо на моем канале. С вас – прочесть книгу и написать мини-конспект.

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

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

#партнерскийпост

121. Переписывайте продукты по частям

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

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

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

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

122. Лучше просить прощения за то, что сделал

Смотрел как-то фильм про полицейских или ФБРовцев, не помню точно. Там коп должен спасти хороших и арестовать плохих, но для этого ему нужно нарушить букву закона. Ворваться без ордера и найти улики. Но если улики не найдет, то его могут уволить. Он решается, потому что от бездействия будет только хуже. Перед этим говорит напарнику: «Лучше просить прощения за то, что сделал, чем за то, что не сделал».

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

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

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

Продукт запустили. Меня ругали за это. Я извинялся. Ведь лучше просить прощения за то, что сделал.

Книга разыграна

Неделю назад мы решили разыграть книгу «Этой кнопке нужен текст». Книга будет полезна всем, кто связан с разработкой IT-продуктов – техническим писателям, UX/UI-дизайнерам, менеджерам, маркетологам, программистам и т.д.

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

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

А всем остальным остается только купить книгу на сайте издательства «Альпина Паблишер». 399₽ в электронном виде или 610₽ в бумажном.

#партнерскийпост

Есть коллективный твиттер «Менеджер продукта». Это площадка, на которой разные люди из индустрии делятся опытом. Каждую неделю у аккаунта новый автор, который каждый день раскрывает какую-то тему через серии твитов и общение с подписчиками.

На этой неделе я – ведущий этого твиттера. Темы на «моей» неделе такие:

1. Планируем квартал.
2. Спринт: планинг, груминг, стендап, ретро, демо.
3. Проверка фич и статистика.
4. Плохая/хорошая команда.
5. Эксперименты.
6. Технический долг.
7. Кто такой менеджер продукта.

#УголокТщеславия

123. А/Б-эксперименты без стратегии – путь в никуда

Раньше я считал А/Б-эксперименты вредной ересью. Сначала дизайнер с любовью и вкусом создает продукт, например, сервис по бронированию отелей. Потом устраивают 200 тестов «какая кнопка принесет больше покупок, красная или синяя» и в результате получают неудобного и некрасивого монстра. Множество маленьких полезных улучшений не приводят к хорошему результату.

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

В результате я примерил два подхода:

1. Если не понятно, куда развивать продукт стратегически, мы генерируем из головы хоть какие-то идеи и на их основе проводим количественные А/Б-эксперименты и качественные UX-исследования. Цель – провалидировать идеи и понять «в какую сторону бежать».

2. Когда понятно, в какую сторону развивать продукт, надо писать стратегию и дальше двигаться под ее руководством. Анализировать все новшества качественно (UX-техники) и количественно (аналитика).

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

Если совсем коротко: А/Б-эксперименты без стратегии – вредны. Но они помогают с идеями на ранних этапах и помогают не заблудиться на поздних.

124. Закон Мёрфи в разработке продуктов

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

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

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

Однажды фичу решает посмотреть САМЫЙ-БОЛЬШОЙ-НАЧАЛЬНИК, это может быть главный инвестор или какой-нибудь председатель совета директоров. Он не пользовался продуктом уже полгода, но тут решил зайти на пару минут. Именно в эти пару минут он находит самую ужасную ошибку из всех виденных ранее.

Мы столкнулись с частным случаем закона Мёрфи:
Чем выше начальник, тем критичнее проблема, которую он обнаружит.

125. Допустимая ржавчина

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

У моего коллеги была крутая тачка – девятка. Она была достаточно новая и совсем не ржавая. Я завидовал ему всеми оттенками зависти. Однажды я увидел, что на его прекрасно-нержавой машине дворники покрыты ржавчиной. Я очень удивился и спросил: «Почему ты не заменишь дворники, это же недорого?»

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

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

Коллеги ворчат, мол, зачем это все, формализм ведь, толку никакого. А я улыбаюсь и говорю: «Лучше пусть бюрократия будет здесь, чем в нашем продукте».

126. Советоваться нужно, но сложно

Мне всегда нравился этот отрывок из Притчей Соломона:

Предприятия получают твердость чрез совещание, и по совещании веди войну. (Притчи 20:18)

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

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

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

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

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

127. Когда нужно разделить команду

С точки зрения пользователя у компании может быть один продукт, например, агрегатор объявлений об аренде квартир. Но внутри – это много разных продуктов: сборщик объявлений с разных площадок, система для модераторов, приложение под iOS, приложение под Android, веб-портал, биллинг, система для работы с корпоративными клиентами. У каждого такого «внутреннего» продукта может быть своя команда разработки, свой менеджер продукта и собственные бизнес-метрики.

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

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

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

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

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

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

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

Где в нишевых товарах собака зарыта

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

Товары хвоста могут пользоваться стабильным спросом, но емкость их рынка ограничена, а потребители разрознены. Тем не менее, инновации (например, 3d-печать) повышают доступность производства мелкосерийных изделий, а маркетплейсы и новые решения в логистике (например, развитие доставки последней мили) упрощают процесс попадания таких товаров к потребителям. В итоге «хвост» утолщается и становится конкурентоспособной альтернативой «телу». Потенциально внутри хвоста сидят и нишевые товары массового спроса, пока не способные конкурировать с крупными брендами. Многие станут покупать зубную пасту и туалетную бумагу от нишевых производителей? Сейчас – вряд ли. Ведь помимо решаемых уже сейчас вопросов производства и доставки, есть более сложная проблема доверия.

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

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

На своем канале @disruptors_only я рассказываю про инновационные практики, меняющие бизнес и нашу жизнь в целом.

#партнерскийпост

128. Когда надо остановить или закрыть продукт

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

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

А потом наступил 1991 год, рухнул Советский Союз, а вместе с ним система детско-юношеских спортивных школ. Тренировки прекратились. Другой секции в моем городе не было.

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

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

А прекрасная продуктовая команда пусть начнет заниматься новым продуктом.

Просить прощения авансом

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

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

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

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

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

129. Уйти ответственно

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

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

Через полгода позвонили:

– Привет, не подскажешь, где исходник взять?
– В такой-то папке.
– А где она?
– Я же вам отдал! По такому-то адресу в корпоративной сети.
– Ой, да… Хорошо, что есть такое.

После этого еще пару раз звонили, и этот разговор повторялся.

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

В течение года пару раз звонили:

– Ой, а помнишь мы вот это делали, где материалы?
– В такой-то папке.
– А где она?
– Я же вам отдал! По такому-то адресу в Гугл документах.
– Ой, да… Хорошо, что есть такое.

130. Горизонтальный рост для продакта

Менеджер продукта может расти вертикально: отвечать за группу продуктовых команд или стать директором по продукту, CPO или даже CEO. А может расти горизонтально – открывать новое, не меняя должность.

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

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

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

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

Ранее я писал про майндсет и чеклист при передаче продукта.

131. О туалетах и управлении продуктами

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

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

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

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

Мне подумалось, что продуктовым командам, когда они внедряют новые фичи и переходят на новые фреймворки, стоит задаваться вопросами: «А не ходят ли мои пользователи с грязными и мокрыми руками?»

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

Я работаю на фрилансе, поэтому всегда рада новым интересным проектам. Пару моих работ можно посмотреть здесь: behance.net/a_l
————————————

10 идей из книги «Этой кнопке нужен текст»

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

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

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

4. Писать нужно лаконично и понятно, но не обязательно кратко. Понятность текста в приоритете.

5. Голос и тон продукта – то, что делает его «живым». Иногда нужно добавить юмора или сочувствия. А чтобы не запутаться в том, как должен разговаривать продукт, используйте гайдлайны.

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

7. Интересный способ для проверки понятности текста – клоуз-тест. Надо дать людям интерфейсный текст с пробелами (примерно каждое третье слово) и описать ситуацию, а затем попросить заполнить пропуски. Если результат совпадает с исходным текстом хотя бы на 60-70%, то всё хорошо, иначе текст стоит переписать.

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

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

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

#КонспектКниги

Какая профессия хайпанет следующий?

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

Когда я стал запускать и развивать продукты, таких вакансий не было на Хедхантере. Сейчас, спустя 8 лет, менеджер продукта – одна из самых популярных профессий. Все их хотят нанять. Все на них учат. Старые знакомые, кто раньше был маркетологами и программистами написали в графе должность «менеджер продукта».

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

Посоветуйте, уважаемые читатели.

132. День рождения в офисе

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

У меня в команде 10 человек. Еще есть коллеги-продакты и коллеги из других департаментов, с кем постоянно пересекаемся по работе, где-то 25 человек. Отдельная каста – начальники, их не много, человек 5. Это все близкие люди, а не просто едва знакомые коллеги.

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

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

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

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

133. Как проводить опросы

Продуктовые команды постоянно создают что-то новое, экспериментируют. Конечно, лучше делать выводы на основании численных метрик: MRR, ARPPU и т.д. Но бывают случаи, когда метрики не показательны и приходится опираться на отзывы пользователей. Например, мы решили изменить внешний вид главной страницы: для новых пользователей хорошей метрикой будет количество первых платежей, а для старых – Churn Rate + отзывы. Можно выкатить новую версию на 10% старых пользователей и понять, как сильно они будут ругать или хвалить новый дизайн. Расскажу, как я провожу такие опросы.

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

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

Критерии успеха заранее. Важно определиться с критерием успеха до начала эксперимента. Задайте себе вопрос: «Если 50% пользователей будут ненавидеть новую версию, мы оставим ее?» Если ответ отрицательный, то попробуйте уменьшать цифру до тех пор пока вы и ваши стейкхолдеры не согласятся, что, к примеру, 30% негативных отзывов вполне приемлемы. После этого определите минимальный порог количества участников. К примеру, я решил, что если в опросе участвовали менее 1% пользователей, то я вообще не смотрю на долю негативных отзывов.

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

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

134. Умеренность в тирании

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

Хочется подсказать этому историческому тирану: «Чувак, ты добился отличных результатов, пора остановиться, дать послабления народу, раздать дары соратникам и заняться благотворительностью». Но тиран не слышит и строит очередную пирамиду до тех пор, пока его не поднимут на вилы.

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

Мы успели. К концу у разработчиков дергался глаз, а дизайнеры пару раз вызывали меня на разговор «так жить нельзя». Но бунта против бесчеловечной тирании не произошло. Я дал всем отдохнуть, перестал подгонять дизайнеров и выполнил все их требования. Разработчиков отпустил заниматься рефакторингом и другими тайными удовольствиями. Через пару недель вернулись в обычный темп.

Лучше не быть тираном. Но если уж стал, то умей вовремя остановиться.