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

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

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

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

Зачем нужна градация ошибок?

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

Но документирование – не первопричина. Важнее – накопление опыта.

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

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

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

По аналогии может помочь система градации ошибок менеджмента (системы управления предприятием или проектом).

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

Концепция «вина-ответственность» всегда остается актуальной.

Классификация рисков в IT-проектах

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

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

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

Сэм Канер в книге «Тестирование программного обеспечения» приводит следующую общую классификацию ошибок внутри программных продуктов:

  • Ошибки интерфейса (UX/UI).
  • Логика обработки ошибок (для облегчения их обнаружения).
  • Ошибки вычислений.
  • Ошибки обработки/интерпретации данных (очень близки по смыслу к вычислениям).
  • Проблемы начального и конечного состояния.
  • Превышение нагрузки.
  • Ситуация спешки.
  • Ошибки аппаратного обеспечения и несовместимость.
  • Контроль идентификаторов (процессов).
  • Ошибки, связанные с граничными условиями.

Но и это далеко не эталон. С появлением DevOps-подхода логика работы программ стала заметно сложнее. Ведь у вас в распоряжении могут быть контролируемые и неконтролируемые среды: сетевые стеки, сторонние сервисы и службы, и т.п.

Как можно классифицировать ошибки проектного менеджмента?

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

Наиболее универсальный подход в классификации любых ошибок – опирание на функции и задачи.

За что отвечает менеджер проекта? Ранее мы рассматривали обязанности администратора проекта, которые во многом дублируют обязанности менеджера (ведь администратор – правая рука руководителя команды).

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

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

Группы ошибок проектного менеджмента в зависимости от их источника

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

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

Заказчик:

  • Неправильные критерии оценки проекта.
  • Завышенные ожидания.
  • Непонимание отдельных внутренних процессов работы проектной команды.

Команда в целом (включая в том числе руководителя):

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

Внешняя среда:

  • Нестабильная экономическая ситуация на рынке или в конкретной (важной для проекта) сфере.
  • Изменение условий поставщиков (а поставщики есть даже в IT-проектах).

Как снизить количество ошибок проектного менеджмента?

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

Во-вторых, все потенциальные ошибки управления должны быть идентифицированы (как в матрице рисков) и для каждой конкретной ошибки должна быть определена вероятность наступления + определён эффект последствий (цена ошибки). Так вы сможете заранее оценить потенциальные проблемы и спланировать пути их обхода.

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

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

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

Если вы хотите ознакомиться с примерами типовых ошибок в проектах, у нас есть отдельный материал – «Почему стартапы терпят неудачи».

Ошибки в управлении проектами

Директор по стандартам Американского общества управления проектами Вильям Дункан считает, что проектным менеджерам в любой стране и в любой сфере бизнеса необходимы одни и те же навыки. Формированию этих навыков посвящены тренинги, которые он проводит в России по приглашению компании PSM Consulting

«Все ошибки одинаковы, независимо от страны»

Вильям Дункан – один из авторов первых версий стандарта по управлению проектами PMBoK, разработанного Институтом проектного менеджмента США (PMI USA). Долгое время он был директором этого института. Сегодня Дункан – совладелец и директор компании Project Management Partners, работающей в области консультирования и подготовки по управлению проектами. Свои тренинги он основывает на 30-летнем опыте управления и консультирования.

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

– В чем специфика вашего подхода к управлению проектами?

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

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

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

Кроме того, существование международного стандарта позволит не проходить сертификацию проектным менеджерам при перемещении из одной страны в другую.

– Каковы основные ошибки управления проектами в России?

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

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

Многие проектные менеджеры, отвечая на вопрос о цели проекта, говорят, например: «Наша задача – построить завод». Но, по сути, они не называют реальной цели – зачем им этот завод. А если ты не понимаешь назначения проекта, ты автоматически принимаешь неверные решения.

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

Другая распространенная ошибка – недостаточное понимание процесса оценки проекта. Многие путают оценку и формирование бюджета. В отличие от бюджетирования, оценка учитывает множество косвенных факторов, которые влияют на проект.

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

Так и с проектом – многие субъективные факторы влияют на него и, следовательно, на его бюджет.

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

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

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

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

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

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

«Это все равно что учить грамоте»

– Как за короткий срок научить человека управлять проектами?

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

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

– Но ведь все проекты разные. Как можно все свести к единому алгоритму?

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

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

– Какие стадии развития проекта вы разбираете?

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

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

«Мы моделируем не проблемы, а реальные ситуации»

– Как имитировать реальную обстановку для участников тренинга?

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

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

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

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

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

Источник: mybiz.ru

Ткаченко Елена

Логика управления проектами

  1. Управление
    проектами подчиняется четкой логике,
    которая связывает между собой различные
    области знаний и процессы управления
    проектами.

  2. У
    проекта обязательно имеются одна
    или несколько целей
    .

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

  4. В
    число основных критериев оценки
    различных вариантов исполнения проекта
    входят сроки
    и стоимость

    достижения результатов.

  5. Запланированные
    цели
    и качество

    служат основными ограничениями при
    рассмотрении и оценке различных
    вариантов.

  6. Для
    управления проектами необходимы рычаги.

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

Жизненный цикл проекта и фазы проекта

Начало
жизненного цикла проекта совпадает по
времени с началом проекта, а его окончание
– с завершением проекта.

Наиболее
традиционным является разбиение проекта
на
четыре крупных этапа:
разработка
концепции проекта(постановка), планирование
(разработка), реализация(исполнение) и
завершение(закрытие проекта) (рис. 1).

Рисунок
1 – Жизненный цикл проекта

1. Концепция проекта.

Разработка
концепции проекта, по существу
подразумевает функцию выбора проекта.

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

2. Разработка (Планирование).

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

Что
надо сделать?

Кто
сделает это?

Как
это будет сделано?

Когда
это должно быть сделано?

Сколько
это будет стоить?

Что
нам нужно чтобы сделать это?

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

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

3. Реализация (Осуществление).

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

На
правильном ли мы пути?

Если
нет, что нужно сделать?

Следует
ли изменить план?

4.
Завершение.

Рано
или поздно, но проекты заканчиваются.
Проект заканчивается, когда достигнуты
поставленные перед ним цели.

Что
сделано хорошо?

Что
следовало бы улучшить?

Что
мы узнали нового?

Процессы
управления проектами

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

Процессы
управления проектами могут быть разбиты
на шесть основных групп (рис. 2):

1.
процессы инициации;

2.
процессы планирования;

3.
процессы исполнения

4.
процессы анализа;

5.
процессы управления;

6.
процессы завершения.

 

Рисунок
2 – Процессы управления проектами

Процессы
инициации

Данный
процесс представляет собой принятие
решения о начале выполнения проекта.

Процессы
планирования

Процесс
определения целей и критериев успеха
проекта и разработка рабочих схем их
достижения

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

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

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

Процессы
планирования
представлены
на рисунке 3.

Рисунок
3 – Процессы планирования

Этапы
планирования

    1. Разработка
      формулировки миссии, целей и задач
      проекта.

Формулировка
миссии

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

Заказчик
проекта

– главная сторона, заинтересованная в
осуществлении проекта и достижении его
результатов.

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

Формулировка
миссии должна отвечать на три вопроса:

Что
мы делаем?

Для
кого мы это делаем?

Как
мы делаем это?

Когда
формулировка миссии разработана, можно
определить цели проекта. Цели намного
более конкретны, чем миссия.

Цель

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

Два
важных вопроса при установлении целей:

Каков
желаемый результат?

Как
вы узнаете, когда достигли желаемого
результата?

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

Согласно исследованию компании Hewlett-Packard 96% IT-проектов в России завершаются не вовремя. Это одни из самых низких показателей в Европе. В то время как в Швеции этот показатель равен 64%. Когда такое количество проектов срываются по срокам, вы начинаете искать решение этой проблемы.

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

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

  • Получаем вводные данные A.
  • Если данные соответствуют условию B, переходим на последовательность действий C;
  • Если данные соответствуют условию D, выполняем действия E.
  • Полученный результат передается на выход.

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

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

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

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

Причины по которым команды срывает сроки:

  • Ошибки при оценке задач
  • Ошибки при управлении изменениями
  • Проблемы в коммуникации и ожиданиях
  • Ошибки при подготовке к проекту
  • Недостаточная компетенция исполнителя
  • Демотивация команды

