Текст книги "Программное обеспечение и его разработка"

Автор книги: Джозеф Фокс

сообщить о нарушении

Текущая страница: 18 (всего у книги 21 страниц)

Основной вклад в стоимость разработки программного обеспечения вносят:

1. Масштаб. Количество реализуемых функций.

2. Ясность. Степень, до которой понятны все реализуемые функции.

3. Логическая сложность. Число условных переходов в расчете на сто команд.

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

5. Взаимодействия с человеком. Насколько часты и интенсивны взаимодействия с системой.

6. Требования реального времени. Сколь быстро должна быть выполнена нужная функция.

7. Стабильность инструментального программного обеспечения. Достигло ли оно нужного уровня стабильности и зрелости?

8. Стабильность вычислительной машины, на которой будет выполняться система. Достигла ли нужного уровня стабильности вычислительная машина, на которой будет выполняться система.

Это самые главные из 27 факторов, которые мы перечислили выше.

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

Числа, которыми я буду тут пользоваться, не являются данными из какого-либо конкретного обзора или исследования. Это приблизительные цифры, основанные на моих собственных суждениях, я их выбрал не из-за их значений, а только для иллюстрации принципа возрастания удельной стоимости программы, и из-за того, что они находятся в полном относительном соответствии друг другу. Я считаю, что сильнее всего удельная стоимость программ увеличивается из-за нестабильности машины, используемой в фазе выполнения. Я приписываю этому фактору коэффициент 20.

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

Программа, которой нельзя сбиваться, обойдется мне дороже, чем программа, которая выполняет ту же функцию, но при этом допустимы сбои. На сколько же это обходится дороже? Я оцениваю этот фактор – надежность, – коэффициентом 15. Следовательно, если создание «ненадежной» программы стоит один доллар за строку, то надежная программа будет обходиться по 15 долларов за строку.

Каждому из восьми основных факторов я могу приписать такие коэффициенты:

Масштабность (размер)	от 1 до 8
Ясность	от 1 до 10
Логическая сложность	от 1 до 10
Последствия сбоев	от 1 до 15
Взаимодействие с человеком	от 1 до 5
Требования реального времени	от 1 до 5
Стабильность вспомогательного программного обеспечения	от 1 до 10
Стабильность вычислительной машины в фазе использования	от 1 до 20

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

Рис. 6.19. Из чего складывалась общая оценка.

Однако в реальной ситуации редко может случиться так, что для каждого фактора будут наиболее неблагоприятные условия. Нужно попробовать оценить относительную трудность каждого из них для конкретной задачи по разработке. На рис. 6.19 приведены мои оценки для пакета программ размером в 10 000 строк для управления ракетой. Эти программы не должны сбиваться, должны обрабатывать данные, поступающие от радиолокатора каждые 4 с, никак не взаимодействовать с пользователем и работать совместно со стабильным вспомогательным программным обеспечением на «вполне стабильной» вычислительной машине. Логическая сложность минимальна, а ясность просто на отличном уровне.

Моя оценка стоимости – 32,5 доллара за строку – была получена суммированием стоимостей, показанных на диаграмме. Я начал с 1 долл. за строку, мне нужно было лишь определить множители.

По моему мнению, коэффициенты надо расставить так:

– множитель для логической сложности отсутствует

– множитель для ясности отсутствует

– множитель для взаимодействия с пользователем отсутствует

– множитель для стабильности вспомогательного программного обеспечения отсутствует

– множитель 5 для размера

– множитель 2,5 для реального времени

– множитель 15 для надежности

– множитель 10 для нестабильности вычислительной машины, применяемой в фазе использования

Все это вместе дает общую оценку в 32,5 доллара за строку. Еще раз повторю, что отдельные факторы должны умножаться на соответствующие коэффициенты, а общая стоимость определяется не перемножением, а суммированием по всем факторам.

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

В представленном здесь методе игнорируется тот факт, что на самом деле трудность пропорциональна произведению отдельных факторов.

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

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

Как проводить оценки

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

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

Предположения при проведении оценок

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

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

