Текст бизнес-книги "Сделано"

Автор книги: Скотт Беркун

Раздел: Зарубежная деловая литература, Бизнес-книги

Задача проектного менеджмента

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

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

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

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

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

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

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

Программный и проектный менеджмент в Microsoft

В конце 1980-х годов Microsoft столкнулась с проблемой координации технической работы с задачами маркетинга и бизнеса (некоторые скажут, что это до сих пор остается проблемой для Microsoft и многих других компаний). Мудрый человек по имени Джейб Блюменталь придумал должность, на которой человек одновременно будет выполнять лидерские и организационные функции. Ему предстояло работать над проектом с первого дня планирования и до последнего дня тестирования. Он должен был разбираться в технических вопросах настолько, чтобы завоевать уважение программистов, уметь широко смотреть на продукт, а кроме того с радостью заниматься написанием спецификаций, анализом маркетинговых планов, составлением графиков, управлением командами, стратегическим планированием, триажем ошибок, мотивированием команды и любой другой необходимой работой, которую не выполняет никто иной (по крайней мере, достаточно хорошо). Новая должность в Microsoft получила название программный менеджер. Он обладал значительными полномочиями, хотя не все члены команды находились в его прямом подчинении. (В теории менеджмента это пример матричной организационной структуры[17]17
  Резюме матричной организационной структуры и других типов см. Steven A. Silbiger The Ten-Day MBA (William Morrowand Company, 1993) (Силбигер С. МВА за 10 дней. Самое важное из программ ведущих бизнес-школ мира. М.: Альпина Паблишер, 2018), pp. 139–145. Хотя информацию можно найти почти в каждой книге по теории менеджмента.


[Закрыть], которая предполагает двойное подчинение: в зависимости от должности сотрудника и в зависимости от проекта. Так, программист или тестировщик подчиняются двум менеджерам.)

Джейб стал программным менеджером в работе над продуктом под названием Multiplan (позже его переименовали в Microsoft Excel), и успех не заставил себя ждать. Улучшились процессы проектирования и разработки и координация работы команды, и все были счастливы. После многочисленных совещаний и рабочих встреч команды адаптировались к новой роли. Поручив конкретные обязанности линейному эксперту широкого профиля, Microsoft навсегда изменила динамику работы команд разработчиков. Практически все время работы в Microsoft я как раз выступал в роли программного менеджера. Я работал с продуктовыми командами Internet Explorer, MSN и Windows и даже руководил командами программных менеджеров.

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

Однако независимо от того, что было написано на моей визитке или каким легендам Microsoft вы верите, мои ежедневные обязанности в качестве программного менеджера совпадали с функциями менеджера проекта. В двух словах, это означало, что я ответственен за успех проекта – и всех, кто в нем участвует. Все главы этой книги отражают основные задачи, связанные с этой функцией, от предварительного планирования (глава 3 и глава 4) до спецификаций (глава 7), проектных решений (глава 8), разработки и выпуска (глава 14 и глава 15).

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

Сбалансированность проектного менеджмента

Сложно найти хороших менеджеров проекта, потому что им нужно гармонично сочетать в себе разные мировоззрения. В своем эссе Pursuing the Perfect Project Manager[18]18
  http://www.tompeters.com/col_entries.php?note=005297&year=1991.


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

• Эгоизм / альтруизм. Из-за колоссального объема ответственности менеджеры проекта зачастую черпают огромное личное удовлетворение в работе. Как вы понимаете, они вкладывают немало эмоций в свое дело, и зачастую именно это позволяет им выдержать его интенсивность. Однако в то же время менеджеры проекта не должны ставить личные интересы превыше проекта. Они должны быть готовы делегировать важные или интересные задачи и делить славу со всей командой. Хотя эго может быть полезным топливом, грамотный менеджер проекта должен чувствовать, когда он перегибает палку.

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

• Терпимость к неопределенности / стремление к завершенности. Ранние этапы любого проекта – абсолютно открытый и изменчивый опыт, где неизвестное перевешивает известное. Как мы обсудим в главе 5 и главе 6, контролируемая неопределенность необходима для поиска хороших идей, и менеджер проекта должен чтить эту особенность, даже если не удается управлять ею. Однако есть моменты, особенно на более поздних этапах проекта, когда дисциплина и точность имеют первостепенное значение. Нужна мудрость, чтобы понять, когда стремление к завершенности оправдано, а когда вполне достаточно решения на скорую руку (раздел «Поиск и оценка вариантов» в главе 8).

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

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

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

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

• Вера / скептицизм. Нет ничего лучше для морального духа команды, чем авторитетный лидер, который верит в то, что она делает. Для менеджера проекта важно чувствовать уверенность в работе и видеть истинную ценность в задачах, которые нужно выполнить. В то же время необходима здоровая доля скептицизма (не цинизма) относительно того, как продвигается работа и как решаются эти задачи. Кто-то должен зондировать почву, задавать вопросы, обличать существующие предположения и проливать свет на сложные моменты. Баланс заключается в том, чтобы активно задавать вопросы и бросать вызов убеждениям команды, но при этом не поколебать ее веру в то, что она делает.

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

Стресс и отвлекающие факторы

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

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

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