1. Ошибки при оценке задач

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

Причины оптимистичны оптимистичной оценки включают:

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

Как давать реалистичную оценку

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

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

Метод 1. Оценка по трем точкам

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

Для оценки по трем точкам есть формула:

Итоговая оценка = ((O + (3 × R) + P)) / 6

где,

О — оптимистичная оценка, если все идет по плану.

P — пессимистичная оценка, если все идет не по плану.

R — реалистичная оценка, среднее значение.

Метод 2. Декомпозиция.

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

Метод 3. Создание резервов.

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

Есть несложная формула, как рассчитать резервы.

Резервы = P х I, где

P – вероятность в процентах,

I – влияние в часах или в деньгах

Рассмотрим на примере. Представьте, что у вас на проекте есть риск того, что заказчик затянет согласование дизайна. Вы анализируете, какое влияние имеет этот риск. Допустим, на согласование уходит 3 дня. Вероятность, что заказчик затянет согласование – 30%. Это ваша экспертная оценка, которая опирается на ваш опыт. Если это случится, тогда повышается вероятность сорвать сроки. Используя формулу, получаем:

Резерв = 30% х 72 часа = 21,6 часа

Получается, что на этот риск можно заложить 22 часа.

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

Именно поэтому рисков должно быть много — хотя бы 20. Если у вас будет 2-3 риска, то резервов не хватит, чтобы все компенсировать.

2. Ошибки при управлении изменениями

Управление изменениями — это методология, которая помогает управлять запросами на изменение проекта.

Каждый кто работал с digital-проектами сталкивался с ситуацией, когда клиент просит внести незапланированные правки. При этом аргументируя это тем, что здесь работы на 10 минут. В итоге таких правок за время проекта может быть сотни. Как результат этого — просроченный дедлайн.

Решение проблемы:

Проговорите какой объем изменений на проекте возможен. Например, определите количество итераций дизайна или допустимое отклонение по часам без изменения срока.

Убедитесь, что клиент понимает, как это будет выглядеть на практике. Для этого объясняйте на примерах, а также фиксируйте все в договоре. А именно пропишите количество дополнительных правок, которые доступны клиенту. Обычно хватает 2-3 итерации правок.

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

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

3. Проблемы в коммуникации и ожиданиях

Представьте себе следующий разговор с программистом:

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

Как правильно сообщить об ожиданиях

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

Вот три способа как можно проверить, что ваша команда понимает свои сроки.

Способ 1. Используйте сервисы для управления проектами

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

Именно поэтому рекомендуем вести все задачи в сервисе для управления проектами.

Мы в Alto используем Trello. Она интуитивно понятная и при определенных настройках позволяет фиксировать время на задачу, показывать отчеты.

Способ 2. Получите обратную связь

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

Давайте пересмотрим приведенном выше диалог с учетом этого способа.

В итоге вы бы сразу узнали об этом до того, как сроки будут сорваны.

Способ 3. Внедрите периодические проверки

Добавьте периодические проверки в свой график. Так вы достигнете двух целей:

  • Напомните сотрудникам о дедлайне.
  • Дополнительная обратной связь

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

4. Ошибки при подготовке к проекту

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

Давайте рассмотрим, какие могут быть ресурсы проекта.

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

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

  • Время. Постройте график проекта. Отслеживайте время для анализа производительности команды, контрольных точек и планирования работ.

5. Недостаточная компетенция исполнителей

По данным отчета The Boston Consulting Group (BCG) почти 45% сотрудников в России не соответствуют занимаемой ими должности. В США этот показатель равен 33,5%, а в Германии — 37,2%.

Задача руководителя в этой ситуации — подбирать специалистов соразмерно задаче или наоборот. То есть менеджер должен сопоставить сложность проекта и возможности исполнителя.

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

Что делать если сотруднику не хватает компетенций:

  • Заложите больше часов на задачу. Во многих случаях, задача решаема, если выделить на нее больше времени.
  • Возьмите консультацию у senior-специалиста. Как показывает практика при поддержке опытного наставник junior-специалист выполняет задачу на уровне «middle».
  • Проведите обучение. Если сотрудник не обладает технологией, а заменить исполнителя уже нельзя. В этом случае разработайте программу обучения и внедрите ее в регулярный план работ. В короткой перспективе это замедлит проект, но к середине проекта вы заметите рост производительности

6. Демотивация команды

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

Персональная демотивация

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

Давай разберем несколько ситуаций

— Мне хотелось бы попробовать новые технологии на этом проекте. Я считаю, что мы слишком долго используем 1С-Битрикс, пора переходить на node.js.

Здесь можно найти решение если рассмотреть несколько смысловых слоев. На первом человек говорит про Битрикс и Node.js. На втором смысловом слое — хочет попробовать новое. Поэтому если хотите замотивировать этого сотрудника — дайте возможность сделать что-нибудь новое. Если такой возможности нет — создайте. Придумайте небольшой проект, где такая возможность появится

— Скучно, я уже такое делал. Знаю точно, что справлюсь. Хочется чего-то другого.

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

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

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

Командная демотивация

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

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

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

  • Поделите вашу работу на спринты.
  • Планируйте объем работ на каждый спринт
  • Подводите итоги спринта,
  • Следите за тем успеваете ли вы в срок

Итог кратко

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

  • Ошибки при оценке задач
  • Ошибки при управлении изменениями
  • Проблемы в коммуникации и ожиданиях
  • Ошибки при подготовке к проекту
  • Недостаточная компетенция исполнителя
  • Демотивация команды

Если вы научитесь их предсказывать — это 95% успеха. Остальные 5% — это внешние обстоятельства, на которые мы не всегда можем повлиять.

Напоследок оставим несколько полезных ссылок:

  • Наш канал в telegram.
  • Кейсы команды Alto

Последние публикации:

  • Инструменты для подготовки ТЗ + шаблон
  • Альтернатива курсам: программа обучения для project-менеджера
  • Как управлять проектом, когда не знаешь, что будет завтра
  • От формата киосков до сервиса по доставке блюд в кризисный год

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

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

Просчеты, связанные с персоналом

Ошибка № 1: Проекту не хватает ресурсов и квалифицированных исполнителей.

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

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

«Существует масса организационных моделей, — отметил Ричард Скэннелл, один из основателей компании GlassHouse Technologies, предоставляющей консультационные услуги, связанные с построением ИТ-инфраструктуры. — Но я никогда еще не видел, чтобы хорошо работало абсолютно все. На вопросы, касающиеся распределения ресурсов, к сожалению, не существует простого ответа».

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

Скэннелл предлагает формировать «команды тигров», члены которых освобождаются от своих традиционных обязанностей на год или больше ради участия в конкретном проекте. Кен Чени, директор центра HP Software’s PPM Center, рекомендует распределять ресурсы на уровне проекта, не опускаясь до конкретных задач, поскольку сделать это гораздо труднее.

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

Ошибка № 2: Нехватка опытных руководителей проектов.

Проявление: При отсутствии грамотного руководителя проекты могут быстро выйти из-под контроля.

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

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

Процедурные ошибки

Ошибка № 3: Управление проектами осуществляется при отсутствии стандартных, повторяющихся процедур.

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

Решение: Методология управления проектами помогает вам осуществлять их эффективную реализацию и находиться в курсе всех мероприятий, сопряженных с выполнением проекта. «Наличие базиса, включающего стандарты и методологии, позволит избежать многих рисков, связанных с претворением ИТ-проектов в жизнь», — отметил Чени.

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

Ошибка № 4: Слишком большое число процедур, ограничивающих ваши возможности.

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

Фуми Кондо, управляющий директор консультационной компании Intellilink Solutions, однажды была свидетелем интересного разговора между разработчиком программ и руководителем проекта. Разработчик заявлял, что функционал приложения можно расширить, не прилагая никаких дополнительных усилий. Руководитель проекта убеждал разработчика не добавлять никаких новых функций, потому что пользователи об этом не просили. «Тогда я посоветовала им следующее: ступайте к пользователям и посмотрите, действительно ли им нужны эти функции, — вспоминала Кондо. — Не вижу ничего плохого в том, чтобы предоставить клиентам больше того, что они ожидают, если при этом вы не выходите за рамки бюджета и установленных сроков».

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

