Кое что про ИТ - 2
Babs Baberley Production & Alex Balaganov Inc представляют.
Привет тебе Василий, еще раз. Сегодня мы обратим твое внимание на следующее обстоятельство — по разным оценкам, на всей нашей планете, процент успешных проектов в области информационных технологий оценивается от 25% до 50% в зависимости от точки зрения оценщиков. Что это означает в переводе на русский язык? А то что, примерно в половине ИТ - проектов любой из основных параметров проекта был превышен более чем на 25% (формальный критерий оценки от коллективов независимых оценщиков) То есть либо сроки, либо бюджет, либо состав работ не вписались в пейзаж на вышеуказанные проценты и, естественно, не в сторону уменьшения. Это, Вася, те самые сроки, бюджет и объем работ, которые написаны в любом договоре, в том числе на создание информационной системы в твоем (или не твоем) ГБУ-ФГУП-МУП из тех самых программных продуктов, «лицензии» на которые ваша контора купила в прошлый раз. И в котором они являются основными и самыми существенными условиями договора, о чем тебе должно быть хорошо известно. И согласно мировой статистике — в каждом втором-третьем случае Исполнитель проекта должен либо вернуть деньги (со всеми пенями и неустойками) в госбюджет, либо стать твоим, Вася, клиентом. Почему же такое на практике происходит не часто, а часто происходит прямо наоборот - все бегают и машут флагами и докладами о своих успехах? И почему процент посадок так удручающе низок? Разберем ситуацию более детально.
Как ты Вася, думаешь, - что нужно сделать для запуска в промышленную эксплуатацию например программы для работы обычной бухгалтерии или расчета зарплаты\денежного довольствия? Сама она точно не заработает поэтому нужно выполнить несколько десятков, а то и сотен работ. Таких как — установить программу на серверы и компьютеры пользователей, занести начальные данные, такие как справочники личного состава, начальные остатки денег на счетах и ТМЦ на складах, обучить пользователей, настроить отчеты, сделать интеграцию с другими системами и т. д. И т. п. И вот тут Василий, начинаются чудеса. В явном виде в составе работ прослеживаются явные аналогии с отраслью строительства или машиностроения, но отличия просто грандиозные. Ты вот дом себе строил, Василий? Тогда должен представлять себе процесс строительства хотя бы на пальцах. И вспомнить, как ты первым делом определялся какой дом тебе нужен — камень, дерево, бетон или еще что. Сколько площади, этажей, какая крыша и фундамент. Ну и еще несколько десятков вопросов, которые обычно описываются в документе «Технические Требования». Это совершенно отдельный документ, по сути список хотелок заказчика. Далее ты Василий шел к архитектору и дизайнеру и он тебе рисовал домик на бумаге. И как он будет внутри выглядеть — то же риcовал. С обоями, розетками, мебелью, дверями, потолками и сортирами. Рисовал раз этак 10-15 пока тебе не понравится, то что ты видишь на картинке. Потом уже конструктор, негромко матерясь и регулярно названивая архитектору пытался спроектировать уже конкретные стены, лестницы, окна, вентканалы, розетки, канализацию отопление и еще кучу всего таким образом, что бы было похоже на то, что нарисовал архитектор, но при этом что бы тебе вся эта красота на голову не упала и хоть как то была пригодна к эксплуатации. Примеров — их есть у нас. Можно взять и сделать смотровой люк 10х10 см. Что бы через него только посмотреть на дырку в трубе и можно было. Можно взять и залить трубы отопления в стяжку. Что бы когда протечет — развлечений было по максимуму. Можно вообще утеплитель изнутри к стене приклеить. Ну и вообще столько всего на стройке можно — аж глаза разбегаются. Сам небось знаешь. Так вот в результате общения архитектора, дизайнера и конструктора появляется уже вполне приличный документ под названием «Проект». С описанием из чего конкретно будет сделана вот эта стена, какие провода каких сечений где и как будут проложены, какого цвета и марки будут обои и какими гвоздями будут прибиты наличники. И вот по этому документу уже волне себе можно будет посчитать сколько > IT LAW: конкретно гвоздей, кирпичей, и плитки нужно будет для постройки дома вот по этому конкретному проекту. Умножив количество на > IT LAW: рыночные цены ты Вася с хорошей точностью будешь знать сколько стоит материал. А умножив количество кирпичей на нормы работ по их укладке — можно оценить стоимость работ по постройке. А заодно и сроки примерно прикинуть. Вместе с количеством рабочих. Вот на этом этапе уже можно объявлять конкурс на постройку среди подрядчиков — появляются документы под названием Смета, График работ, в которых вполне есть рассчитанные, вполне правдоподобные ожидаемые, и самое главное, проверяемые, цифры. Ну и контролировать стройку тебе никто не мешает. Включая сокрытие работы. В общем, если нигде в “Проекте» сильно не ошиблись и прораб нормальный — результат будет более менее предсказуем. Примерно по этой схеме — требования — проект — смета — собственно сами работы - исполнительная документация - обучение эксплуататоров— приемка работ (с экспертизами и даже испытаниями если нужно) не так давно в одном высокоразвитом государстве строили все подряд — автомобили - дома-заводы-космические корабли, атомные электростанции и прочие “изделия».
И для каждой отрасли были придуманы ГОСТы, требования которых было нарушать было весьма небезопасно для нарушителя. Особенно на стройке. Особенно атомной станции. И такие требования были придуманы в том числе и для создания информационных систем. А именно — ГОСТ-34 и ГОСТ-19. В которых состав и содержание документов описывалось в явном виде. И где «Требования к системе» и «Техническое задание» отличались по содержанию как небо и земля. Но вот что удивительно — в недавнем прошлом требования этих ГОСТ перестали быть обязательными для выполнения сторонами проекта. Это прямо удивительное дело — на фоне нарастающих бюджетов и дефицита квалифицированных людей в этой отрасти — стандарты их деятельности обязательными не являются. Точнее для того, что бы эти ГОСТы стали требованиями — нужно отдельный нормативный акт по конкретной отрасли, группе проектов и т. д. Ну или две стороны договора напишут такое требование в договор, находясь в здравом уме и твердой памяти. То есть требования этих ГОСТ применяются весьма выборочно. Сделано это весьма неспроста, что открывает еще более невиданные возможности по извлечению сверхприбылей из государственного бюджета РФ даже по сравнению с торговлей «лицензиями». Познакомим тебя, Василий, с некоторыми приемами более детально.
Первые два параметра договора являются легко проверяемыми и в общем и целом прозрачны. Можно конечно оформить приемку работ передним или задним числом к какому нибудь празднику с целью получения заранее забюджетированной премии. Или неполучению по шапке за просрочку. Но это можно несложно проверить. Заплатить же денег по договору сверх утвержденного бюджета то же весьма занимательная и нетривиальная процедура.
Остается одно — игры с объемом работ и себестоимостью их выполнения. Процедура обычно выглядит примерно так — две высокие договаривающиеся стороны принимают решение договориться и договариваются. После чего сторона Заказчика проводит внутреннюю процедуру обоснования необходимости какой нибудь автоматизации. Или внедрения. Или даже цифровой трансформации. И кладет в бюджет некую сумму, согласованную с Исполнителем за рюмкой чая. Откуда берется эта сумма и как она обосновывается ДО появления “Технического Задания» — это одна из загадок бюджетирования госпредприятий. И ее мы пообсуждаем чуть попозже. А пока, после утверждения суммы в бюджете, Заказчик пишет фантазию на тему «Технические требования» и играет конкурс.
Фишка №1 Условием этого конкурса является написание «Технического задания» Исполнителем. В процессе работ по договору. Что самое неожиданное — так это рекомендация в самих ГОСТ именно так и делать — писать ТЗ силами Исполнителя. То есть рекомендуется, Вася, делать проект на дом силами организации, которая его потом строить > IT LAW: будет. Вот как ты думаешь — что тебе в ТЗ напишет стройконтора, у которой в штате полно плотников и ни одного каменщика? Или наоборот. Ясное дело - тебя по крайней мере попробуют убедить что строить нужно только из дров или только из кирпича. И если у тебя компетенции в этой области нет — будешь строить из того, что выгодно Исполнителю. Так вот в проектах ИТ — то же самое. Исполнитель, ясное дело — напишет в ТЗ то, что ему нужно. А если Заказчик компетенциями в вопросе не обладает или в доле — то он это и подпишет. Даже если ТЗ будет на трех листиках...
Фишка №2 Как ты Вася понимаешь, ни один нормальный строитель не видя самого проекта и сметы к нему — не возьмется ничего строить и ни в какие конкурсы играть не будет. И попросит оформить разработку «бумажной части» стройки отдельными работами. Что вполне логично — добавление в смете слова «золотой» перед словом «унитаз» может несколько увеличить затраты Исполнителя. Причем тут возможна масса нюансов — унитаз может быть просто «позолочен золотым покрытием толщиной такой то пробы металла такой то». А может быть «цельнолитым из металла пробы не ниже такой то». Улавливаешь, Вася, разницу в стоимости? Так вот в ИТ — такое случается сплошь и рядом — подрядчики берутся делать проекты не имея ТЗ и Сметы. Явление объясняется просто -если конкурс выиграл «свой» подрядчик то и ТЗ и объем работ к нему будет согласованы такими, что маржинальность Исполнителя может составить 200-300-1000%. А вот если конкурс выиграл подрядчик «залетный», а такое бывает — кто-то в надежде залезть в крупную контору демпинганул и по закону ему отказать нельзя — то и в ТЗ ему напишут «семь верст до небес и все лесом». И слово «золотой» перед словом «унитаз» напишут точно. Ну или напишут что «система закупок должна работать в режиме реального времени». Или надежность 99,9999%. В общем в ТЗ можно написать все. Ну или не написать. Заметь, Вася — ТЗ в этом случае обычно пишется по согласованным между двумя сторонами шаблонам, а вовсе не по ГОСТ. И может реально занимать три листочка. А может и 3000. Если подрядчик начинает бузить на этом этапе — то он просто не сдает этап написания ТЗ, утопая в лавине замечаний и поправок. Ну и далее везде — суд, реестр недобросовестных поставщиков двора его императорского величества. Ибо нечего на чужой каравай…
Ну да ладно. Предположим что документ «Техническое задание» да еще и по ГОСТ, откуда то появился и надо работу работать — код писать, тесты гонять, людей учить ну и т. д. И все эти работы потом принять и соответственно заплатить денег.
Фишка №3. Часть или весь объем работ выполняется штатными сотрудниками Заказчика. Ну вот в самом деле — надо же твоих местных как то приобщать к полезному труду. И под предлогом - «готовимся к самостоятельной эксплуатации системы и повышаем бесплатно свою квалификацию” – ставим и настраиваем пару сотен серверов и рабочих станций силами штатных сотрудников Заказчика. Пусть эта работа и явно написана за Исполнителем. Или сами пишем документацию, или… да в общем много всякой ручной и нудной работы можно повесить на сотрудников Заказчика, особенно если они согласятся добровольно и сразу после слов начальников - «это прямое указание — несогласные будут уволены, распремированы и далее со всеми остановками».
Фишка №4. Зачем что то делать самим, если можно взять готовое?
В мире написано уже столько всякого программного обеспечения, что найти что-то готовое или полуготовое — вполне себе возможно. Как и готовый проект дома. И тем самым сильно сократить затраты Исполнителя на написание собственно текста программы. Бывает, что и Заказчик и Исполнитель заранее знают какую программу они будут запускать в эксплуатацию и ТЗ и все остальное пишут заранее и под эту программу. Но предметом работ по договору, будет являться ясное дело — разработка программного обеспечения. То есть дрова и все > IT LAW: остальное для сборного дома уже напилены и лежат бесплатно, а Исполнителю нужно только собрать готовый дом. При этом вся документация на такой дом уже готова. А ты, Вася, за все это заплатишь как за индивидуальный проект лично для тебя. И это может реально уменьшить себестоимость Исполнителя в разы.
Фишка №5 Больше бумаги — чище ж… Никто не мешает Исполнителю и Заказчику в процессе работ разработать документ под названием «Методические рекомендации по разработке концепций цифровой трансформации определенных областей государственного и муниципального управления». Или «Концептуальное проектирование методических рекомендаций в целях понижения рисков управления муниципальными территориями с использованием механизмов цифровой трансформации». Ну или еще что то подобное. И написать такой документ в трех-четырех томах теперь может любая нейросеть за 5 минут. Причем если не вчитываться — то вполне правдоподобно. На это собственно и расчет — главное что бы такие документы не начали читать люди, разбирающиеся в вопросе. Вообще, Вася, если тебе в юридически значимых документах попадаются подобные слова, то тебе надо сразу обращать свое внимание на документы подобных названий и содержания по максимуму.
Перейдем к чуть более тонким материям.
Фишка №5 Как ты Вася, думаешь — кому принадлежат права на написанную за государственный счет программу? Вот как не удивительно, если передача прав на программу не предусмотрена отдельно — то права могут вполне себе оказаться у Исполнителя. И он, само собой, может предусмотреть, что использование программы, ты не поверишь, стоит каких то регулярных денег. В размере — сколько совесть позволит. А если Заказчик еще и в доле — то этот размер может быть весьма и весьма приличным. Что и обеспечивает высоким договаривающимся сторонам постоянный приличный доход прямо из госбюджета на долгие годы. Ну и как можно крутить Заказчику руки с помощью исключительных прав на ПО — мы уже обсудили в первой части этого марлезонского балета.
Фишка №6 Для того что бы Заказчик слишком быстро не обрадовался преимуществам цифровой трансформации и не убежал далеко вместе с государственными деньгами от Исполнителя - можно ему отдать не весь исходный текст программы. Или вообще не совсем тот текст. Ну вот как не отдать тебе схему вентилей и выключателей - автоматов в новопостроенном доме. Что бы ты либо сам методом тыка выяснял что к чему, либо опять таки заплатил денег за вызов Исполнителю. Причем если надо переделать что-то серьезное — надо что бы следующий Исполнитель потратил кучу времени (и кучу денег соответственно то же) на выяснение того что и как работает сейчас… Ну или текущий Исполнитель будет всю оставшуюся жизнь выигрывает конкурсы на поддержку, поскольку ему лишние деньги и время на выяснение того что и как сейчас работает — не надо тратить.
Фишка №7. Любую сложную систему требуется сопровождать и обслуживать. Сохранять резервные копии, чего то настраивать, чего-то дорабатывать и прочее и прочее. И желательно все это делать силами сторонней организации, ибо в своей содержать в штате квалифицированных сотрудников типа слишком накладно. А вот договор на «сопровождение» желательно заключить на условиях абонентской платы. Типа за 100 рублей в месяц Исполнитель обязан… ну и так далее. Только вот количество обращений пользователей (и естественно, объем выполняемых работ) тянет максимум рублей на 10. Ибо правильно построенная система требует минимальных трудозатрат на обслуживание вообще. И это хороший шанс исполнителя получить 100% доходной части договора при практически нулевых расходах. Кстати, если Исполнитель на таком проекте окажется «залетным» - то он скорее всего утонет в потоке отказов, поскольку такая ситуация запросто может быть заранее «спроектирована» «своим» Исполнителем и Заказчиком и соответствующие «технические решения» могут быть легко реализованы системе.
Фишка №8 Управление проектом. Ты Вася, опять не поверишь, но в высокоразвитой цивилизацией были ГОСТИрованы сами работы по созданию различных информационных систем. Да-да. Прямо так и было написано — что нужно делать в проекте автоматизации и , самое главное, какие документы при этом оформлять. Кто это должен делать, когда это нужно делать и так далее. Как ты, Вася, понимаешь, сделано это было так же не спроста, а для того что бы процент не успешных проектов (и соответственно, списанных в никуда государственных денег) был поменьше. Что бы твоим историческим коллегам можно было установить — это действительно сработали проектные риски, накосячили работники, или таки бененфициарами мероприятия стали частные лица? В первом случае последствий обычно не было, деньги действительно списывались в никуда. Во втором случае — конкретные персоналии получали по голове в виде снятия с должностей и лишения премий. То есть обделывались легким испугом. А вот если выяснялось что деньги вдруг оказались в карманах частных лиц и при этом результат работ так себе — вот тут сроки были не малые. Ибо если делали, старались, но не получилось и не разбогатели — это одно. А если не делали, не получилось — и вдруг разбогатели — это совсем другое. И вот что бы не сажать всех без разбору — как раз и были придуманы Госты по управлению проектами. Что бы было что предъявлять экспертам, твоим коллегам и вообще полезно для обмена опытом в масштабах государства, хотя бы для того, что бы не повторять одно и то же в разных ФГУП-МУП. Ну и естественно, если не платить специально выделенному руководителю проекта, не тратить времени на планирование, не оформлять протоколы совещаний и так далее — можно а) неплохо сэкономить, б) спрятать концы в воду. Поэтому несоблюдение рекомендаций ГОСТ по ведению проектов — это еще один весьма нехороший признак.
Фишка №9 Ну и наконец — можно же вообще не выполнять некоторые предусмотренные работы в принципе? Вот совсем — взять и не сделать.
Таким образом, Вася, и приключается весьма странная ситуация — когда по мировой статистике от 25 до 50% денег на проекты в ИТ должны быть либо списаны, либо возвращены в бюджет Заказчика. Что по идее должно еще раз удвоить твое, Вася денежное довольствие..