Заметки по книге Цель 3.0

Заметки по книге Цель 3.0

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

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

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

многие проекты по внедрению ERP сбиваются с графика.
Четыре года работы, а конца проекта зачастую даже и не видно. Естественно, компании, оказавшиеся в такой ситуации, очень недовольны. Дело вполне может дойти до судебных
разбирательств.
— И это ты называешь возможностью? — спрашивает Ленни.
— Однозначно, — уверенно заявляет Гейл. — С начала этого года мы стали искать компании, которые уже вдоволь натерпелись от своих поставщиков систем ERP. Пока мы выявили как
минимум дюжину таких компаний, готовых, на наш взгляд, сменить поставщика. Все, что нам
нужно — сделать им сногсшибательное предложение и как-то убедить, что с нами подобного
фиаско

Теперь борьба идет не за опции и конфигурации. Борьба идет за скорость и легкость
внедрения. -это главный плюс QV, если все делать правлильно.

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

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

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

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

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

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

Одноразовая выгода получается в результате сокращения сроков дебиторской задолженности, решения
«Проблемы 2000» и снижения запасов.
Снижения объема и сроков задолженности влияет на платежи за деньги. Снижение дефицитп и срока поставок на объем продаж и маржи, на упущенные продажи и доли рынка конкурентам.
Но не менее важна и длящаяся выгода, — продолжает Мэгги. — Она получается опять же в
результате снижения запасов, консолидирования закупок и роста продаж.

Но вывод все равно тот же: чем меньше компания, тем
меньше ее ожидаемая выгода от нашей технологии. Даже в относительном выражении.
Ленни готов согласиться с этим.
— Значит, ты утверждаешь, что крупным компаниям мы предлагаем чрезвычайно выгодное
приобретение, а для средних — практически ничего ценного?!
— Я бы согласилась с этим, — задумчиво произносит Гейл.
— Я всегда говорила, что рынок средних компаний — это не наш рынок.
— Почему? — спрашивает Ленни.
— Разве не понятно? — отвечает Гейл. — Если мы не будем предлагать реальную выгоду, наши системы будут покупать только те, кто восхищается новыми технологиями, кто стремится
быть современным и успевать за новыми веяниями.
— Слава богу, таких предостаточно, — быстро добавляет она.
— Конечно, не все в компаниях являются фанатами новых технологий, поэтому если мы не
предлагаем реальную выгоду, нужно очень много времени, чтобы преодолеть сопротивление
скептиков.

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

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

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

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

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

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

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

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

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

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

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

