Здравствуйте, EM, Вы писали:

G>>Далее — в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG — проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать.

EM>Выделенное глубоко верно, но это и так все знают.
EM>Более интересно, какими именно мерами он "эффективно решил проблемы с качеством клиента CQG" ?

Ввел и наладил работу...
1) ...схемы приоретизации дефектов и планирования релизов. Дефекты начали сортировать по принципу value-cost, для этого собирался специальный triage meeting. Его МакФэйден вел лично.
2) ...а также улучшения маршрутизации дефектов и простейшей схемы контроля качества. МакФейден ввел код-ревью — все чекины, в которых не прописана фамилия проверяющего, отклонялись. Проверяющий был всегда компетентен в тех модулях, к которым относились исправления(была собрана матрица компетенции, которая применялась при назначениях). Это снизило количество дефектов, которые вносились исправлениями других дефектов.

Вот и все. Умница МакФейден. Как-то тихо все через полгода все забыли о проблемах с дефектами, когда схема заработала.

Я не так давно повторил этот фокус на последнем месте работы. Комания никак не могла выпустить maintenance release в срок, и каждый раз это было дикое напряжение и аврал — по 4 месяца задержки были. И вдруг через несколько месяцев — о чудо . Как-то незаметно и без напряжения все вдруг с удивлением обнаружили, что очередной maintenance release к выпуску готов . Странно, никто задницу на британский флаг не разрывал. Одна проблема — как-то слишком быстро и незаметно как-то все получилось, и customer support не успел поставить предыдущий release всем клиентам

А всего-то надо было делать несколько простых вещей. 1) code freeze — не подбрасывать в релиз, который проходит системный тест исправлений новых дефектов, просто потому, что "он все равно сломался" 2) Исправлять дефекты каждую неделю, не забивая на них полный болт. Скажем, по одному дню в неделю выделить на них каждому программерут 3) Иметь четкую отсечку по времени по выпуску каждого релиза. 4) разделить "зоны ответственности" между программистами, чтобы равномерно размазать по нима нагрузку по maintenance 5) и аккуратно управлять приоритетами, постоянно имея в виду всю эту схему — чтобы в первую очередь исправлялись критичные для кастомеров дефекты.

И все. Эти простые правила не напряжны для всех, и воистину творят чудеса Пункт 6) про code review — чтобы снизить количество неверных исправлений, я не смог до конца претворить в жизнь как непреложное правило (для этого нужна была новая инфраструктура билдов-VCS-issue tracker), но зоны ответственности уже положительно повлиял и на количество неверных исправлений.

EM>Кстати, я за этим чудо продуктом трейдил еще 9 лет назад и до сих пор этот ужас не забыл.

Не такой уж и ужас. Впрочем, было бы любопытно узнать, что именно вам не нравится в этом продукте — я это с удовольствием передам своему бывшему коллеге, который сейчас директор свой собственной конторы, и делает конкурента CQG . Заодно, расскажу, что из этого мы исправили с 1999 до 2005 года .