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

Работать в одной команде много лет или менять их несколько раз в год

Обсудили с девчонками-тестировщицами Контура. 💅 Капа Потапова шесть лет в одной команде, Катя Заусова — из бюро тестировщиков, меняет проекты и контекст задач каждые несколько месяцев.

Постоянная смена команд вызывает чувство одиночества и отсутствия долгосрочных связей с коллегами

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

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

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

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

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

Работа в одной команде даёт больше чувства значимости в успехе продукта

Меняет команды: Конечно, потому что ты регулярно вносишь свою лепту. Но тут ещё важно, чтобы команда рассказывала о своих результатах и успехах, вакуума быть не должно, когда человек думает «У меня есть одна зона ответственности, а на другие даже не смотрю». Чтобы чувствовать свою значимость, тебе нужно хотя бы видеть продуктовые метрики фич.

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

Работа в одной команде может привести к выгоранию из-за однообразия

Не меняет команды: Любая работа может, если неправильно распределять ресурсы и не соблюдать баланс, работать по выходным и круглосуточно. Это не зависит от того, в команде ты или в бюро. К потере интереса скорее приведёт монотонность и рутина. С другой стороны, постоянный хаос тоже может быстро надоесть.

Я спасаюсь тем, что у меня много непроектных активностей, например, мероприятия и обучение.

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

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

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

Приходите послушать и посмотреть выпуск подкаста с Капой и Катей ➡️ YouTube, Rutube, VK, Яндекс Музыка.

Представлен репозиторий Free Certifications с бесплатными сертификациями по IT-технологиям от Google, Oracle Microsoft и других компаний. Все сертификаты строго разделены по категориям: фронтенд, бэкенд, SQL, Data Science, информбезопасность, аналитика и ещё множество тем.

Разработка в 2025 году — это уже не только про умение писать код. Важно уметь работать в связке с ИИ, быстро адаптироваться к новым инструментам и смотреть на задачи шире, чем строки кода. Автоматизация ускоряет процессы, языковые модели становятся полноценным помощником, а кибербезопасность требует внимания как никогда раньше.

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

Что формирует будущее разработчиков

1. ИИ и языковые модели. Инструменты вроде Cursor/Windsurf и LLM помогают быстрее и качественнее выполнять то, что вы уже умеете, или разобраться в новой теме. LLM берут на себя «черновую» работу: исправляют опечатки, улучшают оформление кода, помогают с декомпозицией задач и первичным код‑ревью. Это снижает нагрузку и освобождает время под архитектурные решения.

2. Кибербезопасность. С ростом объема данных и активным использованием ИИ‑решений увеличивается и число атак. В 2025 году безопасность уже не «дополнительная опция», а критически важный аспект разработки. В приоритете: оперативное устранение уязвимостей, поддержка зависимых библиотек в актуальном состоянии, а также проектирование безопасных систем.

Главные скиллы

— Промпт‑инжиниринг и итеративный подход. Чем лучше вы понимаете и формулируете задачу для LLM, тем лучше результат. Разбивайте сложные задачи на небольшие, пошагово уточняйте вводные, добавляйте контекст, референсы и критерии качества.
 — Умение адаптироваться к изменениям. Мир меняется быстро: нужна гибкость и готовность учиться новым инструментам и подходам.
 — Осознанное применение ИИ. ИИ ускоряет рутину, но не заменяет понимания. Код или решения без осознания внутренних механизмов сложнее поддерживать; сырые и неадаптированные ответы часто дороже, чем написать с нуля.
 — Критическое и системное мышление. Хороший разработчик видит систему целиком, задает вопросы, сравнивает варианты и думает на несколько шагов вперед: архитектура, влияние изменений, риски и стоимость владения.

Как развиваться разработчику

1. Книги, курсы и пет‑проекты. Рабочая связка: цель → план → небольшой прототип → разбор ошибок. LLM помогают собрать персональный план обучения: перечисляете, что знаете и что хотите изучить, — получаете черновой roadmap и список практик.

2. Конференции и митапы. Это возможность обменяться опытом и задать вопросы. Сильно прокачивает подготовка собственного доклада: структурируете знания, получаете обратную связь, улучшаете подходы.

