330. Как знакомиться на конференциях

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

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

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

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

Так хоть с кем-то познакомитесь и подружитесь. Насколько это полезно — другой вопрос, о нем в другой раз.

329. Одно подтягивание в день

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

Я хорошо запомнил этот принцип «начни с малого и прямо сейчас». Видимо позитивное подкрепление едой работает, и Павлов со своими собаками был прав.

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

Тренироваться сложно. Но одно подтягивание в день — кажется посильной задачей.

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

328. Как не быть корпоративным колхозником

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

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

Кстати, не всегда иконки должны быть одного цвета. Внизу этого же экрана в Доке — иконки должны быть разноцветными. Попробуйте сделать их однотонными — будет стильно, но неудобно.

327. В чем сила, HR?

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

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

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

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

P.S. А еще у нас половина людей — зумеры. Это те, про которых рассказывают, что они не умеют работать, брать ответственность, не выходят на связь, тупые, обидчивые и ленивые. У нас таких нет. Видимо какая-то другая порода зумеров, все с точностью до наоборот.

326. Закономерности и внутренние связи

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

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

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

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

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

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

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

325. Девальвация сочувствия

Регулярно общаюсь с поддержкой Teamly (это такая русская замена Notion). Система пока сыровата, работает не всегда стабильно, но вот поддержка у них замечательная. Так и думал про них: «Все через задницу, но хотя бы отвечают живые адекватные люди и проблемы в итоге решаются, так что продолжаем пользоваться, у остальных еще хуже».

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

В ответ нам мой баг репорт они стали автоматом слать такое:

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

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

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

Заявку приняли, разбираемся, ответим в течение получаса.

Сочувствие и извинения — это хорошо. Но поставленные на автомат — они девальвируются и теряют ценность.

324. Успех зависит от квалификации

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

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

Через три месяца мотоцикл снова отдали мне. Оказалось, что на этот раз он даже не едет.

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

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

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

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

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

323. Переодевание шапок
 
В одной компании, где я работал продактом, владелец как-то стал объяснять, что ему не нравится в моем продукте и предлагать, что именно надо изменить. Меня возмутило такое директивное управление и я сказал, что так дела не делаются. На что он ответил:

«Лёша, я сейчас говорю с тобой не как директор, а как пользователь нашего продукта. Я снял с себя шапку директора и надел шапку пользователя». 
 
Дальше у нас это стало внутренним мемом. Мы постоянно говорили: «Я надеваю такую-то шапку».
 
Люди часто путают человека и его роль в компании. Со мной вообще беда, я могу исполнять много ролей: CPO, CFO, CTO, HR, QA, арт-директора, проджекта и безопасника. 
 
Поэтому у коллег возникает ощущение, что любой вопрос надо согласовывать с Лёшей. Но это не так! У каждой роли своя ответственность. Но раз у меня ролей много, то и ответственностей много. Вот и получается, что я «в каждой бочке затычка».
 
Я не придумал ничего умнее, чем объяснять коллегам «про шапки». Что вот, я сейчас не продакт, а арт-директор, а вот сейчас я не «лезу не в свое дело», а исполняю обязанности технического директора. 
 
Костыльно как-то. Но я ничего лучше не придумал.

322. Модный и без напильника
 
Я езжу на старой дешевой Шевроле. По современным меркам там все убого и некрасиво.
 
А еще я довольно часто езжу на каршеринговых китайцах, там попадаются очень даже навороченные и дорогие модели. Огромные экраны, интересный дизайн, эмбиент подсветки.
 
Все эти новомодные навороты — полностью бессмысленные и неудобные. И не надо говорить мне, что я старый дед и привык к традиционным крутилкам. И дело совсем не в том, что в личной машине я провожу больше времени. Я умею отделять личные привычки от объективных проблем.
 
Проблема — в отсутствии у китайцев напильника. 
 
Традиционные автопроизводители годами допиливали старые решения. В результате да, отстали. Но их продукты продуманные и удобные. 
 
У новых китайских компаний одна задача — сделать быстро и чтобы выглядело круче, чем у других. Они привлекают лучших европейских дизайнеров и демонстрируют серьезный рост на гос. субсидии. Но вот годами допиливать нюансы — им не можется. Через пару лет твоя машина не интересна для производителя, он не выпустит к ней улучшения прошивки, да и с запчастями проблема. Хочешь лучше — покупай новую модель. 
 
В цифровых продуктах тоже самое. У какой-нибудь мега корпорации за миллиард денег пишется модный молодежный продукт с крутыми программистами и дизайнерами. Все ахают, но потом оказывается, что есть куча проблем (что ОК), которые никто не торопится править (что не ОК). Мы тут искали российскую замену для видео созвонов. Альтернатив, вроде много, но какое-то все «китайское».
 
У всех продуктов своя судьба и причины поступать так или иначе. Но лично я предпочитаю допиливать годами и постепенно улучшать. И продолжаю ездить на старой Шевроле.

321. Численность команды и стадии ее развития
 
Стадия 1. Идеальное число продуктовой команды — пять человек. Пятерых легко собрать, а собравшись, они способны действовать быстро, умело и тихо. Четверым из них можно поручить кодить. Пятый, не сведущий в этом, станет менеджером.
 
Стадия 2. Как ни удобно число пять, нередко в команду входит семь, а то и девять человек. Трое кодят, двое тестируют, один скрам мастер. Со свободным от дела продактом получается семь человек. Остальные двое, по-видимому, нужны для красоты. Мы практически ничего не знаем о назначении двух молчаливых членов, но у нас есть основания полагать, что на этой, второй, стадии команда без них работать не может.
 
Стадия 3. На третьей стадии в команду входят новые люди, иногда они вроде бы знают ещё что-то нужное, но чаще просто начинают вредить, если их в команду не взять. Чтобы их утихомирить, приходится непрестанно с ними советоваться. По мере их включения число членов ползёт от десяти к двадцати. На этой третьей стадии дела идут много хуже. Прежде всего, очень трудно собрать столько народу.
 
Лишь немногие из членов отбирались с расчётом на то, что они будут или могут приносить пользу. Большую часть взяли, чтобы угодить какой-нибудь внешней группировке, и задача их — сообщать своим, как идут дела. Чем крепче утверждаются ненужные люди, тем громче требуют обойдённые группы, чтобы ввели их представителей. Число членов переползает в третий десяток. И команда вступает в четвёртую, последнюю стадию.
 
Стадия 4. Когда в команде от 20 до 22 человек, она внезапно претерпевает особое превращение. Пять полезных членов встречаются отдельно и что-то решают. Остальной команде практически нечем заняться, тем самым в нее можно ввести сколько угодно народу. Лишним членам не понадобится лишнее время, ибо все митинги теперь — пустая трата времени. Внешние группы довольны, их ставленников принимают беспрепятственно, и не скоро поймут они, что победа их призрачна. Двери открыты, число участников приближается к 40, растёт дальше. Может оно дорасти и до тысячи. Это уже не важно. Команда больше не команда, и прежние ее функции выполняет другое, малое сообщество.
 
Си́рил Норткот Па́ркинсон, 1957
 
(я немного перефразировал, заменив слова “кабинет (министров)” на “команда” и добавил современных реалий)

320. Кто не ответил, я не виноват!

Вам знакома боль от обращения в саппорт? Когда у них в запасе всё время мира, а у вас только пара минут. Вот как возникает эта несправедливость:
 
1. Пишешь в чат вопрос. Подробно описываешь проблему и шаги воспроизведения.
 
2. Тебе отвечает глупый робот.
 
3. Пытаешься вызвать человека заклинаниями: «нужен человек», «позови оператора», «тупой бот».
 
4. Чат пишет «Подождите, мы зовем человека, он скоро будет».
 
5. Ты ждешь 10 минут, потом отвлекаешься на другие дела.
 
6. Через час вспоминаешь, заходишь в диалог, а там:
 
— Извините, что заставил вас ждать.
— Мне нужно время, чтобы изучить вопрос.
— (не изучил, не прочел то, что я писал) Ответил стандартной отпиской.
— У вас еще остались вопросы?
— Т.к. вы не отвечаете, мы закрываем ваше обращение.
— Дайте знать, если потребуется помощь. (издеваются!)

7. Ты пишешь свой вопрос еще раз и цикл начинается сначала.

Весь этот театр абсурда можно прекратить одним простым изменением:

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

Недавно я помогал настраивать процессы саппорта в Sponsr.ru
— там тикет висит, пока пользователь не ответит «спасибо, все работает». Если помогли, но он не ответил, то в конце концов, тикет закроют. Для простых вопросов ожидание — сутки. Для сложных — три дня. А не 15 минут и даже не час!

Маленький шажок для регламента саппорта и гигантский скачок для клиентского опыта!

319. Мы всё просчитали
 
Среди продуктологов принято опираться на статистику. Типа, мы не просто так пилим фичи, «потому что в них верим», а собираем метрики и проводим измеряемые эксперименты. Всё это говорится немного через губу — подразумевается, что большинство других именно что «пилит фичи наугад».
 
Молодым специалистам (да и старым тоже) стоит помнить, что мы живем в мире, где количество переменных в уравнении успеха — слишком большое, чтобы их просчитать. Поэтому история знает много идиотов, достигших успеха и множество провалившихся гениев.
 
«Результаты измерения подтверждают нашу текущую гипотезу», — говорят ученые.
 
«Делай что должен и будь что будет», — говорят рыцари.
 
«Действуй так, как будто все зависит от тебя и молись так, как будто все зависит от Бога», — говорят христиане.
 
«Мы проанализировали метрики и уверены, что фича залетит», — говорят продуктологи.
 
«У нас сокращения, лучше, если вы уйдете по собственному желанию», — говорят эйчары.

0. У тебя всё получится!
 
Эй! Да, да, вот ты, подписчик моего канала. Именно ты, не другой. Я хотел сказать, что у тебя всё обязательно получится. 
 
Тебе иногда кажется, что ты ничего особого не достиг. Что упустил кучу возможностей. Налажал. Но это все не страшно, впереди много свершений. Да и сейчас ты справляешься просто отлично! Ты — крутой профессионал и замечательный человек. 
 
У тебя всё получился!

318. Кричите: Волки!
 
Старая сказка о мальчике, который кричал «Волки! Волки!», учит нас, что не надо наводить панику раньше времени и предупреждать о гипотетической угрозе.
 
Но кричать «Волки!» очень даже полезно.
 
Я работаю с разными эквайрингами. Это такие компании, через которые проходят платежи банковской картой. Так вот, один из эквайрингов постоянно присылает мне письма: 
 
«Уважаемые пользователи, обратите внимание, что через неделю глубоко ночью в течение пары минут у нас может чуть-чуть что-то не работать». 
 
Этими сообщениями они меня раздражали. Ну зачем предупреждать, что ночью может что-то не работать?! Ночью я сплю и плательщики тоже.
 
Но однажды у другого эквайринга перестали работать платежи. На вопрос, «Что происходит?» они ответили: «Ой, простите, мы ввели ограничение по IP, а вам забыли сказать об этом».
 
Косяки бывают у всех. Но именно этот накосячивший эквайринг никогда не предупреждает о готовящихся обновлениях. У них нет культуры заботы о пользователях, поэтому они забывают даже о критических вещах предупредить.
 
Мальчика, который предупреждал деревню о волках, не стоило игнорировать. Надо было просто подправить ему чувствительность срабатывания алерта.

317. Перекрестные проверки

Заправлял машину и у меня с карты списали сумму два раза. Я позвонил в банк, они сказали: «Ничего не делайте, в течение месяца само решится». Так и вышло. 
 
В цепочке оплаты задействовано куча организаций и технических систем: компания-продавец и несколько его внутренних систем (учет, бухгалтерия, CRM), банк-эквайринг, платежная система, карточная система, банк-продавца. В этой цепочке бывает что-то идет не так. Поэтому участники цепочки делают перекрестную сверку данных, чтобы выявить и исправить проблемы. 
 
Я 20 лет работаю с платежными данными и внутри своих систем тоже использую принцип перекрестных проверок как на техническом, так и на человеческом уровнях. 
 
В Sponsr пользователи платят деньги за контент, система взимает комиссии и начисляет авторам контента их долю. Мы спроектировали три разных системы подсчета, которые проверяют друг друга. Все три системы технически и человечески независимы. Т.е. если в одной есть ошибка, вторая покажет. Если один человек ошибся, другой из другого отдела, это увидит.
 
Перекрестные проверки помогают вскрывать несоответствия и исправлять ошибки. Применяйте их два раза в день. Лучшие стоматологи рекомендуют!

316. Раньше было лучше без AI
 
Здравствуйте, молодые и прогрессивные! Это я, дед Лёша, хочу побухтеть по-стариковски, как всё стало плохо и как раньше было лучше.
 
Был тут на хорошей конференции Product People, там некоторые докладчики рассказывали, как они используют AI для продуктовой работы. Я думал будут рассказы о расшифровке голосовых интервью или написания саммари встреч. Больше! Речь шла про генерацию продуктовой стратегии, аналитике и принятии решений о персонале.
 
Вот пара мыслей, почему я считаю это полной шляпой.
 
1. Атрофия устройства вывода
 
У человека есть ввод (чтение, слушание, смотрение) и вывод (говорение, писание, жестикуляция). Очевидно, что скорость вывода — сильно меньше скорости ввода. Поэтому вы уже поняли «что он хочет сказать», а собеседник все говорит. И поэтому читать сильно быстрее, чем писать.
 
Более того, у людей без навыков, скорость вывода в профессиональных задачах может падать до нуля или даже быть отрицательной. Именно поэтому большинство людей «не умеют писать сочинения» или даже «объяснить, чего надо».
 
И вот теперь поколение людей, которое плохо говорит и пишет, начинает активно использовать AI, чтобы оно за них.... говорило и писало. Минимальные упражнения «на вывод информации» — сойдут на нет. И профессионалы превратятся в тех собак, что всё понимают, но сказать не могут.
 
2. Иногда надо потерять время на «потупить»
 
Я иногда часами смотрю на цифры статистики. Просто так, без дела. Иногда просто размышляю о стратегии или ситуациях в команде. Просто так, без повода.
 
И вот это «спокойно потупить» (некоторые называют это медитацией), готовит твое сознание к обдуманному решению. Твоему личному решению. 
 
И именно это некоторые отдают нейросети. 
 
Жену тоже будете с чатом жпт выбирать? Что говорите, уже выбрали? Ну-ну.
 
Обнимаю, искренне ваш, дедушка.

Поговорки продуктолога
 
Лучше зарплата в руках, чем премия в конце квартала
 
Кто старое помянет – тот олд
 
Кто легаси рефакторил, тот в цирке не смеется
 
Всяк HR своё болото хвалит 
 
Сколько разработчика ни корми, он все равно резюме обновляет
 
На фрилансе, да не в обиде
 
Рекомендованному разработчику в резюме не смотрят
 
Нет хука без Гита
 
Любопытной Варваре сделали выгодный джоб оффер
 
Кто рано встает, тот быстро устает
 
Не фичей единой жив пользователь
 
Что имеем – не храним, без бэкапов – плачем 
 
Век живи – век учись в {partner_school_name}
 
Любишь фичи релизить, люби и тех. долг отдавать
 
От инвестиций, да от юстиций не зарекайся
 
Бадди познается на корпоративе
 
Кто на удалёнке, тот не пьет шампанское
 
Заставь айтишника праздники отмечать, он себе аптайм расшибёт
 
Семь бед – один ресет
 
Детей по смартфонам считают 
 
Где родился, там все креды уже выданы
#ПоговоркиПродуктолога

315. Про юристов и мёртвых мух
 
Мне тут спам пришел в одной соц. сети. Пишет незнакомый владелец юридической конторы, мол, расскажи с какими юристами работаешь и какие сложности возникают. Такая прелюдия к рекламе, так что я даже отвечать не стал. Но внутри задумался.
 
Я работаю с несколькими юр. фирмами. Вопросы разные, корпоративное право, авторское право, налоги, недвижка. Люди разные. Процессы разные. И вот я задумался, а действительно, всё ли меня устраивает? Что не так с юристами?
 
И с удивлением понял, что у меня нет претензий по их работе, зато есть куча раздражающих мелочей в коммуникациях.
 
Прямо вот детсадовских мелочей:
 
— Очень хочется, чтобы юристы соблюдали сроки. Вот если обещали сделать что-то к среде, к среде и сделали. А если никак, то хотя бы предупредили.
 
— Очень хочется, чтобы отвечали в чате и почте. Бывает такое, что имидж вечно занятого человека, который иногда просто перестает пинговаться и куда-то пропадает.
 
— Очень хочется, чтобы общались лично. Не могу понять концепцию, когда надо писать на какой-то общий адрес, откуда тебе отвечают несколько разных людей и ты даже не понимаешь, с кем будешь общаться в следующем письме.
 
— Мечтаю, чтобы юристы присылали нормально оформленные документы и таблицы. Хуже оформляют только в муниципальных учреждениях.
 
Список можно продолжать, но думаю вы поняли. 
 
Я не к тому, чтобы поворчать (ну ок, чтобы поворчать тоже). Моя мысль в том, что иногда мелочи делают неприятным в целом крутой продукт и результат сложнейшего труда. 
 
Как хорошо сказал царь Соломон:
Мертвые мухи портят и делают зловонною благовонную масть мироварника: то же делает небольшая глупость уважаемого человека с его мудростью и честью.
 
