Перевод статьи подготовлен в преддверии старта курса «Product Manager IT-проектов».

---

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

1. Уменьшите затраты, которые ваш клиент должен понести при переходе на ваш продукт.
2. Увеличьте затраты, которые ваш клиент должен покрыть при переходе к конкурентам.

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

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

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

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

Предлагаю ознакомиться с расшифровкой доклада Николая Самохвалова "Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных"

Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?

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

1. строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым",
2. глубокого понимания особенностей работы СУБД и ОС.

Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.

Недавно на Coursera произошло примечательное событие — вышла дублированная версия курса «Финансовые Рынки» (Financial Markets) о самых азах финансов.



И примечательно оно потому как раньше дублированных курсов на платформе не существовало, а первый появился именно на русском языке. Во-вторых, сделано это было на частное пожертвование. И в-третьих, курс прочитал профессор Йельского университета, нобелевский лауреат по экономике 2013 года – Роберт Шиллер.

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

Хотелось, чтобы система полива была автоматической, при этом при ее выборе приходилось учитывать следующие условия:

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

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

Машинный перевод в последние годы получил очень широкое распространение. Наверняка, большинство моих читателей хоть раз пользовались сервисами Google.Translate или Яндекс.Перевод. Также вероятно, что многие помнят, что не так уж и давно, лет 5 назад пользоваться автоматическими переводчиками было очень непросто. Непросто в том смысле, что они выдавали перевод очень низкого качества. Под катом краткая и неполная история машинного перевода, из которой будет виден в этой задаче и некоторые его причины и последствия. А для начала картинка, которая показывает важную концепцию относительно машинного перевода:

Наверное, мало кто из нас задумывался, что практически с рождения пользовался дашбордами. Мы получали некую информацию, анализировали, принимали решение или даже испытывали какие-то эмоции благодаря им. Да-да, градусник, измеряющий температуру, когда вы болели; часы; стрелка спидометра, перевалившая за 200 км/час (ну, это может быть не у всех) — все эти приборы по сути являются дашбордами или их элементом. Но мне бы хотелось рассказать об интерактивных аналитических дашбордах. И, самое главное — показать, что в наше время такие дашборды могут быть полезны каждому человеку, а не только крупным банкам или корпорациям.

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

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

Микросервисная и модульная системы — это типы архитектуры IT-решений.

При работе с модулями мы дорабатываем коробочную версию существующего IT-продукта.

Под коробочной версией имеем в виду монолит, готовую систему с ядром, которая поставляется всем заказчикам одинаково, «как есть».

Доработка состоит в создании модулей с недостающим функционалом.

Новые модули получаем путём переиспользования частей монолита (ядра или других модулей).
Бизнес-логика прописывается внутри монолита: для программы (приложения, сайта, портала) есть одна точка входа и одна точка выхода.

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

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

Компании с правильными дизайн-процессами зарабатывают существенно больше.

Я бы хотел рассказать про три базовые вещи с позиции пятилетнего исследования и своей практики в российских и международных компаниях:

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

Меня зовут Николай, я дизайн-директор в McKinsey & Company. Одна из моих рабочих задач — показывать и объяснять компаниям, что такое дизайн. Вопреки распространённому мнению, это не «картинка» или «нарисованный интерфейс». Это проектирование, которое ведёт к тому, что будет решаться основная задача бизнеса. А основная задача бизнеса — максимально удовлетворять потребности клиентов, зарабатывая при этом или накапливая какой-то другой ресурс.

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

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

Давайте расскажу чуть подробнее и с числами исследования.

У меня не складываются отношения с комнатными растениями. Дело в том, что я забываю их поливать. Зная это, я начал размышлять о том, что кто-то, наверняка, уже нашёл способ автоматизации полива. Как оказалось, способов таких существует очень много. А именно, речь идёт о решениях, основанных на Arduino или на Raspberry Pi. В этом материале я хочу рассказать о том, как создал систему, основанную на Raspberry Pi и Python, предназначенную для автоматизации полива растений.

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

Пол Грэм — один из самых уважаемых людей среди ИТишников, основателей и инвесторов. Он первоклассный программист (написал два языка программирования), хакер, создатель дерзкого акселератора Y Combinator, философ. Своими помыслами и разумом Пол Грэм врывается в широкий спектр областей: от прогнозирования развития языков программирования на сто лет вперед до человеческих качеств и способов починить/хакнуть экономику. А ещё он осознает важность того, чтобы формулировать свои мысли в текст и делиться ими с окружающими.

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

Первую подборку переводов эссе Пола Грэма меня вдохновили сделать коллеги из tceh.com (60 переводов из 176). Вторую — Edison Software (125 переводов). Третью — PhilTech-акселератор (134 перевода и еще несколько в процессе). Потом был период (2017, 2018 и 2019), когда Пол Грэм не писал эссе (а занимался с детьми), а только немного в Твиттер и дал одно видео-интервью для стартап-школы. Но в конце 2019 и начале 2020 года он вновь стал публиковать глубокие тексты об которые интересно подумать. Предлагаю вашему вниманию ссылки на новые переводы (upd с прошлой подборки) и полный список всех эссе.

Novelty and Heresy (Да здравствует ересь!)
The Lesson to Unlearn (Вредные уроки)
The Bus Ticket Theory of Genius (Теория навязчивых идей)

Five Questions about Language Design (Пять вопросов о проектировании языков программирования)
What Made Lisp Different (Что сделало Lisp особенным)
After the Ladder (На смену корпоративной лестнице)
What I’ve Learned from Hacker News (Чему я научился у Hacker News)
Snapshot: Viaweb, June 1998 (разбор полетов: Viaweb июня 1998 года)
Some Heroes (Мои кумиры)
The Equity Equation (Как делить доли в стартапе)

Привет, Хабр! Представляю вашему вниманию перевод статьи «How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh» автора Zhamak Dehghani (Жамак Дегани)(все изображения взяты из этой же статьи).

Все крупные компании сейчас пытаются строить огромные централизованные хранилища данных. Или же ещё более огромные кластерные Data Lakes (как правило, на хадупе). Но мне не известно ни одного примера успешного построения такой платформы данных. Везде это боль и страдание как для тех, кто строит платформу данных, так и для пользователей. В статье ниже автор (Жамак Дегани) предлагает совершенно новый подход к построению платформы данных. Это архитектура платформы данных четвертого поколения, которая называется Data Mesh. Оригинальная статья на английском весьма объёмна и откровенно тяжело читается. Перевод так же получился немаленьким и текст не очень прост: длинные предложения, суховатая лексика. Я не стал переформулировать мысли автора, дабы сохранить точность формулировок. Но я крайне рекомендую таки продраться через этот непростой текст и ознакомиться со статьёй. Для тех, кто занимается данными, это будет очень полезно и весьма интересно.

Евгений Черный

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

Наверняка многие из вас хотя бы однажды пользовались хабраконвертером, который официально рекомендован администрацией Хабра — https://shirixae.github.io/habraconverter-v2/. Несколько лет назад его создал хабравчанин meta4, а потом доработал Shirixae. Принцип простой: открываете гуглодок с постом, Ctrl-A, Ctrl-C и вставляете в окно конвертера. Нажимаете кнопку «Конвертировать» и получаете готовый код вёрстки, который можно вставлять в редактор Хабра и публиковать. Только перед этим нужно пройтись и поправить кое-какие мелочи.

И всё бы хорошо, если верстать приходится не слишком часто. Или посты небольшие, несложные. Но если вы верстаете помногу, и в постах есть и картинки, и таблицы, и куски кода, то из раза в раз приходится делать рутину: вставлять нужные пустые строки и убирать лишние, заменять теги <sоurce> на <cоde>, и т.д. и т.п. Мы решили потратить день, чтобы потом долетать за час, и допилили конвертер.

Новая версия лежит тут, а под катом — перечисление доработок.

– Рынок систем управления давно насыщен! Это была хорошая идея 30 лет назад.
– Ха-ха еще одна система управления проектами. Их же уже сотни?
– Команда вроде опытная, а занялись давно просроченной идеей. Вам бы что-то на Блокчейн сделать…

Примерно так говорят 9 из 10 инвесторов, когда слышат, что мы делаем еще одну «новую» систему управления проектами с упором на коммуникации. Оставшиеся 10% смотрят на рост пользователей, размер рынка и спрашивают: «А вы сами понимаете, в чем фишка и почему вы растете?»

Мы думаем, что понимаем. И также думаем, что понимаем, в чем «фишки» других продуктов, которые продаются на b2b рынке систем управления примерно на $10 млрд в год.



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

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

Мы делили апельсин, много нас, а он один

В американской традиции стартапов принято брать в долю всех участников проекта, работающих с первого дня его основания. Отличный способ мотивации команды, скажу я вам. Но как делить баснословные доходы, если они таки будут? Самое первое, приходящее на ум — поделить поровну. Таким образом, если над стартапом работало пять человек, то каждому достанется по 20%. Справедливо? Не очень.

У американцев есть отличная поговорка про курицу и свинью «a chicken is involved with breakfast, but a pig is committed»: речь о яичнице с беконом на завтрак, для приготовления которого требуется некоторое усилие от курицы (снести яйцо и жить себе спокойно дальше), в то время как свинье придётся принести куда более существенную жертву. Так же и в бизнесе: некоторые участники проекта выполняют работу достаточно формально и потом наблюдают за результатами, другие же несут принципиально большие риски и вкладываются в дело сильнее.

Frank Demmler, профессор предпринимательства в бизнес-школе при Carnegie Mellon University, предложил следующий метод распределения долей в стартапе.

Один из наиболее универсальных советов, которые мы даем в Y Combinator, это браться за сложную работу. Многие начинающие основатели верят, что стартапы или «взлетают» или нет. Вы создаете что-то, делаете это доступным, и, если вы придумали самую лучшую мышеловку, люди, как и было обещано, сами придут к вам. Или не придут, в таком случае у вас нет рынка. [1]

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

Привлечение клиентов

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

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

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