Ошибка № 5: Изменения не соответствуют содержанию и границам проекта.

Проявление: Бюджет проекта устойчиво растет. То же самое происходит и со сроками.

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

Ошибка № 6: Отсутствие актуальной информации о состоянии проектов.

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

Решение: Программное обеспечение.

Ошибка № 7: Игнорирование возникающих проблем.

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

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

Планируемые недочеты

Ошибка № 8: Игнорирование необходимости определения содержания и границ проекта.

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

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

Ошибка № 9: Отсутствие понимания зависимостей, существующих между проектами.

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

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

Ошибка № 10: Игнорирование законов Мерфи.

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

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

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

Ошибка № 11: Дефицит времени, выделяемого на управление изменениями.

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

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

Ошибка № 12: Незавершенность графика проектов.

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

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

Проблемы взаимодействия

Ошибка № 13: Нереальные сроки проекта, которые ИТ-специалисты не в состоянии изменить.

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

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

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

Ошибка № 14: Недостатки взаимодействия со спонсорами проекта и заинтересованными в его реализации лицами.

Проявление: Предложенная техническая реализация не отвечает ожидаемым требованиям.

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

«Возможна также ситуация, при которой одна из сторон в процессе взаимодействия изъясняется на языке, совершенно непонятном другой стороне, — заметила Кондо. — В конце концов раздосадованные ИТ-специалисты восклицают: “Но ведь мы обо всем этом говорили. Почему же полученный результат не удовлетворяет конечного пользователя?”»

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

ИТ-служба должна прилагать больше усилий, разъясняя представителям бизнеса этапы реализации проекта.

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

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

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

Meridith Levinson. The 14 Most Common Project Management Mistakes. CIO.com. 07/23/2008

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

Ошибка №1: Вы выбрали не того project-менеджера

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

Решение: поручайте руководить проектом только того, кто действительно разбирается в предстоящих задачах.

Ошибка №2: В вашей команде отсутствует мотивация

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

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

Ошибка №3: Ваш проект никто не контролирует

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

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

Ошибка №4: Вы берете на себя сразу несколько проектов

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

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

Ошибка №5: В вашей команде не налажена коммуникация

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

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

Ошибка №6: У вас нет четкой конечной цели проекта или вы меняете ее в ходе работы

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

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

Ошибка №7: Вы неверно рассчитали время для реализации проекта

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

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

Ошибка №8: Вы не идете на уступки

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

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

Ошибка №9: Вы не систематично отслеживаете изменения в проекте

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

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

Ошибка №10: Вы руководите каждым шагом своих сотрудников

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

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

Ошибка №11: Вы нечетко распределили обязанности в команде

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

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

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

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

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

  • Авторы
  • Резюме
  • Файлы
  • Ключевые слова
  • Литература


Усова Ю.П.

1

Чинарева О.И.

1


1 ФГБОУ ВПО «Воронежская государственная лесотехническая академия»

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

квалификация управленческого персонала.

система вознаграждения

программное обеспечение

проблемы

управление проектами

1. Ветлужских Е. Система вознаграждения: Как разработать цели и KPI. – М. : Альпина Паблишер, 2013. — 217 с

2. Гаврилов Н.Н., Козлов А.С., Матвеев А.А., Богатов А.А. «Естественный отбор» руководителя проектом. — URL: http://www.pmsoft.ru/knowledgebase/articles/detail.php?ID=1500

3. Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. – М. : Альпина Бизнес Букс, 2007. – 418 с.

4. Пятенко С.В. Методы анализа наиболее типичных проблем управления проектом / Элитариум: Центр дистанционного образования. — URL: www.elitarium.ru

5. A guide to the project management body of knowledge. PMBOK guide. 5th edition. – Project Management Institute, 2013. – 616 с.

Введение

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

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

Рис. 1. Проблемы и их решения в управлении проектами.

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

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

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

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

Даже применение ПО от лидеров сегмента — MS Project, Primavera, не страхует от возможных проблем, ведь это всего лишь инструменты, эффективно работающие в руках профессионала, а не искусственный интеллект, решающий все ваши проблемы [2].

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

Следующим способом решения выше обозначенных проблем является активное использование системы вознаграждения. Чаще всего в российских компаниях используется стандартная система вознаграждения: в небольших по длительности проектах (например, до шести месяцев) сотрудники поощряются за выполнение проекта в срок, а при более долгосрочных проектах – за завершение каждого этапа и всего проекта в срок. Причем за выполнение первого этапа проекта размер вознаграждения обычно меньше, чем за завершение всего проекта. Например, если проект состоит из трех этапов, а общее вознаграждение составляет 100%, то за завершение первого этапа выплачивается 20% от общей суммы вознаграждения, 30% – за второй и этап и за завершение всего проекта – остальные 50%.

При этом используются два варианта взаимосвязи с вознаграждением:

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

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

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

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

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

Свое негативное влияние оказывает и так называемый студенческий синдром: большинство людей склонны откладывать выполнение задания до последнего. Исследования показали, что менее трети задания обычно выполняется в первые две трети срока, отведенного на него, и две трети – за последнюю треть срока. Кроме того, сотрудников постоянно отвлекают на выполнение новых заданий, а многозадачность, как известно, ведет к увеличению длительности выполнения проекта. Чтобы быть хорошим в глазах руководителя, сотрудник просто обязан брать и выполнять новые задания, в результате – он перегружен, что часто приводит к стрессу и в конечном итоге еще к большему увеличению длительности проекта. Поэтому проекты редко выполняются досрочно. Если бы некоторые этапы проекта завершались сотрудниками досрочно, то возникающий запас времени мог бы использоваться на непредвиденные обстоятельства, которые всегда могут возникнуть на завершающих этапах проекта [1].

А так получается, что существует постоянный конфликт между целями компании: удовлетворением требований клиента и руководства, достижением большего результата за минимальные сроки и деньги и личными целями каждого члена команды — личной успешностью (а для этого нужно закладывать запас времени, не сдавать работу досрочно, укладываться в бюджет, но ни в коем случае не экономить, брать новые задания, чтобы быть хорошим в глазах руководителя и т.д.). Формируется определенный стереотип поведения, выгодный сотруднику. Получается, что вроде все работают хорошо с точки зрения индивидуального результата, но нужных результатов для бизнеса нет [3].

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

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

Для иллюстрации такой ситуации введем качественные показатели «требования проекта» и «квалификация руководителя проекта». Под понятием «требования проекта» будем понимать совокупный уровень знаний и навыков, необходимых для успешной реализации проекта. Под понятием «квалификация руководителя проекта» будем понимать совокупный уровень знаний и навыков, которыми обладает руководитель проекта на определенный момент времени. Требования проекта и квалификация руководителя проекта – это динамичные характеристики [2].

Графическая иллюстрация понятий «требования проекта» и «квалификация руководителя проекта» приведена на рисунке 2.

Рис. 2. Качественные соотношения динамики требований проекта и квалификации руководителя проекта.

Введем предположение, что по мере выполнения проекта его требования сначала возрастают за счет постоянного уточнения и детализации требований к продукту, услуге, цели проекта. Затем, достигнув максимального уровня, состав и уровень требований стабилизируются и некоторое время могут оставаться неизменными, определяясь требованиями к качеству проекта. Далее, при завершении проекта, его требования естественным образом снижаются (в принципе, до нулевого уровня к завершению проекта). Вместе с тем с развитием технологий требования каждого следующего проекта больше, чем у предыдущих подобных ему проектов в той же прикладной области. Введенное предположение верно не для всех проектов — требования к проекту могут уменьшаться или оставаться постоянной величиной [2; 3].

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

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

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

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

  • неосведомленность о проблеме;
  • неверный «диагноз»;
  • решение не «продано» топ-менеджменту;
  • принятие решений без запланированных действий;
  • действия при отсутствии рамок решения;
  • неспособность действовать тогда, когда нужно;
  • действия, не соответствующие принятым решениям [4].

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

Рецензенты:

Демченко А.Ф., д.э.н., профессор кафедры экономики, финансов и менеджмента Воронежского филиала Российской академии народного хозяйства и государственной службы при Президенте Российской Федерации, г. Воронеж.

