Когда таск-трекер внезапно уходит с рынка, процессы не нажимают на паузу. Команда по-прежнему должна держать в порядке задачи, сроки и коммуникацию — особенно если работа идет в высоком темпе. В этот момент перед бизнесом встает болезненный вопрос: чем заменить систему, которая была встроена в ежедневные процессы?
Есть проекты, которые с первого дня пахнут успехом. А есть те, от которых веет таким могильным холодом, что хочется завернуться в плед, удалить мессенджеры и переехать в деревню без интернета. Проблема в том, что часто мы слишком поздно замечаем запах горелого кода и безнадёжных дедлайнов.
Живой пример
Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную, и занимался этим не один-два человека, а аж целый отдел. Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.
Мы привыкли думать, что архитектура программ рождается из требований бизнеса, бюджетов и технологий. Но в самом начале любого проекта лежит архитектура мышления — разработчика, заказчика, пользователя. Эта статья и ряд других в серии «каскад» — попытка рассмотреть проектирование как отражение когнитивных механизмов человека. Не UX, не поведение пользователей, а именно то, как фазы нашего мышления формируют будущую систему. И главное — как, поняв это, создавать более устойчивые и человечные архитектуры.
Мода на то «вкат» в IT появилась задолго до пандемии и массового распространения удаленного формата работы. Я помню пасты на двачах и мемы про «300кк/наносек синьора-помидора» в 2016-2017 годах - уже тогда многие стремились попасть в эту сферу из-за высоких зарплат и относительно низкого порога входа. После распространения удалёнки, хайп вокруг вката вырос многократно: появилось ещё больше желающих работать, лёжа на шезлонге где-нибудь на Бали с ноутбуком на коленках и с коктейлем в руках.
На фоне стремления огромного числа людей вытянуть свой счастливый билет в сказочный мир больших зарплат, удалённой работы, гибкого рабочего графика и достаточно низкой ответственности за результаты работы по сравнению с другими профессиями, начал набирать популярность феномен накрутки опыта, который подавался как эффективный способ вкатиться сразу на высокую зарплату на должность миддла и выше, минуя низкооплачиваемые (а иногда вообще не оплачиваемые) стажировки и джуновские позиции.
Логика простая: в IT-сфере профильный диплом не нужен, опыт из резюме почти никогда не просят подтвердить официальными документами. Зачем в таком случае тратить годы на учёбу в профильном ВУЗе и самообучение, начиная свой карьерный путь с позиции стажёра, если можно продумать легенду (или попросить кого-нибудь с реальным опытом выдумать её для вас), поставить в резюме 3+ года опыта, потратить на подготовку максимум год (а с ментором – раза в два меньше), походить по собесам, получить оффер и сразу начать «рубить бабло»? Так делали многие, и у многих получалось.
Всем привет!
Я недавно закончил подготовку курса по управлению проектами на основе 8-го издания PMBoK и у меня появилось время поделиться здесь своими мыслями по поводу особенностей управления проектами с разных точек зрения и в разных отраслях.
Сегодняшний пост будет, в основном, посвящен обзору PMBoK 8, его ключевым особенностям и отличиям от предыдущих изданий. На всякий случай, если кто вдруг не в курсе, PMBoK, также известный как Project Management Body of Knowledge или Свод Знаний по Управлению Проектами – это основной руководящий документ сообщества PMI (Project Management Institute https://www.pmi.org/). С момента своего появления в 1996 году, PMBoK пережил несколько переизданий, часть из которых оставили большой след в области управления проектами и в профессиональной жизни многих руководителей проектов.
Особняком стоит 7-е издание, на данный момент – предпоследнее, которое тоже сильно повлияло на отрасль и участников, но этот след справедливее было бы назвать травмой. Несмотря на наличие большого количества передовых идей и внедрение новых подходов, 7-е издание оказалось воспринято сообществом неоднозначно и скорее даже с негативом. Уж слишком радикальными и, что самое главное, не всегда релевантными и практически применимыми оказались нововведения. Да и в целом, документ производит впечатление какого-то компромиссного недоразумения, в котором собрали новые концепции, скопипастили определения и целые разделы из предыдущих изданий, но местами просто не проверили соответствие одного другому.
OpenAI 5 месяцев строили продукт без единой строчки ручного кода — миллион строк, 1500 PR, 7 инженеров. Разбираю их подход «harness engineering» и что из этого можно применить уже сейчас: как организовать AGENTS.md, почему скучные технологии побеждают, и зачем нужна архитектура с первого дня.
Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет).
На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate.
В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта.
И главное — помогаем находить уязвимости на ранних этапах. Объясняем их суть на понятном языке, проверяем эксплуатируемость, придумываем меры митигации и составляем план по устранению — причем не где-то там в своих кабинетах, а вместе с командой при планировании работы на спринт или квартал.
Звучит неправдоподобно? Из-за образа безопасников-церберов, который складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!
2026 год закрыл вопрос «а вдруг всё вернётся». Не вернулось — и рынок успел повзрослеть.
Если пару лет назад компании в панике мигрировали из Jira и искали временные замены, то сегодня задачи другие. Бизнесу нужны не «костыли», а инструменты, которые ускоряют Time-to-Market, дают прозрачность ресурсов и связывают разработку с финансовым результатом.
Главный вызов теперь — не нехватка решений, а их избыток. На рынке десятки систем: от лёгких планеров до тяжёлых Enterprise-платформ. Маркетинга много. Осознанного выбора — меньше.
В этой статье разберём 10 ключевых игроков российского рынка управления ИТ-проектами и попробуем отделить реальную процессную зрелость от красивых дашбордов.
«На автотесты нет времени — релиз через неделю!» говорит зарубежная компания со штатом 500+ человек, зарплатами 5 000 €, баг-репортами по ISO. Разбираю, откуда берётся эта фраза, почему разработчики не могут объяснить бизнесу очевидное.
Сегодня утром я прошёл лайв-кодинг в одну англо-продуктовую компанию. Написал ноль строчек кода руками. Задеплоил результат на свою VPS прямо во время звонка. Интервьюер сказал: "It's so wonderful just how much everything has changed." А неделю назад другая компания не зачла мне тестовое, потому что я забыл про запрет AI.
20+ собесов за последние месяцы. Фронтенд, бэкенд, фулстек, AI-инженер. Python, TypeScript. Разные рынки, разные компании, совершенно разное отношение к одному и тому же инструменту. Я не теоретик, который рассуждает о будущем. Я прямо сейчас хожу на эти собесы и вижу, как рынок разламывается пополам.
В советское время в каждом ресторане и крупном кафе выступали полноценные ансамбли: гитаристы, барабанщик, клавишник, духовая секция и певица. Содержание такого коллектива стоило дорого, а их синхронная игра требовала долгих репетиций. С появлением мощных синтезаторов надобность в огромных ансамблях отпала: оказалось, что для качественного звука достаточно дуэта — клавишника за пультом и солиста.
Сегодня мы видим то же самое на рынке развлечений: корпорации с неограниченными бюджетами по инерции заказывают живые ансамбли. Кто считает деньги — нанимает дуэты. Кто хочет максимальной рентабельности — зовет диджея. А в авангарде уже выступает ИИ, который сам генерирует музыку и вокал, оставляя человеку лишь роль слушателя или заказчика настроения.
В Enterprise-разработке программного обеспечения прямо сейчас происходит точно такой же тектонический сдвиг, финал которого изменит не просто ИТ-индустрию, а само мироустройство.
Работая в крупном финтехе и пройдя путь от разработчика и техлида до руководителя направления разработки (управляя пятью командами) и ведущего архитектора решений, становится очевиден один факт: классическая кросс-функциональная Agile-команда из 7-8 человек необратимо теряет свою экономическую эффективность. Изменилась сама природа создания систем.
Я год наблюдал, как в нашей команде junior и middle разработчики почти полностью пересели на автогенерацию кода. Сначала это выглядело как ускорение. Через несколько месяцев начали всплывать странные эффекты: деградация архитектурного мышления, рост скрытого техдолга и зависимость от подсказок. В этой статье — не морализаторство, а практические наблюдения, конкретные примеры кода и вопросы, которые мне самому пришлось себе задать.
Полгода назад я понял, что мы проигрываем не конкурентам и не техдолгу. Мы проигрываем времени суток. В этой статье — мой практический разбор того, как я замерял хронотипы команды, собирал телеметрию активности, анализировал коммиты и встречи, строил простенькую модель продуктивности и в итоге полностью перестроил рабочий график удалённой команды. Будет немного биологии, немного математики, немного кода и много личных факапов.
Разработка любого ИТ-продукта, если она ведётся осознанно и целенаправленно, а не спонтанно и хаотически, требует чёткой постановки задачи – что должно быть получено в результате. Соответственно, необходимо описание требований к создаваемому продукту, которое и принято называть «ТЗ» – Техническим заданием.
Необходимость разработки формального документа со спецификацией требований, когда продукт делается не собственными силами для собственного потребления, а выделяются заказчик и исполнитель, очевидна. Особенно, если речь идёт о достаточно сложном продукте, не являющимся типовым решением.
Однако, возникает логичный вопрос – ДЛЯ КОГО должно быть написано ТЗ.
Из этого уже вытечет следующий вопрос – ЧТО должно быть включено в ТЗ, т.е. какие требования составляют спецификацию (как, собственно, в иностранных языках ТЗ обычно и называется – «спецификация требований»).
Конечно, можно (и, в большинстве случаев, нужно) использовать существующие стандарты – например, отечественные ГОСТ 19.201 для программы и ГОСТ Р 34.602 для автоматизированной системы. Есть и другие стандарты, которые достаточно хорошо описывают структуру и содержания таких документов. Но увы, в большинстве случаев эти стандарты описывают спецификации «внешних» требований заказчика к целевому продукту (что, в сущности, верно), т.е. продукт рассматривается как «чёрный ящик», который что-то и как-то делает, и вот эти «что-то» и «как-то» в их внешнем проявлении в ТЗ как спецификации требований и описываются. А вот вопрос о том, может ли быть ТЗ «для разработчика», остаётся открытым.
Уже вечер, ты активно пишешь код. Тревожность вместе с тобой. Утром на дейли сказал, что добьёшь таску: да она не сложная, каких‑то 2 стори поинта. Но вот вечер, и ты точно не успеваешь. Завтра на дейли спросят статус задачи, а ты — не сделал. Да, ты общался с архитектором по решению, отвечал на вопросы поддержки и помогал решать проблемы с тестовым окружением. Ещё был синк с другой командой, помог решить проблему с локальным окружением другому разработчику и готовил контракт для фронта для будущей таски. И на обед ты не сходил. Но кого это заботит, если твоя задача все ещё в InDev? Точно придётся посидеть ещё пару часов ночью, чтобы закрыть должок.
Или другой вариант. Ты — менеджер. У тебя за день от 5–6 встреч. Всё нужно решить. Ну и текучка не отпускает: нужно решить конфликт в команде «А», есть запрос на согласование обучения для Иванова, нужно ещё согласовать технические работы и выдать пару доступов. А ещё Сергей из команды «B» недостаточно открыто ответил на вопрос своего коллеги, и тут просят твоего внимания. И, кстати, ещё нужно запланировать изменение процесса и предложить расчёт новой метрики.
Знакомо?
Тогда тебе точно нужен курс по time management ряд привычек, которые каждый может внедрить в свою работу.
Мы привыкли думать, что главным узким местом ИТ-разработки является capacity — количество рук, способных перевести бизнес-требования в рабочий код. Долгие годы индустрия строила "фабрики фич" и масштабировала пирамиду разработчиков. Но генеративный ИИ сломал эту физику.
Сегодня производство артефакта (кода, лендинга, дизайна) стремится к нулю по стоимости. Кодинг перестает быть рычагом конкуренции: он коммодитизируется и больше не ограничивает ни рынок, ни организацию. Объем кода и скорость коммитов превращаются в шум — они больше не коррелируют с ценностью продукта.
Если код стал дешевым, куда сместился дефицит? И почему ИИ, способный написать любую систему, никогда не станет в ней полноценным CEO?
За последний год писать код действительно стало быстрее.
AI‑ассистенты помогают разработчикам, генерируют функции, пишут тесты и иногда собирают почти готовые фичи.
Но есть странный эффект: скорость написания кода выросла, а скорость развития продукта — почти нет.
Эта история — о том, почему так происходит, если смотреть на разработку глазами продакт‑менеджера.
Дисклеймер: история вымышленная. Все совпадения случайны. Хотя местами — подозрительно точны.
Как вы считаете, что хуже – падение всего сервиса на сутки, или крошечный баг, слегка портящий пользовательский опыт месяцами?
В СМИ всегда попадают именно масштабные инциденты. Да и в поддержку пользователи пишут только тогда, когда что-то совсем не работает.
Раньше и я боялся больших инцидентов. Но как только мы сделали большой и сложный сервис, я понял, что бояться надо другого.
Облако по природе своей устроено так, что деньги из него утекают как песок сквозь пальцы. Не потому что провайдеры жадные или инженеры попались безответственные. Всему виной органический рост: тут один сервис поднял новый кластер, здесь команда не выключила стейджинг после релиза, там забыли про снапшот двухлетней давности. По отдельности каждый из этих факапов – вроде не катастрофа. Но в конце месяца счета неизменно напоминают о том, что думать так — большое заблуждение. В прошлых материалах цикла мы уже разбирали типичные боли тех, кто работает с облаками, и рассматривали, почему счета растут, хотя инфраструктура не меняется. А сегодня поговорим про первый и самый важный методологии FinOps, которая должна решить эти проблемы: Inform.
Практики FinOps в Telegram| Бот
Почему начинать с оптимизации — плохая идея
Первая мысль, которая появляется, когда счет за облако в очередной раз оказывается процентов на 40 выше запланированного, — взять и что-нибудь урезать. Неважно что. Лишь бы сократить расходы. Ну, оно вроде и логично. Режем лишнее – оставляем нужное – сокращаем траты.
Вот только вся проблема в том, что без понимания структуры затрат такая оптимизация — это что угодно, только не она. Потому что так можно запросто угробить десяток-другой человекочасов на тюнинг компонента, который дает 2% от общего счета, и не заметить, что 60% уходит на базы данных, про которые никто не вспоминал с момента основания компании. Или, скажем, прибить сервис, который выглядел как заброшенный, но на самом деле держал чей-то продакшн. И ходи потом доказывай, что не верблюд.
Мы подошли к финальной стадии производства Информационной системы (ИС).
Очень важно осознавать, что успешным итогом всего производства ИС является не сам по себе произведенный ИТ-продукт, а внедренное на предприятии решение, которое приносит реальную пользу, в соответствии с установленными на проект показателями.
Как и для предыдущих стадий, определим вызовы и цели, с которыми мы подошли к этапу:
