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

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

N_C>>Соответственно одним из способов минимизировать этот риск является полное выведение этого человека из проекта. И ничего страшного в этом нет.
КЛ>Так если из проекта вывести работящего сотрудника, а оставить на проекте тех, кто работать не хочет или не умеет, гипотетический риск развала проекта превратится в суровую данность.
Не все так однозначно. Во-первых если весь проект держится на одном сотруднике это очень большой риск для организации, разрабатывающей проект. Потом, те, кто по Вашим словам не хотят/не умеют работать на самом деле могут быть просто демотивированы самим присутствием этакой звезды. И как только эта звезда уйдет "за горизонт" у них все наладится. Если не умеют — тоже не проблема. Вырастить подходящие кадры можно, главное, чтобы они хотели. Еще раз повторюсь, что для того, чтобы делать выводы надо обладать всеми данными, чем мы не обладаем. И в случае развития именно такого сценария (убирание из проекта звезды), проект вполне реально сможет и выжить (правда несколько замедлив темпы развития), а может и умереть.
И именно поэтому я говорю, что такая ситуация возможна. А вот почему Вы делаете вывод, что это однозначно плохо, остается для меня загадкой.

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

C>Правильно ли я понимаю, что участие в проекте любого разработчика, чей уровень значительно превышает уровни остальных, увеличивает риски проекта?
Смотря какие...

Но вот кстати говоря. А зачем такой разработчик на проекте? Если для проекта нужна разработка (т.е. простой кодинг) то мне, как ПМу более важны следующие качества разработчика: аккуратность, внимательность к деталям, точность в оценке трудоемкости звоей будущей работы, а главное чтобы то, как он оценил, так и работал. Уровень разработчика мне ни о чем не говорит — он может быть прекрасным кодером, но ему будет трудно изучать новые технологии, он может быть очень умным и буквально схватывать все новое, но посредственным разработчиком, когда дело дойдет до рутины.

Звезды нужны в стартапах, или там, где нужен прорыв, а в обычной работе они бывают зачастую даже вредны именно из-за своей звездности.

Здравствуйте, Nikolay_Ch, Вы писали:

C>>Правильно ли я понимаю, что участие в проекте любого разработчика, чей уровень значительно превышает уровни остальных, увеличивает риски проекта?
N_C>Смотря какие...

N_C>Но вот кстати говоря. А зачем такой разработчик на проекте? Если для проекта нужна разработка (т.е. простой кодинг) то мне, как ПМу более важны следующие качества разработчика: аккуратность, внимательность к деталям, точность в оценке трудоемкости звоей будущей работы, а главное чтобы то, как он оценил, так и работал. Уровень разработчика мне ни о чем не говорит — он может быть прекрасным кодером, но ему будет трудно изучать новые технологии, он может быть очень умным и буквально схватывать все новое, но посредственным разработчиком, когда дело дойдет до рутины.

У нас наверно разное понимание терминов разработка и простой кодинг.
Простой кодинг может быть нужен только в случае, если кто-то уже составил подробные требования, архитектуру и разжевал все возможные сложности "простому кодеру". Т.е. опять таки нужен или ведущий разработчик\тим лид\архитектор (давайте не будем говорить о звёздах — т.к. это настоящая звезда — очень редкое явление) уровнем выше остальной команды.
Единственная ситуация где предложенный вами подход возможен — это самая примитивная версия аутсорса, когда здесь набираются только junior/middle разработчики и тестеры. Т.е. это у заказчика болит голова о возможном уходе специалистов.

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

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

Здравствуйте, Nikolay_Ch, Вы писали:

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

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

Но такое разделение труда, заметьте, никак не избавляет Вас от необходимости держать квалифицированных специалистов. Кто-то же всё равно должен "вытрясать" требования из Заказчика и составлять ТЗ, а кто-то — проектировать архитектуру. Такое разделение труда просто поможет Вам содержать меньшее количество квалифицированных специалистов. Оно так же поможет Вам занять этих специалистов квалифицированной работой, свалив всю рутину на середнячков.

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

