Притчи продуктолога

211. Поделись улыбкою своей

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

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

Все неформальное общение в офисе происходит вне рабочих встреч – за кофе, на обеде, в курилке. А на удаленке есть только рабочие встречи – собрались, обсудили вопрос, разбежались. Не делать же специальный созвон «пьем кофе вместе».

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

Не всегда получается, но я стараюсь делать две вещи:

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

2. Стараюсь начинать даже личные встречи small talk – улыбнуться собеседнику, узнать, как погода в его городе или как провел выходные.

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

210. Быстрорастворимое юзабилити-тестирование

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

Похоже, настало время провести ликбез. Рассказываю, как провести юзабилити тестирование:

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

2. Задания должны быть максимально приближены к реальным действиям пользователя. Например, если вы тестируете интернет-магазин: «Вы хотите купить кроссовки Nike AIR MAX, закажите их доставку на на адрес Ленина 27 кв. 1 и оплатите наличными при получении».

3. В тексте задания не должно быть подсказок. Неправильно: «Найдите в каталоге кроссовки Nike AIR MAX, перейдя в корзину, оформите доставку курьером».

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

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

6. Проведите тестирование на 3-10 респондентах. Юзабилити-тестирование – это качественное исследование, не количественное. Обычно 5 респондентов достаточно.

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

95. О пользе регулярного образования

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

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

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

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

#старыйпост

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

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

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

Правило Парето в математике относится к так называемым фрактальным системам. Если простыми словами, это подобие, внутренняя рекурсия (в природе есть много примеров - раковина улитки, листья папоротника). Внутри набора 20% причин вложены свои 20% (то есть 4%), которые отвечают за 64% следствий-результатов. А вторая вложенность выводит нас на то, что ~1% из списка задач отвечает за ~50% наших результатов. Это и есть ключевые факторы успеха (КФУ). Т.е. КФУ – это оптимальная мини-стратегия для выбранной области. Это область фокусировки основных наших усилий.

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

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

2. Это всегда ограниченный набор, только 1-2 главных приоритета. Не может быть КФУ-списков из 15-20 пунктов! 

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

4. Неочевидность. Узкие, тонкие, «вкусные» нюансы в описании, детали реализации. 

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

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

209. Что такое документация, зачем она нужна и как ее писать

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

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

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

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

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

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

Форма и подробность документации должна подходить для её читателей.

Я раньше писал подробные технические задания, где описывал как реализовать ту или иную фичу продукта. Программисты читали, делали по ТЗ, а потом выяснялось, что половину забыли. Для них было слишком «много букв».

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

Я предпочитаю давать задание одновременно в разных формах, которые дополняют друг друга. Для front-end задач используем: Макет в Фигме с разными состояниями + устное обсуждение + чеклист. Для back-end задач: Техническое задание в виде текста + устное обсуждение + чеклист.

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

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

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

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

Итак, хорошая документация должна:

1. Приносить больше пользы, чем проблем.
2. Иметь удобную для читателей форму или несколько форм.
3. Быть простой и удобной для поддержки.

88. Правило для передачи продукта

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

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

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

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

#старыйпост

ВРЕДНЫЕ СОВЕТЫ ДЛЯ МЕНЕДЖЕРОВ ПРОДУКТА

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

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

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

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

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

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

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

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

9. Не верьте в технический долг. Тех. долга не существует. Не верьте в эту пагубную ересь. Ее придумали ленивые программисты, чтобы ничего не делать.

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

#старыйпост

208. Я в завязке

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

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

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

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

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

80. Мало ресурсов – хорошо для продукта

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

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

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

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

Нет ограничений? Придумай их сам, на то ты и менеджер!

#старыйпост

207. Be smart, bro!

В английском есть слово smart. Я понимаю его скорее не как «умный», а как «сообразительный». Человек с живым умом, который не тормозит и быстро соображает.

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

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

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

