Получение согласия

Получение согласия

Не каждый инженер-программист, с которым вам доведется работать, благосклонно воспримет описанный в данной главе протокол, потому что инженеры - живые люди, и у них есть свои особенности. Однако мой опыт показывает, что этот метод жизнеспособен в подавляющем большинстве случаев и потому может послужить хорошей отправной точкой.
В следующей главе мы посмотрим, что следует за шагом четыре. Мы полагаем, что на этом шаге уже заручились согласием инженера сделать чтото к определенному сроку. Наш успех зависит от того, выполнит ли он свое обязательство. Эта базовая парадигма глубже исследуется в главе 15.
Как правило, планы и графики работ проектов разработки ПО носят агрессивный характер. В редком проекте не встретишь каких-нибудь нововведений или честолюбивых замыслов. Руководство всегда хочет получить результат как можно скорее, а риск является неотъемлемым элементом. При этом большинство разработчиков уже участвовало по крайней мере в одном провалившемся проекте, кое-кто из них был занят в проектах, которые сразу же выпадали из графика и велись мучительно и нескончаемо. Поэтому, как только предлагается некий новый проект, разработчики и менеджеры воспринимают его настороженно: какие сюрпризы ждут их на этот раз?.
Напуганная команда не может работать эффективно, поэтому такую изначальную тревогу необходимо побороть. Этого не добиться заказом специальных футболок и устройством вечеринок. Правильный путь заключается в том, чтобы составить разумный план с максимальным участием всей команды, а потом обсудить его в более мелких группах. Не имеет смысла собирать всю команду в одном зале и демонстрировать план в виде презентации PowerPoint. С помощью такого шоу вы ничего не добьетесь: они хотят обсудить детали и практические вещи, а это можно сделать только в непринужденной обстановке с небольшим числом участников.
В конце каждого из таких небольших совещаний нужно оглядеть всех сидящих за столом и предложить каждому участнику подтвердить свое согласие осуществлять этот план. Недостаточно заручиться согласием руководителя группы; нет, об этом должен заявить каждый из присутствующих. Обсудив план во всех группах и получив одобрение от всех участников, можно обоснованно считать, что вся команда готова к старту. Если.
кто-то считает план нереальным, у него была возможность высказать свое мнение. И если этот человек не подтвердил своего согласия, вы должны решить, остается ли он в этой команде.
Но что в действительности имеется в виду, когда идет речь о «подтверждении согласия»? Главное в данном случае - это принятие обязательств. В этой главе мы снова познакомимся с точкой зрения Роско.
Роско разбивает себе нос...
Опять мы с Роско сидим около печки и брюзжим на субботний дождь. Он уже год работает с группой инженеров-программистов, и у него произошел первый крупный «прокол». Роско столкнулся с неизбежностью, и это меня не удивило. Интереснее было, как он произведет разбор этого всегда неприятного события.
..И сразу переходит к делу.
- Итак, - начал Роско, - все очень просто. Ребята меня подвели.
Роско не тот человек, чтобы искать виновных и срывать на ком-нибудь.
злость. Он не из малодушных. Тем более мне было интересно, что заставило его произнести такие слова.
- Дело было так, - продолжил он. - Они согласились выпустить продукт к определенному сроку, но не сделали этого.
Я не спрашивал, большим ли было опоздание, хотя подозревал, что большим. Что меня заинтриговало, так это «двоичный» образ мышления Роско. Мне показалось, что он занял позицию «все или ничего» и воспринимал только два цвета - белый и черный. Разве окружающая действительность не выглядит лучше в полутонах?.
- Вероятно, - сказал я, - были какие-то смягчающие обстоятельства.
Лучше бы я ничего не говорил.
Извержение Везувия.
- Чушь собачья! - вскричал Роско. - Послушай меня, сынок. Ни у одного из них руки-ноги не отвалились, начиная с того дня, когда они подписались на этот срок, и кончая тем днем, когда он истек. Какие к черту смягчающие обстоятельства!.
Очевидно, я задел больное место, и содрогнулся при мысли о том, что пришлось пережить команде Роско. Ибо если даже я, сторонний наблюдатель, был поражен его реакцией, то можно только догадываться, как они реагировали на те пинки, которые он раздавал в день предполагавшейся сдачи продукта. Всем известно, что Роско не станет стесняться в выражениях, когда решит высказать людям, что он думает об их работе.
- Пойми, я оставил им большой резерв, - продолжал Роско. - Они сами сделали оценки, а я применил свое правило квадратного корня.
И после этого приходят с пустыми руками. Моя первая сухая скважина
за долгое время. Я все время чувствовал, что у них не ладятся дела. Я пытался влезть в их работу и разобраться, что происходит. Но они меня не пускали, говоря, что я не пойму технические проблемы, и все в конечном итоге будет хорошо. Сам виноват, что согласился с ними. Больше я такой ошибки не сделаю.
Роско неохотно признал, что его невмешательство в этом проекте было ошибкой. Я предположил, что он недостаточно глубоко занимался проектом, в отличие от своей обычной практики, поскольку доверился своим людям. Похоже, что в данном случае они оказались недостойны его доверия.
Я поинтересовался у него, на что он рассчитывал? На их безупречность?.
Как это делается в Техасе.
Тут Роско объяснил мне, что такое рукопожатие в Техасе. Мне предстояло расширить свое образование.
- Я вырос на нефтяных полях Техаса,
- объяснил Роско. - Там, где добывают нефть, мужчина связывает себя словом. Если ты скрепляешь договор рукопожатием, то берешь на себя обязательство. А обязательства священны.
Я попросил его привести какой-нибудь пример.
- Пожалуйста, - сказал он. - Допустим, у меня есть какие-то трубы,
которые мне нужно срочно перебросить на другую буровую. Что я делаю?.
Звоню своему местному водителю,
и он присылает мне грузовую платформу. Через час все, что мне нужно, перевезено.
- Прелесть в том, - продолжал Роско, - что вся сделка заключается с помощью рукопожатия. Мы договариваемся о том, куда и когда надо перевезти трубы и сколько это будет стоить. Он берет на себя обязательство быстро доставить товар, а я - обязательство быстро ему заплатить. Контракт мы не подписываем, хотя я, возможно, чиркну свои инициалы на какой-нибудь бумажке, когда он будет забирать груз. Главное, нет никаких законников. Нет ни нужды в них, ни лишнего времени. Достаточно рукопожатия. Если один из нас не выполнит своего обязательства, мы никогда больше не станем работать вместе.
Вот как? Интересная мысль.
- Это честно. Твое слово - твое обязательство, а твое рукопожатие - это твое слово. И если пройдет слух, что твое рукопожатие ничего не стоит, ты оказываешься вне закона. Никто не станет иметь с тобой дела.
Как это связано с программным обеспечением.
Так, подумал я, значит, Роско, рассчитывал на такую же железную верность своему слову от своих программистов. Можно допустить. Что же не сработало?.
- Главная проблема заключается в следующем, - постулировал Роско. На нефтяном поле обязательство означает «обязательство доставить». Помоему, эти ребята-программисты понимают обязательство иначе - как «обязательство постараться».
Вот оно! Роско без лишнего красноречия попал в самую точку. Я часто был свидетелем того типа провалов, который он описывал. Люди, только что сорвавшие срок выпуска продукта, начинают долго объяснять, какие большие усилия они приложили, как будто это снимет с них ответственность. Им кажется, что их старания служат доказательством благородных намерений, а потому их следует простить.
- Обязательство состоит из двух частей, - продолжал Роско. - Первая часть - это добровольное желание. Оно означает, что человек постарается сделать работу. Без желания ничего не будет. Но и вторая часть не менее важна. Это способность выполнить работу. Человек должен не только хотеть выполнить работу, но и быть в состоянии это сделать. Первое без второго бесполезно с точки зрения конечного результата.
- Поэтому, когда кто-нибудь берет передо мной некое обязательство, заключил Роско, - я предполагаю, что он одновременно хочет и может его выполнить. Поэтому работа будет сделана. Дело закрыто. Если он не уверен в своих возможностях, не надо брать на себя обязательств.
Мне пришлось задуматься над этим глубже, чем я делал это раньше.
Мое домашнее задание съела собака.
- Конечно, - продолжал Роско, - всегда найдутся жулики, которые станут сочинять сказки про то, как «мое домашнее задание съела собака». Я таких не терплю и всегда удивляюсь, откуда они вообще взялись. И знаешь что: они всегда сообщают тебе, что не успевают сделать работу вечером накануне сдачи, хотя ясно, что они знали об этом намного раньше. Это просто несерьезные люди, и их надо гнать как можно скорее.
Я решил, что это справедливо. Меня всегда возмущали те, кто ждал последней минуты, чтобы сообщить мне плохие вести. Я не только считаю это признаком их трусости, но и полагаю, что они украли у меня время, в течение которого я мог бы придумать альтернативный план, чтобы закрыть их провал.
- Ты правильно рассуждаешь, Роско, - отвечал я. - Но иногда кажется, что просто возникло какое-то недоразумение.
- Да, есть два распространенных типа «механического» провала. Во-первых, может быть разночтение по поводу того, что представляет собой обязательство. То есть что именно должен представлять собой результат? Сколько труб надо перевезти и в какое место в Техасе? Во-вторых, может быть нечетко определено «когда». Я всегда указываю водителю час, к которому трубы должны быть доставлены на место. Он понимает это так, что если он задержится с доставкой, то я не получу той услуги, за которую заплатил.
- Тут вопрос денег, - вставил я.- Применимо ли это, если речь идет о программном обеспечении?.
Роско ответил без колебаний. - Программистам не мешало бы лучше уточнять, что именно должно быть поставлено и к какому сроку. Тогда меньше стало бы нытья относительно того, сделали они то, что нужно, или нет. Условия должны быть однозначными, четкими и не обсуждаться до бесконечности задним числом.
- Потому что обязательство, - подчеркнул он, - это контракт, в котором нет места двусмысленностям. В обязательстве не должно быть условий, напечатанных мелким шрифтом. Там не должно быть лазеек, позволяющих отвертеться, если уговор не выполнен в срок.
Я был просто поражен тем, как простая логика техасских нефтедобытчиков нашла применение в программном бизнесе. Но у меня тут же возникли некоторые опасения.
Войны спецификаций?.
- Подожди, Роско, - вмешался я. - не так просто осуществить твое намерение точно затвердить, что именно должно быть поставлено. Уокер Ройс неоднократно говорил мне, что стремление к излишней точности в самом начале проекта ведет к большим потерям времени. Например, если настаивать на очень точных условиях поставки, возникает масса споров относительно спецификаций.
- На самом деле, - отвечал Роско, - я согласен с Уокером. Трата уймы времени на обсуждение мелких деталей конечного продукта напоминает споры юристов о расстановке запятых в контракте. Желательно избежать подобных затрат. Иначе ничего никогда не будет доведено до конца, и мы потратим слишком много времени, плодя бесполезные документы. Но есть реальная проблема, которая требует решения. Вот пример. Очень часто инженер или программист обязуется написать за неделю к пятнице некий фрагмент кода, который должен участвовать в сборке более крупного проекта. В указанный срок код поступает, но в нем обнаруживаются ошибки. Еще неделя уходит на то, чтобы их устранить. Затем обнаруживается, что если число элементов в используемом им массиве возрастает со 100 до 1000, то алгоритм работает в 100 раз медленнее. На исправление этого уходит еще несколько недель. И все это время задачи, которые зависят от этого кода, висят и ждут, когда он будет доделан.
Роско разминался перед выступлением. Он продолжал.
- Проблема в том, что ребята просто не договорились о том, что именно должно было быть готово в ту пятницу. Программист считал, что это должен быть фрагмент кода. Менеджеру нужен был полностью отлаженный код, эффективно работающий в разумном диапазоне входных данных. Очевидно, что характеристики поставляемого продукта не были согласованы. Программист будет доказывать, что, предоставив код, он выполнил свое обязательство, и станет изворачиваться, объясняя, что он вовсе не обещал при этом выявить и исправить все ошибки. Но вступать на эту скользкую дорожку очень опасно, потому что теперь вы станете обсуждать, насколько серьезной может быть ошибка, которой разрешается проскочить тестирование (да проводил ли он его вообще?). А программист станет также доказывать, что вопросы эффективности вообще не обсуждались, хотя применение им алгоритма с квадратичной зависимостью от объема данных
вообще несовместимо с понятиями компетентности и профессионализма.
Интересно, кто это просветил Роско о квадратичных алгоритмах?.
- Я не стану утверждать, что для решения этой проблемы нужны детальные спецификации, вплоть до точных показателей эффективности. Но так же, как я на своем нефтяном поле в Техасе вправе рассчитывать, что мои трубы после доставки на новую буровую не окажутся завязанными в крендель, так и менеджер программного проекта вправе полагать, что представляемый ему код не окажется полусырым. Особенно, когда программисту известно, что его код участвует в сборке проекта и будет использоваться другими людьми.
«Вот что я пытаюсь объяснить», - сказал Роско, откидываясь в кресле.
Три самых распространенных отговорки.
Я деликатно поинтересовался у Роско, есть ли у него какие-либо представления о том, почему люди регулярно не выполняют свои обязательства. Стоило ли сомневаться, что у него было свое мнение по этому предмету?.
- Сдается мне, что в программном бизнесе большинство обязательств ничего не стоят уже в тот момент, когда произносятся. Люди просто не дают себе труда хорошенько подумать, прежде чем принимать на себя обязательства. Если бы они понимали все последствия, вытекающие из принятия на себя обязательств, они были бы гораздо осторожнее. Приведу несколько примеров. Вот одна из трех самых распространенных отговорок: «меня все время отвлекали, а я на это не рассчитывал». Позвольте, чьи это трудности? Явно не мои. Не я брал на себя обязательство. Тот, кто взял на себя обязательство, должен был либо, когда это делал, учесть, что его будут отвлекать, либо не отвлекаться, когда его пытались отвлечь. Очевидно, что обязательству, принятому в отношении меня, он не придал достаточного значения, если отвлекся на другие задачи. А как же понятие «ранее данного обещания»?.
- Подожди, Роско, - воскликнул я, - всякое случается в жизни. Ты роешь ямы под столбы для забора, и начинается дождь. Ты вынужден прекратить работу. Разве не так?.
- Да, иногда бывает дождь, - сказал он. - Я считаю, что, делая свою оценку, ты должен это учесть. Если 50% времени идут дожди, то не стоит в своей оценке полагаться на то, что дождя не будет. Нельзя делать такое предположение, а потом жаловаться, что пошел дождь.
- Да, - подумалось мне, - кажется, людям редко приходят в голову такие вещи. Многие обязательства исходят из того, что все будет идеально. Нежелание признать, что обстоятельства могут сложиться неудачно - одна из причин, приводящих к беде и невыполнению обязательств.
- Хорошо, что идет вторым в списке? - спросил я.
- Вот вторая отговорка: «задача оказалась сложнее, чем я предполагал». Опять-таки, чья это вина? Не я оценивал задачу, а он. Если у него не было уверенности, не надо было брать на себя обязательство. Если он недостаточно разобрался в задаче, чтобы правильно ее оценить, не нужно было брать на себя обязательство. Неожиданное прозрение посреди работы явный непрофессионализм. То, что ты паршиво сделал оценку, не снимает с тебя ответственности за результат. Желание-то у тебя было, а компетентности не хватило.
Ох, сколько раз мне приходилось это слышать! Несчастный малый рассказывает, что трудился день и ночь, но задача оказалась намного, неизмеримо труднее, чем он предполагал. И он рассчитывает на сочувствие. Я часто обнаруживал, что мне жалко того человека, который только что меня подвел. Может быть, зря?.
- Полагаю, - сказал я, - что иногда люди принимают на себя обязательства, потому что им кажется, что они сумеют сделать эту работу. И слишком часто, как мне кажется, они начинают что-то понимать, только вникнув в задачу глубже. Наверно, прежде чем брать на себя обязательство, они должны были попросить какое-то время, чтобы изучить задачу.
Роско кивнул. Очевидно, что он предпочел бы подождать более точной оценки, чем получить ненадежное обязательство. - Ну, - спросил я, - какова же третья стандартная отговорка?.
- Последняя отговорка, - продолжал Роско, - это старая песня про то, как «меня подвел мой субподрядчик». То есть тот, кто взял на себя обязательство, передал часть работы кому-то третьему, а тот не сделал работу в срок. Что, это моя проблема? Да нет, черт возьми! Я никаких подрядчиков не нанимал, я даже не знал об их существовании. Вполне может быть, что этот третий не выполнил своего обязательства, но это не моя забота. Я договаривался с первым человеком. Ответственность передо мной несет он. Конец разговора.
Должен сказать, что и эту историю я уже слышал.
И еще одна...
Так значит, - сказал я Роско, - вся катастрофа свелась к тому, что кто-то не выполнил своих обязательств? Не слишком ли все просто?.
- Можешь рассматривать это с каких угодно точек зрения, но мой ответ всегда будет один, - сказал Роско. - Да, есть люди, которые рисуют все эти диаграммы PERT и Ганта, пытаясь спланировать все сверху донизу. Можно соглашаться с тем, что они делают, или не соглашаться, и разные умные люди имеют разное мнение по этому вопросу. Одно мне ясно наверняка: учесть все зависимости трудно, и всегда по ходу дела будут возникать новые задачи, которые не были учтены в плане. Все эти диаграммы напоминают мне паутину. Если отвлечься от деталей, то можно сделать вывод, что результат зависит от целостности паутины. Если хочешь, можешь называть ее сетью. Для меня это сложный набор звеньев в очень сложной n-мерной цепи.
Я пытался понять, куда клонит Роско. Едва ли он собирался читать мне лекцию по теории графов. Но я не стал вмешиваться и ждал.
- Далее я могу попытаться определить, что случится с моим графиком работы, если одно из звеньев разрушится. Если это звено входит в критический маршрут, я могу быть уверен, что весь проект будет задержан. Если маршрут не критический, общей задержки может и не произойти - смотря по тому, насколько задержится именно та конкретная область. Но все мы знаем, что проекты обычно опаздывают не из-за какого-то одного катастрофического провала - серьезного повреждения одного звена, - а из-за того, что есть много-много звеньев, в каждом из которых есть маленькая задержка, или, лучше сказать, каждое чуточку надломлено. Поэтому, как я понимаю, целостность всего графика - это суммарная целостность всех и каждого из его звеньев.
«А что есть каждое звено, - торжествующе закончил Роско, - как не взятое на себя обязательство? Моя гипотеза: в большинстве проектов неприятности происходят из-за накопления всех невыполненных обязательств. И это одна из причин, по которым менеджеры проектов обычно не могут понять, чем вызван провал. Не было какой-то одной большой поломки: просто накопилась масса мелочей. Это очень коварно».
Удар, защита, ответный удар.
Во всем этом разговоре меня беспокоила одна проблема, и я решил, не откладывая, выложить ее перед Роско.
- Роско, - начал я, - мне понятно твое желание привнести в процесс больше реализма и честности, но, честно говоря, мне кажется, что ты заблуждаешься. Разве можно сравнить простую детерминированную задачу с четкой целью, такую как перевозка труб в определенную точку, с выпуском большого и сложного программного пакета, когда неизбежны исследования, применение новых технологий и неопределенность? Ведь сравнивать такие задачи несправедливо!.
- Извини, сынок, - ответил Роско, - но ты немного сбился. Правильной аналогией будет сравнить выпуск сложного программного продукта с получением первой бочки нефти из скважины. Кто тебе сказал, что это простая или детерминированная задача? Будь это так, мы никогда не сталкивались бы с сухими дырками. Но скажу тебе - я ни минуты не сомневаюсь в этом, - что вовремя поставить сколько-нибудь нефти можно только совместным выполнением всех взаимозависимых подзадач, включая своевременный подвоз труб. Я утверждаю, что все сложные проекты от бурения нефтяных скважин до разработки программ можно фактически разложить на мелкие конечные задачи. Каждую из них можно оценить с большей или меньшей степенью неопределенности. Но, в конце концов, каждая из этих задач и ее оценка представляют собой обязательство. Можно взглянуть на это иначе. Мы всегда стараемся работать в условиях, которые мы называем атмосферой высокого доверия. Это такая обстановка, в которой можно неявно положиться на товарища по работе. Если хочешь, «единицей измерения доверия» можно считать обязательство.
- Почему же тогда, - возразил я, - те, кто работает над большими проектами, так небрежно относятся к своим оценкам и обязательствам?.
Жертва большого проекта.
- Ну, это просто, - отвечал Роско. - Ребята из NASA с этим разобрались. Это называется жертва большого проекта. Во всех крупных проектах люди считают, что кто-то другой опоздает еще больше, чем они сами. Им кажется, что если они слегка задержатся, это будет незаметно на фоне чьей-то крупной задержки. Шутники в NASA утверждают, что когда идет обратный счет перед пуском, только в последние 10 секунд кто-нибудь не выдерживает и прерывает запуск. Все ждут, чтобы кто-то другой вышел из игры первым.
Это показалось мне серьезной проблемой. Роско подтвердил, что так оно и было.
- Да, тут извращенная психология, - сказал он в завершение. - Когда ты связываешь свой «успех» с провалом другого человека, то встаешь на гибельный путь. Но в этом и есть суть «жертвы большого проекта». Ты рассчитываешь, что кто-то другой напортачит больше тебя. Это сильно подрывает мораль проекта и идею атмосферы высокого доверия.
Роско был снова прав, но я выпустил еще не все свои стрелы.
Конец программных разработок в прежнем понимании?.
- Хорошо, Роско, - сказал я, - но твой подход порождает другую проблему. Если все проникнутся такой ответственностью за свои обязательства, как тебе хочется, не станут ли их оценки настолько консервативными, что, сложив их все в один график, ты обнаружишь, что не стоит и начинать проект, потому что теперь для него потребуется в три раза больше времени?.
- Экая у тебя длинная получилась фраза, - подмигнул мне Роско. - Да, такое препятствие есть, и я знаю два обходных маневра. Во-первых, надо справиться с перестраховкой.
Ты должен добиться уменьшения таких консервативных оценок, при которых все задачи или обязательства окажутся выполненными. Надо добиться от людей таких оценок, чтобы их обязательства оказывались выполненными в 80-90% случаев. Сегодня мы не дотягиваем и до 50%, что совершенно недопустимо. Во-вторых, стоит подумать о том, чтобы чаще закрывать проекты на ранних стадиях. Я слишком часто сталкиваюсь с графиками, которые лишь суммируют самые оптимистичные оценки для подзадач. Это не графики работы, а бесплодные мечтания. Такие проекты заранее обречены на провал. Исполнители говорят своим менеджерам то, что тем хотелось бы слышать, а менеджеры слушают, как завороженные. Проходит несколько месяцев или лет, результаты этого фарса обрушиваются вам на голову, и начинается охота на ведьм. ЭТУ ПОРОЧНУЮ ПРАКТИКУ НАДО ПРЕКРАТИТЬ!!!.
На правом виске Роско вздулась вена, поэтому я предпочел немного отступить и смягчить свой заключительный выпад.
Проработка и построение системы.
- А что ты скажешь по такому поводу, - начал я. - В Rational Unified Process средние две фазы, проработка и построение системы, занимают больше всего времени.
Я могу себе представить графики работы на основе обязательств для фазы построения системы, когда мы уже достаточно хорошо представляем себе, чем мы занимаемся. Но для этапа проработки, где все еще в большом объеме присутствуют исследования и риск, это проблематично.
- Хорошее замечание, - признал Роско.- Начнем с построения системы. Даже там мы сегодня много теряем из-за нарушения обязательств, поэтому усиление ответственности несомненно должно улучшить нашуэффективность. Взято на заметку. Кстати, я подозреваю, что обязательства так часто не выполняются на этапе построения системы потому, что на этапе исследования оценка трудоемкости задач была проведена плохо. Когда во время построения в массовом порядке нарушаются сроки, это служит верным признаком того, что предыдущий этап, этап проработки, был завершен преждевременно - возможно, из-за того, что поджимали сроки. Расплачиваться, разумеется, приходится на следующей стадии.
- Однако, - продолжил он, - вернемся к исследованиям. Нам еще предстоит научиться лучше определять объем и сроки исследовательских работ, которые, напомню тебе, можно разбить на более мелкие подзадачи с меньшей степенью неопределенности и с лучшими возможностями для оценки сроков. Нам нужны обязательства с жесткими сроками и на стадии проработки, чтобы стимулировать принятие решений. В противном случае мы будем вечно изучать проблему. Полезно устанавливать срок для принятия решений по рискованным вопросам. Это концентрирует усилия и гарантирует подведение окончательной черты.
Мне больше нечего было возразить. Как всегда, Роско продумывал партию не на два хода вперед, а на шесть.
Жестокая любовь.
- Итак, - сказал Роско, - спускаемся на землю. Я сажусь со своими менеджерами и учу их жизни. Отныне мы делаем честные оценки и даем реальные обещания. И пусть пеняет на себя тот, кто еще раз позволит себе не сделать работу вовремя.
- Кстати, - сказал он застенчиво, - я и сам больше не засну за рулем.
Мне показалось в тот момент, что первый промах Роско будет у него.
и последним.
Резюме.
Материал этой главы вызвал более горячие дебаты, чем вся остальная книга. Разработчикам программ и их менеджерам очень не нравится мое жесткое отношение к принятым обязательствам. Они все время пытаются мне доказать, что «разработка программ - это очень специфическая область».
Извините, ребята, но я с вами не согласен. В любых сферах человеческой деятельности существуют риск и неопределенность. В каждом из когда-либо предпринятых проектов был элемент новизны. У всех проектов слишком сжатые сроки и недостаточные ресурсы. Поинтересуйтесь у своих друзей, работающих в других областях. Не настолько вы исключительны.
Дело не в том, что я не способен посочувствовать. В разработке программ есть свои особые проблемы. Одна из наиболее зловредных среди них - заблуждение руководства по поводу того, что в последнюю минуту можно все переиначить, стоит лишь чудесным образом заменить одну строку кода другой. Так не бывает, это вымысел. Скорее всего, при выявлении проблемы потребуется существенная переработка продукта, как и во всякой другой области, где результат определяется архитектурой.
Часто можно услышать другой аргумент: дескать, в любом грандиозном программном проекте есть новые и уникальные особенности, затрудняющие планирование и своевременную поставку и в принципе превращающие его в научно-исследовательскую задачу. У меня есть два возражения:.
• Во-первых, если построить процесс так, чтобы исследовательская часть проекта была ограничена и замкнута в фазе «проработки» (как в Rational Unified Process), то ее можно контролировать и удерживать в рамках. Здесь может сильно помочь итеративная разработка, нацеленная на уменьшение рисков.
• Во-вторых, я готов держать пари, что большинство программных проектов не укладывается в сроки не из-за затягивания исследовательской стадии, на которую обычно выделяется относительно небольшое время. Нет, чаще проект опаздывает из-за плохого выполнения рутинной части работы, а исследования и разработки становятся козлом отпущения. Легче заслужить прощение за срыв той части проекта, которая связана с высокой наукой, чем отпущение грехов за неспособность справиться с самыми обыденными вопросами.
С чем бы я хотел раз и навсегда покончить, так это с представлением отом, что ПО обладает какими-то особыми свойствами, из-за которых нельзя требовать от разработчиков, чтобы они отвечали за взятые на себя обязательства. Эта идея неправильна и опасна. Она всегда служит оправданием бездеятельности и в значительной мере обусловливает сегодняшний непрофессионализм в разработке ПО. Профессионалы серьезно относятся к своим обещаниям и всегда отвечают за них. Это важнейшее понятие как для отдельных лиц, занимающихся разработкой программ, так и для профессии в целом.
В связи с этим есть важное указание и для менеджеров: не вынуждайте работников брать на себя обязательства, которые они считают нереалистичными, но которые устраивают вас по срокам. Вы можете вынудить их к этому своим давлением, но эта победа будет слабым утешением, когда окажется, что обязательства не выполнены. Только тогда у обязательств есть достаточные шансы быть выполненными в срок, когда они достигнуты в результате компромисса между менеджером и разработчиком, который оставил каждого из них с чувством легкой неудовлетворенности.
В следующей главе я перехожу к теме, которую открыто никогда не обсуждают. Это деликатная тема вознаграждения за труд. Почему так мало советов можно найти в этой области? Вы найдете некоторые новые интересные идеи по этому поводу на следующих страницах.