Pull to refresh

Разработка ПО: 3. Теплое и мягкое

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

image

Странно, но методики, которые родились непосредственно в области разработки ПО совсем не похожи на пришедшие извне.

Например достаточно простой SCRUM, описание которого вполне можно уместить на листок A4, но которым пользуется CERN. Или Agile, который можно описать десятом абзацев где содержатся весьма общие и идеалистические принципы в соответствии с которой был сделан GitHub и много других клевых штук. Можно ли их использовать в строительстве? А при создании самолетов?

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

(в качестве иллюстрации лицо типичной универсальной методики авторства RuxxSilver, которое на первый взгляд выглядит весьма привлекательно и правдоподобно)



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

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

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

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

Скажите, только честно, кто успешно использует RUP, так, чтобы это было больше нежели набор общих принципов, помещающихся на листке бумаги? У меня на полке лежит книжка по RUP и еще несколько в электронном виде. К сожалению, там не сказано, кто так делает. Интернет тоже не очень помог мне ответить на этот вопрос.

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

Универсальность — это не всегда хорошо, но всегда хорошо звучит.

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

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

Когда мы моделируем реальный мир мы имеем дело с его объектами, их измеримыми свойствами и их взаимоотношениями.

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

Когда мы считаем это тождественным, то мы начинаем путать теплое и мягкое.

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

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

В наименее затратном виде камни будут унифицированы: камень №1, камень №2, камень №3… В реальном мире не существует идентичных камней. Чтобы описать все камни нужно их полностью воспроизвести. Мы можем ввести в нашу систему множества камней, сгруппированных по весу, и с ее точки зрения унифицированность камней сильно уменьшится, нам будет проще определить к какой из групп относится конкретный камень в реальном мире. Для каких-то задач, информация о том, влезет ли эта группа камней в грузовик, может быть полезной. Вопрос в том, какая степень детализации окажется полезной и насколько эта польза будет сочетаться с затратами.

Чем более тиражурем и неспецифичен объект, тем проще обрабатывать информацию о нем. И тем меньше нужно работы, чтобы создать ПО, которое ее обрабатывает и преобразовывает.

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

Резюмируя: есть разные цели, и в соответствии с ними есть некоторые принципы: как писать неплохое ПО, как создавать модели реального мира и как извлекать экономическую прибыль из результата. Если кто-то претендует на смешение этих вещей и универсальные методики, то это относится к зоне экономических целей, потому что “универсальный” звучит круто, и продается лучше, чем “не универсальный”.

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

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

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

И если молодой руководитель IT проекта или руководитель группы разработки сейчас видится нам действительно молодым человек в возрасте от 15 до 30 лет, то молодой архитектор (который проектирует здания) попадает скорее в возрастные рамки 30-45 лет и открыв альбом “20 молодых архитекторов” первая ваша мысль будет: “А кто все эти старперы?!”. Просто потому что 5-7 лет обучения и 10 лет практики это достаточно мало даже для того, чтобы хорошо спроектировать даже хрущевку.

В следующей заметке я хочу спуститься на уровень ниже и попробовать на прочность такие понятия, доставшиеся нам в наследство, как заказчик и требования.
Tags:управление проектомменеджментit-индустрия
Hubs: Project management
Total votes 49: ↑41 and ↓8 +33
Views1.1K

Comments 44

Only those users with full accounts are able to leave comments. Log in, please.

Popular right now