​​📞 Чтобы было кому позвонить

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

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

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

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

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

Из этой истории я сделал вывод (да, спасибо, кэп): любой конфликт обязательно идет по нарастающей. Если первый человек начал говорить со вторым раздраженно, то второй ответит еще более раздраженно. Первый повысит голос – второй закричит. Люди получают сигнал: «Мне тоже так можно» и усиливают его.

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

​​👍👍 Мечта о сервисе для отзывов

Я мечтаю о таком сервисе: один раз в жизни пишешь усредненно хороший отзыв об абстрактном продукте, нажимаешь кнопку ОК и больше никогда-никогда-никогда не видишь ни одной просьбы «пожалуйста, оцените наше приложение» или «как вам качество этого звонка?»

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

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

Не сомневаюсь в востребованности такого сервиса. )

​​🦸🏻‍♀🦸🦸‍♂ Загадочные интерфейсные «они»

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

Так делать не надо.

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

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

Продукт — это не ваша классная продуктовая команда, не бэк-офис и не служба поддержки. Это отделенная от них сущность.

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

Интересный канал @uxhorn ведет Михаил Хананашвили. Это регулярно обновляемая подборка статей, видео и других материалов про UX на русском и английском языках из разных источников.
Я такие каналы люблю полистать, тем более, что работа с UX - не только наше настоящее, но и будущее.

Понравилось:
https://t.me/uxhorn/134 - о теории близости в дизайне.  
https://t.me/uxhorn/254 - история про дизайн городской среды.    
https://t.me/uxhorn/1004 - о разработке цифровых продуктов с помощью ментальных моделей.
https://t.me/uxhorn/1017 - о зависимости конверсии от качества текстов.
https://t.me/uxhorn/1465 - когда ВВС США осознали изъян со средними числами.

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

​​✅ ✅ Менеджеру о делегировании задач

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

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

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

4. Делегирование всегда происходит сверху вниз в иерархии управления. На горизонтальном уровне мы просто ставим задачи исполнителям.

5. Нельзя делегировать задачу в один момент. Делегирование — это процесс:
А. Руководитель показывает, как он делает задачу. Сотрудник смотрит.
В. Они делают задачу вместе, но сотрудник пассивен, основную часть делает руководитель.
С. Сотрудник делает, руководитель корректирует его действия.
D. Сотрудник делает, а руководитель его хвалит. Это важно. В этот момент руководитель становится пассивным наблюдателем, задача уже у сотрудника.
Е. Сотрудник действует самостоятельно.
F. Руководитель контролирует результаты и наказывает за косяки.

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

Пример: менеджер Антон нанимает разработчиков и аналитиков в команду. Он делегирует задачу «нанять разрабов» сотруднику Глебу.
А. Антон идет собеседовать кандидата и зовет с собой Глеба. Тот смотрит, как Антон проводит интервью, какие вопросы задает.
В. Антон проводит интервью. Глеб тоже иногда задает вопросы кандидату.
С. Глеб проводит интервью, а Антон задает уточняющие вопросы, помогает.
D. Глеб проводит интервью, Антон молча наблюдает, а после — хвалит Глеба.
E. Глеб на интервью, а Антон даже не пришел. Глеб сам нанял разраба.
F. Антон следит, кого нанимает Глеб. Когда Глеб решил нанять человека без полноценного интервью, только на основе рекомендаций знакомых, Антон не позволил.

6. Можно делегировать задачу, но не ответственность.
Антон избавился от задачи, но не получил права сказать: «У нас проблемы? Ну, это Глеб виноват, он плохих людей нанимает».

7. Задачу нельзя делегировать навсегда — иначе это просто расширение полномочий сотрудника, новая должность и обязанности. У делегирования есть временные рамки.
Глеб будет нанимать разрабов только полгода. Потом Антон эту задачу заберет.

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

9. При делегировании сотрудник получает власть. Он обязательно начнет ей пользоваться и постарается ее приумножить. И нарушит правила. Поэтому ограничения и контроль — это важно.
Глеб хотел нанять человека за 300К, но Антон не позволил.

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

11. Делегировать  — это правильно. Только надо правильно делегировать. )

​​​​🤷‍♀ Чек-лист погружения менеджера в проект

Мы с Сережей Колосковым, продукт-менеджером Ozon и автором канала https://t.me/freshproductgo, набросали чек-лист для погружения менеджера в новый проект. Хотим помочь менеджерам задавать правильные вопросы, чтобы все прошло быстро и продуктивно.
Даже если у вас нет нового проекта, проверьте свой по этому чек-листу – сразу увидите все проблемные зоны.

