Рубрика: Технологии

Опубликовано

HR + AI

А что, если я скажу, что headhunter в обозримом будущем помрёт и его место займут Озон и Ягодки, и масса народа находить работу будет через них? И маркетплейсы будут это делать намного лучше. Это уже почти можно "потрогать".

Человеки сейчас весомую долю покупок делают через маркетплейсы, и последние о конкретном человеке знают очень много. В определённом смысле даже больше, чем сам человек: имея историю покупок, просмотров, состава корзины можно сделать много выводов по пользователю. Кто какие книги покупает, кто какую одежду, даже цвет трусов многое расскажет о человеке. А bigdata+AI сделают это получше чем большинство психологов, найдут такие завимости, которые сейчас психологам даже не снятся.

А далее на маркетплейсе появляется раздел для работодателей, где они по определённым параметрам подбирают себе нужных сотрудников. Как в магазине! А со стороны подневольных — они и соврать не смогут, в отличие от cv и резюме, их этот ИИ раскусит получше детектора лжи.

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

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

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

Опубликовано

blog vs telegram vs соцсети

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

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

Старый добрый web погибает. Раньше реклама была "сайт три дабл-Ю что-то там", сейчас это скорее tg-канал или приложение. Соцсети туда же.

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

Старые добрые технологии индексирования и поиски (на чем взлетел гугл) и свободный доступ к информации уже в прошлом.

Может лучше старый добрый web?

Опубликовано

К природе технологических революций

Интересное исследование от Маккинзи о производительности экономики и как эта производительность распределяется и растёт. Несколько неочевидных моментов:

  • Рост производительности отдельных компаний приводит к росту экономики
  • Небольшое количество компаний вносит основной вклад в рост производительности. В США 5% компаний это 80% прироста производительности.
  • Производительность растёт в результате новых путей создавать/масштабировать ценность

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

Полное исследование в pdf, нашим "импортозаместителям" на заметку.

the-power-of-one-how-standout-firms-grow-national-productivity_vfinalDownload

Опубликовано

Halloween docs

Осенью далёкого теперь 1998 года из в сеть утекли так называемые Хеллоуинские документы. Это внутренняя аналитика Microsoft по вопросам конкуренции её продуктов с Linux и в целом с открытым программным обеспечением. Это крайне интересное чтиво, как в первоисточнике, так и с комментариями Эрика Раймонда. Кто интересуется внедрением ИТ-систем, интеграцией и даже разработкой ПО полезно хотя бы ознакомиться с этой историей. И точное необходимо кто развивает ИТ-бизнес или метит в фаундеры, а также любому бизнесу, завязанному ключевым образом на ИТ.

А история следующая. В 90-е годы Майкрософт вполне себе хорошо жил на рынке серверных операционных систем. Даже больше: MS вместе с Интелом (=wintel) были такими же столпами индустрии в корпоративном ИТ, как сейчас Nvidia с OpenAI в искусственном интеллекте. Unix в разных вариантах использовался, но имел огромные сложности как коммерческий продукт, а Linux был вообще уделом маргиналов и прочих гиков. Основной софт писался под Windows и основное внимание "денег" было направленно в wintel.

В хеллоуинских документах Linux и OSS уже признается как серьезная угроза бизнесу MS. Открытые протоколы, эффективная архитектура ОС, работа с сетью, расширяемость, масштабируемость и многое другое в линуксах было сделано изначально лучше. Например, такая выдержка:

Linux Operating System

The Next Java VM?

The Linux OS is the highest visibility product of the Open Source Software (OSS) process. Linux represents a best-of-breed UNIX, that is trusted in mission critical applications, and — due to it’s open source code — has a long term credibility which exceeds many other competitive OS’s.

Linux poses a significant near-term revenue threat to Windows NT Server in the commodity file, print and network services businesses. Linux’s emphasis on serving the hacker and UNIX community alleviates the near-medium term potential for damage to the Windows client desktop.

In the worst case, Linux provides a mechanism for server OEMs to provide integrated, task-specific products and completely bypassing Microsoft revenues in this space.

Через 15 лет Java-программисты действительно "захватят" мир. И Linux действительно станет платформой для многих программных решений. Кроме жавы, станут очень популярными разные питоны, руби и прочие, которые, конечно же, в серверном варианте тоже работают на линуксах. Многое из хеллоуинских доков реализовалось и произошло это по фундаментальным причинам и архитектурным преимуществам линуксов. Майкрософт практически потерял рынок серверных ОС и во многом интернета.

Архитектура критически повлияла и на развитие смартфонов, о чём в доках ни слова, тогда об этом "не мечтали". Apple свои айфоны делала под iOS, который потомок BSD. Google выбрал в качестве платформы Linux и получился Android. Обе компании сделали свои экосистемы на этих решениях. Майкрософт пыталась сделать свою ОС под смартфоны и она не получила развития, даже покупка Нокии не помогла.

С позиции более чем 25-летней давности произошедшее уже далёкая история. Но так и произошло! Главный вывод: Архитектура на долгосроке определяет развитие.

Опубликовано

Выбор технологий под проект

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

Аналогичная закономерность справедлива и для используемымых технологий. Любая технология требует времени и затрат на её внедрение, а также минимальный размер инфраструктуры, на котором технология полезна. Затраты на внедрения хорошо масштабируемой технологии (а именно таким и надо отдавать предпочтение) обычно сильно убывают с размером инфраструктуры, но в самом начале они значительны. Отсюда выводы:

  1. Для небольшой инфраструктуры лучше избегать ресурсоёмких технологий, какими бы хорошими, модными и полезными они ни были
  2. Когда использовать технологию становится целесообразно обычно лучше её внедрять на новой отдельной инфраструктуре, а не вносить изменения в рабочую старую.

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

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

Опубликовано

Разработка ПО полвека назад

Так Фредерик Брукс описывает разработку и тестирование софта примерно полвека назад:

Мы централизовали все наши машины и библиотеку магнитных лент и создали для обслуживания их работы профессиональную и опытную команду машинного зала. С целью максимизации скудного времени S/360 мы выполняли все отладочные прогоны пакетно на любой системе, которая была свободной и подходящей. Мы проводили четыре попытки в день (с оборотом в два с половиной часа) и запрашивали четырехчасовой оборот.

(…)

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

Люди работали круглосуточно, чтобы машины не простаивали. Еще 20-30 лет назад крупное ПО полностью компилировалось раз в сутки и код выкладывался на тестирование. Там же:

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

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

(…)

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

Сейчас по ночам обычно спят, а инструменты всего цикла разработки ПО поменялись. У почти каждого разработчика в арсенале виртуальные машины, контейнеры и прочие докеры для экспериментов и не только. Тестировать и выкладывать даже большой код можно настолько часто, насколько это позволяет местный DevOps.

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