​​✒️ Продуктовая притча #2

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

Юный Хунь Заень, известный своим любопытством и веселым нравом далеко за пределами провинции Мо, встал и почтительно поклонился.

— Наш правитель поручил одному почтенному торговцу, — продолжал учитель, — поставить для его армии десять тысяч доу риса. Торговец сразу решил, что не способен этого сделать и, взяв лучшие чернила и самую тонкую рисовую бумагу, написал своему повелителю письмо, начав его со слов «к сожалению». — Учитель замолчал и некоторое время задумчиво смотрел, как кипит на огне рисовая похлебка, щедро сдобренная тертым корнем травы ша.
— Где же он сейчас, учитель? — вопросил Хунь Заень, наделенный какими угодно добродетелями, кроме терпеливости.
— Только степному ветру да морской пене известен ответ. Хотя голова его до сих пор на пике возле дворца правителя. И оказалась она там не за то, что торговец не выполнил приказ, а за то, что написал «к сожалению». И здесь скрыта великая мудрость: слова эти означают, что он преисполнен сожаления. На деле же он не потратил ни капли своей ци, чтобы решить проблему. Стало быть, повелитель его получил только сожаления. Что он мог с ними поделать?
— Получается, писать «к сожалению, мы не можем выполнить ваши требования» клиенту не следует? — уточнил юный Хунь. — А тексты в интерфейсах, например, «к сожалению, мы не смогли выполнить операцию»?
— Умный человек не прячется за лицемерным сожалением, он помогает клиенту понять суть проблемы и решить ее. — И учитель направил взгляд вверх, где серебряный серп Юэ взрезал серую мглу ночного неба.

Говорят, с того дня Хунь Заень принял обет не писать «к сожалению», и о его мудрости люди сложили легенды.

​​🙅🏽‍♀ Снисходительный тон в интерфейсе

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

«Упс. Что-то пошло не так».
«Все сломалось, но мы очень стараемся все починить».
«Мы не можем завершить операцию, может и не надо?»

Но лидер этого UX-парада — поддержка Яндекс.Драйва. Когда в диалоге нет активности несколько дней, обращение клиента закрывается (это нормально), и приходит сообщение: «Извините, этот чат сломался. Если остались вопросы, создайте, пожалуйста, новый. В этом, к сожалению, уже ответить не сможем :(».

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

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

​​🦠 Меняться прямо сейчас

Очень удивляет настрой некоторых компаний: «Кажется, мы это пережили! Наконец-то. Ура!»

Надо воспринимать работу в карантине как MVP продукта «удаленка». Компании смогли протестировать своих людей и процессы. Самое время интенсивно улучшать и то, и другое. А если придется — полностью менять.

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

Потому что когда случится «новая волна заражения», или COVID-20, или HRENOVID-21, то тем, кто относительно благополучно пережил этот карантин, второй раз может и не повезти.

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

​​🤖🤖 Подкрался незаметно

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

Делаете что-то несложное? Вас очень скоро заменят на ИИ.
Делаете что-то, на первый взгляд, сложное? Разложат на простые компоненты и заменят на ИИ.

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

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

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

​​🤦🏽 Perception is always reality

Открыл Облако от Mail.ru, решил выполнить несложную операцию. Облако мне выдало прекрасное сообщение (картинка внизу). Три ошибки и ощущение, что это писал полуразумный дырокол. Обнять и плакать, честное слово.

Я думаю, такие проблемы в интерфейсе надо решать административными методами. )

По тому, что у вас в интефейсе написано, ваш продукт и оценивают. Perception is reality.

​​🧩 О монетизации продукта

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

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

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

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

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

​​🚙 О создании одного великого продукта

Любопытно взглянуть из нашего времени на проект создания Ford T, самого знаменитого детища Генри Форда.

=> Форд выделил для проектной команды целый этаж своего завода в Дирборне. Вход туда был разрешен только Форду, одному из топ-менеджеров и нескольким лучшим инженерам. Команда не имела права общаться с другими сотрудниками завода. Ее общение с внешним миром тоже ограничили.
Изоляция команды избавила ее от политики, слухов и дрязг. Этим приемом пользовались потом и Стив Джобс, и Илон Маск. В наших реалиях можно хотя бы отгородить зону оупенспейса – уже поможет.

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