Три месяца спустя все разлетается в пух и прах. И не потому, что что-то пошло не так в
производстве. В производстве все шикарно. Положение дел в дистрибуции ухудшается на сто
миллионов долларов, а обвиняют в этом их. Вот что значит продавать выгоду — теперь ты всегда
крайний. Сто миллионов долларов. Если об этом кто-то узнает, легко представить, что тогда
начнется.
Именно программа помогла высвободить столько скрытой мощности на заводах. А когда объемы производства резко растут, в то время как продажи за ними не успевают, неизбежно начинают расти запасы на складах.
Такого не происходит на заводах, которые производят на заказ. Но это типичная ситуация для
заводов, которые производят в соответствии с прогнозом продаж. Запасы готовой продукции
будут расти.
Рост запасов вызван ростом производительности заводов. Но где скапливаются эти запасы? В
дистрибуции. Только спросите начальников складов, каково отвечать за растущие запасы и быть
бессильными что-либо изменить. Проблема возникает в дистрибуции, но она в ней не виновата и
ничего не может с ней поделать.
применения ТОС в производстве. Если
тебя беспокоит качество прогноза, почему бы тебе не применить подход ТОС к дистрибуции?
— Я ничего не знал об этом подходе. Ты можешь рассказать о нем?
— Да, он опирается на тот факт, что относительная точность прогноза для разных уровней в
компании разная. Больше всего запасов следует держать там, где точность прогноза наиболее
высокая.
— Я тебя не понимаю, Скотт, — говорит Брайан и, повернувшись к залу, спрашивает: — А вы?
Практически все уверяют его, что они тоже ничего не поняли.
— Что же тут непонятного? — невинно спрашивает Скотт. — Разве вы не знаете, что точность
прогноза ухудшается по мере того, как вы сужаете диапазон выборки? Продажи по какому-то
одному магазину, например, на следующей неделе могут оказаться в три раза выше или ниже
продаж на этой неделе. Спрогнозировать это невозможно. Но крайне маловероятно, что
подобные экстремальные колебания будут типичны для продаж всех магазинов в Северной
Америке.
— Согласен, — говорит Брайан. — И что?
— Поэтому, я думаю, было бы разумней держать запасы в тех местах, где они подчинялись бы
прогнозу, отражающему прогноз продаж для всего континента. Такой прогноз гораздо точнее.
— И что же это за места? — спрашивает Брайан.
— Заводы, — отвечает Скотт. — Заводы производят для всего континента. Так почему бы не
держать запасы прямо там, у источника?
— Скотт, — говорит Брайан, — может быть, твое предложение и разумно, но, боюсь, большинство людей в этом зале скажут, что ты не понимаешь наш бизнес. В нашем бизнесе
запасы готовой продукции не хранятся на заводах. Видишь ли, мы должны держать запасы как
можно ближе к нашим клиентам, для этого мы и создаем систему дистрибуции. Клиенты не будут
ждать, пока мы доставим им товар с заводского склада. Когда им что-то нужно, они
рассчитывают получить это в тот же день.
— Я знаю, — уверяет его и всех собравшихся Скотт, — я знаю, что в вашем бизнесе вы не
держите запасы готовой продукции на заводах. А, может, следовало бы?
— Тебе придется очень постараться, чтобы убедить нас в этом, — решительно говорит Брайан.
— Можно хотя бы постараться?
— Пожалуйста.
— Брайан, ты говорил, что количество случаев дефицита увеличивается с пугающей
скоростью и составляет двадцать случаев в день.
— Именно так.
— Почему? — спрашивает Скотт и быстро добавляет: — Только не рассказывай мне, что
качество прогнозов вдруг резко ухудшилось.
— Нет, вовсе нет. Качество осталось таким же гнусным, как и раньше. Быстрое увеличение
случаев дефицита вызвано тем обстоятельством, что мы кардинально сократили целевой уровень
запаса. Ситуация такова, что когда возникает дефицит на одном из складов, заводу нет смысла
производить этот недостающий продукт для всех остальных складов. Проще говоря, мы не
сможем отгрузить им этот продукт. Если кому-то этот товар и нужен, его количества не хватит, чтобы загрузить фуру хотя бы наполовину. В результате наши заводы работают теперь с
крошечными производственными партиями. Они настолько малы, что большая часть времени
уходит на переналадку линий. Неудивительно, что мы все хуже и хуже реагируем на заказы
складов.
— Понимаю, — говорит Скотт и, немного помолчав, говорит:
— Хотя нет, не понимаю.
— Чего ты не понимаешь?
— Я не понимаю, почему, когда завод производит продукт для одного склада, он не может
произвести в пять раз больше. Отправь столько, сколько нужно этому складу, а остальное
количество оставь на заводе. Сколько пройдет времени до тех пор, пока этот продукт
потребуется другим складам и будет им отгружен в полном объеме? Две недели? Три?
Брайан делает вид, что задумался.
— Мы никогда не держали запасы готовой продукции на заводах, — говорит он, — но, навскидку, почему бы и нет, — он обращается к директорам заводов: — А вы что думаете?
— Я не уверен, что у меня хватит для этого места, — говорит один из них.
— Предположим, мы решим этот вопрос, — говорит Брайан. — Мы найдем вам место
поблизости. Кстати, у тебя там есть склад всего в часе езды, можно использовать его. Так что ты
теперь думаешь по этому поводу?
— Очень разумно, — отвечает директор завода.
— Брайан, — говорит другой из них, — мелкие производственные партии просто сводят нас с
ума. Я соглашусь на все что угодно. Но ты это серьезно? Неужели ты позволишь нам держать
запасы готовой продукции на заводах?
— А почему нет? Назови хотя бы одну причину.
— Ну, я не знаю. Может, внутренние правила компании?
Брайан отмахивается и, повернувшись к Скотту, говорит:
— Я обсужу это подробнее со своими людьми, но пока можно сказать, что твоя идея
принимается.

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

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

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

про инвестиции в ИТ.
трудом я принимал решение о покупке новой
системы ERR. Знаешь, почему? Потому что инвестиции в компьютерную систему сильно
отличаются от инвестиций во все остальное. Это не то же самое, что инвестиции в новую
компанию, или в недвижимость, или в оборудование. Ты платишь такие деньги, и что ты
получаешь на руки? То, что ты получаешь, нельзя ни перепродать, ни заложить. Мне было
трудно принять это решение, и так же трудно будет моим поставщикам. Поэтому я подумал, что
бы такое вы могли предложить компании, в результате чего вы получили бы те же деньги, но при
этом значительно облегчили бы этой компании процесс принятия решения?
— Интересный подход, — говорит Скотт.
— Продолжай, — просит Мэгги.
— За последние три года я заплатил вам в совокупности около трехсот миллионов долларов. И
я продолжу платить где-то по десять миллионов в год за обслуживание и все такое. Но знаете
что? Я бы с радостью платил вам по сто миллионов в год сколько угодно времени, если бы мне не
пришлось выкупать вашу программу и платить за ее внедрение.
Крейг резко замолкает.
— А за что бы ты платил по сто миллионов в год? — сосредоточенно спрашивает Мэгги.
— Как раз за то, что вы сделали. Ну, может быть, не только за это. Например, если бы вы
взяли на себя все, что у меня в компании связано с информационными системами, я бы с
удовольствием столько вам заплатил. Вы работаете с данными, мои люди вводят их, но работаете
с ними вы. Вы следите за тем, чтобы у моих людей всегда была необходимая информация. Какие
там используются компьютеры и программы — мне безразлично. Я не хочу ничего слышать об
ошибках кода, о новых версиях, о новом оборудовании. Это все ваша головная боль. Мне нужны
конечные результаты. Информация, которая доступна моим людям в нужное время, в нужном
месте и в нужной им форме.
Мэгги и Скотт переглядываются. Какое-то время все молчат. Наконец Мэгги кивает, и Скотт
говорит:
— Знаешь, Крейг, еще год назад я бы от души посмеялся над твоим предложением.
— Почему?
— Потому что это точно привело бы нас к банкротству.
— Почему?
— Когда клиент тебя о чем-то просит, зная, что ему не придется платить, он будет постоянно
требовать что-то новое: новые функции, новые модули, новые шаблоны и так далее. Но на самом
деле все это клиенты просят, даже несмотря на то, что им приходится за это платить. Поэтому у
нас возникло бы две альтернативы. Первая: мы делаем все, что просят клиенты, и вскоре
разоряемся. Вторая: мы расстраиваем наших клиентов и вскоре разоряемся. Но в случае с
«Пирко» и при существующих обстоятельствах я готов подумать.
— А в чем разница? Чем мы так отличаемся от других?
— Вы стали отличаться со временем. Крейг, с тех пор, как вы начали применять ТОС, количество запросов на новые функции сократилось в разы по сравнению с тем, как это было
раньше. А оставшиеся запросы основаны на реальных и осмысленных требованиях, а не на
капризах. Видишь ли, система в «Пирко» подчиняется теперь совсем другим правилам. Любой
запрос подкрепляется теперь обоснованием с точки зрения экономических результатов. По
сравнению с тем, что было раньше, это как небо и земля.

нужно продумать про
продажу в лизинг,
передачу системы в аренду.

кратко SAP busines one stroim effectivnyi biznes

source
Описание:

Он начинает решение со своих проблем, т.е. там, где заканчивает производитель. Затем смотрит, какие возможны варианты решения проблемы, затем выбирает один из них и только после этого выбирает конкретный продукт или технологию из списка пред- лагаемых различными производителями. Т.е. сам продукт, который ему продают, возни- кает только на заключительной стадии принятия решения, а не в начале, как у продавца.
• «Бизнес по-русски» — это небольшие и средние
предприятия в области торговли и производства
с типично российской системой управления. Ав-
томатизация и использование информационных
технологий в таких компаниях находится на са-
мом начальном уровне, а управление в значи-
тельной степени реактивное — т.е. действия ком-
паний являются реакцией на
внешние обсто-
ятельства. • «Бизнес в западном стиле». Важнейшие отличия
этого сегмента — более формализованное «проце-
ссное» управление и проактивный (т.е. решающий
проблемы еще до того, как они становятся крити-
ческими) стиль менеджмента. Стратегия развития
строится таким образом, что учитывает возможнос-
ти изменений и старается управлять ими, создавая
возможности там, где остальные находят проблемы.
Большие корпорации имеют
значительное влияние на экономику страны, но в сумме
малые и средние предприятия составляют большую
часть экономики США. Такая экономика, построенная по
принципу пирамиды, обладает очень высокой устойчи-
востью и способна адаптироваться при весьма значи-
тельных изменениях конкурентной ситуации на рынке.
дование Access Markets International Partners по-
казывает, что малые и средние предприятия пот-
ратят в 2006 году на программное обеспечение ав-
томатизации продаж (SFA), управления отношени-
ями с клиентами (CRM), планирования ресурсов
предприятия (ERP) и управления цепочками поста-
вок (SCM) до 4,2 миллиарда долларов. Для сравне-
ния, в 2005 году весь российский
или директор по информационным технологиям», там называется CIO — Chief Information Officer. Не нуж- но искать ассоциации с армией, прочитав слово «offi- cer» — как говорят словари, это всего лишь «чинов- ник, должностное лицо; служащий; член правления» и только во вторую очередь — «офицер». Соответ- ственно, «исполнительный директор» — это CEO (Chief Executive Officer), а финансовый директор — CFO (Chief Financial Officer). Существует даже редкая и забавная комбинация: ЧМО или, точнее, CMO (Chief
Marketing Officer) — директор по маркетингу.
Роль CIO и его взаимодействие с другими бизнес- подразделениями вряд ли удастся изложить в нес- кольких параграфах — она много больше и многог- раннее. Боюсь, что на это не хватит и целой книжки. К тому же CIO даже на Западе более характерны для крупных компаний, а мы обсуждаем малый и средний бизнес, но тем не менее я попробую отметить нес- колько характерных черт CIO. Во-первых, правильный
CIO — это никоим образом не технический специ-
алист. Если ваш бизнес требует наличия «верховного
технобожества», то тогда вводится пост CTO — Chief
Technology Officer, а CIO — это проводник и перевод-
чик с бизнес-языка на технический и с технического
на бизнес-. Задача CIO — показать, как информаци-
онные технологии могут помочь бизнесу быть более
эффективным и прибыльным.
Подобно тому как ди-
ректор по маркетингу на совещаниях не продвигает
собственное направление, а подключается к предла-
гаемым бизнес-проектам, подсказывая, как сделать
их более эффективными, так и CIO должен предла-
гать пути снижения издержек и повышения эффек-
тивности бизнеса, а не рассказывать о тонкостях ре-
ализации протокола TCP/IP менеджерам по прода-
жам. И наоборот, его задача в том, чтобы объяснить
задачи бизнеса техническим специалистам привыч-
ным им техноязыком. Кроме того, он политик, управля-
ющий проектами, управляющий своим персоналам и
прочая, прочая, прочая. Вряд ли у вас в малом и сред-
нем бизнесе будет под рукой такой специалист, но
стремиться к этому нужно.
любая технология в начале своего пути дает серьезные конкурентные преимущества над теми компаниями, у которых нет к ней доступа. В качестве примера можно привести железные дороги или телеграф — на начальном этапе их развития те компании, которые могли ис- пользовать эти технические новшества, получали серьезные конкурентные преимущества. Но в даль- нейшем, по мере распространения технологии,
к ней получали доступ все больше и больше компа-
ний, пока она не становилась массовой. В результа-
те технология переходит в разряд инфраструктур-
ной, то есть базовой, поддерживающей. Действи-
тельно, считаете ли вы, что наличие в вашем горо-
де станции железной дороги дает вашей компании
серьезное конкурентное преимущество? А может
быть, вы считаете, что использование
телефона ва-
шими сотрудниками дает вам какое-то преимущес-
тво перед конкурентами? А ведь когда-то это были
пионерские технологии, и они действительно дава-
ли выигрыш в бизнесе.
. Более того, сегодня нельзя даже стоять на месте, подобно тому как Алиса в Стране Чудес вынужде- на была бежать изо всех сил, чтобы остаться на месте. Дело в том, что конкуренты постоянно обновляют техно- логии, и чтобы не отстать, необходимо обновлять техно- логии вместе с ними. В результате уровень технологий остается примерно одинаковым у всех игроков, но за об- новление технологий приходится регулярно платить
С другой стороны, «отставание» позволяет смотреть на то, как «лидеры»
набивают синяки и шишки, наступают на грабли и теря-
ют время и средства. Позиция «второго» имеет целый
ряд преимуществ на данном этапе, но для их реализа-
ции необходимо тщательно
анализировать процессы
на западном рынке и примерять их на свой бизнес.
И все же есть ли перспектива у информационных
технологий? Карр, как представитель направления ги-
перпрагматиков, делает довольно пессимистические
выводы — новые технологии следует применять, только
если они уже достаточно созрели и упали в цене, и ес-
ли вы уже начинаете отставать от конкурентов. Крити-
ка этой теории является весьма популярным занятием,
в котором уже отметились первые лица крупнейших ми-
ровых компьютерных компаний. Но для наших целей
нам не нужно забегать так далеко в будущее — просто
отметим, что следующим этапом, с которым столкнется
Россия, догоняя Запад, будет «карровщина», или стра-
тегия крайнего пессимизма. Как
сегодняшние. На рынке ин-
формационных технологий для небольших компаний
существует еще одна проблема, которая стала видна
только недавно. Дело в том, что раньше имелось чет-
кое разделение продавцов по сегментам. При этом су-
ществовало четкое разделение
поведения и мотивации заказчиков. Для корпораций важнейшим является ре- зультат и качество работы — они заинтересованы уровнем сервиса, технической поддержкой, обучени- ем, наличием книжек по продукту и т.д. Императив ма- лого бизнеса — сделайте мне подешевле! Это естес- твенный процесс, но до тех пор, пока каждый из игро- ков остается в своем классе. Но наше время — это эпоха нарушения правил и стирания классовых разли- чий. Ну кто еще недавно мог представить внедорожник от Porsche?
малый бизнес по мере роста перехо- дит в категорию среднего. При этом потребности у не- го становятся как у крупного, а психология остается как у малого. В результате получается кошмар любого поставщика — высокая стоимость качественных услуг премиум-сегмента накладывается на нежелание пла- тить за них справедливую цену. Конечно, рынок слиш- ком соблазнителен, чтобы отказаться от него, но бес- платный сыр бывает только в мышеловке. Если маржа маленькая, то поставщик либо будет завышать цены, либо
снижать качество товара — да так, что покупатель сразу и не поймет, почему цена такая низкая, пока не увидит, что сложную систему внедряют не опытные специалисты, а студенты, или не будет часами дозвани- ваться в службу технической поддержки.
критерии выбора информационных систем
Проработав в области информационных технологий более 10 лет, начинаешь забывать, что еще далеко не все люди на Земле занимаются компьютерными технологиями. Есть немало тех, кто не очень разби- рается в этом вопросе, но замечательно управляет бизнесом, продает товары, обеспечивает работу предприятия и его сотрудников. Работая с крупными
1. Поймите, что вы хотите получить от автоматизации.
На самом деле информационные системы — это
всего лишь инструмент. Если вы уверены, что планиро-
вание закупок на основании анализа прошлых продаж
способно увеличить эффективность вашего бизнеса, и
знаете, как воспользоваться этой информацией, то да- же простейшие программы этого класса способны при- нести серьезную прибыль.
зовать. Для меня, как для человека управляющего бизнесом, CRM — это не программное обеспечение,
а часть моего бизнеса по построению отношений с клиентами. Вы думаете, что я их без программного
обеспечения не умел строить? Просто в определенный момент этих отношений становится слишком мно
го для того, чтобы хранить это в голове или на листочке бумаги, и тогда мне нужен удобный инструмент».
2. Установите границы затрат (не только денежных), которые
вы готовы понести для решения поставленной задачи.
3. Тщательно продумывайте свои действия. Чаще задавайте вопрос — «зачем?»
конечно, превосходит все существовавшие раньше,
лучше, чем у конкурентов и разве что «крестиком вы-
шивать не умеет». Технологические новинки, безус-
ловно, очень важны, но часто они не являются жиз-
ненно необходимыми в настоящий момент.
4. «Зоопарк» — это плохо!
. Не позволяйте лучшему победить хорошее.
Эта ситу-
ация снова напоминает Алису Льюиса Кэррола, где
для того, чтобы остаться на месте, приходилось бе-
жать изо всех сил. Оптимальной стратегией в этом
случае является выбор решения, удовлетворяющего
некоторому уровню потребностей на ближайшее бу-
дущее с возможностью последующей модернизации
и интеграции с другими системами.
6. Бесплатный сыр бывает только в мышеловке.
Характерной особенностью крупных компаний яв- ляется их ориентация на результат, планирование опе- раций на длительное время, повышенное внимание к инфраструктуре и обеспечению операций. Эти ком- пании больше ориентируются на качество работ и сер- висов, стараясь минимизировать затраты. Но при этом затраты не являются единственным или доминиру- ющим критерием выбора.
В связи с тем, что многие средние компании вы- росли из малых, их поведение двойственно. С одной стороны, они уже хотят качества и сервиса, как боль- шие. С другой — не готовы платить за это адекватные деньги, и психологически ориентированы на макси- мальное снижение цены. Именно поэтому большин- ство поставщиков решений не любят работать с таки- ми компаниями — времени тратится столько же, сколько и на крупную продажу, а размер продажи
много меньше. Тем не менее, средний бизнес в миро-
вой экономике — это один из основных источников до-
хода компьютерных корпораций, и отдавать столь ла-
комый кусочек не хочет ни одна компания. При этом
действовать они могут разными способами, но покупа-
тель должен четко понимать — любой товар, любая ус-
луга имеют свою цену. Если вам предложили что-то
очень дешево, то нужно задуматься,
задуматься, почему. Нельзя
сказать, что дешевизна означает жульничество. Дело в
том, что сами программные продукты очень недороги в
копировании.
7. Стоимость владения всегда выше цены покупки.
Одной из наиболее характерных черт работы на рынке информационных технологий во второй по- ловине 1990-х годов была борьба с теми «специ- алистами», которые считали, что «правильное пове- дение» покупателя заключается в «прессовании» продавца по цене и выбор того поставщика, ко- торый даст наименьшую цену.
пользователя, который выбирает тот или иной продукт на основании цены лицензии, прекрасно понимая, что кроме покупки лицензии будет необходимо потратить средства на внедрение купленного продукта, обучение специалистов и пользователей, его обслуживание и модернизацию. Сегодня на Западе это называют жизненным цик- лом продукта (lifecycle management) и включают ту- да все затраты на технологию с начала принятия ре- шения до утилизации его и перехода на новый про- дукт или технологию.
Для оценки экономического эффекта использу-
ются стандартные экономические критерии.
• ТСО — Total Cost of Ownership, или Общая Сто-
имость Владения, рассчитывается исходя из всех
затрат на технологию, включая неявные затраты.
• ROI — Return of Investment — Возврат Инвестиций.
• VCO — Visible Cost of Ownership — Видимая Сто-
имость Владения, отличающаяся
отличающаяся от ТСО тем,
что в нее входят только прямые затраты, ви-
димые бухгалтерией.
• Время возврата инвестиций — время, за кото-
рое прибыль сравняется с начальной сто-
имостью проекта.
 
Чем быстрее возвращаются вло-
женные деньги, тем выгоднее проект.
Мы должны не только выдвигать задачи, но и решать вопрос о методах выполнения этих задач.
Тем не менее понимание того, что начальные инвес- тиции в технологию или продукт (фактически затраты на покупку) не отражают всех затрат на продукт и скорее являются меньшей частью всех затрат, уже стало ба- зовым в крупных компаниях и организациях, но с трудом приживается в средних и мелких компаниях. Причин это- го несколько, и они перечислены выше. Наиболее веро- ятно, что ключевыми являются неуверенность в стабиль- ности бизнеса и отсутствие опыта управления сложны- ми проектами в
• Масштабируемость
• Надежность
• Управляемость
• Опора на стандарты
О нелинейности масштабируемости очень инте-
ресно рассказывает в своих презентациях компа-
ния Sun Microsystems. Они приводят историю или,
возможно, байку про компанию, которая решила за-
няться грузовыми перевозками в городе и подошла
к этому делу очень серьезно. Специалисты компа-
нии тщательно исследовали рынок и выяснили, что
типичный заказ включает перевозку
перевозку коробки весом
от 3 до 20 килограмм на расстояние от 5 до 15 кило-
метров. На основании этих данных они выбрали на-
иболее экономически эффективный автомобиль
для своей компании — FIAT Uno (что-то вроде на-
шей Оки) и закупили партию этих автомобилей для
своих курьеров. К сожалению, первый же заказ, ко-
торый они получили, был на перевозку пианино!
При всей анекдотичности этой истории она от-
ражает основное правило ИТ — данные в системе
могут стоить дороже всей системы.
профессионалов безопасности существует свой критерий выбора системы защиты: защита дол- жна делать экономически невыгодной проникновение
гое. Какими же свойствами должны обладать ин-
формационные системы для бизнеса?
• Простота обработки информации. Должно быть
понятно, что и как делать. При этом сам про-
цесс работы с информацией должен быть очень
прост и эффективен.
Доступность информации.
Пользователи дол-
жны иметь возможность получить доступ к необ-
ходимой информации в правильном формате и
в удобной форме.
 
