Разбираюсь, почему рука тянется закрыть вкладку, когда текст очевидно сгенерирован нейросетью — с точки зрения психологии. Параллельно ставлю эксперимент: эту статью я написал сам, а вторую — целиком отдал Claude. Посмотрим, какую заминусят первой.
Разрабатываю AI-агента персональной аналитики для себя вместе с Claude Code. Любопытной инженерной задачей оказалась архитектура памяти. Как сделать, чтобы агент помнил не только последний разговор, но и паттерны, накопленные за месяцы? В этой статье описана архитектура, рабочие решения и грабли, на которые я наступила.
Причины провалов ваших проектов, нездоровая коммуникация в команде, изменения в PMBOK, матрица Эйзенхауэра, ИИ-камуфляж и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Делюсь методологией артефактно-ориентированной разработки с AI-ассистентами. Метод решает проблему ограничений контекста в LLM через двустороннюю синхронизацию проекта и сжатых артефактов. Эксперимент на реальном проекте (портфолио с нуля, 36 файлов) показал: 18× меньше файлов для загрузки, 30× ускорение подготовки контекста, 100% воспроизводимость.
Если верить хайпу, та отрасль разработки ПО, к которой мы привыкли, уже мертва. Однако странно, что, несмотря на годы работы с ИИ-инструментарием, результаты выглядят, ощущаются и работают примерно так же, как и в начале: невзрачно.
Невозможно спорить, что эту технологию окружает огромный ажиотаж. В неё вливаются сотни миллиардов долларов и создаётся масштабная инфраструктура, что, в свою очередь, требует ещё большего ажиотажа, чтобы оправдать инвестиции. Уже очевидно, что всё построено на преувеличениях — новые модели продолжают обучать для достижения целей, которых должны были, судя по обещаниям, достичь уже вышедшие в тираж модели.
Поэтому позвольте мне сказать фразу, которая повергнет бывалого резидента Кремниевой долины в больший шок, чем дефекация на Маркет-стрит: не использовать ИИ совершенно нормально.
Это не превратит вас в троглодита. Из-за этого вы не останетесь на обочине прогресса, который якобы несут самопровозглашённые техноволшебники и их агенты. На самом деле, такое решение выглядит гораздо менее трудным и гораздо более радостным, чем альтернатива ему.
Это перевод статьи с opensource.com, которая мне показалась особенно полезной и практичной, поэтому решил поделиться адаптированной версией для русскоязычной аудитории. Оригинал доступен по ссылке: https://opensource.com/article/22/10/docs-as-code
В статье разбирается подход Docs as Code — способ встроить документацию в процесс разработки так, чтобы она проходила через Git, ревью и автоматическую сборку вместе с кодом. Материал будет полезен разработчикам, тимлидам и тем, кто выстраивает инженерные процессы в команде.
Вирусный пост на Substack обвалил фондовый рынок и похоронил профессию. Citadel Securities Кена Гриффина ответила цифрами. Разбираю обе стороны — и добавляю то, что вижу на своих проектах.
«Я заметил, что возникает дефицит внимания в твоей команде, и это снижает мотивацию,» — сказал председатель ПРП в одной из наших приватных бесед на профсоюзной встрече. И я решила разобраться с этим. В статье опишу результаты этого исследования: возникновение, основные проявления и способы устранения этого дефицита.
Velocity, Burndown и количество закрытых задач выглядят как контроль над разработкой. На практике эти метрики часто создают только видимость управляемости: отчёты красивые, а сроки всё равно срываются.
В статье разбираем, какие показатели действительно помогают прогнозировать сроки, находить узкие места и держать баланс между скоростью разработки и качеством релизов.
Данная статья является переводом откровений Гельдрейха о работе в Valve и некоторых других «самоорганизующихся» компаниях (представленных в виде, без преувеличения, «учебника по выживанию»), с некоторым форматированием для более удобного чтения. Имейте ввиду, что это рассказ об условиях работы на Западе (США), и некоторые советы могут выглядеть очевидными или странными.
Привет! Меня зовут Игорь Федорчук, я руковожу разработкой в направлении «Монобренды» в GRI.
За последний год компания заметно выросла: команд стало больше, изменений и интеграций — тоже. А процессы в разработке долго оставались такими же, какими были пару лет назад. В какой-то момент это перестало «склеиваться» само собой: ответственность размылась, централизованной точки входа в команды не было, а коммуникация стала слишком неэффективной.
Это первая статья о том, как мы пересобирали процесс разработки в GRI — от получения запроса от заказчиков до выкатки в прод. В этой части я разберу роли (тимлиды, техлиды, TPM), зоны ответственности и общий флоу. Во второй части покажем, как мы приземлили это в Jira и метрики, а в третьей — как масштабировали поставку: релизы, код-ревью и инциденты.
Начали мы не с Jira и не с попытки «ускорить релизы», а с зоны ответственности. При росте она ломается первой: задачи начинают зависать на стыках ролей, статусы приходится собирать вручную и дублировать в несколько каналов коммуникаций, а «владелец результата» меняется по ходу движения.
Для кого статья: для тех, кто интересуется облаками или планирует заниматься такой разработкой.
О чём статья: ожидания и впечатления людей, присоединившиеся к нашей команде не так давно.
Об авторе: лид стрима в облачном провайдере, набирал большую часть команды в 2024-2025, пришлось скорректировать процесс проведения интервью и создать онбординг.
Продолжаю цикл статей о своей команде и об облаке, которое развиваем.
В этой статье – история нашего роста: как мы отбирали кандидатов, преодолевали «порог входа» в сложные технологии и формировали культуру разработки. Через интервью с участниками команды вы увидите, как менялись их ожидания и что стало реальностью. Это не просто рассказ о найме – это опыт создания команды, где каждый вносит вклад в общий результат. Это был достаточно долгий непростой процесс: процесс поиска, обучения, притирки, развития стандартов.
Недавно знакомый PM попросил рассказать “Что значит отвечать за качество?” в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину.
Матрица Эйзенхауэра знакома каждому управленцу и менеджеру. Этот инструмент любят на тренингах по тайм-менеджменту: рисуют на флипчартах, распечатывают для ежедневников и советуют применять всем — от разработчиков до руководителей проектов.
Говорят, что так получится закрывать задачи без горящих дедлайнов. Но когда дело доходит до практики, матрица перестает работать уже через неделю. И это не потому, что люди ленивые. Приоритизация в компании — это не личная привычка каждого, а целый управленческий процесс.
Помните момент, когда вы впервые попробовали ChatGPT или GitHub Copilot? У меня это было похоже на взрыв: привычные процессы рухнули, а на их месте начала формироваться новая реальность. ИИ не просто ускоряет работу — он заставляет переосмыслить сам подход к хранению и обработке информации.
Раньше я, как и многие, хранил готовые документы: Word‑отчёты, PowerPoint‑презентации, схемы в графических редакторах. Потом пришёл момент, когда я поймал себя на мысли:
«Почему я трачу время на поддержание десятков копий одного и того же текста? Почему не хранить „исходники“, а документы генерировать по мере необходимости — как сборку кода?»
Так родилась концепция, о которой я хочу рассказать.
Привет, Хабр! Меня зовут Антон Осетров, я разрабатываю СнК в компании YADRO. Раньше я проектировал отказоустойчивые бортовые вычислители, а также испытывал в лаборатории микросхемы. В этой статье я расскажу, что такое DFT, зачем это нужно, а также сравню популярные архитектуры, с помощью которых DFT реализуют на FPGA.
Я долго размышлял на данную тему и наконец решил изложить.
Вся эта история с оценкой кода по количеству написанных строк или другие попытки оценить объем работы мне всегда не давали покоя.
Сейчас я не пишу код в промышленных масштабах, разве что для себя какой-то мелкий инструмент. Но когда-то я писал много и занимался этим больше 15 лет.
Придешь утром в офис и начинаешь что-то писать. А вечером мне нравилось иногда нажать ctrl+z и смотреть в ускоренном темпе, пусть и в обратном порядке, как бегал курсор, как выделялись, появлялись и исчезали какие-то блоки кода. Сначала условие и цикл появились в одном месте, потом кусок кода из цикла перешел в процедуру, цикл вообще исчез и т.д.
И я задавал себе вопрос: а кто видел все эти мои поиски и скитания? Для внешнего наблюдателя видно только сколько строк было утром и сколько их стало вечером. Но это вообще не то. Эти 80 строк даже не намекают на то, чем я занимался целый день. Уверен, вы понимаете, о чем речь.
Сейчас, в эпоху тотальной увлеченности ИИ, меня не покидает мысль, что неплохо бы весь этот когнитивный процесс легализовать.
Здесь не будет инструкций как я это сделал. Здесь будет просто рассуждение вокруг да около.
О чем эта статья
Проблемы клиентов живут на проде годами. Поддержка о них знает, аккаунтам они снятся, разработка горит на проектах, а продукт почти не меняется. Клиенты пишут снова и снова, команда выгорает.
Триггерит?
Поздравляем, у вас сломана петля обратной связи.
Сначала нам обещали, что можно просто разговаривать с ИИ, а он будет писать код. Теперь выясняется, что этого мало: уже выигрывают не те, кто лучше промптит, а те, кто умеет проектировать систему, задавать рамки агентам и ловить их ошибки раньше, чем они попадут в рабочую версию сервиса, которой пользуются реальные люди.
Я разобрала, что произошло за последние месяцы, почему кодинг, что называется, "по вайбу" оказался опасной иллюзией, и что теперь делать разработчикам, чтобы не остаться за бортом.
Пятница, конец спринта. Команда сдала всё в срок. Клиент доволен. Тишина в эфире. Я смотрю на экран и понимаю, работу затащили, как и всегда, но какой ценой?
Команда не выгорела, а я — да.
Выгорел, следя, чтоб не выгорела команда — иронично.
