кратко из статей по управлению проектами

source
Описание:
Необходимыми факторами успеха реформирования являются, во-первых, вовлеченность всех участников процесса и, во-вторых, - мотивация членов проектных команд.Рабочая
 
* 100.00% 8/8
* 2008/06/26 10:53
Аутсорсинг управления проектами.docx/
 
Но на практике компании передают на внешнее управление и ключевые проекты – по причинам, которые уже упоминались: а) нет своих ресурсов, а расти и завоевывать рынок нужно быстро; б) необходимо обучать в работе с профессионалами своих руководителей проектов. Таким образом, аутсорсинг управления проектами может применяться без ограничений.
 
* 75.42% 3/4
* 2008/06/26 10:53
2READ\Опыт сертификации по стандартам PMI и IPMA.docx/
 
Экзамен PMI напоминает бег на среднюю дистанцию. Ровно в 9.00 (по местному времени) международные асессоры по всему миру разрешают кандидатам вскрыть конверты с 200 вопросами, и начинается трехчасовая гонка: на каждый вопрос у кандидата есть примерно одна минута. Кандидат должен выбрать правильный ответ из четырех предложенных вариантов. Большинство вопросов предполагает детальное знание стандартов
 
* 83.87% 4/4
* 2008/06/26 10:53
2READ\Опыт сертификации по стандартам PMI и IPMA.docx/
 
PMI (PMBoK). Однако есть вопросы, предполагающие наличие у кандидата практического опыта, и здесь существует опасность дать неправильный ответ, поскольку в ряде ситуаций сложно сделать однозначный выбор (кроме того, оценки ситуации и приоритеты, расставляемые американскими и российскими менеджерами, могут отличаться). Должен отметить, что экзамен - тяжелая физическая нагрузка. Дополнительные сложности некоторым кандидатам
 
* 91.59% 4/4
* 2008/06/26 10:54
2READ\Опыт сертификации по стандартам PMI и IPMA.docx/
 
доставило недостаточное знание английского языка.
 
* 100.00% 4/4
* 2008/06/26 10:54
2READ\Опыт сертификации по стандартам PMI и IPMA.docx/
 
Система сертификации IPMA в большей степени обращает внимание на деловые качества кандидата, нежели на точное соответствие ответов утвержденным стандартам.
 
* 48.81% 2/4
* 2008/06/26 10:54
2READ\Опыт сертификации по стандартам PMI и IPMA.docx/
 
PMI требует от кандидата предоставить описание его опыта управления проектами за последние шесть лет. Данное описание должно показать не менее 4500 часов практического опыта с перечислением конкретных управленческих процедур, которые выполнял кандидат в качестве менеджера проектов, структурированных в рамках пяти основных процессов (инициация, планирование, исполнение, контроль, завершение).
Экзамен
 
* 55.24% 2/4
* 2008/06/26 10:54
2READ\Опыт сертификации по стандартам PMI и IPMA.docx/
 
Экзамен
Сдача экзамена по требованиям IPMA проходит в три этапа и занимает три дня.
Первый день предполагает работу кандидатов в команде. Каждая команда должна самоорганизоваться и выполнить задание на основе предложенного экзаменационной комиссией описания проекта.
Задание предполагает разработку основных разделов плана реализации проекта, включая организационную структуру и график работ. Оценивается как
 
* 64.27% 3/4
* 2008/06/26 10:54
2READ\Опыт сертификации по стандартам PMI и IPMA.docx/
 
результат работы, так и участие кандидата в процессе его реализации.
Второй день - собственно экзамен. Он включает в себя вопросы по основным разделам теории управления проектами, на которые необходимо дать развернутые ответы. Кандидат может отразить свое видение вопроса, хотя и рекомендуется пользоваться терминологией, утвержденной Российской ассоциацией управления проектами.
В последний день кандидаты проходят личное собеседование с
 
* 72.94% 3/4
* 2008/06/26 10:54
2READ\Опыт сертификации по стандартам PMI и IPMA.docx/
 
асессорами.
 
* 83.35% 17/20
* 2008/06/26 10:55
2READ\Знак качества для менеджеров проектов.docx/
 
зависимости от уровня сертификации, одно из следующих званий:
сертифицированный директор программ или проектов (уровень А);
сертифицированный управляющий проектами (уровень В); сертифицированный управляющий международными проектами (уровень В1 );
сертифицированный профессионал по управлению проектами (уровень С);
сертифицированный специалист по управлению проектами (уровень D).
 
* 32.71% 2/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
Информация о Сертифицированных специалистах - данные о Сертифицированных специалистах, которые заносятся в МЕЖДУНАРОДНЫЙ и НАЦИОНАЛЬНЫЙ РЕЕСТРЫ СПЕЦИАЛИСТОВ по УПРАВЛЕНИЮ ПРОЕКТАМИ и на web-сайты IPMA и СОВНЕТ.
Виды сертификатов
Кандидат, успешно прошедший все процедуры по одному из сертификационных уровней, получает сертификат утвержденного образца:
Уровень А. Сертифицированный директор программ или проектов -
 
* 37.45% 3/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
СДП (Certificated Project Director - CPD) должен:
Быть способен управлять всеми проектами компании или проектами ее отделения или всеми проектами программы;
Иметь минимум 5-ти летний опыт управления комплексными проектами и программами, из которых кандидат не менее 3-х лет был ответственен за руководство, координацию и управление портфелем проектов;
Уметь осуществлять руководство координацией и контролем всех проектов компании или ее
 
* 42.37% 3/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
отделения;
Иметь портфель конкретных стратегических предложений по общему управлению в компании;
Принимать участие в подготовке персонала, задействованного в управлении проектами и управляющих проектами;
Нести ответственность за реализацию управления проектами, разработку руководящих и нормативных материалов, а также применение основных методов и средств.
Уровень B. Сертифицированный управляющий проектами -
 
* 46.70% 4/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
СУП(Certificated Project Manager - CPM) должен:
Быть способным самостоятельно управлять сложными проектами;
Иметь минимум 5-ти летний опыт управления проектами, из которых не менее 3-х лет в качестве ответственного за руководство и управление сложными проектами;
Уметь осуществлять руководство координацией и контролем всех проектов компании или ее отделения;
Иметь портфель конкретных
 
* 51.43% 4/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
стратегических предложений по общему управлению в компании;
Принимать участие в подготовке персонала, задействованного в управлении проектами и управляющих проектами;
Нести ответственность за реализацию управления проектами, разработку руководящих и нормативных материалов, а также применение основных методов и средств.
Уровень B1. Сертифицированный управляющий международными проектами - СУМП(Certificated International Project Manager -
 
* 56.02% 4/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
CIPM) должен:
Быть способным самостоятельно управлять сложными проектами, включая международные проекты;
Иметь минимум 5-ти летний опыт управления проектами, из которых не менее 3-х лет в качестве ответственного за руководство и управление сложными проектами;
Иметь минимум трех летний опыт работы в международных проектах;
Владеть одним из трех иностранных языков: английским,
 
* 60.82% 5/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
немецким или французским - для профессиональной деятельности;
Нести ответственность за осуществление сложного проекта связанного с:
множеством взаимосвязанных подсистем и элементов, а также связей с окружением проекта;
несколькими компаниями и/или организационными единицами, вовлеченными в проект;
различными функциональными сферами и дисциплинами, задействованными в проекте;
различными фазами жизненного цикла проекта, имеющими значительную
 
* 65.73% 5/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
значительную продолжительность;
применения различных известных методов, средств и инструментария по Управлению Проектами.
Руководить большой группой персонала, участвующего в управлении проектом;
Участвовать в международных мероприятиях и форумах по управлению проектами
Уровень C. Сертифицированный Профессионал по Управлению Проектами - СПУП (Registered Project Management Professional - RPMP) должен:
Быть способным самостоятельно
 
* 70.39% 6/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
самостоятельно управлять несложными проектами и помогать управляющему сложными проектами во всех функциональных областях Управления проектами;
Иметь минимум 3-х летний опыт управления проектами в качестве руководителя в функциональных областях несложного проекта;
Нести ответственность за осуществление несложного проекта и за все его параметры;
Управлять небольшими группами персонала по управлению проектом;
Применять
 
* 75.08% 6/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
Применять методы, средства и инструментарий по управлению проектами;
Быть способным работать в качестве руководителя группы специалистов, входящей в команду сложного проекта, и нести ответственность за соответствующие параметры проекта.
Уровень D. Сертифицированный специалист по управлению проектами - ССУП (Project Management Professional - PMP) должен:
Обладать знаниями во всех областях Управления Проектами
 
* 79.75% 6/8
* 2008/06/26 10:56
2READ\Международная Сертификация.docx/
 
(и быть способным применять их в некоторых областях как специалист);
Обладать широким спектром знаний в Управлении Проектами и быть способным применять эти знания на практике;
Быть способным выступать в качестве члена команды проекта в любой функциональной области по управлению проектами.
Требования, предъявляемые к специалистам по управлению проектами разных уровней сертификации
№
Требования
 
* 29.35% 3/11
* 2008/06/27 08:44
Engineering.docx/
 
простое правило: «если процессы невозможно автоматизировать при помощи Excel и Word, то их невозможно автоматизировать нигде». Так давайте не будем больше культивировать чепуху относительно главенства ПО в системах УП.
Чепуха вторая (библейская) Об абсолютной правильности процессов описанных в PMBOK.
 
* 37.06% 4/11
* 2008/06/27 08:45
Engineering.docx/
 
Если консультант сообщает Вам, что нужно изменить такой-то процесс только потому, что в мире так никто не делает, а Вы знаете, что этот процесс – Ваше конкурентное преимущество именно потому, что в мире так никто не делает, то гоните этого консультанта прочь.
 
* 38.11% 4/11
* 2008/06/27 08:46
Engineering.docx/
 
Чепуха третья (проектно-ориентированная) О высокой эффективности внедрения УП в проектно-ориентированных отраслях. Да, действительно, в конечном итоге внедрение методологии УП приносит эффект и в этих отраслях.
 
* 42.80% 4/11
* 2008/06/27 08:47
Engineering.docx/
 
Даже если руководство компании, из стратегических соображений, очень заинтересовано в этом внедрении, то старую систему отбросят, а новую будут некоторое время саботировать (гласно или негласно).
 
* 50.35% 5/11
* 2008/06/27 08:48
Engineering.docx/
 
наибольший эффект внедрение системы УП приносит в изначально непроектных отраслях: финансы, производство, дистрибуция, транспорт и т.д. В этих отраслях запускается сейчас огромное количество проектов и за неимением собственных накатанных техник и средств УП они наступают на все грабли, на которые только можно было наступить.
 
* 55.86% 6/11
* 2008/06/27 08:48
Engineering.docx/
 
Чепуха четвертая (эзотерическая) УП – это дорогое секретное оружие для достижения небывалых результатов. Эта чепуха появилась, вероятнее всего, от желания не достаточно компетентных консультантов набить себе цену.
 
* 58.92% 6/11
* 2008/06/27 08:49
Engineering.docx/
 
На самом деле здесь не может быть никакой секретности, поскольку единоличное владение этой методологией, сродни владению единственным мобильным телефоном или e-mail в мире. Какая польза от них в таком случае? Представьте, если заказчик владеет методологией УП, а исполнитель и слухом о ней ничего не слыхивал (или наоборот). Что происходит в этом случае? Правильно! Все разговаривают на разных языках. Получается своего рода Вавилонская башня и разные языки.
 
* 66.97% 7/11
* 2008/06/27 08:49
Engineering.docx/
 
Чепуха пятая (богатырская) Методологию УП могут внедрить только внешние консультанты.
 
* 71.69% 8/11
* 2008/06/27 08:50
Engineering.docx/
 
Поэтому и используют их здесь именно как консультантов, но ни в коем случае ни как руководителей проекта и ни как ключевых внедренцев. это ваш проект
 
* 79.84% 9/11
* 2008/06/27 08:51
Engineering.docx/
 
Стандарт же должен жить и постоянно развиваться, а вместе с ним должны развиваться входящие в него документы. Даже в Конституцию вносят поправки!
 
* 84.07% 9/11
* 2008/06/27 08:52
Engineering.docx/
 
Microsoft Solutions Framework[2]. Билл Г.
 
* 91.11% 10/11
* 2008/06/27 08:52
Engineering.docx/
 
Чепуха седьмая (бумажная) Очень важно быть сертифицированным специалистом в области УП Организации, предлагающие услуги по сертификации в области УП утверждают, что наличие сертификата – это чуть ли не самое главное требование при трудоустройстве руководителя проектов; что сертификация крайне важна для подтверждения компетенции; что это возможность доказать руководителям и подчиненным
 
* 94.75% 10/11
* 2008/06/27 08:52
Engineering.docx/
 
подчиненным свою исключительность. Возможно, где-то в Европе или Штатах так и есть, но у нас, где любую бумажку можно купить, к сертификатам относятся скептически. В результате сертификат в нашей стране – это просто очередная корочка для утешения самолюбия.
 
* 97.95% 11/11
* 2008/06/27 08:53
Engineering.docx/
 
Так что сертифицируйтесь, но не для очередной медальки на «дряхлой груди генсека», а для улучшения своей компетенции и самоуверенности. Слышен шелест чепухи…
 
* 8.12% 1/21
* 2008/06/27 08:54
Balanced Scorecard как инструмент стратегического менеджмента качества посредством DIN EN ISO 9001.docx/
 
"What you measure is that you get"2
Введение
Исходя из определения, данного в DIN EN ISO 9000:2000 [1], качество определено как: "степень, в которой комплекс соответствующих характеристик отвечает необходимым требованиям".
 
* 22.01% 4/21
* 2008/06/27 09:17
Balanced Scorecard как инструмент стратегического менеджмента качества посредством DIN EN ISO 9001.docx/
 
Пренебрежение нематериальными возможностями предприятия обуславливает краткосрочность планирования в области качества. (1) Доля нематериальных вложений (например, расходы на повышение квалификации сотрудников) по сравнению с материальными вложениями в последнее время непрерывно растет.
 
* 31.92% 6/21
* 2008/06/27 09:19
Balanced Scorecard как инструмент стратегического менеджмента качества посредством DIN EN ISO 9001.docx/
 
Финансовые показатели учитывают только события в прошлом. Существуют мягкие показатели: удовлетворение сотрудника, удовлетворение клиента, положение в обществе и т. д., которые являются актуальными для организации именно сейчас, а не в прошлом. Через финансово ориентированную систему показателей эти данные могут учитываться только задним числом. "Вообще, имеет место тот факт, что финансовые величины могут отражать только успех предприятия в прошлом" [2].
 