Поэтому попытка решить эту проблему заранее намеренным увольнением архитектора, ИМХО, глупость. Ничего это шаг не решит и ничему не поспособствует.

Здравствуйте, AndrewJD, Вы писали:

ГВ>>Ай, молодец.
+1

ГВ>>Хм, нужно быть просто дисциплинированным до икоты человеком, чтобы зная о том, что всё равно прима задержится на пять минут, приходить строго в назначенное время.
тоже верно... только прийти можно и вовремя. и начинать работу тоже вовремя, раз чайника своего пока нету.
правда не поверю что за первые 5 минут успели бы обсудить\утвердить что-то немерянно важное... в любом случае нервы дороже. Понятно что тут психология и понятно раздражение bkat — ну так это тоже маленький секретик обретения чайничка... но я не говорю что это хорошо!

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

Кстати, если без паренька с чайником ничего ни решить, ни сделать не могут — наверное это что-то все же да значит?

AJD>Митинг может быть с людьми из другого офиса, с партнерами из-за рубежа, просто льюдьми которые слабо знают этого ведущего специалиста. И что теперь куча народа, у которых могут быть также другие митинги и неотложные дела, должны сидеть ждать пока кто-то соизволит прийти?
ждать не стоит — в конце концов, вся эта вежливость запросто может ударить по королю, если это действительно кому-то будет нужно\важно сверху. Умные шефы закрывают глаза на все эти вещи до поры, а потом очень быстро припоминают, когда надо звезду вернуть на землю. Если команду в примере bkat так напрягает необязательность паренька со стигматом — почему бы не напрячь управляющего процессами\командой, чтобы наладил дисциплину? Любую звезду могут административным способом вернуть на землю, если это реально нужно вышестоящим — по крайней мере за 15 лет обратных примеров я не видел. А звезд повидал.

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>Понятно что тут психология и понятно раздражение bkat — ну так это тоже маленький секретик обретения чайничка... но я не говорю что это хорошо!

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

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

В общем даже примадонном стоит все же иногда работать с оглядкой на коллег.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я не пытаюсь сказать, что специалист всегда безгрешен, просто критику нужно обосновывать.

Естественно никто не безгрешен.

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

Здравствуйте, bkat, Вы писали:

B>Конкретно сейчас есть объективные причины, почему примадоннам позволено много чего
B>и почему они вообще существуют среди разработчиков.
B>Рынок перегрет и работников реально не хватает.
B>Это сказывается и еще как.

Слушай, извини, конечно. Что ты мелешь?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, bkat, Вы писали:

B>>Конкретно сейчас есть объективные причины, почему примадоннам позволено много чего
B>>и почему они вообще существуют среди разработчиков.
B>>Рынок перегрет и работников реально не хватает.
B>>Это сказывается и еще как.

ГВ>Слушай, извини, конечно. Что ты мелешь?

он завидует

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Звезды нужны в стартапах, или там, где нужен прорыв, а в обычной работе они бывают зачастую даже вредны именно из-за своей звездности.

Пошла и говорит с досадою: "Ну что ж!
На взгляд-то он хорош,
Да зелен — ягодки нет зрелой:
Тотчас оскомину набьешь".

И.А. Крылов. "Лисица и виноград"

Здравствуйте, Nikolay_Ch, Вы писали:

__>>странный способ — превращать риск в свершившийся факт действительно, риска после этого уже нет. нет риска потерять сотрудника, если его выгнать
N_C>Это нормальный процесс минимизации риска. Только надо понимать, что риском здесь является не увольнение сотрудника, а развал проекта в случае его увольнения. Соответственно одним из способов минимизировать этот риск является полное выведение этого человека из проекта. И ничего страшного в этом нет.

