Управление разработкой *

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

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

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

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

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

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

Пишите в комментариях, с какими еще проблемами сталкивались вы как аутстаф-специалисты?

Читайте также:
Аутстаф глазами руководителя направления
Честное мнение разработчика про аутстаф
Видео для тех, кто предпочитает YouTube

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

Архитектурный надзор и анализ трейсов

В новом выпуске НЕмитапа — проекта, где наши инженеры рассказывают про инструменты и подходы — Ваня Нещадин, техлид команды Bridge, делится опытом, как в Авито обрабатывают 5 миллионов трейсов в сутки.

Из видео вы узнаете:

• зачем вообще обрабатывать такой объем трейсов;

• с чего начинали, какой была архитектура сервиса;

• graceful degradation (GD): что это, как найти и устранить GD;

• уровни критичности сценариев и сервисов.

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

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Ответ на этот вопрос очевиден — выгода.

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

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

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

Экономия времени
Аутстаф-разработчики – ребята с опытом, поэтому обучение, организация рабочего места и внедрение в процессы проходит в разы быстрее.

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

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

Читайте также:
- Честный материал о том, как Doubletapp взаимодействует с заказчиками и готовит специалистов к аутстаф-проектам
- Мнение разработчика про аутстаф
- Видео для тех, кто предпочитает YouTube

Для начала разъясним, что такое бизнес-юнит:

Это выделенное подразделение в компании с собственной структурой и стратегией. Если совсем просто – маленькая компания в большой. 

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

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

• 70% собеседований с клиентом заканчиваются успешно, это значит, что аутстаф-специалисты Doubletapp имеют постоянную коммерческую загрузку

• Работа на аутстафе удачно вписывается в концепцию роста сотрудника от стажера до мидл/мидл+ в корпорации.

• Сотрудники Doubletapp довольны опытом работы на аутстаффе и готовы идти на новые проекты. 

Если вашему проекту нужны опытные аутстаф-специалисты, то можем обсудить сотрудничество.

Читайте также:
Честный рассказ о том, как мы готовим специалистов, выводим на проекты и взаимодействуем с заказчиками
Мнение разработчика про аутстаф
Видео для тех, кто предпочитает YouTube

Эта встреча могла быть сообщением в чате: 6 проверочных вопросов

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

Перед тем как назначить встречу, задай себе эти вопросы — они помогут не только чётко определить её цель, но и сделать обсуждение продуктивным:

• Зачем нам нужна эта встреча? Зачем мы проводим эту встречу именно сейчас?

• Что должно измениться после этой встречи? Конкретизируем эти ожидания, уточняем последствия. Какой ожидаемый эффект для команды, проекта или бизнеса? Если ничего не измениться, возможно встреча не нужна;)

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

• Что случится, если встречу не проводить? Если ответ — «ничего страшного», значит, её можно заменить асинхронным обсуждением.

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

• Какие решения/информация нужны до встречи? (Если участники придут неподготовленными, встреча может затянуться и быть бесполезной. Этот вопрос помогает заранее собрать данные).

Разработчик под ником madprops предложил способ для быстрого поиска команд в терминале

«Я очень часто обращаюсь к истории действий в shell, чтобы снова и снова запускать одни и те же команды. Пока нет эффективного способа сделать это. Я думаю, что это проблема, которую нужно решать с помощью специализированного инструмента. Я могу попробовать сделать инъекцию оболочки с помощью rofi позже. Но сейчас я придумал трюк, который помогает в работе. Добавьте значки к командам, чтобы вы могли мгновенно распознавать их по стрелкам вверх:

• : ✅;./utils/check.sh

• : ⚡;./scripts/tag.py

• : 📚;./scripts/makedocs.sh

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

🌱Объясняем основы риск-менеджмента на репке

В известной русской сказке один дед посадил репку. Она выросла огромной, дед решил вытащить её, но не смог — в одиночку такой проект просто так не затащить. Тогда он собрал команду: позвал бабку, внучку, Жучку, кошку и мышку. Только благодаря командной работе дед справился с задачей.

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