* 76.23% 16/21
* 2008/06/27 09:27
Balanced Scorecard как инструмент стратегического менеджмента качества посредством DIN EN ISO 9001.docx/
 
для освоения зарубежных рынков сертификат согласно DIN EN ISO 9000:2000 просто необходим.
 
* 18.88% 4/23
* 2008/06/27 11:10
6 ловушек управленческого консультирования.docx/
 
Ловушка 1: Квалификации персонала предприятия, участвующего в проекте, недостаточно чтобы разработать эффективную технологию и в дальнейшем сопровождать ее внедрение.
 
* 25.35% 6/23
* 2008/06/27 11:11
6 ловушек управленческого консультирования.docx/
 
Что вас ждет: дополнительные расходы на обучение, нежелание сотрудников работать в новой системе, вынужденные увольнения.
Каким образом учитывать этот фактор и влиять на него:
Совместно с консультационной компанией-исполнителем проекта, выделяем функциональные подразделения, которые будут задействованы в проекте, составляем список конкретных сотрудников, им соответствующих. Далее, со стороны консультационной компании должен быть предоставлен
 
* 27.43% 6/23
* 2008/06/27 11:11
6 ловушек управленческого консультирования.docx/
 
список требований к знаниям "перечисленных" сотрудников, какими они должны обладать для эффективной работы в процессе проекта и после его завершения. Затем (в идеале, это, конечно, должна делать консультационная компания) проводится анкетирование "попавших под подозрение" сотрудников на предмет их реальных знаний. На основании полученной информации оцениваются будущие расходы на "апгрейд" знаний ваших специалистов с подробной сметой ожидаемых затрат. Здесь также нужно обратить
 
* 29.10% 6/23
* 2008/06/27 11:11
6 ловушек управленческого консультирования.docx/
 
обратить внимание на то, что круг ваших специалистов, которые будут задействованы, обычно несколько шире, чем вы себе это будете представлять.
Фактор 2. Четкое понимание целей проекта всеми его участниками
Ловушка 2: После завершения проекта Вы не получили того, чего ожидали в начале.
 
* 39.96% 9/23
* 2008/06/27 11:13
6 ловушек управленческого консультирования.docx/
 
Каким образом учитывать этот фактор и влиять на него:
Обычно, предприятия, обращающиеся с первоначальным запросом за консультационными услугами к специалистам, запрашивают конкретное решение, которое им (по их глубокому разумению) необходимо. Очень часто, запрос формируется конкретным образом: нам необходимо бюджетирование, нам нужен такой-то программный продукт, нам необходимо провести тренинг топ-менеджмента по лидерству и уволить нескольких человек. При этом, вся
 
* 42.09% 10/23
* 2008/06/27 11:14
6 ловушек управленческого консультирования.docx/
 
"предыстория" обычно умалчивается, принявшему решение о задействовании управленческих консультантов или специалистов по внедрению того или иного продукта все предельно ясно. Еще бы, скорее всего, та проблема (точнее ее видимые негативные проявления), которая заставила на это решиться, обдумывалась не одну ночь или месяц, был проведен глубокий (на самом деле, очень поверхностный) анализ решений, предлагаемых рынком. Но бывалых консультантов этим не смутишь: будьте готовы к тому, что
 
* 44.08% 10/23
* 2008/06/27 11:14
6 ловушек управленческого консультирования.docx/
 
вас будут очень подробно (в дружественной и доверительной обстановке) расспрашивать о вещах, с вашей точки зрения, к проблеме совершенно не относящихся. Не все так просто, недаром в современном бизнесе есть своего рода "разделение труда" - вы управляете своим предприятием, а есть компании, которые специализируются на том, чтобы помогать вам управлять наиболее эффективным образом. Поэтому не спешите с выводами и выбором конкретного решения: доверьтесь консультантам, не стесняйтесь
 
* 46.08% 10/23
* 2008/06/27 11:14
6 ловушек управленческого консультирования.docx/
 
выдавать поток проблем, которые вас мучают "без анализа". Известный факт, что любой, даже самый квалифицированный специалист порой не в состоянии увидеть банальных причинно-следственных связей, которые прямо-таки бросаются в глаза консультанту, который, хоть и не обладает соответствующим знанием специфики данной области, но "съел собаку" на подобных проектах и при общении с такими "озабоченными" будущим своей компании специалистами. Чем более подробную картину вы предоставите, тем
 
* 47.79% 11/23
* 2008/06/27 11:14
6 ловушек управленческого консультирования.docx/
 
больше шансов на то, что выбранная технология будет соответствовать решению поставленных вами задач.
Фактор 3. Соответствие философии вашей компании философии консалтинговой компании
 
* 52.68% 12/23
* 2008/06/27 11:41
6 ловушек управленческого консультирования.docx/
 
Ловушка 3: Проект идет с трудом, затягивается и после его завершения, внесенные изменения "не приживаются", так как не соответствуют ценностям компании, не вписываются в характер и темпы ее развития.
Что вас ждет: здесь сложности начнутся с первых
 
* 55.26% 13/23
* 2008/06/27 11:41
6 ловушек управленческого консультирования.docx/
 
Каким образом учитывать этот фактор и влиять на него:
Нет конкретного "индикатора", позволяющего определить, насколько ваша компания и компания, предоставляющая услуги по управленческому консультированию, близки по духу. Обычно, такие вещи очень хорошо чувствуются, когда происходит "очное" общение, причем именно в офисе той компании, которую вы "присмотрели" в качестве консультанта. Если на протяжении всего общения не только вы, но и ваши коллеги будете испытывать напряжение,
 
* 57.24% 13/23
* 2008/06/27 11:42
6 ловушек управленческого консультирования.docx/
 
напряжение, а скорее даже отчуждение того, как и что вам будут говорить, то стоит хорошо задуматься, прежде чем обратиться к услугам данной компании. В делах консультирования, также как и в обычных человеческих отношениях, должен присутствовать элемент доверия и понимания...
Кстати говоря, язык общения очень показателен в этом смысле – он может принимать различные формы для выражения в сущности одного и того же. В каждой компании есть свой "птичий" язык. Есть компании, в которых менеджеры
 
* 59.38% 14/23
* 2008/06/27 11:42
6 ловушек управленческого консультирования.docx/
 
перекидываются друг с другом обрывочными фразами директивными характера, им достаточно дать "набросок" мысли – и все друг друга понимают, и время не теряется. У других – наоборот – принято говорить много, витиевато, показывать друг другу проблему с разных сторон, не забывая при этом отвешивать друг другу "реверансы". Вообще говоря, специалисты – профессионалы должны подстраиваться под разные стили общения – но если они совпадают изначально – это поможет избежать многих издержек общения.
 
* 61.08% 14/23
* 2008/06/27 11:42
6 ловушек управленческого консультирования.docx/
 
общения.
Еще один важный момент – одинаковый темп выполнения работ, и принятия решений. Любой консалтинговый проект означает выполнение разных работ двумя сторонами, например, заполнение анкет, подготовка документов и пр. На практике плохи оба отклонения: и если консультант работает медленнее, чем того ожидает заказчик, и наоборот, если заказчик медленнее выполняет свою часть работы (подготавливает информацию, согласовывает результаты), чем
 
* 63.03% 15/23
* 2008/06/27 11:43
6 ловушек управленческого консультирования.docx/
 
того ожидает консультант (да-да, при наличии определенной технологии консалтинговых работ бывает и такое!).
В смысле ценностей компаний очень полезно сравнить миссии
 
* 64.95% 15/23
* 2008/06/27 11:43
6 ловушек управленческого консультирования.docx/
 
Фактор 4. Ваши материально-трудовые ресурсы
 
* 67.11% 16/23
* 2008/06/27 11:43
6 ловушек управленческого консультирования.docx/
 
И что в итоге получается, компьютеры оказываются недостаточно мощными, чтобы установить необходимое программное обеспечение, системное программное обеспечение устарело, а у сотрудников, которых выдвинули для реализации, а в дальнейшем на поддержку и развития результатов проекта нет резервов свободного времени для этих работ.
 
* 71.48% 17/23
* 2008/06/27 11:44
6 ловушек управленческого консультирования.docx/
 
Ловушка 4: Вы начинаете проект, не просчитав все необходимые материальные ресурсы и достаточность свободного рабочего времени, а значит, практически в 90% случаях, никогда его не закончите.
 
* 74.34% 17/23
* 2008/06/27 11:44
6 ловушек управленческого консультирования.docx/
 
Каким образом учитывать этот фактор и влиять на него:
Любая консалтинговая компания перед началом проекта проведет с той или иной степенью детализации так называемое предпроектное обследование, в процессе которого будет составлен бюджет проекта. В такой бюджет будут включены примерные затраты за непосредственно консультационные услуги, часто – предложения по обучению сотрудников, оценка "железных" ресурсов, которые вам наверняка понадобятся. Как показывает практика, реальные затраты
 
* 76.49% 18/23
* 2008/06/27 11:44
6 ловушек управленческого консультирования.docx/
 
затраты на проект никогда не исчерпываются той цифрой, которая будет сформирована вначале. Самое первое, с чего нужно будет начать, после того, как вам стала известна примерная сумма затрат за консалтинговые услуги, так это подробный График занятости ваших сотрудников на время исполнения проекта. Составить его вовсе не так просто как может показаться на первый взгляд. Это должно быть вашей совместной работой на "допроектной" стадии переговоров с консалтинговой компанией, которая должна четко
 
* 78.32% 18/23
* 2008/06/27 11:45
6 ловушек управленческого консультирования.docx/
 
сориентировать вас, какие сотрудники, для чего и как часто понадобятся. Далее, исходя из приоритетов вашей текущей работы, вы должны четко распределить загруженность ваших сотрудников. Так как времени никогда и не на что не хватает, то здесь также есть "свои ухищрения". иногда консалтинговые предлагают проводить тренинги и корпоративное обучение загородом в отвлеченной обстановке.
Фактор 5. Соответствие выбранного управленческого решения реально стоящей перед
 
* 80.16% 19/23
* 2008/06/27 11:45
6 ловушек управленческого консультирования.docx/
 
вами задаче
К
 
* 88.75% 21/23
* 2008/06/27 11:47
6 ловушек управленческого консультирования.docx/
 
Ловушка 5: В процессе проекта вы осознаете, что проблема лежит гораздо глубже и для ее решения требуется совершенно другой способ.
Каким образом учитывать этот фактор и влиять на него:
Самый главный совет: руководству предприятия отойти от постановки конкретной задачи к осознанию проблемы в комплексе. На самом деле, на первоначальном этапе общения – это и есть основная задача консультанта.
Фактор 6 Способность ваших сотрудников объединяться в
 
* 90.47% 21/23
* 2008/06/27 11:47
6 ловушек управленческого консультирования.docx/
 
команду
Ловушка 6: В процессе проекта обнажаются и обостряются все негативные моменты взаимоотношений между сотрудниками, безобидный на первый взгляд проект дает толчок к расколу внутри компании, возникает "сопротивление" проекту.
 
* 93.48% 22/23
* 2008/06/27 11:48
6 ловушек управленческого консультирования.docx/
 
Каким образом учитывать этот фактор и влиять на него:
Не смотря на то, что этот фактор мы указываем в конце, он, несомненно, самый важный в процессе любого проекта, влекущего за собой вмешательство в систему управления. Если вы переоцените собственных сотрудников с точки зрения их умения сплачиваться в команду и эффективно вырабатывать командные решения – это сведет на нет все ваши предыдущие усилия. Поэтому именно перед началом любого проекта необходимо проанализировать,
 
* 95.59% 22/23
* 2008/06/27 11:48
6 ловушек управленческого консультирования.docx/
 
какие проблемы у вас есть с точки зрения внутрифирменных коммуникаций. Причем, специалисты, непосредственно вовлеченные в проект, могут уметь прекрасно работать друг с другом, а проблема может крыться в отношениях того или иного сотрудника со своими непосредственными подчиненными, которые на этапе вмешательства в компанию консультантов могут никак не участвовать, но которым планируется "спустить" все нововведения "свыше". Обладают ли ваши менеджеры достаточным авторитетом и доверием
 
* 97.56% 23/23
* 2008/06/27 11:48
6 ловушек управленческого консультирования.docx/
 
подчиненных? Когда вы проанализируете психологическую подготовку своих сотрудников и коллег к проекту, у вас наверняка появятся определенные "дыры" и сомнения относительно будущей совместной работы, о них вам и нужно будет подробно рассказать компании, предоставляющей консультационные услуги. На основании этой информации уважающим себя консультантом будет выработана технология, позволяющая избежать разрушительных процессов и решить их конструктивными методами. Скорее всего, понадобится
 
* 99.32% 23/23
* 2008/06/27 11:48
6 ловушек управленческого консультирования.docx/
 
понадобится ряд корпоративных тренингов по выработке коммуникационных навыков у ваших сотрудников. Хотя опыт нашей компании показывает, что при определенном подходе, правильной организации проекта общение сотрудников в отвлеченной обстановке, направленное на развитие и рост компании выводит все внутренние конфликты на конструктивный уровень.
В идеале, проект по постановке системы управления – это лучший повод для того, чтобы сплотить команду, вовлечь менеджеров в
 
* 100.00% 23/23
* 2008/06/27 11:48
6 ловушек управленческого консультирования.docx/
 
процесс развития и выработать общекорпоративные ценности и установки.
 
* 44.83% 8/19
* 2008/06/28 23:42
Введение в проектный менеджмент.docx/
 
календарного графика. НЕМНОГО ИСТОРИИ ... В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов в США. В 1956 г. М.Уолкер из фирмы "Дюпон", исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д.Келли из группы планирования капитального строительства фирмы "Ремингтон Рэнд". Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по
 
* 47.25% 9/19
* 2008/06/28 23:42
Введение в проектный менеджмент.docx/
 
модернизации заводов фирмы "Дюпон". В результате был создан рациональный и простой метод описания проекта с использованием ЭВМ. Первоначально он был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути - МКП (или CPM - Critical Path Method). Параллельно и независимо в военно-морских силах США был создан метод анализа и оценки программ PERT (Program Evaluation and Review Technique). Данный метод был разработан корпорацией "Локхид" и консалтинговой фирмой "Буз,
 
