Внимание. Это черновик статьи, который требует проверки.
Статья представляет собой конспект лекции, прочитанной Гехтом Н.Е. ПМ-ам компании в июне 2017 года.

Введение

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

1. Деньги надо получить.
2. Компания должна получить больше денег, чем она потратила на разработку проекта.

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

Элементы экономики проекта

Деньги надо получить

Чем определяется, что деньги будут заплачены:

Первый фактор: Для того, чтобы деньги были заплачены, продукт должен быть готов и должен начать использоваться. Никто не будет платить деньги за половину сделанной работы.
Если человек заказал ремонт кухни, а покрасили только пол, то он не заплатите даже за покраску пола, так как кухня не готова. Если человек заказал торт, и ему показали замешанное тесто, он не будет платить только за тесто, так как заказывал торт. Если сотрудники написали требования, если сотрудники написали код – это не стоит нисколько, это не имеет ценности само по себе, пока не появится окончательный продукт.
До тех пор, пока не появился продукт, денег за этот продукт не будет. Отсюда следует, что любой человек, участвующий в проекте, должен быть нацелен на то, что продукт должен попасть в реальное использование. Тогда и только тогда будут деньги. От того, что кто-то один сделает работу хорошо, а остальные – плохо, потеряют все. Как бы хорошо человек ни работал, проект не пошел – денег нет. Всегда премии зависят только от того, как продался проект.
То, что проект попал на прод, дает нам юридические основания получить деньги от заказчика.

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

Итак, внимание к нуждам, держать свое слово, быть грамотным, быть вежливым – это то, что создает приятное впечатление о команде у заказчика.
Если проектные команды будут озабочены этими двумя факторами, процесс получения денег от заказчика значительно облегчится.
Эта часть экономики проектов достаточно простая: нашли человека, у которого есть деньги и ему надо что-то сделать, сделали это до конца, чтобы он мог начать это использовать, сделали так, что получить ему это приятно – получили деньги. Хорошо ли это? Неизвестно. Переходим ко второму элементу экономики проектов.

Денег надо потратить меньше, чем получили

Враг №1 экономики проекта – несоответствие полученного результата потраченным усилиям.
Ценность любого предмета определяется исключительно его потребительскими качествами (ИТ индустрия здесь никак не отличается от любого другой), никак не определяется себестоимостью. Нет такого человека на свете, который станет платить много денег только за то, чтобы получить это трудоемко. Деньги платятся только за то, что это можно использовать и получить эффект и эффект от использования больше, чем потраченные деньги. Эффект может быть не только экономическим, может быть удовольствие (поедания блюда больше чем обладания деньгами). Всегда мы получаем больший эффект, чем деньги, которые мы потратили. Поэтому никогда ни при каких условий не может быть, что мы говорим этот продукт стоит дорого, потому что мы потратили на него много усилий. Это никого не волнует.
Усилия, затраченные нами на достижения результата, должны соответствовать ценности этого результата. Добрая половина проблем возникает, когда мы беремся делать функциональность, которую делать долго, а ценность ее низкая. Часто это понимание возникает в середине работы. Вот тут психологически очень сложно бросить работу и ограничить потери на них. Для бизнеса жизненно важно прекратить терять деньги.
Математика тут очень простая. Есть фича, на которую вы потратили 100 часов и надо потратить еще 200 часов, ценность фичи – минимальная. Если мы остановимся прямо сейчас мы потеряем 100 часов. Если мы продолжим, мы потеряем 300 часов. Решение о том, что нужно прекратить эти работы и списать эти 100 часов является ключевым и его очень сложно принять. Психологическая сложность этого решения понятна: жалко сделанной работы. Баланс между ценностью фичи и потраченными трудозатратами он должен отслеживаться весь жизненный цикл фичи, не только в начале принятия решения. В тот момент, когда мы осознали, что эта фича не будет прибыльной никогда, есть только два пути:
Путь 1. Придти ко мне и согласовать, какие дополнительные выгоды мы можем получить, доделав фичи. Это могут быть выгоды технологические, например, мы столкнулись с новой для себя работой, мы это недооценили, и фича окажется намного тяжелее, но в результате этой работы у нас появитя фрэймворк, при помощи которого мы эти задачи будем потом легко решать и мы видим, что такой класс задач существует. Или, если фича имеет какую-то психологическую ценность. Мы знаем, что за нее не заплатят, мы знаем, что мы потеряем на ней больше, чем заработаем, но мы знаем, что представитель заказчика, который подписывает счета, и принимает решение о том, кому будут отданы деньги, эту фичу очень хочет. Когда мы точно знаем, что от этого человека зависят деньги и велика вероятность, что в следующий раз когда будут подписывать подпишут именно нам, потому что человек именно от нас он получил то, что хотел, тогда можно вложиться. Но и только.
Может создаться впечатление, что такая проблема возможна только на этапе девелопмента. Нет: требования стоят денег, тестирование стоит денег, написание документации стоит денег. Эта фича может потребовать огромных усилий на любом из этапов. Успешность экономики будет определяться суммой затрат на всех четырех этапах.
Мы не можем требовать от базового аналитика, базового девелопера, базового тестера, базового документатора видения всего процесса. Они на то и базовые: если бы они могли видели так глобально, они бы были начальником департамента. Но на уровне менеджера проекта необходимо понимание того, что ### Итак, сумма всех затраченных усилий, начиная со сбора требований и заканчивая тестированием, должна коррелировать с ценностью фичи. Если вы у себя на проекте установите правило, что усилия должны коррелировать со значением атрибута важности для пользователя, это очень поможет проекту. Если атрибут важности неизвестен, это не карт-бланш тратить на эту фичу сколько угодно много денег. Наоборот, неизвестная важность – это не высокая важность. Нельзя тратить много усилий на фичу с неизвестной важностью. И вот эту информацию можно донести до линейного тестера, линейного девелопера –чтение атрибутов – это очень просто. Вы, как ПМ-ы можете сказать, что когда на неважную фичу потрачено больше человеко-недели (это не жесткая цифра, зависит от проекта, команды, представителя заказчика – вы знаете свою цифру), значит что-то происходит не так. Обнаружить и прекратить, часто, намного более важно, чем предугадать сначала. Потому что сначала у нас есть недостаток информации, недостаток опыта и еще миллион причин, почему мы в начале проекта примем миллион идиотских решений. Так вот, бороться с принятием идиотских решений в начале проекта бесполезно - мы не можем преодолеть свою ограниченность знаний и недостаток опыта. Но можно научиться обнаруживать это потом и исправлять.
Нет и невозможно изначально разработать идеальный дизайн, но можно разработать такую систему патернов, которая позволяет идентифицировать и избегать проблем или потом исправлять свой код, перенося типовыми блоками из места в место для отработки качественной архитектуры. Этот этап намного важнее.

