Достижения через преодоление себя против наслаждения процессом достижения целей

Достижения через преодоление себя против наслаждения процессом достижения целей

Рассмотрим две популярные точки зрения.

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

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

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

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

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

Определимся со спортивными целями. Они могут быть разными:
1. Не хочу быть толстым, поэтому буду бегать 2-3 раза в неделю.
2. Хочу красивое тело — буду ходить в зал 3-5 раз в неделю.
3. Хочу стать марафонцем.
4. Хочу пробежать марафон из 3-х часов.
5. Хочу стать КМС в каком-либо виде спорта.
6. Хочу поучаствовать в ЧМ по триатлону.

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

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

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

Чем выше планка — тем больше страданий и дисциплины. Это нужно либо принять, либо поумерить свои амбиции.

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

Однако, в условиях цифровизации мира, есть вероятность, что необходимость в таких специалистах рано или поздно пропадет.

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

В Usethics написали о том, как объединить подход персонажей и Jobs to be done

JTBD описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z).

Во подходе персонажей первое место занимает персонаж: как Х, я хочу Y, чтобы Z. «Как турист (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)». Персонажи рассказывают о пользователях продукта, а «работы» сообщают об их ключевых целях.

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

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

Объединённый подход:

1. Выделяем типы пользователей. Думаем, какие индивидуальные особенности могут повлиять на их опыт выполнения работы (базовые шкалы свойств персонажей). Например: соседство с другими в спальне. Выдвигаем гипотезы о персонажах, но не наделяем их социально-демографическими характеристиками.

2. Проводим интервью, где оцениваем участников с точки зрения выделенных свойств, узнаём контекст, делим работу на составляющие («подработы»). Например: Подготовка ко сну → Планирование подъёма утром → Засыпание → Сон → Пробуждение → Подъём. Это не обязательно должна быть последовательность.

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

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

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

6. Profit (выявляем инсайты о проектируемом продукте).

https://medium.com/usethics-doc/b35d4174cea3

PayPal: рост аудитории в 5 раз

PayPal - крупнейшая платежная система в мире. Оплаты счетов, денежные переводы и куча всего прочего.

Сегодня кейс о том, как компания увеличила аудиторию в 5 раз.

Что сделали

- переосмыслили подход к привлечению пользователей- за каждую регистрацию начали давать по $20 с порога
- тестили разные формы регистраций
- нашли ту, которая дает самую низкую стоимость привлечения CPA

В итоге, за 5 месяцев аудитория выросла 1 до 5 млн.юзеров.

Со временем начали снижать бонус за регу с $20 до $10, потом до $5 и так до нуля. Дальше сервис раскрутился и начался органический рост.

Посыл

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

Источник - https://bit.ly/2OLQ3qI

Анна Данилова написала о тире. То, что мы обычно называем просто «тире», — это длинное тире.

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

Если говорить о характеристиках шрифта, например, в Arial у тире нулевые полуапроши (расстояние от края кегельной площадки до крайней точки рисунка символа), в других — авторы сознательно закладывают большие полуапроши, чтобы не отбивать тире вовсе.

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

Исторически длинное тире делалось размером с прописную М (поэтому оно называется Em dash). Некоторые иностранные типографы считают его слишком длинным и не используют в тексте. В современных шрифтах у тире бывают разные пропорции, а некоторые шрифтовики делают несколько типов длинного тире — «устаревшее» длинное, более современное покороче и т. д.

Короткое тире (En dash) в современном русскоязычном наборе чаще всего используется для обозначения числовых диапазонов, например 1990–1998. В текстах на английском короткое тире используется в любом диапазоне, даже если он набирается словами: October–November. Короткое тире в таких ситуациях не отбивается пробелами.

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

https://type.today/ru/journal/dash

Лишние люди на совещаниях

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

Такой диалог я слышал много раз перед обсуждением проекта или дизайна с заказчиком. У многих больших компаний, а особенно у госов в ДНК заложено: позвать как можно больше людей на совещание. И вот сидит целая толпа и обсуждает то, о чём ещё 5 минут назад многие даже не знали.
Эффективность такого совещания очень сомнительна: активничает 10% участников, а остальные ждут, когда закончится и думают: лишь бы слово не дали. Если молчуну дадут слово, то в лучшем случае, он скажет, что добавить нечего. В худшем — начнет на серьёзных щах фантазировать и предлагать ерунду или суперфункции.

Хуже всего, когда лишних людей позвали обсуждать дизайн 🤦‍♂️ — случайные люди не всегда молчат. Включается синдром актёра — позвали критиковать, значит надо критиковать. А это же дизайн — в нём все "сильные критики".

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

Чтобы совещание удалось:

  • Нужна повестка — все могли заранее подготовиться и прийти с обратной связью или мнением. Надо избегать совещаний без контектста.
  • Не нужны молчуны — все, кого позвали были активны. Кто отмалчивался — не надо больше звать в эту тему.
  • Нужны зафиксированные итоги — с ними можно ознакомить остальных, да и в целом полезно зафиксировать. О навыке резюмировать итоги обсуждений есть отдельная заметка (https://t.me/proudobstvo/187).

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

С вялым заказчиком каши не сваришь

Иногда пишу зарисовки из проектной деятельности. Вот и сегодня такая зарисовка.

Более-менее крупный проект может заглохнуть, если на стороне заказчика не будет команды. 

Если вам говорят: "С вами будет работать Ира, она в курсе всех процессов, а если надо – будет привлекать ещё кого-то!", то есть повод насторожиться. У заказчика должна быть команда, в которой Ира руководитель проекта, тогда норм.

Из жизни. На заре моего проектного менеджмента (в 2008-2009 году) у меня был проект внедрения системы автоматизации в транспортно-логистической компании. 

Большой проект, большое ТЗ. И один человек на стороне заказчика, который "активно" занимается проектом.

Этот один человек всегда загружен (работу же работать надо), поэтому обратная связь по релизам/вопросам идёт с задержками.

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

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

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

Заказчика в тонусе держать надо, а то на шею сядете и соскользнёте с неё очень быстро.