=> Форд проводил с командой все время, что позволяло быстро принимать решения в проекте.
Никаких комитетов и бюрократии. А у менеджера – максимум полномочий.

=> В процессе команда столкнулась со сложной проблемой – расчетный вес автомобиля составлял тонну. Форд требовал не больше 900 кг. Чтобы решить эту задачу, срочно пригласили экспертов из неавтомобильной сферы. Задачу решили, машина стала весить около 850 кг, и команда двинулась дальше.
Форд поощрял нестандартные идеи и использовал любой полезный опыт. Почему мы так редко подключаем профи из других сфер и рынков?

=> Перед проектной командой с самого начала поставили цель: сделать дешевый в производстве автомобиль из простых узлов. Команда сфокусировалась на этом, а не на удобстве использования продукта. Получилась, мягко говоря, необычная машина. В отличие от других марок, у Ford Т педаль газа была не педалью, а маленьким рычажком с правой стороны под рулевой колонкой. Зато передачи переключались педалями, причем этих педалей было три. Владельцам Ford T в некоторых штатах даже пришлось выдавать отдельные права.

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

Форд прекрасно знал о недостатках, но разрешил выпуск в серию. Он просто распорядился поставлять с каждым автомобилем набор инструментов – видите на фото ящик на подножке?
Вот вам MVP за сто лет до всяких аджайлов. Форд был сначала менеджером, а только потом инженером. И потому продукт вышел на рынок. А было бы наоборот, погрязло бы все в непрерывных улучшениях. Инженеров к управлению проектами и продуктами допускать нельзя, пока они мыслят как инженеры.

=> Форд еще на старте проекта думал о продвижении продукта. Чтобы снизить цену, Форд предложил гениальный маркетинговый ход: продавать автомобиль «в базовой комлектации», а все дополнения – за деньги. Даже зеркала и запасное колесо считались опциями, за них покупателю приходилось доплачивать.
Ну, это до сих пор используется. Во всех продуктах. )

​​📡 ​​Великие проекты: создание БТА

Один из проектов, поражающих воображение – создание БТА (Большого Телескопа Азимутального).
Для гуманитариев: такой телескоп – это не большая подзорная труба, а что-то вроде спутниковой тарелки. Только она сделана из зеркала.

Проект стартовал в 1960-м году, его менеджером стал Баграт Иоаннисиани, хороший управленец и талантливый конструктор.

Проект разделили на параллельные потоки работ:
1. Изготовить и собрать конструкцию телескопа.
2. Сделать зеркало.
3. Доставить результаты пунктов 1 и 2 на Кавказ, в Карачаево-Черкессию.
4. Установить и собрать телескоп.

Вот несколько фактов:
=> Для изготовления конструкции телескопа построили новый цех высотой с двадцатиэтажный дом.

=> Изготовление конструкции заняло пять лет, а сборка – еще полтора. Конструкция была готова в 1968 году.

=> Самое сложное – сделать зеркало. Представьте себе стеклянную тарелку высотой до второго этажа и массой как 60 легковых автомобилей. Для создания прототипа (!) зеркала построили отдельный цех, чтобы отработать технологию. На нее ушло три года.

=> Надо было отлить зеркало, а потом делать отверстия для крепления, придавать нужную форму, полировать. Для этого сконструировали и сделали новые станки и инструменты.

=> Зеркало отливали два года и закончили в 1966 г. Обработка же была закончена только в 1971 году! Итого 11 лет на зеркало. Почему столько возни? Зеркало такого диаметра очень сложно сделать (в мире никто до нас не делал), и оно должно быть идеальным. Даже микроскопические неровности делают работу бессмысленной. Огромная стеклянная штуковина два года остывала в стерильных условиях.

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