Трещевский Ю.И., д.э.н., профессор, заведующий кафедрой экономики и управления организациями Воронежского государственного университета, г. Воронеж.


Библиографическая ссылка

Усова Ю.П., Чинарева О.И. ПРОБЛЕМЫ В УПРАВЛЕНИИ ПРОЕКТАМИ И СПОСОБЫ ИХ РЕШЕНИЯ // Современные проблемы науки и образования. – 2013. – № 6.
;

URL: https://science-education.ru/ru/article/view?id=11844 (дата обращения: 29.01.2023).


Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

(Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления)

From Wikipedia, the free encyclopedia

Error management theory (EMT) is an extensive theory of perception and cognition biases created by David Buss and Martie Haselton. How humans think and make decisions using heuristics and biases may be embedded in the human brain. Error management training is a related area that uses this theory. The objective of it is to encourage trainees to make errors and encourage them in reflection to understand the causes of those errors and to identify suitable strategies to avoid making them in future.[1]

Ebbinghaus–Titchener circles

An example of error management theory is the Ebbinghaus–Titchener circles that can illustrate, a person’s view of which of the (orange) centre circles is bigger is subjective, and can cause a misinterpretation of reality. That is to say, both circles are the same size but each person may interpret the information presented differently depending on which bias they rely on to make the decision.

Various biases in thinking and decision-making have been highlighted by Daniel Kahneman and have been shown to cause cognitive errors in psychological and economic decisions. Cognitive biases in error management theory refer to biases and heuristics that have survived evolutionary history, because they hold some benefits towards reproductive success. Based on Darwinian principles those that «out mate» others have a greater chance of successfully producing offspring. According to this theory, when there are differences in costs of errors made under conditions of uncertainty, selection favours «adaptive biases». Humans are animals, and evolution charts their passage from single celled organisms to the media and technology-consuming organisms of today. These adaption biases ensure that less costly survival or reproductive errors will be committed.

Error management theory asserts that evolved mind-reading agencies will be biased to produce more of one type of inferential error than another.[2] These mind-reading biases have been further researched in terms of the mating world. Error management theory provides a clear explanation for the discovery that men have a tendency to perceive women as having greater sexual interest in them than is present, if they smile or touch them, and females have a tendency to underplay a man’s interest in them, even if it is quite strong. This is based on commitment scepticism. The theory has been much replicated,[failed verification] but the authors are still[when?] testing and refining it.[3] Newer research indicates exceptions as well as gender differences may be significant to the effect, such as postmenopausal effects, the possible projection of sexual and commitment self-interest,[4] and other differences including unrestricted sociosexuality.[5]

Type errors[edit]

In the decision-making process, when faced with uncertainty, a subject can make two possible errors: type I or type II.

A type I error is a false positive, thinking that an effect is there, when it is not. For example, acting on a fire alarm that turns out to be false. When someone infers sexual interest, where there is none, then a false-positive error has occurred.

A type II error is a false negative, not seeing an effect where one exists. Ignoring the fire alarm that turns out to be accurate, due to scepticism, illustrates this point. Falsely inferring a lack of intent about sexual interest means a false negative error has occurred.

Sexual overperception bias[edit]

Males[edit]

One of the aims of error management theory is to explain sexual overperception bias.[6] Sexual overperception occurs when a type I error is committed by an individual. An individual committing this type error falsely concludes that someone else has a sexual interest in them.[6] Research has shown that males are more likely than females to commit sexual overperception bias – men tend to overestimate women’s sexual interest while women tend to underestimate men’s.[6] This is theorised to be likely due to the fact that the reproductive costs of sexual underperception are greater for men than the risk of making false positives.[6] Men who perceive themselves as especially high in mate value are especially prone to experiencing this phenomenon. In addition, men who are also more inclined to pursue a short term mating strategy exhibit a more prominent case of sexual overperception bias.[7]: 334 

Manipulation[edit]

Differences in perceptions of sexual interest between men and women may be exploited by both genders. Men may present themselves as more emotionally invested in a woman than they actually are in order to gain sexual access to her; 71% of men report engaging in this form of manipulation and 97% of women report having experienced this form of manipulation.[7] Women may present themselves as more sexually interested in a man than they actually are in order to fulfill other needs and wants.[7] The manipulations create conflicts between men and women as to the status of their relationships. Women on the receiving end of emotional manipulation may complain that the relationship is moving too quickly while men on the receiving end of sexual manipulation may complain about «being led on».[7]

Exceptions[edit]

The sister effect[edit]

The sister effect is an exception to male overperception bias. Haselton and Buss (2000) found that sexual overperception bias would not occur when the target the men had to perceive sexual intent from was their sister.[8] They found that the men’s perception of their sister’s sexual intent was lower than their perception of sexual intent from other females. Haselton and Buss (2000) believed that this perception of female sexual interest was most accurate as it fell between women’s perception of women (high interest) and women’s perception of their own sexual interest (low interest).[8] This could be a product of incest-avoidance mechanisms.[7]

Sexual and commitment self-interest[edit]

Sexual underperception in males is also observed, in cases where men report low levels of their own sexual interest.[6] A person’s own level of attraction, rather than their gender, may lead to over or under-perception.[4] The exact mechanism for this is unclear but it is suggested that individuals may project their own level of sexual and commitment interestedness on to their interaction partner, whether they are in a relationship with them or they were strangers before the interaction.[4]

«The Fox and the Grapes»[edit]

The Aesopian fable of The Fox and the Grapes gives another possible explanation as to why males fall victims of underperception. The fable concerns a fox that attempts to eat grapes, but fails to do so, as they are too high. The fox, being too proud to admit defeat, claims that the grapes are «sour» and thus inedible.[4] In a similar fashion, males that expect a female to be uninterested may report less sexual interest, as an attempt at saving face.

Male insensitivity bias[edit]

A different explanation for the presence of both overperception and underperception in men is the male insensitivity bias. Evidence has shown that males lack perceptual sensitivity, so they are more likely to misperceive friendliness as sexual interest, but also more likely to misperceive sexual interest as friendliness, in comparison to females,[9] something that explains the presence of both biases in males.

Sexual underperception bias[edit]

Females[edit]

Women also fall victim to misconceptions during male-female interactions. Haselton and Buss (2000) advocate that these errors primarily stem from women’s perceived desire for a committed relationship by a male counterpart.[7] Women have evolved strategies to protect themselves from deception.[10] One of these evolved strategies is to commit the Skeptical Commitment Bias.

Skeptical commitment bias[edit]

Women’s commitment skepticism arises from the high costs of falsely inferring a mate’s commitment to a relationship. It hypothesizes that women have adapted to be cognitively biased towards under perceiving male interest and commitment. This is due to the high cost of a false positive – a man not being committed and a woman accepting him – that could lead to raising a child without an investing mate, reputational damage and risk reducing chances of future courtship. The cost of a false negative – a man that is committed and a woman rejecting him – is far less costly to the female.
Women are limited to how many children they can have in a lifetime. However, men are not limited and can reproduce multiple times. Therefore, overperception costs are higher for females.[11] This hypothesis is mentioned briefly by Buss (2012).[7]

Females’ commitment skepticism is unique to humans. For other mammals, courtship rituals are not particularly varied and there is no guesswork or ambiguity involved. For instance, a long-tailed manakin bird has a mating dance that is instinctive and intricate and requires a young apprentice to perform as a duet to the female. If the dance is good enough the female will mate with the male, if the duet falls flat then she will not choose him to reproduce with. However, human courtship behaviour is more ambiguous and so requires these types of cognitive biases to avoid costly errors, in this case, sexual deception.[6]

Exceptions[edit]

«Skeptical dad» and «Encouraging mum» hypothesis[edit]

Previously, commitment skepticism and overperception biases were thought of as sex specific. Women would underplay or fail to infer a psychological state that is there in order to prevent a false negative error. Men would over perceive female interest because the reproductive costs of sexual under perception are greater for men than women. Al-Shawaf (2016) stated that this is not what the core logic of the Error Management Theory (EMT) suggests. EMT states that the ancestral cost-benefit matrix of both false positive and false negative errors is what drives the cognitive biases and decision-making processes, not gender which is what it has been defined by.[12]

