×Закрыть

13 вредных советов для проектного менеджера

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

1) Не оговаривайте всех деталей с клиентом

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

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

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

2) Не фиксируйте результаты телефонных и устных переговоров в переписке

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

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

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

3) Не уточняйте ТЗ

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

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

4) Соглашайтесь на все доработки без оценки

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

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

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

5) Не следите за ходом выполнения работ

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

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

6) Подолгу не отвечайте клиенту

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

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

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

7) Работайте по своему особому графику

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

Нестыковка во времени знакома всем project менеджерам, которые работают с иностранными клиентами.

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

8) Передавайте информацию между техническими специалистами своими словами

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

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

9) Делегируйте общение с клиентом вашим разработчикам

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

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

10) Перекладывайте всю работу над ошибками на ваших сотрудников

Очень часто возникают ситуации, когда предоставленный клиентом API работает иначе, чем заявлено в документации. Ситуация усугубляется тем, что IT-отдел клиента по каким-либо форсмажорным причинам не может внести изменения со своей стороны. И вы возлагаете на плечи своей команды все тяготы подгонки функционала до рабочего состояния.

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

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

11) Используйте только один канал связи

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

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

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

12) Храните информацию о проекте как попало

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

К примеру, у меня такая ситуация возникала, когда файлы по проекту были равномерно распределены в почте, dropbox, google drive и skype. Очень важно выработать единую структуру хранения файлов по проекту, которая позволит вам избежать лишней траты времени на то, чтобы объяснить коллеге, где находится нужный ему файл.

13) Реагируйте эмоционально на любые спорные ситуации по проекту (бонус)

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

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

44 комментария

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

Можно с этого места поподробнее, приходилось работать с разными почтовыми клиентами, да и почтовыми серверами тоже. Но ни в одном не было опции «ПИСЬМО ПРОЧИТАНО» или хотя бы «открыто».
О стандартном ответе сервера что письмо доставлено, это думаю все знают. Но вот узнать что оно было открыто не говоря уже о том что оно прочитано, :)

А есть то же самое только для Mozilla Thunderbird или можно адаптировать? За ссылку спасибо интересно.

это универсальный подход(кстати, клиенты могут детектить tracking image и подавлять его, сообщая пользователю).
outlook от thunderbird отличается только тем, как будет кастомная HTML разметка добавляться

Одна из стандартных функций Lotus Notes но работает соотв. только внутри самой системы т.е. оба адресата должны быть там.

9 пункт зло, надо делать как раз наоборот, другое дело что общение внутри команды никто не отменял

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

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

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

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

9) Делегируйте общение с клиентом вашим разработчикам
Как результат предыдущего пункта, у вас могут возникнуть и негативные последствия, когда менеджер клиента начнет общаться с вашими сотрудниками напрямую, выставляя при этом им разнообразные правки и задачи, не уведомив об этом вас. И тут вы должны четко понимать, что любая постановка задач должна идти через вас, потому что именно вы ответственны за оценку задачи и приоритета её выполнения. Необходимо пресекать попытки клиента ставить задачи вашим сотрудникам без вашего ведома.
Вы либо путаете две очень большие разницы — общение с клиентом и постановку задачи, либо у вас до сих пор не было адекватного клиента, который сам умеет различать общение и озадачивание :) Первая весчь в любых объемах исключительно полезна для того, чтобы исполнитель почувствовал себя причастным к чему-то большему, чем ежедневному кодированию или тестированию 8 часов подряд с перерывом на перекус. Вторая, озадачивание, кстати вполне может идти через подотчетных ПМ-у технических или тим-лидеров, если проект достаточно велик и задачи текут из разных источников. Даже в том, что клиент сильно любит одного васеньку и предпочитает ставить задачи и слышать его оценки лично, я не вижу трагедии; главное — это должно быть согласовано с ПМ-ом, а у ПМ-а должен быть определенный уровень доверия к заказчику и васеньке. Именно «пресечь» тут ИМХО не всегда выход, следует найти компромисс... например, сделать васеньку тех-лидом.

Отличнейшая статья. Напоминает быдло-пмов где-то там лет 5-7 назад))) Хотя и сейчас подобные встречаются, почему-то среди мужчин пм-ов гораздо больше. ХОтя и девушек 20-летний пм-ов хватает.

