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

На SOC Forum одной из самых горячих дискуссий стала тема, которая ещё пять лет назад казалась нишевой, а сегодня напрямую влияет на устойчивость критической инфраструктуры: создание доверенных репозиториев ПО.

В дискуссии приняли участие: Федор Герасимов, лидер сообщества FinDevSecOps, эксперты финансового сектора − Максим Кожокарь (Банк России), Всеслав Соленик (Сбертех), а также Антон Прокофьев (ГК «Солар»), Юлия Липатникова (Cloud.ru) и Николай Костригин (Базальт СПО).

Полную запись дискуссии можно посмотреть здесь (Программа 18 ноября, Зал 3, 16.00).

В этом материале приводим самые интересные цитаты экспертов сессии и их рекомендации.

В прошлой статье я рассказывал, как настроил личный iptables и перешел в режим Default Deny, чтобы отбиться от внешних DDoS-атак (коллег, пустых встреч и спама). Периметр я защитил, входящий трафик почистил. Uptime вырос.

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

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

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

В какой-то момент я понял: это не лень. И это не «отсутствие мотивации». Это классический Technical Debt (Технический долг), только не в репозитории, а в нейросети.

И проценты по этому долгу я плачу самым дорогим ресурсом — своей когнитивной емкостью.

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

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

Год ушёл на то, чтобы навести порядок в процессах: выстроили скоринг задач по RICH, ввели требования, ограничили загрузку команд и формализовали тестирование. Хаос превратился в поток, появился контроль сроков, а time-to-market снизился на 30%. Но нагрузки на PO всё ещё остаются.

Привет, Хабр! Меня зовут Денис Улизко, я CPO CRM-системы Automation of Sales (AoS) в B2B-блоке МТС. Это тот самый продукт, вокруг которого крутится большая часть моего дня. Я уже не первый год в этой роли, но каждый раз убеждаюсь: она про баланс между хаосом и структурой, а не про красивые концепции. В один день — архитектура, в другой — инцидент на проде, вечером — охота за фокусом. Сегодня расскажу, как эта роль выглядит изнутри на примере AoS, как проходит мой рабочий день, какие решения приходится принимать и как удерживать баланс между операционкой и фокусом на ценность для бизнеса и пользователей. Погнали! 

Статья построена на основе интервью с Вячеславом — руководителем департамента разработки SSP SOFT.

Когда речь заходит о технических собеседованиях, большинство кандидатов представляет себе классическую схему: компания зовет кандидата, внутренний тимлид или сеньор-разработчик задает вопросы, оценивает тестовое задание, дает live-coding (лайфкодинг) — и выносит вердикт. В SSP SOFT мы выстроили процесс иначе. Мы используем внешних технических экспертов и в статье рассказываем — почему так.

Выбираем архитектуру по кайдзен: на что обратить внимание

Я часто замечаю одни и те же ошибки в различных решениях — как по работе, так и в жизни. Зачастую многие думают, что сейчас сделают прототип, а потом допилят, но не учитывают, как будет развиваться решение и что лучше взять за основу. Поэтому эта статья будет полезна не только архитекторам при выборе основы, но и разработчикам для понимания более важных и ценных задач. А также проектным менеджерам — чтобы создать верную стратегию развития.

Предлагаю разобрать на примере подход выбора архитектуры для продукта!

Вам наверняка попадался тот самый мем: «Как видит проект заказчик / как видит разработчик / как видит пользователь». Так вот, я — тот парень, который рисует четвертую картинку: «Как это должно работать на самом деле» и «как сделать продукт, который устроит всех». 

Меня зовут  Ярослав, я data pre-sale в MWS. За долгие годы работы я совершил массу ошибок и однажды чуть не похоронил проект, потому что послушал заказчика и не поговорил с бухгалтером, которому в итоге предстояло пользоваться продуктом. Оказалось, их боли — две огромные разницы. В итоге я вывел для себя два главных правила:

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

— Твоя главная суперсила — не техстек, а синергия. Умение переводить с языка бизнес-хотелок на язык Python и обратно, а потом и на диалект «бухгалтера Галины Ивановны» — вот что определяет успех твоего проекта. 

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

Если вы до сих пор пытаетесь выстроить нормальную работу в таск-трекере — расслабьтесь. Это скучно и неблагодарно. Гораздо интереснее использовать эти 11 вредных советов.

Работаю в ИТ с 2004 года. Пришёл осознанно в индустрию не за деньгами - по любви к технологиям и тишине, когда можно заставить машину делать нужные вещи. Начинал с настольных приложений на Delphi, бэкенд на Python, немного React. Сейчас Финтех.

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

Краткий PMBoK, возможности Ганта, STATIK, контрольная диаграмма, диаграмма сгорания задач, топ таск‑трекеров, ошибки делегирования, манипуляции на проекте, синдром спасателя и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

В последнее время тема лидерства в IT компаниях потерялась в потоке энтузиазма, вызванного безграничными перспективами отрасли. Лидерство, конечно, фигурирует в современных методологиях типа Agile и DevOps, но при этом не наделяется достаточной силой, чтобы выполнить свою трансформационную роль. Лидерство выглядит как Золушка с неочевидным для всех королевским потенциалом. Эта статья возвращает лидерство на пьедестал, обосновывая его уместность именно для IT. Речь здесь идет о таком лидерстве, которое одержимо незаурядным результатом в равной степени, как и опорой на смыслы и человеческое достоинство и не имеет ничего общего с расхожим «лидерством», которое практически равнозначно понятию «руководитель». За таким подлинным пониманием лидерства, стоят хорошо известные с 70-х годов принципы трансформационного лидерства Джеймса Бернса и Бернарда Басса. В период индустриальной эпохи эти принципы использовались факультативно, хотя и с большим успехом. Лидерство в компаниях стало притчей во яцызах , но не возобладало в традиционном менеджерском управлении. Эра информационных технологий делает трансформационное лидерство в IT компаниях безальтернативным. Эта статья не про теоретические изыскания на будущее, а про достижение незаурядных результатов в настоящем.

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

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

Со временем стало очевидно: проблема не в модели, а в том, как мы ее онбордим в проект. Один и тот же Claude в одном репозитории ведет себя как сильный мидл, а в другом как растерянный стажер. Разница почти всегда в том, что написано (или не написано) в CLAUDE.md и его аналогах для агентов.

Я перепробовал кучу подходов: от огромных "библий" с правилами до минималистичных заметок и автогенерации. Что-то работало, что-то категорически нет. В итоге вырисовались простые, но хорошо проверенные на практике принципы того, каким должен быть CLAUDE.md, чтобы не было мучительно больно ни вам, ни агенту.

Бизнес Додо активно масштабируется. Уже сейчас Dodo IS круглосуточно работает в двух облаках, более чем в 25 странах и практически во всех часовых поясах. В таких условиях важно знать, что вся система действительно работает хорошо, а не просто «не горит» прямо сейчас.

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

Сегодня мы расскажем, как приручили своего SLO'на и прошли путь от первых экспериментов с нагрузочным тестированием до построения культуры надёжности.

Привет, Хабр! ИИ-агенты и производные от них стремительно вошли в повседневную рутину разработки, зажигая глаза менеджеров и добавляя головной боли архитекторам. И если с одиночным агентом в целом никаких проблем не возникает, то когда агентов становится много, возникает настоящая проблема: как ими управлять? В этой статье попробуем разобраться в основных подходах к созданию управляющего слоя в такой системе, разберём на примере, почему не все очевидные подходы будут работать и какие классические архитектурные паттерны актуальны в новой моде. И, конечно же, расскажу, как это работает на практике в Домклик. Будет интересно!

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

Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап.

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

TL;DR

Мы собрали рабочего ИИ‑агента‑разработчика, который сам анализирует задачи в Jira, уточняет детали, пишет код, запускает сборку, фиксит ошибки, создаёт MR в GitLab и отправляет его человеку на ревью. Он работает параллельно на нескольких задачах, благодаря чему суммарное время выполнения пачки задач падает почти втрое. Команда избавилась от рутины, а скорость разработки выросла без расширения штата.

Использовали: Ollama + Qwen3 Coder, PostgreSQL, Docker, GitLab/Jira API, систему строгих JSON‑действий.

Столкнулись с контекстом, «галлюцинациями», GPU и самовольными правками кода — всё решаемо архитектурой.

ИИ не заменяет разработчиков, он снимает тупую монотонную работу и экономит деньги.

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

Я Никита Дубина, руководитель команды автоматизации Департамента больших данных РСХБ. В этой статье расскажу о том, что такое теневые ИТ, почему они возникают в крупных организациях, особенно в банках, какие риски несут и как при правильном подходе могут стать источником новых идей. Делюсь опытом борьбы с ними. 

«Зачем беспокоиться о том, чего не произойдёт?»

Этот вопрос председателя КГБ Чаркова из сериала «Чернобыль» может стать хорошей эпитафией для сотен закончившихся катастрофами проектов по разработке, модернизации и эксплуатации ПО. Провалы в этой сфере происходят везде, они не зависят от страны и размеров компаний. Они случаются в коммерческих, некоммерческих и государственных организациях, вне зависимости от статуса и репутации.

За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни.

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

Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.