Стоимость разработки vs ценность

Стоимость разработки — как она коррелирует с ценностью, которую получает заказчик в итоге? Мне кажется — никак.

Разработка ПО на аутсорсе — это почти всегда Water-Scrum-Fall.
Мы тщательно изучаем, планируем, оцениваем, пишем планы, рисуем диаграммы проекта и собираем ресурсы — это часть Water.
Дальше мы разрабатываем итерационно, делаем стендапы, ретро, демо и прочие артефакты аджайла (может у вас Scrum-ban вообще, добавьте свой список, по вкусу) — это Scrum часть проекта.
Затем мы передаем это в бета тестирование, делаем стабилизацию, релиз в продакшн и проводим окончательную приемку проекта и получаем последний транш денег — это Fall часть.

Все вполне логично, снижает многие риски, легче продавать, особенно большим компаниям с их четко спланированными бюджетами на год. В то же время мы наследуем все минусы обоих миров.
Такой подход напрочь убивает любую гибкость: вы пробовали параллельно с основым объемом работ, делать с десяток запросов на изменение (change request) с собственным бюджетом каждый? Это то еще удовольствие, ведь надо постоянно в любое время суток выдавать точную дату релиза и завершения фазы/проекта.
Ну и отдельно это уничтожает большую часть инноваций и ценности, ведь к моменту релиза мир уже изменился и чем дольше вы к нему шли — тем сильнее изменения.

Почти всегда я вижу достаточно существенное количество времени уделено подсчету стоимости разработки той или иной фичи, а еще чаще — сразу всего проекта. Считать стоимость фич начинаем только когда понимаем, что бюджет догорает синим пламенем, а фич еще осталось прилично и надо выбирать.

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

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

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

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

Навеяно http://blackswanfarming.com