Я бы хотел знать о «мертвых мухах» моего продукта, моей работы, коммуникациях со мной.

314. Пока жареный петух не клюнет
 
Нам надо серьезно поговорить.
 
Хуже всего с информационной безопасностью у тех, у кого она должна быть на высоте:
– юристов
– риэлторов
– HR-ов
– бухгалтеров
 
Они постоянно получают и отправляют договоры, сканы паспортов и прочую чувствительную информацию. И делают это через вотсап или личную почту. Это все хранится «у Лены на айфоне» или ноутбуке. Эти устройства часто даже экран не блокируют. На них играют дети. Они доступны случайным прохожим. Эти устройства периодически теряются. 
 
Вот вы устраиваетесь на работу или оформляете договор ГПХ и отправляете HR-у сканы документов. Будьте готовы, что они останутся на телефоне у условной Лены, а этот телефон потом могут продать на Авито вместе со сканом вашего паспорта.
 
И когда со страховым агентом оформляете полисы — тоже самое. И с риелтором. И т.д. и т.п.
Ждать, что они будут соблюдать информационную гигиену — не стоит. Они как правило даже не понимают о чем речь. Юристов, правда, можно пугнуть неисполнением закона о персональных данных, но смысла в этом мало.
 
Так что позаботьтесь хотя бы о себе:
 
– Ваши телефоны и компьютеры должны блокировать экран автоматически. Телефоны обычно блокируют, а вот компьютеры — почти ни у кого.
 
– Документы отправляйте только по корпоративной почте (никаких телег и вотсапов). Если корп. почты у получателя нет, отправляйте на личную (что хуже).
 
– Отправляя паспорта, напишите поверх скана КОПИЯ, не то, чтобы спасет, но хоть что-то.
 
– Приложения на телефоне с чувствительными данными защищайте отдельным пин кодом или еще лучше зашифрованым хранилищем.
 
– Поставьте пин код на симку в телефоне. Без этого любой, у кого есть скрепка и 30 секунд наедине с вашим телефоном — получит доступ в ваш банк и мессенджеры.
 
– В телеграме установите пароль (в дополнение к логину через смс).
 
– Зашифруйте диск вашего ноутбука и компьютера. На маке это делать легко через FileVault. Без этого тот, кто вытащит диск из ноута — получит все данные без пароля.
 
Это все — самые-самые азы. Но большинство людей этого не делает. Даже программисты у которых все ваши исходники и доступ в боевую базу данных.

313. Научное исследование: профилактика хронического стресса
 
Любой руководитель сталкивается с хроническим стрессом. IT — одна из наиболее опасных областей из-за высокой динамики изменений и ненормированной рабочей недели. Последние три года участвовал в масштабном исследовании по диагностике и профилактике хронического стресса, проводимом НИИФ при министерстве здравоохранения.
 
Я не связан с медициной и попал в исследование как подопытный. Дело в том, что я давно езжу на мотоцикле, а для исследования нужны были именно такие люди. Сейчас объясню.
 
Лобная доля головного мозга отвечает за принятие решений, организацию и планирование, контроль сложных интеллектуальных процессов — у руководителей это постоянно задействовано. В результате работы этот участок мозга постоянно перенапряжен и находится в стрессе. Ученые давно ищут метод «расслабления» и нормализации лобных долей. 
 
Академик Байдаков еще 40 лет назад выдвинул гипотезу, что при резком ускорении мозг немного сдвигается назад в черепной коробке, при этом снижается давление на лобные доли. Он проводил исследования на военных летчиках и парашютистах. Но из-за развала СССР опыты прекратили.
 
В наши дни исследования стали проводить на мотоциклистах. Ускорения на мотоцикле почти такие же как у пилотов, а выборка гораздо больше. Кроме того, сложно найти руководителя-парашютиста, а руководителя-мотоциклиста — вполне реально. 
 
Три года принимал участие в эксперименте. Выпускал релиз, потом садился на мотоцикл и гнал в закат. Все это с прилепленными к телу датчиками и с постоянным заполнением анкет. Но чего не сделаешь ради науки!
 
Но главное, метод работает! Езда на мотоцикле уже введена (пока факультативно) в программы курсов переподготовки руководителей при НИИФ. Я рад, что участвовал в этом эксперименте. 
 
Если кто не боится научных статей, вот ссылка на исследование.

312. Адресно и конкретно
 
Бывает такое, что есть задача, в ее решении задействовано куча специалистов из разных отделов и организаций, проходит время и куча совещаний, тонна переписок, а задача не решается. 
 
Интересно, что такие задачи бывают во всех сферах деятельности. Сталкивался и у нас в айтишечке — недавно неделю не могли понять, кто должен настроить почтовую PTR запись, мы или сервис мэйлера. Встречал и при покупке недвижимости — риелторы и юристы со стороны покупателя и продавца при нестандартной ситуации начинают ходить кругами и топтаться на месте. И чем больше людей задействовано, тем запутанней все становится.
 
Врач скорой помощи как-то научил меня, как решать такие ситуации на примере если человеку на улице стало плохо или он попал в аварию. Обычные люди кричат в толпу что-то типа «человеку плохо, помогите». Но это не работает. 
 
Надо обратиться: 
1. адресно
2. конкретно
 
— Мужчина в зеленой куртке, подержите голову.
— Женщина в шляпе, наберите на телефоне 103 и вызовите скорую.
 
Метод работает в любых сферах деятельности.

311. Парт-тайм сотрудники в продуктовых командах
 
Я четверть века руковожу продуктовыми командами. В отличии от проектных команд работа тут идет над одним и тем же условно бесконечно. Поэтому важно, чтобы люди в команде были:
 
— Вовлечены и понимали контекст что и для кого они делают.
— Профессиональны и внимательны, потому что «выстрел в ногу» будет болеть годами.
 
Прийти в команду на пару месяцев и сделать что-то полезное — почти нереально. Пару месяцев обычно уходит на «идеянахожусь».
 
Работать парт-тайм — не вариант по тем же причинам. В продуктовых командах обычно «все знают всё» и для парт-тайм работников это нереально. Если в компании по 3 часовых созвона в день, то парт-таймеру на кодинг просто не останется времени.
 
Так я думал всегда. Пока три года назад бюджет, сроки и критическая ситуация не заставили меня собрать продуктовую команду из парт-таймеров. Просто тогда иначе не получалось. И результат меня радует.
 
Я сократил всю нецелевую активность, прежде всего встречи/созвоны. У команды есть планинг, груминг, дейли, ретроспектива. Но времени на этих встречах они проводят где-то в 3 раза меньше, чем в обычных продуктовых компаниях. 
 
Также стал гораздо лучше работать с декомпозицией эпиков. Если раньше была концепция «вылить что-нибудь полезное в прод 1-2 раза в спринт», то теперь мы релизимся почти каждый день. Чтобы это не превратилось в хаос, я внимательно слежу за тем, чтобы эти мелкие шаги находились внутри мастер-плана и перформили в большую цель. 
 
С разработчиков снята лишняя нагрузка и проще фокусироваться. Но больше ответственности на менеджменте и правильной координации. Думаю, не у всех получится, но схема рабочая.
 
Все, кто работают у нас парт-тайм параллельно работают в другой продуктовой компании. Ребята, кто приходил из заказной разработки (что логично для парт-таймеров) — быстро отвалились.

310. Иерархия бэклога

Когда я не работал в продуктовых IT-компаниях, я думал проблемы там от недостатка идей. Надо просто посоветовать и объяснить, как правильно сделать, и они сразу исправятся. Так думают многие пользователи, поэтому постоянно пишут предложения, что нужно улучшить.
 
Когда работаешь внутри продукта, то понимаешь, что проблема наоборот — в избытке идей. Их так много, что сделать даже треть — нереально. Все идеи записываются в бэклог, это главный рабочий инструмент продуктолога. А на деле — гигантская помойка. 
 
Главная ошибка начинающих продактов — делать задачи по принципу «это нужно и полезно». Задач много, все они так или иначе полезные и нужные. Легко потратить силы команды на мелочи и не достичь ничего значимого. Когда две команды перетягивают канат, побеждают те, что действует синхронно и осмысленно, а не те, кто «старался и устал».
 
Сохранять сфокусированность мне помогает иерархия бэклога и следующие принципы:
 
1. Стратегия. Должно быть понимание, в какую сторону развивается продукт в ближайшие пару лет. Надо сформулировать 1-3 North stars — ключевых метрик/целей. Пример: «Повысить ежемесячную выручку до 100М».
 
2. Эпики. Мыслить надо не фичами, а эпиками. Это значимое достижение, которое можно сделать за несколько месяцев. Например: «Подключить иностранные платежи». Каждый эпик должен внятно переоформить в какую-то North star. Мы планируем по 2-3 эпика на квартал.
 