Странная позиция. Главный риск в данном случае формулируется как "потеря возможности продолжить работы по проекту вследствие увольнения ключевого сотрудника". И очень странный способ его понижения — вывести самого сотрудника. Прямо гильотина в качестве лекарства от головной боли. Хотя проблема вовсе не в сотруднике, поскольку минимизация риска здесь должна сводиться к "приобретению возможности продолжить проект в случае увольнения ключевого сотрудника". Что нужно для того, чтобы продолжить проект, если КС уволился? Правильно — документация и исходные тексты. Следовательно, как будем снижать риск? Правильно — исходники в CMS, документацию туда же. Контролируем факт наличия документации и организуем управление артефактами проекта. Как минимум — управление требованиями и КУ.

Как это всё решается отстранением КС — тайна сия велика есть.

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

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

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

N_C>По-моему, он просто предлагает просчитать риски и начать процесс их минимизации. Если одним из способов минимизировать риск будет увольнение сотрудника... что-ж — это только один из способов.

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

Я конечно понимаю, что для слабых менеджеров уволить "звезданутого" сотрудника — лучшее решение. Но ребята, если вы хотите быть сильными менеджерами, то не стоит решать трудности убеганием от них. Нужно учиться работать со всякими сотрудниками, если они приносят прибыль компании. Компании, типа, Microsoft и Google вообще пытаются набирать только "звёзд" и успешно с ними работают. А вас при виде одной "звезды" начинает бить лихорадка.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Слушай, извини, конечно. Что ты мелешь?
Спокуха на лице.
"Держите себя в руках или за вас это сделают другие". (с)

P. S.
Кто тут мелет — еще большой вопрос. =)

Здравствуйте, bastrakov, Вы писали:

Мда.. Честно говоря, я поражен..

Здравых мыслей прозвучало почему-то очень мало, а вот воинствующий максимализм в острой форме, как-то нездорово процветает..
Весна что ли? =)

1. Мы не видим ситуацию из нутри и не можем быть уверенными, кто там на самом деле вносит диссонанс в стройные отношения.
2. Практика показывает, что в таких ситуациях, в большинстве случаев, оказывается виноват именно "примадонна", "звезда", "КС"
3. Практика же показывает, что наличие на проекте "звезд", вовсе не гарантирует его успешного завершения.
4. Она же показывает, что для успешности проекта наличие "звезды" вовсе не обязательно.
5. Управлять командой без "звезд" — проще, тут на выручку приходят формальные процессы, в большем количестве. Это конечно скажется на результате, но сейчас торжествует принцип good enough.
6. Проблема со "звездами" в том, что они расслабляют весь остальной коллектив. Причем это происходит на иррациональном уровне — башкой человек понимает, что этот шлемазл, сидящий на против — заслужил чайник и возможность приходить позже на два часа, а он сам пока нет. А хочется, черт возьми, все равно таких же благ. Эта ситуация жутко озлобляет и демотивирует.

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

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

Анатомия CIO : Легенды и мифы Древней Греции

Нельзя, чтобы деятельность зависела от людей

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

C>У нас наверно разное понимание терминов разработка и простой кодинг.
Скорее разное понимание звездности.

C>Простой кодинг может быть нужен только в случае, если кто-то уже составил подробные требования, архитектуру и разжевал все возможные сложности "простому кодеру". Т.е. опять таки нужен или ведущий разработчик\тим лид\архитектор (давайте не будем говорить о звёздах — т.к. это настоящая звезда — очень редкое явление) уровнем выше остальной команды.
Хм... А если их не будет, то и разговора нет. Я не говорю, что старших не должно быть, я говорю про случаи присутствия "звезд" на проекте. Звезда — это понятие очень сложное.

