IT ManagerИТ в бизнесеЧто хочет бизнес

Крошка сын к отцу пришел, или PMBOOK против УК

Михаил Сусоров | 03.02.2019

Крошка сын к отцу пришел, или PMBOOK против УК

Статью эту я пишу по мотивам «Круговорота проектов в природе», обсуждений в клубе 4 CIO и дела Александра Селютина.

Третий сорт ничуть не хуже первого.

Рекламное объявление в русской печати, 1908 г.

И для начала приведу пример из прошлого. Проводим очередные работы по исправлению производительности очередной системы. Система обеспечивала сбор некоторой информации и генерацию отчетности по весьма немаленькой и частично военной отрасли нашей промышленности. В процессе решения задачи было выяснено много всего, что обычно выясняют в таких случаях – и размер базы не соответствует «размеру» оборудования, и настройки этого оборудования прямо противоположны решаемой задаче, и в коде системы много всего неоптимального, а местами и прямо запрещенного к использованию вендором. Ну и какой-либо мониторинг работы системы отсутствовал вовсе. Стандартный, в общем, набор. В договоре с подрядчиком параметры производительности описаны весьма размыто, гарантийный срок уже кончился – все как всегда.

В процессе такой работы, как обычно, бывает множество диалогов типа: «Вас, коллеги, не смущает, что база отчетности целой отрасли размером в терабайты работает на почти обычной «персоналке»?» – «Нет, не смущает, нам же никто не написал, какое оборудование нужно». – «А как вы ее работоспособность отслеживаете?» - «А как пользователи начинают звонить с утра из Владивостока, так и отслеживаем». – «А вы не в курсе, коллеги, что ввод данных можно ускорить раз в 10 при затратах в 10 копеек? И освободить пару тысяч операторов от работы в режиме ожидания ответа на клик мышки…» – «А что, так можно было?» и тому подобное.

По результатам исследования вопроса готовятся рекомендации, отслеживается их выполнение, параметры системы приходят к заданным, среднестатистическим для таких систем, параметры ее работы меряются и рассылаются всем заинтересованным по расписанию и событиям. То же все как обычно...

Не забывайте о качестве. Гроб, например,

должен быть сделан так, чтобы его хватило на всю жизнь.

Курт Тухольский

Но вопрос: «Можно ли считать качественными такие услуги, оказанные по запуску системы в эксплуатацию?» – остался для меня тогда открытым. А вопрос: «Что такое «качество услуги»?» – стал более актуальным. Интересующиеся данной проблематикой обязательно отметят, что в определениях, даваемых этому понятию, часто встречается прилагательное «предполагаемые» применительно к существительному «потребности», что делает большинство таких определений неприменимыми на практике. На практике же, скажем, в судах, одним из самых популярных вопросов к экспертам является «Соответствует ли результат работ условиям договора?» – из чего и можно сделать предварительный вывод, что качество при создании ИТ систем – это соответствие формальным требованиям. Причем требованиям «здесь и сейчас», в конкретных обстоятельствах на конкретную дату, которые и фиксируются в конкурсной документации и договорах. 

Но любой действующий РП расскажет вам немало историй, когда за время пути «собачка» требований сильно «подрастает», а вместе с ними должны расти сроки и бюджет. И процитирует соответствующий раздел из любых рекомендаций по управлению проектами. 

В обратном, предельном, случае, по ходу реализации смысл работ может быть утрачен вовсе, и проект нужно остановить и закрыть. То есть изменению в процессе работ подлежат те самые «существенные условия – сроки, объем, цена» договора, который был заключен по конкурсной процедуре. В больших коммерческих структурах такие изменения в договорах происходят непросто и не быстро – в них достаточно своих контролирующих и проверяющих органов. Но если заказчику действительно нужен результат работ и он способен бороться с внутренней бюрократией – то происходят. А вот в работах и услугах по ФЗ 223 и ФЗ 44 такие изменения являются отдельной, интересной процедурой, обычно с большим количеством участников как изнутри, так и снаружи. Но и в том и в другом случае, согласно тем же «руководствам по руководству проектами», есть большая вероятность получить в результате работ результат, отличающийся от первоначального, описанного в конкурсной документации. И для проектной деятельности – это нормальное состояние.

Подделать высокое качество не проще, чем подделать хорошую еду.

Уильям С. Берроуз

Теперь отметим несколько моментов, имеющих отношение к «качеству»: если в требования не написали время отклика системы – имеем случай описанный в примере. Если написали что-то вроде «время отклика системы 3 сек» и не уточнили, на что именно, то получим формальное несоответствие требованиям – отчеты заведомо считаются дольше. Если написали для системы бюджетирования «работа системы в реальном времени» – даже комментировать не буду. И если критически важные требования были упущены, то результат окажется невозможным применить на практике, хотя он полностью соответствует условиям договора. «Формально правильно, а по сути – издевательство», как говорил один известный в прошлом политик.

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