Imagine a woman is assessing her potential mate’s commitment intent. The woman’s father also has a vested interest in whether she reproduces because he shares genes with her and thus, his reproductive interests extend to his daughter’s mate choice. The father also has to evaluate the costs and benefits of the two types of errors she could make when evaluating her mate’s commitment intent. If the chosen mate sexually deceives and then leaves her then the outcome is more costly for him than if his daughter is more cautious and underestimates intent. Thus, the father might take time before offering his parental seal of approval. The father shows the same skeptical commitment bias as his daughter, favouring the false negative error because it is less costly.

Taking the parental dynamic and switching it from father to mother, the same could be said for sexual overperception bias. A mother has an interest in who her son decides to mate with and therefore will favour the false positive error over false negative. If she fails to detect real interest in the woman, and thus, fails to share this female interest with her son, then it is more costly to her than if she falsely detects sexual interest from a woman towards her son and encourages him to pursue. If her son misses an opportunity, he has missed the chance to pass on his, and in doing so her own, genes. Therefore, the mother shows the same overperception bias as her son, favouring the false positive error because it is less costly.

It is not sex or gender that predicts what type of cognitive bias might be expressed but rather the potential costs to reproductive success.

Postmenopausal females[edit]

Contrasting the evidence for fertile females, skeptical commitment bias does not occur in postmenopausal women. Haselton and Buss (2000)[8] found evidence for the perception biases studying young subjects; however, this was not representative of older females, who have passed through menopause. The reason for this disparity between pre- and postmenopausal females is that fertile females underestimate the intentions of males to invest in the relationship, in order to avoid the costs of pregnancy without support; however, postmenopausal women do not perceive such costs. Their inability to conceive means that there is no reason to underestimate a male’s intentions.

Alternative explanations[edit]

Some recent studies researching error management theory have found men and women’s perceptions of opposite gender sexual and commitment interest may be mitigated by other explanations.[5]

Culture[edit]

With a universal proclivity, it would be possible to document the bias across cultures and «across different demographic groups, including among men varying in age, ethnicity, and education level» within cultures[13] and in females based on their job status, health, levels of education and income equality.[5] When investigated in Norway, one of the world’s most gender egalitarian societies,[5] error management theory and its evolutionary explanation were supported. In addition, the pattern of misperception of men and women held up across demographic groups differing in relationship status (singles versus partnered participants).[5]

Individual differences[edit]

Sexual over-perception relative to under-perception was reported more frequently among younger participants, among singles, and among participants with an unrestricted socio-sexual orientation.[5] Endorsing and being more open to casual sex may have evoked more sexual interest from members of the opposite sex, leading to more frequent reports of sexual overperception.[4] Socially unrestricted male and female high school students were found to report being more subject to sexual harassment as well as sexually harassing others.[5] From this, it is possible that being subject to sexual over-perception may explain the link between socio-sexuality and being subject to sexual harassment.[5]

Projection[edit]

As stated above what was reported about male sexual and commitment self-interest was also true of women. They self-reported levels of sexual interest and desire for commitment which also predicted their perceptions of their partners’ sexual interest and desire for commitment.[14] This implies that instead of males and females falling victims of overperception and underperception respectively, both sexes project their own level of interest onto the individuals they are interacting with.[15]

Reciprocity[edit]

Another explanation that removes overperception and underperception from the picture is how males and females reciprocate the perceived interest in one another. Evidence from speed dating shows that a partner’s level of attraction for an individual, influences the individual’s own interest in that particular partner.[4] Unlike the «fox and the grapes» approach, which explains how underperception occurs in men as a means of face-saving, reciprocity reflects a real shift in the level of interest in a partner as a result of returning the perceived interest.

Other examples[edit]

Similar examples can also be seen in the judgment of whether a noise in the wild was a predator when it was more likely the wind—humans who assumed it was a predator were less likely to be attacked as prey over time than those who were skeptical. This is similar to the animistic fallacy.[clarification needed]

Smoke detectors are designed with this theory in mind. Since the cost of a Type I error (false positive, e.g. a nuisance alarm) is much lower than the cost of a Type II error (false negative, e.g. an undetected fire that could burn a house down), the sensitivity threshold of a smoke detector is designed to error on the side of Type I errors. This explains why nuisance alarms are relatively common.[16]

See also[edit]

  • Reinforcement learning

Notes[edit]

  1. ^ Keith, Nina; Frese, Michael (2008). «Effectiveness of error management training: a meta-analysis». The Journal of Applied Psychology. 93 (1): 59–69. doi:10.1037/0021-9010.93.1.59. ISSN 0021-9010. PMID 18211135. S2CID 18058247.
  2. ^ Buss (2012). Evolutionary Psychology: The New Science of the Mind. Boston: Allyn & Bacon. p. 333. ISBN 978-0-205-01562-7.
  3. ^ Haselton, Martie. «Error Management Theory: Overview and Significance». UCLA. Archived from the original on 2006-09-08.
  4. ^ a b c d e f Luo, S; Zhang, G (2009). «What leads to romantic attraction: Similarity, reciprocity, security, or beauty? Evidence from a speed dating study». Journal of Personality. 77 (4): 933–963. doi:10.1111/j.1467-6494.2009.00570.x. PMID 19558447.
  5. ^ a b c d e f g h Bendixen, M (2014). «Evidence of Systematic Bias in Sexual Over- and Underperception of Naturally Occurring Events: A direct Replication of Haselton (2003) in a more Gender-Equal Culture». Evolutionary Psychology. 12 (5): 1004–21. doi:10.1177/147470491401200510. PMID 25402231.
  6. ^ a b c d e f Henningsen, David D; Henningsen, Mary Lynn Miller (October 2010). «Testing Error Management Theory: Exploring the Commitment Skepticism Bias and the Sexual Overperception Bias». Human Communication Research. 36 (4): 618–634. doi:10.1111/j.1468-2958.2010.01391.x.
  7. ^ a b c d e f g Buss, David (2012). Evolutionary Psychology: The New Science of the Mind. Boston: Allyn & Bacon. ISBN 978-0-205-01562-7.
  8. ^ a b c Haselton, Martie G.; Buss, David M. (2000). «Error management theory: A new perspective on biases in cross-sex mind reading» (PDF). Journal of Personality and Social Psychology. 78 (1): 81–91. doi:10.1037/0022-3514.78.1.81. PMID 10653507. Archived from the original on 2012-03-24.{{cite journal}}: CS1 maint: bot: original URL status unknown (link)
  9. ^ Farris, C.; Treat, T. A.; Viken, R. J.; McFall, R. M. (2008). «Perceptual mechanisms that characterize gender differences in decoding women’s sexual intent». Psychol Sci. 19 (4): 348–54. doi:10.1111/j.1467-9280.2008.02092.x. PMC 2890253. PMID 18399887.
  10. ^ Abbey, Antonia (1982). «Sex Differences in attribution for friendly behaviour: Do males misperceive females’ friendliness?». Journal of Personality and Social Psychology. 42 (5): 830–835. doi:10.1037/0022-3514.42.5.830.
  11. ^ Ehrlichman, Howard; Eichenstein, Rosalind (1992). «Private wishes: Gender similarities and differences». Sex Roles. 26 (9–10): 399–422. doi:10.1007/bf00291551. S2CID 144522125. ProQuest 618242868.
  12. ^ Al-Shawaf, Laith (4 May 2016). «Could there be a male commitment skepticism bias and a female sexual overperception bias? Novel hypotheses based on error management theory». Evolutionary Psychological Science. 2 (3): 237–240. doi:10.1007/s40806-016-0052-x.
  13. ^ Haselton, M. (2003). «The sexual overperception bias: Evidence of a systematic bias in men from a survey of naturally occurring events». Journal of Research in Personality. 37: 34–47. doi:10.1016/s0092-6566(02)00529-9.
  14. ^ Koenig, B. L.; Kirkpatrick, L. A.; Ketelaar, T. (2010). «Misperception of sexual and romantic interests in opposite-sex friendships: Four hypotheses». Personal Relationships. 14 (3): 411–429. doi:10.1111/j.1475-6811.2007.00163.x.
  15. ^ Shotland, R. L.; Craig, J. M. (1988). «Can men and women differentiate friendly and sexually interested behaviour?». Social Psychology Quarterly. 51 (1): 66–73. doi:10.2307/2786985. JSTOR 2786985.
  16. ^ Gonick, Larry; Smith, Woollcott (1 Jan 1993). The Cartoon Guide to Statistics. ISBN 0062731025.

