Управление проектами *

Как одна журнальная статья, написанная 70 лет назад, поменяла всю инвестиционную индустрию и принесла ее автору Нобелевскую премию.

В одном из последних интервью ее автор вспоминал: «Когда люди восторгаются моей Нобелевской премией, я люблю говорить им, что Нобелевская премия не была моей самой большой наградой. Моя самая большая награда была вручена мне в мужском туалете большого отеля в Вашингтоне, округ Колумбия, после ужина, где-то между Рождеством и Новым годом 1990 года»...

Представим ситуацию.

Маркетолог работает в крупной компании с собственной A/B-платформой. Каждый квартал он должен запускать несколько новых маркетинговых кампаний, и подтверждать их эффективность с помощью экспериментов. Ресурса аналитика всегда не хватает на подобные задачи. А A/B-платформа позиционируются как инструмент, доступный в том числе маркетологам и проектным менеджерам. В итоге, наш герой решает запустить эксперимент самостоятельно.

Гипотеза. «Новый лендинг увеличивает среднюю выручку на пользователя (ARPU) в выбранном сегменте».

Спустя несколько недель маркетолог открывает AB-платформу, чтобы подвести итоги эксперимента. Видит, что пользователи распределены по группам примерно равное: 9 936 в тесте и 10 068 в контроле. Результат радует глаз: effect = 18.28%. "Какой эффект! Вот только чувствительности для "прокраса" немного не хватило", - думает он, - "глядя на p-value = 0.1179".

Но можно ли принимать решения на основе этих данных? Давайте разберемся, проведя анализ вероятных искажений.

Статья для PM и тимлидов, которые работают в арт‑аутсорсе или других креативных командах с высокой вариативностью задач.

Я разбираю систему из четырёх метрик — estimation accuracy, task complexity, variability и volatility — которая помогает видеть устойчивость проекта, прогнозировать перегрев и принимать управленческие решения без усиления контроля над командой.

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

Привет всем! Я — Майя, контент-менеджер, опять к вам с очередным обзором.
Если открываете календарь на iPhone и всё равно что-то забываете — вам сюда.

В этой статье разберу 12 календарей для iOS — простые бесплатные и «комбайны» с задачами.​

Этот обзор для тех, кому нужен удобный календарь для планирования на айфон: учёба, работа, созвоны, дедлайны, семейные дела.

В конце — таблица сравнения, чтобы не перечитывать весь обзор, если времени нет. И вопрос, чтобы понять, кто чем пользуется и почему.

Notion запустила кастомных AI-агентов, которые сами работают по расписанию и триггерам, а за этим релизом скрывается куда более важный сдвиг. Похоже, мы входим в этап, где ИИ перестает быть просто чатом по запросу и превращается в постоянного цифрового исполнителя, который работает в фоне 24/7.

Разбираю, что именно показал релиз Notion, при чем тут Ramp, Remote, OpenClaw и Kimi Claw, и почему все это может быть началом новой гонки агентов.

2026 год закрыл вопрос «а вдруг всё вернётся». Не вернулось — и рынок успел повзрослеть.

Если пару лет назад компании в панике мигрировали из Jira и искали временные замены, то сегодня задачи другие. Бизнесу нужны не «костыли», а инструменты, которые ускоряют Time-to-Market, дают прозрачность ресурсов и связывают разработку с финансовым результатом.

Главный вызов теперь — не нехватка решений, а их избыток. На рынке десятки систем: от лёгких планеров до тяжёлых Enterprise-платформ. Маркетинга много. Осознанного выбора — меньше.

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

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

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

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

Корпоративный мир ушёл далеко вперёд. Если 10 лет назад сотрудники выходили на работу, чтобы создавать продукты «с нуля», то сегодня конъюнктура изменилась. IT-ландшафт крупных компаний перенасыщен решениями на любой вкус. На смену классическому проектному управлению, ориентированному на создание чего-то нового, пришло управление продуктами, где гибкие методологии работают на развитие и стабилизацию уже существующих систем.

Но любой продукт когда-то был просто идеей. Поэтому давайте договоримся о терминах: в этой статье проект — это нулевая ступень, фундамент, с которого начинается жизненный путь любого продукта. Расскажу об этом подробнее на примере из личной практики.

Команда «Нанософт» создала информационную модель исторического здания торговых рядов на Красногорской площади в Сергиевом Посаде Московской области. Здание, построенное в 1902–1903 годах по проекту А. А. Латкова в русском стиле, в 1920 году пережило пожар, а в 2014-м было полностью отреставрировано к 700-летию Сергия Радонежского.

