惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

有赞技术团队
有赞技术团队
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
IT之家
IT之家
博客园 - 【当耐特】
罗磊的独立博客
Stack Overflow Blog
Stack Overflow Blog
MyScale Blog
MyScale Blog
WordPress大学
WordPress大学
The GitHub Blog
The GitHub Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Hugging Face - Blog
Hugging Face - Blog
I
InfoQ
B
Blog RSS Feed
腾讯CDC
云风的 BLOG
云风的 BLOG
N
Netflix TechBlog - Medium
Apple Machine Learning Research
Apple Machine Learning Research
GbyAI
GbyAI
雷峰网
雷峰网
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
D
DataBreaches.Net
The Cloudflare Blog
V
V2EX
S
SegmentFault 最新的问题

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Business-case (бизнес-кейс) проекта. В каждом проекте как...
Iurii_PM · 2026-04-17 · via Все публикации подряд на Хабре

Проект кто-то заказывает — это Заказчик. И его кто-то реализует — Исполнитель. Очень часто это разные юридические лица, часто исполнителей несколько, и также часто у исполнителя есть субподрядчики. В проекте есть и специфичный объем Заказчика (например, поставить задачу и согласовать результаты) и Исполнителя (например, выполнить работы в соответствии со своими компетенциями, ради чего его и позвали). И со стороны может показаться, что они делают один проект. Более того, сам вопрос для некоторых может показаться странным: «Один ли проект они делают?» Но вопрос этот правильный, и ответ на него: если бизнес-кейсы у Исполнителя и Заказчика разные, то они делают разные проекты. Еще ярче, если Исполнитель и Заказчик — это разные компании, то бизнес-кейсы у них точно разные. Мы знаем каждый проект имеет свой собственный бизнес-кейс. Так что, если бизнес-кейсов несколько, то и проектов всегда несколько.

Поэтому чаще всего проектов — два. Первый проект — у Заказчика. Обычно его и принято считать за «главный» проект. Второй проект — у Исполнителя.

Совпадают ли бизнес-кейсы проектов Заказчика и Исполнителя? Узнать это чаще всего очень сложно: даже если бизнес-кейсы формализованы (что бывает не так часто, как хотелось бы, а чаще всего не бывает), то вряд ли обмен ими сочтут целесообразным. Но что точно знает Заказчик об Исполнителе — это то, что как минимум сейчас Исполнитель считает выполнение своего проекта выгодным. А Исполнитель о Заказчике тоже знает, что ему проект нужен и что он дал лучшее предложение среди конкурентов. А лучшее — значит, дешевле всего за тот объем, качество, риски и сроки, которые обещал.

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

Академический аспект

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

Если проект выполняется сторонним Исполнителем, то для расчета стоимости, прибыльности и целесообразности проекта создается свой бизнес-кейс. Тем самым Исполнитель инициирует свой собственный бизнес-кейс.

Бизнес-кейс описывает получаемые результаты, выгоды от результатов, прибыль от их использования и фиксирует главные проектные риски. Стандартом PRINCE2 диктуется также представление в бизнес-кейсе трех вариантов реализации проекта: ничего не делать, сделать по минимуму, сделать выше минимума.

Где можно найти совпадающие параметры бизнес-кейсов? Лучше всего — в договоре и в уставе проекта. Именно там должны быть зафиксированы результаты и выгоды от их использования, которые должны разделяться как Заказчиком, так и Исполнителем. Также договор должен быть составлен таким образом, чтобы из него было ясно, что произойдет при негативном развертывании событий, а именно: прекращение проекта, нарушение сроков, качества и изменение объема работ.

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

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

Аспект культурный

Для заказчика. Подготовить бизнес-кейс означает не только отсутствие культуры, где принято уходить в описательные или эзотерические тезисы при обосновании проекта («это наш имидж», «наш позор», «это стандарт», «это эффективность», «у нас каменный век, так никто уже не живет»). Но и наличие культуры обоснованного принятия решения на основании цифровой объективной оценки целесообразности, определение и признание наличия проблемы. Это возможно только в культурах тех компаний, где выработан общий язык планирования и бюджетирования деятельности. А главное — объяснения сути необходимого не на жаргонном языке, где каждая функция хочет сделать недоступную тайну из того, чем она занимается, придавая своей деятельности сложность и загадочность, а простым языком договориться с несведущим, объяснив ему суть.

Для исполнителя. Подготовить бизнес-кейс проекта и пересчитывать его на протяжении проекта. Казалось бы, это должно быть базовым инструментом определения целесообразности и здоровья проекта для организации, которая целью своего существования ставит реализацию проектов. Но это только так кажется. Чаще всего бизнес-кейсы не формализуются. Расчет параметров проекта на входе частью забывается, обоснования теряются, остается только пара цифр. Оценка прибыльности проекта, даже если есть, живет в отрыве от выгод и рисков проекта. Прибыльность проекта пересчитывается нерегулярно, и непонятно, по какой методике. Это чаще всего бывает в реактивных культурах, в которых принято тратить время на решение проблем, а не на их предупреждение. «Работа на отказ» часто бывает выгоднее, чем предиктивная профилактика. В проактивной культуре, где выделяют время на то, чтобы «подстелить соломку», наличие полноописательного бизнес-кейса с регулярным пересчетом и пониманием того, как он согласуется с бизнес-кейсом Заказчика, является обязательным — так как именно это дает возможность эффективно быть умным «задним» числом. Подготовка и пересчет требуют создания общей культуры, где проактивность — это не дуть на холодное, а прозрачность, не делающая функцию уязвимой.