3. Задачи. Каждая задача должна принадлежать какому-то эпику. Если пришла идея, которую хочется сделать, но она не попадает в запланированный эпик — не делайте ее. Конечно, есть мелочи, которые приходится делать вне очереди, но я слежу, чтобы доля задач «без эпика» была не более 10-20%.
 
Обычно в продуктовом бэклоге сотни и даже тысячи задач. Очень сложно с таким количеством работать. Эпиков же получается штук пятьдесят. Работать с 50 идеями проще, чем с 1000.
 
Если прилетает какая-то идея от пользователя, от исследований или просто осенило — я ищу для этого подходящий эпик и записываю туду. Когда эпик попадет на проработку и дизайн, эта идея будет учтена или отброшена.

309. Много лет на одном месте
 
Моя родственница всю жизнь работала на одной работе. Она закончила институт, после него ее распределили в лабораторию при больнице и там она отработала 35 лет, пока не вышла на пенсию. Думаю, идея устроиться на другую работу у нее даже не возникала. Вполне типичная ситуация для Советского Союза. Хотя мои родители (ее ровесники) много раз меняли работу и даже переезжали в другие города ради карьеры.
 
Не скажу за реальный мир, но у нас в виртуальной IT-вселенной не принято работать на одном месте. 5 лет уже считается много. Я сам не люблю менять работу, и с удовольствием бы работал всю жизнь на одном месте, при условии постоянного разностороннего развития. Но в реальности это не получается и приходится открывать новые горизонты путем смены компании. 
 
Я работал в двух IT-компаниях и двух не IT, где было довольно много людей со стажем по 10-20 лет на одном месте. И знаете, у меня очень смешанные впечатления.
 
С одной стороны я полностью поддерживаю идею работы на одном месте. Люди в моей команде часто работают много лет, а я стараюсь, чтобы им было интересно и они постоянно профессионально росли.
 
С другой стороны, старожилы-долгожители, которых я видел в тех компаниях, производили довольно печальное впечатление. Слабые технические навыки на фоне огромного самомнения, поддерживаемого окружающими. Этакий дилетант с сознанием принцессы. Выглядит печально.
 
Моя гипотеза, что феномен порождается не долгими годами на одном месте, а корпоративной культурой, где не любят брать людей «умнее чем ты» и где должность бьёт перфоманс. 
 
Дворовый кот за годы тяжелой жизни лишь лучше научится ловить мышей. А вот на домашнем корме может разжиреть и потерять хватку. И винить такого кота за то, что он не хочет ежедневно рисковать своими порванными ушами — язык не поворачивается. Но мышей он, как правило, ловить уже не способен.

308. Голосуют ногами
 
Недавно я писал, что отзывы пользователей надо рассматривать через призму продуктовой стратегии. Хочу еще раз порассуждать на эту тему.
 
Большинство отзывов — негативные. Если все хорошо, люди воспринимают это как должное и ничего вам не пишут. А вот если что-то не нравится — жди «обращений граждан». Если у вас только негативные отзывы — это нормально. 
 
Я всегда благодарю за негативный отзыв. Делаю это искренне, ведь критика помогает увидеть свой продукт со стороны и стать лучше. Но стараюсь узнавать детали. Иногда ставят одну звезду и пишут, что полный отстой. Я в ответ благодарю и уточняю, в чем именно «отстой», иногда всплывают очень интересные подробности.
 
Если вам больно и обидно от негативных отзывов, вспомните, что главное голосование пользователей — ногами. Допустим, вашим продуктом регулярно пользуются 100 тысяч человек и каждый месяц вы получаете 1000 негативных отзывов. 99% людей проголосовало ногами «за продукт» и только 1% написал негатив. Впрочем, возможно этот один процент тоже проголосовал ногами за «остаться».
 
Недавно мы перешли с прекрасного Notion на Teamly — отечественный пока очень сырой аналог. Я каждую неделю пишу им в поддержку кучу критики и конкретных предложений. Возможно, я самый занудный и вредных их клиент, который всех достал. Но ногами и деньгами я остаюсь с ними. Критикую регулярно, потому что не теряю надежды, что они изменятся в лучшую сторону.

307. Хороший баг себя проявит
 
Я человек нервный. Очень меня раздражает, когда штора на окне неровно задернута. Или когда в банковском приложении есть колокольчик с непрочитанными сообщениями, ты их читаешь, а он снова делается непрочитанным. Всё незавершенное меня мучает.
 
Когда двадцать лет назад я стал руководить разработчиками, сразу же полюбил расставлять задачи по полочкам. Но в этот светлый праздник постоянно вклинивалась черная туча багов.
 
Баги были везде. Большие и маленькие. Найденный пользователями, начальством, QA и мной лично. Критичные и блокирующие. Минорные и тривиальные. Разные. Но одно было неизменно:
 
БАГОВ ВСЕГДА ДОХРЕНА. Они копились годами. Регулярные ревизии ничего не давали. Сотни и сотни проблем, которые никто никогда не в силах будет исправить.
 
Некоторым коллегам это безразлично. Но я то нервный, я страдал.
 
Однажды на ретро один наш QA сказал, а давайте введем Зиро баг полиси. Я изучил вопрос детально и всесторонне, минуты полторы потратил. И решил, что надо брать.
 
С тех пор я живу счастливо. Если баг не правится за пару месяцев — он удаляется. Не архивируется, не анализируется, а тупо стирается. Как мудро говорят автомеханики про неполадки в машинах «хороший стук себя проявит». Если баг важный, он снова прилетит на доску. А если неважный, то и не жалко.
 
Конечно, подход Зиро баг полиси надо правильно раскурить. Но это вы и сами нагуглите.

306. Фидбек это важно?
 
Продуктологу надо слушать пользователей. Если пользователи просят, значит надо это сделать. 
 
— Мы запилили эту фичу, потому что много пользователей ее просили!
— «Много пользователей» это сколько?
— Ну, постоянно пишут.
— В цифрах сколько?
— 7 человек.
— У вас же 100 тысяч пользователей!
— Ну, один из этих пользователей — наш директор.
 
Сколько процентов пользователей должны написать, чтобы прислушаться? 1%, 10%, 50%? А проценты считать от общего объема пользователей или от тех, кто хоть что-то написал?
 
Продуктолог не просто так получает зарплату. Если бы его можно было заменить голосовалкой или нейросетью — давно бы сделали. 
 
Ну так что с фидбеком делать то? Вот простой алгоритм:
 
1. Надо иметь стратегию развития продукта. Не бояться ее постоянно корректировать.
2. Собирать фидбэк из любых источников.
3. Соотносить просьбы пользователей со стратегией.
4. Если просят то, что помогает стратегии — ставить в план. Даже если 1 человек попросил. Если просят то, что мешает стратегии — не делать, даже если тысяча попросила.
5. Если много пользователей просят то, что не соответствует стратегии, вернуться к п.1.

305. Самописные платежные админки
 
20 лет работаю с продуктовыми системами и везде есть платежи и самописные админки для их контроля и управления. Еще ни разу не встречал продукта без самописной админки для платежей. Не буду разбирать почему так происходит, поделюсь парой советов из моего опыта.
 
1. Упрощенный цикл проектирования и разработки
 
Обычно продуктовая разработка идет так: исследование > ТЗ > дизайн > разработка бэк/фронт > тестирование. Больше всего времени уходит на дизайн, разработку фронта и правку его багов. 
 
Админка — это что-то для себя. Одна должна работать, но не обязана быть красивой и в корпоративной дизайн-системе. Поэтому я не подпускаю к админке дизайнеров и фронтендеров. Цикл упрощенный: ТЗ > разработка бэк > тестирование.
 
Стэк для фронта подбирается такой, чтобы с ним справился бэкендер. Бутсрап css какой-нибудь. Для Лавравеля на PHP и Джанги на Питоне есть фреймворки для админок. Рельсы — вообще лучше всех в плане “сделать админку одним бэкендером за день”. 
 
2. Перекрестные проверки
 
Какие автотесты ни пиши, как ни проверяй — где-то будут ошибки в расчетах. Поэтому надо делать независимые проверки и визуализировать разницу.
 
Например, у нас автор зарабатывает деньги, мы вычитаем из них комиссии и остальное автор выводит в свой банк. У нас есть два независимых расчета: один считает разницу “от последнего вывода”, второй считает “за все время”. Если они расходятся, мы реагируем.
 
Еще есть сверка с бухгалтерией и с эквайрингами. В общем, считай по-разному, в разных системах и сравнивай.

304. Работа без официального графика 
 
У нас в компании нет рабочих дней и часов. 
 
Их нет настолько, что мы про это даже не думаем. Собеседовал кандидата, он спросил про рабочие часы и я потерялся. Долго что-то мямлил, потому что мы с коллегами никогда это не обсуждали. Все сложилось естественным образом. Попробую описать, как мы работаем.
 