* 49.64% 9/19
* 2008/06/28 23:43
Введение в проектный менеджмент.docx/
 
Аллен энд Гамильтон" для реализации проекта разработки ракетной системы "Поларис", объединяющего около 3800 основных подрядчиков и состоящего из 60 тыс. операций. Использование метода PERT позволило руководству программы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также вероятность своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект удалось завершить на два года раньше
 
* 24.46% 3/16
* 2008/06/29 18:27
Естественный отбор.docx/
 
с одной стороны, не должен «цепляться» за свое место в проекте и быть морально готовым по его завершении формально остаться без работы (по крайней мере, до вступления в управление новым проектом);
с другой стороны, руководитель проекта должен вкладывать все свои силы и душу в выполнение текущего проекта и достижение поставленных целей проекта.
Уникальность проекта диктует
 
* 26.81% 4/16
* 2008/06/29 18:28
Естественный отбор.docx/
 
необходимость владения междисциплинарными знаниями и навыками, в отличие от руководителей функциональных организаций, который может являться профессионалом только в одной области.
 
* 48.62% 7/16
* 2008/06/29 18:30
Естественный отбор.docx/
 
человек вряд ли может быть профессионалам во всех областях. Решением этой проблемы является формирование команды проекта, состоящей из профессионалов в различных предметных областях, на которые распространяются требования проекта.
 
* 56.90% 9/16
* 2008/06/29 18:32
Естественный отбор.docx/
 
симфоническим оркестром, а руководителя проекта – с дирижером. В оркестре выделяются первая скрипка, другие солисты. При этом, не обязательно, чтобы все музыканты были виртуозами, а дирижер может и не уметь сам виртуозно играть на всех музыкальных инструментах. Но все музыканты должны играть по одной партитуре, вступать в требуемые моменты времени, а дирижер должен слышать и координировать всех музыкантов во время исполнения музыкального произведения. В то же время, в характере
 
* 60.55% 9/16
* 2008/06/29 18:32
Естественный отбор.docx/
 
С учетом всех особенностей проектной деятельности, руководитель проекта должен уметь:
решать проблемы, которые не могут быть полностью предоставлены другим предметным специалистам;
в процессе управления проектами учитывать множество факторов со сложными взаимосвязями, оценивать совместимость, непротиворечивость отдельных решений, регулировать связи между целями проекта и способами их достижения;
корректировать конкретные
 
* 63.15% 10/16
* 2008/06/29 18:32
Естественный отбор.docx/
 
подцели и нормы на определенный период, а также предлагать сценарии возможных направлений развития и рекомендации для других уровней управления;
перестраивать сети взаимосвязей между представителями высшего руководства, менеджерами и специалистами в различных подразделениях, участвующих или привлекаемых в конкретные моменты времени к участию в проекте;
работать и договариваться со всеми заинтересованными в проекте сторонами;
 
* 40.15% 2/6
* 2008/06/29 18:39
Заметки о быстрой разработке с использованием Scrum.docx/
 
 
Scrum предоставляет эмпирический подход к разработке ПО. Этот процесс быстр, адаптивен, умеет самонастриваться и отличен от последовательного (водопадного) подхода. Scrum основан на повторяющихся циклах, это делает его более гибким и предсказуемым.
В основе лежат короткие ежедневные встречи — Scrum и циклические 30-дневные встречи, называемые Sprint. Во время ежедневного Scrum'a каждому члену команды задаются только 3 вопроса:
Что
 
* 44.84% 2/6
* 2008/06/29 18:39
Заметки о быстрой разработке с использованием Scrum.docx/
 
Что было сделано с последнего Scrum'a?
Что вы будете делать между этой и следующий встречей Scrum?
Что мешает вам выполнять работу?
Главные принципы Scrum
Индивидуализм и взаимодействие важнее строгих процессов и методов
Работающее ПО важнее сложной документации
Взаимодействие
 
* 49.88% 3/6
* 2008/06/29 18:39
Заметки о быстрой разработке с использованием Scrum.docx/
 
Взаимодействие с заказчиками важнее контрактных договоренностей
Готовность изменить важнее следованию плану
Scrum, как и
 
* 68.08% 4/6
* 2008/06/29 18:44
Заметки о быстрой разработке с использованием Scrum.docx/
 
 
Команда — главная движущая сила проекта, это источник продуктивности и креативности.
Команда, которая будет участвовать в ежедневных Scrum'ах должна состоять из 7 плюс-минус 2 человека. Большее число не рекомендуется, лучше разделить на несколько команд. Scrum Master (или, более понятно – Project manager) ведет эту встречу. Члены команды называются «свиньями» и только они имеют право говорить. На встречах могут присутствовать молчаливые посетители — «курицы», которые такого права
 
* 75.52% 4/6
* 2008/06/29 18:44
Заметки о быстрой разработке с использованием Scrum.docx/
 
Кен Швабер (Ken Schwaber, автор книги «Agile Project Management with Scrum») на своих тренингах предлагал вводить практику наказания «рублем», когда каждый опоздавший платит по доллару или евро, собранные деньги впоследствии он отдавал бездомным на улице.
 
* 80.23% 5/6
* 2008/06/29 18:45
Заметки о быстрой разработке с использованием Scrum.docx/
 
В команде не должны быть только разработчики. Команда должна включать в себя также и тестеров, дизайнеров, а также других заинтересованных лиц. Желательно, если рабочие места всей команды находятся в одной комнате, либо, как минимум в соседних. Это должно способствовать максимальной коммуникации между членами команды.
 
* 93.87% 5/6
* 2008/06/29 18:45
Заметки о быстрой разработке с использованием Scrum.docx/
 
Успех Scrum'a зависит во многом до деятельности Scrum Master'a. В числе его главных задач и особенностей деятельности:
Удалять барьеры между заказчиком и разработчиками, так чтобы заказчик напрямую управлял разработкой
Доверять своей команде, делать все возможное чтобы раскрыть креативность каждого ее члена
Увеличивать продуктивность команды любыми возможными способами
Мертвый
 
* 31.56% 3/11
* 2008/06/29 18:49
Идеальный час.docx/
 
Он занимался работой. Просто КПД его деятельности был вынужденно низким. Не потому, что плох Федя. А потому, что продуктивность любого разработчика влияет то, что я называю «коэффициентом мусорного времени» . Грубо говоря — это соотношение непроизводительных часов к производительным. В случае Феди — 5:3, что означает что для выполнения 4х часовой задачи ему был необходим весь день и еще немного следующего. Если посмотреть на его результат, то мы увидим, что это вполне справедливо —
 
* 60.40% 6/11
* 2008/06/30 00:03
Идеальный час.docx/
 
точным методом может стать использование статистического моделирования — например, с помощью инструмента Riskology , разработанного Томом де Марко и Тимом Листером для моделирования влияния рисков на проекты. Получить его можно по адресу SystemsGuild.Com, и там же находится инструкция по применению. Согласно этой инструкции надо задать параметры проекта, внести новый риск непрерывного типа «Влияние мусорного времени», и задать коэффициент его влияния согласно инструкции.
 
* 69.93% 7/11
* 2008/06/30 00:05
Идеальный час.docx/
 
Административно-хозяйственной службы — обеспечивать производственную деятельность, а не мешать ей. В своей компании, например, я установил такой порядок — бухгалтер готовит для сотрудника весь набор документов, и ему остается лишь поставить свою подпись.
 
* 79.29% 8/11
* 2008/06/30 00:05
Идеальный час.docx/
 
Личные интересы сотрудников. Возможно, я кого-то удивлю, но достаточно много людей рассматривает работу как способ заниматься любыми делами за чужой счет. Чаты, форумы, поиск фильмов и музыки, онлайновые знакомства — вот далеко не полный перечень развлечений в рабочее время. Конечно, не надо путать теплое с мягким — форумы могут способствовать профессиональному росту, коммуникаторы можно использовать для общения с коллегами из других городов — но во всем хороша мера.
Если
 
* 89.69% 10/11
* 2008/06/30 00:06
Идеальный час.docx/
 
Требуйте использовать голосовую почту на рабочих и персональных рабочих телефонах. Во-первых, это существенно сократит уровень шума в комнате, а во-вторых, позволит людям сохранять концентрацию, так как они не будут отвлекаться на звонки. Голосовую почту можно проверять на перекурах или кофе-брейках, убивая двух зайцев.
 
* 98.34% 11/11
* 2008/06/30 00:07
Идеальный час.docx/
 
Станьте брандмауэрами перед Вашими людьми. Защищайте их от бюрократов, попыток вовлечь их в бесконечные совещания, начать менять им мебель в середине рабочего дня — одним словом, от любых действий, которые могут помешать им работать.
 
* 44.67% 6/13
* 2008/07/01 13:12
Как оценивать компетенцию менеджеров проектов.docx/
 
Программа сертификации: основные принципы
В том же 2006-м, когда был представлен стандарт GAPPS, рабочая группа приступила к созданию сертификационной программы, основанной на анализе результатов работы. И уже в конце года она была впервые внедрена компанией Motorola для внутренней аттестации своих менеджеров проектов.
Представляя новую программу,
 
* 51.64% 7/13
* 2008/07/01 13:13
Как оценивать компетенцию менеджеров проектов.docx/
 
требует, чтобы кандидат предоставил реальные физические документы, иллюстрирующие уровень его квалификации. Это могут быть, например, копии электронных писем, направленных претендентом своему руководителю и определяющих заинтересованных участников проекта. Или страница из проектного плана, где приведен такой список участников. И последнее — возможно, наиболее важное: успешный кандидат должен удовлетворить всем без исключения критериям оценки выполнения проекта. Только в
 
* 57.28% 7/13
* 2008/07/01 13:14
Как оценивать компетенцию менеджеров проектов.docx/
 
оценкам не бывает: “Всё, что связано с человеком, — это всегда субъективно. Мы стремимся к увеличению объективности, и с точки зрения сравнения с другими имеющимися подходами наша программа более беспристрастна благодаря сбалансированности стандарта. Поскольку мы требуем стопроцентного удовлетворения всем критериям, у нас не может быть признан компетентным человек, который имеет как сильные стороны, так и слабые. Менеджер проекта должен уметь работать во всех областях, иначе он не является
 
* 44.44% 3/6
* 2008/07/01 13:26
Как повысить эффективность процесса тестирования в компании.docx/
 
«за качество отвечает каждый участник проекта». Если все действительно так, поздравляю Вас. У Вас здоровая компания, и результат долго ждать себя не заставит.
 
* 50.87% 4/8
* 2008/07/01 14:47
Как правильно уволить айтишника.docx/
 
хотят ею делиться.«Всегда, всегда, всегда действуйте с мыслью: а что, если его собъёт автобус?», — говорит Монро. Если даже такая перспектива не пугает тезавратора, то объясните ему ещё три истины, которые сильнее затрагивают его интересы. Люди, у которых нет надёжного сменщика, никогда не пойдут в отпуск. Они никогда не могут взять больничный. И, что ещё интересно, им никогда не предложат повышение по службе, то есть более престижная и высокооплачиваемая работа для них теперь недоступна.Так или
 
* 68.37% 5/8
* 2008/07/01 14:48
Как правильно уволить айтишника.docx/
 
уволить сотрудника, делайте это быстро. Монро рекомендует завести некую стандартную процедуру. Она должна включать проверку по списку всех пунктов по допуску к критическим системам, а также окончательное интервью с увольняемым по прояснению всех ключевых моментов относительно соглашений о неразглашении.
 
* 49.57% 4/8
* 2008/07/01 19:26
Камни преткновения проект.docx/
 
сроков исполнения проекта. В-третьих, руководители проектов часто неосознанно способствуют этому фактору, измеряя возможности сотрудников мерой собственной производительности. Поскольку же они часто за меньшее время в состоянии сделать больше, чем сотрудники, это приводит к просчетам в планировании затрат времени и укрепляет сотрудников в их переоценке собственных возможностей.
Четвертым
 
* 82.55% 6/8
* 2008/07/01 19:27
Камни преткновения проект.docx/
 
- встречающиеся ошибки всегда одного плана: руководитель проекта считает, что он все знает и умеет лучше сотрудников и поэтому редко делегирует ответственность членам команды. Мотивация последних , конечно, падает, а руководитель просто не справляется со временем. В дополнение чрезмерное чувство ответственности или неуверенность неопытного руководителя нередко приводят к тому, что информированность используется как средство власти. Существенную информацию о проекте и состоянии его исполнения
 
* 12.22% 1/10
* 2008/07/03 17:15
Мастер управления.docx/
 
Следует быть смелым и решительным; ничто так не компрометирует руководителя, как безынициативность и трусость, боязнь брать на себя ответственность, постоянное ожидание указаний свыше что и как делать.
Незачем откладывать без причин решение вопроса: бремя нерешенных проблем давит на психику и делает человека раздражительным.
Не торопитесь вносить изменения
 
* 24.03% 2/10
* 2008/07/03 17:16
Мастер управления.docx/
 
Распределяйте задания с учетом опыта и способностей каждого работника. Нельзя давать поручения, явно превышающие возможности работника. Задание должно быть трудным, но выполнимым.
Давая задание, надо объяснить подчиненному его цель и смысл, а также проверить, как подчиненный понял задание. Это поможет ему действовать сознательно и проявлять инициативу.
Нельзя давать одновременно несколько важных и срочных заданий: это распыляет внимание исполнителя. Рекомендуется определить
 
* 28.18% 2/10
* 2008/07/03 17:16
Мастер управления.docx/
 
Неразумно рассчитывать только на себя, считая себя все знающим и все умеющим, а подчиненных неграмотными, неквалифицированными людьми.
Никогда не делайте сами того, что могут выполнить ваши подчиненные, за исключением случаев, когда нужно показать образец исполнения или пример.
 
* 37.46% 3/10
* 2008/07/03 17:17
Мастер управления.docx/
 
Если среди ваших подчиненных есть хоть один бездельник, сделайте все возможное, чтобы заставить его работать, иначе он может подорвать дисциплину во всем коллективе.
Когда предлагаемое сотрудником решение не противоречит в принципе вашему мнению, предоставьте ему максимум свободы: нет нужды вести дискуссии по мелочам и мешать проявлению его инициативы.
Каждое
 
* 43.75% 4/10
* 2008/07/03 17:18
Мастер управления.docx/
 
