BoatmansHome: Заметки/ПочемуТакДорого ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

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


Оглавление

Когда я слышу слово «методология», моя рука тянется к кобуре ©

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


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


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


В большом проекте есть ролевое разделение, но оно не так велико, как в машиностроении или строительстве.


Можно видеть, что средняя требуемая квалификация не растет с ходом проекта, а совсем наоборот. Именно поэтому, часто люди уходят, когда начинается рутина сопровождения.


В среднем количество времени, потраченного на работу в проекте, обратно уровню квалификации для этой работы.
Уровень зарплаты от самой высокой до самой низкой квалификации падает на порядок.


Есть ли в машиностроении роль, совмещающая все эти работы?
Конечно да:


И вот теперь давайте посмотрим экономику вышеперечисленных закономерностей.


На картинке ниже показана зависимость между квалификацией и временем, вложенным в проект.


file:compmoney.png


Что мы можем здесь увидеть.


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



В чем же дело?
Дело в переходах между ролями, помеченных точками 1,2,3.
К сожалению, нам очень сильно портят жизнь лозунг «каждому проекту своя методология» и кривая накопления дефектов.


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


Такова драма сегодняшних (2014г.) информационных технологий.


Выводы каждый может сделать сам.
А я сформулирую свои:


***


Я знаю, что софт как будто сложнее машин и зданий/сооружений.
На это могу привести следующие выкладки.


У меня за окном строят небольшой семиэтажный четырехподъездный дом, в стены которого укладывают от 500тыс до 1млн кирпичей, 50тыс пеноблоков. Каждый кирпич ставится ровно на свое место руками, перед этим под него наносится скрепляющий раствор. Это лишь поверхностный расчет, так в кирпичной кладке есть не только кирпичи и раствор.
При заливке каркаса в решетку сваривается до 50 тыс. стержней арматуры, которые скрепляются сварными швами в количестве 500тыс., устанавливается несколько тысяч щитов съемной опалубки.
Для заливки перекрытий, устанавливается в общей сложности несколько тысяч стальных подпорок, несколько тысяч щитов и несколько сотен поддерживающих их лагов.
Потом надо добавить облицовочную плитку, элементы покрытия крыши, десятки тысяч элементов внутренней начинки от проводов и розеток (патронов, лампочек, плафонов и т.п.), плитки в ванную, до шурупов, гвоздей и прочих мелких крепежных деталей. И там есть много того, о чем я вообще не знаю или не помню.


Если даже грубо загнуть по пальцам, то число конструктивных элементов в этом маленьком домике будет колебаться от 2 до 3 миллионов. Это как раз совпадает с числом строк кода в 1С по данным википедии. Ядро Linux 2.6.3 имеет 12'606'910 строк кода.


При проектировании этого дома успешо взаимодействовали примерно 20 проектных специальностей. При возведении скоординированно работают еще примерно 10–20 рабочих специальностей.
При проектировании промышленного объекта типа газоперерабатывающего завода взаимодействуют 40–50 специальностей. А число элементов в таком объекте вполне дотягивает до нескольких десятков миллионов, что соответствует по размеру Windows 2000 (20млн строк) или Windows XP (45млн строк).
Из машиностроительной области, например в самолетах Boeing от 3 до 7млн деталей, каждая из которых поставлена на свое место чьими-то руками. А в 100 самолетах, соответственно, от 300 до 700 млн. деталей, которые все так же ставятся каждая на свое место руками.


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


У софта остается аргумент про великую нелинейность. Мол, изменение одной строки кода может вызвать изменение поведения всей системы.
Такие случаи нам известны и в строительстве и в машиностроении:


Я не отрицаю сложность современного ПО, проблемы совместимости, наличие феноменов, подобных аду DLL. Однако, все эти трудности радостно были созданы своими руками в погоне за унификацией там, где, возможно, ее следовало бы избегать.
Подобные проблемы бывают и в строительстве и в машиностроении и обходятся они гораздо дороже, чем в ИТ. Однако никому в голову не приходит гордо выпячивать грудь и говорить о своей исключительности. Все обычно понимают, что облажались или инженеры с проектными решениями или менеджеры с планированием.


***


Поиски идеальной методологии разработки ПО начались достаточно давно. Хотя, конечно, длятся гораздо меньше, чем в машиностроении и строительстве. По крайней мере «Мифический человеко-месяц ...» датируется 1975ым годом (сегодня этому труду 29 лет).
Самая главная причина, почему эти поиски не завершатся успехом при текущем подходе заключается в том, что обычно все ищут там, где ничего не было спрятано.
Сейчас объясню.

Великий обман информационных технологий

Если я спрошу вас, сколько лет ИТ, что вы ответите?
Известно ли вам, что информационные технологии существуют с тех пор, как вид homo sapiens овладел устной речью?
Реальным толчком в развитии ИТ послужило изобретение счета и письменности (а не цифровых вычислительных машин, как думают некоторые), и за последнюю тысячу лет в самих информационных технологиях мало что поменялось.


Что же мы наблюдаем последние 50 лет?
На самом деле в середине 20го века мы видели бурный рост технологий цифрового хранения, обработки и передачи данных.
Надеюсь, все отличают данные от информации ?


Задачи сбора, накопления, обработки, передачи, поиска и использования информации развивались в своих предметных областях: в торговом деле, географии, управлении, библиотечном и патентном деле, юриспруденции, прикладной математике и инженерном деле, дипломатии, связи и т.п. Все прикладные информационные технологии (я имею ввиду схему потоков данных, обслуживающих ту или иную деятельность) не были рождены достижениями цифровых технологий.


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


Сумма исходных данных для успешного построения автоматизированной системы находится в двух областях:

Когда мы строим методологию по разработке ПО мы вычеркиваем первый пункт и отрезаем половину исходных данных. Жалкие попытки автоматизаторов отгородиться от большого бурлящего мира бизнес-требованиями или другим подобным документом заканчиваются провалом, так как любая модель содержит лишь часть сведений о реальной действительности. И до завершения проектирования никто не может предсказать, которая часть сведений о действительности необходима для построения системы.


Формируя ожидания, важно не путать две вещи:


Я часто вижу вокруг себя увлечение первым и полное равнодушие ко второму. И это естественно, так как софт – это именно цифровые средства.


Что делать:

UPD

И вот продолжение по этой теме: /Заметки/ГлавнаяПроблемаИТПроекта


 
Один файл.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]