Секрет успешных проектов. Взгляд через призму гештальт-подхода

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

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

Впрочем, продолжим. Каждый успешный проект прежде всего начинается со знакомства с его командой, с заказчиком и даже, если так можно выразиться, с духом или атмосферой проекта (контекстом, в котором он родился и в котором находятся его участники). Поэтому давай и мы с тобой сначала немного познакомимся, чтобы простроить базу для доверия и взаимопонимания. Представлюсь – меня зовут Сергей, я много лет занимаюсь ведением различных организационных и ИТ-проектов, последние несколько лет руковожу менеджерами проектов, организую их работу. А еще раньше работал программистом, консультантом в управленческом консалтинге и даже как-то финансовым директором. Ещё со школы изучал менеджмент, скажем так «классический», потом с удовольствием развивался в этом направлении в институте и на практике, и так случилось, что спустя много лет начал постигать психологию, в т.ч. организационное консультирование, и, крайне воодушевлен, теми возможностями, которые мне открылись. Хочу поделиться с тобой своими находками.

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

Однако ближе к делу. Так случается, что проекты, как говорится, «не взлетают». Привлекая методологию проектного менеджмента анализируем, что послужило причиной. Отсутствие плана управления проекта, недостаток ресурсов, небрежное отношение к управлению рисками, и т.д. по списку. Это всё, безусловно, крайне важно. Но часто ключевая проблема лежит вне рамок вопросов проектного управления. Иногда бывает так, что идеально запланированный и обеспеченный ресурсами проект проваливается. Или формально завершается успешно, но в восприятии заказчика становится «вещью в себе» и списывается на счёт «Прибыли и убытки», причем не по статье «Прибыль». Случается и обратное – проект без внятного плана, с откровенно слабой командой, без адекватных ресурсов, криво, косо, но запускается. И заказчики очень ценят его результат. За годы работы я получил разносторонний опыт по всему обрисованному спектру ситуаций и пришел к выводу, что есть кое-что, что во многом предопределяет результат проекта. Будет успех или провал. И это кое-что это не расклад натальной карты у астролога 😁

Зайдем издалека, с теории. И начнем с «классического» менеджмента, с т.н. цикла Деминга.

Цикл Деминга (англ. Deming Cycle — круг качества) – это постоянный круг регулирования усовершенствования продукта и производственных процессов, оптимизации отдельных единиц и объектов. Этот круг часто называют циклом PDCA (Plan-Do-Check-Act):

1.    Планирование

2.    Осуществление

3.    Проверка

4.    Претворение в жизнь (корректировка)

Всё в этом цикле Деминга логично и правильно, так? Так, да не совсем, но об этом позже. Ты можешь заметить, что цикл Деминга это что-то не из методики управления проектами. Да, это так, но заложенные принципы в цикле PDCA являются фундаментальными, и в проектном менеджменте они просто более развернуты, а цикл Деминга понадобится нам из-за простоты и наглядности, для «стыковки» с одной важной концепцией из другой дисциплины, пока подержим его в уме.

Касательно принципов проектного управления – то они соответствуют циклу Деминга, это можно наглядно увидеть в следующей таблице соответствия:

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

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

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

Попробую начать с аналогии. Предположим у тебя есть прекрасно составленный план управления проектом, все документы утверждены и ресурсы выделены. Образно говоря у тебя есть автомобиль (выделены ресурсы), ты умеешь на нем ездить (есть необходимая квалификация), тебе названы координаты места назначения (определена цель) и ты составил на карте подробный путь к месту назначения (составлен план управления проектом). Казалось бы, что еще нужно для успешной поездки? Разовьём аналогию – ты садишься в автомобиль и едешь в точку назначения и успешно доставляешь груз. И так раз за разом. Но вот однажды посередине пути автомобиль заглох. И ты точно знаешь, что он исправлен (в плане управления рисками было прописано прохождение ТО перед выездом, и оно было качественно проведено). В чем же может быть причина остановки? Ответ банален – нет топлива. Автомобиль не едет без топлива как бы все остальное не было бы прекрасно организовано. Рискну предположить, что данная аналогия может вызвать определенную степень неприятия, но прошу немного потерпеть. Возвращаясь из мира аналогий к обычным терминам менеджмента слово «топливо» переведем как «мотивация». Для того, чтобы вовлеченные в проект люди энергично и результативно действовали нужна мотивация. И речь не сколько и не столько про финансовое вознаграждение, а про ту внутреннюю движущую силу, которая заставляет человека встать с дивана и начать активно действовать.