Каждый раз с удовлетворением отмечайте положительные сдвиги в поведении неподатливого сотрудника, которых ему удалось добиться. Убедите его, что вы за разумные компромиссы и не разделяете лозунга «все или ничего».
Не бойтесь, если ваш подчиненный окажется более сведущим в каком-то вопросе; радуйтесь такой опоре и поддерживайте его Хорошая репутация подчиненных есть похвала руководителю и ставится ему в заслугу.
Не давайте обещаний, если не уверены, что они будут обязательно
 
* 68.16% 7/10
* 2008/07/03 17:19
Мастер управления.docx/
 
Всегда старайтесь предварительно выяснить, насколько уместными могут оказаться ваши критические замечания в адрес подчиненных в каждом конкретном случае, имея в виду, что их ошибки могут быть вызваны уважительными причинами.
Чтобы не унизить подчиненного без особой надобности, не делайте подчиненному замечаний в присутствии третьего лица. Не отзывайтесь о подчиненных недоброжелательно или оскорбительно в их отсутствии, высказывайте свои претензии к ним открыто.
Оценивая
 
* 75.93% 7/10
* 2008/07/03 17:20
Мастер управления.docx/
 
Внимательно и благожелательно выслушивайте любую критику и любое предложение подчиненного, даже если оно несущественно. Иначе подчиненный будет молчать и в других, более важных случаях. Руководитель пренебрегающий справедливыми критическими замечаниями, неизбежно противопоставляет себя коллективу и в конечном счете теряет возможность эффективно управлять.
В манере говорить проявляется профессиональная грамотность, общая культура и нравственный облик руководителя. Благоприятное
 
* 45.97% 14/32
* 2008/07/05 19:35
Набор серебряных пуль.docx/
 
если не доверяешь людям, которые участвуют в проекте, то лучше вообще не начинать такой проект. Поэтому, лучше дать людям власти столько, сколько они смогут «унести». В конечном счете, если кто-то не справится с работой, его всегда можно уволить.
 
* 52.82% 17/32
* 2008/07/05 19:37
Набор серебряных пуль.docx/
 
Поэтому, я считаю, что нужно ставить перед собой реальные цели и каждую минуту работать над её достижением. К сожалению, постоянное отсутствие свободного времени приводит к тому, что главным (а зачастую и единственным) местом для повышения своей квалификации и развития является рабочее место.
Работодатель должен (несмотря на кажущуюся убыточность вложений на «быстрый» Интернет, новые книги, курсы и даже поездки на конференции типа PDC — см. статью «Формула успеха»,
 
* 54.21% 17/32
* 2008/07/05 19:37
Набор серебряных пуль.docx/
 
Автор Eric Sink, Перевод: Лев Курц) обеспечить рост (профессиональный, карьерный) своих сотрудников. В конечном счете, все остаются в выигрыше — сотрудник становится более удовлетворенным работой, а организация получает более профессиональные кадры.
Конечно, возрастает риск потерять работника, ставшего «более квалифицированным», чем требуют его должностные обязанности.
 
* 55.04% 17/32
* 2008/07/05 19:37
Набор серебряных пуль.docx/
 
«НЕ РАБОТАЙТЕ С НАЧАЛЬНИКОМ, КОТОРЫЙ АКТИВНО ПРЕПЯТСТВУЕТ ВАШЕМУ ПОСТОЯННОМУ ОБУЧЕНИЮ. НИ В КОЕМ СЛУЧАЕ».
 
* 58.13% 18/32
* 2008/07/05 19:38
Набор серебряных пуль.docx/
 
Коммуникация
Очень многое в проекте зависит от скорости и способов передачи информации. Конечно, хотелось бы (как того требует методология XP) наличия единой комнаты (deathmatch room), в которой бы бок о бок находились бы все разработчики, совместно с представителем заказчика, и никто кроме них. Однако, в большинстве случаев это невозможно (не собираться же, в самом деле, всем разработчикам
 
* 62.45% 20/32
* 2008/07/05 19:39
Набор серебряных пуль.docx/
 
Первое правило планирования — используйте его, каким бы бессмысленным оно вам не казалось.
 
* 64.98% 21/32
* 2008/07/05 19:39
Набор серебряных пуль.docx/
 
Цель планирования — «Знать, на сколько проект отстаёт и вовремя перераспределить задачи, чтобы пусть и с меньшей функциональностью, но уложиться в график» — см. книгу «Чтобы было яснее», ThoughtWorks , Мартин Фаулер.
 
* 80.72% 26/32
* 2008/07/05 19:43
Набор серебряных пуль.docx/
 
важно для морального духа команды иметь «перед глазами» информацию о текущем прогрессе каждого элемента проекта.
 
* 82.76% 26/32
* 2008/07/05 19:43
Набор серебряных пуль.docx/
 
Ничего не убивает так быстро активность и оптимизм команды, как отсутствие ясной и реально достижимойцели в заданные сроки.
 
* 89.84% 29/32
* 2008/07/05 19:45
Набор серебряных пуль.docx/
 
Однако, смысл в том, что постоянное перенапряжение вредно. Лучше каждый день быть производительным на все 100%, чем в понедельник работать до 22:00, а в течение остальной недели проявлять активность дохлой рыбы на солнцепеке.
 
* 90.51% 29/32
* 2008/07/05 19:45
Набор серебряных пуль.docx/
 
Многие проблемы решаются быстрее (во всяком случае, не кажутся такими страшными), если предварительно хорошо отдохнуть.
 
* 90.88% 29/32
* 2008/07/05 19:45
Набор серебряных пуль.docx/
 
Я знаю, что на данный момент я обладаю некоторой квалификацией. Я уверен, что завтра (после прочтения каких-то книг, статей, форумов в Интернете) моя квалификация повысится. Поэтому иногда, вместо настойчивости в желании «выловить последний баг», лучше отложить проблему. На следующий день она решится гораздо проще.
 
* 98.98% 32/32
* 2008/07/05 19:47
Набор серебряных пуль.docx/
 
Может дело в моей лени или плохой памяти, но мне действительно нравиться фиксировать принятые соглашения по архитектуре или особенностям алгоритма. Это позволяет быстро вникнуть в конкретные детали реализации, без её кропотливого анализа (лень) или быстро вспомнить о принятых решениях после бурно проведённых выходных (память).
Наличие качественной документации — гарантия устойчивости проекта (не будет мест, понятных только одному разработчику). Она дисциплинирует как этапы
 
* 100.00% 32/32
* 2008/07/05 19:47
Набор серебряных пуль.docx/
 
разработки (чтобы выложить мысли на бумаге, придется «причесать» их в понятный всем вид), так и облегчает процесс сопровождения (работники службы поддержки — чаще всего не первоначальные разработчики, и без документации им будет совсем плохо).
 
* 18.57% 3/18
* 2008/07/05 19:52
Непрофессиональные проблемы тестирования в постсоветском государстве.docx/
 
Руководителю следует не стесняясь сказать об этом коллективу. Приведу пример из собственной практики. Когда я работал в молодой компании, в один прекрасный день наш руководитель всех собрал и объявил, что в компании осталось денег ровно на полтора месяца. Если мы не найдем заказчика(ов) в течении этого времени то компания будет закрываться. Мы все получили право на поиск работы и поездки на собеседования, однако все работали до последнего. Заказчика мы нашли и эта компания успешно работает
 
* 21.05% 3/18
* 2008/07/05 19:53
Непрофессиональные проблемы тестирования в постсоветском государстве.docx/
 
Тут Вы узнаете истинный дух компании, и увидите на кого можно положиться.
 
* 33.23% 6/18
* 2008/07/05 19:55
Непрофессиональные проблемы тестирования в постсоветском государстве.docx/
 
Вы страдаете от того, что разработка ведется «из рук вон» плохо, тогда Вам стоит пообщаться с руководителем проекта и директором НЕМЕДЛЕННО. Сразу как только появляются проблемы. Не накапливайте их. Вам необходимо описать Ваши проблемы. Сразу оговорюсь, не стоит описывать проблемы в других отделах.
 
* 91.37% 17/18
* 2008/07/05 20:05
Непрофессиональные проблемы тестирования в постсоветском государстве.docx/
 
Подводя итоги, можно посоветовать «нашим» руководителям чаще общаться с подчиненными. Быстро реагировать на письма, в которых изложены опасения, или явные выводы, о плохой проверке качества продуктов или нездоровой атмосфере в коллективе. Не бояться говорить о трудностях в компании.
А «наши» тестировщики должны чаще смотреть на себя, и общаться по своим вопросам с руководством, прежде чем жаловаться и ругаться на весь мир. Не все проблемы, которые на них сваливаются,
 
* 12.26% 1/13
* 2008/07/07 10:21
Одна аватара сказала.docx/
 
Как создаются слухи
Двигатель вирусного маркетинга — это слух. Именно правильно созданный и запущенный слух будет передаваться из уст в уста. Слух должен интересовать целевую аудиторию и не восприниматься как чистая реклама. Только в этом случае его охотно подхватят потребители.
Идеальная среда для распространения искусственно созданных слухов — Интернет и узкие сообщества (например, клубная тусовка ). Интернет в данном случае — безусловный лидер. Слухи (они же
 
* 15.92% 2/13
* 2008/07/07 10:21
Одна аватара сказала.docx/
 
«вирусы») прекрасно распространяются по форумам, блогам , ЖЖ, сайтам, где активно происходит неформальное общение (например, различные варианты «одноклассников»). Внедрение слуха обходится в смехотворные деньги, так как для этого нужны всего один-два человека — завсегдатаи этих сайтов. Они легко запустят рекламную информацию в свое сообщение, и это уже будет не «навязывание товара», а «рекомендация друга». Таким образом можно отлично продвигать новинки и анонсировать события, создавая
 
* 19.19% 2/13
* 2008/07/07 10:22
Одна аватара сказала.docx/
 
создавая ажиотаж. Тогда сообщение будет строиться по типу: «А ты слышал, что скоро появится в продаже новая модель…» или «Говорят, что открывается новый крутой клуб…» Единственное требование к запуску слухов (помимо их интересности с обывательской точки зрения) — это то, что его «источник» не должен быть новичком на сайте, иначе в сообщении сразу угадают рекламу, что вызовет негатив у пользователей.
 
* 54.66% 7/13
* 2008/07/07 12:32
Одна аватара сказала.docx/
 
Другими менее яркими звездами, но более эффективными «вирусоносителями» вашего бренда могут стать редакторы изданий, доктора наук и доценты, журналисты, ди-джеи, ведущие различных программ и т. п. Если каким-то образом склонить их на сторону своего бренда, то он появится в статьях или даже будет презентован на тематических конференциях и семинарах. При этом можно просто заплатить за то, чтобы «звезды» продвигали ваш продукт, а можно пойти иным путем, воздействующим на лидеров мнений
 
* 60.62% 8/13
* 2008/07/07 12:33
Одна аватара сказала.docx/
 
Кроме того, к лидерам мнений в профессиональной среде можно отнести, скажем, участковых врачей.
 
* 83.69% 11/13
* 2008/07/07 14:25
Одна аватара сказала.docx/
 
действительно захватывающим языком, избегайте явно рекламного слога и призывов к немедленному приобретению. Информация должна запоминаться и рождать желание кому-то еще ее передать. Лидерам мнений нужны факты, технические характеристики и подобная информация, а не красивые слоганы .
 
* 95.75% 13/13
* 2008/07/07 14:26
Одна аватара сказала.docx/
 
Обратите внимание в Интернете на вопросы о вашей продукции (например, на сайтах по воспитанию детей обсуждаются подгузники, детское питание, игрушки, на сайтах по домоводству — продукты питания, моющие средства и т. п.). Незамедлительно предоставляйте требуемую информацию, причем лучше всего как «простой советчик», нежели производитель.
 
* 10.46% 1/9
* 2008/07/08 00:06
Опыт прохождения сертификации PMI.docx/
 
кодекса этики менеджера проекта Code of Conduct (http://www.pmi.org/membership/standards/ethical.htm ).
 
* 32.55% 3/9
* 2008/07/08 00:08
Опыт прохождения сертификации PMI.docx/
 
www.pmprepare.com. На сайте Вы получаете доступ к базе данных вопросов, идентичных тем, что будут на экзамене.
 
* 37.35% 2/7
* 2008/07/08 12:06
Основы управления проектами.docx/
 
1. Проанализируй задачу и составь планВажен именно такой порядок: сначала анализировать, затем планировать —
 
* 43.28% 3/7
* 2008/07/08 12:06
Основы управления проектами.docx/
 
более глубокое понимание задачиИногда повторное чтение письма от босса помогает обратить внимание на ряд вопросов, требующих обсуждения.
решение может оказаться ближе, чем казалосьМногие задачи выглядят чрезвычайно сложными, но стоит потратить пару минут на чтение — и ты уже видишь, что из двухстраничного плана лично тебе нужно сделать лишь несколько простых задач.
2. Не усложняй сверх мерыНикогда не начинай планирование с ошибочных предположений о
 
* 49.47% 3/7
* 2008/07/08 12:06
Основы управления проектами.docx/
 
каком-либо этапе проекта. Планирование — не тот процесс, при котором нужно обсуждать плюсы и минусы конкретной реализации.
Твоя цель — получить в итоге план проекта. Для выполнения задач нужен именно план, а не список причин, по которым достижение твоих целей решительно невозможно.
Не пытайся быть проницательным и оригинальным — время для этого ещё наступит.
 
* 59.39% 4/7
* 2008/07/08 12:07
Основы управления проектами.docx/
 
3. Планируй шаг за шагомКогда первоначальное планирование готово, пора начинать проект. Определи первые шаги — и вперёд.
Делай за раз что-нибудь одно и уделяй особое внимание тому, чтобы каждая выполненная задача имела своё место в общей картине
 
* 64.72% 4/7
* 2008/07/08 12:07
Основы управления проектами.docx/
 
и приближала тебя к завершению проекта. Если что-то кажется неправильным — скорее всего, так и есть. Может быть, задачи следует перегруппировать.
Запомни: при большом количестве проектов нельзя создать подробный план без первоначального анализа и подготовительной работы. Это значит, что если план оказался небезупречным, нужно просто поработать над ним ещё — совсем не обязательно объявлять его неверным и начинать заново.
4. Регулярно следи за продвижениемЭто одна из самых важных
 
* 71.15% 5/7
* 2008/07/08 12:07
Основы управления проектами.docx/
 
вещей в управлении проектами — нужно выработать привычку делать регулярный и тщательный обзор продвижения работы.
 
* 89.80% 6/7
* 2008/07/08 12:08
Основы управления проектами.docx/
 
Сделав обзор проекта, внеси в план необходимые изменения. Не стоит испытывать вину по этому поводу!
Перемены — к лучшему! Это те самые подробности и детали, которые необходимо внести в проект, чтобы он был успешным.
 
* 56.23% 10/18
* 2008/07/09 14:20
Оценка персонала.docx/
 
В рамках программ развития сотрудников проводится так называемая оценка по методу "360 градусов". Данный вид оценки используется и для улучшения внутренней коммуникации, развития корпоративной культуры. Это взгляд на сотрудника с разных сторон. Информацию получают путем беседы с самим сотрудником, его непосредственным руководителем, коллегами, подчиненными, а в отдельных случаях и клиентами оцениваемого. Такая оценка может проводиться для менеджеров среднего звена, руководителей
 
* 58.93% 10/18
* 2008/07/09 14:20
Оценка персонала.docx/
 
руководителей команды или проекта, а также тех, кто работает с внешними и внутренними клиентами.
 
* 61.65% 11/18
* 2008/07/09 14:21
Оценка персонала.docx/
 
Еще одним методом оценки являются личностные опросники. Только в руках обученного и опытного специалиста тесты служат инструментом, дающим возможность проанализировать и спрогнозировать поведение человека в различных ситуациях.
 
* 65.94% 12/18
* 2008/07/09 14:21
Оценка персонала.docx/
 
Проведение тестирования не такая уж простая задача, как кажется на первый взгляд. Человека нужно мотивировать, снять эмоциональную напряженность, соблюсти все условия и стандарты процедуры тестирования. Без этого нельзя получить достоверный результат.
 
* 85.97% 15/18
* 2008/07/09 14:24
Оценка персонала.docx/
 
Причина отказа . Иногда результаты оценки используются для того, чтобы упростить процедуру отказа кандидату: "Вы не прошли тест" - и все.
 
* 23.60% 4/17
* 2008/07/09 14:33
Перспективы WorkFlow.docx/
 
наследниками бумажного документооборота. Отсюда и их естественные ограничения: с документом можно совершить ограниченный набор действий: одобрить/отказать, визировать, удалить, внести правку и т. п. Обычно системы документооборота дополняются системами хранения образов бумажных документов и системами версионного контроля. Основным преимуществом систем документооборота является возможность их быстрого внедрения на предприятии, если там уже на хорошем уровне налажен документооборот.Для
 
* 92.92% 16/17
* 2008/07/09 17:41
Перспективы WorkFlow.docx/
 
(решая задачу А).Менеджеры, как известно, должны иметь три основные компетенции:1. Натуру лидера;2. Умение строить бизнес-процесс;3. Знание предметной областиWF-системы позволяют поставить на системную основу развитие второй компетенции. WF-система не решит всех проблем, но позволит менеджменту предприятия действовать в единой процессной парадигме и проводить реинжиниринг в сжатые сроки. Это даст предприятию серьезные конкурентные преимущества на динамичных рынках.
От
 
* 1.84% 1/79
* 2008/07/09 17:43
Правила Ашманова.docx/
 
Первое правило Ашманова. Не бывает технических проблем. Бывают только человеческие, то есть организационные.
 
* 4.15% 3/79
* 2008/07/09 17:45
Правила Ашманова.docx/
 
разработке программного обеспечения
Миф об уникальной специфике программного обеспечения. Производство программного обеспечения не является особым бизнесом, что бы там ни говорили сами разработчики или продавцы информационных систем. Оно не более особенное, чем пищевая промышленность или косметология. Законы развития и окупаемости проектов при разработке ПО, интернет-сайтов и корпоративных информационных систем — те же самые, что и везде.
 
* 4.22% 3/79
* 2008/07/09 17:45
Правила Ашманова.docx/
 
Миф об уникальной специфике программного обеспечения. Производство программного обеспечения не является особым бизнесом, что бы там ни говорили сами разработчики или продавцы информационных систем. Оно не более особенное, чем пищевая промышленность или косметология. Законы развития и окупаемости проектов при разработке ПО, интернет-сайтов и корпоративных информационных систем — те же самые,
 
* 4.88% 3/79
* 2008/07/09 17:45
Правила Ашманова.docx/
 
Миф о невероятной сложности программирования. На самом деле процесс создания современной программы не сложнее и не более творческий, чем процесс создания современного автомобиля, рекламного ролика или лекарства. В этих индустриях давно наведен порядок, не мешающий творчеству.
Миф о величии программиста. Разработчик программного обеспечения — не оракул, прорицания
 
* 5.51% 4/79
* 2008/07/09 17:46
Правила Ашманова.docx/
 
программист выглядит, как взрослый, умный и ответственный человек — он высокообразован, занимается сложной умственной работой, владеет терминологией, умеет поставить задачу и обосновать запрос на выделение ресурсов. При этом на деле он постоянно проявляет себя как малолетний двоечник — не говорит всей правды, ошибается со сроками, срывает проекты, сворачивает с прямого пути и развлекается за счет работодателя.
Если в проекте разработчики играют первую скрипку, вероятность
 
* 6.46% 5/79
* 2008/07/09 17:46
Правила Ашманова.docx/
 
Нужно помнить, что разработчик ПО — это инженер, а в бизнесе высоких технологий выигрывают не инженеры, а бизнесмены и менеджеры. Как и везде.
Миф о магической силе технологии. Новая, сложная, впечатляющая технология не обязательно приведет к успеху.
 
* 8.13% 6/79
* 2008/07/09 17:47
Правила Ашманова.docx/
 
Правило 3. Разработчики всегда называют неверные сроки.
Нельзя верить срокам, которые называют программисты. Обычно их следует умножать на Пи. Иногда (редко) — делить на Пи. Выбор правильного действия руководителя над называемыми сроками зависит от личности разработчика. Это знание приходит к менеджеру только после нескольких экспериментов именно с этим разработчиком.
 
* 8.42% 6/79
* 2008/07/09 17:48
Правила Ашманова.docx/
 
Правило 4. Разработчику свойственен врожденный оптимизм.
 
* 9.12% 7/79
* 2008/07/09 17:48
Правила Ашманова.docx/
 
Правило 5. Программист испытывает страсть к обобщению.
 
* 10.78% 8/79
* 2008/07/09 17:49
Правила Ашманова.docx/
 
теоретически неправильно и практически вредно для бизнеса. Нужно делать так, чтобы всё работало, удовлетворяло клиентов (ровно на уровне цены продукта) и бизнес развивался.
Верный признак работы в стиле «по-хорошему» — упорная работа с «ядром», задержки с реализацией конкретной запланированной функциональности и срыв сроков выхода продукта.
Правило 7. Приминание травы может отнять любое количество времени.
Программист всегда стремится
 
* 11.92% 9/79
* 2008/07/09 17:49
Правила Ашманова.docx/
 
Правило 8. Разработчик не интересуется бизнесом, он — типичный автор.
Разработчик в среднем не стремится помочь организовать и развить бизнес, именно поэтому он не любит тестирования, считает пользователей идиотами, поэтому его трудно заставить документировать и поддерживать уже сделанные системы и программы.
Истинные личные мотивы большинства разработчиков — авторские , то есть включают интересную работу, хорошие гонорары и известность. Низовой разработчик
 
* 23.03% 18/79
* 2008/07/09 17:54
Правила Ашманова.docx/
 
I. Как правильно запустить проект и закончить его
Решение о запуске проекта должны принимать ответственные лица.
Для начала проекта нужно исполнить процедуру запуска проектов.
Без энтузиаста любой проект мертв.
Проект нельзя обсуждать без обоснования.
Не бывает проекта без руководителя.
Руководитель должен быть
 
* 23.44% 18/79
* 2008/07/09 17:54
Правила Ашманова.docx/
 
один.
Проект нельзя запускать без плана, написанного лично руководителем проекта.
Проект нельзя запускать без ресурсов.
В начале проекта всегда бывает естественное торможение. Чтобы его преодолеть, нужны терпение и настойчивость.
Вполнакала проекты не делаются.
Только коррекцией в контрольных
 
* 23.78% 18/79
* 2008/07/09 17:54
Правила Ашманова.docx/
 
контрольных точках можно удержать проект от срыва.
По окончании проекта нужно правильно переключить ответственность.
После завершения проекта нужно запустить следующий «бессрочный» проект — проект поддержки.
II. Неправильный проект и его лечение
Риск неудачи проекта есть всегда.
 
* 24.20% 19/79
* 2008/07/09 17:54
Правила Ашманова.docx/
 
Важно вовремя узнать «паттерн» неудачного проекта — симптомы надвигающейся болезни.
Когда в проекте что-то идет не так, начальство предпринимает титанические бесполезные усилия по наведению порядка.
Бессмысленно муштровать исполнителей, нужно муштровать менеджеров.
Наведение порядка в проекте всегда должно начинаться с головы.
 
* 53.10% 42/79
* 2008/07/10 10:30
Правила Ашманова.docx/
 
Температура горения
Я глубоко убежден, что сделать проект с командой, работающей на полставки и думающей о проекте «на полставки» — нельзя. Здесь вопрос даже не в количестве рабочего времени в неделю, а в эмоциональной вовлеченности. Кто-то в проекте должен занять проектом свою голову и сердце на 100%. Лучше, чтобы это был руководитель проекта, но может быть и его заместитель, или главный разработчик.
Только в этом случае можно обеспечить необходимый энтузиазм,
 
* 54.29% 42/79
* 2008/07/10 10:31
Правила Ашманова.docx/
 
Контрольные точки должны быть сразу внесены в планы проекта.
Контрольные точки служат для того, чтобы оценить, идет ли проект как запланировано, или имеются проблемы. Дальше требуется принять решение - продолжить работу по плану или вносить коррективы (в планы, в объем выделенных ресурсов, структуру руководства).
 
* 59.51% 47/79
* 2008/07/10 11:26
Правила Ашманова.docx/
 
что на каждой большой стройке они оставляют по человеку (который разбивается). В разработке ПО ситуация чем-то схожая — руководитель проекта должен помнить о том, что если проект важный и развивающийся, кто-то из рабочей группы так и останется постоянно привязанным к нему — всегда будет требоваться поддержка и развитие.
Незаметная рутинная возня с уже выпущенным проектом будет постоянно отнимать время и силы. Обычно этот факт выпускается из виду и поддержка не учитывается
 
* 60.99% 48/79
* 2008/07/10 11:27
Правила Ашманова.docx/
 
Правило 13. После завершения проекта нужно запустить следующий «бессрочный» проект — проект по поддержке.
Проект по поддержке должен иметь все признаки проекта: ответственный руководитель, планы, ресурсы и т. п. Отличия срочных проектов от бессрочных - тема для отдельного разговора.
 
* 82.14% 65/79
* 2008/07/10 14:08
Правила Ашманова.docx/
 
Правило 16. Когда в проекте что-то идет не так, начальство предпринимает титанические бесполезные усилия по наведению порядка.
 
* 82.36% 65/79
* 2008/07/10 14:08
Правила Ашманова.docx/
 
Контроль посещаемости
 
* 83.75% 66/79
* 2008/07/10 14:09
Правила Ашманова.docx/
 
Волна контроля посещаемости иссякает примерно через одну-две недели, максимум месяц.
Контроль количества работы
 
* 84.28% 66/79
* 2008/07/10 14:09
Правила Ашманова.docx/
 
Пятничные отчеты начинают писаться (руководитель проекта упросил всех поддаться), но их перестают читать наверху через пару недель, а писать внизу — через месяц-полтора.
Правила внутреннего распорядка
 
* 85.04% 67/79
* 2008/07/10 14:10
Правила Ашманова.docx/
 
Планы и отчетность
Планомания быстро
 
* 86.51% 68/79
* 2008/07/10 14:10
Правила Ашманова.docx/
 
Начинают появляться варианты нового расчета зарплаты: например, предлагается разбить зарплату на три части — базовый минимум, потом довесок за исполнение проекта в срок, потом — премия за досрочное исполнение. (В первой части я уже объяснял, почему штрафовать программистов абсолютно бессмысленно.) Еще одна очень популярная бесперспективная идея — начать платить программистам процент с продаж вместо части оклада или вообще разрешить им чем-то там торговать, привлекать заказы, а менеджеру
 
* 87.09% 68/79
* 2008/07/10 14:11
Правила Ашманова.docx/
 
Комсомольские накрутки и политинформации
 
* 87.66% 69/79
* 2008/07/10 14:11
Правила Ашманова.docx/
 
Адамса про бедного разработчика Дилберта и его глупого босса (http://www.dilbert.com), так что опустим подробности.
 
* 88.25% 69/79
* 2008/07/10 14:12
Правила Ашманова.docx/
 
Закручивание гаек не работает
 
* 89.04% 70/79
* 2008/07/10 14:12
Правила Ашманова.docx/
 
Правило 17. Бессмысленно муштровать исполнителей, нужно муштровать менеджеров.
Это правило легко доказать следующим рассуждением:
а) Плохой исполнитель и хороший менеджер. Если в проекте оказываются вместе внятный и ответственный руководитель и неквалифицированный или ленивый исполнитель, первый моментально постарается уволить или удалить второго - чтобы не нести за него ответственности. И это правильно.
Поэтому ситуация с хорошим
 
* 96.15% 76/79
* 2008/07/10 14:16
Правила Ашманова.docx/
 
Принцип списания всех убытков и долгов очень важен для того, чтобы запустить новый проект. Если об этом не объявить сразу, старые обиды и амбиции заразят новый проект еще в утробе.
 
* 96.68% 76/79
* 2008/07/10 14:17
Правила Ашманова.docx/
 
Правило 19. После разбора полетов нужно списать все долги и запустить проект заново.
Перезапуск проекта
 
* 20.52% 6/33
* 2008/07/11 00:24
Применение стандартов профессиональных ассоциаций на разных этапах реализации проекта.docx/
 
Содержание стандартов ассоциации
Инициация проекта, планирование проекта, исполнение проекта, контроль проекта, завершение проекта, профессиональная ответственность
Объекты управления, субъекты и инструментарии управления, процессы управления, история и тенденции развития управления проектами
Экономический анализ, разработка прогноза затрат, проектное управление (теория управления, теория мотивации, общий контроль
 
* 21.86% 7/33
* 2008/07/11 00:24
Применение стандартов профессиональных ассоциаций на разных этапах реализации проекта.docx/
 
контроль проекта, планирование и разработка расписания, контроль качества, управление ресурсами, управление контрактами, социальные и правовые вопросы управления проектами),
вспомогательные дисциплины (исследование операций, математическая статистика, основы финансов, инфляция)
Финансовый учет, управленческий учет, финансовая отчетность, корпоративное законодательство, организационный менеджмент, стратегия бизнеса, финансовая и информационная стратегия
Финансовый
 
* 23.09% 7/33
* 2008/07/11 00:24
Применение стандартов профессиональных ассоциаций на разных этапах реализации проекта.docx/
 
Финансовый анализ, макро- и микроэкономика, инвестиционный анализ, корпоративные финансы, финансовые рынки и инструменты
Экономический анализ, финансовый учет, управленческий учет, стратегический менеджмент, организационное управление
Математика и статистика, оценка и управление стоимостью, бухгалтерский учет, организационное управление
Границы применимости стандартов ассоциации
Управление проектом на инвестиционной
 
* 24.27% 8/33
* 2008/07/11 00:24
Применение стандартов профессиональных ассоциаций на разных этапах реализации проекта.docx/
 
инвестиционной стадии (инициация, планирование, выполнение, завершение)
Управление проектом на инвестиционной стадии (инициация, планирование, выполнение, завершение)
Управление стоимостью проекта на прединвестиционной и инвестиционной стадии проекта.
Управление проектом на инвестиционной стадии (инициация, планирование, выполнение, завершение)
Управление стоимостью проекта на всех стадиях жизненного
 
* 25.38% 8/33
* 2008/07/11 00:24
Применение стандартов профессиональных ассоциаций на разных этапах реализации проекта.docx/
 
цикла проекта: прединвестиционной, инвестиционной и эксплуатационной
Управление стоимостью проекта на всех стадиях жизненного цикла проекта: прединвестиционной, инвестиционной и эксплуатационной
Управление стоимостью проекта на всех стадиях жизненного цикла проекта: прединвестиционной, инвестиционной и эксплуатационной
Управление стоимостью проекта на прединвестиционной и инвестиционной стадии проекта.
Управление
 
* 29.25% 9/33
* 2008/07/11 00:25
Применение стандартов профессиональных ассоциаций на разных этапах реализации проекта.docx/
 
www.pmi.org , www.pmi.ru , www.sovnet.ru , www.ipma.ch , www.aacei.org , www.cimaglobal.com . Также в качестве источника информации о сертификациях в сфере управления стоимостью был использован сайт www.gaap.ru.
С более подробной
 
* 30.27% 10/33
* 2008/07/11 00:25
Применение стандартов профессиональных ассоциаций на разных этапах реализации проекта.docx/
 
ими сертификациях AIMR (CFA), IMA (CMA, CFM) и SCEA (CCE/A) можно ознакомиться на официальных сайтах этих организаций: www.aimr.org , www.imanet.org , www.sceaonline.net .
 
* 51.15% 17/33
* 2008/07/11 10:21
Применение стандартов профессиональных ассоциаций на разных этапах реализации проекта.docx/
 
В IPMA существует 4 уровня сертификации. Полное прохождение сертификации предполагает последовательно прохождение всех уровней: от D до A.
Уровень D. Certificated Project Management Specialist (CPMS), или Сертифицированный специалист по управлению проектами.Уровень C. Registered Project Management Professional (RPMP), или Сертифицированный Профессионал по Управлению Проектами.Уровень B. Certificated Project Manager (CPM), или Сертифицированный управляющий проектами.Уровень А.
 
* 15.93% 3/19
* 2008/07/11 13:21
Программы мотивации в проектно.docx/
 
1) цели программы мотивации (к чему должна стимулировать программа мотивации);2) охват (категории сотрудников и проектов, к которым применяется программа мотивации);3) срок действия (например, полгода или год);4) критерии, процедуры оценки и ответственные за оценку поведения для различных категорий сотрудников;5) поощрения за надлежащее и взыскания за ненадлежащие поведение;6) календарный план мероприятий программы мотивации;7) ответственность за выполнение мероприятий программы
 
* 18.09% 3/19
* 2008/07/11 13:22
Программы мотивации в проектно.docx/
 
программы мотивации; 8) бюджет программы мотивации.
 
* 25.64% 5/19
* 2008/07/11 13:24
Программы мотивации в проектно.docx/
 
проектно-ориентированной организации (или рассматриваемой в таком ключе ИТ-службе предприятия) следующие роли:
сотрудник, отвечающий за выполнение только своей задачи, поставленной ему руководителем проекта;
технический лидер, отвечающий в проекте за ключевые технические решения;
руководитель проекта, отвечающий за выполнение проекта;
директор проектов, отвечающий за весь портфель проектов и распоряжающийся ресурсами.
Мотивация
 
* 11.74% 1/11
* 2008/07/13 00:35
РИСК ПРОЕКТА И РИСК ПРОДУКТА.docx/
 
Риск должен устраняться там, где он был выявлен.
 
* 17.20% 1/11
* 2008/07/13 00:35
РИСК ПРОЕКТА И РИСК ПРОДУКТА.docx/
 
2 вида риска: риск проекта и риск продукта. Первый влияет на реализацию проекта, второй связан с продуктом, который, предположительно, будет получен в результате реализации проекта.
 
* 56.87% 6/11
* 2008/07/13 00:38
РИСК ПРОЕКТА И РИСК ПРОДУКТА.docx/
 
продукта наиболее вероятно на этапе построения – это обычно ошибки дизайна, неблагоприятные погодные условия или ошибки поставщика.
 
* 35.42% 3/9
* 2008/07/13 17:15
Связь управления проектами со стратегией организации.docx/
 
И в управлении проектами принято отделять рамки проекта (project scope) от рамок продукта (product scope). Под рамками продукта понимаются характеристики продукта проекта, а под рамками проекта – тот объем работ, который необходимо выполнить для получения продукта. Соответственно, оценивая, успешен или неуспешен проект, стоит разделять успешность продукта и успешность проекта.
 
* 25.40% 4/17
* 2008/07/13 19:46
Технологическая архитектура бизнеса.docx/
 
Какое отношение к бизнесу имеет ИТ–архитектура? Самое непосредственное: она может помогать или препятствовать запуску новых процессов и продуктов и созданию новых каналов. Проблемы, вызванные несовершенством ИТ–архитектуры, особенно заметны в банковской сфере, логистике и телекоммуникациях, где успех бизнеса напрямую зависит от информационных технологий. Во многих банках, к примеру, ИТ–подразделения не в состоянии поддерживать мультиканальные системы, поскольку
 
* 39.70% 6/17
* 2008/07/13 19:48
Технологическая архитектура бизнеса.docx/
 
Некоторые компании пробовали решить проблемы ИТ–архитектуры, заменяя сразу все ее ключевые элементы. В качестве примера можно привести внедрение ERP–систем [2] — монолитных, интегрированных приложений, которые, как правило, заменяют разрозненные программы для управления персоналом, операционной деятельностью, бухгалтерией и цепочкой поставок.
 
* 73.95% 12/17
* 2008/07/13 19:52
Технологическая архитектура бизнеса.docx/
 
Несколько сот стандартизированных бизнес–сервисов могут заменить десятки тысяч интерфейсов, которые приходилось каждый раз создавать заново, чтобы установить связь между приложениями и базами данных. У сервисов есть большое преимущество как для бизнес–подразделений, так и для ИТ–служб: обычно их настраивают один раз, они доступны для всех доменов и предотвращают дублирование. Из–за этого сокращаются издержки, вся ИТ–система упрощается, а бизнес становится более гибким. Сервисы позволяют разделить
 
* 76.75% 13/17
* 2008/07/13 19:52
Технологическая архитектура бизнеса.docx/
 
разделить преобразования в бизнесе и технологические преобразования: они отражают стабильные взаимосвязи между доменами и обычно не изменяются, даже если в пределах домена и приходится иногда корректировать, а то и полностью обновлять ИТ–системы (в результате, например, слияния). И поэтому ИТ–специалисты в рамках домена могут переналаживать ИТ–систему, не пересоединяя сотни интерфейсов к другим системам.
 
* 30.60% 2/8
* 2008/07/17 16:16
Стратегический Навигатор.docx/
 
 
1. Наносим стратегию на карту.
2. Декомпозируем цели на подразделения компании/холдинга.
3. Прописываем процессы измерения показателей.
4. Привязываем мотивацию к показателям эффективности.
5. Работаем в соответствии с поставленными целями и стратегией и через показатели эффективности получаем обратную связь о правильности курса.
6. Реагируем на возникающие отклонения управленческими решениями оперативного, структурного, организационного характера.
 
* 41.40% 3/7
* 2008/07/23 15:34
Управление проектами в И1.docx/
 
Microsoft Project предлагает менеджеру проекта заманчивый инструментарий для рисования календарных планов, особенно замечателен инструмент auto-leveling – используйте его только если вам нужно соорудить красивую презентацию, но никак не для формирования реальных планов. Выставлять проценты выполнения элементарных задач также не следует – задача или выполнена, или нет, для руководителя проекта не существует промежуточного состояния «выполнена на сколько-то процентов». Однако деинсталлировать
 
* 47.60% 3/7
* 2008/07/23 15:34
Управление проектами в И1.docx/
 
деинсталлировать Microsoft Project не обязательно – он может пригодиться для оформительских работ.
Для начала договоритесь с вашим руководством о том, что вы работаете по контрольным точкам – это развяжет вам руки в плане оперативного переназначения работ. Далее, выделите ключевую функциональность системы, которая должна быть реализована во что бы то ни стало, основанием для этого может служить ответ на вопрос «останется ли разрабатываемая система собственно системой без этой функции», примененный
 
* 70.95% 3/5
* 2008/07/23 21:17
Управление проектами в ИТ.docx/
 
Мы рассмотрели возможные последствия развития ситуации в условиях возникновения технической проблемы в проекте. Что можно сделать, чтобы избежать начавшегося торможения проекта и возниконовения последующих проблем? В данной ситуации приветствуется любая деятельность, направленная на преодоление пробуксовки проекта – здесь важно понимать что бездействие недопустимо. Даже неверное решение менеджера проекта теперь будет лучше чем никакого решения. Самым простым и возможно
 
* 79.87% 4/5
* 2008/07/23 21:20
Управление проектами в ИТ.docx/
 
возможно самым действенным методом будет пересмотр ближайшей цели, и установка на выпуск промежуточной версии включающей проблемную область. Весьма вероятно, это будет единственной целью данной версии – добавить в проект функцию, которая неявно тормозит все остальные работы и пассивно вносит дезорганизующее начало в проектную группу.
Для определения пути выхода из сложной ситуации подходит любой метод решения технических проблем, применяемый в вашей организации или практикуемый
 
* 88.08% 4/5
* 2008/07/23 21:20
Управление проектами в ИТ.docx/
 
вашей командой – экспертный совет, системный анализ, мозговой штурм.
Если копнуть глубже, то может всплыть целый набор проблем, связанных с ошибками проектирования системы. Ну что-ж, чем раньше удастся обнаружить такой набор – тем лучше для проекта в целом.
Нелишне напомнить, что в пробуксовке проекта руководитель проекта может принимать самое активное участие, и вместо концентрации на решении назревающей проблемы, он будет пытаться
 
* 96.88% 5/5
* 2008/07/23 21:20
Управление проектами в ИТ.docx/
 
заниматься текучкой, попадая под описанный ранее эмоциональный фактор влияния неопределенности. Чтобы этого избежать, нужно каждый свой шаг соотносить с общими целями проекта, и задавать самый обыкновенный вопрос управления проектами «этот мой шаг приближает проект к успешному завершению?».
Итог проделанной работы – проект всегда движется в сторону успешного завершения. Могут быть нарушены сроки, может быть перерасходован бюджет, но команда всегда видит цель работы,
 
* 100.00% 5/5
* 2008/07/23 21:20
Управление проектами в ИТ.docx/
 
работы, и не останавливается при возникновении трудностей.
Продолжение следут.
 
* 47.40% 7/16
* 2008/07/25 17:44
Учет рабочего времени.docx/
 
Задача первая — определять, не будет ли превышения бюджета и расписания. Отправной точкой здесь является наличие бюджета и расписания. Они есть у любого проекта, независимо от типа: у типичной заказной разработки — контрактный бюджет и график проекта, у проекта с почасовой оплатой типа «доработка» — бюджет и график этапа\задачи, у проекта типа «поддержка» — объем предоплаченного Клиентом времени в контракте на поддержку. Соответственно, любой проект в системе управления проектами
 
* 50.26% 8/16
* 2008/07/25 17:44
Учет рабочего времени.docx/
 
имеет два параметра — одобренный бюджет, у.е. ( approved budget ) и одобренная длительность, раб. д ней ( approved duration ). Их устанавливает Спонсор проекта — руководитель организации, давший «добро» на начало этого проекта. Эту практику необходимо выработать и неукоснительно соблюдать.
Далее все происходит предельно просто. Менеджер ставит задачи и определяет трудозатраты (work), которые могут потратить исполнители на выполнение этих задач. Исполнители отчитываются
 
* 53.41% 8/16
* 2008/07/25 17:44
Учет рабочего времени.docx/
 
о выполнении задач, при необходимости запрашивая дополнительные трудозатраты. Менеджер с помощью метода под названием «анализ освоенного объема» ( earned value analysis , про него написано достаточно и нет нужды повторяться) рассчитывает два параметра — CPI и SPI ( Cost Performance Index и Schedule Performance Index ). Если они больше единицы — менеджер чуствует себя спокойно. Если они меньше единицы — он напрягается и рассчитывает еще один параметр — EAC ( Estimate at
 
* 56.03% 8/16
* 2008/07/25 17:44
Учет рабочего времени.docx/
 
completion , оценка на завершение). Считает он ее для того, чтобы сравнить с одобренным бюджетом ( approved budget ). Если EAC > Approved budget — то пахнет жареным, это означает, что мы будем иметь превышение бюджета по завершению проекта. Что делать для исправления ситуации — вопрос не по теме данной статьи.
Конечно же, менеджер считает эту информацию не вручную. Для
 
* 76.78% 12/16
* 2008/07/25 17:47
Учет рабочего времени.docx/
 
Определить бюджет и длительность — сделать это правильно в начале проекта и корректировать оценки при изменения предмета и границ проекта.
Ставить задачи — оптимально каждая задача должны быть продолжительностью в день и поставлена в соответствии с критерием SMART — Specific, Measurable, Achievable, Realistic, Time-related.
Контролировать использование бюджета — ежедневно или в крайнем случае еженедельно, собирая отчетность об исполнении задач.
Контроливать исполнение бюджета
 