ПРО ДНИ
 
У нас есть дейли на 15 минут каждый будний день. В выходные дейли нет и подразумевается, что в выходные мы не работаем. Но некоторые в выходные работают и те, кто на окладе и те, кто сдельно. Зачем и сколько работают, я как руководитель не в курсе, видимо считают, что надо. 
 
В выходные обычно меньше пишем в чат. Но если кто-то написал — никто не против. Ему даже ответят. 
 
Если кто-то недоступен целый рабочий день — он предупреждает об этом.
 
ПРО ЧАСЫ
 
Мы живем в нескольких часовых поясах, 5 часов разницы между крайними точками. Чтобы не путаться время встреч говорим по Москве — часовой пояс офиса. 
 
Подразумевается, что мы все доступны для быстрого ответа и созвона в рабочее время. Но что такое рабочее время никто никогда не обсуждал. Проблем с этим не возникало. Кто-то начинает работать в 8 утра, кто-то в час дня. Наверное, можно считать временем доступности с 12 до 18 мск, но это не точно. Некоторые активно работают и обсуждают в чате что-то ночью.
 
Если кому-то надо забрать ребенка среди дня или куда-то съездить — он не предупреждает об этом, потому что в этом просто нет смысла.
 
ОЩУЩЕНИЯ
 
Все сложилось естественно. Мы не думаем про часы, потому что стараемся фокусироваться на результате. Если возникнут проблемы — обсудим на ретро и решим чего-нибудь.

303. Все на митинг!
 
Я много лет работал в крупных компаниях. Везде была проблема «слишком много совещаний». Особенно у менеджеров, у них день полностью мог состоять из совещаний. Но и технические специалисты тоже жаловались.
 
Проблема не новая и не айтишная. Мой отец всю жизнь проработал на руководящих постах на крупных энергостанциях. Приходил домой поздно, потому что целый день совещания, а вечером все уходят домой и наконец-то можно спокойно поработать. А еще часто «стрелял» у меня ириски или жвачки, чтобы не уснуть на совещаниях.
 
Недавно я пожаловался коллеге-менеджеру из другой компании, что при найме программистов нашей маленькой компании сложно конкурировать с бигтехом. ДМС у нас нет, пятничных вечеринок тоже нет. И вот что он ответил:
 
— У вас много созвонов и общих встреч?
 
— 1 час в неделю груминг для обсуждения задач. 15-30 минут каждый день дейли для текучки. Кажется, что это мало, если сравнивать с моими прошлыми работами.
 
— Вот! Это и есть ваше конкурентное преимущество! Пользуйся! 
 
Я очень удивился. А потом подумал, а ведь точно!
 
Кстати, если у нас кто-то не пришел на дейли — ничего страшного. Это возможность синкануться с командой, а не обязаловка. Никто не ругает, если ты отсутствуешь. Впрочем, обычно все приходят.
 
Не вижу никакой проблемы построить продуктовую команду вообще без встреч. Но мне кажется, это уже перегиб в другую сторону. Увидеть живых людей и понять, что твоя работа кому-то интересна — незаменимо для ментального здоровья.

302. Как нанимать людей и не сойти с ума
 
Есть компании, где программистов нанимают в 9 этапов. Девять, Карл! Может быть это специально сделано, чтобы остались только те, кто хочет работать именно у нас. Или те, кому больше некуда идти. Не знаю. Но уверен, что это сводит с ума. Я как-то 5 собеседований проходил и был довольно близок к помешательству.
 
Ок, девять это перебор. А у вас сколько? Три-четыре, наверное? Предварительный скрининг, тех. собес, собес с командой, битва с финальным боссом.
 
Последние годы нанимаю людей за одну встречу. Проходит она так:
 
— 45 минут техническое интервью. Минут 30 лайв кодинга, минут 15 технических вопросов. Проводит разработчик, я сижу молча. Важно начать именно с технического интервью и именно с лайв кодинга. Есть много людей, кто может заболтать. Но по скорости стука клавиш и шевелению извилин на лайв кодинге обычно все понятно без лишних слов.
 
— 40 минут общего интервью. В начале я говорю: У нас нет цели друг другу понравиться, мы взрослые профессионалы, давай пообщаемся и поищем точки соприкосновения и решим, можем ли мы быть друг другу полезны. 
 
— 5 минут я даю кандидату обратную связь. Прямо и честно. Возможно, я единственный в мире, кто так делает. Также назначаю дедлайн, когда вернусь с решением. Обычно это 2-14 дней.
 
Потом или отказ или офер. Если готовы сделать офер и кандидат готов его принять, приглашаю на дейли с командой. Кандидат слушает дейли и потом представляется и минут 5 болтает с командой. Потом найм. 
 
Одна встреча на полтора часа. Всё. Никто не сошел с ума. Все счастливы.

301. Время на выполнение задачи
 
Избитая истина. Банальщина. Лютая база. Но работает.
 
Многие задачи занимают ровно столько времени, сколько на них выделено. Я пишу один номерной пост в неделю. Все эту неделю мне то некогда, но неохота. Не сказать, что я прокрастинирую. Мне нравится писать, идеи есть, процесс приятен. Но нужно выделить время и без суеты посидеть хотя бы полчаса. И вот это не получается.
 
Через 10 минут мне выезжать на длинную встречу. Поэтому я написал этот пост за 5 минут. Еще 3 минуты проверял. Еще минуту публиковал.
 
Потому что задача занимает столько времени, сколько на нее выделено. Выделил неделю — сделаешь за неделю. Выделил 10 минут — сделаешь за 10 минут.
 
Многие об этом писали. Банальщина. Но работает.

300. Искусство авралов
  
Без авралов работа не делается. Однако, всем хочется работать спокойно, размеренно, предсказуемо. Чтобы все заранее просчитать, предусмотреть и без суеты сделать. И кажется, что авралы получаются только из-за тупого начальника. Ну, еще из-за форс-мажоров бывает, доллар там скакнул или еще чего.
 
Да, обычно авралы возникают именно из-за тупого начальника. Но у умных начальников тоже бывают авралы, потому что они сами их устраивают. Они давно поняли, что если нет дедлайна, к которому «нужно успеть», то все будут жевать соплю бесконечно долго. Включая самого начальника. 
 
А когда есть дедлайн, когда будет что-то страшное, если не успеем, тогда всё раз-раз и сделали. Куда-то подевались прокрастинация, лень, излишний перфекционизм, страхи, непонимание, как это правильно сделать. 
 
В общем, аврал — это хорошо. Но когда он постоянно случается, начальника считают тупым и не хотят в такой компании работать. Искусство руководителя в том, чтобы авралы были регулярными, но не постоянными и перемежались периодами жевания сопли.
 
Секрет руководителей не только в правильном графике авралов, но и в их правдоподобности. Если команда не успела в спринт и от этого ничего страшного не случилось — грош цена такому дедлайну. Нужно, чтобы страшно было. Чтобы мотивировало.
 
Секреты создания правдоподобных авралов с правильной частотой передаются из уст в уста в тайных масонских клубах продуктологов.

299. Что делать, если у тебя много проектов
 
Когда я только начинал входить в профессию, у меня не было заказов, мне не писали рекрутеры, я был никому не нужен. Но когда набрался опыта, то предложений стало много, а времени мало. Подписчики задают вопросы, студенты просят консультацию, рекрутеры предлагают «познакомиться на будущее», партнеры предлагают обсудить новый проект, друзья спрашивают, не могу ли я сделать им сайт, внутренний голос шепчет, шило в заднице колет.
 
Как быть, если времени не хватает? Как решить, на какое предложение откликнуться, а кому сразу отказать? Брать только коммерческие проекты за большие деньги, а остальным отказывать? Игнорировать?
 
С годами я стал придерживаться двух принципов. Почерпнул их из Библии.
 
1. Иногда работать бесплатно
 
Отпускай хлеб твой по водам, потому что по прошествии многих дней опять найдешь его. Екклезиаст 11:1
 
Не вся рабочая деятельность должна приносить мгновенную прибыль. Недавно мне написал незнакомый человек из другого города и другой отрасли. Мол, читаю ваш блог, проконсультируйте меня. Я согласился, помог ему. Он предложил продолжить в виде платных консультаций, но я решил, что не смогу качественно помочь и отказался. Принесет ли это знакомство мне это прибыль в будущем? Скорее всего нет.
 
Я не забываю о зарабатывании денег, но понимаю, что иногда нужно помогать просто так. Поэтому отвечаю на письма незнакомцев или обучаю коллег, даже если знаю, что они покинут компанию. В том или ином виде добро вернется.
 
2. Уметь отказывать
 
Лучше тебе не обещать, нежели обещать и не исполнить. Екклезиаст 5:4
 