• Полнота, непротиворечивость и значимость ин-
формации. Об этом часто забывают, но не вся-
кая информация достойна «высокого звания ин-
формации». • Информация в нужном месте. Данные либо нахо-
дятся там, где в них возникает потребность, ли-
бо, если это экономически обоснованно, могут
быть доставлены в это место за приемлемое время
и цену. • Информация в нужное
время. Сбор данных вы-
полняется настолько часто, насколько это тре-
буется для поддержки их актуальности. Напри-
мер, в системах биржевых торгов актуальность
информации гораздо важнее, чем в отделе ко-
мплектации заказов.
 
• Информация
• Информация в нужном объеме. Собираются все
необходимые данные, включая первичные.
• Информация в нужном виде. Исходные данные,
чтобы их было удобно использовать, должны
быть предварительно обработаны. Для этого на
основе собранной первичной информации вы-
числяются различные сводные показатели,
позволяющие представить данные в необхо-
димых разрезах и с нужной степенью обобще-
ния.
• Информация сопоставима. То есть необходимо
сравнивать между собой одинаковые или хотя бы
однородные величины.
• Существует единая версия корпоративной
правды. Все потребители данных всегда исполь-
зуют единую версию информации с целью избе-
жать несогласованности действий.
действий.
• Идет накопление корпоративных знаний. Исто-
рические данные накапливаются и могут быть
использованы в процессе работы.
• Поддерживаются изменения в бизнесе. Необхо-
димо иметь возможность легко изменить и рас-
ширить состав информации в процессе работы.
Быстрый, подвижный, он требует моментальной реакции на изменения и выверенного управления. Парадокс, но управление нужно, а за- думываться об этом нет времени!
 
