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

Семинар провел Асхат Уразбаев, вице-президент нашей Гильдии, евангелист Agile и Scrum, Agile Coach, совладелец компании ScrumTrek, основатель сообщества AgileRussia.

Семинар транслировался через Интернет в формате вебинара, что помогло принять в нем участие большому количеству желающих.

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC16.

Скачать презентацию

Предлагаем Вашему вниманию видеокаст выступления Асхата:

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

Докладчик: Асхат Уразбаев, вице-президент нашей Гильдии, евангелист Agile и Scrum, Agile Coach, совладелец компании ScrumTrek, основатель сообщества AgileRussia.

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC18.

Время проведения: 18:00 – 21:00
Место проведения: компания R-Style, ул. Пришвина, д.8, корп.2, 1-й этаж, ауд. 117. Схема проезда

Личное участие в семинаре бесплатное при условии предварительной регистрации.
Зарегистрироваться для участия

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

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

До встречи на семинаре!

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

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

Семинар провел Дмитрий Башакин, вице-президент нашей Гильдии, эксперт по управлению проектами Учебного Центра Luxoft; менеджер проектов и проектных программ с 12-летним стажем; в течение 6 последних лет – тренер-профессионал в области управления проектами по разработке программного обеспечения. В рамках тренерской деятельности в Учебном Центре Luxoft Дмитрием разработаны десятки тренингов и проведены сотни тренинговых сессий для сотрудников Luxoft и многих других компаний.

Семинар транслировался через Интернет в формате вебинара, что помогло принять в нем участие большому количеству желающих.

Участники могут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC16.

Скачать презентацию

Предлагаем Вашему вниманию видеокаст выступления Дмитрия:

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

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

Докладчик: Дмитрий Башакин, вице-президент нашей Гильдии, эксперт по управлению проектами Учебного Центра Luxoft; менеджер проектов и проектных программ с 12-летним стажем; в течение 6 последних лет – тренер-профессионал в области управления проектами по разработке программного обеспечения. В рамках тренерской деятельности в Учебном Центре Luxoft Дмитрием разработаны десятки тренингов и проведены сотни тренинговых сессий для сотрудников Luxoft и многих других компаний.

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC16.

Время проведения: 18:00 – 21:00
Место проведения: компания R-Style, ул. Пришвина, д.8, корп.2, 1-й этаж, ауд. 117. Схема проезда

Личное участие в семинаре бесплатное при условии предварительной регистрации.
Зарегистрироваться для участия

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

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

До встречи на семинаре!

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

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

Семинар транслировался через Интернет в формате вебинара, что помогло принять в нем участие большому количеству желающих.

Участники могут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC13.

Скачать презентацию

Предлагаем Вашему вниманию видеокаст выступления Сурена:

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

Докладчик: Сурен Самарчян, президент нашей Гильдии, руководитель департамента управления проектами в компании Иннова Системс. В Иннове и в ряде других компаний Сурену удалось радикально реструктурировать процессы, удваивая показатели предсказуемости, производительности и качества.

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC13.

Время проведения: 18:00 – 21:00
Место проведения: компания R-Style, ул. Пришвина, д.8, корп.2, 1-й этаж, ауд. 117. Схема проезда

Личное участие в семинаре бесплатное при условии предварительной регистрации.
Регистрация на семинар закрыта

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

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

До встречи на семинаре!

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

Семинар провел Максим Дорофеев, известный эксперт в IT-индустрии. Максим начал карьеру в 2002 году, как инженер по тестированию в компании DC BARS, специализирующейся на создании и сертификации бортового ПО гражданской авиации. Руководил проектами по созданию, поддержке и тестированию встраиваемого программного обеспечения. В июне 2009 года присоединился к команде Лаборатории Касперского для решения еще более сложных задач.

Семинар транслировался через Интернет в формате вебинара, что помогло принять в нем участие большому количеству желающих.

Участники могут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC11.

Скачать презентацию

Предлагаем Вашему вниманию видеокаст выступления Максима:

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

Докладчик: Максим Дорофеев, начал карьеру в 2002 году, как инженер по тестированию в компании DC BARS, специализирующейся на создании и сертификации бортового ПО гражданской авиации. Руководил проектами по созданию, поддержке и тестированию встраиваемого программного обеспечения. В июне 2009 года присоединился к команде Лаборатории Касперского для решения еще более сложных задач.

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC11.

Время проведения: 18:00 – 21:00
Место проведения: компания R-Style, ул. Пришвина, д.8, корп.2, 1-й этаж, ауд. 117. Схема проезда

Личное участие в семинаре бесплатное при условии предварительной регистрации.
Регистрация на семинар закрыта

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

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

До встречи на семинаре!

Руководитель проекта

Правило 1

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

Правило 2

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

Правило 3

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

Правило 4

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

Правило 5

Руководителями проектов могут быть порочные, презренные и совершенно неприятные люди. Бездушные, нерешительные копуши или болтуны – нет.

Правило 6

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

Правило 7

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

Правило 8

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

Правило 9

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

Правило 10

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

Правило 11

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

Правило 12

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

Правило 13

