Программист-прагматик. Путь от подмастерья к мастеру

Эндрю Хант, Дэвид Томас
Программист-прагматик
Путь от подмастерья к мастеру

Высказывания программистов-практиков о книге "Программист-прагматик"

      Главное в этой книге то, что она поддерживает процесс создания программ в хорошей форме. [Книга] способствует вашему постоянному росту и явно написана людьми, знающими толк в программировании.
Кент Бек, автор книги Extreme Programming Explained: Embrace Change

 

      Я обнаружил, что эта книга является смесью убедительных советов и замечательных аналогий!
Мартин Фаулер, автор книг Refactoring и UML Distilled

 

      Я бы купил книгу, прочел ее дважды, а затем сказал бы всем моим коллегам, чтобы они скорее бежали в магазин и купили себе по экземпляру. Эту книгу я никогда не дал бы никому почитать, так как сходил бы с ума от беспокойства за ее сохранность.
Кевин Руланд, сотрудник отдела менеджмента фирмы MSG-Logistics

 

      Мудрость и практический опыт авторов очевидны. Разделы, представленные в книге, уместны и полезны… Сильнейшее впечатление на меня произвели выдающиеся аналогии – стрельба трассирующими, разбитые окна и фантастическое по своей аналогии с управлением вертолетом объяснение необходимости ортогонального подхода, что особенно важно в критической ситуации. Я практически не сомневаюсь, что эта книга станет превосходным источником полезной информации как для начинающих программистов, так и для умудренных опытом мэтров.
Джон Лакос, автор книги Large-Scale С++ Software Design

 

      Когда такие книги появляются на прилавках магазинов, я покупаю по десять экземпляров для раздачи моим клиентам.
Эрик Вот, инженер-программист

 

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

 

      Прочитав книгу, я реализовал много из тех практических предложений и подсказок, которые дают нам авторы. Честно говоря, они сэкономили моей фирме время и деньги, помогая выполнить работу быстрее! "Программист-прагматик" должен стать настольной книгой для всех, кто зарабатывает на жизнь программированием.
Джаред Ричардсон, старший программист фирмы iRenaissance, Inc.

 

      Я хотел бы, чтобы эта книга попала ко всем новым сотрудникам моей фирмы.
Крис Клилэнд, Старший инженер-программист фирмы Object Computing, Inc.