* 79.72% 12/16
* 2008/07/25 17:47
Учет рабочего времени.docx/
 
бюджета — рассчитывая EAC и сравнивая его с одобренным бюджетом.
 
* 54.76% 3/7
* 2008/07/26 00:17
ФОРМАЛИЗАЦИЯ ИНИЦИАЦИИ КРУПНЫХ ПРОЕКТОВ В ХОЛДИНГОВОЙ КОМПАНИИ.docx/
 
управления (РАЗУ). Упрощенная структура разделов устава может выглядеть следующим образом:
1. Характеристика проекта1.1. Сведения о проекте1.2. Цели проекта1.3. Структура проекта
1.3.1. Общее описание структуры проекта 1.3.2. Реквизиты подпроектов
2. Масштаб проекта
2.1. Участники (группы участников) проекта 2.2. Результаты проекта2.3. Ограничения (условия реализации) проекта
3.
 
* 59.67% 4/7
* 2008/07/26 00:17
ФОРМАЛИЗАЦИЯ ИНИЦИАЦИИ КРУПНЫХ ПРОЕКТОВ В ХОЛДИНГОВОЙ КОМПАНИИ.docx/
 
3. Основные этапы и сроки реализации проекта4. Финансирование проекта5. Организационная структура управления проектом
5.1. Общее описание организационной структуры управления проектом 5.2. Распределение ответственности, функций и полномочий по управлению проектом
6. Процессы управления проектом
 
* 1.92% 0/35
* 2008/07/26 13:23
Эффективное корпоративное управление.docx/
 
планированием ресурсов (enterprise resource planning, ERP), организацией снабжения (supply chain management, SCM) и сбыта (sales force automation, SFA), взаимодействием с клиентами (customer relationship management, CRM), регулированием потребительского спроса (consumer demand management, CDM)



"+":

"-":

вывод:

кратко Эдвард Йордан - Смертельный Марш

source
Описание:

1.1 Определение безнадежного проекта
Под безнадежным проектом (death march) я понимаю такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50%. По отношению к софтверным проектам это обычно означает одно или более из следующих ограничений:
План проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; таким образом, проект, требующий в нормальных условиях 12 календарных месяцев, приходится
выполнять за 6 или менее месяцев. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной.
Количество разработчиков уменьшено более чем наполовину по сравнению с действительно необходимым для проекта данного размера и масштаба; таким образом, вместо формирования проектной команды из десяти человек, менеджера проекта убеждают, что достаточно и пяти. Такое представление может быть результатом наивной веры в магические возможности новых CASE-средств
CASE-средств или языков программирования удваивать производительность труда разработчиков - несмотря на то, что разработчики не обучались или не имеют практического опыта работы с новой технологией и, скорее всего, с ними никто не советовался по поводу решения использовать новую технологию. На сегодняшний день более общей причиной уменьшения количества разработчиков является сокращение штатов компании в результате реорганизации, реинжиниринга и т.д.
Бюджет и связанные с ним
ресурсы урезаны наполовину. Зачастую это результат сокращения компании и других противозатратных мер, хотя это может быть и результатом конкурентной борьбы за выгодный контракт. В этой ситуации менеджер проекта в консалтинговой фирме получает из отдела маркетинга следующую информацию: «У нас хорошая новость - мы выиграли тендер, но есть и плохая новость - мы были вынуждены наполовину урезать бюджет, чтобы победить конкурентов». Такое ограничение часто непосредственно влияет на количество
Требования к функциям, возможностям, производительности и другим техническим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях. Например, проектной команде могут заявить, что они должны по сравнению с конкурентом выжать в два раза больше возможностей из фиксированного объема RAM или дискового пространства. Или, например, от них могут потребовать, чтобы система поддерживала вдвое большее количество транзакций по сравнению с любой сопоставимой
 
небольшие проекты - проектная команда включает менее 10 человек, работает в исключительно неблагоприятных условиях и должна завершить проект в срок от 3 до 6 месяцев;
средние проекты - проектная команда включает от 20 до 30 человек, протяженность проекта составляет 1-2 года;
крупномасштабные проекты - проектная команда включает от 100 до 300 человек, протяженность проекта составляет 3-5 лет;
гигантские проекты - в проекте участвует армия разработчиков от
1000 до 2000 человек и более (включающая, как правило, консультантов и соисполнителей), протяженность проекта составляет от 7 до 10 лет.
нужно различать очень сложные и принципиально невыполнимые проекты.
Таблица 1.1. Причины безнадежных проектов
Политика, политика, политика
Наивные представления маркетинговых служб, высшего руководства, менеджеров проекта и др.
Наивный оптимизм юности: «Мы сможем сделать это за выходные!»
Менталитет первопроходцев у неопытных предпринимателей
Менталитет «Морского Корпуса» (Marine Corps): Настоящие программисты не нуждаются в сне!
Высокая конкуренция, порожденная глобализацией рынков
Высокая конкуренция, вызванная появлением новых технологий
Сильное воздействие неожиданных правительственных решений
Неожиданный
Таблица 1.2 Причины участия в безнадежных проектах
Риск высок, но вознаграждение тоже
Синдром покорителей Эвереста
Удовольствие «вкалывать» среди других таких же энтузиастов
Наивность и оптимизм молодости
Альтернатива - безработица
Возможность
Возможность будущей карьеры
Альтернатива - банкротство или прочие разные бедствия
Возможность победить бюрократию
Месть
Этот
оставь меня в покое;
спасайся!
будь внимателен;
спроси: «Что я буду с этого иметь?»;
перед началом проекта как следует отдохни;
убедись, что можно полностью доверять всем своим сотрудникам;
помни, что разработчики тебе не враги, враги - менеджеры;
общение, общение и еще раз общение;
не раздувай проектную команду;
нанимай
молодых специалистов;
береги свою команду;
сделай так, чтобы к началу тестирования план тестирования был уже готов;
сделай так, чтобы каждый хорошо понимал, чем он занимается;
поддерживай документацию в актуальном состоянии;
каждый должен иметь доступ к документации;
проводи регулярно еженедельные совещания для обсуждения
хода разработки;
проводи совещания ежедневно;
держи под рукой побольше хорошего кофе;
команда всегда должна быть в хорошем настроении;
обеспечь команду всем необходимым.
не начинай проект сам;
не начинай проект, если не хватает финансов для его завершения;
не соглашайся на нереальные сроки;
не бойся уйти из проекта, если видишь, что руководство ведет себя неразумно;
не будь слишком строг к низкооплачиваемым сотрудникам;
не затягивай совещания больше, чем на 1,5 часа;
не забывай о личной жизни;
не бойся требовать от руководства
Выставляйте их с работы в пятницу вечером и старайтесь дать им возможность нормально высыпаться. (Если месяцами работать по шесть дней в неделю и по двенадцать часов в день, то большинство разработчиков в конце концов либо уволится, либо наделает кучу ошибок.) Как бы ни шла работа, всегда заботьтесь о своих людях. Кроме того, постарайтесь сделать оплату их труда как можно более приличной. Кардинально это дела не изменит, но, по крайней мере, поможет сохранить команду в целости.
Не позволяйте кому-либо, помимо вас, серьезно вмешиваться в дела ваших сотрудников и обращаться к ним с различными просьбами, отвлекающими их от работы. Это не значит, что вы сами не должны оказывать на них никакого давления, но ситуация должна быть под вашим контролем, если хотите, чтобы дела в команде шли нормально.
1.4.1 Риск высок, но вознаграждение тоже
Да, это было бы замечательное техническое достижение, ну и что с того?
Это хорошая мысль - регулярно задавать такой вопрос на каждое очередное сообщение руководства корпорации. Например, вам говорят: «Такая Windows 95 сможет уместиться в ваших наручных часах!», а вы в ответ снова спрашиваете: «Ну и что?»
Типичными «игроками» в безнадежном проекте являются следующие:
владелец;
заказчик;
акционер;
заинтересованное лицо;
защитник.
 
Традиционно владелец - это человек, который принимает, санкционирует или финансирует систему и/или результаты проекта. Чрезвычайно важно идентифицировать этого человека и сделать все возможное, чтобы он был удовлетворен ходом проекта.
 
большинстве случаев владелец проекта - это друг, а не враг. В интересах владельца разрезать красную ленточку и избавиться от бюрократических рогаток, что почти всегда является благом для менеджера проекта.
Заказчик - это как раз тот человек или, во многих случаях, группа людей, которые будут использовать разработанную систему после завершения проекта. Во всем мире такого человека или группу обычно называют «пользователями».
 
Не стоит забывать про «узкий круг» тех людей, которые вроде бы не имеют прямого интереса в проекте, однако имеют влияние на его участников, мнение о том, что следует делать и горячее желание навязать это мнение всем окружающим. Известные также, как «кабинетные советчики», эти люди часто проводят время, нашептывая мягким и действующим на подсознание тоном на ухо тем, кто принимает решения, и могут довольно быстро сделать из друга врага, причем так, что вы об этом и не узнаете.
Подведем итог: защитник более важен для проекта, чем любая, самая новейшая методология или супермодный язык программирования. В отсутствие защитника, способного отстоять право проектной команды игнорировать бюрократические правила и поддержать решение использовать достаточно рискованные методы и средства, безнадежный проект будет всего лишь единичным жалким экспериментом. Я бы поостерегся выполнять такой проект. Если же ваш защитник является также владельцем проекта, и не существует
каких-либо других заслуживающих внимания акционеров, и если ваш владелец/защитник - достаточно авторитетная фигура для всех заинтересованных лиц, то вы можете позволить себе роскошь игнорировать всю эту политику; в то время как обычно проблемы, связанные с политикой, ложатся на плечи менеджера проекта, остальные участники проектной команды должны иметь хотя бы минимальное представление о составе действующих лиц на политической арене.
Уолл-Стрит, имел любопытную стратегию для испытания физической выносливости и силы духа своей команды: в самом начале проекта он создавал «искусственный» кризис и немедленно бросал всю команду на его ликвидацию, заставляя при этом работать с удвоенной энергией. При этом он наблюдал происходящее из-за кулис; один или двое из участников команды могли уволиться, один или двое могли заработать нервный срыв, и один или двое «скромных героев» могли проявить себя и ликвидировать кризис
за счет сверхинтенсивной работы или удачного технического решения. Испытав таким образом свою команду, этот хладнокровный менеджер мог затем ослабить давление и приступить к реальной работе над проектом, будучи уверен, что в случае возникновения настоящего кризиса (который рано или поздно наступит в безнадежном проекте) он будет хорошо знать, на что способна его команда.
Как отметил автор и консультант John Boddie, очень важно, чтобы все согласились с наличием более чем одного возможного «сценария» для проекта. Для проведения переговоров нелишними будут такие вопросы, как «обанкротится ли организация, если система будет готова не к 1-му сентября, а к 5-му?» или «все хотят, чтобы работа была сделана хорошо, быстро и дешево. Все знают, что реально можно выполнить только два требования из трех. Какие именно два для вас важнее?».
египетских пирамид, если не раньше. Используйте любые методы оценки, оказавшиеся под рукой, затем полученную «разумную» оценку удвойте и для большей надежности добавьте еще три месяца (или три недели, или три года, в зависимости от масштаба проекта). Главная проблема такой стратегии заключается в том, что она прямиком ведет к самому жесткому ограничению, связанному с безнадежными проектами: сжатым срокам.
наиболее общими стратегиями формирования команды безнадежного проекта:
нанять суперпрограммистов и предоставить им свободу действий;
настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;
набрать команду из простых смертных, но при условии, что они будут знать, на что идут;
взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».
Не забывайте о том, что 20%-ное повышение зарплаты имеет гораздо большее значение для молодого программиста, зарабатывающего 25,000$ в год, чем для опытного и квалифицированного программиста, зарабатывающего 75,000$ в год. При более высокой зарплате предельная налоговая ставка обычно существенно выше и может достигать 50%, поэтому опытный программист приносит домой не намного больше молодого, и, следовательно, зарплата при этом рассматривается, скорее, как фактор гигиены.
Что касается проектов, в которых большие премии невозможны или нежелательны, менеджеру проекта важно не забывать о том, что существуют достаточно разнообразные виды нематериального вознаграждения, с помощью которых можно так же серьезно стимулировать участников проекта. Это также справедливо и для «нормальных» проектов, но для безнадежных особенно важно. Важно также помнить, что пресс, под которым находится команда безнадежного проекта, давит также и на членов их семей.
 
Первым делом следует ослабить тот пресс, под которым находятся ваши люди, поэтому первоочередное вознаграждения должно доставаться супругам и семьям участников проекта – карьера и деньги конечно хороши, но не надо забывать и о семье, которая вынуждена нести определенные лишения. Для начала важен и букет цветов. Оказывайте поддержку всей семье – ведь они все так или иначе участвуют в работе.
то менеджер проекта должен перевернуть землю, если потребуется сломать бюрократические преграды, и сделать все, чтобы обеспечить необходимую помощь и успокоить участника проекта, волнующегося о своей семье.
Если дети действительно серьезно больны и нуждаются в медицинской помощи,
Конечно, если бюрократы обнаружат это, то они поднимут вой, что такие расходы официально не предусмотрены. Менеджер, который уступит такому нажиму, будет просто бесхарактерной тряпкой; если это необходимо, менеджер должен оплачивать такие расходы из своего собственного кармана, поскольку он обычно получает гораздо большую зарплату, чем технические специалисты в его команде. В любом случае, воевать с бюрократами – это забота менеджера;
самое последнее дело вынуждать технических специалистов попусту тратить свое время и эмоциональную энергию на борьбу с бухгалтерией, чтобы доказать им целесообразность покупки дополнительной пиццы на ужин, если команда задержалась на работе до позднего вечера.
Оплаченная свобода действий – когда безнадежный проект завершится, привлеките участников команды к шестимесячной работе над «Проектом Х» (эту замечательную идею предложил Larry Constantine на конференции по программному обеспечению в Мельбурне в 1995 году). Вопрос: что такое «Х»? Ответ: все, что они пожелают. Вместо того, чтобы сразу же оказаться втянутыми еще в один безнадежный проект (или в скучный до безобразия «нормальный» проект, что на самом деле ничуть не лучше), участники
команды получат хорошую возможность в течение шести месяцев осваивать Java, изучать новейшие объектно-ориентированные методологии или даже вернуться в колледж, чтобы получить свою степень магистра. Надо проявить некоторую изобретательность, придумывая «официальное» название для Проекта Х, чтобы поставить в тупик бюрократов; что-нибудь вроде «эвристической объектно-ориентированной клиент-серверной системы стратегического прогнозирования с возможностями Internet» может произвести
произвести необходимый эффект.
4.3 Значение коммуникации
В безнадежных проектах одним из важных вопросов, связанных с человеческими ресурсами, является природа и степень взаимодействия между менеджером проекта и остальной командой. По моему убеждению, идеальная ситуация – когда у менеджера проекта нет секретов от команды, и каждый участник команды знает о проекте все. Это означает, что каждый участник команды располагает текущей, актуальной информацией относительно состояния проекта,
 