Руководитель, который является своим собственным системным инженером и финансовым менеджером, является тем, кто вероятно пытается сделать самому себе открытую операцию на сердце.

Правило 14

Большинство руководителей преуспевают за счёт усилий и навыков своего персонала.

Инициация проекта

Правило 15

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

Коммуникации

Правило 16

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

Правило 17

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

Правило 18

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

Правило 19

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

Персонал

Правило 20

Вы не можете наблюдать за всем. То, за чем вы должны наблюдать обязательно – это персонал. Люди должны знать, что вы не потерпите плохой работы.

Правило 21

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

Правило 22

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

Правило 23

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

Правило 24

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

Правило 25

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

Правило 26

Если кто-то не смотрит, не спрашивает, не анализирует, то попросите его уйти.

Правило 27

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

Правило 28

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

Правило 29

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

Правило 30

Некомпетентные специалисты обычно не любят демонстрировать свою работу.

Правило 31

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

Правило 32

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

Правило 33

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

Доклады и отчёты

Правило 34

В НАСА определён перечень стандартных докладов и тех должностных лиц, кто обычно ихрассматривает . Однажды настроенная, такая система будет бороться за то, чтобы продолжать существовать, так что вам остаётся максимально использовать её.

Правило 35

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

Правило 36

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

Правило 37

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

Правило 38

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

Правило 39

Отчёты пишутся не для того, кто их составляет, а для того, кому они предназначены. Если тот, для кого отчет предназначен, не узнает из него ничего нового, то такой отчет неудачен.

Правило 40

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

Правило 41

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

Правило 42

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

Правило 43

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

Правило 44

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

Правило 45

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

Правило 46

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

Контракты и субподрядчики

Правило 47

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

Правило 48

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

Правило 49

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

Правило 50

Быть в дружеских отношениях с субподрядчиком прекрасно, но дружеские отношения с субподрядчиком – подвергают опасности вашу объективность.

Правило 51

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

Правило 52

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

Правило 53

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

Правило 54

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

Инженеры и учёные

Правило 55

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

Правило 56

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

Правило 57

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

Правило 58

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

Правило 59

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

Аппаратное обеспечение

Правило 60

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

Правило 61

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

Компьютеры и программное обеспечение

Правило 62

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

Правило 63

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

Правило 64

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

Правило 65

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

Старшие менеджеры, руководители программ и те, кто над ними

Правило 66

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

Правило 67

Знайте своих руководителей – некоторые любят хорошую шутку, другие любят шутить только сами.

Правило 68

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

Правило 69

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

Правило 70

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

Правило 71

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

Планирование, бюджетирование и оценки

Правило 72

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

Правило 73

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

Правило 74

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

Правило 75

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

Правило 76

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

Правило 77

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

Правило 78

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

Правило 79

Следующий год – это всегда год с нормальным финансированием и графиком работ. Такой следующий год наступит на пятидесятом году вашей карьеры.

Заказчик

Правило 80

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

Инструкции НАСА по управлению

Правило 81

Инструкции по управлению в НАСА написаны другим служащим НАСА, таким же, как вы; следовательно, вы можете возражать, если инструкции будут лишены смысла. Если это возможно, другой служащий НАСА откорректирует инструкцию или согласится с отступлением от неё в вашем случае.

Принятие решений

Правило 82

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

Правило 83

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

Правило 84

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

Профессиональная этика и порядочность

Правило 85

Порядочность означает, что ваши подчинённые доверяют вам.

Правило 86

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

Управление проектом и рабочая группа

Правило 87

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

Правило 88

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

Правило 89

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

Правило 90

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

Правило 91

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

Переговоры и предотвращение неудач

Правило 92 В случае неудачи:

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

Правило 93

Думайте, что неудачи – это выученные на будущее уроки. Иногда правильно думать, что это только выученные уроки. Старайтесь повторять их во время работы.

Правило 94

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

Правило 95

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

Правило 96

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

Правило 97

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

Правило 98

Одним из достоинств НАСА в раннем периоде её существования был тот факт, что если некто что-то знал, то мы были абсолютно уверены, что он может быть неправ.

Правило 99

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

Правило 100

Никогда не оправдывайтесь; вместо этого представьте план действий, которые необходимо предпринять.

О документе

Документ подготовлен Джерри Мэддоном (Jerry Maddon), ассоциированным директором Директората полётов Годдартовского центра космических полётов NASA. Джерри собрал эти драгоценности мудрости за много лет из разнообразных источников. Они были отредактированы Родом Стюартом (Rod Steward) из Mobile Data Service из Хантсвилла в Алабаме (Huntsvill, Alabama),. 1 января 1995 года. Обновлено 9 июля 1996 года. Переработано и отформатировано Оливером Ф. Леманом (Oliver F. Lehmann, Ismaning, Germany). Контакт: Шерман Джоб (Sherman Jobe) Sherman.jobe@msfc.nasa.gov, (205)-544-3279.

Источники:

• Оригинальный английский текст (прим. редакции сайта Гильдии: ссылка, судя по всему, потеряла актуальность; английский текст можно посмотреть, например, в документе One Hundred Rules for NASA Project Managers)
• Русский перевод (PMProfy) (перевод: В. Куперштейн, редакция: В. Богданов)