3. Полезные тг‑каналы. Удобно следить за анонсами моделей, обновлениями LLM и промпт‑подходами в профильных каналах. Выберите несколько источников и регулярно сверяйте советы с документацией и собственным кодом.

...и вот у меня спрашивают «А какие у тебя мотивация работать и стимул для развития?», а я говорю «Деньги». Ты бы видел как на меня посмотрели! Как будто ждали какой-то другой ответ. Что мне надо было ответить? Не понимаю. Работать за идею?

Недавно общался со своим другом с прошлой работы и разговор зашел за повышения и performance review. И этот момент ТОТАЛЬНОГО непонимания руководителями желания сотрудника зарабатывать больше мне как-то скребется, я слышал о похожих ситуациях уже немало.

Хотелось бы здесь написать остро "НИКТО!", но буду мягче. Если мы будем честны: мало кто в найме готов работать только за идею. Я уверен, если предложить этому ревьюверу: «Ой, а давай мы твою зарплату попилим на весь отдел? Тебе же хватит идеи?», – он быстро сольется.

Идея – это роскошь. Можешь себе позволить работать за идею, если холодильник забит, ипотека закрыта, есть запас жирка и нет переживаний за деньги. Желательно, запас средств на несколько поколений безбедной жизни. Всё остальное – манипуляция. И пропагандировать нечто подобное с позиции руководителя – это, ну не знаю, бред?

И вот у друга спрашивают: «А что тебя мотивирует, кроме денег?». И в этот момент я думаю: а что мотивирует стоматолога? Чтобы у меня зуб не болел. Но если ему сказать: «Давай-ка, дружочек пирожочек, ты полечишь меня бесплатно? Твоя ж идея – это здоровье людей»? Он меня пошлет и будет прав. И хирург, и пилот самолета, и строитель – все пошлют. Но почему-то в айтишечке считается, что я должен радоваться "идее".

Работа ради идеи возможна, если эта идея твоя. Если же это чужая идея, за чужие деньги, да ещё и без нормальной компенсации – это.. бесплатный кружок по интересам? Фан-клуб с членскими взносами? Секта? Выбирайте что больше нравится.

Отличная компенсация + интересные задачи + адекватный менеджмент = получаем мотивированную команду. Идея и миссия компании – это важно и круто, но это вишенка на торте, а не замена базовым потребностям.

Пан или MVP пропал! Дебаты на ProductCamp

Уже в эту субботу, 20 сентября, МойОфис организует жаркий баттл продуктологов в формате парламентских дебатов на ProductCamp. Никакой воды и эмоций — только факты и сильные аргументы.

Тема встречи: «Fail Fast наносит больше вреда качеству продукта и духу команды, чем приносит пользы?»

Мы обсудим, может ли быстрая «обкатка» сырой версии подорвать продукт и команду, и бывают ли ситуации, когда Fail Fast действительно оправдан.

Аудитория тоже не останется в стороне — у зрителей будет возможность задать свои вопросы спикерам в одном из раундов.

Дебаты стартуют в субботу, 20 сентября, в 17:00 в большом шатре. Будет жёсткая профессиональная дискуссия без купюр и сантиментов!

Вопрос: оцени сколько времени займет выполнение задачи?

Оценка - это, по определению, предположение.

Так что какое число ни назови столько и будешь работать до следующего такого вопроса 😁

Про вайб и прочих ИИ агентов в ретроспективе "лихих 90-х"

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

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

Будучи разработчиком одной из небрендовых ERP-систем, приходилось участвовать в предпродажных сессиях. Ярким воспоминанием остались контакты с "девопсом" потенциальных клиентов. Никаких "девопсов", конечно, тогда не было: инфраструктурой или, как иногда говорят, "ландшафтом" занимались системные администраторы, инженеры и ДБА.

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

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

10 лет в AvitoTech — а минусы будут?

В этот раз в гости пришёл Александр Лукьянченко, технический руководитель кластера Architecture. Саша работает в Авито почти 10 лет: компания менялась на его глазах, а сам он прошел путь от разработчика до менеджера высшего звена. В интервью вместе с Сашей и ведущим Виктором Раевым, руководителем разработки юнита Services Base, поговорим вот о чём:

• как выглядит путь от разработчика до менеджера высшего звена длиной в 10 лет;

• какие изменения произошли в Авито с 2016 года;

• как зарождалась PaaS — платформа, которая теперь облегчает жизнь инженерам;

• что такое AvitoPlato и какие планы по развитию продукта на будущее.

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

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

Как связаны игра «Что? Где? Когда?» и работа в IT?

А вы знали, что методы легендарной интеллектуальной игры могут стать ключом к эффективной работе вашей команды? Рассказываем в нашей новой статье!

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

Если хочется идти дальше стандартных подходов и строить по-настоящему слаженную команду — статья «Что? Где? Когда?» и эмоциональный интеллект в бизнес-команде для вас!

Инженер по безопасности компании Fortinet представил экспериментальный инструмент KittyLoader. Это небольшой загрузчик, написанный на C и Ассемблере, который автор сам называет крайне ненадёжным и не предназначенным для практического применения.

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

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

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

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

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

Дейлики: благо или зло?

В новом выпуске подкаста «Свободный слот» Саша Прокшина и Паша Федотов разбирают принципы грамотного планирования. Обсуждаем:

• какими должны быть идеальные итоги встречи?

• как выглядят секреты эффективной фасилитации и perfect follow-up?

• и конечно, как выстроить день так, чтобы успеть всё?

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

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

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

«О чем на самом деле думает проджект-менеджер во время митинга: перевод с корпоративного на русский»

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

Про оценку сроков

Каждому проджекту знакомо. Митинг с заказчиком и командой, вдруг, не согласовав оценку с менеджером, разработчик говорит: «Ну, это задача дня на четыре... Если ничего не помешает».
Тут же слышится от заказчика: «Фиксируем, через 4 рабочих дня будет готово».
Вспышка, шторм, помешательство. У проджекта в голове: «Ага, “Если ничего не помешает”, так вам ничего и не помешает, конечно. Сейчас начнется: мало ресурсов на сервере, срочный баг от другого клиента, а тестирование? В этой оценке указана только время разработки! Минимум неделя нужна. А обещать буду за 7 рабочих дней».
Проджект тут же говорит вслух на корпоративном: «Предлагаю заложить на задачу 7 рабочих дней с учетом возможных рисков и интеграции в основной процесс. Нужно обстоятельно убедиться, что функционал готов к релизу».
Заказчик недоверчиво фиксирует 7 рабочих дней на задачу — фух, пронесло 😓

Про «немного поменять ТЗ»

Это из фонда золотых цитат заказчиков: «Мы тут подумали и хотим немного улучшить концепцию. Фактически, всё остается по-старому, просто логика немного меняется».
С этого начинается внутренний диалог проджекта: «„Улучшить концепцию“... Это значит пришить к штанам капюшон и выкинуть 3 недели работы. „Логика немного меняется“ — это сделаем из грузовика экскаватор, новый движок, новая база данных и отказ от всего, что уже сделано».
Проджект говорит вслух: «Понимаю ваше стремление к улучшению! Давайте проведем отдельную встречу вместе с аналитиком, где вы подробно расскажете о новой концепции. Мы проведем анализ, посчитаем новые сроки и бюджет и обсудим решение».
(редко кто меняет изначальную логику, увидев новые сроки и бюджет 😉)

Работа PM — это искусство баланса между желаемым, возможным и реализуемым. Главное — сохранять спокойствие и дальновидность.

Подписывайтесь здесь или в тг: @projectmindset_pm

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

Выгоревший сотрудник это реальная проблема, а не «загрустил, пройдет». Она имеет такие вполне конкретные последствия:

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

2. Падение качества. Это влияет на количество инцидентов и тогда риски возрастают кратно. Восстановление, репутация, штрафы. Например, утечка персональных данных будет стоить до 15 млн только штрафа. А ошибки в мед- или авиаоборудовании могут стоить кому-то жизни.

3. Текучка. Если сотрудник выгорел, то время до его заявления на вашем столе уже пошло. И его не отговорить, он уже нашел интересную замену. А найм и адаптация нового сотрудника дорого. И есть угроза цепной реакции в коллективе.

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

На ИТ-рынке, в целом, заметен тренд на заботу о состоянии сотрудников. Хотя чаще он довольно поверхностный. Стандартный набор — ДМС, оплата спорта, тим-билдинг, корпоратив, индивидуальная работа с сотрудниками, материальная мотивация. Является ли это достаточным? На мой взгляд — мало, но допустимо. Например, психологов я в малом и среднем бизнесе не встречал, только изредка в корпоративном слое. Работу над положительной нематериальной мотивацией встречал где-то в 20-30% организаций.

Нулевого выгорания не достигли нигде (это невозможно из-за особенностей человеческой природы), но значительно снизить удавалось. Помню случай с ТехноНиколь времен пандемии — им за счет работы с выгоранием сотрудников удалось повысить производительность на 50%! По их оценкам они при этом снизили уровень выгорания с 80% до 20%.

Со стороны сотрудника:

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

Со стороны бизнеса:

Работа с выгоранием — это похоже на регулярную страховку: объем бюджета, который менеджмент готов потратить на проблему, и уровень риска, на который согласен. Где брать на это деньги? В фонде оплаты труда. Если выгорание присутствует — потери производительности — 5-50%. Это размер ФОТ, который потрачен впустую. Можно взять из будущего ФОТ 5% и получить прирост производительности в 10%. А это уже рост EBITDA и чистой прибыли.

Берегите себя, и своих сотрудников, коллеги!

И расскажите как у вас с этим?

«СберТех», Cloud.ru и Хабр заколлабились и запустили грантовую программу «Код без границ». Это отличная мотивация для разработчиков и ресурсы для проектов. Можно доработать свой проект с поддержкой сообщества, найти единомышленников и показать свои возможности.

Участвовать просто:

• разместить свой проект на GitVerse (СберТех) или импортировать его с другой площадки.

• делится кодом и вдохновляться чужими разработками.

Номинации следующие: ИИ‑инновации, «Наука и образование», «Проекты для всех», «Разработка для разработчиков».

Заявки на грантовую программу «Код без границ» принимаются с 3 сентября по 31 октября. Отбор проведут в ноябре, а результаты огласят в декабре.

Delivery Manager: где его место среди Project, Product и Program Manager?

Недавно я публиковал статью о различиях Project Manager, Product Manager и Program Manager. В комментариях закономерно возник вопрос: "А где же Delivery Manager?"

Давайте разберёмся!

В базовой статье я сознательно ограничился тремя ролями - PM, PdM, PgM.
Это клубок который действительно может ввести в ступор даже бывалых, который часто встречается в IT и лучше всего показывает разницу между управлением проектами, продуктами и программами.

Delivery Manager - роль более "нишевое" явление, сильно зависящее от конкретной компании и её процессов. В разных организациях она трактуется по-разному: от старшего PM-а до операционного менеджера в Agile-команде. Поэтому в коротком сравнении Delivery Manager легко внести больше путаницы, чем пользы.

Чем отличается: Delivery Manager = фокус на выполнении обязательств команды и стабильности поставки.

• Project Manager отвечает за проект: сроки, бюджет, риски.

• Product Manager отвечает за ценность и развитие продукта.

• Program Manager отвечает за синхронизацию множества проектов и продуктов.

• Delivery Manager отвечает за то, чтобы команда реально и предсказуемо доставляла результат, а процессы разработки и поставки не ломались.

Задачи Delivery Manager-а

• Следить за здоровьем процессов в команде (Agile церемонии, velocity, SLA).

• Снимать операционные блокеры, чтобы команда могла работать.

• Координировать взаимодействие с другими командами (DevOps, QA, Support).

• Мониторить метрики поставки.

Когда Product Manager уходит в стратегию и общение с рынком, а Project Manager в бюджет и отчётность, команде часто нужен человек, который держит фокус на ежедневной предсказуемости поставки. В крупных организациях Delivery Manager становится опорой для нескольких команд разработки, снимая с PdM и PM часть операционных забот.

Метрики эффективности Delivery Manager:

• Velocity & Throughput - стабильность скорости команды.

• Lead Time & Cycle Time - скорость прохождения задач.

• Defect Rate - качество поставки.

• Team Satisfaction - насколько комфортно команде работать в текущем процессе.

Delivery Manager - это не конкурент Project/Product/Program Manager, а их дополнение.

• PM, PdM и PgM отвечают за "что и зачем" (стратегия, ценность, цели).

• Delivery Manager отвечает за "как именно" на уровне повседневной работы команды.

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

А у вас в компаниях, есть ли отдельные Delivery Manager-ы или их функции выполняют PM/PdM?

Ну что вы скажете? С 12 минут до 3 секунд(!) сократил время поиска инструкций полнотекстовый поиск в KMS Gran.

Один из наших клиентов - IT-компания - хранила документацию в Google Docs и Telegram, что вызывало путаницу. В 2024 году внедрили базу знаний KMS Gran, создав разделы "Проекты", "API-документация" и "Ошибки и уроки".

Результат спустя год:

• время поиска инструкций сократилось до 3 секунд

• скрипты автоматизировали уведомления о новых версиях API, уменьшив время согласования релизов на 30%.

• за 6 месяцев количество багов в коде снизилось на 25%, так как разработчики быстро находили решения по прошлым ошибкам.

Статистика показала, что раздел "Ошибки и уроки" просматривали 80% команды, что привело к добавлению видео-разборов типичных ошибок.

А какие процессы хотелось бы улучшить в вашей команде?

Интеграция PVS-Studio c SGRC SECURITM

Компания PVS-Studio и платформа Securitm заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

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

Отчёт анализатора PVS-Studio стало возможным загрузить в Securitm для дальнейшего использования с помощью пользовательского интерфейса системы.

Подробнее о том, как загрузить отчёт анализатора PVS-Studio в систему Securitm можно прочитать в посвящённом этому разделе нашей документации.

Также мы с коллегами из Securitm провели совместный вебинар, на котором обсудили, как обеспечить соблюдение требований ГОСТ в области РБПО, а также показали реальные примеры использования PVS-Studio и Securitm.

Почему ваша архитектура ломается? Спросите у того, кто чинил десятки таких систем!

04.09.2025 в 15:00 (Мск) приглашаем на первую открытую AMA-сессию «Спроси меня о чем угодно» с Дмитрием Овчаренко — техническим директором департамента «Разработка для финансового сектора» IBS и экспертом Учебного центра IBS по архитектуре ПО.

Что вас ждёт (и почему это не обычный вебинар):

✔️ Без воды — только честные ответы на ваши вопросы (даже на те, о которых стыдно спросить).

✔️ Разбор реальных косяков — как ломались системы и что с этим делали.

✔️ Карьерный лифт — что нужно, чтобы перейти из разработчика в архитекторы?

А еще конкурс: 

Пришлите самый нестандартный, забавный или абсурдный вопрос в комментариях к этому посту. Автор лучшего получит приз!

Кому полезно?

➕ Разработчикам, которые хотят расти до архитекторов.

➕ Аналитикам, уставшим от абстрактных советов.

➕ Всем, кому интересно, как устроена «кухня» fintech.

➡️ Зарегистрироваться ⬅️

P.S. Такого у нас еще не было — будет жарко! 🔥

Интеграция PVS-Studio в Inseq RBPO

Компания PVS-Studio и Inseq заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

Программное обеспечение Inseq RBPO предназначено для создания и управления конфигурациями, необходимыми для автоматического развёртывания и настройки компонентов инфраструктуры безопасной разработки ПО — систем контроля версий, анализаторов кода, инструментов автоматизации сборки, тестирования и развёртывания. Управление конфигурациями и политиками безопасности осуществляется централизованно.

"ИНСЕК.РБПО" представляет собой клиент-серверную систему, работающую на локальном оборудовании. Она включает серверную часть, генерирующую конфигурационные файлы, и веб-приложение с графическим интерфейсом для взаимодействия с пользователями.

Внутри этой платформы стало возможным использовать статический анализатор PVS-Studio для поиска критических ошибок в исходном коде.

Также мы провели вебинар с коллегами из Inseq, в котором поговорили о необходимости регулярного статического анализа, а также в целом об автоматизации в РБПО.