НЕ ПУТАЙТЕ ПРОЦЕСС И ЦЕЛИ

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

Чтобы свести к минимуму возможную путаницу, грамотные менеджеры не делят работу на приятную и неприятную. Они не проводят границ между задачами проект-менеджмента и самим проектом. Жесткая привязанность к чек-листу предполагает наличие определенного процесса, который гарантирует определенный результат, а так никогда не бывает. В реальности есть три вещи: задача, масса работы и группа людей. Четко определенные роли (глава 9) помогают организовать работу, однако формирование ролей не самоцель. Чек-лист помогает выполнить работу и достичь цели, однако он тоже не цель. Путать процессы с задачами – одна из самых серьезных ошибок. Знаю, потому что сам грешен.

Много лет назад я руководил разработкой нескольких сложных компонентов пользовательского интерфейса в проекте Internet Explorer 4.0. Я чувствовал себя под прессом: такой важной задачи мне еще никогда не поручали. Я решил, что если все записать в виде чек-листов, успех гарантирован. Конечно, работу по проекту нужно отслеживать, но я дошел до крайности. Данные отображались в сложной электронной таблице, а в офисе висела огромная доска со списками и таблицами (при этом я собирался повесить еще несколько).

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

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

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

Грамотная вовлеченность

Все менеджеры – от управляющих Fortune 500 до тренеров спортивных команд – подвержены чрезмерной вовлеченности. Они понимают, что чаще всего зря сотрясают воздух, и маниакальное участие – один из наиболее удобных (хотя и негативных) способов компенсировать свое бессилие. Это отчасти объясняет бесконечный поток микроменеджеров; самый простой ход для слабого менеджера – злоупотреблять своей властью над подчиненными (и в крайних случаях обвинять их в некомпетентности, из-за которой приходится уделять им столько внимания). Неуверенность, которую испытывают менеджеры, вызвана тем фактом, что, выражаясь терминами индустриальной революции, они не участвуют в производственной цепочке. Они ничего не делают своими руками и по своей ценности явно отличаются от тех, кто делает.

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

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

ВАШЕ ВЫГОДНОЕ ПОЛОЖЕНИЕ

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

У меня была привычка ходить по коридорам и заглядывать к программистам. Обычно я обменивался с ними парой слов, рассказывал анекдот и просил показать, над чем они работают. Иногда смотрел демо-версию. Я делал это раз в два-три дня, тратил всего несколько минут и прекрасно представлял себе реальный статус проекта (в главе 9 мы обсудим этот принцип управления – метод хождения).

Однажды утром, во время работы над проектом IE 5.0, я заглянул в офис Фреда. Обнаружив проблемы совместимости, он спорил со Стивом, другим программистом, о том, как исправить элемент управления для прокручиваемого списка. Никто из них не хотел заниматься этой работой. Не вмешайся я, они бы впустую потратили полдня или даже больше. Я уточнил, о чем спор. Оба замотали головами, словно хотели сказать: «А тебе-то какая разница?» Я предложил им поговорить с Биллом из соседнего отдела. Они снова спросили: «Зачем?», будучи уверены, что мне недоступны тонкости архитектуры проекта. Я улыбнулся и сказал: «Посмотрите на новый элемент управления, который уже прекрасно работает. Билл столкнулся с проблемой вчера вечером и решил ее в рамках другой задачи».

Конечно, я не спас мир и не предотвратил катастрофу. Если бы я не направил их к нужному человеку, они потратили бы всего несколько часов или полдня (как мы обсудим в главе 8, графики иногда сдвигаются). Но дело не в этом. Грамотный менеджер проекта собирает максимально полезную информацию о положении команды (и о положении мира) и с помощью нее помогает людям выполнить задачи. Именно эти своевременные фрагменты информации, как в нашем примере, превращают посредственные команды в хорошие, а хорошие – в блестящие. Ни одна система мониторинга проекта или ошибок не заменит полностью человеческое общение, потому что социальные сети всегда сильнее (а иногда и быстрее), чем технологические. Такие масштабные задачи, как видение проекта, списки функций и график, всегда сводятся к множеству небольших задач, которые легче решать, когда команде доступны нужные знания. МП играет критически важную роль в поддержании потока информации в активном и здоровом состоянии.

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

МЕНЕДЖЕРЫ ПРОЕКТА СОЗДАЮТ УНИКАЛЬНУЮ ЦЕННОСТЬ

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

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

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

В конце концов, если никто не пострадал (кроме, возможно, конкурентов) и вы правильно организовали работу команды, остальное неважно, главное – выполнить то, что нужно выполнить. Не имеет значения, сколько идей предложили вы, а сколько кто-то другой, если результат в итоге положительный. В управлении проектами используются все средства, необходимых для роста вероятности и темпов получения позитивных результатов. Полезный ежедневный принцип, который я применял, звучит так: «Добивайтесь хороших результатов!» Люди видели меня в коридорах компании или в офисе программистов у доски с графиками и таблицами и спрашивали: «Привет, Скотт, чем занят?» Я улыбался и отвечал: «Добиваюсь хороших результатов». Это стало доминирующим методом работы день за днем и хорошо влияло на команду.

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