Идеальные графики. Идеальными можно считать те графики, которые основываются на том, что все поступает вовремя – новый радиолокатор, спутник, вычислительная машина и т. д. Так не бывает никогда, но, если вы хотите выдержать конкурентную борьбу или получить одобрение своего проекта, вы должны с самого начала объявить о своем намерении придерживаться графика. Только не надо верить в это самому! В этом кроется еще один «социальный» аспект данной области! Мы создаем идеальные графики, чтобы получить премию, чтобы проект успешно прошел все защиты.

Организация усилий по разработке программного обеспечения

Правильное решение организационных вопросов лежит в основе большинства наших изумительных достижений, но в то же время мы очень часто путаемся при выборе наиболее правильной организационной структуры. В классической работе Питера Дракера «Организационные принципы»[41]41
  Drucker P. Concept of the Organization (New York: The John Day Co., Inc., 1972).


[Закрыть], вышедшей в 1945 г., указывается, что высочайший уровень промышленного производства, достигнутый Соединенными Штатами во время второй мировой войны, основывался не столько на технологических достижениях, сколько на достижениях в области организационной.

Рис. 6.20. Организация разработки программного обеспечения.

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

В дальнейших рассуждениях мы будем пользоваться схемой, приведенной на рис. 6.20.

Ключевые моменты больших проектов

1. Руководитель выработкой требований. Эта должность редко встречается в организациях, занимающихся программированием, однако функции, относящиеся к ней, имеют важное значение. Когда однажды я спросил руководителя одного проекта, оцениваемого в 100 млн. долларов, «кто отвечает за выработку требований», он пришел в крайнее замешательство. По его словам, отвечал за требования он сам. Это означало, что никакого конкретного ответственного не было! Когда время начнет поджимать, кто сможет отстоять интересы пользователя?

2. Отдел руководителя программного проекта следит за бюджетом, графиками, оборудованием, хозяйственными вопросами и т. д. Сильная, мощная группа может снять множество проблем.

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

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

5. Руководство конфигурацией (РК). Постоянный комитет, в который входят по крайней мере руководитель разработки, руководитель выработкой требований и главный руководитель проектом, должен раз в неделю обсуждать все предполагаемые изменения, результаты тестирования и состояние системы. Это единственный способ быть в курсе всех событий, происходящих при разработке крупной программной системы.

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

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

Среди наиболее часто встречающихся ошибок, которые попадались на моем пути, можно отметить такие:

1. Нет проектировщика. «Проект будет развиваться!»

2. Нет независимой группы тестирования.

3. Нет независимой группы по определению требований.

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

Надзор над разработкой

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

Имеется много способов отслеживания множества дат завершения отдельных работ, которые можно выделить в большом проекте. Хорошо работают схемы, составленные по методике PERT или GANTT, если, конечно, их применяют, но на них приходится тратить и людские и денежные ресурсы. Хорошую помощь при прослеживании всех необходимых подробностей могут оказать вычислительные машины и работающее на них программное обеспечение.

Имеются десятки и десятки систем «контроля за проектом», которые позволяют совершенно точно прослеживать ход разработки, если их применяют на практике. Но руководство при этом должно проверять и перепроверять точность всех поступающих отчетов и то, что система не подвергается губительным воздействиям. Если что-нибудь идет не так, как это было бы нужно, такие системы способны выдать сигналы об этом уже в самые первые моменты нарушений. В этот момент руководители самых нижних уровней обычно пытаются «оправдаться», считая отклонения простыми случайностями и надеясь решить все возникшие проблемы уже в ближайший же месяц.

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

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

Управление

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

Разработка программного обеспечения оставалась невидимой в течение 30 лет. С огромной скоростью она становится все более наглядной. Люди могли делать все, что пожелают. Для небольших, относительно самостоятельных программ это хорошо. В большие системы, состоящие из огромного числа взаимодействующих программ, это вносит мною бед.

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

Экономия усилий

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

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

Управление конфигурацией

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

Рис. 6.21. Цикл управления конфигурацией.

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

Автоматизированная матрица модулей/функций