Можно выделить следующие основные функции
в процессе управления:
• Принятие решения.
• Организация.
• Регулирование, или контроль сверху
• Обратная связь, или контроль снизу.
• Учет.
• Определение финансовой структуры предпри-
ятия путем выделения центров финансовой от-
ветственности.
• Разработка состава, содержания и форматов
управленческой отчетности.
• Разработка классификаторов управленческого
учета.
• Разработка методов управленческого учета зат-
рат и калькулирования себестоимости продукции.
• Разработка управленческого плана счетов и мо-
делей типовых хозяйственных операций.
• Разработка внутренних положений и инструкций,
регламентирующих ведение управленческого учета.
Необходимо также разработать:
• Положение
• Положение о финансовой структуре
предприятия;
• Положение о внутренней учетной политике;
• единые классификаторы управленческого учета;
• управленческий план счетов;
• формы первичных и отчетных документов
управленческого учета;
• регламентацию бизнес-процессов, отража-
ющих сроки, последовательность и ответствен-
ность за формирование регистров
 
«Принцип IBM. Машина должна работать, человек — думать»



Важнее знать, что и зачем делается, и не тонуть в деталях — о деталях пусть по- заботится информационная система компании.
• Ведение конструкторских и технологических
спецификаций.
• Управление спросом и формирование планов
продаж и производства.
• Управление запасами и закупочной деятель-
ностью.
• Планирование производственных мощностей.
• Финансовые функции.
• Функции управления проектами.
 
