В статье я хочу рассмотреть влияние разных факторов на сходимость проектов. Под сходимостью в данном случае я понимаю способность команды сдать проект в срок, уложившись в бюджет. По понятным причинам тема эта достаточно популярная и часто обсуждаемая. Как правило те обсуждения, которые я видел, сводились к следующим пунктам:
Как нам лучше планировать – тут далее идет широкий набор техник и инструментов от 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 для выставления счетов – две недели, три или одну. При этом звоночки о том, что все не так просто могут поступать. Где-то в обсуждении может мелькать слово «модели» или заказчик может нас хвалить и говорить, как быстро мы хотим сделать проект, он думал, что быстрее чем за год там такой командой не управиться, т.е. мироздание часто таки посылает нам какие-то знаки, но умение читать эти знаки заранее есть далеко не у всех.
Несколько примеров, некоторые не существенные детали изменены:
Пример 1: детали реализации
Команда делает проект, 10 человек, полгода, SCRUM, регулярные демо раз в две недели, карта стейкхолдеров, репозиторий на стороне заказчика, все как положено. До сдачи остается месяц, главный архитектор открывает код и пишет письмо, из которого оказывается, что:
Надо использовать другую систему логирования
Надо использовать Java 8 вместо Java 11
Использовать Spring нельзя, а надо использовать Quarkus (если мне не изменяет память)
... список из еще 7 пунктов, но на фоне пунктов 2 и 3 в общем уже не важно
Команда задает резонный вопрос
Мы же тебе ссылку на код присылали каждый спринт и просили посмотреть все ли тебя устраивает.
Я был занят, а сейчас освободился и посмотрел. Вам надо переделать, то, что вы сделали неприемлемо.
Пример 2: Приемка (UAT)
Команда пишет набор сервисов для интеграции со сторонними API. Интеграция там довольно развесистая, ответ от API может занимать до мегабайта JSON и надо вдумчиво мапить поля для разных провайдеров. Сделано где‑то 80% проекта, заказчик просит выкатить уже первый из сервисов в stage окружение. Внезапно (ну как внезапно, что‑то такое было известно, но никто не выяснил насколько все плохо) выясняется, что:
API endpoints с которыми шло тестирование они тестовые, реальный prod like немного от них отличается, причем как точно нигде не написано, посмотреть ошибки на prod like нельзя потому что доступа к нему у команды нет, он просто не работает и все. При этом весь предыдущий год все демо проходили нормально, и никто со стороны заказчика не намекнул, что тестовое окружение имеет отличия.
Есть строгое требование по latency и наши сервисы в них не укладываются и не укладываются так прилично — раза в 3–4. Не то, чтобы мы не спрашивали, но вот performance UAT занимается отдельная команда и до них наш вопрос не дошел, а те, кто его видели, никак не прокомментировали.
Чтобы что‑то выкатить на stage надо написать где‑то десяток документов и в строго определенной последовательности заполнить еще штук 10 Excel таблиц и скоординировать их заполнение с 5-ю разными командами заказчика, пройдя ревью для каждой заполняемой строчки. Все команды заняты и на то, чтобы назначить митинг уходит 1–2 недели.
В результате выполнение всех UAT требований для десятка сервисов в сумме занимает 5 месяцев работы команды. Если вам кажется, что нас специально подставили, то да, по ходу дела так оно и было.
Пример 3: Сделайте deploy только я вам доступ не дам
Большая компания с высоко зарегулированными процессами. Работа идет несколько тяжело, но в общем ничего супернеобычного. Заказчик достаточно трепетно относится к соблюдению сроков промежуточной поставки. При несоблюдении сроков достает контракт и начинает грозить штрафами. Команда делает все возможное, чтобы в сроки попасть.
Для доступа к окружениям нужен ВПН, ВПН работает только с фиксированных 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% вы будете задавать глупые, очевидные вопросы. Собственно большинство людей задавать глупые вопросы не умеют и/или боятся и упускают что‑то важное. Надо уметь соблюсти баланс между «не заметил слона» и «надоел со своими глупыми вопросами».
Заключение
Мы люди так устроены, что мы склонны игнорировать факты, не вписывающиеся в нашу картину мира. С этим фундаментально ничего поделать нельзя, но если очень хочется, то можно расширить картину мира и можно использовать разного рода инструменты позволяющие разглядеть спрятавшиеся от нашего глаза подробности.