Добавлю, лично я уже привык к тому сто ПМ, менеджеры идиоты и обычно пишу им письма с вопросами в стиле, что бы у них был единственный ответ Да или Нет.
То бишь пишу, нужно сделать вот это (детальное описание). Да?
Самое смешное, что находятся такие, что или игнорируют, пока не повторишь письмо 3 раза (обезательно включив уведомление о прочтении). Или вместо простого ответа Да или Нет, начинают рассказывать, как космические корабли бороздят просторы большого театра. Или хуже того, любят пообщаться голосом ни о чем.

Как по мне автор молодец!

Эта статья как минимум полезна еще и девелоперам, чтобы они понимали, где граница их ответственности, а где нужно бить палкой ПМа за разгильдяйство :)

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

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

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

это и так понятно :)
в статейке показаны индикаторы, когда нужно сваливать побыстрее :)

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

Это тоже знак девелоперам!

А мне статья понравилась. Как минимум 10 из этих советов из 13 , сколько видел менеджеров, выполняли неукоснительно с последующими воплями «Просрали все полимеры».

Слишком наивно, как по мне.
То есть, подойдет для тех РМ-ов, которые пришли в профессию не из IT и работают в «шарашкиных конторах» (то есть для "РМ«-ов — в кавычках).
Для остальных, выглядит смешно, но во всяком случае для меня. Изложенное выше побуждает меня написать нормальную (читай, полезную для тех, кто реально работает РМ-ом) статью на эту тему, и не с советами, а об пройдем опыте способах решения (как успешных, так и нет) возникавших по пути проблем.
Может таки «рожу» какой-то эпос, а то после «Как я ездил доставлять в Москву» ничего особо интересного на ДОУ я как-то и не писал.
Прошул год, видимо пора бы :D

А всех остальных, не PM’ов, вы со счетов списали, как незначительную серую массу? Мне вот статья понравилась — лекгая и весёлая.

Похвалиться тем, что не сделано — любой дурак сможет. Ждём рождения «нормальной статьи» вашего пера на тему «реально работающих PM’ов». Я прям вся в нетерпении.

А всех остальных, не PM’ов, вы со счетов списали, как незначительную серую массу?
И да, и нет. Это очевидно и для тех кто не РМ :)
Похвалиться тем, что не сделано — любой дурак сможет.
Во-первых, правильно не «любой дурак», а «даже дурак», а во-вторых — чем я хвалился, не подскажите?
Придется потерпеть, Наталья. От мысли написать статью о Москве до её написания прошло полгода :)

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

Ну и, в рамках чисто филологического интереса, на каком основании вы решили, что

правильно не «любой дурак», а «даже дурак»
"Автор пишет фуфел, а я крутой.
Каждый видит то, что хочет. С моей точки зрения, то что написал автор не подходит под тутошнюю аудиторию, вот и всё.
Ну и, в рамках чисто филологического интереса, на каком основании вы решили, что
Потому что смысл разный как бы, не находите?!

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

Было бы очень интересно почитать статью о PMстве, тем более, что уже и пол года прошло :)

То есть, подойдет для тех РМ-ов, которые пришли в профессию не из IT

т.е по Вашему только АйТи дает обществу правильных ПМов?

Да, хороший РМ-ов в IT даёт только IT. А про всех остальных есть комментарии из сериала «РМ-ы не нужны», так как для многих, почему-то, РМ — это нянька для команды.

Да, хороший РМ-ов в IT даёт только IT.

а что такого особенного есть в АйТи, чего например нету в строительстве, логистике или производстве?

именно такого, что и делает АйТи ПМов особенными?

в чем цимес именно АйТишных проеков?

Вы мой текст вообще читаете или сами с собой общаетесь? Хорошим РМ-ом

Да, хорошим РМ-ов в IT даёт только IT
...
Ну научитесь быть РМ-ом дворников, сходите на собеседования в РМ-ы хирургов... надеюсь метафора ясна.

Как бы прочитал именно это

То есть, подойдет для тех РМ-ов, которые пришли в профессию не из IT и работают в «шарашкиных конторах» (то есть для "РМ"-ов — в кавычках).

вот собственно и возник по факту прочтения вопрос о цимесе...

а это

Да, хороший РМ-ов в IT даёт только IT.

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

мы понимаем друг друга? верно?

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

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

тем более, что это у вас шикарно получается :)

