Организация коллектива разработчиков в компании Microsoft
Относиться к компании Microsoft можно по-разному – слишком агрессивны, чрезмерное стремление к монополизму, программы огромны и неэффективны, документация часто непонятна и, опять-таки, очень объемна. Тем не менее, абсолютное большинство пользователей работает именно на продуктах этой компании, Microsoft поддерживает университеты по всему миру, да и со своим бесконечным ПО успешно справляется. Поэтому в лекциях по технологии программирования мы не можем пропустить опыт Microsoft в этой области.
Служба Microsoft Consulting Services провела анализ результатов выполнения большого количества программных проектов. Оказалось, что только 24% проектов можно признать в той или иной степени успешными, 26% не были завершены, а остальные столкнулись с большими проблемами, например, бюджет был превышен вдвое или затрачено в 1,5 раза больше времени.
Основными причинами неудач были признаны следующие:
- постоянное изменение требований;
- нечеткие или неполные спецификации;
- низкое качество кода;
- слишком широкая постановка задачи;
- ошибка в подборе кадров;
- плохая организация работы;
- нечетко сформулированные цели.
Для преодоления этих трудностей был предложен набор моделей Мicrosoft Solution Framework (MSF), в котором учтен опыт, накопленный группами разработки программных продуктов.
Самыми революционными оказались модель команды разработчиков и модель процесса разработки. Первая модель (team model) описывает, как должны быть организованы коллективы и какими принципами им надо руководствоваться для достижения успеха в разработке программ. Разные коллективы могут по-своему применять на практике различные элементы этой модели – все зависит от масштаба проекта, размера коллектива и квалификации его участников.
Формирование коллектива – сложная задача, которая должна решаться с помощью психологов. Вот некоторые основные положения:
- не должно быть команды из одних лидеров;
- не должно быть команды из одних исполнителей;
- в случае неудачи команда расформировывается;
- система штрафов (если проект проваливается – наказывают всех).
Этот "бублик" описывает только роли, за ними могут скрываться несколько человек, исполняющих каждую роль. Самое удивительное, что в этой модели не предусмотрено единоначалия – все роли важны, все роли равноправны, поэтому MSF называют моделью равных (team of peers).
Program management – управление программой. Исполнитель этой роли отвечает за организацию (но не руководит!): осуществляет ведение графика работ, утренние 15-минутные совещания, обеспечивает соответствие стандартам и спецификациям, фиксацию нарушений, написание технической документации.
Product management – управление продуктом. Исполнители этой роли отвечают за общение с заказчиком, написание спецификации, разъяснение задач разработчикам.
Development – наиболее традиционная роль – разработка и начальное тестирование продукта.
User education – обучение пользователей. Написание пользовательской документации, обучающих курсов, повышение эффективности работы пользователей.
Logistic management – установка, сопровождение и техническая поддержка продукта, а также материально-техническое обеспечение работы коллектива.
Testing – тестирование. Выявление и устранение недоработок, исправление ошибок, другие функции QA.
Все решения принимаются коллективно, разделяется и ответственность в случае провала проекта.
В MSF утверждается, что такую модель можно масштабировать, разбивая систему по функциям. Лично у меня это утверждение (как и коллективная ответственность) вызывает большие сомнения.
Модель процесса определяет, когда и какие работы должны быть выполнены.
