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

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

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

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

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

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

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

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

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

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

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

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

• : ✅;./utils/check.sh

• : ⚡;./scripts/tag.py

• : 📚;./scripts/makedocs.sh

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

ME:
You an expert Java programmer. Your job is to create PlantUML diagramm for the provided code.

LLM:
Creating a PlantUML diagram for the provided code involves understanding the relationships between the classes, their methods, and their interactions. Below is a PlantUML diagram that represents the key classes and their relationships based on the provided code.

AI сильно изменит подход к разработке и DevOps:
Знание и умение запоминать огромное количество технических деталей отходит на второй план, по сравнению с умением формулировать мысли и задавать вопросы.

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

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

Машине все равно это camelCase или snake_case и разбита ли ваша программка на сотни файлов в десятках директорий. Машине «удобнее» если все токены будут в одном файле.

yek

git clone https://github.com/apache/iceberg.git
cd iceberg
ls arrow/src/main/java/org/apache/iceberg/arrow
ArrowAllocation.java		DictEncodedArrowConverter.java
ArrowSchemaUtil.java		vectorized
yek --json

2025-02-15T11:56:02.751663Z DEBUG Not a Git repository or unable to open: "."
/var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json
(base) anton@Antons-Mac-mini arrow % ls -lhat /var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json
-rw-r--r--@ 1 anton  staff   192K 15 фев 14:56 /var/folders/kr/bxl1m6050xnbq5glx1nbfrx40000gn/T/yek-output/yek-output-ba15253a25ac66a21beb1f5433405467913ac2354fa1fa0c47eed2cc6220cc6a.json

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile нужно искать не Jira, а в рабочем окружении, которое не должно мешать постоянному самоусовершенствованию и экспериментам.

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

Время разработчика еще никогда не было настолько дороже, чем железо. Просто добавьте CPU и RAM.
Amazon, Oracle, Google на полную катушку, используют свою же инфраструктуру для разработки. Это не «догфудинг» – скорее они пьют свое же собственное шампанское.

Быстрая итерация становится средой, в которой рождается (а не насаждается сверху) Agile.

Как внедрить 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. Рекомендую: Эволюционная архитектура - автоматизированное управление программным обеспечением - Нил Форд`

Не пишите ничего на Groovy.

Есть такой шутливый пост про разработку, называется no-code framework. «Лучший способ писать безопасные и надежные приложения. Ничего не пишите, и никуда не деплойте».

Нечто подобное, я мог бы написать про Groovy. Не пишите ничего на Groovy. Особенно пайплайны для Jenkins. Когда-то давно, когда в Jenkins еще не было декларативных пайплайнов, сторонние разработчики сделали плагин – Job DSL, благодаря, которому стало возможным писать джобы на Groovy. Хотя вернее будет назвать этот усечнный вариант языка – Jenkins Groovy.

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

Заканчивается это осознанием, того, что так больше жить нельзя, и нужно мигрировать на какой-то другой ci фреймворк. Jenkins здесь не причем – это отличный инструмент, который позволяет гибко настраивать CI под любые задачи, и масштабируется, в умелых руках до тысяч пайплайнов и дестков тысяч билдов.

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

Разработчики на Groovy встречаются крайне редко, а DevOps инженеры и тестировщики не смогут написать хороший, понятный, тестируемый код. Даже если они научатся, потом эти навыки негде будет применить, потому что за пределами Gradle, Jenkins и Jira, он, сейчас нигде не используется.

Если вам нужно шарить код в CI, то можно писать утилиты или автоматизацию на Python, Go, Bash и упаковывать это все в контейнеры.

Если вы хотите использовать Groovy для того, чтобы написать на нем свой кастомный workflow engine для Jenkins, то остановитесь и подумайте хорошо. Скорей всего это ошибка – все тоже самое можно реализовать с помощь скрипта на Bash или Python, который вызывается внутри декларативного pipe.

Если российские компании, которые написали миллионы строчек кода на Jenkins Groovy и на этом они сейчас теряют сотни тысяч человеко часов.

Решение этой проблемы не переезд на GitLab пайплайны – просто не пишите на Groovy. Если у вас меньше 200 разработчиков и не используется монорепозиторий, вам не нужен Bazel, просто не пишите Groovy.

Все что я написал про Groovy и Jenkins, можно применить к TeamCity и Kotlin DSL.

Все топовые фичи нового релиза 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.

Культура и практика написания MoM (minutes of meeting)

Короткий пост о том, что это такое, зачем (и для чего) и, конечно, как.

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

Что такое MoM (Minutes of meeting)? 🤨

Короткие, тезисные записи ключевых мыслей по результату встречи.

Зачем MoM?

• Юридическая значимость, если использовать email для фиксации позиций и решений (возможно, в мессенджерах тоже, но в email я уверен)

• Синхронизация представления о результатах встречи

• Напоминалка (чтобы вернуться к результатам обсуждения, если потребуется). Вроде записки самому себе в будущем, которая поможет вспомнить обсуждение и ключевые для участников договоренности

Как MoM?

• Идеально - сразу после встречи (чтобы не забылось)

• Путь написания письма (email). Вспоминаем пункт про юридическую значимость

• Коротко - 5±2 тезиса по следующим пунктам. Количество не случайно. Короткий текст воспринимается легче, проще выделить главное и требует меньше времени на создание

  • Кто был на встрече (участники)

  • Что обсуждали (ключевая тема, ответвления) 1±2

  • Что решили (ведь зачем-то собирались?)1±2

  • Задачи, которые появились на встрече. Кто исполнитель и, конечно, дедлайны по ним. Тут ограничений нет.

  • Следующая встреча - требуется ли, дата и время

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

Что еще можно почитать на эту тему:

• Учимся проводить совещания (2008 г)

• MoM: Как? Зачем? Почему? (2024 г)