Какие уроки управления проектами и лучшие практики мы можем извлечь из машиностроения и строительной промышленности? [закрытый]
4 ответа
Давайте возьмем мост в качестве примера и сравним его с программным обеспечением.
Мост будет иметь меньше внешних характеристик. У него будут довольно строгие характеристики, но многие из них будут внутренними (например, прочность материала).
Он будет разработан людьми, которые знают, что проектирование моста не должно быть чрезмерно торопливым. В целом инженеры-строители будут пользоваться большим уважением со стороны своего руководства, чем разработчики программного обеспечения. Кроме того, инженеры-строители будут работать в гораздо более ограниченном пространстве. Есть не так много способов сделать мост, как система инвентаризации.
Когда дизайн будет завершен, один или несколько лицензированных профессиональных инженеров подпишут его. Это настоящая ответственность. (С другой стороны, ни один PE не будет ставить свою лицензию на ее надежность, и дизайн никуда не денется.) Этого не происходит в программном обеспечении, отчасти потому, что проблемное пространство настолько неограниченно.
Наконец, мост будет построен, на это потребуются месяцы и много тяжелого оборудования. Программное обеспечение будет изначально создаваться с помощью компилятора и бесконечно воспроизводиться с помощью дешевых инструментов.Здесь есть большое психологическое значение: люди склонны думать, что проекты имеют значительный дизайн и важные этапы производства, а если производство слишком тривиально, они склонны думать о части дизайна как о производстве.
Если бы программное обеспечение было больше похоже на гражданское строительство, нам потребовались бы стандартные, адекватные и надежные методы для большинства вещей. Нам потребуются инженеры, которые изучат эти методы и будут готовы подтвердить, что программное обеспечение было или не было спроектировано должным образом, и на самом деле нам потребуются проекты, выполненные в соответствии с этими методами, чтобы быть почти полностью надежными. Здесь нам потребуется более формальное принятие ответственности. Нам нужно больше внешнего уважения, потому что менеджеры, которые не осмелятся выбросить проект строительства стоимостью 10 миллионов долларов, вмешиваясь, часто не будут стесняться испортить проект программного обеспечения стоимостью 20 миллионов долларов.
Короче говоря, программное обеспечение - слишком незрелая дисциплина, чтобы работать как гражданское строительство.
Я думаю, что самая большая разница в том, что они никогда не подумают о запуске проект с такими же дрянными требованиями, которые нам предъявляют. Может быть, нам также следует прекратить делать это и заставить людей действительно определять, что они хотят, прежде чем мы начнем пытаться это кодировать.
Я хотел добавить, что мы, как отрасль, выполняем паршивую работу по отталкиванию от новых сроков и бюджета, когда требования (такие, как они есть) меняются. Мы начали делать гораздо больше этого отказа здесь, говоря клиенту, сколько еще часов (и больше денег) потребуется для запрошенного изменения, добавляя два дополнительных дня, чтобы выполнить существующий крайний срок, и заставляя его формально подавать запрос на изменение . Количество запрошенных изменений исходных требований резко упало, когда мы настояли на том, что за это изменение придется заплатить. Это изменение также переместило нас из центра затрат в центр прибыли в компании, поскольку мы выполняли много дополнительной работы, но не взимали с клиента больше, чем предполагалось.
Урок, который можно извлечь из инженерии: соблюдайте нефункциональные требования .
Функциональные требования достаточно жесткие, поскольку они ожидают, что пользователи, разработчики, аналитики и все остальные участники смогут определить, что необходимо для ведения бизнеса.
Нефункциональные требования - это то, что инженеры и технические специалисты придумывают, но функциональные люди могут не заметить их. Очень легко упустить из виду или преуменьшить нефункциональность. Некоторые руководители проектов, с которыми я работал в прошлом, не хотели слышать о нефункционалах, потому что они не могли быть напрямую связаны с потребностями бизнеса и вводили задачи, которые угрожали бы показателям «вовремя и в рамках бюджета».
Пример
Функциональное требование : Роскошное судно должно иметь возможность перевозить X пассажиров
Нефункциональное требование : Корабль, достаточно большой, чтобы перевозить X пассажиров, должен иметь корпус Y единиц толщиной, чтобы поддерживать целостность даже при столкновении с айсбергами
Подсчет затрат
Почему программные менеджеры по проектам не соблюдают нефункциональные требования? Потому что цена за такое неуважение для инженеров иная, чем для разработки программного обеспечения.
Цена игнорирования нефункциональных требований в моем примере с кораблем : потеря жизни.
Цена игнорирования нефункционалов в программном обеспечении : некоторая слабая вещь, называемая техническим долгом, который позже будет оплачен людьми, давно удаленными из проектной команды, и бонусами за завершение проектной команды.
Конечно, мои примеры упрощены.Не все инженерные недостатки приводят к смерти, в то время как некоторые неисправные программы, безусловно, могут (например, авионика, медицина или системы управления движением). Но я думаю, вы уловили идею.
Существует разница между разработкой программного обеспечения и индустрией проектирования или строительства - спецификацию всегда можно изменить.
Ходить по воде и разрабатывать программное обеспечение по спецификации легко , если и то, и другое заморожено.
- Эдвард В. Берард ( отсюда )
Вы можете найти более подробное объяснение различий в подходах к управлению проектами в начале « Прикладное экстремальное программирование » книга.