Враг № 2 экономики проекта - когда вообще делают не то. Когда мы говорим, что бюджет проекта нарушен или сроки сорваны, всегда велико желание предположить, что люди, исполняющие работу, не профессиональны, ленивы и так далее. Но, в большинстве случаев, силы потрачены со всем старанием и приложением знаний не на то, что надо – на то, что заказчику было не надо. Лекарство от этого очень простое – управление требованиями. Это то, что должны делать аналитики. Именно аналитик источник информации о важности. Именно аналитик специально поставлен знать то, чего хочет заказчик. Именно аналитик позволяет нам избежать ситуации, когда мы тратим усилия (теряем деньги) на то, что никому не нужно.

Враг №3 экономики проекта. Экономика проекта не ограничена одним релизом. Экономика проекта определяется всем его жизненным циклом – до смерти проекта, если мы собираемся получать за это деньги долго и успешно. Где кроются подводные камни повышенной себестоимости, а значит плохой экономики проекта, на этапе изменения:

1. Стоимость самого изменения.
2. Стоимость проверки изменения.

Это больше связано с девелопментом и тестированием. Проблемы могут быть в следующем:

• Нельзя найти то место, где надо сделать изменения.
• Изменение оказывает непредсказуемое влияние на то, что не изменялось. Это до бесконечности повышает стоимость изменения тестирования изменений.

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

Заключение

Итак, с точки зрения получения денег важно, что:

1. Деньги получаются только тогда, когда продукт начинает использоваться.
2. Результат должен быть передан способом, который заказчику приятен. Приятность определяется вежливостью, вниманием к потребностям, своевременностью.
   

Чтобы расходы не превышали доходы важно, что:

1. Объем усилий должен соответствовать ценности задачи.
2. Усилия тратятся только на то, что нужно сделать и не тратятся на то, что не надо делать. То что нужно, может выходить за рамки проекта, это может быть создание фрэймворка, обучение людей и т.д. При этом должны быть четкие обоснования и механизмы контроля того, что деньги потрачены с пользой.
3. Экономика проекта – она на весь жизненный цикл. Также как мы говорим, что себестоимость чистого девелопмента никому не интересна (потому что важна сумма затрат: написание требований, девелопмент, тестирование, развертывание, документирование), точно также стоимость изначального продукта, это малая часть по сравнению со всем жизненным циклом, потому что 90% расходов лежит не в начальном создании, а в его поддрежке.
   

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

Вопрос-ответ

Если сказать заказчику, что мы не будем это делать, может ли заказчик уйти к другому? Как этого избежать?
Есть две вероятности, почему заказчик может уйти:

• Мы не правильно интерпретировали ценности и потребности и заказчика и ему все-таки надо. Лекарство против этого: не фантазировать, что часто случается с аналитиками, когда они пытаются сыграть в эксперта, а внимательно выслушать заказчика и попытаться вопроспроизвести ситуацию.
• Иногда заказчик хочет странного и мы не можем объяснить ему, что это странно. В таком случае, пусть идет. Если он хочет странного, он все равно в этом проекте разочаруется. Да, мы отдадим часть денег кому-то другому. Заказчик потом вернется к нам и скажет: ребята, вы меня не обманули, а те другие сделали и мне не понравилось. Тут еще играет роль такой фактор: заказчик хотел странного. Вы повелись и сделали – получилось странно. Кто виноват? Вы. Представитель заказчика будет обвинять вас, потому что сказать, что он виноват – потерять деньги и место, а сказать, что вы виноваты – потерять деньги работодателя. Это правило работает не только для проекта в целом, но и внутри проекта. Виноват в том, что сделано странное, исполнитель.