✅ Описано ли, в чем суть проекта?
Иначе как делать то, что непонятно?

✅ Описано ли, какие проблемы будут решены, если проект будет выполнен?
Нет? А что вы тогда собираетесь делать-то?

✅ Сформулирована ли цель проекта и критерии ее достижения?
Нет цели – нет проекта. Формулировать лучше по SMART.

✅ Все ли заказчики одинаково понимают цель проекта?
Если общего понимания нет, как работать совместно?

✅ В какой точке дорожной карты продукта находится проект?
«Где мы вообще?» — один из самых важных вопросов.

✅ Сформулировано ли, что будет, если проект не сделать?
Может, его и делать не стоит?
Бизнес-цель должна быть оцифрована: «После запуска новой корзины на сайте конверсия в покупку вырастет на 20%, а выручка – на 4 млн. рублей в день». Этот пункт очень хорошо помогает понять важность проекта.

✅ Есть ли список метрик, на которые влияет продукт проекта?
Неизмеримо = неуправляемо.

✅ Известно ли, кто заказчик и спонсор проекта?
Кто инициировал проект, кому он действительно нужен?
Нет спонсора и заказчика – нет проекта.

✅ Определены ли стейкхолдеры проекта?
Самое время нарисовать матрицу поддержки и влияния.

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

✅ Способна ли команда справиться с задачей?
У вас команда или толпа непонятных людей?

✅ Можете ли вы влиять на состав команды?
Если совсем не можете – у вас проблемы.

✅ Сформулированы ли ограничения проекта?
Возможно, от вас ждут совсем не тех результатов, к которым вы идете: ожиданиями заказчика никто не управляет.

✅ Есть ли план-график проекта?
Нет плана – нет проекта.

✅ Есть ли в плане привязанные к задачам ответственные исполнители и сроки исполения задач?
Нет ответственных = нет результата.

✅ Есть ли расчет бюджета, юнит-экономики проекта и ROI?
Неизмеримо = неуправляемо.

✅ Есть ли план управления рисками?
Пора составить матрицу рисков и запустить риск-мониторинг.

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

Взлетайте!)

​​📉📈 Что менеджеру нужно знать об отображении количественных данных

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

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

=> Быстрее всего люди обрабатывают положение точки на прямой. Поэтому двумерные объекты — самые удобные для восприятия. Где мы сейчас в проекте? А, вот линия времени, вот границы спринта, вот дата окончания. Все понятно.

=> Люди быстро обрабатывают длину линий и расположение объектов на плоскости. Это хорошая новость для любителей гистограмм и линейных графиков. Человек сразу понимает, какой столбик диаграммы длиннее. И какая точка выше остальных на точечной диаграмме. Точки и линии — это хорошо.

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

=> Любые 3D-объекты под запретом. Трехмерность на плоскости — гарантированное искажение и объекта, и его восприятия.

=> Цвет не может быть самостоятельным способом выделения объектов, потому что у человека нет предустановленных связей цвета и количества. Синее больше красного? Или красное больше? Цвет работает только вместе с другими способами выделения: все точки над прямой коричневые, а под ней — зеленые.

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

​​📩 🤦 📩 Коммуникации by default

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

Например, провел менеджер совещание в zoom и трем десяткам участников разослал протокол. Плохая практика: менеджер в ответ получил 30 писем со словами «Согласовано, замечаний нет». Хорошая практика: участник молчит, пока у него нет замечаний. Если к определенному времени ни от кого комментариев по делу не пришло, протокол автоматически считается согласованным.

Или попросил менеджера коллега-продавец оценить стоимость доработки софтины для клиента. Менеджер все сделал, отправил коллеге оценку. Для него и команды это обычная задача. Плохая практика: коллега в ответ пишет «спасибо огромное!» Хорошая практика: коллега благодарен по умолчанию, лишних писем нет.
А если коллега совсем не может от отправки «спасибо» отказаться, то пусть хотя бы пишет не в ответ на каждое письмо.

Или написал менеджер письмо с задачей сотруднику и больше ничего не спрашивает. Плохая практика: сотрудник отвечает: «Задачу принял!» И все. Зачем? Почта/Jira и так нормально работают. Если задачу правильно поставили, не надо подтверждать ее получение. Хорошая практика: сотрудник менеджеру лишних писем не пишет, а вопросы задает только по существу.

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

​​🐣🐣🐥 Нанимать зрелых сотрудников

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

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

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