Мотивация, стремление людей к действиям, и является тем «топливом», которое запускает внутренние винтики проекта, заставляет его двигаться вперед. Уверен, что в сказанном ничего нового и необычного для тебя нет, и в планах управления рисками проекта проблемы с мотивацией грамотными руководителями проектов (РП) прорабатываются. Но позволь продолжить - откуда мотивация берется? Вот некий сотрудник, который должен в рамках проекта начать выполнять новую функцию сопротивляется изменениям. «Эка невидаль» скажет опытный РП. Нужно всего лишь на всего попытаться «продать» изменения данному сотруднику, обучить, рассказать за всё хорошее и, возможно, проблема решится сама собой. Как вариант создать ему какую-то дополнительную «плюшку», и взамен он пойдет на встречу. А если это не поможет – организовать «пенетрационные» воздействие со стороны его руководителя. Рабочий инструментарий, которого часто более чем достаточно. Когда сотруднику, который ценит своё рабочее место, объясняют, что если он будет саботировать проект вскоре наступит увольнение, то непостижимым образом его мотивация резко возрастает, и проект продолжает движение вперед. Но любой многоопытный РП скажет, что это не всегда так работает. Сотрудник может ценить своё рабочее место в меньшей степени чем зависит руководитель от этого специалиста. Да и сам руководитель может быть не заинтересован в проекте и воздействие на сотрудника будет формальным. А ещё руководитель сотрудника может быть заинтересован в провале проекта, да, так тоже бывает, и не так уж редко. Много может быть причин саботажа. И как тогда быть? Ясно же - тогда идём к руководителю руководителя. Но ты же понимаешь, что обычно это более занятой человек, важных вопросов наряду с твоим у него на повестке больше, времени и энергии выделенных на тебя меньше, а уровень его зависимости от нижестоящего руководителя достаточно высокий (это рядовых исполнителей обычно проще заменить, а руководитель более сложная позиция). Это приводит к тому, что требуемая для продвижения проекта эскалация конфликта затрудняется. А без этого проект топчется на месте. У вышестоящего руководителя должна быть сильная мотивация на успешную реализацию проекта. Эта мотивация должна быть такой силы, что он будет готов при необходимости «вырезать» всех сопротивляющихся и заставить делать всё что нужно всех недовольных. Т.е. сила мотивации главного лица должна быть выше силы сопротивления участников команды (которая на самом деле состоит из массы плюсиков и минусов, но упростим в некий интегральный показатель). Пока, надеюсь, всё очевидно.

Итак – если проект заглох, то что бы его спасти нам нужно на своем уровне максимально снизить силу сопротивления (отрицательную мотивацию на новоязе :) ) у участников проекта и обеспечить превышение силы мотивации главного лица над совокупной силой отрицательной мотивации (сопротивления) остальных участников. В какой-то степени руководитель проекта может регулировать степень и знак заряженности участников проекта, но мы должны помнить об ограничениях по времени, стоимости, качеству… В некой известной степени эластичность уровня мотивации ограничена. И может оказаться так, что обуздать ситуацию не получится, и главное лицо не сможет проявить достаточной управленческой потенции для продвижения проекта вперед. И проект будет провален.  Ну что ж, можно будет развести руками и сказать, что во всем виноват заказчик (или главное лицо). Но провал при этом останется провалом, а мы же заинтересованы в успехе, не так ли?

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

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

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

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

1. Откуда проистекает потребность? Упрощенно говоря потребность рождается от боли. Отдельный человек и группы людей являются открытыми системами, и для выживания и развития вынуждены брать ресурсы из окружающей среды. Если у системы наблюдается дефицит чего-то (например, голод у человека, дефицит денежных средств у предприятия), либо избыток (переполнен мочевой пузырь или затоварен склад, соответственно), то появляется состояние дискомфорта, которое усиливается вплоть до боли. Еще можно сказать, что потребность вызвана отклонением от равновесного состояния открытой системы (гомеостаза). Любая, даже самая бредовая на первый взгляд потребность, имеет в своей основе первопричину, и первопричина эта окажется какой-то болью (от дефицита или избытка). Тема потребностей настолько глубокая и сложная, что можно написать книгу или даже несколько, но в базе важно понять, что маркер правильно выявленной потребности - это попадание в болевую точку. Так, корень «боль» четыре раза употребил, пока достаточно для понимания что такое потребность😎

2.  Все ли потребности дают энергию на мотивацию? Нет, не все. Точнее не всегда. Как определить какая потребность дает нужную нам мотивацию? Потребностей у любого человека и организации много. Но в каждый конкретный момент времени есть только одна актуальная потребность. Это очень важно для понимания. Вся история про многозадачность человеков —  миф, причем на мой взгляд достаточно опасный. В гештальт-подходе есть понятия фигура (gestalt) и фон. Если фигура — это потребность, то всё остальное (включая другие потребности) это фон. Или контекст, если угодно. В конкретный момент времени на передовой всегда оказывается только одна, самая острая потребность (та, в которой больше всего боли). Потребности борются за место под солнцем, сменяются, но в моменте только одна ведущая, фигура в центре внимания, и именно она дает энергию на действия здесь и сейчас.

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

