| Сегодня 30 августа, суббота |
      |
  
|
  
Какой рейтинг вас больше интересует?
|
Главная /
Каталог блоговCтраница блогера PMGuide | Гид проектного управления/Записи в блоге |
 |
PMGuide | Гид проектного управления
Голосов: 1 Адрес блога: http://www.pmguide.info/ Добавлен: 2011-11-02 00:28:35 |
Правило 13: Умейте распознавать и признавать свои и чужие ошибки, работайте над ошибками
2011-12-27 19:17:43 (читать в оригинале)
Установите такие отношения с участниками проекта, при которых они не побоятся сообщить вам об ошибке. Вовремя обнаруженная ошибка может сберечь от больших потерь в будущем.
Учитесь на своих ошибках, учитесь на чужих ошибках.
Все выше написанное ужасная банальность, не правда ли? Я, как и большинство, так часто эту банальность слышал, что она уже не способна как-то привлечь внимание, не говоря уже о том, чтобы зацепить. Сейчас разговор не об этом.Как не совершить ошибку? И как поступить, если Вы ошибку уже совершили?
Давайте пойдем с другой стороны. Какие ошибки бывают?
1) Тупые. Абсолютно тупые ошибки, которые тем не менее могут с нами случаться. Такие ошибки совершать обиднее всего, и признаваться в том, что вы сделали эту ошибку - самое обидное и болезненное.
2) Простые. Ошибки, которые можно было бы легко избежать, но последовательность ваших действий привела к неизбежности ошибки.
3) Сложные. Ошибки, которые понятны, но для предотвращения этих ошибок требуются определенные усилия и затраты.
4) Трудноразрешимые. Ошибки, имеющие сложные причины и не очевидные способы их предотвращения. Например, необходимость принять жесткое решение, которое может иметь далеко идущие последствия.
Извлечь уроки из первых двух категорий ошибок довольно легко. Как только вы распознаете такую ситуацию, вы должны быть в состоянии избегать подобных ошибок. Или поймете, что вне зависимости от вашего знания, вы раз за разом делаете одни и те же ошибки :)
Эти ошибки не интересны, работа над этими ошибками не сложная и извлеченные уроки, как правило, не глубоки.
Большинство людей такого рода ошибок не повторяет, а если вы ее повторяете раз за разом, это уже скорее не ошибка, а дурная привычка. И избавляться от таких ошибок надо как от дурных привычек.
Гораздо важнее стараться предотвращать другие категории ошибок.
Сложные ошибки требуют определенных затрат на планирование и прогнозирование развития ситуации. Здесь, как и в первом случае, самым важным является распознавание таких ошибок. Со временем вы научитесь их распознавать, наработаете набор "паттернов ошибок". Важно только не попасть в ловушку, отказываясь признавать истинный источник ошибки (истинную причину) или полную цепочку последовательности, приведшую к этой ошибке. Важно выявить тенденции развития проблемы, меры для предотвращения.
Трудноразрешимые проблемы требуют большего вашего участия, в такой ситуации неоценимой будет помощь наставника, некоторого внешнего эксперта, который владеет пониманием проблемы, способен направить в нужное русло.
Над ошибками надо работать. Помните, что многие простые и тупые ошибки прячут глубинные трудноразрешимые ошибки, которые носят системный характер. Избавляясь от системных ошибок вы уменьшаете саму возможность появления других ошибок.
Поэтому внимательнее относитесь к своим и чужим ошибкам, исключайте возможность, что ошибки пройдут мимо вас незамеченными.
Книги: Путь камикадзе
2011-12-24 10:34:56 (читать в оригинале)
Книга "Путь камикадзе" Эдварда Йордона - это попытка зафиксировать такие процессы, и надо сказать, попытка более, чем удачная. Читать обязательно.
Ниже перечислены некоторые best practices, рекомендуемые в книге для безнадежных проектов:
...
24) Бинарная оценка качества по результатам этапов – другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно, фиксируя достигнутые результаты с помощью «бинарных» признаков...
25) Свободный доступ к информации о проектных планах и фактических результатах – это согласуется с моими рекомендациями в предыдущих главах. Безнадёжный проект будет испытывать достаточно большие трудности, если менеджер будет скрывать от остальной команды информацию о состоянии проекта.
26) Фиксация дефектов в соответствии с заданными показателями качества – одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.
27) Конфигурационное управление – как бы оно не называлось (контроль версий, контроль исходных кодов, или как-нибудь ещё), конфигурационное управление обычно рассматривается как важная практическая составляющая проектов, протекающих в экстремальных условиях.
28) Ответственность и подотчётность руководства перед сотрудниками – увы, но в большинстве безнадёжных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадёжные проекты относятся к типу «самоубийственных» или «камикадзе»...
31) Не навязывайте заказчику решения, специфичные только для него – полезный совет для любого проекта.
32) Не следует заниматься поиском панацей – об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.
33) Не упускайте возможность удалить из критического пути те элементы, которые находятся вне сферы вашего контроля – если ваша проектная команда не в состоянии их контролировать, то иметь такие элементы на критическом пути означает повышенную степень риска. Это относится к таким вещам, как инструментальные средства поставщика, оборудование, программные продукты и другие компоненты, поступающие от внешних поставщиков. Это касается также вещественных результатов деятельности и политических решений акционеров и заинтересованных лиц, имеющих отношение к проекту.
Книги: Путь камикадзе
2011-12-24 10:34:56 (читать в оригинале)Книга "Путь камикадзе" Эдварда Йордона - это попытка зафиксировать такие процессы, и надо сказать, попытка более, чем удачная. Читать обязательно.
Ниже перечислены некоторые best practices, рекомендуемые в книге для безнадежных проектов:
...
24) Бинарная оценка качества по результатам этапов – другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно, фиксируя достигнутые результаты с помощью «бинарных» признаков...
25) Свободный доступ к информации о проектных планах и фактических результатах – это согласуется с моими рекомендациями в предыдущих главах. Безнадёжный проект будет испытывать достаточно большие трудности, если менеджер будет скрывать от остальной команды информацию о состоянии проекта.
26) Фиксация дефектов в соответствии с заданными показателями качества – одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.
27) Конфигурационное управление – как бы оно не называлось (контроль версий, контроль исходных кодов, или как-нибудь ещё), конфигурационное управление обычно рассматривается как важная практическая составляющая проектов, протекающих в экстремальных условиях.
28) Ответственность и подотчётность руководства перед сотрудниками – увы, но в большинстве безнадёжных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадёжные проекты относятся к типу «самоубийственных» или «камикадзе»...
31) Не навязывайте заказчику решения, специфичные только для него – полезный совет для любого проекта.
32) Не следует заниматься поиском панацей – об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.
33) Не упускайте возможность удалить из критического пути те элементы, которые находятся вне сферы вашего контроля – если ваша проектная команда не в состоянии их контролировать, то иметь такие элементы на критическом пути означает повышенную степень риска. Это относится к таким вещам, как инструментальные средства поставщика, оборудование, программные продукты и другие компоненты, поступающие от внешних поставщиков. Это касается также вещественных результатов деятельности и политических решений акционеров и заинтересованных лиц, имеющих отношение к проекту.
6 Steps to Success
2011-12-22 01:08:59 (читать в оригинале)
6 Steps to Success
2011-12-22 01:08:59 (читать в оригинале)
Категория «Новости»
Взлеты Топ 5
 | ||
|
+903 |
934 |
Блог о подарках и праздниках |
|
+883 |
955 |
Kitten |
|
+876 |
942 |
And_So_On |
|
+846 |
1007 |
Уголок народного трейдера |
|
+814 |
958 |
ank |
Падения Топ 5
 | ||
|
-1 |
255 |
Главная |
|
-1 |
4 |
Equillibrium |
|
-2 |
15 |
Elephant_Talk |
|
-6 |
771 |
Сибдепо / Блоги |
|
-6 |
5 |
lqp |
Популярные за сутки
Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.
взяты из открытых общедоступных источников и являются собственностью их авторов.