C>Единственная ситуация где предложенный вами подход возможен — это самая примитивная версия аутсорса, когда здесь набираются только junior/middle разработчики и тестеры. Т.е. это у заказчика болит голова о возможном уходе специалистов.
Странный вывод. У Заказчика в любом случае болеть голова не должна. А эта схема нормально работает там, где есть действительно четкое разделение между ролями. Если разработчик и разрабатывает архитектуру и реализовывает ее и пишет тестовые сценарии и прочее и прочее, тогда действительно нужны звезды. Хотя я не особенно много видел в том числе и звезд, которым бы нравилось все это делать. Обычно все-таки разработчик напирает на то, что он должен разрабатывать, а все остальное пусть делают другие.

C>А любая, сколь угодно большая толпа из junior/middle программистов никогда не сделает хорошего продукта даже по лучшему в мире процессу.
Хм. Не согласен. Если собрать звезд в такой проект тоже лучше не станет. Нужен баланс. В тех частях проекта, где нужен быстрый результат — пожалуйста звезду (но опять-же надо смотреть какую...), там где уже все четко прописано и продумано — звезда будет только мешать.

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

C>Настоящая цель — это быстрая разработка конкурентноспособного ПО. Помоему, эта цель часто теряется за многочисленными ложными целями (а на самом деле — всего лишь средствами) вроде: формализованных процессов, управлениями рисками, повышением значения LoC, и прочее и прочее.
У бизнеса цель одна — заработать денег. И чем меньше рисков при большей отдаче, тем лучше. А вот все остальное, как раз и подчинено это основной цели.

Здравствуйте, Nikolay_Ch, Вы писали:

C>>У нас наверно разное понимание терминов разработка и простой кодинг.
N_C>Скорее разное понимание звездности.

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

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

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

C>>Единственная ситуация где предложенный вами подход возможен — это самая примитивная версия аутсорса, когда здесь набираются только junior/middle разработчики и тестеры. Т.е. это у заказчика болит голова о возможном уходе специалистов.
N_C>Странный вывод. У Заказчика в любом случае болеть голова не должна. А эта схема нормально работает там, где есть действительно четкое разделение между ролями. Если разработчик и разрабатывает архитектуру и реализовывает ее и пишет тестовые сценарии и прочее и прочее, тогда действительно нужны звезды. Хотя я не особенно много видел в том числе и звезд, которым бы нравилось все это делать. Обычно все-таки разработчик напирает на то, что он должен разрабатывать, а все остальное пусть делают другие.


Т.е. если правильно разделить роли, то и обезъянок можно использовать?

C>>А любая, сколь угодно большая толпа из junior/middle программистов никогда не сделает хорошего продукта даже по лучшему в мире процессу.
N_C>Хм. Не согласен. Если собрать звезд в такой проект тоже лучше не станет. Нужен баланс. В тех частях проекта, где нужен быстрый результат — пожалуйста звезду (но опять-же надо смотреть какую...), там где уже все четко прописано и продумано — звезда будет только мешать.

Никто и не говорил о команде из одних звёзд, а о том что группа junior/middle программистов не может самостоятельно реализовать серьёзный проект. А прописать и продумать тоже ведь кому-то надо? Т.е. всё равно нужен тим лид/архитектор — называйте его как хотите.


C>>Настоящая цель — это быстрая разработка конкурентноспособного ПО. Помоему, эта цель часто теряется за многочисленными ложными целями (а на самом деле — всего лишь средствами) вроде: формализованных процессов, управлениями рисками, повышением значения LoC, и прочее и прочее.
N_C>У бизнеса цель одна — заработать денег. И чем меньше рисков при большей отдаче, тем лучше. А вот все остальное, как раз и подчинено это основной цели.

Естественно. Софтостроительный бизнес деньги зарабатывает написанием конкурентноспособного софта (оставим здесь случаи откатов и т.п.) — т.е. качественно, лучше чем у других и быстро. Хотя можно конечно соревноваться с индусами, кто дешевле человеко-час продаст. Здесь конечно рисков мало, но и о большой отдаче можно забыть.
Для того, чтобы хорошо заработать всегда необходимо брать на себя большИе риски. Никто ещё не стал милионером кладя деньги в банк на депозит .

