Любой действующий РП расскажет вам немало историй, когда за время пути «собачка» требований сильно «подрастает», а вместе с ними должны расти сроки и бюджет.
Статью эту я пишу по мотивам «Круговорота проектов в природе», обсуждений в клубе 4 CIO и дела Александра Селютина.
Третий сорт ничуть не хуже первого.
Рекламное объявление в русской печати, 1908 г.
И для начала приведу пример из прошлого. Проводим очередные работы по исправлению производительности очередной системы. Система обеспечивала сбор некоторой информации и генерацию отчетности по весьма немаленькой и частично военной отрасли нашей промышленности. В процессе решения задачи было выяснено много всего, что обычно выясняют в таких случаях – и размер базы не соответствует «размеру» оборудования, и настройки этого оборудования прямо противоположны решаемой задаче, и в коде системы много всего неоптимального, а местами и прямо запрещенного к использованию вендором. Ну и какой-либо мониторинг работы системы отсутствовал вовсе. Стандартный, в общем, набор. В договоре с подрядчиком параметры производительности описаны весьма размыто, гарантийный срок уже кончился – все как всегда.
В процессе такой работы, как обычно, бывает множество диалогов типа: «Вас, коллеги, не смущает, что база отчетности целой отрасли размером в терабайты работает на почти обычной «персоналке»?» – «Нет, не смущает, нам же никто не написал, какое оборудование нужно». – «А как вы ее работоспособность отслеживаете?» - «А как пользователи начинают звонить с утра из Владивостока, так и отслеживаем». – «А вы не в курсе, коллеги, что ввод данных можно ускорить раз в 10 при затратах в 10 копеек? И освободить пару тысяч операторов от работы в режиме ожидания ответа на клик мышки…» – «А что, так можно было?» и тому подобное.
По результатам исследования вопроса готовятся рекомендации, отслеживается их выполнение, параметры системы приходят к заданным, среднестатистическим для таких систем, параметры ее работы меряются и рассылаются всем заинтересованным по расписанию и событиям. То же все как обычно...
Не забывайте о качестве. Гроб, например, должен быть сделан так, чтобы его хватило на всю жизнь.
Курт Тухольский
Но вопрос: «Можно ли считать качественными такие услуги, оказанные по запуску системы в эксплуатацию?» – остался для меня тогда открытым. А вопрос: «Что такое «качество услуги»?» – стал более актуальным. Интересующиеся данной проблематикой обязательно отметят, что в определениях, даваемых этому понятию, часто встречается прилагательное «предполагаемые» применительно к существительному «потребности», что делает большинство таких определений неприменимыми на практике. На практике же, скажем, в судах, одним из самых популярных вопросов к экспертам является «Соответствует ли результат работ условиям договора?» – из чего и можно сделать предварительный вывод, что качество при создании ИТ систем – это соответствие формальным требованиям. Причем требованиям «здесь и сейчас», в конкретных обстоятельствах на конкретную дату, которые и фиксируются в конкурсной документации и договорах.
Но любой действующий РП расскажет вам немало историй, когда за время пути «собачка» требований сильно «подрастает», а вместе с ними должны расти сроки и бюджет. И процитирует соответствующий раздел из любых рекомендаций по управлению проектами.
В обратном, предельном, случае, по ходу реализации смысл работ может быть утрачен вовсе, и проект нужно остановить и закрыть. То есть изменению в процессе работ подлежат те самые «существенные условия – сроки, объем, цена» договора, который был заключен по конкурсной процедуре. В больших коммерческих структурах такие изменения в договорах происходят непросто и не быстро – в них достаточно своих контролирующих и проверяющих органов. Но если заказчику действительно нужен результат работ и он способен бороться с внутренней бюрократией – то происходят. А вот в работах и услугах по ФЗ 223 и ФЗ 44 такие изменения являются отдельной, интересной процедурой, обычно с большим количеством участников как изнутри, так и снаружи. Но и в том и в другом случае, согласно тем же «руководствам по руководству проектами», есть большая вероятность получить в результате работ результат, отличающийся от первоначального, описанного в конкурсной документации. И для проектной деятельности – это нормальное состояние.
Подделать высокое качество не проще, чем подделать хорошую еду.
Уильям С. Берроуз
Теперь отметим несколько моментов, имеющих отношение к «качеству»: если в требования не написали время отклика системы – имеем случай описанный в примере. Если написали что-то вроде «время отклика системы 3 сек» и не уточнили, на что именно, то получим формальное несоответствие требованиям – отчеты заведомо считаются дольше. Если написали для системы бюджетирования «работа системы в реальном времени» – даже комментировать не буду. И если критически важные требования были упущены, то результат окажется невозможным применить на практике, хотя он полностью соответствует условиям договора. «Формально правильно, а по сути – издевательство», как говорил один известный в прошлом политик.
Предположим, требования написали правильные, подробные, в процессе было минимум изменений, систему сдали в эксплуатацию с заданными требованиями параметрами, мониторингом и прочим. Но жизнь на месте не стоит – систему нужно сопровождать и учитывать требования, появившиеся в ходе эксплуатации. На что заключается следующий договор, в рамках которого в систему вносятся разные нужные изменения, ее своевременно чистят от мусора, занимаются профилактикой отказов и вообще делают с ней все правильно.
Качество – это когда все делаешь правильно, даже если никто не смотрит.
Генри Форд
Теперь перейдем к самому интересному и посмотрим на это все глазами контролирующих и проверяющих, которые должны оценить результат работ и его качество в соответствии с… чем? Если в коммерческих компаниях проверяющие, заметим, от бизнеса, сначала проверяют соотношение «общей полезности» результата для компании и понесенных затрат, а потом формальную часть, то государственные обычно делают все точно наоборот.
На входе и те и другие обычно имеют:
- Конкурсную документацию.
- Договор с приложениями в виде весьма вольно написанных «Требований» или даже «ТЗ».
- Документы, созданные в процессе работ, включая протоколы различных совещаний, испытаний. Часто весьма приличного объема, в кубометрах.
- Результат работ – собственно программу, реально эксплуатирующуюся на реальных аппаратных средствах. Принятую и запущенную в эксплуатацию года два назад и уже переделанную и «улучшенную» процентов на 30 в рамках договора сопровождения.
- Акты и прочую приемо-сдаточную документацию.
Какой космической квалификацией в юридическо-айтишной области должен обладать проверяющий (и сколько их нужно для оценки среднего проекта), чтобы детально разобраться, какие работы по каким договорам были выполнены (и были ли выполнены на самом деле) и когда фактически, если текст программы – один? Насколько обоснованно предъявлялись и менялись требования к программе в процессе работ? Насколько обоснованно менялся бюджет и сроки работ? Насколько система соответствует потребностям бизнеса, если это коммерческая компания? И насколько соответствует требованиям документов, если это госорганизация?
Если результат не соответствует бизнес-потребностям – участников со стороны обычно просто увольняют либо не поощряют в рабочем порядке. А вот выявленное несоответствие результата требованиям документов организации, близкой к государственной, – начало весьма разнообразных, но почти всегда неприятных последствий. Я не буду перечислять тут статьи УК РФ, которые могут быть легко предъявлены участникам таких проектов, но пример того же А. В. Селютина заставляет сильно задуматься над сложившейся ситуацией (кому интересно – поищите «историю одного дела» в FB).
Если бы рекламодатели тратили на улучшение своей продукции те деньги, которые они тратят на рекламу, их продукция не нуждалась бы в рекламе.
Уилл Роджерс
На сегодня есть некоторый сложившийся набор мероприятий, позволяющий облегчить деятельность проверяющих и контролирующих, сделать работы в области государственных и около ИТ более прозрачными и понятными для контролеров. Часть этих мероприятий рекомендована самим законодательством, часть сформировалась в результате опыта различных работ в госструктурах. Но, как и любые дополнительные работы, эти мероприятия увеличивают сроки и бюджет проектов и поэтому практически нигде не выполняются. И не гарантируют отсутствие претензий. Но обозначившаяся тенденция может удвоить сроки и бюджеты в государственных ИТ, половина которых уйдет на реализацию «оборонительных» мероприятий. Что не совсем стыкуется с текущими тенденциями типа развития различных технологий, ускоряющих получение ИТ-результатов. И уж совсем никак не вяжется с задачей «цифровой экономики». А пока – ждем колоссального роста зарплат «риск-менеджеров», работающих в ИТ-проектах госструктур и расходов на «ИТ-оборону».