Важный урок, что я усвоил за годы — надо уметь отказывать. Были ситуации, когда я набирал кучу заказов и не мог их выполнить. Помню это ужасное чувство, когда надо сознаться, что деньги и время уже потрачены, а результата нет и не будет.
 
До сих пор иногда не рассчитываю силы и перегружаю себя. Чтобы совсем не сделать — такого уже нет. Но большая загрузка выматывает, лишает сил, портит здоровье. Так что иногда лучше «не обещать» и не вписываться в очередной проект.

298. Самый важный навык
 
Менеджер цифрового продукта — комплексная профессия. Нужно знать и уметь много разного. Профессия скорее про «вширь», чем про «вглубь». Но вширь эта должна быть довольно глубокой, так что на освоение требуется лет пять.
 
Времени обычно нет, и хочется понять, что прокачивать в первую очередь — дизайн-мышление или SQL, софт-скиллы или математическую статистику. Есть ли какая-то «серебряная пуля», какой-то самый-самый важный навык?
 
Я склоняюсь к тому, что этот навык — приоритезация задач. Умение решить, чем сейчас важно заниматься, а на что можно забить. 
 
В любом продукте задач на порядок больше, чем ресурсов / времени / людей / средств. Сделать всё, что хочется — невозможно. Хорошо, если вы сделаете 10% от желаемого. Да и 1% тоже неплохо.
 
Так что если вы менеджер, то именно от вас зависит, что войдет в эти небольшие проценты «того, что успеем». На что вы потратите силы свои и команды — на что-то важное или на ненужную ерунду.
 
Так что, главное оружие, которым вам необходимо овладеть — это бритва Оккама.

297. Как войти в профессию и как из нее выйти
 
Учу студентов в маге Вышки. Частый вопрос: «Как войти в профессию, расскажите о своем опыте?» И еще: «У меня диплом финансиста/инженера/маркетолога, смогу ли я стать продактом?»
 
Три мысли:
 
1. Профессию можно поменять. Эту простую идею некоторым сложно принять. Особенно мамам и бабушкам, ведь они скорее всего всю жизнь работали не просто по одной специальности, а на одном предприятии. Сейчас другие времена, можно менять место работы, более того, это полезно для развития. Если соискатель на вакансию работал 15 лет на одном месте — это повод насторожиться. Профессию тоже можно менять, это нормально.
 
2. Можно, но не слишком часто. Менять профессии или места работы слишком часто — плохо. Может быть признаком, что человек вечно всем недоволен и не может довести дело до конца. Нормально менять место работы раз в 1–7 лет. Нормально менять профессию раз в 5-15 лет.
 
3. Путь у каждого свой. Истории успеха полезны только с моральной точки зрения, для вдохновения. Практического смысла в них нет. Вы не станете миллионером, прочитав книгу известного предпринимателя. Вы не станете продактом, услышав мою историю. Сейчас другие обстоятельства, чем 20 лет назад — изменилась индустрия, изменилась страна и весь мир. У меня другая семья, и в детстве я приобрел иные навыки. Я получил не такое образование, как вы. Я живу в другом городе. Я знаю других людей. В общем, моя история не поможет вам войти в профессию. 
 
Меняйте профессию на ту, которая вам интересна. Не бойтесь, но и не суетитесь.

296. Непрошеная помощь
 
Есть такая штука в продуктах — welcome tour. После регистрации тебе говорят: «Сейчас мы будем тебя любить и причинять тебе добро!» И заставляют тебя нажимать кнопки «далее» десять раз подряд и показывают, мол, вот тут у нас кнопка «Создать», она создает, а вот тут кнопка «Удалить», она удаляет. 
 
Эти штуки ненавидят примерно все. Я ни разу не встречал ситуации, где кто-то сказал: «О, спасибо что обучили, мне очень помогло». Все в панике ищут, как отключить эту ерунду.
 
Главный прикол в том, что в куче разных продуктов команды из года в год продолжают создавать это недоразумение. И даже измеряют метрики, которые говорят, что 80% пользователей прошли все шаги тура, а значит он жутко эффективный. 
 
Знаете, почему это раздражает? Это непрошенная помощь! Когда человек использует ваш интерфейс и у него возникает конкретный вопрос, тогда он с удовольствием прочитает справку. А когда он только вошел и вопросов у него нет, любая помощь только вредит.
 
Если вы не создаете в своем продукте велком туры, не спешите записывать себя в праведники. Наверняка у вас есть всплывающие окна, и всплывают они в самый неподходящий для пользователя момент.
 
Я открываю приложение «Кошелек» только чтобы показать дисконтную карту кассиру. И оно радостно встречает меня рекламными предложениями, которые перекрывают код и не дают совершить главное действие, для которого это приложение создавалось. Прилоги кофеен, Спортмастера и прочих — все этим грешат. 
 
Ну и банки. Открываю приложение чтобы перевести деньги и приходится избавляться от предложений о кредитах, поздравлений с днем рождения и просьб почитать статью о финансах. А ведь эта реклама всегда стремятся занять весь экран и помешать мне сделать то, на чем продукт зарабатывает.
 
Во всех этих продуктовых компаниях сидят продакты и маркетологи, которые регулярно отчитываются о росте метрик и конверсиях.

295. Памяти компании ABBYY
 
Сегодня попалась статья, что в компании ABBYY уволили всех русских программистов. Это изначально русская компания и большинство программистов там были русскими. Хочу поделиться парой личных воспоминаний об ABBYY.
 
В 2000 году я писал диплом. Тема была сугубо практическая, диплом я писал сам. Но нужно было вставить какие-то теоретические цитаты. Я отсканировал пару книг, распознал текст с помощью ABBYY Reader и вставил в диплом почти без редактирования. В те годы это казалось чудом. Я был уверен, что компания эта находится в США, ведь у нас тогда еще лаптем щи хлебали. С удивлением узнал, что это наши ребята.
 
В 2007 году офис компании, где я работал, находился в одном из корпусов СПбГУ на Ваське. Мы разрастались, и нам выделили другое помещение в этом же здании. После работы мы с коллегами купили пива и пошли осваивать новый офис. Там нужно было освежать ремонт, поэтому мы, молодые кони, особо не церемонились и просто по приколу раздолбали офис. Все равно наше, все равно ремонтировать.
 
На следующий день начальник сказал, что офис у нас будет в другом помещении, а это отдадут ABBYY. Мне, как главному хулигану, было стыдно — безобразничал в чужом офисе. А ведь они мне диплом помогли сделать!
 
Столько лет прошло. Столько всего изменилось. 
 
Морали не будет. Это просто стариковские воспоминания. Хотя, все же есть мораль: IT-компании сильны своими инженерами, они ее соль и суть. Нельзя просто взять и заменить одних программистов на других.

294. Что такое ИИ и кому надо его бояться
 
Мои студенты для защиты курсовых постоянно придумывают себе стартапы «на основе ИИ». Причем пихают его к месту и не к месту. Абитуриенты на полном серьезе интересуются, стоит ли им поступать в магистратуру, ведь через пару лет ИИ может заменить продуктовых менеджеров.
 
Друзья, мне, право, неловко говорить такие базовые вещи, но придется. 
 
1. ИИ — тупой, даже если так не кажется
 
Cамое главное, что нужно понять об искусственном интеллекте — у него нет интеллекта. Он не думает, не осознает себя, ну чувствует. По сути он тупой. Он просто очень хорошо имитирует мыслительную активность.
 
Нейронка может распознать кошку на фотографии, но она не понимает, что такое кошка. Другая нейронка может хорошо объяснить всё-всё про кошек, но при этом тоже не понимает, что такое кошка. Вот такой парадокс: может объяснить, но ничего не понимает. Проклятие китайской комнаты.
 
Возможности больших моделей поражают. Как они работают с текстом или графикой. Но считать, что ИИ думает, могут только люди далекие от индустрии или фантазеры, типа программиста из Гугла, который утверждал, что «оно живое».
 
2. ИИ — инструмент для помощи
 
Когда делали ядерную бомбу (или другие наукоемкие разработки), приходилось делать много расчетов. Сейчас физики сами пишут скрипты на Питоне или в Экселе что-то считают. А тогда сидели целые здания с сотнями техников, которые считали по логарифмической линейке. С изобретением калькулятора, а потом сред разработки, ученых и инженеров меньше не стало. А вот техников — уволили, они больше не нужны. 
 
Тоже самое с ИИ — это инструмент, который экономит время умным людям. Раньше нужно было прослушать 200 часов интервью с пользователями, перевести в текст, сделать заметки. А теперь это делают нейронки. Но выводы на основании этих заметок должны сделать люди. Потому что они думают, а ИИ не думает, он тупой. Это просто очень-очень продвинутый калькулятор.
С рисованием похожая история. Когда появились компьютеры, появились художники, которые не умели рисовать от руки, зато отлично владели кривыми Безье. Сейчас появились художники, кто пишет промпты к нейронкам. Но суть не поменялась, ИИ — это просто инструмент. Ценность и смысл привносит только человек.
 