=> Телескоп доставили на Кавказ довольно быстро, за год. Но вот с зеркалом получилась засада. Как его везти? Это аморфная субстанция. Диаметром 6 м и массой 42 т. Встряска на кочке – начинаем проект заново. Малейшее колебание температуры – зеркало на выброс.
Тогда сделали масляные амортизаторы, погрузили на них зеркало, уложили в контейнер с постоянной температурой. До этого провели тест на прототипе, свозили его на Кавказ, отработали процесс.
Везли зеркало два месяца на баржах до Ростова-на-Дону. Потом месяц в горы на трейлерах c милицейским эскортом.

=> На месте еще около года конструкцию собирали и тестировали. В 1975 году телескоп запустили в эксплуатацию.

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

Пятнадцать лет напряженной работы. Преодоление огромного числа технических и административных препятствий. Создание целой отрасли.
А ведь еще надо астрономов завезти.)

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

​​❓Задачка на интервью

Кандидату на позицию менеджера проектов я даю на интервью всякие задачки. Среди них такая:

“Представьте, что вы — менеджер проекта разработки некой информационной системы. По подписанным договору и ТЗ, система состоит из 10 функций. У вашей команды на создание продукта есть 10 месяцев. Бюджет проекта — 10 рублей.
Итак: 10 функций, 10 месяцев, 10 рублей.
Команда начинает работать, все идет хорошо. Через 6 месяцев к вам приходит заказчик и говорит: “Я очень рад, что с нашим проектом все в порядке. Но я хочу, чтобы вы добавили в мою систему еще две функции”.
Расскажите подробно, как вы будете действовать в этом случае”.

Почти все кандидаты, разумеется, начинают с оценивания возникших доработок. Тогда я говорю: “ОК. Результат оценки — нужно еще 2 месяца и 2 рубля.” Кандидаты предлагают сдвинуть сроки окончания проекта. Или заменить какие-то старые функции на две новые. Или нанять команду, которая бы параллельно запилила две новые функции. Или уговорить клиента сдать сначала старые, а потом открыть еще один проект и сделать новые функции. Или выполнить дополнительную работу бесплатно, если клиент для нас важен. Или послать его куда подальше, договор-то подписан, а в нем про новые функции нет ни слова.

Это все правильно, но задача про другое.)

Поэтому я говорю: “ОК. Заказчик отказывается сдвигать сроки проекта и не дает денег. У вас было 10 функций, 10 месяцев, 10 рублей. А теперь 12 функций, 10 месяцев и 10 рублей. И ваше руководство поддержало заказчика, и денег тоже не даст. Какие у вас еще есть управленческие инструменты, чтобы помочь заказчику?”

И тут примерно 80% кандидатов впадают в ступор. И не знают, что же делать.
Это очень удивительно. Задачка-то совсем простая.

Вы же знаете ответ, да? )

​​🔆 Ответ к задачке

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

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

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

А кто не понимает — работает в каких-то других компаниях. )

🎳 Тренажер для менеджеров и не только: 69-17 

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

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

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

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

Олег просит вас помочь вытащить проект из болота.

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

​​🔎 Комментарии к задачке 69-17

Варианты А и В выбирают обычно люди молодые и энергичные. У них нет ни многочисленных обязательств, ни жесткого жизненного графика. Зато нет и опыта решения задач, они с радостью возьмутся за еще одну. Хорошие отношения — это замечательно, но личные приоритеты важнее. Выгода — понятие обтекаемое, если она не выражена в конкретном предложении. Если Олег так хорош в карьере, почему он этого не понимает? Или понимает, но молчит? )

Вариант С годится только в том случае, если задача Олега вам совсем не интересна. Но тягу к новому и жажду учиться ведь никто не отменял? С этой точки зрения вариант D ничем не лучше.

Вариант Е не так уж плох. Никто не знает, как повернется жизнь: вдруг вы дадите аналитику Олега такой совет, от которого всем будет только хуже? Кто будет отвечать за результат? Советы только тогда чего-то стоят, если за них несут ответственность. Иначе это просто легкий треп ни о чем.

