В мае 1999 года еженедельная деловая газета Barron’s вышла с печально известной обложкой «Amazon.bomb». На ней лицо Джеффа Безоса было изображено на мультяшной бомбе, готовой взорваться. «Мысль о том, что генеральный директор Amazon Джефф Безос создал новую бизнес-парадигму, нелепа, — говорилось в статье. — Он всего лишь очередной посредник, и фондовый рынок начинает это понимать».
В кризис ИТ-директор не может менять процессы и внедрять автоматизацию наугад: риск потратить бюджет впустую слишком велик. Когда в планах оптимизация сервисных процессов, обычно нужен бюджет на новое решение, например ESM-платформу. При защите бюджета финдир спросит про пользу и окупаемость, и цифра эффекта должна быть проверяемой.
Дальше в статье — методика расчета эффекта: сколько времени и денег экономит автоматизация сервисных процессов. ROI и срок окупаемости эта методика не считает: они складываются из эффекта и стоимости внедрения, а стоимость внедрения ИТ-директор получает отдельно, от вендора, на этапе коммерческого предложения. Эффект — числитель в формуле окупаемости, и в статье разберём именно его.
В одном из проектов мне нужно было развивать управленческую аналитику в крупной образовательной организации. Данные уже были: учебные процессы, финансовые показатели, поступления и другие направления хранились во внутренних системах. Руководству требовались не очередные Excel-файлы, а единый BI-контур с дашбордами, детализацией и регулярным обновлением.
На тот момент я уже работал с Power BI и DataLens, а рабочую версию управленческой аналитики мы развернули на сервере в Visiology. Прототип показали руководству и получили согласование на дальнейшее развитие. То есть на уровне первой демонстрации всё получилось: данные загрузились, дашборды открылись, показатели можно было обсуждать уже не на словах.
Если смотреть только на этот момент, систему можно считать выбранной успешно.
Ретро умирают одинаково: жалобная книга вместо разговора, сорок минут на один спор, экшен-айтемы в никуда. Разбираю тайминг на 45 минут, четыре формата (Start Stop Continue, Mad Sad Glad, 4L, Sailboat) — что писать в каждую колонку и когда какой брать, — и правила, которые держат ретро живым. Во второй части — как устроена моя бесплатная доска для ретро: стек, где хостится, шифрование карточек и что происходит с данными.
Привет! Меня зовут Анастасия и я проектный менеджер и scrum-мастер в Окко. Проектным менеджментом я занимаюсь около семи лет: успела поработать с hardware проектами, CRM-системами, мобильной разработкой, ритейлом.
За последние два года я провела больше ста ретроспектив. Внутри одной команды, между несколькими командами, иногда — в роли приглашенного фасилитатора. В какой-то момент поняла, что ретроспективы научили меня гораздо большему, чем просто опыт фасилитатора встреч — я начала иначе смотреть на саму работу менеджера.
Раньше мой фокус был классическим: есть проект, сроки, задачи, зависимости и риски. Если что-то пошло не так, нужно понять причину отклонения, перестроить план и вернуть проект в нужную точку. Работа скрам-мастером добавила к этому другой вопрос: почему проблема вообще возникла и почему она возвращается? Разница кажется небольшой, но именно она постепенно перевела мой фокус с управления отдельными задачами на устройство системы, в которой команда эти задачи выполняет.
В этой статье расскажу, что изменилось в моей работе после появления роли Scrum Master, что оказалось самым неожиданным открытием и почему из всех Scrum-ритуалов именно ретроспектива стала самым ценным инструментом?
Во время выпуска стали из конвертера в сталеразливочный ковш температура — 1600–1650°C. В зоне слива жара такая, что металл светится ярко-белым, и любое незащищённое оборудование обгорает мгновенно. Первые попытки сделать систему визуализации контроля наполнения стальковша в прямом смысле сгорели. А задача внести присадки ферросплавов вовремя, чтобы получить нужную марку стали, — никуда не делась.
Нам пришлось делать новую систему, которая бы справлялась с реальными температурами конвертерного цеха. Несгораемую систему. Которая должна была учитывать, как именно идёт выпуск стали.
Если коротко: сначала в конвертер загружают лом, заливают чугун и продувают его кислородом — так снижают содержание углерода и убирают примеси вроде фосфора и кремния. Затем полученный расплав переливают в ковш и добавляют ферросплавы, чтобы довести состав до нужной марки стали. Это по технологической схеме — в идеальных условиях.
В реальных условиях вносить все присадки разом — рискованно. Они могут сплавиться, покрыться шлаковой коркой и всплыть массивом. Когда корка разрушится и пойдут газы, расплав начнёт бурлить. В такой момент возможно выплёскивание металла из ковша. А рядом — люди и оборудование.
Вы знаете, что игры бывают очень архитектурно «грязными» внутри? Но это не помешало им продаваться миллионами копий, или быть написаннами одним человеком на фреймворке для браузерок, или на Lua поверх библиотеки для геймджемов, или вообще ребенком в бесплатной версии юнити. При этом мощный кастомный движок с ECS, job‑системой, своим рендером и рефлексией повсюду вы тоже знаете, но игра на нем, скорее всего лежит третий год у вас в беклоге, так и не сыграная даже пару часов.
Попросили меня по старой дружбе, где‑то с полгода назад, помочь с разработкой и выводом игры в Steam. Ребята до этого занимались нефтью, и накопив деньжат, решили, что называется оставить след в индустрии. Если честно, я несколько отвык от такого «детского» кода и простых решений, что меня несколько удивило, хотя и вернуло на грешную землю из объятий ентрепрайза. Но я сразу оговорюсь, что простая архитектура это не оправдание плохого кода, а способ выбрать, где именно вы позволяете себе быть сложным. Бюджет сложности конечен... прежде всего размером вашей натуральной оперативкой, и тратить его надо туда, где игрок это увидит.
Проект может сорваться, даже если в команде нет слабых сотрудников. Проблема часто скрывается между ролями. Как обнаружить дефицит компетенций до старта?
“Облачный блокнот” выглядит как ваши файлы. Но это запись в чужой базе: её можно закрыть, выгрузить с потерями или скормить модели без уведомления. Это как золотая клетка с прозрачными стенами: всё видно, кажется своим, выйти нельзя. Есть проверка на тридцать секунд — почти никто её не проходит.
Miro продали в 13 раз дешевле оценки 2021 года, и я пошёл считать, что вышло из нашей попытки уйти от подписок. За год мы заменили Tilda, Confluence, Jira и Slack своим кодом, целей было две: экономия и гибкость. Экономии не получилось: по полной ставке сеньора и с учётом владения первый год ушёл в минус около 2 млн. Гибкость, кажется, получилась, и выяснилось, что трекер до рабочего состояния доводит не разработчик, а скрам-мастер. В статье цифры по четырём заменам, инцидент с уязвимостью в авторизации, который заставил поставить ревью второй нейронкой, и критерий из трёх вопросов, что переписывать не стоит.
31 августа прод моего приложения пролежал около часа.
Причина была обидно простой. Агент добавил в коммит все файлы из общей рабочей папки, вместе с чужой недоделанной работой. Потом сделал это еще раз. Во второй раз уже после того, как сам записал в правила, что так делать нельзя.
Дальше он начал чинить. Ошибка, правка, следующая ошибка, еще правка. Каждая починка тянула за собой новую поломку. Я посмотрел на это и написал: «верни просто старую версию» То есть откатись к последнему состоянию, про которое точно известно, что оно работало.
И тут поймал себя на странном ощущении. Я только что провел разбор инцидента. Ровно так, как годами делал это на работе с живыми командами. Мысль, которая крутилась у меня с июня, в тот вечер наконец сложилась: я не пишу приложение с ИИ. Я управляю департаментом.
Почти три года назад, когда я начал митапы Verilog Mettup в Hacker Dojo, на них пришел Владимир Чурюкин и когда посмотрел на мою инфраструктуру Basic‑Graphics‑Music, где баш‑скрипты по имени платы строят проект, сразу сказал «А давайте перепишем все на питон». И переписал! С оговоркой что это PoC, то бишь Proof of Concept, то есть он это проверил только на 5-ти платах, а не на всех 45-ти, как мой исходный репозиторий.
А теперь посмотрим, что из этого получилось.
Я больше десяти лет делаю рекламные платформы. Команды за это время были разные — по размеру, по составу, по зрелости. Но почти всегда был один загон — всем почему‑то было очень важно работать по спринтам.
Не обязательно называть это скрамом, хотя обычно называли. Важна была именно двухнедельная итерация как фундамент вокруг чего строится планирование (или то, что им кажется), отчетность и разговор со стейкхолдерами.
На последней фразе заказчик улыбнулся. Автоматика системы «Умный Дом» в доме ему была нужна, но облака, голосовые помощники и удалённое управление доверия не вызывали. От нас он хотел понять, есть ли у домашнего оборудования путь к его личным устройствам.
В проекте были проводная шина, IP-шлюз и локальный сервер визуализации. Управление с личного телефона обсуждалось, но заказчик согласился на отдельный планшет. Для автоматики мы предусмотрели локальную работу без постоянного выхода в интернет и соединений с личной сетью.
Недавно OpenAI выпустила GPT-6 Astra. Новая модель стала лучше работать с длинными и сложными задачами, большим контекстом, файлами и инструментами. Для меня это интересный релиз ещё и потому, что AI я в основном использую не для написания кода. Я PM, поэтому мои основные задачи это требования, Jira, документы, анализ информации, планирование и подготовка материалов. Появление более мощных инструментов отлично экономит время, но не отменяет базовой логики: распределять ресурсы с умом и контролировать точки отказа. В этой статье делюсь личным опытом: как построить удобный loop взаимодействия с AI, почему Astra нужна далеко не всегда и какие проблемы процессов не решит даже самый продвинутый алгоритм.
В предыдущей статье мы разобрали пятое базовое понятие BABOK — Контекст (Context). Мы выяснили, что контекст — это не фоновое знание, а структурированный анализ среды, который определяет границы возможного решения.
Теперь цепочка почти замкнута: мы нашли нужных людей (Stakeholders), поняли что им нужно (Needs), спроектировали переход (Change), выбрали решение (Solution) и убедились, что оно жизнеспособно в данной среде (Context). Остаётся один — финальный и, пожалуй, самый честный — вопрос:
А зачем всё это было нужно? И как мы поймём, что оно сработало?
Именно на него отвечает шестое и последнее базовое понятие BABOK — Ценность (Value). Оно завершает цепочку. Разберём, что такое ценность в понимании BABOK и почему без её измерения работа аналитика технически никогда не завершена.
Кажется, что при создании сложных инженерных систем разработка создает технологию, а продукт упаковывает ее для заказчика. У каждой команды своя зона ответственности. На самом деле всё не так просто.
Мы в «Фалькон Тех» уже 9 лет разрабатываем цифровые решения для умного города на основе видеоаналитики и машинного зрения. В статье рассказываем, почему продукт и разработка должны работать в связке, а не передавать друг другу задачи по цепочке.
Почему одни технически сложные проекты доходят до рабочего результата, а другие годами сжигают бюджеты и остаются на бумаге? История Разностной машины Бэббиджа — почти современный кейс про разрастание требований, инженерный перфекционизм и цену решений, которые слишком долго откладывают финальную сборку.
Привет, Хабр! Допустим, вы внедрили LLM-агента в финансовый отдел компании. Все хорошо, пока вы не решаете его подправить: добавить инструкцию или сделать тон дружелюбнее. С точки зрения классического инфобеза вам нужно все перевалидировать.
Личность вашего агента (инструкции, тон, самопрезентации и так далее) живет в одном доверительном домене с действиями агента. Если домен строгий, каждое изменение придется сертифицировать. Если же домен разрешительный, аудит только фиксирует действия в логах, но ничего не блокирует.
Проблема в том, что некоторые домены обязаны быть строгими. А некоторые из строгих надо менять так часто, что постоянно перевалидировать неудобно.
В этом материале расскажу подходе PES (Persona–Execution Separation), отделяющем «личность» виртуального агента от задач.
Фича популярна у самых ценных клиентов и связана с высоким удержанием — но достаточно ли этого, чтобы сделать её основой продукта? Разбираем, почему корреляция в метриках может вводить в заблуждение, какие данные нужны для проверки гипотезы и как принимать продуктовые решения на основе экспериментов.