3. Кому бояться потерять работу
 
Когда я учился на инженера-высоковольтника, устроился работать в компанию проектированию химических заводов. В химии ничего не понимал, но умел чертить в Автокаде. И меня наняли, чтобы я делал на компьютере технологические схемы, которые инженер рисовал на бумаге.
 
Школьник может научиться чертить в автокаде за неделю. Опытный советский инженер тратил на это пару лет. Так вот, эти пару лет у меня была работа. Нормально, кстати, для студента. После стройки, где я долбил бетонные стены, очень даже не пыльно. 
 
Сейчас, в период становления новых инструментов в виде ИИ, у техников-энтузиастов есть работа. Через 3-5 лет прослойка в виде людей «пользователей моделей» отпадет. 
 
Работу надо бояться потерять:
 
— Техникам, кто пользуется ИИ, но не создает продукты или смыслы.
— Инженерам, кто перестал учиться и не может освоить новые инструменты.

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

292. Что делать, если продакшн упал
 
К хорошему быстро привыкаешь. А привычное всегда кажется простым. 
 
Мы привыкли, что в кране есть вода. Мало кто задумывается, что у нас настолько дешевая питьевая вода, что мы спускаем ее в унитаз. Если вдруг воду отключили на пару часов, мы негодуем. Вода в кране была всегда, а что-то естественное, а значит простое. И только инженеры знают, насколько сложна система водоснабжения и канализации. И только коммунальщики знают, как много сил нужно, чтобы все работало.
 
Мы привыкли, что в розетке есть электричество. На нём работают все домашние приборы и оно дешевое. Знаете, сколько стоит киловатт? А что такое киловатт знаете? Если электричество отключили на полчаса, мы негодуем. Электричество в розетке было всегда, вырабатывать его просто, вроде надо газ сжигать. Кстати, а вы задумывались, что происходит с электростанциями ночью, когда потребление снижается? Уходят в спящий режим? Я по образованию инженер-электрик, знаю, как все сложно устроено.
 
Мы привыкли, что сайты работают всегда. И соц. сети. И банковские переводы. И мессенджеры. Чего там может ломаться то? Там же просто большой компьютер, он работает сам. Сидят балбесы какие-то и не могут уследить, чтобы не ломалось. DevOps грустно усмехаются и чинят дальше.
 
Если вы отвечаете за цифровой продукт, просто примите как данность, что люди избалованы и неблагодарны. 99,9% времени, когда все работает, никто не скажет вам спасибо. Зато в 0,1% времени пользователи объяснят вам, что вы криворукий идиот, у которого всё всегда сломано. 
 
Обижаться не надо. Но и молчать тоже не надо. Надо объяснять пользователям, что произошло — публично и лично, через саппорт и статьи в блогах. На доступном им языке. Рассказать, что ввели санкции и пришлось переезжать, а один переезд равен двум пожарам. Объяснить, что вас атаковали какие-то бармалеи и вы восстановили работу за час, а не за сутки. 
 
Пользователи избалованы, но они способны понять и простить.

291. Чем отличается UX от UI (на самом деле)
 
Много смешных картинок можно найти, чем отличаются UX и UI. Про туалетную бумагу, кетчуп и прочее. Все они про КРАСИВО VS УДОБНО. По сути правильно, но имеет мало практической пользы: «Делай удобно, а не просто красиво». Ну, ок, спасибо, что сказал.
 
Хочу предложить вам концепцию, которой я пользуюсь более 20 лет:
 
Смотреть не на интерфейс (который внутри устройства), а на весь путь клиента (в котором разные устройства и физический мир).
 
20 лет назад я работал в платежной системе, где платить надо было с компьютера, а подтверждать платеж на телефоне через смс. Сейчас к этому все привыкли, а тогда этого никто не делал. Поэтому я отлаживал CJM (слова такого еще не придумали) с помощью тестов на реальных людях в приближенных к реальным условиях. Давал им компьютер, телефон и квитанцию за квартиру, которую надо было оплатить. Прогонял их по всему сценарию использования. В результате тексты смс я правил чаще, чем веб-интерфейс платежной формы.
 
Сейчас многие рисуют CJM и оптимизируют в нем сложные места. Но почему-то пренебрегают тестирование. А только тестирование выявляет проблемы на стыке разных частей.
 
Недавно в торговом центре, где я часто бываю, улучшили оплату парковки. Раньше надо было взять талон, не забыть его забрать с собой, не забыть оплатить его на выходе на парковку, оплачивать надо было в ужасном автомате, который вечно ломался и у него была очередь. 
 
В один день на этом автомате я увидел большую надпись: «Плати за парковку прямо с телефона». Я обрадовался и стал искать ссылку на скачивание приложения. Не нашел. Пытался по-разному, но так и не понял. 
 
Видимо я был не один такой. Потому что через месяц по радио в торговом центре стали объявлять: «Чтобы оплатить парковку, отсканируй QR-код на талоне, идиот!» Оказалось, приложение не нужно скачивать. Очень удобно, к слову.

290. Книги на лето
 
В магистратуре ВШЭ, где я преподаю, каждый преподаватель дает студентам небольшое напутствие на лето и список литературы. Я подумал, что почему бы с вами этим не поделиться as is. Заодно узнаете, почему мой канал так называется. А самые догадливые смогут разгадать смысл аватарки канала.
 
================
 
Напутствие
 
Продакт — это очень комплексная профессия. Нужно уметь много всего разного: аналитику, исследования, статистику, работу с людьми, технику, базы данных, экономику, переговоры, проектное управление и т.д. И многое из этого нужно уметь сразу же, в первый год работы. Получается, что в этой профессии люди развиваются «методом прогрессивного джипега», сначала всего понемножку, потому это же «всего» немного поглубже.
 
Поэтому довольно сложно назвать самое главное, что надо прочитать за лето. Ну и какой нормальный студент будет читать что-то летом? Особенно много разного? Особенно занудного? Так и рехнуться можно! 
 
Но раз я должен что-то порекомендовать, то предлагаю прочитать две книги. Первая — про переговоры, потому что вы можете быть плохим аналитиком и исследователем, но как-то выживать в профессии, а вот без умения договариваться — вообще ничего не получится. Вторая — это книга Притч, часть Библии. Вы можете быть неверующим человеком, но прочитать притчи — очень полезно. Автор книги, царь Соломон был самым успешным менеджером древнего мира и самым эффективным управленцем. Говорю абсолютно серьезно, в этой книге отражены многие фундаментальные принципы менеджмента, и что книге 3000 лет, это скорее плюс.
 
Рекомендации по литературе
 
Гэвин Кеннеди — Договориться можно обо всем! — Альпина Паблишер — 2022 — ISBN 978-5-9614-6867-0 — Электронный текст: https://alpinabook.ru/catalog/book-dogovoritsya-mozhno-obo-vsem/
 
Книга притчей Соломоновых — Библия (рекомендую читать в Синодальном переводе) — Электронный текст: https://bible.by/syn/20/1/

289. Великое просветление мониторинга
 
Есть три стадии развития паранойи мониторинга:
 
1. Мониторинга в продукте нет. Если что-то важное сломалось — тебе пользователи обязательно про это скажут. К слову, говорят не все и не всегда. Я встречал продукты, где о падение продакшна команда узнавала через сутки.
 
2. Мониторинги в продукте есть и разные. Внутренние мониторинги проверяют сервера и базу данных. Внешние мониторинги присматривают за сайтом целиком. Всё логируется, все бэкапируется. О проблемах в продакшене команда узнает заранее и реагирует быстро.
 
3. Проверяется не только сам продукт, но и third-party solutions. Иногда партнерские сервисы также важны, как и основной продукт. А вот что они сломались — не всегда очевидно. Иногда можно с ужасом узнать, что уже пару месяцев ничего не работает.
Поясню на примере кассовых чеков. Каждая покупка должна пробивать чек, но главное, там целая цепочка:
 
— Продукт говорит платежной системе сделать платеж.
— Платежка говорит онлайн кассе (другая компания).
— Касса передает данные оператору фискальных данных (третья компания).
— ОФД передает данные в налоговую (государственная структура).
 
Сломалось что-то у нас — мы узнаем быстро. Что-то сломалось у первого партнера — когда как, зависит от настроек. Но в теории тоже можем узнать. Что-то сломалось на 3 или 4 шаге — узнать нереально и автоматизировать сложно.
 
Надо всегда исходить из того, что партнеры могут плохо сделать свою работу и про это никому не сказать. Однажды ОФД перестал передавать наши чеки в налоговую, а когда мы это обнаружили, долго отрицал вину. В другой раз в онлайн кассе перепутали номер версии ПО, чеки пробивались, но налоговая их считала ошибочными. В третий раз оказалось, что один партнер из цепочки лежал с 500 ошибкой и все остальные на это никак не реагировали.
 
Достигнуть третьего уровня мониторинга сложно, долго и дорого. Начните с того, что опишете в документации все такие цепочки и научитесь отслеживать каждый этап в ручном режиме. А то знаю я вас, считаете, что есть ваш продукт, а за ним какая-то непостижимая магия.

288. Почему айтишники крутые
 
Мы, кто работает в софтовых продуктах, привыкли что дизайн должен быть качественным, а опыт пользователя продуманным. Но есть куча отстающих отраслей, где все довольно печально. Например, «умный дом».
 
Автоматизация домов пока на уровне сайтов 20-летней давности — работает, но все как-то через назад. Объясню на примере самого простого и распространенного решения — автоматического включения света. 
 
Свет включается, если в помещении есть движение (люди), в остальное время свет отключается, экономя электричество. Идея норм, реализация кошмарная. Причем делают плохо в разных странах, в дорогих и дешевых домах. Объясню в чем проблема.
 
1. Резкий переход. Ты идешь по темному подъезду и вдруг резко зажигается свет, тебя ослепляет. Причина в том, что датчики движения ставят там же, где светильник. А нужно ставить их заранее. В подъезде свет на втором этаже должен зажигаться пока я иду по первому или третьему.
 
2. Малое время работы. Свет обычно отключается через 15 секунд. Ты заходишь на этаж, свет зажигается, вызываешь лифт, ждешь, датчик не видит движения, свет гаснет, ты ждешь лифт в темноте, шевелишь рукой, свет зажигается. Переход из темноты в яркий свет 3-5 раз сводит с ума. Нужно оставлять свет на пару минут и все будет отлично.
 
3. Плохая экономика. Все делают такие решения, чтобы сэкономить на электричестве. Но сейчас освещение светодиодное и тратит в 20 раз меньше электроэнергии, чем традиционные лампы. Экономия настолько крошечная, что не окупает стоимость датчиков. 
 
Если бы это был софтверный продукт, мы бы провели интервью с пользователями, нарисовали CJM, исправили проблемы, провели UX-тестирование. Экономику бы тоже посчитали. Но в той индустрии другие стандарты и о подобном просто не думают. 
 
Именно поэтому айтишник, создатель платежной системы, Илон Маск, пришел в индустрию автомобилестроения и навел там шороху. Над ним первое время смеялись, а потом стали подражать. Над его ракетами тоже смеялись, пока компания не заняла 90% рынка.
 
Поэтому ребята из IT могут улучшить вещи в любой индустрии. Не за счет сайтов и приложений, а за счет паттернов проектирования, анализа данных и умения работать с фидбэком.

287. Высшее образование у нас оказалось не таким уж бесполезным
 
В прошлом году я стал преподавать в магистратуре ВШЭ, учу будущих продактов. На днях принимал защиты дипломов. И в очередной раз понял, что всё изменилось в лучшую сторону, по крайне мере в некоторых ВУЗах.
 
Я закончил один из лучших университетов страны и при этом всегда считал высшее образование полным отстоем. Может быть фундаментальное у нас и ОК было, но вот инженерное, а тем более айтишное — печаль. Старые преподы, которые никогда нигде, кроме института, не работали, преподают какую-то древнюю ерунду по заплесневевшим методичкам. 
 
Но главная профанация — диплом. Пятерки получают все. Научный руководитель дает диплом прошлых лет, студент его переписывает, что-то по мелочи меняют и получают пятерку. Если напился и упал на выступлении, то четверку могут поставить.
 
Всегда говорил, что высшее образование — это ерунда на постном масле, полезно лишь как фитнес для мозга и прокачка социальных связей.
 
Но сейчас, глядя на Вышку, я понимаю, что времена изменились. В магистратуре преподают профессионалы из отрасли. Например я. Мне не ставили никаких ограничений, почти не парили бюрократией. Сказали, мол, учи как считаешь нужным, чтобы нормальные специалисты получились. 
 
Но больше всего меня поразила гос. комиссия по защите дипломов. Я всегда считал себя злым преподом, а тут познакомился с еще более злыми преподами и преподшами. Сегодня только 1 человек ушел с пятеркой за диплом, половина с четверками, почти половина с тройками, 1 с неудом. 
 
Люди заплатили кучу денег за магистратуру. Два года учились. Полгода писали диплом. А им поставили трояки. Я в шоке. Ну да, я же и поставил… Но мне сказали не жалеть, типа репутация у нас, не можем за слабые работы пятерки ставить.
 
Наш программист на днях защищает диплом в ИТМО. Я его спросил, типа, ерунде наверное учат, а всему нужному ты самостоятельно научился? Нет, говорит, нормально учат, в работе помогает. Похоже ИТМО тоже нормальным стал. В мое время был второсортным институтом (ну, мы его таким считали).
 
Даня, давай там, держись. Пусть тебе попадется не такой злой препод, как я.

286. Успех выжившего
 
Сын в детстве занимался борьбой Самбо. Соревнования проходят по годам и по весовым категориям. У сына в весовой было много сильных конкурентов. Он старался изо всех сил, много боролся, но медали доставались редко и на пределе сил. 
 
С ним занимался мальчик, который был очень высокий и тяжелый. В его возрасте просто не было детей, кто весил как он, хотя город у нас большой и спорт популярный. Поэтому на соревнованиях, пока мой сын потел и страдал, его друг играл на телефоне. Под конец соревнований обычно его вызывали на поединок с единственным нашедшимся оппонентом. Иногда он проигрывал и получал серебряную медаль. Иногда оппонент не находился и он получал золотую медаль и призы.
 
Победа в любом деле зависит от твоих навыков и старания. Но довольно часто она зависит от них на 10%. Остальные 90% победы — это внешние условия.
 
Поэтому, когда слушаете историю успеха бизнесмена, помните, что скорее всего рынок в тот момент был не занят или были другие внешние благоприятные обстоятельства.
 
А когда к вам приходит на собеседование менеджер продукта и показывает кейс, где под его управлением продукт вырос на 200% там и сям… Имейте ввиду, что скорее всего он вырос вместе с рынком или благодаря совокупности факторов и труду сотен людей.
 
Поверьте мне, я знаю. Все мои успехи, которые я могу доказать с цифрами на руках, скорее всего случились бы и без меня. А все мои провалы — в них я сделал все идеально правильно, но все равно не получилось.

285. Синхронная и асинхронная коммуникация
 
Учимся управлять людьми и процессами на примере работы серверов.
 
Синхронные запросы. Вы хотите посмотреть новый клип Киркорова, в браузере нажимаете на ссылку и получаете видео в ту же секунду. Если одновременно с вами еще миллион человек пытаются посмотреть клип, то ссылка может открыться через пять секунд. А если 10 миллионов, то ответ от сервера будет задерживаться, через секунд пятнадцать вы начнете нервничать и жать на ссылку еще и еще — этим самым еще больше увеличивая нагрузку. Синхронные запросы работают быстро, но если нагрузка велика, то начинаются проблемы. Если сервер не успевает обработать запрос, то через какой-то таймаут (например через минуту) он отдаст вам 504 ошибку.
 
Асинхронные запросы. Вы хотите отправить миллиону своих подписчиков email-рассылку о весеннем снижении цен. Сервер для них создает очередь и письма отправляются одно за другим, пока очередь не опустеет. Вы все это время занимаетесь своими делами (например, пытаетесь посмотреть клип Киркорова). Асинхронные запросы надежны и удобны, но могут занимать много времени.
 
Менеджер может работать в синхронном режиме, а может в асинхронном. Правильный выбор — залог эффективности. 
 
Недавно один из клиентов автопроизводителя Тесла пожаловался, что ему несколько месяцев не могут согласовать ремонт автомобиля. Менеджеры ответили, что сам Илон Маск повелел согласовывать с ним каждый ремонт. Он гендир, поэтому занят, и придется подождать.
 
Ошибка Илона не в том, что он занимается не своим делом. А в том, что он выбрал асинхронную коммуникацию и создал очередь. А надо было работать синхронно и обозначить таймаут: «Хочу согласовывать все ремонты, пишите в телегу, но если не ответил через час — не ждите, принимайте решение на свое усмотрение».
 
А бывает, что менеджеры наоборот ошибочно выбирают синхронную коммуникацию. Пишут каждому программисту в личный чат вопрос и требует немедленного ответа. А потом зовет всех на совещание, чтобы 20 человек обсудили важный вопрос. Программист вместо написания кода отвечает в чате нетерпеливому начальнику и скучает на встречах. А мог бы код писать.