Ну научитесь быть РМ-ом дворников, сходите на собеседования в РМ-ы хирургов
весь мир во главе с PMI уже давно знает, что проектный менеджмент — это отдельная отрасль знаний. только украинские ИТшники продолжают бить себя в грудь кулаком и кричать «кто не кодил — тот москаль не ПМ». Смешно же, право слово, когда ж корона-то упадет — когда в сертификацию PMP включат вопросы по ООП?
Уточню — погружаться в предметную область, естественно, необходимо. Но понятия «ПМ дворников», «ПМ строителей», «ИТ ПМ» не существует. Если, конечно, это специалист в области ПМ, а не бывший дворник-строитель-кодер, решивший, что практический опыт автоматически конвертируется в возможность быть ПМ.
Но понятия «ПМ дворников», «ПМ строителей», «ИТ ПМ» не существует

именно к этой простой мысли я и пробовал подвести Alexander Kuznyak ....

Практика показує, що досвід в прикладній області на порядок зменшує кількість помилок. Тобто якщо ПМ має досвід розробника, то він завчасно бачитиме проблеми зв’язані з розробкою, і зможе їх усунути. Якщо ПМ має досвід ПМ-а, то він завчасно бачитиме проблеми зв’язані з керуванням проектом, і їх усуне.
В конкурентному середовищі, клієнт віддаватиме перевагу тому ПМ-у, який створює йому менше проблем, тобто ПМ-у який має стаж в обох галузях.

З іншого боку, класики менджменту кажуть, що нормальний менджмент при конфлікту строків і якості, віддасть перевагу строкам, що часто приводить до загибелі компанії (погане слово: торопилы). Нормальний інженер в такій ситуації віддає перевагу якості, що часто приводить до втрати клієнтів або ринків на початкових етапах.

З власного досвіду розробника, з програмістом ПМ-ом можна нормально поговорити, а чистого ПМ-а можна тільки послати, бо, щоб з ним поговорити, його треба кілька років натаскувати. З власного досвіду як клієнта ситуація прямо протилежна — нормальний ПМ говорить про віхи, строки і бюджети а не про всіляку технічну х-ю, але платять не за це, а за результат.

IMHO, найкращий результат досягається коли є чистий ПМ, техлід(чистий технарь), і представник власника (технарь з можливостю поговорити з клієнтом і знаннями в клієнтьскій прикладній області), з яких кожен має досвід і право вето, але це дорого. А коли змішувати всі три ролі в одного ПМ-а, то тоді потрібен ПМ з досвідом роботи в усіх трьох галузях.

найкращий результат досягається коли є чистий ПМ, техлід(чистий технарь)
Согласен на все 100%. И мне пока везло, именно в такой формации я и работаю — она идеально работает при налаженных процессах.

Со стейкхолдерами не всегда так хорошо, но это уже работа ПМа).

На самом деле в словах Александра есть доля истины. ПМов универсалов в СНГ на пальцах пересчитать и их гонорары состоят из «шестизнаков».

Тем не менее, чтобы быть ПМом в определенной сфере, нужно в этой сфере что-то понимать.

Конечно есть _доля_ истины, и в моих словах тоже есть :)

И даже в Ваших словах есть _доля_ истины :)

Тем не менее, чтобы быть ПМом в определенной сфере, нужно в этой сфере что-то понимать.

Это никто не опровергает.
Есть люди, которые понимают, что нужно выучить специфические моменты отрасли.
А есть люди, которые убеждены, что они сразу родились ПМами :)

То есть, подойдет для тех РМ-ов, которые пришли в профессию не из IT и работают в «шарашкиных конторах» (то есть для "РМ"-ов — в кавычках).
А вот тут обидно было =D

Отлична подборка для IT-домохозяек.
А вообще, модератора здесь однозначно не хватает.

И еще совет. Никогда не постить статьи с советами на доу

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

это сарказм :)
знаете, как кота ловить в коробку :)

Це не правда. Опис лише позитивного досвіду призводить до невірних висновків із-за «survivorship bias».

Если уж и приплетать этот ваш

«survivorship bias»
в контекст статьи, то она дает советы как раз по результатам неагтивного опыта. Только дает все в таком же неагитвном ключе (как не нужно делать). А правильно подводить итоги в положительном ключе и писать о том, что нужно делать. Казалось бы суть таже, но полярность изложения очень важна.

Подписаться на комментарии