И дело не в возрасте. Лучшие вратари мира точно знают, откуда он будет бросать, но ничего не могут с этим поделать. Бросок — гол. Остальные задачи Овечкин вполне может позволить себе сделать некачественно.

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

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

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

​​🏹 Держать руки свободными

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

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

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

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

Не надо. Держите руки свободными.

​​🐩 Синдром выученной беспомощности в управлении

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

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

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

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

=> Отказ от деятельности — апатия, заторможенность, выпадение из реальности. Сотрудник часами уныло глядит в окно или непонимающе пялится в монитор.

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

=> Псевдоактивность — бессмысленная суета, не ведущая к результатам и не адекватная ситуации. Сотрудник бегает по офису, звонит по всей адресной книге, дергает коллег.

=> Смещение на псевдоцель — попытка решать неактуальную задачу взамен актуальной. Вместо разруливания конфликта в команде менеджер перетряхивает содержимое тумбочки или чистит рабочий стол от "лишних" ярлыков.

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

=> У менеджеров выученная беспомощность быстро появляется в среде с мотивацией к избеганию неудач. Хотим беспомощных менеджеров — поощряем их не совершать ошибок.

=> У команд выученная беспомощность возникает при авторитарном стиле руководства. Хотим беспомощную команду — управляем ей как диктатор-микроменеджер.

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

Как не дать выученной беспомощности убить команду:

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

=> Поддерживать в людях высокую самооценку. Люди с повышенным ЧСВ менее подвержены выученной беспомощности.)

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

Так просто и так важно, правда?

​​👽 🤖 О чем спрашивать на интервью

На интервью кандидату задают вопросы двух типов:
«Кто ты такой?» и «Как ты решаешь задачи?»

Вопросы первого типа мы все просто обожаем:  
«Расскажите о себе!»
«Кем вы видите себя через пять лет?»
«Какие ваши самая сильная и самая слабая стороны?»
«Как вы справляетесь со стрессом?»
«Почему вы хотите работать именно в нашей компании?»

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

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

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

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

А вы подумайте, не задаете ли вы на интервью дурацких вопросов.)

​​1⃣ 2⃣ 3⃣ Три ошибки менеджера

Если вы поставили человеку задачу и видите, что задача не сделана, вы совершили одну из трех ошибок:

=> Неверно выбрали исполнителя.  
=> Плохо объяснили ему задачу.  
=> Не проконтролировали результат.  

Большинство менеджеров верят, что основная причина несделанной задачи – не те люди. Или считают, что недостаточно контролировали исполнителя.

И почти никто и никогда не готов признать, что причина провала в плохой постановке задачи.

​​👨‍⚖ 🧟 🧝‍♀ Проверенная схема интервью

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

Вот моя рабочая схема интервью.

1. Поздороваться, представиться.

2. Дать тест и уйти на полчаса. Тест — 2-3 вопроса. Никаких абстрактных задач «на логику». Тестировать нужно только реальные навыки, которые критичны для будущей работы. Я проверяю умение писать по-русски (или по-английски) без диких ошибок и навык оценивания ресурсов в проекте.    

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

4. Задать два-три теоретических вопроса, обсудить ответы кандидата. Что такое проект? Чем продукт отличается от проекта? Что такое риск? Какие бывают стратегии реагирования на риск?

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

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

7. Еще один-два кейса по специальности.

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

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

10. Вопросы про размеры вознаграждения и его структуру.

11. Ответить на любые вопросы кандидата.

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

Интервью лучше проводить после встречи кандидата с HR — тогда у вас меньше шансов напороться на неадекватов.)

Я люблю хорошие авторские каналы, и "Текст в тесте" @txtin как раз такой. Авторы работают в Сбере и Яндексе, а канал у них о русском языке вообще и текстах в интерфейсах в частности.  

У вас пригорает от канцелярита? Бомбит от ненужных заглавных букв в середине предложения? Вымораживает от плохого текста в форме регистрации? Вам точно сюда.)          

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

Смотрите сами:
https://t.me/txtin/3 - про особенности описания жестов в интерфейсе. А вы смахиваете?)
https://t.me/txtin/17 - про юридические риски, возникающие от непродуманного рекламного текста.  
https://t.me/txtin/26 - как правильно писать некоторые сервисные сообщения.
https://t.me/txtin/680 - про Вас, уважаемый Вы наш.
https://t.me/txtin/639 - о хамском письме Светлане Степановне.
https://t.me/txtin/606 - как писать нерусские имена по-русски.
https://t.me/txtin/557 - о тактике "не торопись в конце". Годится не только для писателей, но и для менеджеров.
https://t.me/txtin/496 - про пятибалльные оценки и их значение.
https://t.me/txtin/478 - как редактировать себя.
https://t.me/txtin/461 - про императив в описании ошибок и в письмах.
https://t.me/txtin/409 - почему не надо называть кнопки похоже.