Предисловие

      Книга, которую вы сейчас держите в руках, попала ко мне как рецензенту еще до выхода в свет. Даже в черновом варианте она оказалась превосходной. Дэйву Томасу и Энди Ханту есть что сказать, и они знают, как сказать. Я видел то, над чем они трудились, и уверен, что сделанное ими будет работать. Меня попросили написать это предисловие, в котором я объясняю причины своей уверенности.
      В этой книге говорится о способе программирования, которому вы можете последовать. Вполне возможно, что вы даже и не думали, что программирование окажется таким трудным занятием, но дело обстоит именно так. Почему? С одной стороны, не все книги по программированию написаны профессиональными программистами. Многие из них скомпилированы создателями языков программирования или же журналистами, которые сотрудничают с ними в продвижении на рынок этих языков. Книги эти рассказывают вам, как общаться на некоем языке программирования (что, конечно, является немаловажным фактором), но это лишь малая часть того, чем, собственно, занимается программист.
      Что же программист делает помимо общения на языке программирования? Эта проблема достаточно глубока. Большинство программистов затруднились бы объяснить, что же они делают. Программирование – это работа, насыщенная подробностями, и для того чтобы уследить за ними, необходимо сосредоточиться. Проходит время, на свет появляется программа. Если всерьез не задумываться над тем, что вы делали, можно придти к выводу, что программирование сводится к набору операторов на специфическом языке. Разумеется, это неправда, но вы ни за что бы так не подумали, осмотревшись по сторонам в секции программирования книжного магазина.
      В своей книге "Программист-прагматик" Дэйв и Энди рассказывают нам о способе программирования, которому мы можем последовать. Как же им удалось добиться таких успехов? Не сосредоточились ли они на деталях, уподобившись другим программистам? Нет, они лишь уделили внимание тому, что они делали, во время самой работы, а затем попытались сделать это несколько лучше.
      Представьте, что сидите на совещании. Наверное, выдумаете, что совещание длится целую вечность, а вместо него лучше было бы заняться программированием. Дэйв и Энди в такой ситуации думали бы о том, почему происходит это совещание, и задались вопросом, существует ли что-то еще, что они могли бы сделать вместо совещания, и может ли это «что-то» быть автоматизировано таким образом, чтобы это совещание проходило не в настоящем, а в будущем. Затем они бы осуществили задуманное.
      Именно таков образ мышления Дэйва и Энди. Это совещание не отвлекало бы их от программирования. Напротив, это и было бы программирование. И этот способ может быть усовершенствован. Я знаю, что они мыслят именно таким образом, поскольку в книге есть подсказка 2: "Думай! О своей работе".
      Представьте себе, что авторы мыслят подобным образом на протяжении нескольких лет. У них вскоре должна была бы собраться целая коллекция решений. Теперь представьте, что они используют эти решения в своей работе на протяжении еще нескольких лет и при этом отказываются от слишком трудных решений или тех, что не всегда приводят к желаемому результату. Этот подход и может быть определен как прагматический. Вы, вероятно, подумаете, что подобная информация – настоящая золотая жила. И будете правы.
      Авторы рассказывают нам, как они программируют. И рассказывают тем способом, которому мы можем последовать. Но в последнем утверждении есть нечто большее, чем вы думаете. Позвольте мне объяснить.
      Авторы проявили осторожность, избегая выдвижения теории разработки программного обеспечения. Это хорошо, поскольку в противном случае им пришлось бы исказить всю книгу, защищая эту теорию. Подобное искажение является традицией в физике, где теории в конечном счете становятся законами или же преспокойно отвергаются. С другой стороны, программирование подчиняется немногим (если вообще каким-нибудь) законам. Поэтому совет в области программирования, вращающегося вокруг квазизаконов, может прекрасно выглядеть в теории, но на практике не провалиться. Именно это происходит со многим книгами по методологии.
      Я изучал эту проблему в течение десяти лет и обнаружил, что самым многообещающим является подход, называемый языком шаблонов. Вкратце шаблон представляет собой некое решение, а язык шаблонов является некой системой решений, подкрепляющих друг друга. Вокруг поиска таких систем сформировалось целое сообщество.
      Эта книга – нечто большее, чем просто собрание подсказок. Это и есть язык шаблонов, но в "овечьей шкуре". Я говорю так потому, что каждая подсказка получена из реального опыта, подана как конкретный совет и соотносится с другими, образуя систему. Подсказки представляют собой характеристики, которые позволяют нам изучать язык шаблонов и следовать ему.
      Вы можете следовать советам, содержащимся в данной книге, потому что они конкретны. В книге нет расплывчатых абстракций. Дэйв и Энди пишут непосредственно для вас, так, как будто каждая подсказка является жизненно необходимой для пробуждения вашей карьеры в сфере программирования. Они упрощают эту сферу, они рассказывают некую историю, используют легкие намеки, а затем отвечают на вопросы, возникающие, когда вы попробуете сделать что-либо.
      Есть и нечто большее. После того как вы прочтете десять или пятнадцать подсказок, вам начнет открываться новое измерение вашей работы. В английском языке это измерение обозначается аббревиатурой QWAN (Quality Without A Name – качество без имени). Книга содержит философию, которая будет внедряться в ваше сознание и смешиваться с вашей собственной. Она не занимается проповедью. Она лишь сообщает, что может работать. Но рассказ способствует проникновению внутрь. В этом состоит красота этой книги: она воплощает философию и делает это непретенциозно.
      И вот она перед вами – простая в чтении и применении книга о практике программирования. Я все говорю и говорю о том, почему она действенна. Вам же, вероятно, нужно, чтобы она действовала в принципе. Она действует. Вы это увидите вами.
       Уорд Каннингхэм