А еще советы хоть чего-то стоят, если за них готовы платить. И не обязательно деньгами. Например, в одной компании такой "валютой" были дни дежурства по выходным — разработчики не любили дежурить и обменивали свои часы дежурства на какие-то услуги. Поэтому вариант F весьма жизнеспособен. Хотя с ним надо аккуратнее: если что-то случится с основным проектом, как вы будете разрываться между двух?

Что касается варианта G, то и тут все не очень просто и зависит от культуры компании. Если она предполагает помощь и сотрудничество, то все в порядке. Если же нет, то менеджеру нет смысла делить вас с другими проектами. Зачем ему лишние риски?
Но согласовать свое участие в других задачах — это подход профессионала. Так что вариант G — самый верный. Приятно, что большинство читателей это понимает.

В жизни еще можно комбинировать варианты F и G. Это разумно.

Еще раз:
1) Вы не обязаны делать ничью работу без вознаграждения, которое считаете адекватным. Интересная задача — тоже награда.
2) Вы можете делать все что угодно в свободное время. Но что такое свободное время в жестком и сложном проекте?
3) Ничего не надо делать ради "хороших отношений". Особенно если за дверью офиса у вас еще огромная жизнь и личные планы.
4) Одно дело — дать комментарий, помочь советом, который не требует долгого изучения вопроса, другое дело — работать над задачей.
5) Помощь людям — дело хорошее. Только не увлекайтесь. )

♟♟ Тренажер для менеджеров и не только: 73-24

Вы — менеджер проекта по разработке софта в крупной компании. Ваша команда уже несколько лет разрабатывает важный продукт.

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

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

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

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

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

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

Комментарии к ответам будут завтра. Или послезавтра.)

​​🔎 Комментарии к задачке 73-24

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

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

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

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

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

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

🗑 Признаки бесполезной бизнес-книжки

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

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

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

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

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

5. Цитаты.

6. Притча о строительстве храма.
Эту бородатую притчу особенно любят молодые авторы. Им кажется, что нет повести прекраснее на свете. Сколько можно выдавать несвежую осетрину за только что пойманную?

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

8. Едкая критика компании Enron.
Да, Enron — символ умышленного корпоративного мошенничества. Да, крах этого гиганта превратил "большую пятерку" в "большую четверку". Но сколько можно? Ни одного из популярных бизнес-авторов и близко не подпустят к управленческим задачам такого масштаба, который был в Enron.

9. Постоянные ссылки на японские управленческие методы.
Экономика Японии давно находится не в самом хорошем состоянии. Нашли с кого пример брать.
Мало кто реально работал в японских компаниях. Зачем писать про то, чего сам не видел?
Ну и большинство японских бизнес-терминов прекрасно переводится на другие языки, нет смысла устраивать терминологический Вавилон.

10. Поучительные истории про Apple, McDonald's, Kleenex и Walmart.
Да, энтузиазм среднестатистического американца вспыхивает, когда он слышит про подвиги основателей этих знаменитых брендов. Подумаешь, всего-то полвека прошло.
Готов также поверить, что все это можно посеять и в нашу каменистую почву. Но уж слишком это удобно и просто — кивнуть на гигантов за спиной. Обычно в текстах, где таких кивков много, одна пустота.

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

12. Придуманные синтетические аббревиатуры.
Неленивый автор бизнес-книжки обязательно изобретет свою методику чего-нибудь и назовет ее мнемонической аббревиатурой, акронимом. Все эти DREAM, SUCCESS, DISC. Чтобы нам легче было запомнить. Но это как пытаться запомнить "красивый" номер телефона химчистки: вроде там есть только пятерки и семерки, но в какой последовательности и сколько?

Присутствие этих маркеров в книжке еще не приговор, но вот злоупотребление ими — гарантия бесполезности.

Выбросить нельзя читать. Запятую сами поставьте.)

​​​​🚹 🚺 🎦 Тренажер для менеджеров и не только 927-800

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

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

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

Эйчары у вас фоткать не умеют нормально, вы уж их простите, что было, то и прислали. )

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

Поймете по фото, кого стоит звать, а кого не нужно?

Комментарии к ответам будут завтра. Или послезавтра.)