Когда разработчики 1С слышат о вайбкодинге, у многих возникает скептицизм. И не без оснований если просто скидывать задачу в Cursor и ждать чуда, результат действительно будет плачевным. ИИ генерирует что-то среднее, нарушает архитектуру, ломает существующий код.
Но это не проблема ИИ. Это проблема подхода.
Один ML-проект в проде вам или два другому? Внедрение машинного обучения в производственную среду остаётся одной из главных проблем индустрии. По статистике, 80% ML-проектов никогда не доходят до продакшена. Однако хитрые опсы и тут решили выделиться, и в результате появился MLOps — методология, которая поможет вам сократить путь от эксперимента до деплоя с месяцев до дней. В этой статье мы пройдёмся по верхам MLOps и посмотрим на фундаментальные принципы и конкретные инструменты.
Есть момент, когда компания внезапно понимает: «мы уже не стартап на коленке, у нас продукт, клиенты, релизы, ответственность — и, кажется, пора взрослеть». Вот примерно там и появляется РБПО — разработка безопасного программного обеспечения.
В выпуске CrossCheck говорят: РБПО — не «для галочки» и не «для регулятора». Это про то, чтобы выжить в реальности, где код растёт, команды меняются, а рынок всё чаще спрашивает: «а вы вообще понимаете, из чего и как собраны ваши решения?».
Взгляд CPO на дистрибуцию B2B-IT-продуктов и опыт построения SaaS-экосистемы
В статье обсуждается гипотеза о том, что часть B2B-продуктов можно быстрее и дешевле выводить на рынок, если вынести повторяющийся back-office слой (доступы, аудит, биллинг, административный UI) в общую SaaS-платформу, оставив backend и данные у вендоров.
Модель не универсальна, предполагает осознанный vendor lock-in и требует жёстких правил экосистемы. Текст — приглашение к обсуждению применимости такого подхода, а не утверждение, что он подходит всем.
За последние годы разработчики в распределённых системах почти решили инфраструктурные проблемы: масштабирование, деплой, отказоустойчивость. Ценой этого прогресса стал экспоненциальный рост сложности бизнес-логики, которая всё чаще выражается не в коде, а в порядке сервисных вызовов.
Современные команды научились разбивать монолиты на микросервисы, оркестрировать их в Kubernetes и наблюдать через распределённые трассировки. Инфраструктура стала управляемой, но сама бизнес-логика — нет. И чем больше сервисов создаётся, тем сложнее сохранять целостность данных, порядок действий и предсказуемость поведения.
Типичный сценарий: бизнес приходит с задачей "Если в корзине три товара категории "Электроника", положи в подарок чехол, но только если регион доставки не "Дальний Восток". Звучит как if-else на пять строк. Но в распределённой системе это превращается в такой себе квест: BasketService синхронно обращается к Catalog, затем к Warehouse, затем к GeoService. Где-то посередине случается таймаут, где-то - сетевой сбой, и в коде начинают появляться саги, компенсации и ретраи.
В результате бизнес-логика перестаёт быть просто кодом. Она превращается в топологию вызовов: тонкий слой условий, размазанный по HTTP-клиентам и контроллерам. И чем сложнее система, тем страшнее становится трогать эти цепочки.
Я приглашаю сегодня взглянуть на проблему под другим углом. Что если пересмотреть не инструменты, а саму парадигму управления состоянием?
Обычно обезьяны решают головоломки с удовольствием, но получив за это изюм, начинают ошибаться. Когда школьникам дают деньги за хорошие оценки, их интерес к учебе исчезает. Интересно, что и взрослые ведут себя так же. Когда программистам платят за каждую закрытую задачу, производительность команды падает примерно на 20%. Возможно, есть другой вид мотивации, когда само выполнение задачи служит вознаграждением?
Что ж, попробуем в этом разобраться.
Меня зовут Костя Дубровин. Я веду канал про книги.
В какой-то момент почти каждая продуктовая IT-команда приходит к одной и той же мысли: «Нам нужно навести порядок в процессах».
Это обычно происходит не из-за моды на менеджмент, а из-за вполне конкретных ощущений:
Привет!
Меня зовут Дмитрий Клопов. Я продакт-менеджер: отвечаю со стороны продукта за B2B-стрим в агрегаторе доставки готовой еды «Магнит Рестораны», входящего в состав бизнес-группы Магнит OMNI.
В рамках своего стрима я регулярно сталкиваюсь с необходимостью квартального планирования в условиях большого количества заказчиков — 15–20 человек — и ограниченного капаситета команды разработки. У каждого заказчика свои приоритеты, ожидания и аргументы, и при этом все они конкурируют за один и тот же ресурс команды.
Ниже я расскажу о подходе, который мы используем для квартального планирования B2B-стрима. Он позволяет сделать приоритизацию фич более наглядной и осознанной для всех участников процесса.
На дворе шел 2016 год и из каждого утюга кричали, что русские хакеры помогли Трампу избраться, а моя маленькая (очень) команда, была привлечена к безнадёжному проекту,... правда мы поняли об этом потом.
Маленькая предыстория - в тот момент большой канадский гигант SIP телефонии решил выпустить первый телефон под Андроидом, но, не просто выпустить под AOSP, а так, что бы все гугловые сервисы были доступны. Это требовало пройти полное тестирование по GTS (Google Test Suite). Проект разрабатывался израильской командой канадского вендора и командой нашей компании, которая имела давние связи с канадцами.
Приём сертификационных заявок, на прохождение GTS заканчивался в начале ноября, а летом, хитрая израильская команда, предложила нашему архитектору, поменяться задачками - баш-на-баш. Архитектор проведя поверхностный анализ, не нашёл подвоха и... согласился,... как потом оказалось - зря, стоило анализ провести получше.
Первый "подход к снаряду" был ещё летом, но, что-то пошло не так, интеграция не задалась, и... задачу отложили на потом. Когда же на дворе стоял конец сентября, о ней вспомнили,... и вот тут - всех накрыло... и не зря - нужно было интегрировать WideVine...
Тогда подключили мою "команду спасателей" - меня и моего разработчика (Вовка, ты крут).
Задача на словах звучала просто (как всегда):
Аналоги конфлюэнса, лучшие таск-трекеры, управление проектом в форс-мажоре, жизненный цикл ERP-проектов, спецификации, настройка скрамбана, как работать с зумерами и всё интересное, что писали за последние 3 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Когда я был ещё джуном, мой менеджер иногда на наших еженедельных встречах тет-а-тет делился своим возмущением. Он указывал на проект, над которым работала другая команда, и говорил: «Я не верю, что этот проект достигнет какого-то успеха. Они решают не ту задачу». Я отвечал любопытством: «Но вы же старший, почему бы просто не пойти и не поговорить с ними?» Мне казалось странным, что при наличии возможности повлиять на ситуацию человек предпочитает молчать.
И ирония не обошла меня стороной. На прошлой неделе я сам поймал себя на том, что рассказываю новичку, почему соседней команде придётся кардинально менять свой проект, так как они изначально пошли не тем путём. И он справедливо задал мне тот же вопрос, что и я задавал многие годы назад: «А почему вы просто не поделитесь с ними своим мнением?» С тех пор эта ситуация засела в моей голове, так как я осознал, что за прошедшие годы моя позиция по этому вопросу изменилась.
Представьте себе, что вы работаете над относительно простым монолитным приложением в команде из пяти человек. К сожалению, каждый из вас выгружает код в основную ветку всякий раз, когда завершает работу над порученной ему функцией (или, что еще хуже, когда захочет). Вы то и дело правите код друг друга: используете разные соглашения по именованию, переписываете и, возможно, дублируете код. Именно так может выглядеть разработка в отсутствие процесса код-ревью.
Команда работает на полную, задачи в трекере есть, но релизы выходят нерегулярно. Стейкхолдеры спрашивают «когда будет готово?» — а вы не знаете, что ответить.
Знакомо?
Меня зовут Артём Герасимов, я владелец продукта SimpleOne SDLC. В этой статье расскажу, как превратить хаос в управляемый процесс разработки — без внедрения тяжёлых фреймворков, бюрократии и микроменеджмента.
Всем привет! Меня зовут Артём Харченков, я руководитель направления Java-разработки компании Crosstech Solutions Group. В этой статье хочу поделиться практическим опытом построения команды с нуля: от ситуации, когда вся экспертиза сосредоточена в одном человеке, до управления большой командой из пятидесяти специалистов, которые параллельно развивают несколько продуктов в различных классах решений информационной безопасности.
Долгое время казалось, что 5–6 лет коммерческого опыта — это условный "безопасный уровень", после которого поиск работы перестает быть проблемой и превращается в формальность. Ты понимаешь рынок, знаешь, как проходить собеседования, и примерно представляешь, чего от тебя ждут.
За последние месяцы я столкнулся с ощущением, что эта логика больше не работает. Формально мой опыт и стек соответствуют большинству вакансий, но на практике процесс останавливается задолго до технического разговора. Эта статья — попытка разобраться, что именно изменилось и почему привычные стратегии поиска перестали давать результат.
Привет, Хаббррр! Сейчас я расскажу, как использую агенты, чтобы упростить себе backend-разработку и не тратить на рефакторинг больше, чем на написание кода.
Какие задачи идеально подходят для оптимизации с помощью ИИ, а какие не стоит отдавать агенту.
Жизненный цикл (далее - ЖЦ) производства Информационных систем (ИС) представляет собой структурированную, логическую последовательность стадий, через которые проходит целевая система от идеи до вывода из эксплуатации (утилизации).
Как уже упоминалось выше, понимание ЖЦ производства ИС является фундаментом профессиональной грамотности для любого профессионала IT-отрасли, от разработчика до топ-менеджера. Это не просто абстрактная теория, а практический инструмент, который напрямую влияет на вклада каждого специалиста в общий успех проекта, превращая хаотическую деятельность в управляемый процесс. Поскольку в последнее время значительно меняются условия ИТ-производства, смещаются акценты, размываются границы этапов и прочее, важно иметь представление об основных устоявшиеся стандартах. Поэтому перед тем как преступить к подробному рассмотрению стадий и этапов современного ИТ-производства пройдемся кратко по магистральным трендам.
Всем привет! Меня зовут Дарья Андреева, я руковожу командой бэкенда Биллинга и B2B‑платформы Яндекс 360. Наша команда, чтобы сократить TTM и освободить разработчиков от рутины, создаёт удобные внутренние инструменты. Сегодня я хочу поделиться своим опытом и порассуждать о внутренних инструментах.
Начну с контекста. Яндекс 360 — это виртуальный офис для работы и личных дел, куда входят Диск, Почта, Календарь, Телемост, Мессенджер, Документы и другие сервисы. В течение четырёх лет команда растёт больше чем в два раза каждый год. Растёт нагрузка на сервисы, и вместе с ней бэклог. Поэтому автоматизация и ускорение процессов для нас вопрос выживания: без этого мы не смогли бы двигаться с той скоростью, которая нам нужна.
Эта статья — попытка собрать наш опыт, чтобы вы избежали наших грабель и могли быстро отвечать на главный вопрос: как реализовать тот или иной внутренний инструмент. Расскажу, какой критерий считается основным при выборе подхода к разработке внутренних инструментов, какой тип админок будет самым подходящим в той или иной ситуации и чем могут помочь готовые инструменты.
Затребовали у меня намедни справку об убытках из-за блокировок. И вот я взял и посчитал. Ниже приведен расчет ежедневных потерь на одно рабочее место для типовой российской компании.
Блокировки обходятся бизнесу не менее 1 000 р/день на сотрудника, но реальные потери сильно зависят от отрасли и региона, в отдельных случаях потери могут быть на порядки больше - и 10 000 и 100 000 р/день не предел.
Месяц работы за один вечер: сравнил Claude Opus 4.5 и китайский GLM-4.7 в vibe coding на задаче локального транскрайбера для NDA-встреч. Где критические баги, а где архитектурный идеал — и почему дорогой инструмент в 7 раз не всегда оправдан.