От авторов

      Эта книга поможет вам стать лучшим программистом.
      Неважно, кем вы являетесь – разработчиком-одиночкой, членом большой проектной команды или консультантом, одновременно работающим со многими заказчиками. Эта книга поможет вам – отдельно взятой личности – повысить качество работы. Она не посвящена теории, авторы сосредоточились на практических аспектах, на том, как использовать свой опыт для принятия более продуманных решений. Слово «прагматик» происходит от латинского pragmaticus-"сведущий в каком-либо виде деятельности", а оно, в свою очередь, от греческого Trpaxxeiv, означающего "делать что-либо". Таким образом, эта книга посвящена деятельности.
      Программирование – это прикладное искусство. Его простейший смысл заключается в следующем: заставить компьютер делать то, что вам нужно (или то, что нужно пользователю, работающему с вашей программой). Программист – он и слушатель, он и советник, он и переводчик и даже диктатор. Вы пытаетесь ухватить суть не совсем ясных требований и найти такой способ их выражения, что только машина сможет оценить его по достоинству. Вы пытаетесь задокументировать работу так, чтобы она была понятна другим, спроектировать ее так, чтобы другие могли на нее положиться. Кроме того, вы пытаетесь сделать все это вопреки безжалостному ходу стрелки часов, отсчитывающих время, отпущенное на проект. Каждый день вы совершаете маленькое чудо.
      Это непростая работа.
      Многие предлагают вам помощь. Фирмы-поставщики инструментальных средств настойчиво говорят о чудесах, которые творят их программы. Мудрецы от методологии заверяют, что их средства гарантируют результаты. Каждый считает свой язык программирования лучшим из лучших, а операционную систему – панацеей.
      Разумеется, эти утверждения неверны. Простых ответов не существует. Нет такого понятия, как наилучшее решение, будь то инструментальное средство, язык или операционная система. Существуют лишь некие системы, которые являются более приемлемыми при конкретном стечении обстоятельств.
      И в этот момент на сцену выходит прагматизм. Стоит избегать обряда венчания с конкретной технологией, но при этом необходимо обладать подготовкой и опытом, настолько обширными, что это позволит выбрать верные решения в конкретных ситуациях. Ваша подготовка происходит из понимания основных принципов информатики, а опыт основывается на разнообразных практических проектах. Теория и практика сочетаются, придавая вам силу.
      Вы корректируете ваш подход, приспосабливая его к существующим обстоятельствам и окружающей среде. Вы оцениваете относительную важность всех факторов, влияющих на проект, и используете свой опыт в выработке приемлемых решений. И все это делаете непрерывно по ходу работы. Программисты-прагматики делают дело и делают его хорошо.

Кому адресована эта книга?

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

Как происходит становление программиста-прагматика?

      Каждый разработчик уникален, со своими сильными сторонами и слабостями, предпочтениями и неприязнью. С течением времени каждый создает собственную окружающую среду. Эта среда отражает индивидуальность программиста в той же степени, как его (или ее) хобби, одежда или прическа. Однако, если вы принадлежите к программистам-прагматикам, то у вас есть общие черты, характеризующие данный тип:
      •  Опережающее восприятие и быстрая адаптация.У вас есть инстинкт на технологии и методы, и вам нравится проверять их на практике. Вы быстро схватываете новое и объединяете его с уже имеющимися знаниями. Ваша уверенность рождается из опыта.
      •  Любознательность.Вы стремитесь задавать вопросы. "Это здорово – как тебе это удалось?" "У тебя возникали сложности при работе с этой библиотекой?" "Что это за система BeOS, о которой я как-то слышал?" "Как реализуются символические ссылки?" Вы – охотник до мелких фактов, каждый из которых может повлиять на то или иное решение даже годы спустя.
      •  Критическое осмысление.Вы редко принимаете что-то на веру, не ознакомившись предварительно с фактами. Когда коллеги говорят, что "этого не может быть, потому что этого не может быть никогда", или же фирма-поставщик обещает решить абсолютно все ваши проблемы, у вас возникает ощущение близящейся схватки с соперником.
      •  Реализм.Вы пытаетесь нащупать, где же находятся подводные камни в каждой проблеме, с которой приходится сталкиваться. Реализм дает понимание того, насколько трудными могут быть многие предметы и сколько времени займет то или иное действие. Осознание для себя, что процесс должен быть непростым или что для его завершения потребуется время, придаст вам жизненные силы, необходимые для его осуществления.
      •  Универсальность.Вы стараетесь познакомиться с большим числом технологий и операционных систем и работаете, чтобы не отставать от новшеств. Хотя для вашей теперешней работы может потребоваться узкая специализация, вы всегда сможете перейти в новую область, открывая для себя новые горизонты.
      Под конец авторы приберегли наиболее общие характеристики. Все программисты-прагматики обладают ими. Они настолько общие, что могут расцениваться как подсказки:
 

      Подсказка 1: Позаботьтесь о вашем ремесле

 
      Нет смысла разрабатывать программы, если вы не заботитесь о качестве работы.
 

      Подсказка 2: Думай! О своей работе

 
      Авторы призывают вас во время работы думать исключительно о работе – только так вы останетесь программистом-прагматиком. Это не случайная оценка существующей практики, а критическая оценка каждого принимаемого вами решения – в течение каждого рабочего дня и по каждому проекту. Никогда не пользуйтесь автопилотом. Думайте постоянно, критикуя свою работу в реальном масштабе времени. Старый девиз фирмы IBM "ДУМАЙ!" является своего рода мантрой для программиста-прагматика.
      Если сказанное покажется вам каторжной работой, это значит, что вы обнаруживаете реалистическое мышление. Это, вероятно, отнимет некоторую часть вашего драгоценного времени – того времени, которое уже спрессовано до крайности. Но наградой станет более активное вовлечение в работу, которую вы любите, чувство властителя над все большим числом предметов и удовольствие, порождаемое чувством постоянного усовершенствования. Вложенное вами время будет приносить доход в течение долгого периода по мере того, как вы и ваша команда будут работать с большей эффективностью, писать программы, которые легче поддерживать, и тратить меньше времени на производственные собрания.

