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

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

Одно не вызывало сомнений: при срабатывании устройства пациент испытывает то, что мой врач назвал словом «неудобство». Конечно, умереть из-за неполученного электрического разряда - это еще большее «неудобство», но легко представить себе, что и ложное срабатывание устройства несет угрозу жизни. Эту ветвь дерева решений также надо было обдумать.

Где мог возникнуть отказ? Само устройство достаточно простое. Есть батарейка с длительным сроком службы, конденсатор большой емкости и микропроцессор с программным обеспечением. Батарейка и конденсатор - это стандартные технические детали, которые могут быть подвергнуты обычному контролю качества; то же относится и к микропроцессору. Но что можно сказать о программном обеспечении?.

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

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

Значение качества программ.

Этот пример непосредственно иллюстрирует, какую важность имеет разработка ПО. Для меня и тысяч других людей эта программа «критически важна». В большинстве встроенных приложений можно не обращать внимание на мелочи. Если программа, управляющая СВЧ-печкой, иногда допускает ошибки, то в крайнем случае вы что-нибудь пережарите в ней. Но программа, управляющая системой ABS для тормозов в машине должна работать всегда, как и прочие программные системы в транспортном средстве - управляющие работой двигателя, сцеплением с поверхностью дороги, вентиляцией салона, показаниями на приборной доске и т. д. Организовать правильное функционирование таких взаимозависимых систем не просто. А по мере увеличения количества взаимодействующих распределенных программных систем вероятность возникновения непредвиденных ошибок растет.

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

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

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

Островки надежности.

Я основываюсь на личном опыте, включающем в себя 30 лет работы в области управления программными проектами и 10 лет службы рядовым, которые ей предшествовали. За этот период в нашей отрасли почти всюду произошли глубокие перемены, коснувшиеся аппаратной базы, операционных систем, сетевого взаимодействия, языков, инструментов и т. д. Можно обоснованно утверждать, что на сегодняшний день разработка программного обеспечения - самая бурно развивающаяся область техники. Поэтому я попытался выяснить, что же осталось неизменным за эти 40 лет. Ибо если за эти суматошные 40 лет что-то не изменилось, то не исключено, что оно не изменится и за следующие 40. Информация об островках надежности в этом хаосе поможет нашему продвижению вперед с учетом того, что область продолжит свой рост, развитие, подвергаясь мимолетным капризам и увлечениям моды. Хорошие администраторы по-прежнему будут добиваться успеха, соединяя «вечные истины» с новейшими технологиями, отыскивая правильное соотношение между консерватизмом прошедшей проверку временем практики с одной стороны и риском и вознаграждением, связанными с новшествами, с другой.

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

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

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

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

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

Мое участие в этом предприятии в течение более чем 16 лет было для меня большой радостью.

Для кого предназначена эта книга.

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

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

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

Циферблат для итеративного решения задач.

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

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

Первый циклический обход.

Этапы, которые мы проходим во время первого цикла, немного отличаются от тех, которые будут потом:

Рис. 1.1. Циферблат для итеративного решения задач.

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

• Одиннадцать часов: слушать. Выявив проблему, советуемся с другими и выясняем, что они думают. Слушаем активно, ведем сократовские диалоги с партнерами, чередуя роли учителя и учащегося. Стараемся больше слушать, чем говорить, и тщательно все записываем.

• Час дня: сопереживать. Я отделил это от действия «слушать», чтобы вы почувствовали разницу. Можно слушать, чтобы получить «объективные» данные; сопереживание - это мостик между слушанием как сбором фактов и началом синтетической стадии процесса. Мы слушаем ушами, а синтезируем мозгами; в сопереживании участвует сердце. Для этого необходимо забыть про себя и поставить себя на место другого человека. Это не всегда просто сделать, особенно если то, что мы слышим, не согласуется с нашими прежними представлениями. Поэтому синтезу должно предшествовать сопереживание. Менеджеры, прежде работавшие в машиностроении, иногда пропускают этот шаг, потому что привыкли решать проблемы, природа которых на 99,44% техническая; к сожалению, для большинства проблем общего управления это неверно.

• Три часа: синтезировать. Теперь соединяем все части вместе:.

• Данные, которые мы собрали, наблюдая и слушая.

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

• Наш прежний опыт решения аналогичных проблем.

• Некий «посторонний» опыт, имеющий отношение к делу.

• Наш арсенал методов, процедур, стратегий, тактик, приемов и трюков.

• Придумываем пробное решение проблемы на основе всего, что нам известно.

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

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

Второй и последующие проходы цикла.

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

• Наблюдать: Посмотреть, как реагируют люди на пробное решение. Есть ли у нас потери?.

• Слушать: Поговорить с людьми о плюсах и минусах решения. Пусть выскажутся, что им нравится, а что нет, что действует, а что не действует.

• Сопереживать: Какие факторы повлияли на то, что мы услышали? Может быть, люди просто сопротивляются переменам? Не задело ли решение кого-то лично? Нет ли каких-то побочных эффектов и нежелательных последствий, кого-то огорчивших? Или оно слишком противоречит здравому смыслу?.

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

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

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

Когда считать проблему решенной?.

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

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

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

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

Резюме.

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