🔮 Риск роста: будь готов к неожиданностям
Когда дед инициировал проект (сажал репку), он вряд ли предполагал, что она вырастет такой огромной. В реальной практике проект вида «репка-переросток» встречается не так уж и редко. Мог ли дед что-то с этим сделать? Конечно мог! 

Что можно сделать:

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

• На этапе планирования ответить на вопрос «а что нам будет нужно, если…?» и строить планы с учетом возможных рисковых событий. 

• Основываясь на риск-плане, сформировать резерв ресурсов — времени, денег и прочего. Например: «Сколько времени понадобится дополнительно, если репка будет зреть долго?», «Кто в итоге участвует в сборе урожая?» и так далее.

👥 Риск недооценки команды: отсутствие подготовки
Деду пришлось собирать команду по ходу дела. Если бы он сразу оценил возможные сложности, подготовил ресурсный план и заранее распределил роли, то, возможно, всё прошло бы быстрее.

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

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

Главное, что дед мог понести неприятные для него затраты на срочное привлечение команды. И вот тут уже всё могло быть не так просто: Жучку, может, и достаточно погладить по голове со словами «ну кто тут хорошая девочка?», а вот кошка вряд ли стала бы работать без гарантий элитного корма.

Что можно сделать:

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

• Убедитесь, что все участники понимают задачу и готовы приступить к работе.

🧩 Риск несогласованности: тянуть в разные стороны
В сказке все участники тянули за одну сторону репки, что обеспечило успех. А вот в IT-проектах часто возникает «перетягивание каната» — каждый тянет в свою сторону.

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

Что можно сделать:

• Заранее определить подход и технологии.

• Убедиться, что цели и задачи понятны всей команде.

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

⚠️ Риск упущенных возможностей: вовремя привлечь помощь
Мышку позвали в последнюю очередь, хотя ее вклад оказался решающим. А ведь иногда именно «незаметные», но важные участники команды (например, аналитик или DevOps) могут посоветовать лучшее решение.

Что можно сделать:

• Слушать мнения всех членов команды, даже если они временные участники.

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

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

P. S. Первый пост из этой серии — про инфобез и семеро козлят.

Как внедрить ML Autotasking в отделе продаж и что из этого выйдет

Рома Захаров, руководитель аналитики юнита ML Autotasking в коммерческом департаменте Авито, делится опытом, как использовать аплифт от касания менеджера для ранжирования его задач. Почему это влияет на рост эффективности работы и какие проблемы могут возникнуть при создании MVP? Из доклада вы узнаете про:

• аплифт как наиболее правильную метрику эффективности менеджера;

• автоматизацию выбора клиентов, с которыми будет взаимодействовать менеджер;

• механику сбора датасета для обучения модели — почему это было непросто;

• сравнение ранжирования клиентов моделью против бейзлайнового алгоритма;

• сложности, возникшие при внедрении модели.

А здесь ссылка для тех, кто привык смотреть на YouTube.

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Senior-разработчик: интроверт с большим опытом VS экстраверт, но опыта меньше

Кого выбрать в свою команду?

>> Рассказывает Илья, директор департамента разработки в ЮMoney.

Тут всё, конечно же, зависит от контекста. Если у меня в команде ребята-мидлы, которых нужно растить и обучать, выберу человека, который умеет разговаривать — с хорошо прокачанными софтами. Сегодня в компаниях у разработчиков нет проблем с технической экспертизой (хард-скиллами) — очень уж много доступных материалов и курсов, где можно научиться тому, что нужно. А вот с мягкими навыками у большинства разработчиков сложнее, и натренировать их так же быстро, как харды, не получится.

3 греха в софтах айтишников 😈

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

• Когнитивные искажения. Под одними и теми же словами и фразами люди могут подразумевать разные вещи. И это тоже приводит к конфликтам.