Прекрасный канал, рекомендую.

​​🐉 Продуктовая притча #1

Как-то после недельной медитации молодой Хунь Заень обратился к своему учителю с вопросом:

— О, мудрейший из мудрых и опытнейший из опытных, назови самые сложные загадки вселенной!
Учитель сделал глоток ароматного настоя из лепестков цветка фу и ответил:
— Воистину, меньше капель в море, чем загадок во вселенной. Но три из них не могут разгадать даже величайшие мудрецы, чьи умы подобны двуострому мечу, вспарывающему ткань мироздания с легкостью и изяществом танцовщицы на празднике тысячи лотосов в провинции Ля.
— Что же это за загадки, мудрейший? — повторил вопрос Хунь Заень, ибо был юн и, стало быть, нетерпелив.
— Первая: «где рождается заря?» — и учитель задумчиво посмотрел на розовеющую полоску неба. — Вторая: «о чем поет соловей майской ночью?»  — и учитель слегка улыбнулся, будто вспоминая что-то приятное. — Но даже они — ничто в сравнении с третьей загадкой: «почему в Вайлдбериз можно расплатиться Яндекс.Деньгами, но ни Яндекс.Такси, ни Яндекс.Еда, ни даже Яндекс.Плюс их не принимают?» — и учитель склонил голову в знак великой печали.  

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

А третья так и осталась неразгаданной.

​​🗣 🦠 👥 Лжеэкономия на удаленке

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

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

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

Да очень просто. Качественный фрилансер — это профи, который все умеет и не нуждается в няньке. Это онлайн-человек. Он прекрасно себя чувствует на внутреннем или на русскоязычном рынке, а если не поленился подтянуть английский, то и на международном. С чего ему стоить дешево? Может, вы выиграете процентов пятнадцать на квартирно-транспортных расходах. Или не выиграете, если его специализация востребована. На Senior Java dev-e не сэкономите точно. )  

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

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

​​📚 Английские фразочки менеджеру в помощь

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

С-suite – первые лица компании, руководители.

IDGAS – аббревиатура (I don’t give a shit): мне все равно, мне безразлично.

Do a one-eighty – двигаться в противоположном направлении, менять свое мнение на 180 градусов.

Icing over the cake – дополнительный, необязательный бонус. 

Get the monkey off your back – переложить проблему на чужие плечи.

Gobbledygook – канцелярит, бюрократический или специальный язык.

We are a nosey bunch – мы сгораем от любопытства.

I’m pulling your leg – я над тобой подшучиваю (дурачу, морочу, высмеиваю).

Under the weather – чувствующий недомогание (например, как причина не пойти на работу), поддатый, менструирующая.

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

Around the world – помимо распространенного значения "в мировом масштабе" в сленге означает "секс во всех позах". Тоже используется при описании статуса проекта. )  

Bugaboo – (буквально — "пугало") реальное или придуманное препятствие.

It rains cats and dogs – (устаревшее: "лить, как из ведра", например, о дожде) в современном британском языке употребляется только как шутка, но австралийцы и южно-африканцы иногда так говорят.

Just ducky! – (американизм) прекрасно, превосходно, лучше, чем ОК, "зашибись".

Toing-and-froing – хождение взад-вперед, нервные безрезультатные усилия, суматоха.

Spinning many plates – делать сразу много дел одновременно (аналогия с цирковым трюком с тарелками), работать над многими задачами одновременно.

I got the ball rolling on this – я выступаю инициатором чего-либо, я открыл дискуссию на определенную тему.

Кстати, русский человек всегда выделяется: он половину предложений начинает с фразы "I think ...". Не надо так.) 

​​🚦 Установить границы и дать свободу

Еду я на такси, выскакиваем мы на МКАД, проезжаем знак, как на картинке внизу. Я спрашиваю у таксиста, знает ли он, что сие означает. Он признался, что толком не помнит. Но сказал, что, судя по форме и цвету, этот знак ничего не запрещает. Просто о чем-то информирует.

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

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

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

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

​​⏸ Держать паузу

Сто миллионов лет назад, на первом курсе института, я сдавал экзамен по матану. Старшекурсники рассказали, что преподаватель любит дать студентам задачку с подвохом: просит разложить в ряд Фурье функцию sin 2x.

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

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

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

Важно держать паузу.