Жизненное

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

Директор по консалтингу: «Я помню этот срок запуска, но надо переносить — вчера я продал эту же команду другим». На вопрос от собственника: «А какой там бизнес-кейс?» — ответ был: «Его нет, но должен быть лучше». Но предоплата уже поступила, договор уже отправлен, пусть и не подписан. Но что-то уже обещали другим, и срок подвис.

Строка "Бюджет выручки" — без вопросов: как договорились в КП, так и есть. Бюджет затрат — директор практики: «За это они не сделают». Продавцы (когда-то в прошлом и исполнители) - : «Мы это оценивали, и мы бы сделали за столько-то». Директор практики — «Да как вы оценивали?». Ответ - «Когда-то два года назад делали примерно такое же (не задокументировано), а еще — мы знали цену конкурентов, у них чуть даже ниже. Вот при делении на нашу ставку и есть бюджет затрат. Примерно совпадают». Директор практики: «....Вот сами и делайте....».

Строка «максимально возможные трудозатраты" (те трудозатарты при которых проект финансово неинтересен». Директор практики смотрит: «Вот это без РП сгодится». Ген.дир: «Мы не будем работать в убыток, давайте вернем предоплату». Продавцы: «Если сделаем хорошо, то получим еще».... «Да там главное биллинг сделать.... на остальное закроют глаза, даже если работать не будет...».

Возвращаемся к сроку. Часть команды уже перепродана. Директор практики: «Биллинг знает только тот-то и тот-то». Возврат к команде. Тот, кто знает биллинг, перепродан еще раньше. Надо или вытаскивать, или искать. Срочно. И далее возврат к средней себестоимости: если вытаскивать или искать срочно, она будет выше. И далее опять к маржинальности. Вопрос полученной предоплаты. Разошлись делать.

Кстати, в ходе проекта часть объема действительно оказалась не нужна. Бизнес кейс благодаря не сделанному и не нужному объему оказался положительным.

Аспект человеческий

Почему же бизнес-кейс так сложно готовится? Почему забывается, что бизнес-кейсов два (Заказчика и Исполнителя)?

Начнем с человеческого: для человека бизнес-кейс в проекте один — и он свой. Каждый, входя в проект, что-то от него хочет: получить зарплату, опыт, бонус, продвижение. Это и будет двигать каждого принимающего решение. Притащить бизнес-кейс ключевым заинтересованным лицам, да еще и дать понятие, что существует другой (второй) бизнес-кейс (Заказчика или Исполнителя) и объяснить, что вот ради этого проект и существует, — значит разрушить частную картинку ради общей.

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

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

И далее он различает каждого участника проекта: есть ли у него свой бизнес-кейс или это просто «работник за зарплату», и также пробует (помогает) гармонизировать бизнес-кейсы каждого из участников.

Гармонизация возможна только при глубокой психологической установке, что чужие интересы и удовлетворение чужих интересов не более и не менее важны, чем свои собственные. Что будущее благополучие всех сторон зависит от эффективности их сотрудничества, и что руководствоваться необходимо собственным представлением о том, что выгодно сейчас себе, а не (и это часть не важнейшая) представлениями о том, сколько (как много) на этом зарабатывают другие стороны. Как только эта установка рушится, у одной из сторон появляется желание «отжать» — не потому что у себя мало, а потому что у другого много. Это приводит к разбалансировке бизнес-кейсов и, как следствие, для кого-то он в какой-то момент может стать невыгодным, что приведет к разрушению всего проекта.

Свой бизнес-кейс надо защищать, но не стараться это делать за счет чужих.

Сталинская школа — как это было в СССР

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

В чем же успешность с точки зрения бизнес-кейса в сталинской школе? Она проста. Мы поняли: степень пересечения всех бизнес-кейсов определяет вероятность успеха. Что же делает (рекомендует) товарищ Сталин? Он заставляет, чтобы пересечение всех бизнес-кейсов было максимальным — под 100%! Как следствие — возрастает вероятность успеха, и тоже под 100%.

Если наш секрет звучит как «в каждом проекте как минимум три бизнес-кейса (Исполнитель, Заказчик и Руководитель проекта)», то в сталинской школе они все три сливаются в один, и можно сказать, что там остается только один бизнес-кейс.

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

Первый. Привязать проект к социально (общественно) значимому процессу. Например, на проекте внедрения «Честного знака» декларировать, что развитие системы маркировки — это общая борьба с теневым рынком, который разрушает государство.

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