Проблема, в том, что человек заранее наметил в голове сценарий. Услышал новые вводные, но не смог осознать. Или осознал, но не смог перестроиться. Не был достаточно гибким и сообразительным. Wasn't smart enough.

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

— UX/UI дизайнер в игровой проект — лучше фултайм, но возможен и парттайм. Для начала разговора шлите мне ссылку на портфолио.

— Маркетолог / комьюнити-менеджер — работать с игровым комьюнити deepmine.world в Дискорде и Телеге и всякое такое. От джуна до синиора, главное бодрость и проактивность. Хороший английский — очень важен, без него никак. Лучше фултайм, но возможен и парттайм. Для начала разговора шлите один абзац текста о себе и CV.

— Product manager на запуск новых продуктов — только фуллтайм, совмещать не выйдет. Для начала разговора шлите один абзац текста о себе и CV.

— Content Writer — парттайм и/или фуллтайм. Нужен английский на отличном уровне. Для начала разговора шлите один абзац текста о себе и CV.

— BI developer (Google Data Studio) — парттайм, возможно фуллтайм. Для начала разговора стукнитесь ко мне в личку, обсудим.

72. Болезнь дизайнеров, от которой надо излечиться

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

В продуктовой разработке внимание к деталям – это хорошо. Например, заметили, что люди вводят номер телефона и с пробелами, и с дефисами, и с +7 в начале, и с восьмеркой. И научились все это обрабатывать и принимать, а не выдавать дебильные сообщения «номер в неправильном формате». А вот переживать, что отступ перед полем «не по гайдлайну» или что тень при наведении на два пикселя меньше – это плохо.

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

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

#старыйпост

206. Оставь это между собой и монитором

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

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

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

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

Интересно, как это трансформируется в будущем в какой-нибудь виртуальной метавселенной?

65. Принеси фичу в следующий спринт

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

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

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

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

#старыйпост

205. Калибровка поведения

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

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

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

Поведение ключевых сотрудников калибрует поведение всех остальных. Они понимают: «Здесь принято поступать вот так и не принято вот этак». Это и есть настоящий Code of conduct, а не то, что написано у вас в корпоративных документах.

Мне нужны художники иллюстраторы для игр. Форма сотрудничества любая: разовые работы или постоянный контракт. Для начала рисовать в жанре научной фантастики, типа этой картинки. Потом будут и другие жанры. 2d/3d. Работы много. Если есть кто сам или знакомый — шлите портфолио.

204. О самооценке программистов

Собеседую много front-end инженеров. Заметил неприятную тенденцию: самооценка специалистов не соответствует действительности.

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

В целом это нормально. Проблема в том, что он сам считает себя Senior+, просит зарплату 6-7 тысяч долларов и говорит, что уже устал от программирования и стремится стать архитектором. И это после того, как человек на собеседовании не смог ответить, чем различаются get- и post-запросы.

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

Не все такие, но тренд довольно заметный.

203. Как я перестал истерить

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

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

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

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

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

64. Время – это газ

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

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

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

#старыйпост

202. Собеседование: минимальные системные требования

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

1. Прийти на собеседование.
Кандидат не пришел на собеседование. Я подождал 7 минут, отключил звонок и отписался рекрутером, что прекращаем переговоры. Рекрутеры долго убеждали меня, что так делать не стоит, ведь «кандидаты часто забывают». Серьезно? Мы набираем людей на удаленную работу с высокой степенью ответственности каждого в команде. Если человек не способен вести календарь или предупредить заранее, что у него изменились планы, зачем нам такой работник?!

2. Настроить камеру и микрофон.
Часть людей не включают камеру. Когда видит меня, спрашивает, что надо камеру? Начинают переключаться с компьютера на ноутбук и оттуда на телефон. У многих ужасно работает микрофон, шуршит, трещит, ничего не слышно. Напомню, что я собеседую IT-профессионалов, работающих на удалёнке. У них 100% общения с коллегами происходит дистанционно.

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

Раз за разом вспоминаю старый анекдот про минимальные требования к кандидатам.