На примере системы по составлению платежных ведомостей (в конце гл.5) мы видели, что частями системы могут становиться многие программы довольно значительных размеров. Конечно, каждая из перечисленных нами программ состоит из множества более мелких модулей команд.

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

Ключ к успеху – руководитель разработки

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

Выбор руководителя разработкой программного обеспечения

Первое качество, на которое надо обращать внимание при выборе руководителя разработки программного обеспечения, это не его технические возможности и даже не его личный опыт, а его эмоциональная зрелость и «неуступчивый» характер. Хорошие руководители разработкой умеют соразмерять цели с реальностью и могут твердо стоять на своем, говоря «нет» непрерывным требованиям ввести «еще несколько» функций, совсем немного здесь и еще чуть-чуть там. Такое наращивание функций называется «потерей элегантности» и может оказаться фатальным. Они знают, что время, необходимое на выполнение n + 1 тривиальных вещей, вдвое больше времени, необходимого на выполнение n вещей, если n стало уже достаточно большим (возражение Логга на закон Грея)[42]42
  Dickson P. The Official Rules, New York: Delacorte Press, 1978.


[Закрыть]. Они знают, что Брукс был прав, когда в книге «Мифический человеко-месяц» написал: «Как получается, что программы опаздывают на год? Это происходит постепенно». Они знают, что требования являются первой линией обороны. Не допускай «врага» к этим позициям, и ты будешь контролировать все события.

Вторым необходимым качеством руководителя является внимательность к деталям. Большинство хороших руководителей разработок программного обеспечения тратят очень много времени на изучение мельчайших подробностей работ. И не напрасно.

Третьим желательным качеством руководителя программным проектом является способность к руководству вообще.

Затем следует учитывать знание области, в которой будет проходить работа. Затем опыт. Приходилось ли ему ранее участвовать в какой-нибудь столь же крупной разработке? Не забывайте о «принципе Питера». Многие люди, бывшие способными заместителями, никогда не могут стать хорошими руководителями! Разработка программ объемом в миллион строк намного более чем в 10 раз сложнее разработки в сто тысяч строк.

Какие качества нежелательны?

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

Технический опыт

Для того чтобы стать программистом, не обязательно иметь техническое образование. Но с руководством большими сложными структурами в программном обеспечении, нахождением оптимальных «решений» при соединении сотен отдельных частей, распределением работы между сотнями технических разработчиков – со всем этим гораздо лучше справится человек, имеющий техническое образование. Изучение некоторых новейших средств структуризации этих сложных видов деятельности показывает, что они относятся к самым передовым областям математики и техники.

Карьера разработчика программного обеспечения

Некоторые аспекты деятельности руководителя разработкой программного обеспечения могут внушать беспокойство. Оценки не бывают точными и объективными. Единственной «хорошей» методологией остается личный опыт, а проведение оценок можно отнести к области черной магии. Не известно еще, как измерить прогресс в этой области. Определить, насколько проект близок к завершению, можно, только пользуясь хорошими методами автоматизации разработки и системой слежения за процессом. Для предсказания, измерения и численного определения производительности труда нет ни одного хорошего метода:

1. Трудно сказать, насколько велика данная работа.

2. Вы не можете сказать, какова будет (или даже была) производительность труда ваших людей.

3. Вы не можете указать процент выполненной работы.

4. Трудно сказать, в каком направлении идет работа!

5. Трудно сказать, насколько быстро вы движетесь!

6. Трудно сказать, насколько далеко вы продвинулись! Найдется ли человек, который захочет взять на себя руководство работой при таком спектре нерешенных проблем?

Пять стадий развития всех новых проектов

1. Эйфория.

2. Разочарование.

3. Поиск виновных.

4. Наказание невиновных.

5. Награждение непричастных к делу.

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

Печальная участь первопроходцев

Сказано точно. Изучение новых разработок показывает, что первый руководитель и второй, пришедший ему на смену, обычно кончают одинаково – их снимают. Только после одного или двух «кровопусканий» главное руководство может занять реалистические позиции. Почему люди вообще хотят стать руководителями больших разработок программного обеспечения? Потому что это наиболее быстрый способ продвижения по служебной лестнице, «путь наверх» – если, конечно, вы сможете удержаться.