Прагматики-одиночки и большие команды

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

      Отесывая камни, всегда думай о соборах, которые будут строиться из них.
Кредо средневекового каменотеса

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

Непрерывность процесса

      Во время экскурсии по Итонскому колледжу в Англии турист спросил садовника, как ему удается содержать лужайки в столь идеальном состоянии. "Это несложно, – ответил садовник, – вы просто стряхиваете росу каждое утро, выкашиваете лужайку через день и утрамбовываете раз в неделю".
      "И это все?" – спросил турист.
      "Абсолютно все, – ответил садовник, – если заниматься этим на протяжении 500 лет, то ваша лужайка будет не хуже".

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

Как составлена эта книга

      Книга состоит из кратких разделов, каждый из которых является законченным и посвящен определенной теме. В тексте есть перекрестные ссылки, которые помогают поставить каждую тему в контекст. Разделы можно читать в любом порядке – данная книга не предназначена для чтения от начала до конца.
      Периодически вам будут попадаться вставки типа "Подсказка nn" (например, "Подсказка 1: Позаботьтесь о вашем ремесле"). Помимо выделения некоторых важных моментов в тексте, подсказки живут своей собственной жизнью, а авторы живут по ним повседневно.
      В приложении А содержится перечень использованных ресурсов: библиографический список, список ссылок на web-ресурсы, а также перечень рекомендованных периодических изданий, книг и профессиональных организаций. В тексте книги есть библиографические ссылки и ссылки на web-ресурсы, такие как [КР99] и [URL 18] соответственно.
      Авторы включили также Упражнения и Вопросы для обсуждения. Упражнения (и ответы к ним) как правило, несложные, тогда как Вопросы для обсуждения более замысловаты. Для того чтобы передать свой образ мышления, авторы включили свои собственные ответы к упражнениям в приложение В, но лишь некоторые из упражнений имеют единственное корректное решение. Вопросы для обсуждения могут стать основой для групповых дискуссий или написания эссе на углубленных курсах программирования.

Исходные тексты программ и другие ресурсы

      Большинство программ, представленных в этой книге, извлечены из компилируемых исходных файлов, которые можно загрузить с web-сайта  .

Ваши отклики

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

Благодарности

      Когда мы начали писать эту книгу, у нас и в мыслях не было, сколько коллективных усилий необходимо для ее выпуска в свет.
      Издательство Addison-Wesley было как всегда великолепно, пригласив пару начинающих хакеров и показав авторам весь процесс издания книги – от идеи до оригинал-макета. Авторы выражают благодарность Джону Уэйту и Меере Равиндирану за поддержку в начале работы над книгой, Майку Хендриксону, редактору-энтузиасту (и оформителю обложки!), Лоррейн Ферье и Джону Фуллеру за помощь в производстве, а также неутомимой труженице Джулии Дебаггис, связавшей нас воедино.
      Затем наступил черед рецензентов. Это Грег Эндресс, Марк Чиэрс, Крис Кли-лэнд, Алистер Кокбэрн, Уорд Каннингхэм, Мартин Фаулер, Тхапг Т. Зиан, Роберт Л.
      Гласе, Скотт Хеннингер, Майкл Хантер, Брайан Кирби, Джон Лакос, Пит Макбрин, Кэри П. Моррис, Джаред Ричардсон, Кевин Рулэнд, Эрик Старр, Эрик Ваут, Крис Ван Вик и Дебора Зуковски. Без их заботливых комментариев и ценных советов эта книга читалась бы хуже, была бы менее точной и в два раза длиннее. Благодарим их за уделенное нам время и мудрость.
      Второе издание этой книги существенно выиграло за счет пристальных взоров читателей. Благодарим Брайана Блэнка, Пола Боула, Тома Экберга, Брента Фулгэ-ма, Луи Поля Эбера, Хенка-Яна Ульде Лоохюса, Алана Лунда, Гарета Маккофана, Иошики Шибату и Фолькера Вурста за найденные ошибки и деликатность, проявленную при указывании на них авторам.
      В течение многих лет мы работали с большим количеством продвинутых клиентов, от них мы набирались опыта, который и описали в этой книге. Недавно мы имели счастье работать с Питером Герке над несколькими проектами. Мы благодарны ему за его поддержку и энтузиазм.
      При издании данной книги использовались программные продукты LaTex, pic, Perl, dvips, ghostview, ispell, GNU make, CVS, Emacs, XEmacs, EGCS, GCC, Java, iContract и SmallEiffel, оболочки Bash и zsh в операционной среде Linux. Поражает тот факт, что все эта груда программного обеспечения распространяется абсолютно бесплатно. Авторы говорят «спасибо» тысячам программистов-прагматиков, создавших эти продукты и передавших их нам. Отдельно хотелось бы поблагодарить Рето Крамера за его помощь в работе с iContract.
      И последнее, но оттого не менее важное: авторы в огромном долгу перед своими семьями, которые не только смирились с поздним засиживанием за компьютером, огромными счетами за телефонные разговоры и постоянным беспорядком, но и благородно время от времени соглашались прочесть то, что написали авторы. Благодарим их за то, что они не давали нам спускаться с небес на землю.
       Энди Хант
       Дэйв Томас

