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

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

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

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

В 1985 году Чжан Жуйминь раздал кувалды рабочим и заставил разбить 76 бракованных холодильников. Для сотрудников убыточного Qingdao Refrigerator General Factory это выглядело весьма странно (холодильники тогда стоили как пара месячных зарплат), но директор хотел проиллюстрировать простую идею: за качество отвечает тот, кто непосредственно делает продукт, а не только начальство.

Сорок лет спустя Haier — империя с выручкой $52 миллиарда — работает как воплощение принципа, который открыли через боль рефакторинга: организационная структура неизбежно диктует архитектуру систем. То, что в IT называют законом Конвея, китайский производитель холодильников воплотил через радикальную децентрализацию всего бизнеса. 

Эта история о том, как структура команды неизбежно определяет архитектуру кода, почему Amazon Prime Video сэкономил, вернувшись к монолиту, и что общего между китайским производителем холодильников и вашим последним проектом на микросервисах.

Привет, я Рома, во время поиска работы я часто сталкивался в вакансиях project и product менеджеров с требованиями «технического бэкграунда» или чего‑то более конкретного, например, составления API запросов. Из своего опыта я слабо понимал откуда берутся данные требования, но запросы в Postman направлять научился.

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

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

Привет! Меня зовут Денис, я руковожу группой R&D в Naumen Service Management Platform. В этой статье — разбор виртуальных потоков (VT) в Java: почему исторически обычные потоки упирались в I/O, как и зачем появились виртуальные потоки, что пошло не так в Java 21, что исправили в JDK 24–25, а также когда виртуальные потоки необходимы, а когда — лучше от них отказаться.

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

Привет, Хабр! Я — Павел Лукьянов, системный архитектор и Deputy CTO в AGIMA. В этой статье по мотивам доклада с Saint HighLoad++  на примере одного из реальных кейсов с большим количеством внешних систем для сбора данных расскажу, как их собирать и обрабатывать, представлю готовые импортозамещённые инструменты для систематизации и хранения. Кроме того, покажу, почему не стоит заморачиваться из-за безопасности и по какой причине бизнесу важно следить за проектом в реальном времени и принимать решения.

ИИ перестраивает саму ткань разработки: ускоряет релизы, но множит баги, заставляет пересматривать тестирование и принципы командной работы. В 2025-м инженеры и лиды живут в двойственности — между стремительным ростом продуктивности и растущей ценой наблюдаемости, между автоматизацией и риском утраты человеческого взаимодействия. Новый отчёт InfoQ о культуре и методах разработки показывает: индустрия вступила в фазу, где платформенная инженерия становится наследником DevOps, а психологическая безопасность и умение работать малыми итерациями — вопросом выживания команд, а не модного тренда.

Сегодня расскажу историю о том, как мы еще в 2017 году решили поменять инфраструктурную платформу. Мы расшифровали мой доклад с DevOpsConf21, много всего уточнили, переписали и дополнили с учетом опыта следующих четырех лет, прошедших после того выступления. 

8 лет назад у нас было 40 сред, 15 разработчиков, 2 монолита, 10 сервисов и свое железо в трех серверных стойках. С такими исходными данными мы решили перейти с Puppet на Ansible. Окружений много, потому что с 2010-го мы поставляли разработчикам и тестировщикам маленькие копии нашего приложения — это делало задачу еще интереснее.

Путь был непростой. О нем расскажу в хронологическом порядке, не забывая о косяках и ошибках. По ходу повествования я выделил инсайты, которые могли бы сильно помочь мне в прошлом. В конце оформил их в виде письма для себя образца 2017-го 🙂.  А если вы решитесь проделать нечто столь же безумное (ну там, не знаю, переехать с микросервисов на монолит, с linux на windows и так далее), надеюсь, мои заметки уберегут вас от сложностей, с которыми мы столкнулись.

После COVID-19 наша культура труда в основном изменилась к лучшему, но были и негативные изменения, например, увеличение количества совещаний на 13,5%[1].

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

В своей знаменитой статье «Maker's Schedule, Manager’s Schedule» [2] Пол Грэм писал:

«Когда работаешь в режиме творца, совещания — это катастрофа. Единственное совещание может поломать день, разделив его на две части, в каждой из которых невозможно сделать ничего достаточно сложного».

Эта проблема не решилась с появлением ИИ-помощников в кодинге; напротив, она усугубилась, потому что менеджеры теперь считают, что разработчики могут быть продуктивными в меньших временных интервалах.

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

Компания Atlassian, известный производитель систем для управления проектами и разработки, объявила о прекращении продаж и поддержки on-premise версий своих продуктов в 2029 году. Эта новость вызывает серьезные опасения среди российских компаний, активно использующих эти продукты для своей работы.

Почему Jira прекращает поддержку on-premise версий?

Atlassian начала поэтапный отход от серверной модели ещё в 2020 году, когда была провозглашена стратегия Cloud First. Инновационные функции последних лет разрабатывались исключительно для облачных решений, оставляя on-premise версии позади. Изначально компания отказалась от версии Server, теперь же процесс коснулся всех серверных решений:

Примерно месяц назад я рассказывал о проекте @er77/code-graph-rag-mcp — инструменте, который превращает LLM из простого генератора кода в полноценного члена команды с глубоким пониманием архитектуры вашего проекта. Сегодня я рад представить самое крупное обновление, которое выводит анализ кода на совершенно новый уровень. Мы не просто добавили новые функции, мы кардинально расширили возможности инструмента, увеличили его производительность и добавили поддержку десяти языков программирования.

Узнайте, как использовать шаблоны элементов и коннекторов в Camunda, чтобы быстро создавать эффективные, стандартизированные и многократно используемые процессы.

Строим B2B-платформу для международной торговли (ВЭД), где решаем сразу несколько болей

⚠️ Важно: Платформа не банк и не платёжная система. Все реальные выплаты выполняются лицензированными операторами (банки/НКО/EMI).

Мы — интерфейс и оркестратор.

Чтобы освободить команду от рутины, я возглавил инициативу по внедрению автоматизации. Мы добились этого с помощью Jira Automation и Telegram Bot API, полностью избавившись от отчётов и ускорив работу команды — о результатах расскажу в этой статье. Стоит сказать, что до этого я был обычным пользователем Jira, без глубокого погружения в её внутренние возможности. Тем интереснее этот кейс оказался для меня!

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

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

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

Отсюда сформулируем главные вопросы, на которые мы ответим в этой статье:

- Нужно ли вам писать юнит тесты под ваши задачи? Или лучше выбрать другой тип тестирования и ограничиться только им?

- Если все же да, то как тогда писать юнит-тесты? Какие есть подходы, и какой лучше выбрать?

Короче, всё как обычно: как и нафига?

Заметил одну особенность, часто проекты у разрабов нормально идут, запускаются, контейнеры собираются. но если к примеру, новенький заходит на проект, то он не может собрать проект. ты смотришь и он реально не поднимается, 0_о. меняешь не много конфиг и проект вновь запускается. задумался, может спросить в чате у живых людей кто как решал. но вкладка chatGPT была открыта и я задав вопрос там. в течении пары минут я получил ответ и рекомендации по устранению проблемы. стало понятно, что нейронки снижают коммуникацию в команде. новички у коллег стесняются спрашивать, а иишки позволяют набрать опыта не выработав навык задавания вопросов. что в последующем повлияет на работу с самой нейронкой. в итоге, изложив свои мысли сначала chatGPT, а потом DeepSeek, получил готовое решение. Решил поделиться с вами.

Как не развалить команду с помощью нейросетей: руководство по выживанию

Подзаголовок: Используем ChatGPT не для замены коллег, а для усиления командной продуктивности.

ИИ-планировщик отправил туристов в несуществующий каньон. Разбираем, почему нейросети опасны для путешественников

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

Кейс №1: «Священный каньон» в Перу

Гид из Перу Мигель Анхель Гонгора Меса столкнулся с туристами, которые собирались в одиночный поход к «Священному каньону Умантай». Проблема в том, что такого места не существует. Нейросеть просто скомбинировала названия двух реальных локаций и сгенерировала красивое, но абсолютно фейковое описание. Туристы потратили $160, чтобы добраться до глухой дороги в горах без связи, гида и понимания, что делать дальше. На высоте 4000 метров такая «галлюцинация» ИИ могла закончиться трагически.

Кейс №2: Застрявшие на горе в Японии

Другая пара использовала ChatGPT для похода на гору Мисэн в Японии. ИИ уверенно сообщил, что последняя канатная дорога вниз работает до 17:30. В реальности она закрылась раньше, и туристы застряли на вершине горы после заката.

Таких историй становится все больше: от Эйфелевой башни в Пекине до невыполнимых марафонских маршрутов. Почему так происходит?

Суть проблемы — «галлюцинации» LLM

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

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

Что в итоге?

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

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

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

Следующий этап эволюцииИИ — агентные системы. Что это и почему это важно для вашего бизнеса?

2025 год называют «годом AI‑агентов», но что это на самом деле? Большинство путает их с продвинутыми чат‑ботами или RAG‑системами. Однако настоящий агентный ИИ — это следующий шаг: система, которая не просто отвечает на вопросы, а самостоятельно анализирует, планирует и действует для достижения цели.

В своей новой статье я сделал выжимку из материала военного журнала Small Wars Journal, где эта концепция раскрывается на примере современной армии. Они называют это «доминированием в принятии решений».

Что внутри:

Четкое разделение: где хайп, а где реальность агентного ИИ в 2025 году.

Таблица, показывающая, как агентные системы меняют 4 ключевых этапа управления: Понимание, Визуализация, Направление и Оценка.

Практический чек-лист для оценки готовности вашей компании к технологиям завтрашнего дня.

Привет, Хабр! Это моя вторая статья, посвященная нашему проекту. 

Мы создаем продукт, который, как мы верим, изменит рынок труда в Рунете — AI-ассистента для поиска работы, забирающего на себя всю рутину. А рутины, как выяснилось, очень много.

В этой статье я постараюсь открыть больше внутрянки про техническую часть проекта и продолжу рассказывать про наши факапы (а куда без них?:)