Further reading[edit]

  • Darwin, Charles (1871). The descent of man, and selection in relation to sex (2nd ed.). John Murray. ISBN 978-0-8014-2085-6.
  • McKay, R.; Efferson, C. (2010). «The subtleties of error management» (PDF). Evolution & Human Behavior. 31 (5): 309–319. doi:10.1016/j.evolhumbehav.2010.04.005. S2CID 29138729. Archived from the original on 2016-06-11.{{cite journal}}: CS1 maint: bot: original URL status unknown (link)
  • Johnson, D. D. P.; Blumstein, D. T.; Fowler, J. H.; Haselton, M. G. (2013). «The evolution of error: error management, cognitive constraints, and adaptive decision-making biases». Trends in Ecology & Evolution. 28 (8): 474–481. doi:10.1016/j.tree.2013.05.014. PMID 23787087.

Теория управления ошибками (ЕМТ) — это обширная теория искажений восприятия и познания, созданная Дэвид Басс и Марти Хэзелтон. Как люди думают и принимают решения, используя эвристика и предубеждения могут быть встроены в человеческий мозг. Обучение управлению ошибками — это смежная область, в которой используется эта теория. Его цель — побудить обучаемых совершать ошибки и побудить их к размышлению, чтобы понять причины этих ошибок и определить подходящие стратегии, чтобы избежать их в будущем.[1]

Круги Эббингауза – Титченера

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

Различные предубеждения в мышлении и принятии решений были отмечены Даниэль Канеман и было показано, что они вызывают когнитивные ошибки при принятии психологических и экономических решений. Когнитивные предубеждения в теории управления ошибками относятся к предубеждениям и эвристикам, которые пережили эволюционную историю, потому что они имеют некоторые преимущества для репродуктивный успех. На основе Дарвиновский те принципы, которые «опережают» других, имеют больше шансов на успешное потомство. Согласно этой теории, когда существуют различия в стоимости ошибок, допущенных в условиях неопределенности, отбор благоприятствует «адаптивным ошибкам». Люди — животные, и эволюция показывает их переход от одноклеточных организмов к современным организмам, потребляющим средства массовой информации и технологии. Эти ошибки адаптации гарантируют, что будут совершены менее дорогостоящие ошибки выживания или репродукции.

Теория управления ошибками утверждает, что развитые агентства, читающие мысли, будут склонны производить больше ошибок вывода одного типа, чем другого.[2] Эти предубеждения в отношении чтения мыслей были дополнительно исследованы с точки зрения брачного мира. Теория управления ошибками дает четкое объяснение открытию того факта, что мужчины склонны воспринимать женщин как имеющих к себе больший сексуальный интерес, чем есть, если они улыбаются или прикасаются к ним, а женщины имеют тенденцию преуменьшать интерес мужчины к ним, даже если он достаточно сильный. Это основано на скептицизме обязательств. Теория была многократно воспроизведена,[неудачная проверка ] но авторы все еще[когда? ] тестирование и уточнение.[3] Более новые исследования показывают, что исключения, а также гендерные различия могут иметь большое значение, например, постменопаузальные эффекты, возможная проекция сексуальных и преданных личных интересов,[4] и другие отличия, в том числе неограниченные социосексуальность.[5]

Ошибки типа

В процессе принятия решения, столкнувшись с неопределенностью, субъект может сделать две возможные ошибки: тип I или тип II.

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

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

Смещение сексуального чрезмерного восприятия

Самцы

Одна из целей теории управления ошибками — объяснить предвзятость сексуального чрезмерного восприятия.[6] Сексуальное чрезмерное восприятие возникает, когда человек совершает ошибку I типа. Согласно этой типовой ошибке, человек ошибочно приходит к выводу, что представитель противоположного пола проявляет к нему сексуальный интерес.[6] Как показывают предыдущие исследования, мужчины чаще, чем женщины, склонны к чрезмерному сексуальному восприятию.[6] Результаты показали, что мужчины переоценивают сексуальный интерес женщин, в то время как женщины склонны недооценивать интерес мужчин.[6] Вероятно, это связано с тем, что репродуктивные издержки недостаточного сексуального восприятия для мужчин выше, чем риск получения ложноположительных результатов.[6] Мужчины, которые считают себя особенно ценными в партнере, особенно подвержены этому феномену. Кроме того, мужчины, которые также более склонны к краткосрочной стратегии спаривания, демонстрируют более явный случай предвзятости сексуального чрезмерного восприятия.[7]:334

Манипуляции

Различия в восприятии сексуального интереса между мужчинами и женщинами могут использоваться представителями обоих полов. Мужчины могут представить себя более эмоционально вложенными в женщину, чем они есть на самом деле, чтобы получить к ней сексуальный доступ; 71% мужчин сообщают, что прибегали к этой форме манипуляции [7] и 97% женщин сообщают, что испытали эту форму манипуляции.[7] Женщины могут представить себя более сексуально заинтересованными в мужчине, чем они есть на самом деле, чтобы удовлетворить другие потребности и желания.[7] Манипуляции создают конфликты между мужчинами и женщинами относительно статуса их отношений. Женщины, подвергшиеся эмоциональным манипуляциям, могут жаловаться на то, что отношения развиваются слишком быстро. [7]в то время как мужчины, подвергающиеся сексуальным манипуляциям, могут жаловаться на то, что «их ведут» [7]

Исключения

Сестринский эффект

Сестринский эффект — исключение из предвзятости мужского чрезмерного восприятия. Haselton и Buss (2000) обнаружили, что смещение чрезмерного сексуального восприятия не возникает, если целью, от которой мужчины должны были воспринимать сексуальные намерения, была их сестра.[8] Они обнаружили, что восприятие мужчинами сексуального намерения своей сестры было ниже, чем их восприятие сексуального намерения от других женщин. Haselton и Buss (2000) полагали, что это восприятие женского сексуального интереса было наиболее точным, поскольку оно находилось между восприятием женщинами женщин (высокий интерес) и восприятием женщинами своего собственного сексуального интереса (низкий интерес).[8] Это могло быть результатом механизмов предотвращения инцеста.[7]

Сексуальные интересы и приверженность личным интересам

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

«Лиса и виноград»

В Эзопов басня о Лиса и виноград дает другое возможное объяснение того, почему мужчины становятся жертвами недостаточного восприятия. Басня повествует о лисе, которая пытается съесть виноград, но не может этого сделать, так как они слишком высоки. Лисица, слишком гордая, чтобы признать поражение, утверждает, что виноград «кислый» и потому несъедобный.[4] Аналогичным образом, мужчины, которые ожидают, что женщина будет незаинтересованной, могут сообщить о меньшем сексуальном интересе, как о попытке спасая лицо.

Предвзятое отношение к мужской нечувствительности

Другим объяснением наличия как чрезмерного, так и недостаточного восприятия у мужчин является предвзятость мужской нечувствительности. Факты показали, что мужчинам не хватает чувствительности к восприятию, поэтому они с большей вероятностью ошибочно воспринимают дружелюбие как сексуальный интерес, но также более склонны ошибочно воспринимать сексуальный интерес как дружелюбие по сравнению с женщинами.[9] то, что объясняет наличие обоих предубеждений у мужчин.

Предвзятое сексуальное восприятие

Самки

Женщины также становятся жертвами неправильных представлений во время взаимоотношений между мужчинами и женщинами. Haselton и Buss (2000) утверждают, что эти ошибки в первую очередь проистекают из предполагаемого стремления женщин к преданным отношениям со стороны партнера-мужчины.[7] Женщины разработали стратегии защиты от обмана.[10] Одна из этих эволюционирующих стратегий — совершить предвзятое отношение к скептическим обязательствам.

Скептическая предвзятость

Скептицизм женщин в отношении приверженности возникает из-за высокой цены ложного вывода о приверженности партнера отношениям. Предполагается, что женщины приспособились к когнитивной предвзятости в отношении недопонимания мужских интересов и обязательств. Это связано с высокой ценой ложного срабатывания — мужчина не принимает на себя обязательств, а женщина принимает его — что может привести к воспитанию ребенка без помощника-инвестора, репутационному ущербу и риску, уменьшающему шансы на будущие ухаживания. Цена ложноотрицательного результата — когда мужчина предан, а женщина его отвергает — для женщины обходится гораздо дешевле. Женщины ограничены тем, сколько детей они могут иметь за всю жизнь, однако мужчины не ограничены и могут воспроизводить несколько раз, поэтому для женщин издержки чрезмерного восприятия выше.[11] Эта гипотеза кратко упоминается Бассом (2012).[7]

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

