ИТ - проекты: «Публикуем и обсуждаем» или
Ударим по ИТ – ротозейству и ИТ – профанации
открытой библиотекой и публичной экспертизой
Project «RITIL»:
Russian Information Technology Internet library (RITIL)
Открытая библиотека передового опыта по ИТ – проектам
План
Введение
1. Кто виноват? Анализ проблемы
2. Что делать? Как спасать ИТ – отрасль?
3. Технологическая карта. Этап 1
4. Возможные направления развития проекта
Заключение
Введение
Большинство ИТ – проектов проблемные и в открытом доступе отсутствуют:
корпоративные территориальные
сети связи \ системы передачи данных, распределенные ЦОД, серверные подсистемы, системы хранения
данных, системы управления и мониторинга, ITSM, хранилища данных, разработка и
внедрение ПО (от сетевого типа email, AD, биллинга до мега-прикладного типа ERP, торговых систем), систем информационной безопасности и др.
Одна из больших бед отечественной ИТ – индустрии – это минимизация повторного использования наработок, слабая методологическая проработка процессов проектирования. Что не проект – очередной «велосипед». Повторное использование наработок ограничено особенностями ИТ – рынка в России, отсутствием подходов к стандартизации и унификации на отраслевом уровне, закрытостью проектных решений.
Эффективность ИТ – проектов низкая, а их рентабельность сверхвысокая, что обусловлено, в том числе, особенностями "национального характера" российского ИТ строения.
Вместо принципа «Заказчик должен знать чего он хочет, а подрядчик знать то, чего действительно нужно Заказчику» сегодня господствует принцип: «Заказчику нужно внушить: сколько это должно стоить». Да и госЗаказчик сегодня "совсем не жадный".
Огромное число сегодняшних проектов реализуется как «относительно честный способ отъема денег»: проекты либо изначально задуманы как «холостые» \ «на дурочку» и предельно рентабельные или это «приходит в процессе». Часто проекты несут подрядчику возможность неплохо заработать, а заодно и научиться, как это делать. К сожалению, компетенции Заказчиков по защите своих интересов предельно низкие, сознательно или неосознанно.
Для решения задач:
а) «открыть глаза на реальность ИТ»,
б) обмен опытом на реальных проектных данных
предлагается первым направлением – это раскрытие и независимая публичная экспертиза ваших проектов. Следующим, возможно, будет формирование практических рекомендаций для Заказчика по контролю работ подрядчика, начиная с тендера, формирование золотого фонда - банка типовых проектных решений.
1. Кто виноват? Анализ проблемы
Основные
1.1 “Деньги – все, остальное ничто»
В подрядчике, как правило, борются две сущности «Разработчик» и «Бизнесмен». При этом обычно «творец» проигрывает «буржуа» и побеждает «сильнейший», т.е. деньги. У подрядчика вместо сделать что-то «очень полезное» для Заказчика получается сделать что-то «очень прибыльное» для себя. Это основной закон капитализма по-российски, за другие страны судить не берусь, хотя еще в «Капитале» К. Маркс заметил:
"Обеспечьте капиталу 10% прибыли, и капитал согласен на всякое применение, при 20% он становится оживленным, при 50% положительно готов сломать себе голову, при 100% он попирает все человеческие законы, при 300% нет такого преступления, на которое он не рискнул бы пойти, хотя бы под страхом виселицы". Другими словами: жадность «всея буржуазной Руси».
1.2 Best Practice против Заказчика
Часто Подрядчик использует свои опыт и знания как «Best Practice против Заказчика», т.е. как можно одурачить Заказчика, формально выполнив условия договора, но реально не предоставив ему законченного решения или «поддев его на крючок», среди них:
а) минимум документирования своего решения, или некачественная проектная документация: «налить воды», не отразить принципиальных моментов решения и др.;
б) планирование работ в таком виде, когда в середине проектирования выясняется, что для завершения необходимы объемные дополнительные работы по «отдельным договорам». Например, при первоначальных переговорах речь идет о всем объеме («под ключ»), а далее выясняется что «под ключ» либо только часть, либо «в упрощенном виде», а как надо – «так это же СОВСЕМ за другие деньги».
Примеры «Best Practice против Заказчика» рассмотрим отдельной темой.
Сегодня фактически у Заказчика нет надежной методологии организации контроля и инструментов по защите своих прав при ведении ИТ – проектов.
Например, мало кто работает по ГОСТ, хотя бы 34.ххх. Но именно ГОСТы стояли на защите интересов Заказчика. К тому же эти инструменты контроля должны постоянно совершенствоваться.
Другие
1.3 Получил «CIO» и «вертись как хочешь»
Коррупционная составляющая. Уверен, что коррупция в ИТ – сфере, не меньше чем в строительстве. Но это отдельная тема, здесь мы ее только обозначим. Для ее рассмотрения лучше создать отдельный сайт «Роспил-ИТ» ("роспилит"). Помните анекдот про новичка милиционера:
- Ты чего за зарплатой третий месяц не идешь?
- А что, еще и зарплату дают? Я думал: выдали пистолет (или полосатую палочку) и «вертись как хочешь».
Если сделать такой эксперимент: на должностях ИТ – директоров организаций Заказчиков ИТ – услуг, руководителей конкурсных комиссий, других постах «принимающих решение» перестать платить зарплату: многие места не оказались бы пустыми, не везде, конечно, но в большинстве госструктур уверен.
Кроме криминальной составляющей видимо работает принцип «мотивированного суждения», так CIO и не скрывают, что часто самовольно выбирают подрядчика «в интересах дела», например:
«Выбирая поставщика, я прежде всего выбираю партнера. Я ни разу не начинал тендер, не понимая, кто его выиграет. Безусловно, тендер нужен, чтобы довести до правильного уровня ожидания партнера, прежде всего по деньгам. Но партнера я всегда выбираю заранее. Выбор правильного партнеры – это важнейшее умение CIO, и его нельзя доверять случаю» см. «Учебник 4CIO» (М: Клуб 4CIO, 2011), с126.
Собственно эта цитата - уже нарушение авторских прав! Вот так и живем.
1.4 Секретность – как основное оружие
Как скрыть подлог? Конечно все засекретить. ИТ – проекты (наработки) никому не показывать, в ТКП – сплошные фразы «после прочтения съесть». Почему подрядчик боится огласки своих проектных решений? Что бы а) скрыть некомпетентность, б) уровень рентабельности.
Более того, многие свои проекты подрядчики не показывают новым Заказчикам, ссылаясь на подписанные ранее соглашения о неразглашении (NDA) или объясняя возможностью утечки ее к конкурентам. Как правило, сложности и с референс – визитами к предыдущим Заказчикам.
Собственно против этого, в основе и лежит идея. Все тайное когда-нибудь становится явным. Поэтому скрыть ахинею или в чистом виде «развод на деньги» - не выйдет.
Конкурентная борьба, подписание соглашений о неразглашении проектных решений и отказ от их публичного обсуждения, закрытые методики проектирования, - эти заявления для сокрытия размеров бардака и «гири» тормозящие технологическое развитие страны.
Собственно: «дурят нашего брата, и безбожно».
2. Что делать? Как спасать ИТ – отрасль?
2.1Цели:
а) Раскрытие информации. Площадка для обмена опытом на реальных проектных данных. ITIL по – русски, библиотека опыта передового и не очень;
б) Независимая публичная экспертиза ваших проектов. ИТ – аудит (технический);
в) выявление качественных проектов (компаний - разработчиков), продвижение типовых решений и их тиражирование, унификация, типизация, массовость на основе популяризации открытой библиотеки ИТ - проектов;
г) в будущем, стандартизация решений, Рекомендации и Best Practice в защиту интересов Заказчика.
Раскрытие информации и независимая экспертиза ИТ – проектов, в целях оптимизации ведения проектов на основе максимального (повторного) использования наработок (своих и чужих).
2.2 Шаги
а) создаем сайт (площадку), куда могут все выкладывать ИТ - проекты компаний. Таким образом, сформируется библиотека ИТ – проектов.
б) желающие и созданная на общественных началах экспертная комиссия будет проводить независимую экспертизу выложенных проектов.
в) в будущем – формирование рекомендаций по ведению проектной деятельности.
Возможно будут присутствовать некие элементы IT – wikileaks, т.к. не всем может нравиться правда об их реальной проектной деятельности и эксплуатационной практике и многих не устроит объективная оценка приобретенного «ИТ - хлама» или лучшие практики « впаривания» . Выкладывать проекты и давать им оценки можно будет анонимно, из проектов можно будет вытирать названия компаний.
В идеале, каждый подрядчик должен в открытом доступе выкладывать свои проекты. Так будет оцениваться его рейтинг. Например, некоторые ЦОД в прямом режиме транслируют на публичном сайте все возникающие неисправности. Что-то подобное, надеюсь, будет и в проектной составляющей.
Обозначаем
проблемы:
А) общий взгляд на
RU-IT: она в такой же яме как и отечественный автопром, авиапром и всё
остальное в России, кроме, нефтегазового насоса, вывоза леса и подобных
сырьевых направлений. В яме и IT-образование и профессиональная IT –
разработка. Что-то конечно есть, например, очередное чудачество http://besttoday.ru/read/3374.html но это скорее
похоже на конверсионные игрушки.
но уверен, это очередной «выгодный проект», не более.
Б) Конкретная
проблема. На мой взгляд, качество IT
– проектов предельно низкое, их стоимость «астрономическая», повторное
использование стремится к нулю. Это все три взаимосвязанные вещи: повторяемость
(плюс стандартизация и унификация) – массовое использование (повышение
качества) – снижение цены (доступность для массового использования).
Собственно об этом и на станицах блога: Russian Information Technology Internet library (RITIL)
Постановка
задачи первого этапа:
А) Создание
библиотеки IT – проектов на интернет ресурсе (в открытом доступе), где
сознательная IT - общественность наполняет библиотеку имеющимися авторскими
материалами
Б) экспертиза IT – проектов. Можно и так:
Объекты: IT – проектов из
жизни
Предмет исследования: их анализ, включая
Б1) выявление просчетов, элементов профанации (часто из интернет
не к месту копируют целыми разделами для "листажа")
Б2) выявление типовых качественных решений для повторного
использования лучших системотехнических решений и, таким образом, циклического
"улучшайзинга". Популяризация и накопление опыта через банк проектов.
СХЕМА: берем типовой проект, разбираемся, адаптируем под свои
нужды и не забываем поделиться результатом для обогащения Best Practice.
Собственно,
корневая идея схожа с библиотекой ITIL - британскими Best Practic-ами по ITSM
(собственно оттуда и название RITIL с небольшой корректировкой).
Плюс
к этому: краусорсинговый
IT-аудит (crowdsourcing). На мой взгляд профессиональный IT – аудит:
А) безумно дорог
Б) на столько же
несостоятелен (могу показать примеры).
Плюс
к этому: элементы IT – wiki leaks, т.к. все и всё скрывают, прежде
всего, свою халтуру и жадность (астрономическую рентабельность).
Решение задачи: создаем Web ресурс с форумом, где
А) выкладываем реальные
IT – проекты
Б) обсуждаем, оцениваем
Для первого этапа этого, думаю, достаточно.
Пункт А – скорее
организационный
Пункт Б – скорее
исследовательский
Действовать планируется в
направлении:
А) привлечь внимание IT
– общественности к бардаку в ИТ – отрасли и отсутствию повторного использования
IT – проектов
Эти сферы прошли период «детских болезней», теперь очередь за
ИТ. Лечить её нужно, а кроме нас некому.
3. Технологическая карта. Этап 1
Основные элементы решения:
- Банк проектов (публичный архив проектов, в том числе с элементами IT - wiki leaks)
- Общественный контроль
- Публичная экспертиза, "краусорсинговый IT-аудит", crowdsourcing
- Повторное использование наработок, обмен опытом
4. Возможные направления развития проекта
Заключение
На протяжении двух десятилетий
«буржуазно - демократических реформ» руководством отраслей и «мужами»
отечественной ИТ – индустрии продемонстрировано пренебрежение к отраслевой и
межотраслевой типизации ИТ – решений, игнорированы создание банков проектов,
внутри и межотраслевой обмен опытом (проектами). Пока мы наблюдаем только
сокрытие информации и вынужденное многократное изобретение очередного
«велосипеда» с неизбежным попаданием «на те же грабли» (детские и взрослые), а
также проекты с астрономическим бюджетом и неадекватным полезным выхлопом,
разбазаривание народных средств и неэффективное использование творческого
потенциала ИТ – специалистов.
Сегодня накоплена масса проектов, но она не "работает", лежит мертвым грузом в ИТ - чулане. Ее использование способно привести к мощному технологическому рывку. В то же время, некачественные, халтурные проекты должны быть выявлены, в интересах повторного "неиспользования", преступные схемы их "жизненного цикла" должны быть преданы огласке.
Очевидно, что «верхи не хотят». У Мега - босов было достаточно времени на "осознание и просветление", но ничего не сделано. Следовательно, начинать нужно
«снизу». Кто спасет российскую ИТ – индустрию, если не ты? Выкладываем
имеющиеся ИТ – проекты, коллекционируем ссылки на них, делимся опытом, вносим
реальный вклад в становление отечественной ИТ – отрасли.
Спроси себя сам: что
ты сделал для спасения ИТ – отрасли? Если не ты, то КТО?
Skeptic-ru skeptic.ru@gmail.com апрель 2012
Вопросы:
Есть ли, что подобное?
Есть ли библиотеки ИТ – проектов? (если ДА, то где?)
Дополнительно:
Кратко, пример «подвигов» системных интеграторов:
А) "GPL – цена". Заказчик часто мониторит цены на закупаемое оборудование и ПО, чтобы «не переплатить». Ему подсказывают мониторь по GPL – цене (Global Price List, «глобальный список цен»). Реально интеграторы забирают со склада в Москве у дистрибьюторских центров IT-оборудование со скидкой 50-70%, а реализуют по ценам, близким к GPL. GPL – изначально подразумевает «потолочную» цену. Если Заказчик – бюджетник, то в итоге эту разницу платим мы с вами – налогоплательщики. У цепочки системный интегратор - дистрибьюторский центр существуют специальные средства по сокрытию этих схем, например, для каждого крупного гос - Заказчика ведется свой прайс – лист. Когда интегратор запрашивает у дистрибьютора цены нужно обязательно сказать «для кого поставка», это нужно чтобы «не засветить» цены. Напрямую Заказчику дистрибьютор не продает. Это скорее преступный сговор, нежели «честная конкурентная борьба». Проверить можно, определив по каким ценам, была поставка и какое ее отличие от GPL, далее путем оценки общерыночной скидки на данное оборудование можно сделать вывод. На «тыжелое» (мощное, дорогостоящее, редкое), как правило, скидки более 70% от GPL. Но реальную закупку не проверите, все закупочные документы будут «в порядке».
Б) Для некоторых крупных Заказчиков работает схема: группа подрядчиков по сговору (как правило, с участием Заказчика) распределяет себе регионы (другие «куски») и в них работает. Формально при этом конкурсы проводятся, но за «свой» регион подрядчик для всех остальных готовит сам «технико-коммерческие предложения» и, соответственно, выигрывает. Проверить можно путем анализа, кто в каком регионе побеждает.
Продолжение или пояснение замысла RITIL «методом аналогии»
Задаваемые вопросы по RITIL
