Что касается модели команды MSF с точки зрения ролей и разделения на ролевые кластеры. Нужно отметить, прежде всего, то обстоятельство, что команда Microsoft является командой равных, но это не означает, что ответственность размазана как внутри ролевого кластера, так и, может быть, по ролевым кластерам. На самом деле, персональная ответственность очень четко определена, сферы ответственности очень четко разграничены, рабочие продукты очень четко описаны и критерии приемки их с точки зрения уровня качества также описаны достаточно четко и вполне конкретно. Скажем, когда мне приходилось работать с Microsoft Research — это исследовательское подразделение Microsoft на предмет создания учебного курса — было вполне точно сказано, какое количество рабочих продуктов необходимо предоставить, какое количество, скажем, презентаций по каждому курсу необходимо, какое количество слайдов должно быть в каждой презентации и, буквально, до того, какой шрифт должен использоваться, какое количество слов в строке, какое количество строк на слайде и т. д. Все было достаточно четко оговорено. Пределы по размерам документов Word, которые сопровождали эти слайды в форме комментариев, также были очень четко описаны. Т. е. на самом деле, можно было говорить о том, что процесс работы был очень четко поставлен и строго отслеживался и контролировался. Таким образом, каждая роль отвечает за определенную ступеньку качества, за определенный атрибут качества в общем решении или некоторые атрибуты качества. Скажем, usability как удобство использования выделяется в отдельный кластер, тестирование выделяется в отдельный кластер для обеспечения качества работы и т. д. Другим важным принципом является представление интересов всех заинтересованных или участвующих сторон или стейкхолдеров. Часто это слово теперь по-русски используется при описании методологии. Т. е. на самом деле, как разработчики, так и представители заказчика, которые лично заинтересованы в высоком качестве продукта, достаточно активно участвуют в его производстве, в его создании, консультациях. И на первом этапе, на этапе концептуальной проработки, на этапе, как говорят в Microsoft, создания видения продукта и разработчики, и заказчики достаточно интенсивно консультируются, дают свои предложения, для того чтобы получить возможность рельефно взглянуть на продукт с разных точек зрения, для того чтобы получить возможность отсеять те, может быть, негативный или непродуктивные подходы, которые не приведут нас к результату достаточно быстро, и наоборот, учесть все те требования, которые может быть даже по началу кажутся не необходимыми, где-то даже абсурдными с точки зрения разработчика и которые, скажем, поступают от заказчика. Такой подход дает нам возможность концептуально проработать продукт на ранней стадии достаточно полно и не допустить существенных затрат при переработке продукта, если вдруг будет выяснено в ходе разработки, что продукт не соответствует ожиданиям, потому что какие-то из этих ожиданий, какие-то из этих высокоуровневых требований были упущены при первоначальном обсуждении. Мы помним, что стоимость работ и стоимость исправления ошибок возрастает экспоненциально по мере движения в жизненном цикле. И таким образом, в кризисных условиях такой подход дает возможность достаточно эффективно расходовать ресурсы и обеспечить высокое качество. Ну и наконец, третьим важным требованием с точки зрения ролевых кластеров является адаптивность, умение приспособиться, чтобы соответствовать характеру и масштабу продукта. Мы вскоре еще раз обсудим как матрицу компромиссов, так и матрицу совмещения ролей, которая дает возможность команду Microsoft по количеству ее участников и по распределению ролей в кластере достаточно гибко и эффективно масштабировать как в сторону сжатия, так и в сторону расширения, введения новых ролей либо создания команд, которые состоят из, в свою очередь, других команд.