Качество – это когда все делаешь правильно, даже если никто не смотрит.

Генри Форд

Теперь перейдем к самому интересному и посмотрим на это все глазами контролирующих и проверяющих, которые должны оценить результат работ и его качество в соответствии с… чем? Если в коммерческих компаниях проверяющие, заметим, от бизнеса, сначала проверяют соотношение «общей полезности» результата для компании и понесенных затрат, а потом формальную часть, то государственные обычно делают все точно наоборот.

На входе и те и другие обычно имеют:

1. Конкурсную документацию.

2. Договор с приложениями в виде весьма вольно написанных «Требований» или даже «ТЗ».

3. Документы, созданные в процессе работ, включая протоколы различных совещаний, испытаний. Часто весьма приличного объема, в кубометрах.

4. Результат работ – собственно программу, реально эксплуатирующуюся на реальных аппаратных средствах. Принятую и запущенную в эксплуатацию года два назад и уже переделанную и «улучшенную» процентов на 30 в рамках договора сопровождения.

5. Акты и прочую приемо-сдаточную документацию.

Какой космической квалификацией в юридическо-айтишной области должен обладать проверяющий (и сколько их нужно для оценки среднего проекта), чтобы детально разобраться, какие работы по каким договорам были выполнены (и были ли выполнены на самом деле) и когда фактически, если текст программы – один? Насколько обоснованно предъявлялись и менялись требования к программе в процессе работ? Насколько обоснованно менялся бюджет и сроки работ? Насколько система соответствует потребностям бизнеса, если это коммерческая компания? И насколько соответствует требованиям документов, если это госорганизация?

Если результат не соответствует бизнес-потребностям – участников со стороны обычно просто увольняют либо не поощряют в рабочем порядке. А вот выявленное несоответствие результата требованиям документов организации, близкой к государственной, – начало весьма разнообразных, но почти всегда неприятных последствий. Я не буду перечислять тут статьи УК РФ, которые могут быть легко предъявлены участникам таких проектов, но пример того же А. В. Селютина заставляет сильно задуматься над сложившейся ситуацией (кому интересно – поищите «историю одного дела» в FB).

Если бы рекламодатели тратили на улучшение своей продукции те деньги, которые они тратят на рекламу, их продукция не нуждалась бы в рекламе.

Уилл Роджерс

На сегодня есть некоторый сложившийся набор мероприятий, позволяющий облегчить деятельность проверяющих и контролирующих, сделать работы в области государственных и около ИТ более прозрачными и понятными для контролеров. Часть этих мероприятий рекомендована самим законодательством, часть сформировалась в результате опыта различных работ в госструктурах. Но, как и любые дополнительные работы, эти мероприятия увеличивают сроки и бюджет проектов и поэтому практически нигде не выполняются. И не гарантируют отсутствие претензий. Но обозначившаяся тенденция может удвоить сроки и бюджеты в государственных ИТ, половина которых уйдет на реализацию «оборонительных» мероприятий. Что не совсем стыкуется с текущими тенденциями типа развития различных технологий, ускоряющих получение ИТ-результатов. И уж совсем никак не вяжется с задачей «цифровой экономики». А пока – ждем колоссального роста зарплат «риск-менеджеров», работающих в ИТ-проектах госструктур и расходов на «ИТ-оборону».

управление проектами

Горячие темы: Бизнес в цифре

Журнал: Журнал IT-Manager [№ 01/2019], Подписка на журналы

Об авторах

Михаил Сусоров

Михаил Сусоров

Член клуба 4CIO
Заведующий Центра правовой поддержки потребителей ИТ.


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Другие материалы рубрики

Мысли вслух

Можно ли, поняв, что половина информации не доходит до серого вещества, отсеиваемая «вратами сортировки», что-нибудь с этим сделать?
Уже довольно многие согласны с тем, что в крупных организациях необходимо создавать т. н. «службы заказчика», предоставляющие аутсорсинг ИТ-услуг.
На первой встрече по первому проекту, на котором я выступала в роли аналитика, я молчала, хмурила брови и писала что-то в блокнот. В общем-то, я и сейчас на встречах с бизнесом хмурю брови и пишу в блокнот. Но только раньше я это делала от неопытности, а теперь от неожиданности.

Компании сообщают

Мероприятия

15.07.2020
Создание и вывод на рынок hardware-продукта

Санкт-Петербург, онлайн-трансляция

17.07.2020 — 18.07.2020
Лаборатория: бизнес как система.

онлайн, 10.40 -18.00 (мск)

23.09.2020 — 24.09.2020
Форум Индустриальной Роботизации

Санкт-Петербург, Чернорецкий пер. 4-6