Глава 1
Прагматическая философия

      Что отличает программистов-прагматиков? Мы полагаем, что это склад ума, стиль, философия подхода к существующим проблемам и их решениям. Прагматики выходят за пределы сиюминутной проблемы, всегда стараются рассмотреть ее в более широком контексте, осознать общую картину происходящего. В конце концов, как можно быть прагматиком вне широкого контекста? Как приходить к интеллектуальным компромиссам и принимать взвешенные решения?
      Другим ключом к успеху прагматиков является то, что они берут на себя ответственность за все, что они делают; это обсуждается ниже в разделе "Мой исходный текст съел кот Мурзик". Будучи ответственными, прагматики не сидят, сложа руки, глядя на то, как их проекты погибают из-за небрежного отношения. В разделе "Программная энтропия" говорится о том, как сохранить проекты в первоначальном виде.
      Большинство людей с трудом воспринимают изменения: иногда по понятным причинам, иногда в силу старой доброй инерции. В разделе "Суп из камней и сварившиеся лягушки" рассматривается стратегия провоцирования изменений, а также (для равновесия) предлагается поучительная сказка о некоем земноводном, которое не учло опасностей, таящихся в постепенном изменении.
      Одним из преимуществ понимания контекста, в котором вы работаете, является более легкое осознание того, насколько хорошими должны быть создаваемые программы. Иногда "почти идеальность" является единственно возможным вариантом, но зачастую приходится идти на компромиссы. Этот аспект исследуется в разделе "Приемлемые программы".
      Конечно, необходимо обладать обширной базой знаний и опыта, чтобы все это одолеть. Обучение представляет собой непрерывный и продолжительный процесс. В разделе "Портфель знаний" обсуждаются некоторые стратегии поддержания стремления к обучению.
      Разумеется, никто из нас не работает в безвоздушном пространстве. Все мы проводим большое количество времени в общении с другими людьми. В разделе "Общайтесь!" перечислены способы, как сделать это общение более эффективным.
      Прагматическое программирование ведет свое начало от философии прагматического мышления. В данной главе приводятся основные положения этой философии.

1
Мой исходный текст съел кот Мурзик

      Страх показаться слабым есть величайшая из всех слабостей.
Ж. Б. Боссюэ, Политика и Священное Писание, 1709

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

Принятие ответственности

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

      Подсказка 3: Представьте варианты решения проблемы, а не варианты отговорок

 
      Перед тем как подойти к кому-либо, чтобы высказать, почему что-либо не может быть сделано или уже сломалось, остановитесь и прислушайтесь к себе. Поговорите с резиновым утенком, стоящим на вашем мониторе, или с котом. Как звучит ваша отговорка, разумно или глупо? И как ее воспримет ваш шеф?
      Смоделируйте разговор в уме. Что, вероятнее всего, скажет ваш собеседник? Спросит ли он: "А так вы пробовали?" или "А это вы учли?" Как ответить? Перед тем как пойти и сообщить плохие новости, может, попробовать что-то еще? Иногда вы просто знаете, что он собирается сказать, поэтому избавьте его от лишних забот.
      Вместо отговорок представьте варианты решения проблемы. Не говорите, что это не может быть сделано, объясните, что может быть сделано для спасения ситуации. Может быть, взять да и выбросить исходный текст? Развивайте эти варианты, используя реорганизацию (см. "Реорганизация").