• Неспособность вовремя остановиться и не работать, когда рабочий день закончился. В ЮMoney есть процесс проверки здоровья команды — Health Check, и среди вопросов есть пункт про нагрузку команды с градацией ответов от «Всё в порядке» до «Мы горим и проектов слишком много!». Если столкнулись со вторым случаем, я встречаюсь с директором департамента проектов, вместе разбираем отчёты по командам и решаем, что можно сделать, чтобы стало легче. Иногда точечно обращаемся к тому сотруднику, которому тяжело, предлагаем помощь. Может, у него вообще проблемы не на работе, а дома: это разбираем вместе с HR BP. Бывают и случаи, когда PM (проектный менеджер) взял слишком много задач и нагрузка возросла так, что стало дискомфортно. Обсуждаем с ним проблему и снижаем нагрузку на команду.

***

Хочешь тоже работать в ЮMoney? Откликайся на наши вакансии! 😉

Сэм Альтман сообщил, что GPT-5 будет бесплатной, а следующей нейросетью OpenAI станет GPT-4.5.

Альтман признал, что сам устал от десятков моделей с разными названиями и неясными функциями — с GPT-4.5 в компании начнут возвращение к понятному неймингу. С GPT-5 номерные модели будут объединять сразу все функции и сами определять, когда им дать короткий, но быстрый ответ, а когда уйти в длительное размышление.

Также GPT-5 запланирована быть бесплатной с неограниченным доступом к чат‑боту и всем функциям, но с базовым уровнем мощности. У нейросети будет несколько ступеней: основная для обычных пользователей, продвинутая для Plus‑подписчиков и мегамощная за $200. Ждать GPT-4.5 осталось несколько недель.

Должен же тимлид смотреть Merge Request (Pull Request)? 

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

• контролировать качество кода программистов команды;

• следить за соблюдением принятых стандартов;

• управлять рисками кодовой базы команды;

• обучать участников команды через ревью их кода;

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

Однако что делать, если у вас кросс-функциональная команда, состоящая из двух бэкендеров, пары фронтендов, QA и аналитика? Нужно ли вам просматривать все их MR? Сможете ли вы адекватно оценить код на PHP, код на React + TypeScript и автотесты на Python? Очевидно, что нет. 

Для разрешения данной ситуации вы можете:

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

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

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

 Как поступить?

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

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

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

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

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

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

