Поскольку 94% всех agile-преобразований заканчиваются неудачей, будет полезно рассмотреть некоторые инженерные практики, которые обещают сократить число неудач программных проектов, пишет на портале ComputerWeekly Джунэйд Али, британский специалист в области управления программной инженерией, компьютерной безопасности и распределенных систем.

В течение последних нескольких месяцев я работал с опытным клиническим психологом и командой исследователей уровня PhD, включая психолога и академического ученого-бихевиориста, чтобы понять, что отличает наиболее эффективные команды от тех, которые испытывают трудности. Исследование показало, что 81% лиц, принимающих бизнес-решения в Великобритании и 89% в США, обеспокоены своевременным выполнением программных проектов в своих организациях.

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

Однако проблемы, как представляется, имеют еще более глубокие корни, чем те, что связаны с написанием или тестированием кода.

Когда я писал свою книгу «Как защититься от компьютеров-убийц» («How to Protect Yourself from Killer Computers»), я глубоко изучил ряд катастрофических отказов ПО, включая связанные с входом самолетов в «смертельное пикирование», смертельными автокатастрофами и убийственными передозировками радиации в больницах. Психологические факторы помогают нам понять, почему ошибки в ПО превращаются в катастрофические компьютерные сбои, однако тревожная тема, повторяющаяся во многих примерах, заключается в том, что первоначальная техническая причина многих проблем была связана с проектированием ПО, или, по сути, отсутствием надежного проектирования.

Подход, ориентированный на требования, был формализован в манифесте Agile, которому уже более 23 лет и который пропагандирует разработку ПО, основанную на «реагировании на изменения, а следовании плану».

Совместно с компанией J L Partners я опросил 600 инженеров-программистов в Великобритании и США об успешных и неудачных проектах по разработке ПО, над которыми они работали. Наше исследование показало, что проекты, в которых разработка ПО начиналась до появления четких требований, в которых отсутствовало полное документирование спецификации и в которых значительные изменения вносились на поздних этапах разработки, в 65% случаев оказывались неудачными.

В то же время мы выявили всего пять инженерных практик, которые позволяют снизить процент неудач до 10%. Только наличие четких требований до начала разработки повышало вероятность успеха проектов на 97%, а наличие у инженеров свободы обсуждения и решения проблем увеличивало процент успеха на 87%. Среди других практик: обеспечение соответствия требований реальной задаче (54%); наличие полной спецификации перед началом разработки (50%) и недопущение поздних изменений требований (7%). В совокупности эти практики мы называем Impact Engineering.

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

Любопытно, что наибольшее различие в инженерных практиках между Великобританией и США заключается в том, что британские инженеры-программисты на 13% реже считают, что могут обсуждать и решать проблемы, чем их американские коллеги. И это несмотря на многочисленные исследования, включая данное, подчеркивающие, насколько психологическая безопасность фундаментально важна для успеха компьютерных систем.

В ходе нашего исследования мы также выяснили, почему инициативы по трансформации терпят неудачу. Несмотря на перспективность трансформационных методологий, мы по-прежнему видим, что 70% цифровых преобразований и 96% agile-преобразований терпят неудачу. Только 10% предприятий, независимо от отрасли, попавших под административное управление специалиста по банкротству, выживают, несмотря на смену руководства.

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

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

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

Благодаря подобным исследованиям мы разработали психологическую основу, позволяющую людям добиваться значительных личных и организационных преобразований. Эти методы представлены в моей новой книге «Impact Engineering: Transforming Beyond Agile Project Management», в которой описано их применение в реальных примерах, а также научное обоснование этих выводов.

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

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

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

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