«CRM — это концепция уп- равления проактивными взаимоотношениями с поку- пателем. В терминах управления бизнесом предпри- ятия это система организации работы front-office с ориентировкой на потребности клиента, на проак- тивную работу с клиентом...».
• CRM — это современная бизнес-стратегия, наце-
ленная на рост и повышение доходности бизнеса
компании, путем повышения лояльности клиента на
протяжении всего цикла взаимодействия с ними
(Microsoft).
В целом CRM — это то, что отличает бизнес, ори-
ентированный на производство, от бизнеса, ориенти-
рованного на продажу. А именно такой бизнес и имеет
шанс на успех в сегодняшнем мире перепроизводства.
Начнем мы с BPD (Business Process Design, или раз- работка бизнес-процессов). Под бизнес-процессами се- годня подразумевается устойчивая последовательность и комбинация бизнес-действий, относящихся к производ- ственно-хозяйственной деятельности компании и обычно ориентированных на создание новой стоимос- ти. Бизнес-процесс включает в себя иерархию вза- имосвязанных функциональных действий, реализу- ющих одну (или несколько) из бизнес-целей компании
в информационной системе компании, например уп-
равление и анализ выпуска продукции или ресурсное
обеспечение выпуска продукции.
• Материально-техническое обеспечение деятельности
предприятия (входящая логистика).
Производственные процессы.
Материально-техническое обеспечение сбыта (исхо-
дящая логистика).
Маркетинг и продажи.
Сервисное обслуживание.
Четыре вторичных (или поддерживающих) дей- ствия таковы: • Закупки.
• Развитие технологии.
• Управление людскими ресурсами.
• Поддержание инфраструктуры фирмы.
• Управление ресурсами предприятия —
mySAP ERP • Управление взаимоотношениями с клиентами —
mySAP Customer Relationship Management • Управление жизненным циклом продукта —
mySAP Product Lifecycle Management • Управление взаимоотношениями с поставщика-
ми — mySAP Supplier Relationship Management • Управление логистической сетью — mySAP
Supply Chain Management
выбора решений не пришли к нам сами собой, а по- явились в результате целого ряда проектов плюс ре- гулярное обучение внутри компании с обменом опы- том в мировом масштабе. В то же время сотрудники компаний малого и среднего бизнеса выбирают сис- тему для управления предприятием не каждый день, да и не каждый год. Кроме того, у потребителей и продавцов зачастую очень разные задачи. Покупате- лям часто не нужно самое технологическое и пер- спективное в мире решение.
Более того, им вообще
не очень интересен продукт сам по себе. Все, что им нужно, это некая информационная система, которая решит их проблемы в бизнесе как можно быстрее и за приемлемые деньги. Поверьте, если бы их проб- лемы решались на уровне шаманских плясок, то они бы купили большой бубен, ничуть не беспокоясь о его «несоответствии мировым тенденциям». Просто так получилось, что бубен не помогает, а вот хорошая ин- формационная система — наоборот.
глава 09
внедрение
Стандартный процесс внедрения системы управле- ния компанией состоит из следующих этапов: 1. Анализ деятельности предприятия. 2. Разработка стратегий автоматизации. 3. Выбор системы. 4. Реорганизация деятельности. 5. Внедрение системы. 6. Использование (эксплуатация + сопровождение).

"+":

"-":

вывод:

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

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 лет назад Генри Дэвид Торо, люди становятся орудиями в руках собственных средств.
Я провел годы в лотерейном бизнесе, где все делается в экстремальных условиях, поскольку это единственный способ существования и развития отрасли. Если вы не желаете работать в таком режиме, то не сможете играть в этой песочнице. Разработчики в данной отрасли мирятся с таким положением, поскольку им доставляет удовольствие добиваться успеха в краткосрочных и в высшей степени интенсивных проектах и получать взамен значительную свободу действий, включая, в частности, двухмесячные
отпуска между проектами. Эти команды считают себя элитой, и компании всячески поддерживают такие убеждения.
Молодые, неженатые трудоголики – это именно то, что требуется многим организациям для их безнадежных проектов.
Военные игры помогают вам оценить свои относительные достоинства и недостатки, и помогают организации в целом оценить свои слабые и сильные места.
Наиболее эффективной для участников формой военной игры, позволяющей стимулировать творческий беспорядок, является командная игра.

"+":

"-":

вывод:

Вечерняя работа..и как нужно управлять

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


"+":
боремся с кризисом
подарил хороший подарок-урок
сооздали классные промо-материалы (а еще подсатвку для кружек и наклейки)
организаю взаимоотношения с клиентами.
управляем проектом =)
всего по немногу)
помогаю друзьям.


"-":

вывод:

люблю праздники- можно хорошо поработать)

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

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

еще заново прослушал некоторые книги трейси и тд.. воодушевляет)

"+":

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

"-":

вывод:

кратко Джон вон эйкен HR

source
Описание:
Джон вон эйкен HR суть работы отдела в поиске самых лучших и талантливых людей и их развитие для увеличения стоимости фирмы.

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

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

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

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

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

"+":

"-":

вывод:

кратко Грехи Лидерства

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


"+":

"-":

вывод:

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

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)



"+":

"-":

вывод: