Менеджмент

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

Как Airbnb удалось пройти путь от нуля бронирований до почти 500 миллионов в год, и как функционирует компания?

Первые хосты

История начинается в Сан-Франциско осенью 2007 года. Брайан Чески и Джо Геббиа, оба выпускники Школы дизайна Род-Айленда, снимали вместе квартиру в районе Саут-оф-Маркет. Сан-Франциско знаменит многим, но точно не доступным жильём и изобилием свободных квартир. Для Чески и Геббии, как и для многих других жителей города, аренда квартиры была постоянным источником стресса. Даже в обычные месяцы с ней было трудно, а тут хозяин квартиры сообщил, что арендная плата вырастет на 20%. У них просто не было таких денег. Зато у них были креативность, пустая гостиная и пара надувных матрасов.

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

Троица на скорую руку собрала сайт и назвала его «AirBed and Breakfast» («Надувная кровать и завтрак»). За небольшую плату (дешевле гостиничного номера, но достаточно, чтобы покрыть аренду), участники конференции могли переночевать у них на надувных матрасах, а утром получить простой завтрак. Они отправили письма различным блогам о дизайне, чтобы вызвать интерес, и в итоге к ним приехали женщина из Бостона, отец из Юты и студент из Университета штата Аризона. Несмотря на некоторую неловкость поначалу, опыт оказался тёплым и человечным — таким, каким отели бывают крайне редко. Разговоры, совместные трапезы и взаимодействие с совершенно незнакомыми людьми убедили Чески и Геббиа, что перед ними, возможно, нечто большее, чем просто способ разово решить проблему с арендой.

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

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

Увлекательные истории происходят сегодня на IT ландшафте повседневности и быта бизнеса. Рябь сменилась крупными волнами, и открылось окно возможностей даже для небольших компаний, чтобы оседлать волну, догнать или даже перегнать лидеров рынка – конкурентов в своём отраслевом водоёме, не без помощи AI, конечно. Давайте порассуждаем, отметим тенденции текущего этапа развития индустрии с AI, не вдаваясь в разбор мелких деталей. Хотите узнать чем занимаются ваши конкуренты прямо сейчас, в это время, что внедряют и какие для этого сценарии используют?

Если вы всерьёз рассчитываете построить «стабильную кривую спроса» на рынке недвижимости, то вы взялись за задачу, которая по сложности сравнима с предсказанием погоды на год вперед. Спрос в недвижимости — штука капризная, как погода в Питере. Вот жара и +28, прогноз на неделю - ни облачка... и вдруг гроза, ливень и +12.

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

При этом надо учитывать, что есть еще Макао и Гонконг. Они функционируют немного по иным (также регламентируемым в дополнительных самостоятельных законах) правилам.

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

Учёные из Университета Утрехта совместно с Complexity Science Hub решили глубоко разобраться в распространении генеративного ИИ в программировании. Они изучили более 80 миллионов изменений кода на платформе GitHub, сделанных в период с 2018 по 2024 год. Исследователи разработали специальный нейросетевой классификатор, способный отличить код, написанный человеком, от кода, созданного с помощью генеративных алгоритмов.

Выяснилось, что лидерами в этой «гонке автоматизации» стали программисты из Соединённых Штатов. Уже к концу 2024 года более 30% всех Python-функций, написанных разработчиками в США, были результатом работы искусственного интеллекта. Европейские страны, такие как Германия и Франция, также активно следуют этому тренду, достигая показателей в 24,3% и 23,2% соответственно.

Любопытно, что среди стран Азии картина выглядит иначе: если в Индии использование ИИ достигло уровня 21,6%, то в России и Китае показатели значительно ниже — 15,4% и 11,7% соответственно. Эксперты связывают это с различиями в экономических и технологических условиях, а также с возможными регуляторными ограничениями.

Интересным аспектом исследования стало выявление групп, наиболее охотно передающих рутину программирования алгоритмам. Оказалось, что новички, которые недавно начали карьеру на GitHub, особенно склонны использовать нейросети в своей работе — они доверяют ИИ около 41% задач. Опытные программисты более консервативны и чаще предпочитают писать код вручную, полагаясь на алгоритмы лишь в 28% случаев.

Оптический бюджет в ВОЛС: Невидимая грань между работоспособностью и отказом. Как не оступиться в эпоху 100G+ и плотных ЦОД?

Представьте: вы спроектировали идеальную магистраль, выбрали "качественные" компоненты, смонтировали... И линк не поднимается. Или работает, но с ошибками. Или стабилен сегодня, но "падает" при нагреве летом. Часто корень зла кроется в нарушении оптического бюджета мощности (Optical Power Budget - OPB). Это не абстрактная цифра из даташита – это фундаментальный закон сохранения энергии в мире оптики. Игнорируете его – гарантируете себе головную боль. Сегодня, с ростом скоростей (100G, 400G, 800G) и плотности в ЦОД, понимание и точный расчет OPB критичны как никогда. Давайте разберемся, что это, из чего складывается, где поджидают ловушки и как избежать фатальных ошибок.

1. Суть Оптического Бюджета: Проще, Чем Кажется (На Словах)

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

Упрощенная формула:
OPB = P_Tx_min - P_Rx_min - System_Margin

Где:

Год назад я вышел на очередную работу в бюджете, и как это часто бывает, начал все с нуля. Была дана куча архивных документов и папок, как физических, так и в цифре, 7 подразделений и около 30 человек «штатки». Название из серии «департамент цифрового развития», где каждое слово можно смело ставить под сомнение.

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

Мы реализовали мультирегиональность на eCommerce-платформе OpenPets с помощью поддоменов, геолокации по IP, MODX и интеграции с CRM. Делимся архитектурой, кодом, решениями и подводными камнями.

Недавно наткнулся на гайд по двум работам в IT. Я сразу же подумал, а почему только 2 работы? Это же какое-то раздолбайство. Где гайд по 3–4–5 работам? Совсем не хотят работать блогеры. Поэтому я решил написать свой гайд на Хабр.

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

За последние три года, посетив более 50 заводов различных отраслей, я всё больше убеждаюсь: система управления на многих из них напоминает вождение автомобиля 1915 года. Завел с ручки, поехал со скоростью 20 км/ч, и неизвестно, доедешь ли сегодня в точку Б в двух кварталах, не говоря уже о более дальних поездках.

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

Особую «радость» вызывают ручные замеры и бумажные инфоцентры завода или цеха. Десятки, а то и сотни человеко-часов в месяц тратятся на, казалось бы, правильную работу. Но вокруг цифровизация, а мы стоим у станка с бумажкой, записывая каждый простой. Пять цехов, 5-10 ключевых станков в каждой из трех смен, 10 тысяч подобных заводов в стране… К армии курьеров маркетплейсов смело можно добавить армию замерщиков.

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

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

Потому что в большинстве случаев вы конкурируете уже не с людьми, а с кодом, даже если открываете сделки вручную. В статье делаем первый шаг к обучению алгоритмической торговле на TradingView и знакомимся с основами Pine Script через реализацию RSI. На мой взгляд, это идеальная связка для тех, кто хочет быстро войти в сферу и не тратить время на настройку инфраструктуры (или, возможно, даже никогда не программировал).

Все уже пошутили и запомнили что если в тексте — , то его писал ChatGPT. А если нет, то человек?

Эта статья - самый подробный гайд в рунете, как отличить текст, сгенерированный Gen AI от текста, написанного человеком и как самому, используя GenAI писать очеловеченный текст. Я разберу реальные приемы, маркеры, ошибки и вооружу вас важными знаниями

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

Я собрал большой список вопросов по профессии Product Manager'a и получилось очень внушительно! Там собрано всё, что только я смог вспомнить: от базовых принципов до конкретных фреймворков. Слава роду ChatGPT, который помог сгруппировать больше 120 вопросов и отсортировать от простого к сложному. Вопросы разбиты на смысловые «главы».

Решил написать ответы на все вопросы и публиковать отдельными постами в формате телеграм канала (а как еще). Для потомков, так сказать (для себя то есть), решил собрать все посты первой «главы» в одну большую статью для Хабра. Вдруг какой-то заблудшей душе будет полезно.

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

Важно: это не учебник! Это мой опыт упакованный в формат FAQ. Для новичков, для комьюнити, для себя.

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

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

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

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

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

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

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

Таким образом мы расширяем наш домен решений, добавляя в него – модель данных.

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

Это можно сделать огрублено, приблизительно, упрощенно.

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

2)   Второй шаг состоит в том, чтобы объединить все мало различающиеся объекты в одну группу, оставив вне ее все сильно различающиеся.

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

Для выражения различий между классами им присваиваются различные имена (названия, обозначения, символы, номера и т.п.).

Классифицировать можно не только объекты, но и свойства (цвета, звуки, силы, размеры и т.д.), и процессы (ходить, бегать, тянуть, есть, пить и т.д.). Таким образом, классификация сущностей исследуемой предметной области идентифицируется в виде названия некоторых классов.

Будем честны: мало кто любит учиться. И никто не любит тратить время зря. Поэтому создание бесполезного обучения приносит настолько большой убыток карме, что впору обдумывать план «чемодан — вокзал — монастырь». Меня зовут Ростислав Сперанский, я ведущий методист продуктовых курсов в Selectel. Последние восемь лет я занимаюсь разработкой образовательных решений для бизнеса и вузов. 

Недавно я задумался, за какие советы был бы благодарен, когда только начинал погружаться в разработку учебных курсов и программ. Вместе с моими коллегами по цеху, которые разрабатывают полезное для слушателей и бизнеса обучение, мы собрали список таких советов. Затем я перевернул их и переписал как вредные. Итак, представляю вашему вниманию вредные советы для разработчиков корпоративного обучения. Они помогут провести аудит своей практики, если вы делаете корпоративное обучение, сформулировать вашу точку зрения на учебный курс или программу, если вы — заказчик обучения, поднять настроение, если вы сталкивались с таким «вредным» обучением. Поехали!