В статье я хочу рассмотреть влияние разных факторов на сходимость проектов. Под сходимостью в данном случае я понимаю способность команды сдать проект в срок, уложившись в бюджет. По понятным причинам тема эта достаточно популярная и часто обсуждаемая. Как правило те обсуждения, которые я видел, сводились к следующим пунктам: Как нам лучше планировать – тут далее идет широкий набор техник и инструментов от MS Project до SAFe. Как мотивировать команду и сделать так чтобы они работали лучше и быстрее. Какие инструменты использовать чтобы кодировалось лучше – от Low code до Copilot и ChatGPT. Давайте рассмотрим пример, это реальный случай примерно 10-летней давности специально видоизменный так, чтобы поместиться в рамки статьи. Дано: Заказчик хочет сайт для продажи микросхем (в реальности там быть несколько иначе, но не в этом суть). На сайте должна быть главная страница, по страничке на каждую из 60 микросхем, с подробным описанием, характеристиками, возможностью искать микросхему по характеристикам, кнопка добавить ведомость материалов (Bill of materials) и кнопка послать заказ на оформление, выставить счет.  В общем-то почти статика, за вычетом нескольких интеграций и того факта, что список микросхем и их характеристики читаются из API. Можно делать на CMS, ну или в общем на чем угодно. Оценка: Сколько времени это может занять? Если какие-то шаги пропущены не придирайтесь, список скорее для иллюстрации хода мысли при оценке Финализация требований, макеты страниц – 2 недели Прототипы интеграции с внутренними системами заказчика – 2 недели Сетап проекта, создание репозиториев, seed сервисов, настройка окружения – 2 недели Главная страница – 1 неделя Страница с характеристиками микросхемы – 4 недели (тут мы закладываемся на то, что там много элементов) Страница поиска и результатами – 3 недели Интеграция с API с характеристиками микросхем – 2 недели Интеграция с API для выставления счетов – 2 недели Стабилизация - 4 недели Сдача проекта (UAT) – 2 недели В результате получаем проект на 24 недели. Или если округлить два месяца на троих человек. Ну пусть будет на 3 месяца – учтем верстку, рисование элементов оформления и т.п.  Где засада? Начинаем делать, показываем первые демо заказчик счастлив, идем с опережением, где-то к концу первого месяца уже 80% проекта сделано. Заказчик на демо спрашивает: «как нам лучше переслать вам проекты Autocad по каждой из микросхем, проекты большие и через почту не пролезут». И он бы хотел посмотреть на 3D анимацию и поговорить с теми, кто ее будет делать, там могут быть тонкости, и он хочет убедиться, что все нормально выглядит и не тормозит. В этом месте менеджер резко останавливается и говорит: «ЧТО?! Какая 3D анимация». Выясняется, что заказчику нужно, чтобы на каждой странице товара была интерактивная 3D модель соответствующей микросхемы сделанная в WebGL с возможность измерить габариты виртуальной линейкой. При этом без 3D модели проект не имеет смысла, сама суть была в том, чтобы все было интерактивно и трех мерно. А задачу просто составления ведомости материалов в виде таблички по характеристикам они и так сейчас прекрасно решают при помощи Excel и почты. Почему такое важное требование выпало в результате обсуждений не понятно, но сейчас это в общем уже не важно. Контракт подписан таким образом, что там слов «никаких 3D моделей» нет. Куда дальше двигаться не понятно т.к. стоимость увеличивается раз так в 10. Денег у заказчика на этот проект больше, чем выделено нет. Даже если мы его убедим, что надо без 3D моделей – по бизнесу ему такой проект не нужен, ему и с текущим процессом хорошо. Мы потратили 3 человека месяца и что делать дальше нет никаких идей. Такая ситуация называется «слон в комнате» - обстоятельство или предмет настолько важной величины, что не обратить на него внимание было бы глупо, когда предмет под носом, но его никто не видит. Применительно к IT проектам слоном в комнате называем какое-то обстоятельство, которое с одной стороны критическим образом влияет на возможность выполнить проект в срок и уложиться в бюджет, с другой для одной стороны было очевидно, а другая сторона о ней не подозревала. Часто команда, сфокусировавшись на том, что просто известно и понятно игнорирует наличие таких обстоятельств предпочитая микро оптимизировать то, что микро оптимизируется. В примере выше это могут быть долгие споры о том на какой технологии делать быстрее и проще, использовать ли CMS и сколько времени займет интеграция с API для выставления счетов – две недели, три или одну. При этом звоночки о том, что все не так просто могут поступать. Где-то в обсуждении может мелькать слово «модели» или заказчик может нас хвалить и говорить, как быстро мы хотим сделать проект, он думал, что быстрее чем за год там такой командой не управиться, т.е. мироздание часто таки посылает нам какие-то знаки, но умение читать эти знаки заранее есть далеко не у всех.  Несколько примеров, некоторые не существенные детали изменены: Команда делает проект, 10 человек, полгода, SCRUM, регулярные демо раз в две недели, карта стейкхолдеров, репозиторий на стороне заказчика, все как положено. До сдачи остается месяц, главный архитектор открывает код и пишет письмо, из которого оказывается, что: Надо использовать другую систему логирования Надо использовать Java 8 вместо Java 11 Использовать Spring нельзя, а надо использовать Quarkus (если мне не изменяет память)  ... список из еще 7 пунктов, но на фоне пунктов 2 и 3 в общем уже не важно Команда задает резонный вопрос  Мы же тебе ссылку на код присылали каждый спринт и просили посмотреть все ли тебя устраивает. Я был занят, а сейчас освободился и посмотрел. Вам надо переделать, то, что вы сделали неприемлемо.  Команда пишет набор сервисов для интеграции со сторонними API. Интеграция там довольно развесистая, ответ от API может занимать до мегабайта JSON и надо вдумчиво мапить поля для разных провайдеров. Сделано где‑то 80% проекта, заказчик просит выкатить уже первый из сервисов в stage окружение. Внезапно (ну как внезапно, что‑то такое было известно, но никто не выяснил насколько все плохо) выясняется, что: API endpoints с которыми шло тестирование они тестовые, реальный prod like немного от них отличается, причем как точно нигде не написано, посмотреть ошибки на prod like нельзя потому что доступа к нему у команды нет, он просто не работает и все. При этом весь предыдущий год все демо проходили нормально, и никто со стороны заказчика не намекнул, что тестовое окружение имеет отличия.  Есть строгое требование по latency и наши сервисы в них не укладываются и не укладываются так прилично — раза в 3–4. Не то, чтобы мы не спрашивали, но вот performance UAT занимается отдельная команда и до них наш вопрос не дошел, а те, кто его видели, никак не прокомментировали. Чтобы что‑то выкатить на stage надо написать где‑то десяток документов и в строго определенной последовательности заполнить еще штук 10 Excel таблиц и скоординировать их заполнение с 5-ю разными командами заказчика, пройдя ревью для каждой заполняемой строчки. Все команды заняты и на то, чтобы назначить митинг уходит 1–2 недели. В результате выполнение всех UAT требований для десятка сервисов в сумме занимает 5 месяцев работы команды. Если вам кажется, что нас специально подставили, то да, по ходу дела так оно и было.  Большая компания с высоко зарегулированными процессами. Работа идет несколько тяжело, но в общем ничего супернеобычного. Заказчик достаточно трепетно относится к соблюдению сроков промежуточной поставки. При несоблюдении сроков достает контракт и начинает грозить штрафами. Команда делает все возможное, чтобы в сроки попасть.  Для доступа к окружениям нужен ВПН, ВПН работает только с фиксированных IP адресов добавленных в white list.  Перед сдачей очередного этапа ВПН перестает работать. У админов заказчика обновилась инфраструктура и старый доступ сломался. Они видят нашу заявку, взяли ее в спринт и сделают ее в следующем спринте, который начнется через 3 недели, а деплой у нас на этой неделе. Но сделать они с этим ничего не могут, или не хотят.  Предстателя заказчика, который производит приемку, такие делали не волнуют вообще. Нет результатов, пункт контракта нарушен.  Глядя на проекты «в которых что‑то пошло нет так» я могу сказать, что больше чем в половине из них причиной проблем был какой‑то важный фактор неучтенный на начальной стадии. Какого рода факторы бывают: Крупное неучтенное функциональное требование, значительно увеличивающее объем проекта.  Важный, дорогой в реализации аспект известного функционального требования. Например, для функции загрузка аватарки пользователя надо сделать в браузере полноценный редактор загруженной картинки. Не функциональное требование, увеличивающее стоимость реализации, например мобильное приложение должно запускаться на Android v2.2 Процессные сложности, что‑то, что делает процесс разработки и/или сдачи проекта дорогим, хрупким или невозможным. Внешние зависимости. Зависимости от API, среды исполнение, оборудования и т. п. которые очень долго, очень дорого или вообще никак не разрешаются. Например — для разработки нужен доступ к API который стоит $3K в месяц на разработчика, и заказчик предполагает, что у нас сертифицированные разработчики, у которых доступ уже есть.  На самом деле список этими 5-ю пунктами не исчерпывается, жизнь всегда найдет чем развлечь инженера. Природа полна удивительных вещей.  Одна из основных проблем со слонами заключается в том, что они могут завести проект в состояние, из которого нет выхода вообще. т. е. это не «проект будет стоить на 10% дороже, работаем в ноль» или «срок релиза переносится на 2 месяца, пользователи негодуют» а вот буквально «обнаружилось новое обстоятельство и что дальше делать непонятно, лучшая идея — закрыть проект и списать убытки». Конечно, не каждый слон имеет столь убийственную силу, но для компании и одного может быть достаточно.  Часто стандартным ответом менеджмента на снижение рисков является «пропишите все возможные риски, требования и допущения в контракте». Все прописать невозможно и всегда какая‑то доля требований лежит в серой области умолчаний и распространенных практик. Основная проблема тут в том, что  мы не знаем то, чего не знаем; часть критически важных деталей «всплывает» на этапе реализации. Есть классические практики производства проектов, в которых сначала для проекта отдельно делается техническое задание, рассматривается, утверждается, потом делается технический проект на основе задания, проект детально описывает что и как будет разработано. И уже после того, как проект утвержден, начинается разработка.  В теории такая практика должна уменьшать количество негативных факторов, но, во‑первых, честно скажем почти никто так сейчас не работает. Во‑вторых, такие проектных практики кратно увеличивают стоимость и все равно не страхуют от неучтенных факторов. Да и полной страховки от неудачи это все равно не дает.  Даже если вы все‑все пропишете в контракте, например как в примере из начала статьи явно скажете «никакого 3D» и заказчик это подпишет — это все равно не сделает заказчика счастливее и не принесет ему пользы. А конечная цель любого проекта все же принести пользу заказчику Прежде всего надо понимать, что окончательного и ультимативного способа учесть все неучтенное не существует. Хотя бы потому, что неучтенный фактор может появиться уже после старта проекта и всего знать в принципе невозможно (см. Теорема Гёделя о неполноте). Но ряд правил позволяет все же уменьшить риски. Важно понимать как конкретно бизнес заказчика будет извлекать деньги из использования вашей системы, как это происходит сейчас, если происходит и как в деталях он видят процесс в будущем. Кто является выгодоприобретателем наличия системы у заказчика и как они видит промежуток от сейчас до момента, когда система сдана. И если вам кажется, что в этой картинке что‑то не сходится — лучше не постесняться и явно спросите. Часто народ стесняется и это рождает проблемы. Опыт разработки похожих систем позволяет понять карту залегания граблей и учесть типовые грабли на начальном этапе. Это может быть индустриальный опыт, опыт в менеджменте, опыт в конкретной технологии и т. д.  Несмотря на то, что в контракте нельзя учесть вообще всего, но тем не менее четко прописанные требования в начале разработки могут помочь защититься даже от тех проблем, которые в них явно не прописаны. Не ленитесь подробно проговаривать со всем заинтересованными сторонами что как и зачем вы собираетесь делать.  К текущему моменту индустрия накопила большое количество разного рода методологий и проверочных списков, содержащих вопросы «а какая допустимая latency», «а какие требования к безопасности», «а где вы планируете это развертывать» Также помогает до начала работ нарисовать комплект диаграмм описывающих систему с разных ракурсов.  Мы, условно говоря берем в руки черный ящик будущей системы и начинаем вертеть его в разные стороны в надежде найти ракурс с которого видно прячущегося внутри ящика Ктулху слона. Примером такого списка вопросов для конкретного аспекта может служить AWS Well Architected Review https://aws.amazon.com/architecture/well‑architected  Часто в процессе анализа проекта мироздание подает нам знаки. Что‑то, что не относится к основному потоку информации, но что намекает нам на наличие потенциальных проблем. Задайте больше вопросов вида «а почему», «а зачем», «а вот тут я хотел утонить», «а зачем вы упомянули модели в Autocad». Если слышите что‑то непонятное или выбивающееся из стандартной картины, лучше уточните. Единственное что тут важно — не терять эмоциональный контакт и понимать, что в 80% вы будете задавать глупые, очевидные вопросы. Собственно большинство людей задавать глупые вопросы не умеют и/или боятся и упускают что‑то важное. Надо уметь соблюсти баланс между «не заметил слона» и «надоел со своими глупыми вопросами». Мы люди так устроены, что мы склонны игнорировать факты, не вписывающиеся в нашу картину мира. С этим фундаментально ничего поделать нельзя, но если очень хочется, то можно расширить картину мира и можно использовать разного рода инструменты позволяющие разглядеть спрятавшиеся от нашего глаза подробности.