Что не так с так с менеджментом в России как науки?

Евгений Равич пишет:
А про смену парадигмы?

Теперь мы будем играть во всё. Но врамках темы, под присмотром.

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

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

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

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

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

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

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

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

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

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

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

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

Этот вывод верен на 100%.

Это одна их ключевых компетенций рук. проектов - умение правильно задавать вопросы. 

Михаил Лурье пишет:
специалисты могут не захотеть ему помогать, а тем более исправлять его ошибки.

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

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

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

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

А для удачного формирования команды нужна перспектива.

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

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

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

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

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

Хотя конечно частично это должно присутствовать.

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

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

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

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

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

Хотя конечно частично это должно присутствовать.

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

Понимание отрасли должно быть.

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

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

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

Вы затронули одну из больных и часто обсуждаемых тем. Я, видимо, отношусь к тем, кто "не знаком с логикой проектного менеджмента" и считаю, что одна из бед нашего менеджмента (науки управлять) и состоит в том, что существет ошибочное мнение, что РП - это особая специализация и РП может ни бельмеса не понимать к примеру в ИТ, в строительстве, в энергетике. Секция автомобилестроения нам дала многолетний и устойчивый отрицательный пример таких РП. Был такой уже забываемый руководитель судпрома, который перешёл из автопрома. Тоже, типа, без разницы. Или руководил Роскосмосом бывший журналист. Хотя это и не уровень РП.

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

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

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

Да. Это действительно очень больгая тема. Единственное уточнение к Вашей идее:

Вы написали "существет ОШИБОЧНОЕ мнение. Таким образом, Вы не только обозначили наличие разных мнений и наличие проблемы, но и вынесли вердикт о заблуждении одной из сторон. Хотя перед этим сказали, что не знакомы с логикой РМ (имеется в виду, полноценное владение всем комплексом инструментов).

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

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

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

1. На позиции рук. проектов оказывается человек, который не знает ни РМ, ни предметную сферу. Тут вероятность провала самая высокая. Но при этом такая ситуация используется как аргумент против РМ, как самостоятельной функции (хотя и не является примером реализации этой функции).
2. Второй вариант - на позиции РП человек, который прошел обучение, но не поднялся по лестнице компетентности. По сути - теоретик, плохо владеющий инструментами РМ. Если он при этом не знает и предметную область, результат также маловероятен. Эта ситуация также используется как аргумент против самостоятельности функции РМ. Однако и тут нужно учитывать, что нельзя делать вывод о технологии на основе работы ученика или подмастерья.
3. Третий вариант - на позиции РП человек, который не знает РМ, но знает предметную сферу и имеет какой-то опыт и способности в руководстве. Тут вероятность успеха выше, хотя организационная эффективность таких проектов не высока. Но результат все же, как правило, получается. И это становится аргументом в пользу позиции "для руководства проектом нужно прежде всего знать предметную область". Это, как я понимаю, как раз и есть Ваша позиция.
4. Четвертый вариант - рук. проектов хорошо знает и владеет РМ (на реальном проф. уровне), но не владеет предметной областью. В этом случае как раз и происходит тот процесс, который я описал. Тут очень важно понимать, кто чем занимается и кто за что отвечает в такой системе. Мы привыкли, что "начальник" сам решает что и как делать. И именно поэтому должен знать предметную область. Но РП отвечает не за то, что лично выбоал решение, а за то, что грамотно применил правильные инструменты. Т.е. правильно подобрал экспертов, правильно организовал сбор данных и обсуждение, правильно организовал выработку решения на основе мнения экспертов, с помощью тех же экспертов правильно предусмотрел риски и альтернативы и т.д.  
   Такую логику сложно принять сходу, особенно не посмотрев на реальные успешные кейсы. 
5. Ну и пятый вариант - РП знает и технологи. РМ и предметную сферу. Для такой ситуации даже ввели специальный термин - не рук. проекта, а Директор проекта. Идея единоличной ответственности и принятия решений ближе нашим привычным представлениям. Т.е. такой руководитель может выслушать мнения, но решение примет сам и с учетом своего собственного мнения в предметной сфере. И вот тут возникает вопрос
   - если он следует правильной технологии выбора решений, то его мнение - это просто еще одно экспертное мнение. Оно не имеет приоритета. И если он уже собрал достаточно квалифицированных экспертов, то при разногласиях его мнение не может быть решающим.
   - а если он делает свое мнение решающим, то зачем ему эксперты и при чем тут реальные технологии РМ  

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

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

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

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

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

Вот тогда, может быть и можно избежать неприятностей.

Вы, как я понял, с таким подходом не согласны.

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

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

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

Зачем играть в товарища Огурцова?

Павел Вайнштейн пишет:

Ирина Плотникова пишет:
А Методология, (кстати, не понимаю, почему вы используете термин"технологии"),

Люди часто применяют термины "метод", "методика", "методология", вкладывая в них разные смыслы.

Формально, методолгия - это учение о методах, способах и стратегиях исследования предмета. Т.е. это не о том, как с помощью инструмента получить результат, а о том, как исследовать сам инструмент, объект обработки, их соответствие и т.д.

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

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

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

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

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

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

А что практика? Руководители называли слова "алгоритмы", "регламентация". Но звучало и "технология". Последний термин мне милее в логике моей привязанности к идеям Коржибски. И я стал использовать его, как термин для обозначения пусть и сложного, но алгоритмизированного и воспроизводимого инструмента.

