Карго культ в IT

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

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

Грузы, естественно, не появлялись. Вместо того, чтобы остановиться, островитяне начинали молиться самолетам еще упорнее.

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

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

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

Эта концепция называется Jobs To Be Done (JTBT), становится очень популярной сейчас, и Михаил Руденко, который занимается продуктовым маркетингом уже 9 лет, в четверг, 2го августа с 16-00 до 17-30 МСК проведет вебинар с рассказом, что такое JTBT и как правильно эту технику применять.

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

Регистрация на вебинар здесь

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

1. Wait But Why - блог Тима Урбана, в котором несколько раз в год появляются лонгриды на интересные темы. Например, как выбрать подходящую карьеру, почему в крионике есть смысл, и даже как выбрать имя ребенку. Для каждой статьи Тим проводит свое собственное исследование, что позволяет ему разобрать тему по полочкам, а юморной стиль делает их не скучными для чтения. Говорят, Илон Маск фанат этого блога. Статьи на английском, но достаточно легкочитаемом, если нужен перевод на русский - большинство можно найти в гугле.

2. Что если? - блог Рэндалла Монро, автора комиксов xkcd, который отвечает на абсурдные вопросы на полном серьезе с точки зрения физики. Например, что будет, если кинуть бейсбольный мяч на 90% от скорости света, или сколько нужно времени, чтобы спуститься на шесте от Луны до Земли. Перевод на русский тут

3. LessWrong - уже писала о нем, но он так и просится в эту подборку. Это блог со статьями о рациональном мышлении., который ведет Элиезер Юдковский, специалист по ИИ. Перевод на русский тут

В общем, вместо котиков на ютубе в свободное время лучше почитать статьи оттуда.

Гибкое сознание: люди с разными жизненными установками

#ap_книги
Прочитала "Гибкое сознание" Кэрол Дуэк.
Книга - бестселлер, ее очень многие рекомендуют к прочтению, 2400 отзывов на амазоне, почти 5 звезд, а это говорит о многом.

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

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

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

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

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

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

В книге 347 страниц (301 по теме, остальное - рекомендации и благодарности), словосочетание "установка на рост" встречается в том или ином виде 327 раз, а "установка на данность" - 321, т.е это действительно одна тема на протяжении всей книги.

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

Про обязательные и необязательные параметры в ТЗ

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

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

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

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

Про общение с заказчиками и партнерами

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

Например, часто случаются такие диалоги:

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

А теперь сравните его с таким диалогом:

- Коллеги, добрый день. Подскажите, почему на этот запрос мы получаем ошибку такую-то? (пример запроса)
- Добрый день! Вы забыли передать параметр userId. Вот пример правильного запроса (пример запроса)

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

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

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

3. Не приводите отсылок к началу переписок: вместо того, чтобы написать "посмотрите документацию, которую мы вам отправили полгода назад" или "см. сообщение от 14 авг. 2000 года", отправьте эту документацию еще раз или продублируйте сообщение.

4. Пробуйте не просто отвечать "да/нет" на вопросы, а понимать, почему вас об этом спрашивают. Попробуйте отвечать на вопросы чуть шире, чем вас попросили: вместо "да, этот параметр нужен" написать "да, этот параметр нужен, потому что бывают такие случаи, что…" - очень часто в таких объяснениях можно заранее выявить нестандартные случаи.

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

Хорошая статья про карьеру продакт-менеджера от бывшего CPO в Netflix: Hacking Your Product Management Career.

В ней про hard и soft skills, про подход к построению карьеры и про его собственный путь - почитайте, особенно интересно про его графики зарплаты, удовлетворенностью работой и чувством делания чего-то важного для мира :)

Статья на английском.

К проблеме, о которой писала выше - про общение с заказчиками и партнерами:

Недавно на вопрос "По какой логике вы определяете, использовать этот параметр или вот тот?" мне просто скинули кусок php-шного кода со словами "Вот так. Остались вопросы?".
Это пример, как делать не надо никогда. Надеюсь, что очевидно, почему, но все же:

Во-первых, ваш собеседник может не уметь читать код (внезапно), особенно если вы не знаете точно, кто он по должности на стороне партнера.

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

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

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

Когда стоит эскалировать

Дни постов про soft skills на Analysis Paradisis :)

Эскалация, для тех, кто не знает (вдруг) - это вынесение решения какого-то вопроса на уровень выше, т.е., например, просьба своему руководителю вмешаться в процесс.

У людей бывают две крайности:
- Не эскалировать никогда, и тогда при возникновении серьезных проблем сотрудник тонет в попытках их решить самостоятельно, а руководитель узнает об этом на последнем этапе, когда уже ничего изменить нельзя
- Эскалировать по каждому чиху, когда "он пообещал прислать мне документ через 5 минут, а прошло уже 10". Иногда эти "чихи" настолько несущественны, что эскалация начинает восприниматься ябедничеством (а ваши руководители тоже устают участвовать в таких переписках).

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

Попробуйте сначала спросить:
- почему ваш коллега не успевает?
- как вы можете ему помочь?

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

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

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

Помните: в 99,9% случаев у ваших коллег есть адекватные причины не успеть или не сделать что-то: не успеть выкатить задачу к релизу, не успеть отправить документ. И работа в команде - это не про "наябедничать на соседа и испортить отношения", а про "помочь соседу, если ему нужна помощь".

Ребят, сегодня хочу рассказать вам про две вакансии: мы в Тинькофф ищем продуктового и системного аналитиков, заниматься мобильными приложениями:

Продуктовый мобильный аналитик (Senior)

От вас:  
- Хорошее знание Amplitude, SQL и Python.

Что делать:
— Поддерживать спецификацию аналитики.
— Отвечать на вопросы продукт менеджеров и дизайнеров. Иногда придется залезть в Data Warehouse или Splunk.
— Обучать всех пользоваться Amplitude.
— Планировать и проверять a/b тесты.

Суммарный MAU 5 миллионов, сложный и интересный основной продукт с кучей разных сегментов пользователей, несколько других проектов с разными метриками и целями.
Найти хотим в Москве, но можно и Питер.

Системный аналитик в команду мобильного банка (Middle/Senior)

От вас:  
- знать Postman, SoapUI или их аналоги
- уметь работать с логами
- уметь рисовать UML Sequence
- иметь опыт работы в командах по разработке мобильных приложений (желательно, но не обязательно)
Не пишу про "знать принципы разработки ПО, умение писать требования понятно и однозначно" - это по умолчанию.

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

С нас разные плюшки: бесплатная столовая, свой спортзал, хакатоны и разные турниры внутри компании, и еще много всего.
В Москве находимся на м.Водный стадион, 3 минуты от метро.

Вопросы и резюме можно в личку - @shenzzzi, я передам HR :)

Говорят, что деньги надо тратить на путешествия и образование. Поэтому на прошлой неделе купила билеты в отпуск и курс GoPractice :)

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

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

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

Если делать только то, что знаешь - ничему не научишься

Если говорить про книгу "Гибкое сознание", то мне, наверно, больше всего запомнилась часть про школьников. Когда учитель спрашивает "кто знает …?", обычно поднимают руки отличники, которые на 100% уверены в ответе на вопрос. Они отвечают правильно, учитель доволен, но никто из них не узнал ничего нового.  В книге приводился разговор с девочкой-школьницей, которая сказала "я тяну руку всегда, даже когда совсем не уверена в ответе или не знаю, как решать пример - если я ошиблась, меня поправят и научат. Для этого и нужна школа".

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

Теория успешных инноваций, Клейтон Кристенсен

#ap_книги

Я хотела написать следующую заметку про книги тогда, когда дочитаю эту книгу. Но я не смогла, хоть мне ее и посоветовал коллега, которого я очень уважаю :) Книга о том, что прорывы в продуктах не случайны, а имеют закономерность: во всех этих случаях создатели думают, 
для чего покупатели "нанимают" продукт. Иными словами, это книга о Jobs To Be Done.

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

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

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

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

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

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

Хакатон как ускоренный курс по менеджменту

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

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

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

— Расстановка приоритетов. У нас было задумано 5 функций в программе и было понимание, как делать каждую, но не было приоритетов, т.к. мы думали, что мы успеем все. В итоге у нас были готовы все функции на 80%, но ни одной по факту пользоваться было нельзя. Если бы мы изначально подумали о том, какой минимальный набор задач надо сделать, мы бы смогли презентовать продукт с минимальным набором функций, но работающий.

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

— Понимание, что это всего лишь прототип. Большую часть времени ребята потратили на выстраивание правильной и красивой архитектуры (кое-кто под утро даже рефакторил код соседа, потому что он ему не понравился). На самом деле, чтобы сделать MVP (minimum viable product) и доказать, что идея работает и нравится пользователям, не нужно пытаться построить идеальную архитектуру, надо просто быстро сделать прототип.

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

Поэтому, если можете в них участвовать, то обязательно участвуйте. Узнаете про себя много нового.

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

Сила момента, Чип Хиз и Дэн Хиз
#ap_книги

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

Знания о том, как создавать такие моменты, могут пригодиться в работе с клиентами: например, отель Magic Castle получает оценки "великолепно" из-за особенного момента: рядом с бассейном, в котором плавают посетители, находится ярко-красный телефон. Позвонив по нему, можно получить доставку фруктового льда прямо в бассейн.

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

Закончила GoPractice, теперь умею и продуктовую аналитику — не на высшем уровне, но уже и не на совсем базовом. Курс отличный, теперь осталось его еще раз перечитать и уложить в голове. Расскажу про него на неделе :)

Корреляция или причинно-следственная связь?

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

Есть такие понятия, как корреляция и причинно-следственная связь. Корреляция -  это статистическая взаимосвязь двух значений, а причинно-следственная связь - это доказанная зависимость этих значений друг от друга.

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

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

Вот вам пример корреляции, кстати)

Вчера была на EpicGrowth - почти все доклады были интересные, но больше всего понравились от SkyEng, Aviasales и Партии еды. Михаил Карпов из SkyEng рассказывал, как они растят продактов в компании, а ребята из Aviasales и Партии еды рассказывали про примеры экспериментов в их компаниях и как это все влияло на конверсию.

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

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

А еще встретились и отлично пообщались с авторами каналов @normalno_delaj и @productclub :)

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