Comments 50
А можно примеры обтекаемых пунктов из ТЗ?
И как вообще происходит приёмка продукта? Т.е. в чём проблема взять этот "расплывчатый ТЗ" и сделать продукт согласно ТЗ?
Если по расплывчатому ТЗ сделать не так, как задумал заказчик, он не примет. Можно попробовать через суд его заставить подписать акт, но не все готовы в это ввязываться, да и результат непредсказуем.
У заказчика часто просто нет нормальных специалистов чтобы написать подробное ТЗ, пишут в общих чертах, по ходу проекта уточняются хотелки - это самая распространённая ситуация. Нет тут никакого злого умысла.
Статья написана в чёрных красках. Типа так всё тяжело на рынке госзакупок, пожалейте нас. ;) На самом, деле госзакупки - это золотое дно как правило. Как то довольно давно работал в холдинге у которого было специальное отделение занимавшееся закупками. Они выигрывали тендеры и перепродавали их (типа нанимали субподрядчиков). Прибыли всем хватало при этом + ещё и инсайдерам, помогавшим выигрывать тендеры на "той стороне", перепадало.
Да, конечно бывают и проблемные закупки. Я сам как-то был такой закупкой с тендером на обновление нетиповой конфигурации корпоративного портала Битрикс, но тут уж подрядчик сам виноват был. Даже я знал и честно их предупреждал что дизайн портала кастомный, а значит нармально он не обновиться, нет, нашлись бодрые парни из ставрополья взявшиеся сделать всё за месяц (видимо, думали что жирный куш на халяву сорвали :) ). В итоге кое-как управились за полтора года.
Иногда злого умысла нет, а иногда есть. И то и другое - проблема, просто разная.
Прибыли всем хватало при этом
Это "золотое дно" за наш с вами счёт. Инсайдеры и прокладки делают ситуацию хуже. Главное что бы они не сделали ситуацию настолько плохой, что бы польза от проекта пропала совсем.
У меня на VC.ru выходили материалы и про недостатки и про положительные стороны(надеюсь, не забанят за ссылку!). В целом, система рабочая и мы в ней зарабатываем, но проблемы есть.
Добрый день! В текст рассказывали мимолетно – в нашем случае бывали истории, что руководство отдела заказчика хотело сделать один продукт, а когда мы спрашивали про часть про безопасность, они говорили сделайте по минимуму. Но когда мы запросили отдельную встречу с безопасниками, они нам намекнули, что "хрен вы сдадите" на приемке проект без полноценной части по безопасности. А это уже другие бюджеты!
Именно так, суд затянется на 1-2 года и вы потеряете больше денег, чем могли заработать. Плюс от таких маневров портится имя на рынке госзаказа
Тендеры - зло, решение: усиливать договора, проверять рекомендации, базы и рейтинги исполнителей/заказчиков/посредников, оценка исполнителей, обучение заказчиков, понятные роадмапы, прозрачные ТЗ по нормально собранным БФТ, контрольные точки - по итогам которых штрафные санкции за невыполненные обязательства, плюсы/бонусы за сверхожидаемый сервис/качество/не прокуканные дедлайны, раздельные выплаты по этапам. Вот это все прекрасно работает.
Вы сначала декларируете что тендеры типа зло, а потом описываете что в ходе тендеров делается в качестве решения. Так зло или решение? Противоречие какое-то выходит.
Современные тендеры уже давно включают этап оценки, на котором как раз рейтинг исполнителей исходя из опыта выполненных заказов, наличия кадровых технических и т.п. ресурсов и считают.
Наверно, как и в моей статье, зло – но с которым можно работать, чтобы оно было добрее. По методам соглашусь и ещё чуть позже напишу про сам процесс закупки и площадки статью, раз эта зашла!
Именно.
Жду статью про обещанное.
Пожалуйста, участники продаж, учитывайте не только свои БП продажи, но и БП закупа у клиента/заказчика.
Пока я, с сейлзами и IT/тех десантом из экспертов на переговорах, не стали этого учитывать, продажи были совсем плохонькие. А то закуп говорит, условно на С++, а мы на С# и вроде об одном и том же, но все же разном. Когда смогли более-менее наложить БП друг на друга, случился оргазм ))) вернее продажи поперли.
Далее стали учитывать процессы согласования, оценки и приемки, смотрели как делает Заказчик и смогли найти синергию, где-то подстроились, где-то обучили, где-то "насильно склонили" ))) т.е. показали, что в данном случае нужно делать, а не так как хотел Заказчик - работало с новичками в разработке, особенно когда обламывали, когда заказчик хотел пилить свое CRM, а на готовые решения не смотрел, ну например из-за своей паранойи.
Если, у автора и здесь есть, что рассказать, с удовольствием почитаем.
а хотя половина не знает, что нужно и как это будет сделано, а другая не умеет нормально, ни делать, ни разъяснять, хотя втирать научились. В долгую надо играть и той и этой стороне, а получается как на баррикадах
Не знаю как сейчас, но с десяток лет назад, почти каждый мне известный крупный проект (ИТ-заказ) не обходился без коррупционной составляющей.
Например, по ЦБ: между аккредитованными компаниями заранее "сверху" выбирался победитель, кто в каком регионе выиграет конкурс. Например, если должна выиграть Компания А, то сотрудники компании А за других участников делали их конкурсные предложения, а они уже просто от своего имени выставляли их на конкурс. Смешно, но из-за человеческого фактора иногда побеждал "не тот", например, тот кто циркулярно делал ценовые предложения - накосячил и где-то с циферкой ошибся и победил "не тот" (комиссия уже сделать ничего не может) или участник конкурса перепутал комплект и отправил предыдущую полученную от "планового победителя" версию (например, прямо перед конкурсом добавили работу и у всех циркулярно нужно вписать новую стоимость и соответственно поменять в предложениях цены).
Были и такие варианты (не с ЦБ):
Кстати стратегия: "Ваши кони тихо скачут" - типовая и массовая.
Поэтому крупные гос-заказы (любой заказ, который подразумевает участие любой монополии) должны быть предельно прозрачны, включая детальное ТЗ, тех-проекты (т.е. как контроль выполняемых работ уже после победы в конкурсе / доказательство добросовестной победы), возможно даже рабочие проекты (детали ИТ-безопасности можно замазать). А главный Фреймворк для "крупный ИТ-заказ" - это борьба с коррупцией, чего сейчас нет, потому что ...
Все эти "законы" - во всяком случае ранее, легко обходятся совместными "усилиями" заказчика и "правильного" исполнителя. Полагаю, что целесообразна организация некого общественного контроля над этим, которой и будет предоставлен доступ к указанным деталям.
Так и есть, к сожалению. Одна из моих прошлых работ как-то решила обновить свою корпоративную ГИС-систему (хотя, старая вполне неплохо работала).
Внедрение старой, в своё время, обошлось в 8 млн. руб, часть из которых ушла на лицензии ArcGIS, зато новая, на опенсорсных решениях (то что за лицензии не надо платить декларировалось как суровое преимущество) в итоге потянула на миллиард примерно (может и больше, дальше не следил. От всех местных специалистов по ГИС и меня в конторе избавились, чтобы не мешали заниматься таким важным делом :) ). Они закупки били по кусочкам в 5-20 млн. обычно, для реализации ТЗ надо было быть в курсе тонкостей реализации предыдущего кусочка. В итоге и гигантскую сумму проекта не светили и чужим в проект было не войти.
P.S.: Кстати, натыкался потом на видеоролики о достижениях той организации и на экранах компьютеров светилась у них почему-то всё та-же старая ГИС, а не новая почему-то...
Добрый день! Сейчас существуют конкурентные закупки и большинство старается работать, как можно более прозрачно в связи с напряженностью в обществе.
Про то, что ТЗ и закупки должны быть более прозрачны - соглашусь.
Есть много хороших команд, которые зашли на рынок госзакупок и выполнили контракты на 5-7 млн рублей. Они крупный тендер не возьмут даже если захотят. Сначала надо дорасти.
Что мешает им объединиться?
Работаю в строительстве, по тем же самым ФЗ, имею сказать следующее:
Заказчик не монолитен. ПО/ремонты/новые объекты нужны одним структурам, а финансируют, проектируют, выставляют ТЗ другие структуры. В участие подготовки и комплектации тендера принимает большое кол-во специалистов, у каждой группы из которых свои показатели, а так же неформальные требования. Производственникам (условно это эксплуатация) требуется одно, а финансистам (менеджеры/бухгалтерия/управленцы) другое. Из этого вытекает что требования выдвигает формальные вторая группа, а со всем этим жить и строить и принимать первой. Здесь происходит то что в быту часто относят к коррупции, а именно не все организации могут пройти между Харибдой и Сциллой. В некоторых случаях, если группа производственников имеет сильное лобби и им нравится конкретный Подрядчик как он выполняет работу, и умеет балансировать между интересами разных структур, то, понимая как трудно получить такого участника, они входят в сговор с руководством организаций и формируют новые требования под конкретного участника. Кроме того нужно понимать, что есть задачи которые могут сделать считанное кол-во Подрядчиков в регионе/в стране. И тут ссорится с ним себе дороже, хотя не без этого, всегда найдется такой руководитель который считает что раз он платит деньги, то значит Подрядчик должен прогнуться. В итоге оказывается что на следующие тендеры никто не является или приходит такой Подрядчик, которому проще обанкротится чем вывезти. (Хорошо это или плохо? Это работает, значит кому-то нужно!)
Следующий момент это порочная система ценообразования. Т.к. на нее влияет и гос-во, и монополии, и система крупных Заказчиков, то ценообразование выстраивается так что бы сделать/построить максимально за имеющиеся в наличие деньги. Заказчика не интересует себестоимость. Никто не проводит анализ во что это обойдется, а если на тендер никто не явится, то его немного проиндексируют и перевыставят вновь. Для этого используется статистика, индексы, расценки и их состав и много чего еще. Если работать с этим постоянно, то может оказаться что на типовые комплексы работ цены не менялись лет по 10-15, по крайней мере в строительстве, а это значит что денег на цифровизацию тоже нет, хотя заявлен переход на ТИМ(BIM). Это к слову о расширении рынка ПО в стране.
Человеческий фактор. Когда я пришел на Хабр в 2013м году я с улыбкой читал все эти менеджерские статьи по управлению персоналом, но примерно с 2018го у нас на стройке тоже стало не до смеха. В строительство проникли управленцы с новом типом мышления - для которых показать прибыль это самый простой метод построить успешную карьеру. На что только не идут эти люди... Соответственно то что раньше держалось на договоренностях стало рушиться, т.к. управляющие перестают их соблюдать. На фоне этого исполнители стали прятаться за регламенты и произошло забюрократизирование процессов, что так же привело к увеличению рисков и издержек Подрядика.
Я тут все о Заказчике, но такой ли белый и пушистый Подрядчик? Ему нужно кормить работников и находить новые объемы работ, маржа на которые постоянно падает. Это вызывает естественное желание подвязаться с надежным ЗАказчиком. Помимо прочего что бы уложиться в бюджет приходится экономить, или не выполнять часть работ, или использовать менее квалифицированные кадры/более дешевые комплектующие, недоплачивать работникам/субподрядчикам и т.д. и т.п. Что тоже ведет к увеличению рисков, но в цепочке "От идеи до модели" эти риски распределяются неравномерно.
Мой вывод: как бы парадоксально это не звучало, но, на мой взгляд, участники рыночных отношений пытаются именно в рамках коррупционных моделей снижать риски, как ни странно это приемлемо всем, иначе бы борьба с ней приносила свои плоды, а так все при деле и все строят карьеры и у всех на всех есть компромат. Спасибо тендерной системе.
Как человек, имеющий опыт участия в такой развлекухе с обеих сторон, замечу, что заказчику нет особого смысла писать подробное ТЗ для людей со стороны, если есть организации, которые давно работают с заказчиком и хорошо понимают ситуацию и без того. Дело тут часто не в коррупции, а в экономии сил.
Я вот прихожу, например, на обед и говорю: "мне как обычно", потому что в заведении уже давно знают мои вкусы.
Контрактная система порождает некую иллюзию, что можно без опыта с нуля взяться за новое для себя дело в равных условиях. Взяться, действительно, можно, но у исполнителей 80 уровня есть специфические баффы. Объективно, не имея опыта и готовых наработок, вы будете иметь более высокую себестоимость, чем некоторые другие участники, и для вас работа будет заведомо невыгодной.
Ну и, разумеется, любая запятая в ТЗ имеет значение и должна быть выполнена от сих до сих, даже если сам заказчик на этапе заключения договора не понимает, зачем это нужно. А он, например, скопировал требования нормативного документа и понемногу сам разберётся, что без них никак.
заказчику нет особого смысла писать подробное ТЗ для людей со стороны, если есть организации, которые давно работают с заказчиком и хорошо понимают ситуацию
Так это и есть та самая коррупция или сговор.
Если один учёный, например, разбирается в физике чёрных дыр, а другой нет, их попросили написать статью про какое-нибудь там излучение Хокинга, и первый понял, а второй нет, значит ли это, что первый учёный находится в коррупционном сговоре с чёрными дырами?
Тут ведь тоже можно накатить волну, типа, давайте определимся, что мы называем излучением Хокинга, и это должно быть прописано в ТЗ. А можно просто быть в курсе вопроса.
Вот только не нужно приводить глупые аналогии. Тем более, что любая аналогия лжива по определению, а объяснить и обосновать можно все что угодно.
Контрактная система как раз и предназначена для того, что бы исключать коррупцию и сговор между заказчиком и исполнителем, а то, про что вы рассказываете, это один из способов этот закон обойти. Я так же как и вы побывал с обоих сторон и на 100 процентов в этом уверен.
Полное ТЗ нужно будет делать по любому, т.к. на его основании будут разрабатываться в том числе и закрывающие контракт документы. Поэтому "можно не писать", это лишь отговорка, чтобы сразу отсеять возможных конкурентов и ничего более.
В чём именно приведённая аналогия глупая или лживая?
Полное ТЗ нужно будет делать по любому, т.к. на его основании будут разрабатываться в том числе и закрывающие контракт документы.
Разработка закрывающих документов никоим образом не зависит от степени полноты ТЗ. Они просто должны соответствовать договору (и ТЗ, как приложению к нему).
и на 100 процентов в этом уверен
Плохой признак.
В чём именно приведённая аналогия глупая или лживая?
Потому что это аналогия.
Если говорить о закрывающих документа для бухгалтерии, то безусловно полнота ТЗ, как и оно само тут не причем (разве что как приложение к договору). Да и акт приемки можно подписать без ПСИ или сделать ПСИ без учета исходный требований (ТЗ или ЧТЗ).
Но ведь изначально речь шла о требованиях именно для разработчиков. а не для бухгалтерии или закрывающих документов. И если вы сдаете работы по договору без проверки качества работ, ну тогда СЗЗБ. Как раз про подобную ситуацию писали выше, когда вместо ТЗ делают ХЗ, чтобы в последствии жонглировать объёмом работ по договору.
Я давно в руководстве проектами, и возьмусь при необходимости сдать плохо выполненную работу при любом объёме ТЗ. Это вообще не тот вопрос.
Многие почему-то думают, что объём бумаг как-то волшебно помогает сделать дело. Я участвовал, например, и в таком проекте, в котором одну только конкурсную заявку госзаказчику отвозили на Газели, потому что в легковой автомобиль такое количество бумаги не умещалось. Если вы думаете, что это как-то положительно или отрицательно повлияло на качество исполнения работ, то вы ошибаетесь. Ну разве что позволило отсеять случайных людей на этапе проведения конкурса, но, вроде бы, именно этот отсев вам не нравится. А так просто офигенная масса людей в рабочее время составляла и распечатывала бумаги, которые потом никто не читал.
Теперь, что касается требований для разработчиков. Я сейчас работаю в немного новой для себя организации, где, в частности, условно говоря, в соседней комнате сидят инженеры-оптики. А я, понятное дело, программист по специальности, и в оптических вопросах вообще ни в зуб ногой. И вот приходит ко мне оптик и просит написать программу для высокопроизводительной обработки своих данных, а я не понимаю 80% из того, что вообще он говорит. Значит ли это, что оптик находится в коррупционном сговоре с каким-то моим конкурентом и специально говорит мне непонятные и недостаточно подробные вещи, чтобы я отсеялся? Разумеется, нет, он обращается со своей проблемой именно ко мне. Значит ли это, что он в любом случае должен был бы объяснять свою проблему подробнее? Тоже нет. Когда я хотя бы лет 5 с ним поработаю, то научусь понимать его язык, и мне тогда и не нужна будет детализация. Поэтому вывод такой, что требования формулируются на языке, понятном для опытного исполнителя, а неопытный исполнитель запросто может их счесть недостаточно подробно сформулированными.
Я тоже давно в руководстве проектами и могу взяться не только сдать плохо выполненную работу при любом объёме ТЗ, но и пройти сертификацию при не работающем продукте.
Но ведь это ни подтвердит ни опровергнет ни ваши ни мои слова, верно?
Вы почему то пишите исключительно про крайности (целая газель для перевозки кипы бумаг) или приводите примеры про не разбирающихся в теме менеджеров, чтобы подтвердить свое мнение. Но для компаний без компетентных специалистов уже предусмотрены ограничительные барьеры на уровне законодательства.
Поэтому ваши слова "заказчику нет особого смысла писать подробное ТЗ для людей со стороны, если есть организации, которые давно работают с заказчиком и хорошо понимают ситуацию и без того." описывают только ту ситуацию, что за копейки можно вляпаться по самое не балуйся из-за того, что ТЗ специально сделали корявым или не полным, чтобы утопить людей со стороны.
Собственно, про это в статье тоже написано, хоть немного и другими словами.
Мой пойнт в том, что за копейки можно вляпаться по самое не балуйся совершенно необязательно из-за чьей-то злой воли. Вообще, любое плохо знакомое дело содержит плохо известные риски.
Но для компаний без компетентных специалистов уже предусмотрены ограничительные барьеры на уровне законодательства.
Интересно про таковые послушать.
Мой пойнт в том, что за копейки можно вляпаться по самое не балуйся совершенно необязательно из-за чьей-то злой воли. Вообще, любое плохо знакомое дело содержит плохо известные риски.
Тут я с вами полностью согласен!
Интересно про таковые послушать
Так это и есть ТЗ и обязательные требования к исполнителям :-)
Ведь согласитесь, что риск вляпаться с корявым или не полным ТЗ значительно выше, чем с честным ТЗ в полном объеме требуемых работ.
В этом я, в свою очередь, согласен с вами. Но я-то писал про то, что ТЗ может в каких-то случаях только представляться неполным недостаточно осведомлённым людям. Начиная с того, что какой-нибудь специальный трижды гостированный термин, не зная его, можно понять в бытовом смысле.
Автор поста же сам приводит пример, как у него в ТЗ были прописаны требования по безопасности, а он почему-то подумал, что они неважны. Хотя погружённому в тему человеку ясно, что любая безопасность – это многократный геморрой, и если она в действительности не требуется, то надо её сразу вычёркивать под протокол.
Так может быть автор как раз и попался в подобную ситуацию, когда требования в ТЗ были прописаны не полностью, хотя свой собственный прикормленный исполнитель был в курсе этого. Но автор влез со стороны, вот и отгреб, так как по неполному ТЗ не имел возможности оценить полный объем работ?
Вот что автор сам пишет:
Блоку безопасности в ТЗ уделили много внимания, однако устно проговорили, что его реализация обсуждаема т.к. блок не приоритетный.
...
Начинаю общаться и тут выясняется, что блок безопасности стоит в приоритете.
По-моему, тут всё прозрачно.
Я вот не понимаю, что такое “не приоритетный блок” в ТЗ. ТЗ может быть или выполнено, или нет.
Причём неполное ТЗ является проблемой скорее для заказчика, чем для исполнителя.
По-моему, тут всё прозрачно.
Не зависимо от полноты ТЗ, если у заказчика был прикормленный исполнитель (в том случае, который описывает автор), то так сказать про блок безопасности могли, к примеру, чтобы проучить левого исполнителя на будущее.
Нет смысла гадать, так как это всего лишь слова, причем только одной стороны. Вы же должны знать, что одни и те же документы можно притянуть как "за", так и "против", было бы желание или явное указание ЛПР.
История такая, что руководство отдела заказчика хотело сделать один продукт, а когда мы спрашивали про часть про безопасность, они говорили сделайте по минимуму. Но когда мы запросили отдельную встречу с безопасниками, они нам намекнули, что "хрен вы сдадите" на приемке проект без полноценной части по безопасности. А это уже другие бюджеты!
ИМХО корень размытых ТЗ - в нежелании заказчика (а именно конкретного чиновника) нести ответственность в случае ошибок реализации. Проще все огрехи свалить на исполнителя, прикрываясь нечётким ТЗ.
По разному бывает. У меня библиотекари закупают системные блоки по ТЗ и вынуждены прописывать примерно следующие параметры:
Тип и количество USB портов на передней панели
На задней панели
В целом вообще
USB 2.0, 3.2 Gen 2, 3.0, USB-C, и далее по списку - отдельно
Тип ОЗУ, максимальное и минимальное количество, кол-во планок, частоты
ит.д. ит.п.
Даже мне приходится на закупку каждого системника сидеть по часу и пытаться понять, что там Минобрнауки от нас требует в ТЗ на тендер.
А представьте, что не у всех библиотек в штате есть ИТ специалисты для составления ТЗ и приходится штатным библиотекарям и бухгалтерам это вот всё..
C одной стороны я с вами согласен, с другой стороны, как и говорили коллеги ранее. У Заказчика зачастую не бывает специалистов что бы сделать хорошее ТЗ или же когда планируется бюджет заказчик не до конца понимает, что он будет делать и заказывать. Часто бывают такие случаи.
Повторюсь:
Тезисы по ТЗ:
ТЗ нужно, в том числе потому, что на его основе строятся Методика испытаний и Технические условия (ТУ, кстати ТУ делают и на ПО).
ТЗ обычный заказчик не понимает и это нормально. Для сложных систем делают ТЗ на одно и то изделие, но на каждый этап (эскизный проект, техпроект, рабочий) – эти ТЗ отличаются детализацией. Бизнес-требования (функциональные требования) это по сути ТЗ на эскизный проект.
Иметь хорошее (конкретное) ТЗ – это на 30 процентов уже построить систему (взаимоувязанные требования задают «красную нить» разработки). Однако в ТЗ заказчики часто задают размытые формулировки, чтобы «подстраховаться». Потому что: ТЗ исполнитель обычно делает так (пользуясь, что заказчик в деталях не понимает), чтобы как можно было легко закрыть договор (ТЗ приложение к договору на работу) и возложить вину на заказчика если что-то не хватает и тут же предложить новый допник на доработки (заказчик уже «на крючке» и его можно «щипать»). Исполнитель обычно говорит: заказчик сам не знает, чего хочет. Иногда говорят так: «заказчик знает, что хочет, а исполнитель знает, что действительно нужно заказчику» (но это не так). Типовой результат проекта: работы выполнены в точности по ТЗ, но заказчик хотел другого.
Мечта чиновника зачастую в конце года объявить тендер на выполнение своих обязанностей и если всё нормально, то он молодец, а если печально, то его подвели подрядчики.
Зачастую закупки осуществляются с целью освоить бюджет, нежели оптимизации и улучшения. Заказчикам, особенно госсектора иногда не выгодно, чтоб кто-то снижал цену. Т.к. у них будут не освоенные остатки.
Тут не только в остатках дело. Деньги государственные, а с результатом заказчику работать самому. В большинстве случаев снижение цены так или иначе идёт в ущерб качеству. Поэтому в снижении цены заказчик не заинтересован.
Я имел ввиду именно освоение бюджета и про то, что качество руководство не интересует. Потому что на след год, есть что переделать. К примеру: Закупка правовой системы, она одна, но поставщики разные. По факту тех задание ставится таким образом, что более дешёвые просто не входят. И качество у дешёвых, как правило лучше. Второй пример переход на отечественное ОС. Написали закупку с вводом, но год ничего не делали, как кончилась гарантия, начала вводить 3 контора и пришла к выводу, что нужно продлить лицензию. И таких примеров достаточно много.
Большинство из перечисленных болячек можно решить советом «заказчикам нужно усилить менеджмент и грамотно писать ТЗ». Давайте просто признаем, что это совет из серии «Делайте зарядку и спите 8 часов».
Странно, но ладно, у меня есть альтернативный: "тебе надо - ты и сделай".
Почему бы лично Вам не устроиться в государственное учреждение и не показать всем "как надо"?
Или хотя бы не договориться с каким-то из уже имеющихся заказчиков о размещении тендера о разработке системы госзакупок в сфере ИТ?
Добрый день! Попробуйте вместо написания комментариев в интернете следовать своим советам!
Вы знаете, я родом из тех мест, где даже гайку нужных размеров не всегда найдёшь, поэтому уже, спасибо.
Возвращаясь к обсуждаемой теме, поведение участников системы госзакупок в целом соответствует продемонстрированному Вами в комментарии (основываясь на тех примерах, что я наблюдал). Поэтому никакого дисбаланса и головной боли на самом деле не существует. Система выстроена, работает и приносит прибыль заинтересованным в ней лицам. По законам развития рыночной экономики крупные заказчики будут забирать себе всё больше и больше заказов и внедрять нужные им изменения в систему. Ваши публикации на Хабре и комментарии даже с 50 восклицательными знаками изменят примерно ничего.
Короткие сроки обычно говорят о том что тендер под определённого исполнителя
Обтекаемые ТЗ иногда означают, что у "своего" исполнителя эти обтекаемые условия примут легко, а у стороннего выпьют всю кровь и уведут проект в минуса. Если только он не захочет стать "своим".
В ИТ-секторе госзакупок сложился дисбаланс и это головная боль для заказчиков и исполнителей