Обновить
597.18

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

Планирование, отслеживание и контроль

Сначала показывать
Порог рейтинга
Уровень сложности

Принципы организационного проектирования

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели2.6K

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

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

Читать далее

Новости

Атаки на цепочку поставки ПО: виды угроз и как с ними бороться

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели3.2K

Атаки на цепочку поставки – одна из самых устойчивых угроз для разработки программного обеспечения. По итогам OWASP Top Ten, в 2025 году проблемы с цепочкой поставки заняли третью позицию в рейтинге наиболее критических рисков безопасности веб-приложений.

В случае с атаками в open source злоумышленники эксплуатируют доверие к публичным репозиториям, человеческий фактор и сложность зависимостей, внедряя вредоносный код в тысячи проектов одновременно. Последствия варьируются от единичной кражи секретов до компрометации целых экосистем с глобальными экономическими потерями. Только за 2025 год они оцениваются в $60 млрд и прогнозируются на уровне $138 млрд в ближайшие годы.

Читать далее

Cursor не ускоряет разработку, а создает техдолг

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели2.9K

На бумаге AI кодинг выглядит как ускоритель разработки. В живой кодовой базе он все чаще выглядит как ускоритель будущих проблем. Новый paper про Cursor как раз показывает эту механику: вспышка скорости, рост сложности, откат продуктивности. А потом начинается самое интересное...

Читать далее

От стратегии до проектов: для чего бизнесу переходить к портфельному управлению

Уровень сложностиПростой
Время на прочтение8 мин
Охват и читатели3.4K

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

В 2026 году у крупных организаций одновременно реализуются десятки инициатив: цифровая трансформация, импортозамещение, развитие продуктов, модернизация инфраструктуры. В таких условиях инвестиционные портфели проектов становятся не формальностью, а инструментом выживания и роста.

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

Читать далее

Разбираем подводные камни, ошибки и лучшие практики при разработке Kubernetes-операторов. Часть 2

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели4K

Привет, на связи Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Мы все так же пилим наш космолет и готовы поделиться с вами новыми полезными рекомендациями и предостеречь от ошибок при разработке операторов.

В первой части мы уже начали обсуждать разработку K8s-операторов. Сегодня поговорим о поведении  Reconcile и конфликтах обновлений. Рассмотрим возможные ошибки и обсудим тонкости, которые помогут их избежать.

Поехали!

Читать далее

Какую главную ошибку допускают компании при ИИ-трансформации, как это исправить и при чем тут Брэнзи?

Время на прочтение9 мин
Охват и читатели4K

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

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

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

Читать далее

Принцип управления командой «3D»

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели3.2K

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

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

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

Читать далее

Чем управляет корпоративной архитектор? ИТ‑ландшафтом

Уровень сложностиПростой
Время на прочтение8 мин
Охват и читатели3.2K

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

Читать далее

Верёвка и немного теории распространения знаний

Уровень сложностиСложный
Время на прочтение4 мин
Охват и читатели8.1K

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

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

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

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

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

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

Читать далее

Расцвет продакт-инженеров и трансформация в агентную организацию: что ждет продуктовую разработку в 2026 году

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели9.5K

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

Погнали!

Хроники Agent Driven Development трансформации .1: улучшаем agent feedback loop

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели7.7K

Как перевести продакшен-проект на рельсы 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

Время на прочтение5 мин
Охват и читатели7.7K

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

Читать далее

Как выжать максимум из подписки Google AI: параллельные агенты и кросс-модельный консенсус

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели6.4K

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

Читать далее

Ближайшие события

Вы считаете ИИ-ускорение неправильно, сливая бюджет в трубу, пока 7 из 10 проектов умирают ещё на этапе пилотов

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели7.1K

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

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

Читать далее

Git workflow для частых и независимых релизов веб-сервиса

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели5.5K

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

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

Читать далее

Как делать внешние API, если сервисов слишком много

Время на прочтение6 мин
Охват и читатели5K

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

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

Читать далее

МVP случился. Что дальше?

Уровень сложностиПростой
Время на прочтение8 мин
Охват и читатели6.1K

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

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

Читать далее

Владение и локальность

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели6.2K

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

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

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

Читать далее

Интересные кейсы про ADR + ИИ

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели4.6K

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

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

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

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

Читать далее

Как плохое ТЗ может удвоить стоимость проекта

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели6.1K

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

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

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

Читать далее
1
23 ...