Я тоже сталкивался с такими людьми. Более того, сам по-человечески понимаю это чувство. Но я считаю такое поведение незрелым и стараюсь не взаимодействовать с подобными специалистами до поры до времени (видел, как у многих с возрастом и опытом этот подход менялся).
Я начал работать в Axure за десять лет до того, как появилась Фигма. А когда она появилась, никто не заставлял меня на неё переходить. Это просто инструменты.
Пожалуйста. Хочу поделиться с вами двумя моментами, когда мой подход к проектированию сильно менялся.
Первый — примерно через пять лет после начала карьеры. Году в 2010. Я был на острие передовых методов проектирования и внедрял их в свои процессы. Тогда в России только-только набирали популярность персонажи, jtbd, cjm. Я работал с несколькими студиями. Частные клиенты только-только появлялись в моей жизни. Моими самыми частыми проектами в тот период были интернет-магазины. И я тогда сделал около 40 таких магазинов в течение нескольких лет, с каждым проектом продавая всё больше дополнительных артефактов. Это несколько затягивало этап проектирования, но перформанс в глазах клиента был замечательным. Много документации, много оснований для принятия решений.
Но в какой-то момент я сравнил два прототипа. Один из первого десятка, а второй из последнего. И разница между ними была ну максимум процентов в двадцать. Процесс поиска и покупки товара в интернете был достаточно универсальным для того, чтобы с совершенно разными персонажами и сценариями в итоге стремиться к одинаковой форме. Там я прочувствовал, сколько ненужной работы продаю за деньги, и мне стало стыдно. После этого я вынес все эти дополнительные артефакты за скобки. И если мне нужно было воспользоваться одним из них для себя в каком-то особом случае, клиент об этом даже не догадывался.
Второй — когда я в течение пяти лет поднял собственный проект. Там-то круг и замкнулся. Во-первых, я убедился на практике, насколько хорошо работают мои подходы к работе (и окончательно распрощался с синдромом самозванца). А, во-вторых, увидел, насколько важны те вещи, которые мне раньше казались неважными. Как важно описывать всё в функциональной спецификации. Как важно иметь эталонный дизайн. Как важно учитывать стек технологий, если он нам известен на этапе проектирования. Проектировщику, который ни разу не запускал собственного проекта (или который ни разу не работал внутри команды, поднимающей проект), сложно получить эти знания. А я много лет проработал именно таким проектировщиком: проектировал информационные системы и махал клиенту ручкой. А ведь настоящая работа начинается где-то после релиза.
Нам надо сделать форму для клиента. С данными для договора. Заполняем тип заказчика и его реквизиты и тип исполнителя и его реквизиты. Указываем, кто берёт на себя ответственность за маркировку рекламы, сколько стоит размещение и на какой планируется срок.
Клиент хотел на выходе pdf, но я предложу ему на выходе doc, который можно легко подредактировать уже после генерации. Это сразу избавляет нас от сценариев, связанных с хранением и изменением данных, и удешевляет разработку без потери функций.
Проектируем набор полей, их валидацию, сообщения об ошибках и успехе. Берём актуальный договор, продумываем и показываем, какие данные и как туда попадают из нашей формы. Согласовав внешний вид формы, описываем её в функциональной спецификации.
Несколько раз в процессе предлагаем не усложнять проект. Первоначальная задача — автоматизировать часть небольшого процесса, который будет актуален для человека, занимающегся оформлением договоров (в нашем случае это сам заказчик или один из его менеджеров). Поэтому нам не нужны системы аутентификации, связи с внешними сервисами (например, запрос по api данных о юрлицах после заполнения ИНН), так как первое — избыточно, а последнее — потребует техподдержки в дальнейшем.
После этого передаём проектную документацию дизайнеру и программисту. От первого получаем пару-тройку позитивных правок плюс что-то всплывёт при адаптации формы под разные вьюпорты. От последнего — набор технических ограничений в связи с определившимся стеком технологий и просьбу использовать какой-нибудь конкретный фреймворк для вёрстки (бутстрап, например). На основе этой обратной связи актуализируем проектную документацию и корректируем дизайн.
— Персоны пользователей — не нужны, т.к. мы ещё перед началом проектирования точно знаем, кто будет пользоваться продуктом, как и в каких условиях; — CJM — не нужна. Прототип будет состоять из пяти-шести экранов, показывающих разные динамичные состояния формы. Плюс будет договор с выделенными и описанными динамическими участками. Сам по себе этот прототип и будет представлять собой самую наглядную CJM; — Отчёт о UX-тестировании — не нужен. Прототип и дизайн будут готовы в течение недели (два дня на прототип, два дня на функциональуню спецификацию). Ещё за неделю форму закодят и сверстают. И после этого начнётся настоящее «UX-тестирование».
Разумеется, перед началом работ мы проверим, нет ли чего-нибудь похожего уже в готовом виде. Возможно даже найдём и посмотрим, нельзя ли чего-нибудь из него позаимствовать.
Для каждого проекта, за который я берусь, я подбираю набор методик, подходящий ему по смыслу. Поэтому в статье я и не описываю эту часть. Она совершенно не универсальна. У меня не раз бывали клиенты, которые уходили довольные после первых переговоров-знакомства. Когда я в ответ на их запрос просто скидывал ссылку на сервис или набор сервисов, которые уже завтра могут решить его задачу — и проектировать ничего не надо.
Часть артефактов, которые вы перечислили — они либо для студентов, которым пока что нужны такие вспомогательные опорные штуки из-за отсутствия опыта, либо адресованы от специалистов к специалистам. Дайте мне проработанную CJM по проекту — и мне она поможет быстро въехать в суть дела. Дайте такой артефакт клиенту — и он оказывается в ситуации, когда ему нужно согласовать что-то, в чём ему трудно разобраться. Поэтому своим клиентам я не показываю и не предлагаю чего-то более сложного и абстрактного, чем интерактивный прототип. А сбор данных по проекту устроен таким образом, что клиент считает, что просто болтает со мной, а не помогает описывать чьи-то портреты или фиксировать процессы.
Даже функциональные требования я уже сколько лет подряд стараюсь упрощать и упрощать — а всё равно сложный документ, всё равно не читают его до конца, подписывают, а затем создают новые функциональные требования на лету. И это нормально, так и должно быть.
Можете уточнить, что именно вы вкладываете в понятия «исследование» и «тесты с пользователями»?
Возьмём, к примеру, проектирование сервиса, который автоматизирует процесс оформления договора на размещение и маркировку рекламы (пользователь заполняет форму с реквизитами сторон и некоторыми дополнительными данными — и на выходе получает pdf для подписи). Клиент — стартапер, который технически хочет автоматизировать собственный устоявшийся бизнес-процесс.
В моём случае клиент получит интерактивный прототип, который «пощёлкает» сам и, возможно, покажет паре знакомых с вопросом «как тебе?».
Как будет выглядеть этап исследования и тестов у вас и сколько займёт по времени и ресурсами?
Здравствуйте. Ваш вопрос лучше адресовать разработчику, а не проектировщику. Но могу пофантазировать.
1. Что именно нужно изучать — будет зависеть от того, что конкретно вы собираетесь разрабатывать; 2. Выбор языка также будет зависеть от программного комплекса, который вы собираетесь разрабатывать; 3. Время на изучение будет зависеть от вашей персональной способности к обучению, а также от того, будет у вас преподаватель (и какой именно) или нет.
То есть я бы сказал, что на ваши вопросы невозможно ответить, пока они настолько абстрактны.
1. Как давно у вас там существует аккаунт? 2. Вы получили 7 заказов за семь дней или семь заявок? 3. В каких числах это произошло? 4. Как вас там найти? (Очень интересно взглянуть на пример оформленного профиля) 5. За какой срок вы сумели выполнить эти семь заказов? 6. Получили ли вы новые заказы, пока выполняли те семь?
Конечно, бывают. В этом плане мне нравится пример с наглыми водителями на дорогах. Кто-то подрезает тебя или перекрывает целый ряд на светофоре в пробку. И такие товарищи очень хорошо врезаются в память и создают ощущение низкого уровня культуры вождения в целом. А на деле-то их единицы. Во время поездки вокруг мельтешат сотни, а то и тысячи порядочных водителей, а запоминаются непорядочные единицы. Так и здесь. В целом всё не так и плохо.
И уж тем более заказчик не должен выносить здесь каких-то решений, откуда у него такие компетенции?
Заказчик не должен выносить решений. Он должен согласовать решения, которые я ему предлагаю. Или дать обратную связь, которая может на эти решения повлиять.
Для меня вполне комфортна ситуация, когда сделав работу на 90%... начинаешь всё сначала, потому что только теперь ты понял, как на самом деле надо было.
Кстати, прекрасно понимаю. К сожалению, я упустил этот момент в заметке. А звучит он так: зачастую, увидев, что базовое решение не верно, я сразу начинаю переделывать проект с нуля (что-то вроде мягкого перезапуска). Поэтому я вдвойне заинтересован в том, чтобы не углубляться в детализацию там, где не надо. А поначалу старался спасать неверные решения огромным количеством костылей, что приводило к ещё более плачевным результатам.
Сочувствую! Наверное, это зависит от психотипа, но для меня такой подход решительно неприемлем.
Сочувствовать не стоит. Я действительно получаю удовлетворение от результата работы, когда вижу довольного клиента. В конце концов основная задача моего этапа работы — формализовать потребности клиента и перевести их на язык разработчиков. Если я эти самые потребности как-то не так интерпретирую, то кому тогда нужен результат моего труда? Но без конкретных примеров что моё, что ваше высказывания крайне субъективны и абстрактны.
Поделитесь мнением, пожалуйста. Как думаете, почему вот эта моя «графоманская» статья набрала плюсов и оказалась в основной ленте Хабра, а вот эта — нет? А эта?
Также есть вопрос по теме хаба. Какая глубокая техническая статья, не основанная на личных рассуждениях, может оказаться в хабе «Фриланс»? Можете привести пример?
Вот интересно, а почему когда мы говорим о росте, мы всегда подразумеваем вертикальный рост "вместе с рынком"? Почему рост это всегда в сторону организации и управления? И что в конце-концов значит "лучший в своем деле"? Кто это решил? На основании каких данных?
Я говорю только за себя. «Рос вместе с рынком» — становился более продвинутым специалистом по мере развития технологий и методологий на рынке проектирования интерфейсов. Когда я начинал, не было прототипирования, верстали на таблицах, был хтмл ранних версий, для дизайна использовался фотошоп. Сегодня ситуация сильно изменилась. И мне, подрастая вместе с рынком, гораздо проще было осваивать новые технологии, т.к. это был последовательный процесс.
В статье термин «лучший в своём деле» означает «лучший в рамках своего окружения». Я надеялся, что это будет понятно из контекста. Я, например, был какое-то время лучшим специалистом по работе в Axure. Если бы вы захотели изучить туториалы на русском языке на эту тему, то обязательно попали бы либо ко мне в группу в ВК, либо на один из моих видеороликов на ютубе.
Кто угодно может сделать хорошо, если создать подходящие условия. И только настоящий профессионал ни при каких условиях не сможет сделать плохо. Не знаю автора. Но уж очень мне в душу запало это высказывание.
Пример: я больше десяти лет рассказывал окружающим, что, работая на фрилансе, просто необходимо вести базу клиентов. При этом сам начал её вести в 2022 году. Я знал, как надо, знал, почему это важно и полезно, но не делал. При этом очевидно, что это не делало плохо моим клиентам. За последний год я больше сил вкладываю в распространение своего дизайнерского опыта — и это привело к тому, что базу пришлось завести, чтобы слова не расходились с делами. Так что одно дело знать, как надо, а другое — делать.
Вовсе нет. Это очень распространённое явление: начинающие стартаперы, особенно из технарей, упарываются в разработку вместо того, чтобы начинать с продаж. Вот и я совершил ту же ошибку, хотя вокруг полно информации о том, что «сначала продай — потом сделай».
К сожалению, не могу ответить на ваш вопрос, потому что не думаю, что излишняя обходительность — это приятно. Вообще любое излишество — это не очень рационально, что буквально заложено в само значение этого слова.
Красивый пример. Единственно, статью зачастую можно написать за один присест. А перекурить, почесать подбородок, а затем в течение месяца проектировать информационную систему, попутно получая обратную связь от других участников процесса, — это немного другое.
«Разумеется» — потому что это нормальная человеческая реакция. Если меня резко осадить в присутствии других людей — я ощущаю ту самую неприятную эмоцию, которая многим знакома. Александр был очевидно недоволен и это явно указано в тексте.
Вы знаете, возможно, вы правы и я действительно в 2014 году «не видел» других. Статья как раз об этом — об изменениях в лучшую сторону с течением времени. Но вот только «разумеется» никак с этим не связано. Акцент на собственных действиях (и персоне) плюс ответственность за них и эмоции, которые я испытываю при конфронтации, — это вещи из совершенно разных категорий.
Возможно, без яканья читать будет приятнее, не знаю. Сравнительное тестирование уже не проведёшь, а так статья явно зашла читателям и я не жалею, что опубликовал её.
Я тоже сталкивался с такими людьми. Более того, сам по-человечески понимаю это чувство. Но я считаю такое поведение незрелым и стараюсь не взаимодействовать с подобными специалистами до поры до времени (видел, как у многих с возрастом и опытом этот подход менялся).
Я начал работать в Axure за десять лет до того, как появилась Фигма. А когда она появилась, никто не заставлял меня на неё переходить. Это просто инструменты.
Пожалуйста. Хочу поделиться с вами двумя моментами, когда мой подход к проектированию сильно менялся.
Первый — примерно через пять лет после начала карьеры. Году в 2010. Я был на острие передовых методов проектирования и внедрял их в свои процессы. Тогда в России только-только набирали популярность персонажи, jtbd, cjm. Я работал с несколькими студиями. Частные клиенты только-только появлялись в моей жизни. Моими самыми частыми проектами в тот период были интернет-магазины. И я тогда сделал около 40 таких магазинов в течение нескольких лет, с каждым проектом продавая всё больше дополнительных артефактов. Это несколько затягивало этап проектирования, но перформанс в глазах клиента был замечательным. Много документации, много оснований для принятия решений.
Но в какой-то момент я сравнил два прототипа. Один из первого десятка, а второй из последнего. И разница между ними была ну максимум процентов в двадцать. Процесс поиска и покупки товара в интернете был достаточно универсальным для того, чтобы с совершенно разными персонажами и сценариями в итоге стремиться к одинаковой форме. Там я прочувствовал, сколько ненужной работы продаю за деньги, и мне стало стыдно. После этого я вынес все эти дополнительные артефакты за скобки. И если мне нужно было воспользоваться одним из них для себя в каком-то особом случае, клиент об этом даже не догадывался.
Второй — когда я в течение пяти лет поднял собственный проект. Там-то круг и замкнулся. Во-первых, я убедился на практике, насколько хорошо работают мои подходы к работе (и окончательно распрощался с синдромом самозванца). А, во-вторых, увидел, насколько важны те вещи, которые мне раньше казались неважными. Как важно описывать всё в функциональной спецификации. Как важно иметь эталонный дизайн. Как важно учитывать стек технологий, если он нам известен на этапе проектирования. Проектировщику, который ни разу не запускал собственного проекта (или который ни разу не работал внутри команды, поднимающей проект), сложно получить эти знания. А я много лет проработал именно таким проектировщиком: проектировал информационные системы и махал клиенту ручкой. А ведь настоящая работа начинается где-то после релиза.
Нам надо сделать форму для клиента. С данными для договора. Заполняем тип заказчика и его реквизиты и тип исполнителя и его реквизиты. Указываем, кто берёт на себя ответственность за маркировку рекламы, сколько стоит размещение и на какой планируется срок.
Клиент хотел на выходе pdf, но я предложу ему на выходе doc, который можно легко подредактировать уже после генерации. Это сразу избавляет нас от сценариев, связанных с хранением и изменением данных, и удешевляет разработку без потери функций.
Проектируем набор полей, их валидацию, сообщения об ошибках и успехе. Берём актуальный договор, продумываем и показываем, какие данные и как туда попадают из нашей формы. Согласовав внешний вид формы, описываем её в функциональной спецификации.
Несколько раз в процессе предлагаем не усложнять проект. Первоначальная задача — автоматизировать часть небольшого процесса, который будет актуален для человека, занимающегся оформлением договоров (в нашем случае это сам заказчик или один из его менеджеров). Поэтому нам не нужны системы аутентификации, связи с внешними сервисами (например, запрос по api данных о юрлицах после заполнения ИНН), так как первое — избыточно, а последнее — потребует техподдержки в дальнейшем.
После этого передаём проектную документацию дизайнеру и программисту. От первого получаем пару-тройку позитивных правок плюс что-то всплывёт при адаптации формы под разные вьюпорты. От последнего — набор технических ограничений в связи с определившимся стеком технологий и просьбу использовать какой-нибудь конкретный фреймворк для вёрстки (бутстрап, например). На основе этой обратной связи актуализируем проектную документацию и корректируем дизайн.
— Персоны пользователей — не нужны, т.к. мы ещё перед началом проектирования точно знаем, кто будет пользоваться продуктом, как и в каких условиях;
— CJM — не нужна. Прототип будет состоять из пяти-шести экранов, показывающих разные динамичные состояния формы. Плюс будет договор с выделенными и описанными динамическими участками. Сам по себе этот прототип и будет представлять собой самую наглядную CJM;
— Отчёт о UX-тестировании — не нужен. Прототип и дизайн будут готовы в течение недели (два дня на прототип, два дня на функциональуню спецификацию). Ещё за неделю форму закодят и сверстают. И после этого начнётся настоящее «UX-тестирование».
Разумеется, перед началом работ мы проверим, нет ли чего-нибудь похожего уже в готовом виде. Возможно даже найдём и посмотрим, нельзя ли чего-нибудь из него позаимствовать.
Для каждого проекта, за который я берусь, я подбираю набор методик, подходящий ему по смыслу. Поэтому в статье я и не описываю эту часть. Она совершенно не универсальна. У меня не раз бывали клиенты, которые уходили довольные после первых переговоров-знакомства. Когда я в ответ на их запрос просто скидывал ссылку на сервис или набор сервисов, которые уже завтра могут решить его задачу — и проектировать ничего не надо.
Часть артефактов, которые вы перечислили — они либо для студентов, которым пока что нужны такие вспомогательные опорные штуки из-за отсутствия опыта, либо адресованы от специалистов к специалистам. Дайте мне проработанную CJM по проекту — и мне она поможет быстро въехать в суть дела. Дайте такой артефакт клиенту — и он оказывается в ситуации, когда ему нужно согласовать что-то, в чём ему трудно разобраться. Поэтому своим клиентам я не показываю и не предлагаю чего-то более сложного и абстрактного, чем интерактивный прототип. А сбор данных по проекту устроен таким образом, что клиент считает, что просто болтает со мной, а не помогает описывать чьи-то портреты или фиксировать процессы.
Даже функциональные требования я уже сколько лет подряд стараюсь упрощать и упрощать — а всё равно сложный документ, всё равно не читают его до конца, подписывают, а затем создают новые функциональные требования на лету. И это нормально, так и должно быть.
В случае с моим примером у вас получилось дополнительных 4-6 дней работы. Клиент получит какие-то дополнительные артефакты в результате этих работ?
Можете уточнить, что именно вы вкладываете в понятия «исследование» и «тесты с пользователями»?
Возьмём, к примеру, проектирование сервиса, который автоматизирует процесс оформления договора на размещение и маркировку рекламы (пользователь заполняет форму с реквизитами сторон и некоторыми дополнительными данными — и на выходе получает pdf для подписи). Клиент — стартапер, который технически хочет автоматизировать собственный устоявшийся бизнес-процесс.
В моём случае клиент получит интерактивный прототип, который «пощёлкает» сам и, возможно, покажет паре знакомых с вопросом «как тебе?».
Как будет выглядеть этап исследования и тестов у вас и сколько займёт по времени и ресурсами?
Здравствуйте. Ваш вопрос лучше адресовать разработчику, а не проектировщику. Но могу пофантазировать.
1. Что именно нужно изучать — будет зависеть от того, что конкретно вы собираетесь разрабатывать;
2. Выбор языка также будет зависеть от программного комплекса, который вы собираетесь разрабатывать;
3. Время на изучение будет зависеть от вашей персональной способности к обучению, а также от того, будет у вас преподаватель (и какой именно) или нет.
То есть я бы сказал, что на ваши вопросы невозможно ответить, пока они настолько абстрактны.
Ню-ню!
Можете поделиться опытом по Kwork'у?
1. Как давно у вас там существует аккаунт?
2. Вы получили 7 заказов за семь дней или семь заявок?
3. В каких числах это произошло?
4. Как вас там найти? (Очень интересно взглянуть на пример оформленного профиля)
5. За какой срок вы сумели выполнить эти семь заказов?
6. Получили ли вы новые заказы, пока выполняли те семь?
Конечно, бывают. В этом плане мне нравится пример с наглыми водителями на дорогах. Кто-то подрезает тебя или перекрывает целый ряд на светофоре в пробку. И такие товарищи очень хорошо врезаются в память и создают ощущение низкого уровня культуры вождения в целом. А на деле-то их единицы. Во время поездки вокруг мельтешат сотни, а то и тысячи порядочных водителей, а запоминаются непорядочные единицы. Так и здесь. В целом всё не так и плохо.
Заказчик не должен выносить решений. Он должен согласовать решения, которые я ему предлагаю. Или дать обратную связь, которая может на эти решения повлиять.
Кстати, прекрасно понимаю. К сожалению, я упустил этот момент в заметке. А звучит он так: зачастую, увидев, что базовое решение не верно, я сразу начинаю переделывать проект с нуля (что-то вроде мягкого перезапуска). Поэтому я вдвойне заинтересован в том, чтобы не углубляться в детализацию там, где не надо. А поначалу старался спасать неверные решения огромным количеством костылей, что приводило к ещё более плачевным результатам.
Сочувствовать не стоит. Я действительно получаю удовлетворение от результата работы, когда вижу довольного клиента. В конце концов основная задача моего этапа работы — формализовать потребности клиента и перевести их на язык разработчиков. Если я эти самые потребности как-то не так интерпретирую, то кому тогда нужен результат моего труда? Но без конкретных примеров что моё, что ваше высказывания крайне субъективны и абстрактны.
Поделитесь мнением, пожалуйста. Как думаете, почему вот эта моя «графоманская» статья набрала плюсов и оказалась в основной ленте Хабра, а вот эта — нет? А эта?
Также есть вопрос по теме хаба. Какая глубокая техническая статья, не основанная на личных рассуждениях, может оказаться в хабе «Фриланс»? Можете привести пример?
Я говорю только за себя. «Рос вместе с рынком» — становился более продвинутым специалистом по мере развития технологий и методологий на рынке проектирования интерфейсов. Когда я начинал, не было прототипирования, верстали на таблицах, был хтмл ранних версий, для дизайна использовался фотошоп. Сегодня ситуация сильно изменилась. И мне, подрастая вместе с рынком, гораздо проще было осваивать новые технологии, т.к. это был последовательный процесс.
В статье термин «лучший в своём деле» означает «лучший в рамках своего окружения». Я надеялся, что это будет понятно из контекста. Я, например, был какое-то время лучшим специалистом по работе в Axure. Если бы вы захотели изучить туториалы на русском языке на эту тему, то обязательно попали бы либо ко мне в группу в ВК, либо на один из моих видеороликов на ютубе.
Пример: я больше десяти лет рассказывал окружающим, что, работая на фрилансе, просто необходимо вести базу клиентов. При этом сам начал её вести в 2022 году. Я знал, как надо, знал, почему это важно и полезно, но не делал. При этом очевидно, что это не делало плохо моим клиентам. За последний год я больше сил вкладываю в распространение своего дизайнерского опыта — и это привело к тому, что базу пришлось завести, чтобы слова не расходились с делами. Так что одно дело знать, как надо, а другое — делать.
Вовсе нет. Это очень распространённое явление: начинающие стартаперы, особенно из технарей, упарываются в разработку вместо того, чтобы начинать с продаж. Вот и я совершил ту же ошибку, хотя вокруг полно информации о том, что «сначала продай — потом сделай».
А сейчас мне под сорок. Почему вы спрашиваете?
К сожалению, не могу ответить на ваш вопрос, потому что не думаю, что излишняя обходительность — это приятно. Вообще любое излишество — это не очень рационально, что буквально заложено в само значение этого слова.
Красивый пример. Единственно, статью зачастую можно написать за один присест. А перекурить, почесать подбородок, а затем в течение месяца проектировать информационную систему, попутно получая обратную связь от других участников процесса, — это немного другое.
Ну или вот пример статьи, которую я не смог бы написать за один присест: https://habr.com/ru/articles/753156/
В общем, везде свои нюансы и исключения.
«Разумеется» — потому что это нормальная человеческая реакция. Если меня резко осадить в присутствии других людей — я ощущаю ту самую неприятную эмоцию, которая многим знакома. Александр был очевидно недоволен и это явно указано в тексте.
Вы знаете, возможно, вы правы и я действительно в 2014 году «не видел» других. Статья как раз об этом — об изменениях в лучшую сторону с течением времени. Но вот только «разумеется» никак с этим не связано. Акцент на собственных действиях (и персоне) плюс ответственность за них и эмоции, которые я испытываю при конфронтации, — это вещи из совершенно разных категорий.
Возможно, без яканья читать будет приятнее, не знаю. Сравнительное тестирование уже не проведёшь, а так статья явно зашла читателям и я не жалею, что опубликовал её.