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

Представлен сервис LearnXinYMinutes, который поможет освоить базовые команды и понять, как они используются в работе в разных языках программирования, фреймворках и программных средах, включая IDE. Внутри есть 55 ссылок (от баша и C до YAML) для изучения с русским переводом.

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

Опрос занимает 7-10 минут, в конце анкеты вас ждет бонус — бесплатный доступ к одному из курсов Яндекс Практикума (на ваш выбор).

• Если вы рекрутер, лид рекрутеров или HR менеджер, перейдите по этой ссылке. 

• Если вы нанимающий менеджер — тимлид, техлид, руководитель направления, перейдите по этой ссылке.

Зачем нужен опрос?

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

Это безопасно?

Все данные анонимны и будут проанализированы только в обобщенном виде.

А можно ли узнать результаты?

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

⚡️ITFB Group запускает KODA — платформу для объективной оценки эффективности разработки

Мы представили KODA — собственную платформу, которая показывает, как на самом деле работает команда разработки. Не по ощущениям и не по субъективным отчётам, а на основе данных из всех инструментов инженеров: репозиториев, таск-трекеров, CI/CD, баз знаний и систем тестирования.

🔥 За первые 3 квартала внутреннего использования мы увеличили производительность команд на 30%, сократили количество переделок на 35% и ускорили code review на 40%.

💻 KODA объединяет инженерные метрики, ИИ-модули и аналитику, чтобы дать руководителям полную картину разработки — прозрачную, измеримую и безопасную. Все данные остаются внутри компании.

Наталья Романова, директор по развитию ITFB Group:
«Мы создавали KODA как инженеры для инженеров. Но в итоге получили инструмент, который одинаково важен и для бизнеса: он переводит работу разработки в язык цифр, прозрачности и управляемости».

📎 По оценкам Gartner, к 2027 году подобные системы станут стандартом для половины компаний мира. Российский рынок только начинает этот путь — и KODA становится одним из первых решений такого уровня.

Подробнее о KODA — на сайте ITFB Group.

Больше никаких мучений с Markdown — расширение Markdown Viewer превращает все файлы Markdown в Word-документы без боли и страданий. Захватывает инфографику: любые схемы, диаграммы, графики в чистые картинки. Берёт формулы из LaTeX и переносит их в Word нативно, а не в формате ужасных вставок. Переносит форматирование — подсвечивает код, сохраняет таблицы и списки, как в оригинале. Работает локально. Подходит для работы с GitHub: открывает документы и даёт перенести всё в Word.

Хотели ускорить разработку с ИИ, а получили сопротивление и хаос: как работать с командой

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

Евгений Сатуров, CTO Mobile в Surf, провел 50+ сессий парного программирования, понаблюдал, как разработчики впервые работают с ИИ, и собрал 40 страниц выводов. А потом рассказал обо всем на конференции AI Boost. Теперь выступление есть на YouTube.

Вы узнаете:

• Почему ИИ-кодинг — это отдельный навык, а не автоматическое ускорение разработки.

• Какие 5 ключевых страхов чаще всего мешают командам (стоимость, недоверие, потеря контроля, замедление, отказ от результата).

• Как ИИ подчеркивает слабые места постановки задач и почему качество промпта напрямую влияет на качество решения.

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

• Почему ИИ-агенты эффективнее на цельных задачах, чем на мелких правках.

• Как руководителю внедрять ИИ так, чтобы это не было про «разбирайтесь сами».

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

Евгений Сатуров, CTO Mobile в Surf

В видео — много практики, наблюдений и реальных кейсов, как ИИ реально помогает командам — и какие ошибки лучше не повторять. Смотрите на YouTube.

🦋 Почему «перезагрузка» — это не опция, а продуктовая необходимость

Я боюсь «ломать» то, что работает. Боюсь потерять стабильность и контроль.

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

Факт:

Когда гусеница превращается в бабочку, в коконе происходит жестокий биохимический процесс.

Всё тело гусеницы буквально растворяется в суп-пюре. Я себе это вижу не иначе, как финал "Терминатор 2: Судный день" под ту же музыку.

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

Но шутки в сторону. Происходит не улучшение гусеницы. Это не «апгрейд» и не «ребрендинг».

Это- смерть одной формы и рождение совершенно другой. Старая система уничтожается, чтобы дать жизнь новой.

Менеджерская боль:

А мы в это время:

-Цепляемся за «успешные процессы», которые уже не масштабируются.

-Дорабатываем «проверенные решения», которые давно устарели.

- Улучшаем «старый UI», вместо того чтобы создать принципиально новый продукт.

Мы пытаемся «улучшить гусеницу», боясь признать - чтобы летать, нужно сначала перестать ползать.

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

- Вывод:

Настоящий прорыв требует не улучшения, а метаморфозы.

Иногда нужно:

- Разрушить текущую структуру.

- Отказаться от «работающих», но уже ограничивающих процессов.

- Пересобрать продукт с нуля, а не наращивать техдолг.

Да, это страшно. Да, будет больно. Иногда долго. Даже очень.

И делать это должны не пришлые эксперты. А сама команда.

Но единственное, что страшнее- остаться гусеницей в мире, где все уже летают.

p.s. Было бы безобразием не упомянуть, что гусеницы живут от нескольких недель до нескольких лет. Бабочка-максимум 20 дней.
Но. Цель жизни гусеницы - превратиться в бабочку. Цель бабочки - дать жизнь новым гусеницам.

- Вопрос:

А в вашем проекте или компании уже назрела необходимость не «улучшать гусеницу», а «стать бабочкой»? В какой точке вы застряли?

https://t.me/howtcp

#крылья_ноги_и_хвосты

🦋 Почему «перезагрузка» — это не опция, а продуктовая необходимость

Я боюсь «ломать» то, что работает. Боюсь потерять стабильность и контроль.

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

Факт:

Когда гусеница превращается в бабочку, в коконе происходит жестокий биохимический процесс.

Всё тело гусеницы буквально растворяется в суп-пюре. Я себе это вижу не иначе, как финал "Терминатор 2: Судный день" под ту же музыку.

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

Но шутки в сторону. Происходит не улучшение гусеницы. Это не «апгрейд» и не «ребрендинг».

Это- смерть одной формы и рождение совершенно другой. Старая система уничтожается, чтобы дать жизнь новой.

Менеджерская боль:

А мы в это время:

-Цепляемся за «успешные процессы», которые уже не масштабируются.

-Дорабатываем «проверенные решения», которые давно устарели.

- Улучшаем «старый UI», вместо того чтобы создать принципиально новый продукт.

Мы пытаемся «улучшить гусеницу», боясь признать - чтобы летать, нужно сначала перестать ползать.

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

- Вывод:

Настоящий прорыв требует не улучшения, а метаморфозы.

Иногда нужно:

- Разрушить текущую структуру.

- Отказаться от «работающих», но уже ограничивающих процессов.

- Пересобрать продукт с нуля, а не наращивать техдолг.

Да, это страшно. Да, будет больно. Иногда долго. Даже очень.

И делать это должны не пришлые эксперты. А сама команда.

Но единственное, что страшнее- остаться гусеницей в мире, где все уже летают.

p.s. Было бы безобразием не упомянуть, что гусеницы живут от нескольких недель до нескольких лет. Бабочка-максимум 20 дней.
Но. Цель жизни гусеницы - превратиться в бабочку. Цель бабочки - дать жизнь новым гусеницам.

- Вопрос:

А в вашем проекте или компании уже назрела необходимость не «улучшать гусеницу», а «стать бабочкой»? В какой точке вы застряли?

https://t.me/howtcp

#крылья_ноги_и_хвосты

Ссылки и всплывающие подсказки в PlantUML

Всем привет!
Продолжаем тему PlantUML. Сегодня за 5 минут и без воды поговорим о Сылках и всплывающих подсказках в PLantUML

1️⃣ Для добавления ссылки и текста ссылки, используйте конструкцию: [[<URL-ссылки> <Текст ссылки>]]
Пример: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

2️⃣Для добавления: всплывающей подсказки к тексту (с ссылкой), используйте конструкцию: [[<URL-ссылки>{<всплывающая подсказка>} <Текст ссылки>]]
Пример: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

3️⃣Для добавления: всплывающей подсказки к тексту (без ссылки), используйте конструкцию: [[{<всплывающая подсказка>} <текст к которому относится всплывающая подсказка>]]
Пример: [[{всплывающая подсказка} Всплывающая подсказка (без ссылки)]]

🔥 Внимание!!! Чтобы всплывающие подсказки работали у заказчика, выгружайте диаграммы в формат SVG

Пример кода ниже (а ссылка тут), а файл с примером в формате SVG тут:

@startuml
Title **Ссылки и всплывающие подсказки в PlantUML**

' Для добавления: ссылки и текста ссылки, используйте конструкцию: `[[<URL-ссылки> <Текст ссылки>]]`
    Alice -> Bob: [[http://plantuml.com Ссылка (без всплывающей подсказки) на plantUML]]

'Для добавления: всплывающей подсказки к тексту (с ссылкой), используйте конструкцию: `[[<URL-ссылки>{<всплывающая подсказка>} <Текст ссылки>]]`
  Alice -> Bob: [[http://plantuml.com{всплывающая подсказка (с ссылкой)} Ссылка (со всплывающей подсказкой) на plantUML]]

' Для добавления: всплывающей подсказки к тексту (без ссылки), используйте конструкцию: `[[{<всплывающая подсказка>} <текст к которому относится всплывающая подсказка>]]``
  Alice -> Bob:  [[{всплывающая подсказка} Всплывающая подсказка (без ссылки)]]

@enduml

Чтобы работали всплывающие подсказки на русском в плагине предпросмотра (в VS Code) добавьте в настройки (settings.json)

{
    "plantuml.diagramsRoot": "docs/diagrams",
    "plantuml.exportOutDir": "docs/diagrams/out",
    "plantuml.exportFormat": "png",
    "plantuml.exportSubFolder": false,
    "plantuml.render": "PlantUMLServer",
    "plantuml.server": "http://www.plantuml.com/plantuml",
    "plantuml.commandArgs": [
        "-charset",
        "UTF-8"
    ]
}

Code Wiki — AI документация репозиториев от Google

Google релизнули новый интересный проект. Code Wiki — википедия с документацией open source репозиториев. А в будущем обещают CLI версию для автоматической документации приватных репозиториев! Неужели документация кода будет теперь всегда актуальной?

Как работает?

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

Code Wiki:

• Помогает найти open source репозитории по нужной тематике. То есть информация о репозитории, видимо, векторизуется и сверху работает семантический поиск.

• Позволяет общаться с репозиторием и его документацией через Gemini чат (в том числе можно на русском, если читать доку на английском не хочется).

• Автоматически обновляет документацию и все схемы после каждого PR. А значит документация наконец-то всегда актуальна.

Я немного посравнивал документацию от Code Wiki и документацию в самих опенсорс репозиториях. На мой взгляд, в хорошо поддерживаемых open source репозиториях авторская документация, конечно, все равно лучше.

Но, все мы помним те самые опенсорс репы, где лежит как-будто что-то очень полезное для нашего проекта, но черт ногу сломит, пока разберешься, как оно работает. А автор удосужился написать только абзац с общим описанием, о чем репа. Вот на такой случай Code Wiki будет спасением!

Пробуем тут.

Подписывайся на телеграм канал Заместители. Там еще больше интересного про ИИ агентов.

Сколько стоит получить 1 оффер?

Хотите вы этого или нет — но мы уже сделали 330 000 автоматизированных откликов за 5 месяцев. И за это время успели подсобрать кое какие данные.

Рассказываю:

Да, часть из откликов может быть нерелевантной, часть уходит «в молоко», но сейчас уже 40–50% попадают в яблочко.

А есть ли вообще выхлоп? Давайте посчитаем.

За всё время в нашем ассистенте Софи было 434 платных пользователя.
На этих 434 человек мы насчитали 1 956 приглашений на интервью. (Это именно те, что приходят через хх.ру (приглашения в тг или на почту мы не видим - поэтому их может быть и больше)).

Представим, очень грубо, что только 50% из них — это действительно релевантные приглашения, которые конвертировались в состоявшиеся интервью.
Получаем, что в среднем — 2,25 интервью на пользователя.

Средний пользователь заплатил нам 6 500 рублей.
Значит, одно интервью обходится примерно в 2 888 рублей.
Считается, что нужно пройти 3–5 интервью с разными компаниями, чтобы получить 1 оффер.

Итого — около 11 000 рублей стоит один оффер через Софи. Это значит что у кого-то он может выйти в 4500 рублей, а у кого-то в 30000, 40000 или вообще его не быть.

📕📖📚 "Управление победоносной командой" — звучит как отличное название, поэтому я решил ознакомиться со свежей книгой по управлению командами от бывшего бейсбольного тренера, а ныне тренера по лидерству и командной динамике: Трента М. Кларка.

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

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

Стиль изложения максимально напоминает книгу "45 татуировок менеджера" Максима Батырева, которую многие называют жёсткой, что подчёркивает, что человек пришёл из спорта, где высокие ставки и высокая награда за результат, и какие-либо оправдания не принимаются.

__

В основе "Управление победоносной командой" лежат три взаимосвязанных столпа: командная работа, мотивация, стратегия.

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

Эти истории подчёркивают главный принцип: настоящие команды процветают благодаря SPARC — Духовности, Продуктивности, Ответственности, Обязанности и Обучаемости, — концепции, разработанной Кларком для формирования устойчивости.

Для бизнес-лидеров это означает создание среды, где сотрудничество побеждает изоляцию, подобно слаженной защите на поле, выполняющей двойной аут под давлением.

___

Если вам понравилась книга Батырева, либо вам импонирует "красный" менеджмент, то книгу могу вам порекомендовать к ознакомлению.

SpaceWeb открыл расширенную API-документацию для веб-мастеров и DevOps-инженеров

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

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

Что изменилось

В документации появились полноценные методы для работы с основными сервисами платформы:

• балансировщик нагрузки;

• облачные бэкапы;

• управление IP-адресами;

• мониторинг ресурсов;

• почтовые сервисы;

• DBaaS;

• DNS-управление.

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

Зачем это нужно

Расширенная API-документация помогает специалистам глубже контролировать инфраструктуру и встраивать управление ресурсами в собственные процессы. 

Теперь пользователи могут:

• отслеживать метрики потребления и интегрировать их во внутренние системы мониторинга;

• ускорять развертывание окружений;

• автоматизировать управление политиками бэкапов и масштабирование сервисов.

SpaceWeb продолжает развивать платформенное API и движется к модели Infrastructure as Code. В ближайших релизах появится поддержка Terraform и Ansible, чтобы пользователи могли включать управление облачными ресурсами в CI/CD-пайплайны, автоматизировать инфраструктуру и сокращать время вывода IT-продуктов на рынок. Ознакомиться с API-документацией можно на сайте SpaceWeb

Анимация интерфейса в приложении Discord нагружает ПК. Речь идёт о трёх точках, которые появляются, когда кто-то на сервере пишет сообщение. В режиме покоя Discord нагружает процессор на 1%, а при появлении этой анимации — на 10-15%. От этого бага страдает так много пользовательских систем, что даже появился плагин (проверка урла на VirusTotal), отключающий анимацию.

Легендарный разработчик культовых игр Джон Кармак посоветовал разработчикам на Python никогда не переназначать и не обновлять переменную вне итеративных вычислений в циклах. По его словам, наличие всех промежуточных вычислений полезно в отладчике и позволяет избежать проблем, когда при перемещении блока кода он автоматически использует версию переменной, отличную от изначальной. А вот в C/C++ хорошей практикой является инициализация практически всех переменных как const. Кармаку хотелось бы, чтобы это было сделано по умолчанию, а mutable было ключевым словом.

Ранее на Хабре был пост: "17 открытых репозитариев, чтобы выучить Python с нуля".

ИИ в продакшн: где заканчивается хайп и начинается реальная польза

Полгода назад Дарио Амодей из Anthropic заявил: к сентябрю 2025 года 90% кода будут писать нейросети — не помощники, а полноценная замена разработчиков.
Наступил ноябрь. Пророчество не сбылось — но IT-индустрия изменилась радикально. Теперь в компаниях раскол — кто-то жалуется, что нейросети только перегружают всех, а кто-то обучает ИИ на замену рутине.

На конференции AI Boost эксперты от Сбера, Магнита, Атол и Surf обсудили, что изменилось за последние полгода и как ИИ-агенты на самом деле работают в продакшене разработки. Получилась честная и горячая дискуссия, как команды бигтеха и ИТ-компаний переходят на ИИ и что стало с ролью разработчика. Смотрите запись самого обсуждаемого круглого стола конференции, из которой узнаете:

• Почему люди всё ещё пишут 90% кода и как команды учатся использовать AI-агентов в реальной работе.

• Чем хороший джун отличается от ML-модели и что ждёт джунов в мире, где их задачи уже умеет решать AI.

• Можно ли доверить нейросетям проектирование сложных систем и где проходит граница ответственности человека.

• Стоит ли перестраивать SDLC ради ИИ или достаточно встроить новые инструменты в существующие процессы.

• Почему спагетти-код может стать нормой.

• Может ли вообще ИИ заменить разработчиков — или все это так и останется хайпом.

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

Евгений Сатуров, CTO Mobile в Surf

Спикеры:

• Дмитрий Панычев — Head of Seller Development в Magnit OMNI

• Глеб Михеев — лидер трайба «Цифровой ассистент» в Сбере, автор телеграм-канала «Уставший техдир»

• Владимир Кочегаров — Head of QA в компании Атол

• Евгений Сатуров — CTO Mobile в Surf

Смотрите полную запись круглого стола на YouTube.

Экс-инженер Nvidia Чип Хьюен (Chip Huyen, исследовательница ИИ, которая раньше работала над платформой NeMo в Nvidia и преподавала машинное обучение в Стэнфорде) считает, что неважно, что именно вы создаёте, главное — пройти путь от идеи до готового решения, которым сможет воспользоваться кто-то другой.

По словам Хьюен, строить что-то с нуля могут и должны не только инженеры. Например, даже начинающие пользователи без технического образования благодаря ИИ-ассистентам для кодинга могут создавать рабочие проекты. «После этого они становятся гораздо увереннее в себе и лучше понимают, как работает ИИ», — пояснила Хьюен.

Тем, кто не знает, с чего начать, Хюен предлагает простое упражнение: в течение недели записывать всё, что раздражает — от рутинных задач до медленных процессов. А потом выбрать одну проблему и попробовать её решить. При этом важно не ограничиваться только практикой. «Учиться только через проекты — всё равно что осваивать новый язык, просто разговаривая», — отмечает Хьюен. Чтобы разобраться в инструментах, стоит изучить теорию — выбрать учебный курс, книги или структурированную программу.

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

Снежные вершины и карьерные высоты: как все совмещать?

В гостях у «AviTalk» — Егор Гартман, технический руководитель команды в вертикали Авито Недвижимость. Его история — это 4 года интенсивного роста от мидла до руководителя, где первый же проект сразу проверил его на прочность. Но это не помешало двигаться дальше! В беседе с ведущим Виктором Раевым Егор расскажет:

• как выглядят команды внутри Авито и как различается их функционал?

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

• как проводить собеседования и качать софт-скиллы?

• и конечно, как расслабляться, покоряя снежные вершины?

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

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

Айтишников пытаются вернуть в офисы и “заставить” работать?

Недавно прочитал в одном издании, что на IT-рынке США намечается новый тренд: сразу несколько экспертов отрасли заявили о необходимости увеличивать рабочее время разработчиков и возвращать их в офисы.  Эксперты намекают на 12-часовой рабочий день и шестидневку. Пишут, что уже сейчас в Кремниевой долине ИИ-стартапы снова начинают организовывать труд по принципу “работа-проживание - сон” в офисе.  Цель всего этого - удерживать лидирующие позиции в технологической гонке с Китаем.

Как мне кажется, вокруг темы ИИ в разработке сейчас слишком много хайпа. Гонка между США и Китаем действительно есть: выиграет тот, кто создаст AGI - общий искусственный интеллект, сравнимый с человеческим. При этом, не все понимают, что сам по себе AGI, возможно - несбыточная мечта.

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

Почему разработчиков “загоняют” в офисы? Считается, что в офисе все работают продуктивнее и не отвлекаются. Но корни проблемы стоит искать не здесь. В России, например, голод на талантливых инженеров только усиливается. Волна найма “айтишников с нуля” после трехмесячных курсов закончилась, но проблема никуда не делась: с помощью современных инструментов, в том числе и ИИ, компании могут быстро создавать MVP продукта , а вот с их поддержкой и развитием начинаются проблемы.

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

На мой взгляд, рынок сейчас как раз-таки ждёт тех, кто, возможно, не самый сильный в коде, но умеет организовать систему работы разработчиков эффективно и выгодно. А уж в офисе 24 часа в сутки или дома на любимом диване - личное дело каждого.

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

Ресурс Clone Wars содержит более ста клонов самых полезных сервисов. Например, с помощью этой библиотеки можно разобраться в устройстве самых хайповых программ и попрактиковаться в коде. Есть буквально всё, в том числе и клоны сервисов, ушедших из России: Notion, Spotify, YouTube, TikTok, Discord, Dribble, Dropboх и прочее. Детальный разбор устройства каждого сервиса, кода, архитектуры и функционала, а также советы по его воссозданию. Можно стащить использовать многие решения в своих пет‑проектах.