Исключения

Гипотеза «скептически настроенный папа» и «обнадеживающая мама»

Раньше скептицизм к приверженности и предвзятость чрезмерного восприятия рассматривались как специфические для пола. Женщины недооценивают или не могут вывести психологическое состояние, которое существует, чтобы предотвратить ложноотрицательную ошибку. Мужчины будут чрезмерно воспринимать женский интерес, потому что репродуктивные издержки недостаточного сексуального восприятия для мужчин выше, чем для женщин. Аль-Шаваф (2016) заявил, что это не то, что предполагает основная логика теории управления ошибками (EMT). ЕМТ заявляет, что изначальная матрица затрат и выгод как ложноположительных, так и ложноотрицательных ошибок — это то, что движет когнитивными предубеждениями и процессами принятия решений, а не пол, которым он был определен.[12]

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

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

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

Женщины в постменопаузе

В отличие от данных о фертильных самках, предвзятость в отношении скептической приверженности не наблюдается в постменопаузальный женщины. Хэзелтон и Басс (2000)[8] обнаружили доказательства предвзятости восприятия при изучении молодых людей; однако это не было типичным представителем пожилых женщин, которые прошли через менопауза. Причина этого несоответствия между женщинами в пре- и постменопаузе состоит в том, что фертильные женщины недооценивают намерения мужчин вкладывать средства в отношения, чтобы избежать издержек беременности без поддержки; однако женщины в постменопаузе не осознают таких затрат. Их неспособность к зачатию означает, что нет причин недооценивать намерения мужчины.

Альтернативные объяснения

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

Культура

С универсальной склонностью можно было бы задокументировать предвзятость между культурами и «среди разных демографических групп, в том числе среди мужчин разного возраста, этнической принадлежности и уровня образования» внутри культур.[13] а у женщин — в зависимости от статуса работы, состояния здоровья, уровня образования и равенства доходов.[5] При исследовании в Норвегии, одном из самых гендерно-эгалитарных обществ в мире,[5] были поддержаны теория управления ошибками и ее эволюционное объяснение. Кроме того, неправильное восприятие мужчин и женщин сохранялось среди демографических групп, различающихся статусом отношений (одинокие или партнерские участники).[5]

Индивидуальные различия

О чрезмерном сексуальном восприятии по сравнению с недостаточным восприятием чаще сообщалось среди более молодых участников, среди одиноких и среди участников с неограниченной социально-сексуальной ориентацией.[5] Поддержка случайного секса и более высокая степень открытости для него могли вызвать больший сексуальный интерес у представителей противоположного пола, что привело к более частым сообщениям о сексуальном чрезмерном восприятии.[4] Было обнаружено, что социально незащищенные учащиеся средних школ мужского и женского пола чаще подвергаются сексуальным домогательствам, а также сексуальным домогательствам других.[5] Исходя из этого, возможно, что чрезмерное сексуальное восприятие может объяснить связь между социосексуальностью и подверженностью сексуальное домогательство.[5]

Проекция

Как указывалось выше, то, что сообщалось о мужских сексуальных и обязательных личных интересах, было справедливо и для женщин. Они сами сообщили об уровнях сексуального интереса и стремления к обязательствам, которые также предсказали их восприятие сексуального интереса и желания партнеров.[14] Это означает, что вместо мужчин и женщин, которые становятся жертвами чрезмерного и недостаточного восприятия, соответственно, оба пола проецируют свой уровень интереса на людей, с которыми они взаимодействуют.[15]

Взаимность

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

Другие примеры

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

Примечания

  1. ^ Кейт, Нина; Фрезе, Майкл (2008). «Эффективность обучения управлению ошибками: метаанализ». Журнал прикладной психологии. 93 (1): 59–69. Дои:10.1037/0021-9010.93.1.59. ISSN  0021-9010. PMID  18211135.
  2. ^ Басс (2012). Эволюционная психология: новая наука о разуме. Бостон: Аллин и Бэкон. п. 333. ISBN  978-0-205-01562-7.
  3. ^ Хазелтон, Марти. «Теория управления ошибками: обзор и значение». UCLA. Архивировано из оригинал на 2006-09-08.
  4. ^ а б c d е ж Луо, S; Чжан, Г. (2009). «Что приводит к романтическому влечению: сходство, взаимность, безопасность или красота? Данные исследования быстрых свиданий». Журнал личности. 77 (4): 933–963. Дои:10.1111 / j.1467-6494.2009.00570.x. PMID  19558447.
  5. ^ а б c d е ж грамм час Бендиксен, М. (2014). «Доказательства систематической предвзятости в сексуальном чрезмерном и недостаточном восприятии естественных событий: прямая репликация Хазелтона (2003) в культуре более гендерного равенства». Эволюционная психология. 12 (5): 1004–21. Дои:10.1177/147470491401200510. PMID  25402231.
  6. ^ а б c d е ж грамм Хеннингсен, Дэвид Д; Хеннингсен, Мэри Линн Миллер (октябрь 2010 г.). «Проверка теории управления ошибками: исследование предвзятости скептицизма приверженности и предвзятости сексуального чрезмерного восприятия». Исследования человеческого общения. 36 (4): 618–634. Дои:10.1111 / j.1468-2958.2010.01391.x.
  7. ^ а б c d е ж грамм час я Бусс, Дэвид (2012). Эволюционная психология: новая наука о разуме. Бостон: Аллин и Бэкон. ISBN  978-0-205-01562-7.
  8. ^ а б c Haselton, Martie G .; Бусс, Дэвид М. (2000). «Теория управления ошибками: новый взгляд на предубеждения при чтении мыслей между мужчинами и женщинами» (PDF). Журнал личности и социальной психологии. 78 (1): 81–91. Дои:10.1037/0022-3514.78.1.81. PMID  10653507. Архивировано 24 марта 2012 года.CS1 maint: BOT: статус исходного URL-адреса неизвестен (связь)
  9. ^ Farris, C .; Лечить, Т. А .; Viken, R.J .; Макфолл, Р. М. (2008). «Механизмы восприятия, которые характеризуют гендерные различия в расшифровке сексуальных намерений женщин». Психологические науки. 19 (4): 348–54. Дои:10.1111 / j.1467-9280.2008.02092.x. ЧВК  2890253. PMID  18399887.
  10. ^ Аббатство, Антония (1982). «Половые различия в атрибуции дружелюбного поведения: мужчины неправильно воспринимают дружелюбие женщин?». Журнал личности и социальной психологии. 42 (5): 830–835. Дои:10.1037/0022-3514.42.5.830.
  11. ^ Эрлихман, Ховард; Эйхенштейн, Розалинда (1992). «Частные пожелания: гендерные сходства и различия». Секс Роли. 26 (9–10): 399–422. Дои:10.1007 / bf00291551. ProQuest  618242868.
  12. ^ Аль-Шаваф, Лайт (4 мая 2016 г.). «Может ли быть предубеждение скептицизма приверженности мужчин и предвзятость женского сексуального чрезмерного восприятия? Новые гипотезы, основанные на теории управления ошибками». Эволюционная психологическая наука. 2 (3): 237–240. Дои:10.1007 / s40806-016-0052-х.
  13. ^ Хазелтон, М. (2003). «Предвзятость сексуального чрезмерного восприятия: свидетельство систематической предвзятости у мужчин из обзора естественных событий». Журнал исследований личности. 37: 34–47. Дои:10.1016 / s0092-6566 (02) 00529-9.
  14. ^ Koenig, B.L .; Киркпатрик, Л. А .; Кетелаар, Т. (2010). «Неправильное восприятие сексуальных и романтических интересов в дружбе противоположного пола: четыре гипотезы». Личные отношения. 14 (3): 411–429. Дои:10.1111 / j.1475-6811.2007.00163.x.
  15. ^ Shotland, R.L .; Крейг, Дж. М. (1988). «Могут ли мужчины и женщины отличать дружелюбное поведение от сексуально заинтересованного?». Social Psychology Quarterly. 51 (1): 66–73. Дои:10.2307/2786985. JSTOR  2786985.