Хотя даже в рамках наших дискуссий последних дней я столкнулся с ситуацией, что для кого-то технология - это не конкретное прикладное описание/инструкция, а что-то абстрактное.  

Понятно, подмена понятий в угоду толпе, так сказать )) А меня напрягает слово технология в данном контексте )

Павел Вайнштейн пишет:

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

Да. Это действительно очень больгая тема. Единственное уточнение к Вашей идее:

Вы написали "существет ОШИБОЧНОЕ мнение. Таким образом, Вы не только обозначили наличие разных мнений и наличие проблемы, но и вынесли вердикт о заблуждении одной из сторон. Хотя перед этим сказали, что не знакомы с логикой РМ (имеется в виду, полноценное владение всем комплексом инструментов).

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

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

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

1. На позиции рук. проектов оказывается человек, который не знает ни РМ, ни предметную сферу. Тут вероятность провала самая высокая. Но при этом такая ситуация используется как аргумент против РМ, как самостоятельной функции (хотя и не является примером реализации этой функции).
2. Второй вариант - на позиции РП человек, который прошел обучение, но не поднялся по лестнице компетентности. По сути - теоретик, плохо владеющий инструментами РМ. Если он при этом не знает и предметную область, результат также маловероятен. Эта ситуация также используется как аргумент против самостоятельности функции РМ. Однако и тут нужно учитывать, что нельзя делать вывод о технологии на основе работы ученика или подмастерья.
3. Третий вариант - на позиции РП человек, который не знает РМ, но знает предметную сферу и имеет какой-то опыт и способности в руководстве. Тут вероятность успеха выше, хотя организационная эффективность таких проектов не высока. Но результат все же, как правило, получается. И это становится аргументом в пользу позиции "для руководства проектом нужно прежде всего знать предметную область". Это, как я понимаю, как раз и есть Ваша позиция.
4. Четвертый вариант - рук. проектов хорошо знает и владеет РМ (на реальном проф. уровне), но не владеет предметной областью. В этом случае как раз и происходит тот процесс, который я описал. Тут очень важно понимать, кто чем занимается и кто за что отвечает в такой системе. Мы привыкли, что "начальник" сам решает что и как делать. И именно поэтому должен знать предметную область. Но РП отвечает не за то, что лично выбоал решение, а за то, что грамотно применил правильные инструменты. Т.е. правильно подобрал экспертов, правильно организовал сбор данных и обсуждение, правильно организовал выработку решения на основе мнения экспертов, с помощью тех же экспертов правильно предусмотрел риски и альтернативы и т.д.  
   Такую логику сложно принять сходу, особенно не посмотрев на реальные успешные кейсы. 
5. Ну и пятый вариант - РП знает и технологи. РМ и предметную сферу. Для такой ситуации даже ввели специальный термин - не рук. проекта, а Директор проекта. Идея единоличной ответственности и принятия решений ближе нашим привычным представлениям. Т.е. такой руководитель может выслушать мнения, но решение примет сам и с учетом своего собственного мнения в предметной сфере. И вот тут возникает вопрос
   - если он следует правильной технологии выбора решений, то его мнение - это просто еще одно экспертное мнение. Оно не имеет приоритета. И если он уже собрал достаточно квалифицированных экспертов, то при разногласиях его мнение не может быть решающим.
   - а если он делает свое мнение решающим, то зачем ему эксперты и при чем тут реальные технологии РМ  

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

Отличная классификация.

Михаил Лурье пишет:
Особенно, это актуально, когда РП тебя "учит жизни"

Т.е. у РП нет цели успешно реализовать проект. Эта цель для него в лучшем случае на втором месте. А на первом - самоутердиться, показать кто главный, реализовать логику "я начальник - ты дурак". Так?
Это не профессилнальный РП. 

Михаил Лурье пишет:
очень возможна реакция, ну раз ты такой умный, то делай, как знаешь!

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

Отличная у нас команда проекта собралась! Успеха этому проекту..)) 

Задач РП не учить жизни, а помочь, направить и организовать. 

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

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

Михаил Лурье пишет:
Вы, как я понял, с таким подходом не согласны.

Да. И последовательно поясняю почему.
- формулирую суть подхода
- формулирую причины его возникновения
- поясняю альтернативную логику

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

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

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

Я футболом не увлекаюсь, но мне интересно, а в футбольной команде один игрок дает пас другому тоже просто из опасения, что если не даст, его потом поймают за гаражами и начистят морду?

*********************

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

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

• Типовые в противовес уникальным
• Проекты с малым кол-вом задач и участников в противовес проектам с большим кол-вом задач и участников    

Ирина Плотникова пишет:
Понятно, подмена понятий в угоду толпе, так сказать ))

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

Ирина Плотникова пишет:
А меня напрягает слово технология в данном контексте )

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

Павел Вайнштейн пишет:
Подумайте о мотивации участников проекта. Не в отношении данного проекта а вообще об их мотивах.

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

Также обратите внимание на разницу между типовым и уникальным проектом. В типовом проекте все проще и требования к валификации РМ ниже.

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

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

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

То есть я хочу сказать, что пойти работать в проект это не предел мечтаний!

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

Люди должны друг к другу притереться!

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