P.s. Рекомендую: Эволюционная архитектура - автоматизированное управление программным обеспечением - Нил Форд`

Все топовые фичи нового релиза Go

Случился релиз новой версии языка Go: 1.24. Разбираем основные нововведения и используем улучшенные инструменты по максимуму.

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

Смотреть выпуск на YouTube
Смотреть выпуск в VK

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Разработчик из польской инди-студии Immersion Games, который занимался проектом VR-игры про фитнес, похудел в процессе работы на игрой. Он сбросил 30 кг за семь месяцев, пока делал Fitness Fables.

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

Курсы и задачи:

• Курс «Learn Python 3» от Codecademy.

• Курс «Python for Everybody» от freeCodeCamp.

• Задачи Python от freeCodeCamp.

• Учебник Python от w3schools.

• Уроки от Real Python.

• Учебник Python от GeeksforGeeks.

• Курс Python от Codechef.

• Задачи Python от Exercism.

• База по Python для вката в ML.

• Введение в Python от Стэнфордского университета.

Интерактивные платформы:

• Khan Academy.

• MIT OpenCourseWare.

• LeetCode.

• HackerRank.

• CodeWars.

Видеоуроки:

• sentdex.

• CS Dojo.

• Corey Schafer.

• edX: Введение в Python.

• Programming with Mosh.

• Курс CS50 от Гарвардского университета.

• Работа с ИИ на Python от Гарвардского университета.

Книги:

• Think Python.

• Automate the Boring Stuff with Python.

• Программирование на Python от НТУИТ.

• Укус Питона.

• Официальный учебник Python.

Бонус: в Steam вышла игра Joy of Programming — Software Engineering Simulator от разработчика на Python.

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

Как эффектно ворваться в mob-программирование? Узнай из выступления нашего бэкенд-лида! 

В прошлом году Витя Михайлов, Backend lead Garage Eight, выступил на конференции TechLead 2024 с докладом про mob programming. Он рассказал про пользу этого подхода к разработке, а также трудности его внедрения. А еще поделился приемами, которые помогут вовлечь в этот процесс команду, справиться с «болячками» и сделать mob-программирование частью ежедневной работы.

Если не смог побывать на мероприятии, то самое время смотреть запись ;-)
> YouTube
> VK

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

Чем занимается директор департамента разработки в финтехе

Привет, Хабр! 🙌

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

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

Илья:

За 10 лет работы в ЮMoney у меня было четыре карьерных периода:

• Пришёл в компанию мидл-разработчиком в отдел фронтенда в 2014 году.

• За N лет вырос до сеньор-специалиста.

• Спустя N лет стал руководителем отдела разработки интерфейсов.

• Ещё через N лет — директором департамента разработки. Теперь работаю под руководством IT-директора.

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

Поначалу на управленческой должности мне было сложно разглядеть свой вклад в общие результаты. Ребята в команде что-то делают, я подсказываю и контролирую, а в итоге ощущение такое, что вроде и помогал, а вроде просто рядом стоял… Со временем это чувство ушло, и сейчас у меня есть чёткое понимание того, что я делаю: обнаружил проблему >> раскопал её >> поставил решение на рельсы >> процессы улучшились. Чтобы побороть синдром самозванца, пришлось даже поработать со специалистами: мне очень помогли наши HR BP.

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

***

Ждите следующий пост про найм лидов в разработку. А пока задавайте вопросы в комментариях. 😉

Китайский ИИ-проект DeepSeek возглавил топ по скачиванию в США.

OpenAI с проектом ChatGPT была основана 10 лет назад, имеет 4500 сотрудников и привлекла $6,6 млрд капитала. Китайская DeepSeek была основана менее 2 лет назад, имеет 200 сотрудников и была разработана менее чем за $10 млн. Но они начали конкурировать.

DeepSeek выпустила версию DeepSeek‑V3, LLM с открытым кодом, который соответствует производительности ведущих американских моделей, но требует гораздо меньше затрат на обучение. Модель имеет 685 млрд параметров, а в основе её архитектуры лежит подход Mixture of Experts (MoE) с 256 «экспертами», из которых восемь активируются для каждого токена.

В тестах производительности DeepSeek‑V3 превосходит Llama 3.1 и другие модели с открытым кодом. DeepSeek‑V3 соответствует или даже превосходит Chat GPT-4o, уступая лишь Claude 3.5 Sonnet от Anthropic.

В DeepSeek сообщили о расходах в размере $5,6 млн на обучение своей нейросети по сравнению с предполагаемыми $500 млн, потраченными на обучение Llama-3.1.

Бенчмарки подтверждают, что Deepseek недалека от решений OpenAI, но всего за 3% от стоимости разработки. Стоимость собственного API DeepSeek составляет всего $0,55/$2,19 за вход/выход — значительно дешевле.

Китайские разработчики из DeepSeek пошли проторенным путём и сделали свой ИИ-проект, внимательно изучив ошибки других. В результате стоимость продукта Deepseek оказалась на 97% ниже, чем раздутые американские проекты с большими затратами на обучение.

Бенчмарки подтверждают, что Deepseek недалека от решений OpenAI, но всего за 3% от стоимости разработки.

Стоимость собственного API DeepSeek составляет всего $0,55/$2,19 за вход/выход — значительно дешевле.

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

В декабре DeepSeek представила новую языковую модель DeepSeek‑V3, которая продемонстрировала впечатляющие результаты в работе с кодом. Модель имеет 685 млрд параметров, а в основе её архитектуры лежит подход Mixture of Experts (MoE) с 256 «экспертами», из которых восемь активируются для каждого токена.

По данным Deepseek, V3 демонстрирует производительность, сопоставимую с ведущими проприетарными моделями, такими как GPT-4o и Claude-3.5-Sonnet, во многих тестах, при этом предлагая лучшее соотношение цены и производительности на рынке.

Также DeepSeek выпустила открытую версию модели рассуждений DeepSeek‑R1, которая, по её утверждению, работает наравне с o1 от OpenAI в определённых тестах. Это уже подтвердили независимые бенчмарки.

Команда из девяти сотрудников Nokia в 2007 году выступила с внутренней презентацией, на которой объявила, что представленный первый iPhone от Apple может изменить стандарты индустрии и станет лидером рынка.

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

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