C>Правильно ли я понимаю, что участие в проекте любого разработчика, чей уровень значительно превышает уровни остальных, увеличивает риски проекта?

Если следовать такой формулировке, то я уже давал ответ — "Зависит от многих факторов. Однозначно нельзя утверждать это, как и нельзя утверждать обратное."

C>В разработке ПО талантливые люди — это основной и самый лучший актив, который можно придумать. А любой разработчик уровнем выше остальных в любом случае будет вносить больший вклад в проект (иначе зачем ему платить большую зарплату) и соответственно его уход будет заметнее.
Талантливый человек и звездный человек — это разные люди. Сразу оговорюсь, что я не рассматривал в этой дискуссии талантливых людей.

C>Т.е. если правильно разделить роли, то и обезъянок можно использовать?
Как это не парадоксально — то думаю ответ будет "да". Вопрос только в том, что долго расжевывать придется. Естественно, что эффективность будет ниже, чем вы возьмете профессионалов своего дела.

C>Никто и не говорил о команде из одних звёзд, а о том что группа junior/middle программистов не может самостоятельно реализовать серьёзный проект. А прописать и продумать тоже ведь кому-то надо? Т.е. всё равно нужен тим лид/архитектор — называйте его как хотите.
С этим я согласен, но разговор начинался не про иерархию проекта, а про "звезданутых" членов команды. Они могут быть на любой должности.

C>Естественно. Софтостроительный бизнес деньги зарабатывает написанием конкурентноспособного софта (оставим здесь случаи откатов и т.п.) — т.е. качественно, лучше чем у других и быстро. Хотя можно конечно соревноваться с индусами, кто дешевле человеко-час продаст. Здесь конечно рисков мало, но и о большой отдаче можно забыть.
Это как сказать. Современная (западная) культура насаждает идеологию потребления во главу всего. А при ней на первый план выходит отнюдь не качество. Вспомните те старые вещи (от автомобилей до телефизоров), которые работали десятилетиями. А что происходит сейчас? Качество для потребителя не главное. Главное — грамотный маркетинг.

C>Для того, чтобы хорошо заработать всегда необходимо брать на себя большИе риски. Никто ещё не стал милионером кладя деньги в банк на депозит .
Кхе-кхе... Чаще происходит наоборот. Большие деньги приходят не из-за рисков а из-за правильной политики. Опять-же это мое ИМХО — так я вижу окружающий мир. Примеров ситуаций, когда люди зарабатывают огромные состояния на огромных рисках очень мало, а когда грамотно сориентировались в политике — множество.

DB>Ага, ещё можно минимизировать риски поломки аппаратуры — продать её нафиг. Риск ухода зачазчика — самим послать заказчика нафиг. Да что уж мелочиться, можно распрадать все активы компании и положить деньги на надёжный депозит — вот уж где нет рисков! В финансах есть один тезис о том, что любое действие можно захеджировать в ноль, только прибыль от этой сделки после этого не привысит безрисковую процентную ставку.
А Вы представляете, что такое риск и как минимизировать потери от его наступления?

DB>Я конечно понимаю, что для слабых менеджеров уволить "звезданутого" сотрудника — лучшее решение. Но ребята, если вы хотите быть сильными менеджерами, то не стоит решать трудности убеганием от них. Нужно учиться работать со всякими сотрудниками, если они приносят прибыль компании. Компании, типа, Microsoft и Google вообще пытаются набирать только "звёзд" и успешно с ними работают. А вас при виде одной "звезды" начинает бить лихорадка.
Хм... Мне кажется, что Вы никогда не работали с такими звездами. А вот мне — пришлось. Тут как в волчьей стае — или ты ее обломаешь и заставишь работать в команде или она тебя. Тогда очень велик шанс развала команды. Слово-то какое КОМАНДА. А когда звезда начинает выпивать для себя преференции — команда заканчивается.
Есть еще третий вариант — убрать из команды ее вообще. Ну, это мы уже рассматривали.