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

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

Когда команды растут, лидер постепенно с «ускорителя» превращается в координатора сложности. Как руководить и не становиться узким горлышком?

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

Генеративные модели работают в основном на цифровых вычислениях: десятки или сотни шагов через большие сети на GPU. Это энергозатратно и не всегда быстро. Для AR/VR, где всё должно летать прямо здесь и сейчас, такой подход слишком тяжеловесный.

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

Когда человек решает идти по пути менеджера в разработке, например, в начале карьеры или, особенно, уже работая в команде разработки, то приходится фокусироваться на знаниях, которые порой трудно классифицировать и уложить в своей голове. В отличие от разработчика, чей фокус часто сужен до решения конкретных технических задач, менеджеру приходится иметь дело с менее осязаемыми инструментами: процессами, коммуникацией и людьми. В основе своей они имеют другую природу, потому что здесь больше неопределенности и различных инструментов, которые должны помогать в работе. Часто менеджер фокусируется на выполнении правил фреймворка, на механике какого‑нибудь инструмента или метода, забывая, что в конечном итоге пользователь должен получить ценность. Вполне возможна ситуация, при которой все условия фреймворка выполнены, процесс разработки «настроен», на доске сотни выполненных задач, но пользы от них не так много, как кажется. И заказчики, и конечные пользователи могут не оценить вклад команды разработки и самого менеджера. Ситуация, увы, частая и очень обидная. Главная сложность заключается не в изучении теории, а в её применении на практике, где ключевую роль также играет и «социальный фактор». 

Попытки внедрить новые практики, такие как Scrum или Kanban, часто наталкиваются на сопротивление команды, которой комфортно работать в существующем workflow. Иногда проблема усиливается часто меняющимися менеджерами, каждый из которых приносит «волшебную таблетку», оставляя после себя след из никому не понятных артефактов. В результате процессы внедряются поверхностно, лишь создавая видимость изменений. Команда двигает тикеты на Kanban‑доске — значит, у нас «Kanban». Проводятся спринты — значит, у нас «Scrum». Но настоящей ценности такие формальные преобразования не приносят.

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

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

Хабр привет! Меня зовут Кристина Ширкунова, я ведущий аналитик в «Ренессанс жизнь», а до этого 5 лет работала в заказной разработке. Я участвовала в большом количестве проектов: начиная от обычных сайтов и заканчивая цифровой трансформацией достаточно крупных компаний. Почти в каждом проекте требовалось верхнеуровневое описание, потому что проекты были разные, объем большой и команды часто обновлялись. Именно об этом я и написала: как сделать верхнеуровневое описание функциональности максимально эффективно для команды.

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

Здравствуйте! Антон Боев, исполнительный директор веб-интегратора DD Planet. В текущей статье поговорим о том, что внутри моей команды вызывает горячие дискуссии практически каждый день. Итак, речь пойдет об ИНТЕГРАЦИЯХ.

В нашей команде каждый день звучат одни и те же вопросы: «Как подключиться быстрее?», «Какую архитектуру использовать?», «Где взять устойчивое решение для этого сервиса?» Ответы на них не просто технические решения. Это опыт, который накапливается годами. И я хочу предложить вам посмотреть на него под неожиданным углом - как на криптовалюту веб-интегратора.

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

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

Способы интеграций, есть ли изменения?

Организовать взаимодействие двух сервисов можно разными способами:

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

Почему ваш ИИ-проект съедает бюджет, но не дает ROI?

Коротко: Статистика MIT неумолима: 95% ИИ-пилотов в корпорациях проваливаются. При этом бюджеты на них только растут.

Главный вывод: Дело не в технологии, а в том, ЧТО и КАК мы измеряем. Мы гонимся за точностью модели, а не за снижением издержек.

В статье я показываю, как перестать сжигать деньги и заставить ИИ работать на бизнес.

Что внутри:

Три реальных провала (банк, ритейл, производство) и их общая системная ошибка.

Семимерная модель метрик, которая смещает фокус с «технологии ради технологии» на реальный бизнес-эффект (с поправкой на российские реалии).

Готовый инструментарий руководителя: чек-лист, карта рисков, ROI-калькулятор.

Без «воды» и пустых обещаний. Только анализ, система и практика.

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

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

Она о том, как должно меняться мышление у middle-разработчика в сторону senior-разработчика. Автор в частности поясняет, что «цель этой книги — дать вам справочник для работы с новыми и legacy-проектами во фронтенде и бэкенде, а также для работы по их развертыванию». 

Автор приводит приемы senior-разработчиков, чтобы «работать скорее на уровне системы, чем отдельных строк кода» и находить оптимальные/компромиссные решения.

Стоит ли бизнесу так дорого платить за искусственный интеллект?

По данным отчета McKinsey, 78% компаний внедрили хотя бы пилотные AI-решения. Но есть нюанс: реальную ценность получают далеко не все.

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

Почему так происходит? Ответ станет очевиднее, если посмотреть на последствия первой волны энтузиазма.

Занимаясь проектированием систем ПО, идите самым простым путём из возможных.

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

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

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

Привет, Хабр! Меня зовут Роман Изотов. Последние 5 лет я провел по ту сторону баррикад – в роли IT-рекрутера, где отсмотрел более миллиона резюме и провел тысячи собеседований. Сегодня я помогаю IT-специалистам взламывать систему найма, и вот что я вижу: многие по-настоящему сильные Senior-инженеры, тимлиды, архитекторы сталкиваются с одной и той же проблемой – их резюме просто не работает.

«Мой опыт говорит сам за себя!» – Главное заблуждение.

Кажется логичным: если у тебя 7-10 лет опыта, куча проектов, сложные технологии, то резюме должно привлекать. Но в 2025 году это больше не так. Рынок перегрет, конкуренция бешеная. На одну Senior-вакансию приходят десятки, а то и сотни откликов. И вот тут в игру вступают фильтры, о которых вы могли даже не догадываться.

Фильтр №1: Автоматизированные системы отбора (ATS) – ваш первый и самый беспощадный враг.

Забудьте про креативный дизайн и инфографику. Для ATS ваше резюме – это набор ключевых слов. Если вы не используете точную лексику из описания вакансии, не указываете конкретные технологии и метрики – ваша заявка просто не дойдёт до HR. Система не поймёт, что "оптимизировал производительность" означает "сократил время отклика сервиса на 30% на пять миллионов пользователей". А если она не поймёт, то вы в корзине.

Код-ревью убивает вашу команду. И вот доказательства.

Мы измерили. Один пулл-реквест крадет у компании 2.5 рабочих дня и 1.5 часа времени senior-разработчика. 70% комментариев в ревью — бесполезные споры о пробелах и запятых. Хватит это терпеть. Читайте мой разбор, почему код-ревью в Nomium стало главным тормозом разработки и что с этим делать.

(Анонс: Привет. Собираю статистику по инженерным процессам — от enterprise до инди‑команд (форма в конце статьи). Результаты агрегирую и опубликую на хабре в ближайшее время. Анонимно, 5–10 минут. Важен каждый.)

В сети очень много информации о том, как работать в большой и многорукой команде, с кучей выделенных ролей и настроенными процессами. Да я и сам отправляю к девопсам, когда на конференции подходят и спрашивают «а как правильно сделать репликацию базы данных?», потому что они (девопсы) сделают это быстрее и правильнее почти любого бэкендера. Но кроме компаний, в которых работают тысячи инженеров и есть отдел «на любой чих», — есть компании, в которых работают три джуна и один мидл (кстати, они-то и задают этот вопрос). Я и сам когда‑то с такой компании начинал… И эта статья для них.

2025 год должен был стать годом триумфа Искусственного Интеллекта. И если смотреть на заголовки, так оно и есть: 78% организаций по всему миру заявляют, что используют ИИ хотя бы в одной бизнес-функции, а общие корпоративные инвестиции в технологию за 2024 год перевалили за $250 миллиардов. Деньги льются рекой: половина лидеров планирует удвоить бюджеты на ИИ, а средние месячные расходы компаний готовятся вырасти с $63,000 до $85,000. Кажется, что машина хайпа несется на полной скорости.

Но если присмотреться к приборам, а не к пейзажу за окном, картина становится куда интереснее. И тревожнее.

Впервые за два года непрерывного роста крупные компании (250+ сотрудников) внезапно нажали на тормоз: уровень внедрения ИИ в их производственные процессы за лето 2025-го снизился с 14% до 12%. В это же время свежий отчет MIT бьет наотмашь: 95% пилотных проектов по генеративному ИИ проваливаются, не доходя до реального использования.

Что происходит?

Добро пожаловать в эпоху "отрезвления". Период, когда эйфория от первых успехов ChatGPT сменяется жестким похмельем от столкновения с реальностью. Реальностью, в которой 42% лидеров втихую признаются, что громкие заявления их компаний об ИИ - просто раздутый хайп, а 82% людей в целом скептически относятся к технологии. Внутри корпораций назревает настоящий раскол между лагерем "скептиков", которые видят риски и провалы, и лагерем "реалистов", которые продолжают верить в технологию.

Эта статья - глубокое погружение в цифры и настроения сентября 2025-го.

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

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

В этой статье я поделюсь свежим подходом к этой проблеме — фреймворком SPACE. Он предлагает смотреть на продуктивность инженеров комплексно, по нескольким измерениям сразу. Но для начала давайте разберёмся, почему вообще так сложно измерить эффективность разработки.

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

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

«Workslop» - новая чума офисной продуктивности

Представьте: понедельник, утро. Вы открываете почту, а там - отчет от коллеги из соседнего отдела. Называется «Стратегический анализ синергии рыночных векторов на Q4». Звучит солидно. Вы открываете. Тридцать страниц, графики, красивые диаграммы, текст пестрит выражениями вроде «масштабирование инсайтов» и «кросс‑функциональное взаимодействие». Выглядит профессионально. Даже слишком.

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

Поздравляю, вы только что столкнулись с «workslop».

И если вы думаете, что это единичный случай, у меня для вас плохие новости. Это новая чума 2025 года, которая тихо, но уверенно пожирает нашу продуктивность. Исследователи из Стэнфорда и BetterUp Labs недавно взорвали инфополе своей статьей в Harvard Business Review, где привели шокирующие цифры. Оказывается, уже 40% из нас регулярно получают такой «цифровой мусор». И тратят в среднем по два часа на то, чтобы просто его разгрести и понять, что имелось в виду.

Звучит как сюжет для антиутопии? Увы, это наша новая реальность.

«Workslop»- это не просто технологическая проблема. Это симптом болезни. Болезни, имя которой - слепая вера в «магию» ИИ и прогрессирующая атрофия собственного мозга. Это новый, более изощренный вид лени, который научился очень хорошо маскироваться под продуктивность. И он угрожает не только нашим дедлайнам и бюджетам (а потери, по оценкам, достигают $9 миллионов в год на крупную компанию). Он угрожает главному - доверию внутри команд.

Эта статья - о том, как распознать эту заразу, понять, откуда она берется, и, самое главное, как с ней бороться.

Microsoft уволил 9000 разработчиков. Среди них — создатели ИИ-инструментов, которыми их же и заменили. Это не единичный случай: по всему миру программисты массово игнорируют искусственный интеллект, считая его игрушкой или угрозой. Владимир Крылов — доктор технических наук, лектор на канале Ai4Dev по применению ИИ в разработке ПО — видел рождение первых языков программирования и теперь наблюдает, как индустрия стоит на пороге радикальной трансформации. В интервью он объясняет парадокс: почему ИИ действительно замедляет работу в legacy-проектах, но при этом промпт-инжиниринг уже мертв, а на смену ему пришел контекст-инжиниринг.