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

Быстрые спойлеры для тех, у кого мало времени

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

Если интересно, как в этом помогает Брэнзи, добро пожаловать под кат!

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

Проблемы, с которыми он помогает:
— Хаос под видом демократии.
— Бесконечные обсуждения без решений.
— Вечно перегруженный руководитель.
— Слабая инициативность сотрудников.

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

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

Фразу «капиталисты сами продадут нам верёвку, на которой мы их повесим» обычно приписывают Ленину. Историки не уверены, говорил ли он её на самом деле, но в инженерной среде эта мысль звучит неожиданно современно.

В последние годы принято рассуждать об Open Source с некоторой тревогой. Аргумент выглядит так: программисты десятилетиями писали код и публиковали его бесплатно, компании собирали этот код, строили на нём продукты, а теперь обучают на нём искусственный интеллект. После чего этот же интеллект якобы заменит разработчиков. Картина получается строгая: коллективный труд превращается в сырьё, сырьё — в модели, а модели — в инструменты корпораций.

Но в такой схеме чего-то не хватает. Она описывает только первую половину процесса.

Если смотреть на явление более инженерно, Open Source — это не столько способ распространения программ, сколько особый механизм распространения знаний. Он работает по той же логике, что и наука.

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

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

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

Как перевести продакшен-проект на рельсы agent-driven development - когда LLM-агенты становятся полноценными участниками разработки, а не просто подсказчиками в автокомплите ? Реальный опыт на реальном проекте !

Продолжаем улучшать Feedback Loop. В предыдущей статье я ускорил прогон тестов в 6 раз. Теперь — следующий шаг: LLM-агент генерирует тесты. Два подхода (sprint-driven и coverage-driven), шестиуровневый pipeline верификации, двух-агентная архитектура, оптимизация feedback loop — и 68 тестовых файлов на выходе с acceptance rate 86.8% при ревью живыми разработчиками.

В статье — конкретика: как анализировал покрытие и свежесть документации, как ускорял компиляцию для агента, на чём экономил токены, и что сказала команда на code review.

SimpleGen — новый продукт для генерации решений на платформе SimpleOne с помощью AI. В этой статье рассмотрим, как начать работу с SimpleGen: что поставить на рабочую машину, как подготовить репозиторий, настроить доступ к SimpleOne, а также выполнить свою первую задачу.

Всем привет! У многих из нас куплена максимальная подписка на Google AI Ultra - правда же? Да, она стоит не копейки - по акции первые 3 месяца обходятся в $124.99/мес, а потом ценник подрастает. Но мы заставим ее отработать каждый цент.

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

Мы взяли секундомер и устроили жёсткий тест четырём нашим производственным направлениям: мобилке на Native и Flutter, аналитике и QA. Дали командам доступ в Cursor и Claude Code, чтобы вытащить на свет реальные цифры. По итогу — разрыв между цифрами и действительностью оказался шокирующим. 

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

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

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

Меня зовут Юрий Коберман, я технический продакт в Точка Банк. Мы в команде несколько раз меняли систему работы с API. Начинали с одной команды, которая писала всё вручную, и постепенно пришли к универсальному инструменту, с помощью которого сервисы могут выходить наружу самостоятельно без очереди и потери качества. Подробности — в этой статье.

Всем привет, я Артем Герасимов, владелец продукта SimpleOne SDLC. Чуть больше года назад я пришел в компанию в момент, когда продукт только прошел стадию MVP, которую мы делали быстро, чтобы проверить гипотезу. Гипотеза подтвердилась, появились клиенты, но вместе с ними пришел беспорядок: запросы терялись между почтой и чатами, сроки срывались, процессы перестали работать.

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

Итак, Вы – руководитель разработки (главный инженер, архитектор и т.п.) большой системы. После здравых размышлений Вы (обосновано) выбираете для системы микросервисную архитектуру. Далее Вы (и опять обоснованно) разделяете систему на микросервисы, продумываете API, рисуете стрелочки и диаграммы и можно программировать.

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

В этой статье мы рассматриваем два принципа: «Данными владеет только владелец» и «Локальность данных». Понимание принципов, понимание возможностей проектирования доступов к данным позволит Вам спроектировать устойчивые и надежные системы. 

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для ИТ-команд.

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

Один из примеров такой документации — Architecture Decision Records — короткие структурированные документы, которые фиксируют одно конкретное архитектурное решение вместе с контекстом, рассмотренными альтернативами и принятыми trade-off'ами. Ключевое слово — конкретное. ADR — это не архитектурный обзор системы и не проектная документация. Это ответ на один вопрос: «почему мы решили именно так, а не иначе?»

На эту статью меня вдохновил испанский ИИ-слоп и тред на Hacker News вокруг вопроса «как вы фиксируете ПОЧЕМУ инженерных решений, а не только ЧТО?». В статье напомню, зачем нужен ADR и какие есть стандартные проблемы. Также приведу выжимки из кейсов, в которых описаны любопытные ИИ-автоматизации.

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

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

Разберем реальный кейс, где попытка сделать «идеальное» техническое задание привела к увеличению сроков проекта почти в два раза.

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

1. Система ведения онтологии и моделирования бизнеса
2. Система верификации типов с правилами подстановки
3. Система среды исполнения динамического кода
4. Система модульной эволюции кодовой базы

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

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

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

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

Гарвард отследил 62 миллиона работников в 285 000 компаний. При внедрении AI найм джунов падает на 9-10% за полтора года. А ещё 30-50% разработчиков в исследовании METR отказались работать без AI - физически не смогли. Через 3 года эти два факта столкнутся.

Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. За последние два года наша команда внедрила использование ИИ практически на всех этапах разработки — от прототипирования до код-ревью.

В этой статье расскажу, почему внедрение ИИ может незаметно превратить вашу кодовую базу в неподдерживаемое legacy, как измерять реальную эффективность вместо иллюзии скорости и какие правила помогут получать пользу без деградации качества.

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