Формирование: участники команды определяют цели, роли и направление работы.
Утряска: команда устанавливает правила и процедуры принятия решений и, как правило, пересматривает роли и ответственность.
Нормирование: вырабатываются процедуры, стандарты и критерии.
Выполнение: команда начинает функционировать как целое.
В идеальном случае команда
например, если разработчики ПО работают в достаточно тихом помещении, вероятность появления у них ошибок уменьшается на одну треть по сравнению с теми, кто работает в шумном офисе и постоянно отвлекается на посторонние дела. Проанализировав работу 600 разработчиков ПО,
DeMarco и Lister смогли получить результаты, убедительно говорящие о том, что продуктивность работы тех, кто находится в хорошем офисе и может закрыть дверь, не отвечать на телефонные звонки и не отвлекаться на посторонние дела, почти в 2,6 раза выше, чем у находящихся в обычном офисе.
Дистанционный доступ - разрешите всем работать дома и организуйте еженедельные рабочие совещания в ближайшем «МакДональдсе» (в 9 часов утра, когда почти нет посетителей). Пока кто-нибудь обнаружит исчезновение команды, может пройти не одна неделя. Для дополнительного отвлечения внимания можно посадить чучела за столы, которые обычно занимала проектная команда; руководству понадобится достаточно много времени, чтобы отличить их от других зомби, сидящих в офисе.
Самовольный захват - не спрашивая ни у кого разрешения, займите какое-нибудь пустое помещение, которое пока никем не занято, в то время как хозяйственная служба пытается подсчитать, сколько сотен людей они смогут туда впихнуть. Такой захват обеспечит 90% успеха в борьбе за условия работы; пока бюрократы будут ругаться, спорить и отправлять в разные стороны гневные послания, вам, может быть, уже удастся закончить проект и незаметно удалиться на прежнее место.
Лобовая атака - если у вашего проекта есть защитник и/или владелец, которые крайне заинтересованы в его успехе, объясните им, насколько важно, чтобы проектная команда работала в хороших условиях. Если защитник проекта является руководителем высокого уровня, то организовать временный переезд команды в более подходящее помещение будет относительно несложно.
Переход в ночную смену - это более радикальный вариант, однако он может оказаться достаточно эффективным, если большая часть работы может выполняться без взаимодействия с пользователями. Не слишком приятно просить людей работать в ночное время вместо дневного, однако фактически это гарантирует отсутствие обычных отвлечений. Подобная стратегия наверняка вызовет гнев местных бюрократов, но самая замечательная вещь заключается в том, что бюрократы не остаются в офисе до полуночи! Они будут
слать сердитые записки и послания по электронной почте, при этом следует игнорировать их и делать вид, что никогда их не получали. Если это не удается, просто откажитесь менять свой график работы; пока они не додумаются отключать свет или поменять замки на двери офиса, вряд ли им удастся помешать вам в рамках обычного безнадежного проекта.
Преграды и заслоны - если ваша команда работает в обычном «открытом» офисе и упомянутые выше стратегии неприменимы,
тогда постарайтесь сделать все возможное, чтобы сосредоточить команду в смежных помещениях. После этого сделайте все необходимое, чтобы забаррикадироваться от остальной толпы в офисе. Отключите селекторную связь и вопящий из угла громкоговоритель (и будьте готовы проделывать это еженедельно, поскольку обслуживающий персонал может снова включить их). Выключите телефоны из сети, или, как советуют DeMarco и Lister, набейте вату в звонок. Если вы сможете проделать такое на целом этаже или
вообще во всем здании, то будет еще лучше. Поднимите над зданием пиратский флаг, как это сделал Стив Джобс со своей командой в Apple во время проекта Macintosh. Установите охрану, чтобы гнать прочь непрошеных визитеров.
главное заключается в том, что в безнадежном проекте вам не хватит времени на то, чтобы удовлетворить все потребности пользователя. Если вы будете строить все свои процессы и методы, исходя из этого непреложного факта, то у вас появятся шансы на успех; если же вы начнете проект, будучи уверенными, что к кодированию нельзя приступать до тех пор, пока все диаграммы потоков данных, полученные в результате структурного анализа, не будут утверждены пользователем, то вы определенно потерпите неудачу.
разделяя все требования к системе на три категории: «необходимо выполнить», «следует выполнить» и «можно выполнить».
пересмотреть срок окончания проекта;
пересмотреть требования к системе.
Новый менеджер может даже поставить свое согласие на участие в проекте в зависимость от успешного окончания переговоров – например, заявив: «Если вы хотите, чтобы я вытащил вас из этой ямы, то должны принять как факт, что мы сможем реализовать в срок только небольшой процент первоначально заданных функций. Таково реальное положение вещей, согласны вы с ним или нет».
что же делать со всем тем, что было наработано до наступления кризиса и прихода нового менеджера? Ведь команда, вероятно, уже успела много напрограммировать и оттестировать, и может быть, даже успела разработать некоторую документацию и проектные модели. Что же делать со всей этой частично
выполненной работой. Наиболее разумный ответ: большую часть придется выбросить.
все акционеры и заинтересованные лица должны принять согласованное решение, какие требования следует отнести к категории «необходимо выполнить», какие к «следует выполнить» и какие к «можно выполнить». Разумеется, если владелец проекта категорически настаивает на том, чтобы все требования были обязательно выполнены, все дальнейшее обсуждение будет пустой тратой времени.
Что пользователи в состоянии понимать - так это их собственный родной язык, например, английский для большинства североамериканских проектов. И что большинство из них предпочитают читать - это небольшой документ из 10-20 страниц, суммирующий все требования к системе. Требования в таком документе могут называться «характеристиками», а сам документ в целом - «Требования к системе» («Product Requirements Document» - PRD) или «спецификация высокого уровня» или еще какой-нибудь
Он не должен содержать рекламной «шелухи», а также непонятной терминологии или обозначений, заставляющих пользователей задумываться, что бы это значило. В идеальном случае каждый абзац или даже каждое отдельное предложение должны соответствовать конкретному требованию, чтобы и пользователи, и участники проектной команды могли использовать их в качестве отправной точки для своей дальнейшей работы.
Не следует ожидать более чем 10-процентного сокращения сроков по сравнению со среднестатистической нормой для аналогичных проектов – разумеется, если вы действительно в это верите, то не следует даже и начинать безнадежный проект!
Не пытайтесь использовать новую технологию как средство для сокращения сроков – у вас будет и без того достаточно проблем кроме отлавливания ошибок в бета-версиях новых средств и технологий, добытых у знакомого поставщика. Более детально этот
Не навязывайте заказчику решения, специфичные только для него – полезный совет для любого проекта.
Не следует заниматься поиском панацей – об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.
Не упускайте возможность удалить
удалить из критического пути те элементы, которые находятся вне сферы вашего контроля – если ваша проектная команда не в состоянии их контролировать, то иметь такие элементы на критическом пути означает повышенную степень риска. Это относится к таким вещам, как инструментальные средства поставщика, оборудование, программные продукты и другие компоненты, поступающие от внешних поставщиков.
Не следует ожидать точной оценки состояния проекта от чисто формальных оценок, выполненных множеством чересчур активных и некомпетентных критиков – проектная команда не должна об этом беспокоиться, поскольку она уже знает, что такие сеансы оценки представляют собой политические ритуалы.
какие вопросы следует задать команде безнадежного проекта, чтобы быстро определить, не утратили ли они чувство реальности до такой степени, что проект пора прекращать?
Используете ли вы (и поддерживаете в актуальном состоянии) сетевой график работ?
Располагаете ли вы утвержденным планом и бюджетом?
Знаете ли вы, за разработку какого ПО несете ответственность?
Можете ли вы перечислить первые десять проектных рисков?
Известен ли вам процент сжатия вашего плана по сравнению с нормальным?
Каков оценочный объем вашего ПО? Каким образом он вычисляется?
Известна
ли вам та часть внешних интерфейсов, которая находится вне вашего контроля?
Достаточными ли знаниями о предметной области располагают ваши специалисты?
 
мини-этапов» и стратегии «ежедневной сборки проекта».
любит говорить Jim McCarthy, менеджер продукта Microsoft Visual C++ и автор книги Dynamics of Software Development [4]: «Ежедневная сборка - это биение сердца проекта. Она дает знать, что жизнь продолжается».
Такой подход подразумевает наличие автоматизированного управления конфигурацией ПО и механизмов контроля исходных кодов, а также разнообразных «скриптов» для выполнения компиляции и сборки приложений. Но что еще более важно, он подразумевает наличие системы автоматизированного тестирования, которая может работать всю ночь, выполняя гору тестов для проверки работоспособности системы.
 
Оценка риска выполняется обычно путем оценки сложности разрабатываемой системы или продукта, а также оценки клиентской среды и среды проектной команды. Сложность продукта можно оценить в терминах объема (например, количества функциональных точек), ограничений производительности, технической сложности и т.д. Риск, связанный с клиентской средой, определяется в основном такими факторами, как количество пользователей, вовлеченных в проект, уровень квалификации пользователей, значение
 
разработки для пользовательского бизнеса, вероятность того, что внедрение новой системы (если оно произойдет) приведет к реорганизации или даунсайзингу и т.д. Наконец, риск, связанный со средой проектной команды, зависит от ее способностей, опыта, морального состояния и физического/эмоционального здоровья.
смелости, чтобы обратиться к исполнительному директору или первому вице-президенту с просьбой уменьшить риск путем существенного увеличения бюджета или снятия серьезных бюрократических ограничений, будет вполне разумным обратиться с такой просьбой в безнадежном проекте. Если вы этого не сделаете - а для этого может потребоваться пройти по иерархической лестнице и обойти несколько уровней тупых начальников - то вы так никогда и не узнаете, удалось бы вам решить ваши проблемы или нет.
Команда безнадежного проекта должна самостоятельно, независимо от принятых в организации стандартов, решить, какие средства являются необходимыми, а без каких можно обойтись.
Самое лучшее средство - это большая диаграмма, приколотая к стене. Она может содержать (частично полные) E/R-диаграамы, или потоки данных, или что-нибудь другое. Важно то, что она служит отправной точкой для обсуждения проектных решений и почти не требует затрат.
Таблица 6.1 Семь ступеней мастерства в разработке ПО
1. Наивный новичок
Никогда не слышал о технологии Х (очевидно, для этого не требуется никакого времени).
2. Осведомленный разработчик
Прочел статью о технологии Х (в большинстве случаев разработчику ПО достаточно одного часа, чтобы разобраться в общих чертах и высказать свое мнение о преимуществах и недостатках средства, даже если он никогда его не видел или не использовал).
. Начинающий разработчик
Посетил пятидневный семинар (неделя, возможно, сжатая до двух дней ввиду того прессинга, под которым находится безнадежный проект. Следует отметить, что при этом разработчик, скорее всего, успел всего лишь поработать с компьютерными руководствами, предоставленными поставщиком, или пробежаться по небольшим примерам, иллюстрирующим возможности средства. Ему не пришлось столкнуться с какими-либо проблемами и недостатками средства, у него не было возможности,
 
каким образом можно масштабировать средство (если это вообще возможно) для больших и сложных проектов; он не пытался интегрировать средство с большинством остальных средств в данной среде).
4. Практикующий разработчик
Готов использовать технологию Х в реальном проекте (по-видимому, достаточно месяца, чтобы в основном постичь все нюансы использования средства и быть вполне готовым к его использованию в «реальном» проекте).
5.
Квалифицированный разработчик
Постоянно использует технологию Х в своей работе и очень недоволен, если по какой-то причине лишается этой возможности (для достижения такого уровня обычно требуется 6-12 месяцев, и если средство действительно подобно «серебряной пуле», то разработчик превращается в проповедника и пытается всеми способами убедить каждого, что это средство - самое замечательное в мире).
6. Мастер
Усвоил
все детали технологии Х; знает, как обходить ее правила (на это требуется два или три года, это также означает, что разработчик прошел через две или три новые реализации продукта, познакомился со всеми пользовательскими сообществами в Internet, знает все отсутствующие в справочниках номера телефонов специалистов по технической поддержке в организации поставщика).
7. Эксперт
Пишет книги, выступает с докладами на конференциях, ищет
способ распространить технологию Х на другие галактики (Page-Jones в своей статье говорит о методологиях, поэтому не совсем очевидно, что это применимо по отношению к средствам и технологии).
Итак, используйте любые средства, которые вы сочтете подходящими для вашего безнадежного проекта, не обращая внимания на то, какими их считает весь остальной мир: современными или устаревшими. Но не забывайте, что новые средства в безнадежном проекте окажут воздействие и на людей, и на процессы. Как сказал 150 лет назад Генри Дэвид Торо, люди становятся орудиями в руках собственных средств.
Я провел годы в лотерейном бизнесе, где все делается в экстремальных условиях, поскольку это единственный способ существования и развития отрасли. Если вы не желаете работать в таком режиме, то не сможете играть в этой песочнице. Разработчики в данной отрасли мирятся с таким положением, поскольку им доставляет удовольствие добиваться успеха в краткосрочных и в высшей степени интенсивных проектах и получать взамен значительную свободу действий, включая, в частности, двухмесячные
отпуска между проектами. Эти команды считают себя элитой, и компании всячески поддерживают такие убеждения.
Молодые, неженатые трудоголики – это именно то, что требуется многим организациям для их безнадежных проектов.
Военные игры помогают вам оценить свои относительные достоинства и недостатки, и помогают организации в целом оценить свои слабые и сильные места.
Наиболее эффективной для участников формой военной игры, позволяющей стимулировать творческий беспорядок, является командная игра.



"+":

"-":

вывод:
отличная интересная книга