Проблемы с надежностью? Застрелите архитектора!

Моя статья об обеспечении качества по опыту моего участия в разработке Microsoft Project  вызвала большой интерес. Но есть что добавить к сказанному. На самом деле основная проблема это "архитекторы" и их крупные ошибки.

Надо помнить, что реально работает "японская модель качества", т.е. изделие должно быть таким, что просто потенциально не содержит дефектов. В IT-проектах это называется словом "Архитектура". Если архитектура сделана правильно, то в целом программный продукт содержит мало ошибок, они легко устраняются и продукт достаточно легко меняется без серьезных циклов тестирования. За системную архитектуру отвечает "системный архитектор". Обычно ведущий тимлид группы разработчиков. Если он сделает ошибку, то размер кошмара пользователей и поддержки будут невообразимым. Поэтому очень важно понять, что специалист проектирующий архитектуру какого-то модуля делает ошибки проектирования и его надо просто уволить. Не нужно ничего фиксить и поддерживать. Проще уволить архитектора и переписать что-то. В случае Microsoft это происходит и на самых высоких уровнях. Стивен Синофски отвечавший за Windows 8 был уволен за дурдом с Метро. Несколько необычно, что Кешав, архитектор MS Project Server, его большой фанат. :)

Оглядываясь назад на тяжелую историю поддержки MS Project Server, начинаешь понимать, что кратчайший путь для Microsoft был просто уволить "индийскую гвардию", поставить нового архитектора и сделать рефакторинг (переработку кода). Как я уже отмечал, так Microsoft делает часто. Один из примеров резкого повышения качества продукции Microsoft - это Microsoft SQL Server. До версии 6.5 он имел неконкурентное качество относительно Oracle и Sybase. Рывок был связан с тем, что Билл Гейтс уволил ряд ключевых архикторов и нанял известных людей на их позиции. Так и сложилась, "русско-украинско-иудейская мафия" в группе разработки MS SQL.

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

• "Кризис переходного возраста". За 30-35 лет многих вроде опытных IT-специалистов начинает "колбасить", страх "стать никем" так велик, что они хотя поставить себе "памятник нерукотворный". В виде обкуренной архитектуры, например.
• "Вы сказали, я сделал" или "На тебе ТЗ". Еще опаснее наркоманского старпера-архитектора, архитектор который встает в позу исполнителя ТЗ от бизнес-постановщика или клиента. Ему на самом деле наплевать на качество и продукт, главное "фигарить по спеку". 
• "Пользовательский сценарный непониматор". Такой вот термин придумал. Часто архитектор городит архитектуру совершенно не понимая сценарии и бизнес-процессы работы своих пользователей. Это примерно как хирург, который деловито отрезает вам ногу и все правильно анестезирует, но не очень понимает, что у вас насморк.

В любом случае очень важно понять, что архитектору пора уходить, когда зашкаливает метрика поддержки. Это означает, что архитектор прокололся. Норма "разработка/поддержка" где-то 50%/50% в среднем. Возможно у вас как-то иначе, но если 10%/90%, т.е. на одно движение архитектора требуется 10 десять инженеров прибирающихся за ним, то пора сказать #давайдосвиданья