дальнейшее чтение

  • Дарвин, Чарльз (1871). Происхождение человека и отбор в отношении пола (2-е изд.). Джон Мюррей. ISBN  978-0-8014-2085-6.
  • McKay, R .; Эфферсон, К. (2010). «Тонкости управления ошибками» (PDF). Эволюция и поведение человека. 31 (5): 309–319. Дои:10.1016 / j.evolhumbehav.2010.04.005. Архивировано 11 июня 2016 года.CS1 maint: BOT: статус исходного URL-адреса неизвестен (связь)
  • Johnson, D. D. P .; Блюмштейн, Д. Т .; Fowler, J. H .; Хазелтон, М. Г. (2013). «Эволюция ошибок: управление ошибками, когнитивные ограничения и предубеждения при принятии адаптивных решений». Тенденции в экологии и эволюции. 28 (8): 474–481. Дои:10.1016 / j.tree.2013.05.014. PMID  23787087.

Логика управления проектами

  1. Управление
    проектами подчиняется четкой логике,
    которая связывает между собой различные
    области знаний и процессы управления
    проектами.

  2. У
    проекта обязательно имеются одна
    или несколько целей
    .

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

  4. В
    число основных критериев оценки
    различных вариантов исполнения проекта
    входят сроки
    и стоимость

    достижения результатов.

  5. Запланированные
    цели
    и качество

    служат основными ограничениями при
    рассмотрении и оценке различных
    вариантов.

  6. Для
    управления проектами необходимы рычаги.

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

Жизненный цикл проекта и фазы проекта

Начало
жизненного цикла проекта совпадает по
времени с началом проекта, а его окончание
– с завершением проекта.

Наиболее
традиционным является разбиение проекта
на
четыре крупных этапа:
разработка
концепции проекта(постановка), планирование
(разработка), реализация(исполнение) и
завершение(закрытие проекта) (рис. 1).

Рисунок
1 – Жизненный цикл проекта

1. Концепция проекта.

Разработка
концепции проекта, по существу
подразумевает функцию выбора проекта.

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

2. Разработка (Планирование).

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

Что
надо сделать?

Кто
сделает это?

Как
это будет сделано?

Когда
это должно быть сделано?

Сколько
это будет стоить?

Что
нам нужно чтобы сделать это?

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

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

3. Реализация (Осуществление).

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

На
правильном ли мы пути?

Если
нет, что нужно сделать?

Следует
ли изменить план?

4.
Завершение.

Рано
или поздно, но проекты заканчиваются.
Проект заканчивается, когда достигнуты
поставленные перед ним цели.

Что
сделано хорошо?

Что
следовало бы улучшить?

Что
мы узнали нового?

Процессы
управления проектами

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

Процессы
управления проектами могут быть разбиты
на шесть основных групп (рис. 2):

1.
процессы инициации;

2.
процессы планирования;

3.
процессы исполнения

4.
процессы анализа;

5.
процессы управления;

6.
процессы завершения.

 

Рисунок
2 – Процессы управления проектами

Процессы
инициации

Данный
процесс представляет собой принятие
решения о начале выполнения проекта.

Процессы
планирования

Процесс
определения целей и критериев успеха
проекта и разработка рабочих схем их
достижения

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

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

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

Процессы
планирования
представлены
на рисунке 3.

Рисунок
3 – Процессы планирования

Этапы
планирования

    1. Разработка
      формулировки миссии, целей и задач
      проекта.

Формулировка
миссии

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

Заказчик
проекта

– главная сторона, заинтересованная в
осуществлении проекта и достижении его
результатов.

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

Формулировка
миссии должна отвечать на три вопроса:

Что
мы делаем?

Для
кого мы это делаем?

Как
мы делаем это?

Когда
формулировка миссии разработана, можно
определить цели проекта. Цели намного
более конкретны, чем миссия.

Цель

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

Два
важных вопроса при установлении целей:

Каков
желаемый результат?

Как
вы узнаете, когда достигли желаемого
результата?

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

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

Просчеты, связанные с персоналом

Ошибка № 1: Проекту не хватает ресурсов и квалифицированных исполнителей.

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

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

«Существует масса организационных моделей, — отметил Ричард Скэннелл, один из основателей компании GlassHouse Technologies, предоставляющей консультационные услуги, связанные с построением ИТ-инфраструктуры. — Но я никогда еще не видел, чтобы хорошо работало абсолютно все. На вопросы, касающиеся распределения ресурсов, к сожалению, не существует простого ответа».

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

Скэннелл предлагает формировать «команды тигров», члены которых освобождаются от своих традиционных обязанностей на год или больше ради участия в конкретном проекте. Кен Чени, директор центра HP Software’s PPM Center, рекомендует распределять ресурсы на уровне проекта, не опускаясь до конкретных задач, поскольку сделать это гораздо труднее.

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

Ошибка № 2: Нехватка опытных руководителей проектов.

Проявление: При отсутствии грамотного руководителя проекты могут быстро выйти из-под контроля.

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

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

Процедурные ошибки

Ошибка № 3: Управление проектами осуществляется при отсутствии стандартных, повторяющихся процедур.

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

Решение: Методология управления проектами помогает вам осуществлять их эффективную реализацию и находиться в курсе всех мероприятий, сопряженных с выполнением проекта. «Наличие базиса, включающего стандарты и методологии, позволит избежать многих рисков, связанных с претворением ИТ-проектов в жизнь», — отметил Чени.

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

Ошибка № 4: Слишком большое число процедур, ограничивающих ваши возможности.

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

Фуми Кондо, управляющий директор консультационной компании Intellilink Solutions, однажды была свидетелем интересного разговора между разработчиком программ и руководителем проекта. Разработчик заявлял, что функционал приложения можно расширить, не прилагая никаких дополнительных усилий. Руководитель проекта убеждал разработчика не добавлять никаких новых функций, потому что пользователи об этом не просили. «Тогда я посоветовала им следующее: ступайте к пользователям и посмотрите, действительно ли им нужны эти функции, — вспоминала Кондо. — Не вижу ничего плохого в том, чтобы предоставить клиентам больше того, что они ожидают, если при этом вы не выходите за рамки бюджета и установленных сроков».

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

Ошибка № 5: Изменения не соответствуют содержанию и границам проекта.

Проявление: Бюджет проекта устойчиво растет. То же самое происходит и со сроками.

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

Ошибка № 6: Отсутствие актуальной информации о состоянии проектов.

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

Решение: Программное обеспечение.

Ошибка № 7: Игнорирование возникающих проблем.

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

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

Планируемые недочеты

Ошибка № 8: Игнорирование необходимости определения содержания и границ проекта.

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

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

Ошибка № 9: Отсутствие понимания зависимостей, существующих между проектами.

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

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

Ошибка № 10: Игнорирование законов Мерфи.

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

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

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

Ошибка № 11: Дефицит времени, выделяемого на управление изменениями.

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

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

Ошибка № 12: Незавершенность графика проектов.

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

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

Проблемы взаимодействия

Ошибка № 13: Нереальные сроки проекта, которые ИТ-специалисты не в состоянии изменить.

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

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

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

Ошибка № 14: Недостатки взаимодействия со спонсорами проекта и заинтересованными в его реализации лицами.

Проявление: Предложенная техническая реализация не отвечает ожидаемым требованиям.

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

«Возможна также ситуация, при которой одна из сторон в процессе взаимодействия изъясняется на языке, совершенно непонятном другой стороне, — заметила Кондо. — В конце концов раздосадованные ИТ-специалисты восклицают: “Но ведь мы обо всем этом говорили. Почему же полученный результат не удовлетворяет конечного пользователя?”»

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

ИТ-служба должна прилагать больше усилий, разъясняя представителям бизнеса этапы реализации проекта.

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

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

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

Meridith Levinson. The 14 Most Common Project Management Mistakes. CIO.com. 07/23/2008

  • Логика правила доказательства ошибки доказательства
  • Логическая ошибка манга оригинал
  • Логи ошибок битрикс где смотреть
  • Логическая ошибка манга на русском языке
  • Логи ошибок windows server 2012