Продолжим, мы с тобой проговорили, что такое мотивация, что такое потребность, и что только самая актуальная потребность оттягивает на себя основное внимание и ресурсы и заряжает мотивацию. Но что же дальше происходит с потребностью, после появления мотивации? Дальше человек (группа людей) пытается удовлетворить актуальную потребность. В гештальт-подходе разработана так называемая модель удовлетворения потребности – «цикл контакта» (очень обобщённо - контакта с реальностью с целью удовлетворить свою потребность). 

Ниже основные этапы «контакта»:
1.    Выявление потребности («преконтакт»)

2.    Действия, подводящие непосредственно к удовлетворению потребности («контактирование»)

3.    Собственно, процесс удовлетворения потребности («полный контакт»)

4.    Ассимилирование полученного опыта («постконтакт»)

И если сопоставить цикл контакта с ранее рассмотренным циклом Деминга и с принципами проектного управления, то можно обнаружить определенное сходство. И разницу. Приведу таблицу соответствия:

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

У цикла контакта в гештальт-подходе кроме акцентирования внимания на крайне важном этапе выявления потребностей есть и ещё огромное преимущество перед циклом Деминга. Цикл контакта в гештальт-подходе трехмерный. В нем помимо этапов еще есть время и энергия. Неправильное прохождение этапа выявления потребностей обуславливает низкую энергию (мотивацию), и, следовательно, не способствует успеху. Кроме того, другие этапы также важны, и на них тоже могут быть проблемы с прерыванием энергии (контакта), даже при условии правильно выявленной потребности. Но это тема отдельной статьи.

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

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

Итак, давай сменим повестку на позитивную, что делать, что бы проект был успешен? В чем главный секрет, который обещан в начале статьи? Собственно говоря, секрета уже и нет – нужно тщательно выяснять потребности. Перед проектом. Сразу при начале проекта. В течении проекта. Осознанно тратить на этап выявления потребностей много времени. Не кидаться сразу в бой. Задавать вопросы заказчикам – «зачем?», «что это даст?», «что бы что?», «какую именно проблему Вы хотите решить?», «если не сделать проект, то что будет болеть?», «Почему?», «Почему Вы решили, что именно так нужно делать проект?» и т.д. Обязательно получить от заказчика подтверждение, что вы с ним одинаково понимаете какую именно потребность организации вы закрываете проектом и как именно.  Прямо ввести в проектную документацию, например, в раздел «Деловые обстоятельства», отдельный детальный пункт «описание потребностей». И если у вас получится правильно идентифицировать совместно с заказчиком потребность и способ её удовлетворения, то дальше соотнести затрачиваемые ресурсы с пользой от удовлетворения потребности, и с пользой от удовлетворения других потребностей. Удовлетворение заказчика будет максимальным, и его вовлеченность высокой только если вы делаете самый нужный в данный момент проект. Чем менее острая потребность и высокая стоимость проекта, тем меньше будет доволен заказчик и тем выше будет риск провала проекта.  Причем если говорить о потребностях, важно помнить, что они могут быть разными у организации, её подразделений, у внешней среды (клиенты и поставщики), у членов проектной команды, у отдельных персоналий. Добавлю еще метафору – успешный руководитель проектов как капитан парусного судна, который строит маршрут исходя из морских течений и розы ветров, и может искусно лавировать, ловя ветер в парусах.

Навык выявления потребностей сложный, его нужно нарабатывать, в гештальт-подходе это целая технология. Но согласно правилу Паретто 80% результата дает 20% усилий, поэтому даже интуитивно, старательно выявляя потребности ты многократно повысишь свою успешность как руководитель проектов. Но неплохо знать хотя бы азы. Вот тут и обещанная философия подъехала. Есть такое направление в философии – феноменологический подход (один из столпов гештальт-подхода) – если максимально его «приземлить» для целей управления проектами, то речь идет о важности восприятия анализируемого предмета/ситуации как бы с чистого листа, словно ты марсианин, непредвзято, и делая акцент именно на фактах, а не на их интерпретациях. Замечать странные феномены, признавать важность всех фактов, даже самых мельчайших. Тестировать свои догадки. Например, идет совещание по вопросу инициации некого проекта (пусть те же ТСД), участники выдвигают разные инициативы, давайте вот это автоматизируем, и это. И так далее. И при этом завсклад, отвечающий за организацию складского учета, всё время молчит, скрестив руки в три узла. Можно долго фантазировать, что это значит, но точно это важно заметить и прояснить, какова причина его молчания.

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

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

Оригинал статьи здесь.