На примере этой модели мы показываем, как создавать и настраивать пользовательские проемы в nanoCAD BIM Строительство – от базовых до более сложных методов.

Кому это будет полезно?

Архитекторам, конструкторам, руководителям проектов, студентам и всем, кто работает с nanoCAD BIM Строительство или изучает его, – для быстрого освоения программного продукта и решения реальных практических задач.

Сегодня в рубрике — китайский бизнес, который выбрал мировые стандарты. И философию, за которую не страшно получить оплеуху от консервативных топ-менеджеров. Ее автор — Ли Цзянь, основатель и председатель совета директоров Action Education, одной из ведущих тренинговых компаний Китая. Если вы следите за нашими материалами про организационное развитие и корпоративную культуру (а мы к этому постоянно возвращаемся), то этот эксперт вам зайдет.

Немного контекста. Когда в 2014 году компания Ли Цзяня установила себе планку «стать бизнес-школой мирового уровня», это звучало как шутка для своих. Рынок тренингов в Китае — поле боя без правил, конкуренция дикая, а продукт не тот случай, когда можно пощупать качество до оплаты. Но цифры говорят сами за себя: чистая прибыль 16,8 млн юаней в 2014-м, 38 млн в 2015-м, 68 млн в 2016-м, и за сотню в 2017-м. При этом 560 сотрудников делают выручку в полмиллиарда юаней. Даже в ковидном 2020-м, когда индустрию тренингов штормило так, что многих сдуло, Action Education умудрилась вырасти. Автор пишет об этом как о лабораторном подтверждении теории: работает.

«На автотесты нет времени — релиз через неделю!» говорит зарубежная компания со штатом 500+ человек, зарплатами 5 000 €, баг-репортами по ISO. Разбираю, откуда берётся эта фраза, почему разработчики не могут объяснить бизнесу очевидное.

Разработка любого ИТ-продукта, если она ведётся осознанно и целенаправленно, а не спонтанно и хаотически, требует чёткой постановки задачи – что должно быть получено в результате. Соответственно, необходимо описание требований к создаваемому продукту, которое и принято называть «ТЗ» – Техническим заданием.

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

Однако, возникает логичный вопрос – ДЛЯ КОГО должно быть написано ТЗ.

Из этого уже вытечет следующий вопрос – ЧТО должно быть включено в ТЗ, т.е. какие требования составляют спецификацию (как, собственно, в иностранных языках ТЗ обычно и называется – «спецификация требований»).

Конечно, можно (и, в большинстве случаев, нужно) использовать существующие стандарты – например, отечественные ГОСТ 19.201 для программы и ГОСТ Р 34.602 для автоматизированной системы. Есть и другие стандарты, которые достаточно хорошо описывают структуру и содержания таких документов. Но увы, в большинстве случаев эти стандарты описывают спецификации «внешних» требований заказчика к целевому продукту (что, в сущности, верно), т.е. продукт рассматривается как «чёрный ящик», который что-то и как-то делает, и вот эти «что-то» и «как-то» в их внешнем проявлении в ТЗ как спецификации требований и описываются. А вот вопрос о том, может ли быть ТЗ «для разработчика», остаётся открытым.

Уже вечер, ты активно пишешь код. Тревожность вместе с тобой. Утром на дейли сказал, что добьёшь таску: да она не сложная, каких‑то 2 стори поинта. Но вот вечер, и ты точно не успеваешь. Завтра на дейли спросят статус задачи, а ты — не сделал. Да, ты общался с архитектором по решению, отвечал на вопросы поддержки и помогал решать проблемы с тестовым окружением. Ещё был синк с другой командой, помог решить проблему с локальным окружением другому разработчику и готовил контракт для фронта для будущей таски. И на обед ты не сходил. Но кого это заботит, если твоя задача все ещё в InDev? Точно придётся посидеть ещё пару часов ночью, чтобы закрыть должок.

Или другой вариант. Ты — менеджер. У тебя за день от 5–6 встреч. Всё нужно решить. Ну и текучка не отпускает: нужно решить конфликт в команде «А», есть запрос на согласование обучения для Иванова, нужно ещё согласовать технические работы и выдать пару доступов. А ещё Сергей из команды «B» недостаточно открыто ответил на вопрос своего коллеги, и тут просят твоего внимания. И, кстати, ещё нужно запланировать изменение процесса и предложить расчёт новой метрики.