Вы будете прекрасно вознаграждены, если преуспеете.

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

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

Почему же это должно быть очевидно? Это не так очевидно, как можно было бы подумать! В 1961 г. комитет, созданный по предписанию президента Джона Ф. Кеннеди для расследования причин воздушной катастрофы над Нью-Йорком, вынес рекомендации по автоматизации управления авиалиниями. Комитет настоял на том, чтобы Федеральное авиационное агентство (FAA) для всех новых систем покупало только «отработанные» вычислительные машины. Это ограничение было наложено потому, что в конце 1950-х г. FAA стала вкладывать деньги в разработку вычислительных машин – и деньги стали уходить в эту область, а не на разработку собственно систем управления авиалиниями.

Похожая история произошла в середине 1970-х г. в системе здравоохранения. Разработчики перестали заниматься созданием системы, которая могла бы удовлетворить запросы врачей, медицинских сестер, администраторов, специалистов и обслуживающего персонала, и занялись разработкой «сети» мини-ЭВМ и распределенной базы данных.

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

Небольшая консультационная компания потеряла 300 000 долларов – доход за несколько лет – при попытке закончить работы по контракту, в которых использовалась машина фирмы IBM «Series 1». Аппаратура была великолепной; а системное и инструментальное программное обеспечение было отработано не до конца. Каждый раз оказывалось, что люди натыкались на какую-нибудь неисследованную проблему. Программное обеспечение было новым! По этой причине фирма IBM не давала по нему никаких гарантий. И контракт был передан IBM.

Будет ли удовлетворен настоящий пользователь?

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

Рис. 6.22. Организации, занятые в одном проекте.

На рис. 6.22 показана весьма типичная организация работ над большим проектом. Истинные требования, поступающие от пользователя, могут подвергаться искажениям и на пути Л, и на переходе В. Меткой 1 мы преднамеренно отметили сразу два пути. Какой из них «правильный»? Они находятся в постоянном конфликте.

Пути 2, 3 и 4 тоже не являются «чистыми». Сколько проектов терпели неудачи из-за того, что проектировщики или программисты решали, что они знают, что надо делать, а люди, стоящие выше на служебной лестнице, несут околесицу? Таких проектов было слишком много! Я видел системы, где программисты знали больше, чем проектировщики, и поэтому строили систему по-своему. Видел системы, где проектировщики «знали» все, что требовалось. Видел и системы, где ни один человек ни разу не поговорил с подлинным, настоящим пользователем. Короче говоря, искажения могут возникать и в точках А или В, и в точках 1, или 2, или 3, или 4, и все они плохо влияют на систему в целом.

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

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

Прослушивания

Я встречался с разными результатами прослушиваний, с такими, например, когда утверждалось, что все идет прекрасно – и так и было на самом деле, – и с такими, когда говорилось, что все идет хорошо – а затем наступала катастрофа! Иногда предупреждали о предстоящей неудаче, и она случалась. А бывало и так, что предсказанная катастрофа так и не наступала.

Другими словами, при прослушиваниях часто возникают ошибочные выводы! Те, кого вызывали на прослушивание, заявляли: «Мы знаем больше, чем эти эксперты; они ошибаются». И верно, часто так оно и было. Каким образом руководитель может определить, кто же прав? Не означают ли эти ошибки, возникающие в результате прослушиваний, что сама идея таких прослушиваний неверна?

Прослушивания очень важны

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

Что необходимо выносить на прослушивания – и когда?

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

Что такое «прослушивание»?

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

Кто должен участвовать в прослушиваниях?

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

В чем вред прослушивании?

Прослушивания оказывают разрушительный эффект. Руководитель проектом прямо скажет вам, что за каждый день, который отводится на прослушивание, он должен резервировать 2 дополнительных рабочих дня. Он считает, что такое воздействие слишком велико, чтобы подвергать ему проект. Участвуйте в прослушивании и не соглашайтесь на изменения в графике. Типичный ответ руководителя: «Посмотрим».