Инфраструктура - это не про железки, а про умение договариваться с людьми, которые этих железок боятся. Особенно в госухе. Ковыряю очередное ТЗ на предмет адекватности и последовательности, привет ГОСТ 34, решил отвлечься и порассуждать о инфраструктурных решениях.

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

Новый проект, вы разрабатываете ТЗ сами, новая информация, минимальный чекап который держу в голове при первых обсуждениях задачи:

1. ТЗ как протокол допроса Для внешнего заказчика (особенно в госах) ваше изящное решение - ничто, если оно не сходится с бумажкой. Если он не специалист, он не поймет архитектуру, но он точно умеет считать «дырки».

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

Пытайте пресейл вендоров на этапе сбора требований, в их же интересах продать оборудование, для этого есть "отверенные и перепроверенные" технические описания продуктов, нужно уметь с ними работать. Если есть архитектор, ГИП или проектант под рукой, отлично, работаем и с ними. ПМ должен работать своими "зайчатками" разума, вычищая из ТЗ бред, который невозможно подтвердить, и фиксирует границу ответственности. Если вы не прописали, что НЕ чините их ведомственный сервер 1998 года выпуска, но при этом переносите его из стойки в стойку с минимальной перенастройкой - будете чинить его бесплатно до окончания контракта пенсии.

2. Сроки из сказок Верить в то, что тяжелое «железо» приедет вовремя в 2026 году - это как верить в единорогов. Комплектующие дорожают прям на глазах, логистика рвется, а реестровое оборудование часто собирается в режиме «эксклюзивный хенд-мейд» из дефицитных плат, встречал срок поставки до 150 рабочих дней!

На первичном планировании графика работ, срок поставки умножаем на 1.5. При формировании НМЦК и сроков обговорите с заказчиком реальную ситуацию с комплектующими. Выстраивайте отношения с заказчиком, фиксируйте договоренности. В госах всё привязано к бюджетному году: если поставка 30 декабря - вы уже пытаетесь из кубиков "Ж П О А "- составить фразу "проект сдан, акты подписаны". К этому моменту вы должны не только привезти всё что было заложено, но и пройти семь кругов бумажного ада с актами. К примеру НДС в 25 и 26 годах, на ровном месте влечёт изменение стоимости контрактов с НДС, не успели поставить или закупить железо в прошлом году - добро пожаловать новые КП, с новыми ценами. Маржинальность летит вниз, а виноватый вы. Заказчику то пофиг, у него цена ограничена стоимостью контракта, и менять её можно по закону не в очень больших пределах от первоначальной стоимости, но это ещё и обосновать то нужно, допники и прочая бюрократия.

3. Решение принимает CTO, но проект похоронит электрик дядя Вася.

Вы привезли серверы на миллионы, а дядя Вася говорит, что лимит мощности в этом крыле исчерпан еще при Андропове, а безопасник не пускает «железо» в сеть, потому что «не положено». Из последнего: по первичным хотелкам головного заказчика нужно 2 ИБП + блоки батареек к ним, АВР и гарантированные 30 минут работы, когда начали работать с филиалом куда это вот всё ставить, выясняется что там есть машинный зал с АКБ и нам нужен по факту только инвертор +АВР, которые на минутку в 6 раза дешевле.

Что делать: Определите с заказчиком перечень ЛПР, требования, границы ответственности, кто за что в проекте со стороны заказчика отвечает, фиксируйте договоренности! Их «нельзя» на старте — это сэкономленные вагоны ваших нервов в финале.