Знакомо?

Тогда тебе точно нужен курс по time management ряд привычек, которые каждый может внедрить в свою работу.

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

Всем привет, меня зовут Гай, и я консультант, помогающий компаниям разрабатывать стратегию компании. Я помогал с разработкой стратегии в десятках отечественных ИТ-компаний, в том числе и в драгоценной для нас с вами компании Хабр я помогал четыре года.

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

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

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

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

На самом деле кризис сегодня – это почти нормальное состояние бизнеса. Все быстро меняется и приходится быстро перестраивать бизнес или операционную модель, потому что то, что работало раньше, больше не работает. Нужно быстро реализовывать важные проекты и трансформации, чтобы бизнес выжил – за несколько месяцев, а не несколько лет. Потому что в условиях турбулентности и кризиса – время играет против нас. И кто успел быстро перестроиться, тот и выиграл. А кто управляет изменениями по старым правилам, работающим в «мирное время», и отрицает реальность – идет ко дну.

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

Из каких пяти элементов она состоит – рассказываю в этой статье.

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

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

В СМИ всегда попадают именно масштабные инциденты. Да и в поддержку пользователи пишут только тогда, когда что-то совсем не работает.

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

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

В ИТ среде финтех компаний давно не редкость услышать: «мы перешли на стримы». Но за этим модным словом скрывается не просто перестановка людей по полочкам. Это попытка совместить несовместимое: скорость стартапа, надёжность инфраструктуры и строгость регулятора. И в эпицентре этого сложного баланса — ИТ лидер команды. Он не Scrum Master, не техлид и не просто менеджер проекта. Он — операционный центр кросс функциональной команды. Тот, кто превращает бизнес идею в рабочий продукт, а хаос требований — в стабильный поток доставки.

Расскажу, как это работает изнутри, на примере реальных процессов в крупной российской финтех компании, где стримы — не «buzzword», а повседневная реальность.

За 15 лет в разработке и анализе производительности 1С я понял одну простую, но неприятную вещь: когда высоконагруженная система начинает тупить, мы инстинктивно виним платформу, железо или СУБД. Но в реальности, даже на тяжёлых бэкендах с тысячами пользователей, узкое горлышко — это почти всегда наш собственный код.

Сегодня я расскажу, как мы построили систему мониторинга своими руками, сэкономили 20% на железе (которого у нас, к слову, не «терабайты и сотни ядер», а вполне вменяемые конфигурации) и почему стандартный APDEX может нагло врать вам в лицо.

• Платформа 1С 8.3.24.

• СУБД Postgres Pro.

• Больше 40 серверов 1С в разных контурах (внутренний для сотрудников, внешний для поставщиков).

• В пике — более 4000 пользователей. Ежечасно (!) крутятся тысячи фоновых заданий и сотни интеграционных сценариев.

Представьте: вы засыпаете песок в сувенирную банку так, чтобы получился красивый узор. А теперь увеличьте эту банку до размеров десятиэтажки объёмом кубометров этак на 3200, а специи замените на кокс, агломерат, окатыши и руду. Надо их засыпать в доменную печь так, чтобы слоистый рисунок внутри не просто красиво ложился, а обеспечивал жизнь целой системе. Чтобы газовоздушная смесь проходила, материалы не перемешивались как попало, а стенки-холодильники не прогорели.

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

Доменная печь — это сердце металлургии. По словам наших технологов, это гигантский «живой» организм, который превращает оксиды железа в чугун при температурах выше 1500 °C. Но работает он как минимум при одном критически важном условии — если внутри всё лежит «как надо».

Кокс должен быть пористым, газопроницаемым, чтобы через него проходил восстановительный газ, который так и норовит забрать кислород у оксидов. Железорудное сырьё (агломерат, окатыши, брикеты, руда и прочее) должно распределиться так, чтобы не забить эти каналы. Представьте себе лёгкие, где бронхи забиты аллергенами, пылевыми частицами: дыхание становится невозможным. То же самое происходит с доменной печью… Наверное поэтому профессионалов-доменщиков иногда называют «докторами»: они умеют «лечить».

Ошибётесь с укладкой шихты — и печь просто перестанет «дышать». Цена такой ошибки в её апофеозе — не просто несоблюдение графика производства, а сокращение нескольких лет кампании печи, которая обычно составляет 10–15 лет.