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

А что имеется в виду под "девелопер"? Если это может быть и менеджер, и проектировщик, и тестер, то тогда...

Выберете один из вариантов и объясните почему именно так.

Вариант 5.


Все остальные варианты, отличные по сути от Варианта 5 ущербны . Тем более для Канады - это же не Россия. В среднем на Западе обычные программисты еще более хреновые архитекторы (судя по кол-ву вопросов про NF на тех же Mailgate.org и dbforums.com), чем российские, к-рые хоть и дремучие, но зато более изобретательные Левши

2 папа Карло:
Ты не внимательно тред читаешь. я сказал что нанимем только девелоперов (программистов если хочешь). проектные манагеры, бизнесс аналитики, тестеры и вся остальная тряхомудь есть. Нужны люди которорые программить только будут по постановке задачи.

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

developer (RUP)
A person responsible for developing the required functionality
in accordance with project-adopted standards and procedures.
This can include performing activities in any of the requirements ,
analysis & design , implementation , and test disciplines.

Даже если ты набираешь только программистов, то задачу все равно лучше уточнить! Например, ты можешь нанять 1 универсала (ОО + РДБ), а можешь нанять 1 ОО-программиста и 1 программиста БД (датабейсера), т.е уже имеем 1 человек vs 2 человека. И, кстати, во втором случае есть очевидные преимущества как, например, крутая специализация человека в ОО или БД соответственно (чего скорее всего нет в первом случае), большая доступность таких специалистов, но при этом их работу надо будет согласовывать.
Будем и дальше рассуждать абстрактно? О`кей! То есть ты хочешь выяснить как абстрактный расклад окладов влияет, например, на производительность в абстрактной команде? Повторяя в чем-то уже сказанное другими товарищами ранее...

Что касается лидера команды программистов ("горизонтальные" связи),
т.е главного/ведущего программиста (ВП), то он необходим ,
если такую функцию как постановка заданий, совместное обсуждение
архитектурны и ее реализации, а также координация работы программистов
не может выполняться проектировщиком или менеджером .
Кстати, необязательно, чтобы ВП был также и самый крутой специалист.
Основные требования к ВП - это:
а) общие знания во всех областях (программирование, БД и т.д), к-рыми
занимаются его подчиненные/координируемые программисты,
б) удержание в голове общей информации: общая архитектура/требования,
ответственности других программистов,
в) умение общаться как с программистами, проектировщиками, так и
с вышестоящим руководителем (менеджер).
Варианты: 1-4


Встает вопрос нужно ли и на сколько больше платить ВП по сравнению
с другими. Платить ВП больше необязательно . Ему даже можно
платить соответственно меньше , если он будет делать меньший
объем работ, чем его подчиненные программисты.
Варианты: 1-4


Что касается риска , связанного с уходом высокооплачиваемого
(т.е крутого и якобы необходимого) специалиста, то правильно - не следует
нанимать программиста, к-рый уникален поскольку если он уйдет, то
можно не найти другого такого же и проект может быть даже временно
остановлен. Но если исходить из того, что а) исползуется инженерный подход
и б) такой специалист может быстро продвинуть проект вперед в достаточно
короткие сроки, то можно рискнуть, и не побоявшись, что потом придется
менять конфигурацию команды.
Варианты: 1-4

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

2 Дмитрий Мыльников:
Ну и другая сторона вопроса. Сейчас существует множество книжек по управлению, где объясняется как заставить людей работать. Без всяких там команд и т.п. И застваляют и работают. Но я по своему опыту могу сказать одно, получившийся таким образом коллектив всегда имеет КПД не выше среднего. Да и уровень технических решений тоже будет средний. Хотя, наверное, в большинстве случаев этого достаточно.

Печальный у вас опыт, Дмитрий! Скорее всего сказывается то, что мы в России, где а) промышленный (инженерный) подход не распространен и б) ИТ-менеджеры, наверное, самые непрофессиональные из всех менеджеров, обитающих на территории РФ. А что вы хотели от полудикой и еще вчера социалистической экономики и относительно бесперспективной ИТ-отрасли? Сколько знаю таких (моя личная статистика для примерно 15 человек и в достаточно крупных московских компаниях), как правило, это бывшие ИТ-внедренцы и преподаватели ИТ-курсов , т.е те, кто уже раньше работал с людьми - это как правило в компаниях с ИТ-профилем, а также бывшие офис-менеджеры (!!!) или бывшие системные администраторы (!!) - это в компаниях помельче с не ИТ-профилем, к-рые прочитали пару книг по менеджементу или прослушали 2-недельный курс за 2,000$. Все они как правило кисломордые и вялые типы (т.е одним своим видом уже тоску на коллектив нагоняют) хотя внешне и строят из себя активных и деловитых личностей. А что вы хотели, если те, кто их перевел на эту должность такие же профаны? Хуже и то, что большинство ИТ-менеджеров не умеют активно решать проблемы , т.е решение только одно - нудный скулеж и надоедание, пинок под зад или отпуск на самотек - распространенный советский подход. А что вы хотели, если никто не занимается исследованием эффективности их работы и и премирование осуществляется по простому критерию "проект выполнен быстро/выполнен/не выполнен"? Но если есть грамотный менеджер пусть даже и самоучка, к-рый заражает всех позитивным и командным настроем да еще используется инженерный подход в разработке, то даже очень разные люди (возраст, профуровень, темперамент, национальность, благосостояние, пол и т.д) будут работать слаженно, дружно и весело. У меня такой опыт и этой генеральной линии я и стараюсь придерживаться

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

Не скажу чтобы я был каким-то гениальным
программистом. Но сколько себя помню, меня всегда интересовали
компьютеры и программы. Начинал еще с программ под самые первые
версии MS-DOS и Windows 1.0. Я был готов подолгу засиживаться
за компьютером, порой даже завтракая, обедая и ужиная на своем
"боевом посту"...
Посмотрите, как продвинулись технологии и возможности продуктов
компании Microsoft с тех пор! Сегодня в офисе Вы используете
самый удобный в мире и мощный по своим возможностям офисный пакет
- Microsoft Office 2000...
Сейчас мне 41 и в Microsoft мне дали офис с окном. Вы можете
подумать, что это обычное дело - офис с окном, но в Microsoft
это считается большой привилегией...
(помню читал в каком-то ИТ-журнале - статья, посвященная
Майкрософт и юбилею Б.Г.)

2 Серега:
Да не решаются такие "абстрактые" задачи. В ПРИНЦИПЕ не решаются. Это как выбор жены по каталогу по критериям красота/ум. 8-) ...

То что не решаются это понятно, но каталог-то полистать тоже неплохо. Особенно если там жены обнаженные ... :о)

2 Дмитрий Мыльников: \r
Репликант, а к чему эта цитата про Microsoft? :) \r
Ты пытаешься меня убедить, что Microsoft Office 2000 очень крутой и высокотехнологичный продукт? Тогда возможно, что ты хороший ИТ-менеджер, о которых пишешь, но плохой программист... \r
\r
Господь с тобой! Ты не понял намека или интонации, с к-рой я этот короткий отрывочек запостил? Язвительный юмор - раз, намек на успешную профанацию и выжимание бабок Майкрософтом - два, намек на безжалостную и неэффективную эксплуатацию программистов в Майкрософте - три. Мужику 41 и он лет 20 уже по клаве стучит, но только недавно офис с окном получил. Или ты только на "мощный по своим возможностям офисный пакет" обратил внимание? :о)\r
\r
Что же касается "печального опыта", то приведите нам примеры непечальных опытов, особенно не в России. Очень хотелось бы узнать. \r
\r
Есть непечальный опыт - у меня, например. Можно обсудить подробнее\r
\r
.. Да и на счёт "полудикой экономики" я не совсем уловил смысл. Я не знаю полудиких экономик, которые умеют производить ядерное оружие, сверхзвуковые самолёты и космические ракеты. \r
\r
Пожалуйста - российская экономика с ее коррумпированностью и чиновничьим произволом, усложненностью, непрозрачностью и запутанностью хозяйственных операций, с ее политической и правовой непрогнозируемостью, с гос-вом, к-рое не гарантирует основные права (неприкосновенность законной собственности)\r
\r
.. Для этого необходима ну очень продвинутая экономика с очень сложной и развитой инфраструткурой. Да и ИТ сектор в такой экономике тоже должен быть весьма продвинутый, если уж на то пошло. \r
\r
Ты путаешь продвинутую экономику (этого нет в РФ) с продвинутой промышленностью или технологиями (это в РФ есть)\r
\r
Что же касается создания команды и применения западных методик менеджмента, то вы на саомм деле лишь подтвердили мои выводы. Сами же и написали, что менеджеры, использующие западные методики "правило кисломордые и вялые типы (т.е одним своим видом уже тоску на коллектив нагоняют) хотя внешне и строят из себя активных и деловитых личностей". \r
\r
Во-первых, я пока не говорил про "западные методики менеджмента". Мне абсолютно все равно - западные или восточные методики, главное, чтобы они были эффективными . Во-вторых, основная мысль была в том, что менеджеров, кстати, как и руководителей надо готовить не поверхностно , как это делается в России, а тщательнее , т.е подбирать людей, склонных к лидерству и способных зажигать. Но главное их эффективную работу надо стимулировать , с них надо требовать, спрашивать и поощрять. У нас же одна из основных позорных ролей, к-рая отводится менджерам - это подгонять лентяев и присматривать, чтобы все сидели "от звонка и до звонка", т.е руководство из них негласно делает надсмоторщиков. А они должны двигать процесс, за к-рый они отвечают. Менеджеры (от руководителя компании и до самого мелкого менеджера) - это единственная живая сила, к-рая движет компанию к успеху. Никто другой, например, программисты в этом не заинтересованы потому что в их задачи это не входит\r
\r
... Но ведь это заражение позитивным и командным настроем как раз и есть создание хорошей слаженной команды. И только такая команда может создать действиетльно хорошую или даже выдающуюся вещь. \r
\r
Ты путаешь заражение позитивным и командным настроем c созданием хорошей слаженной команды . Я же ведь писал: \r
Т.е менеджер должен быть хорош, тогда у него даже исходно неслаженная команда будет слаженной и эффективно работающей при наличии профессионализма и грамотного подхода к созданию ПО\r
\r
.. А вот под управлением кисломордых менеджеров можно создавать только Microsoft Office 2000 и их подобие. Пусть даже и в офисе с окном. У меня в России, кстати, НЕ РАЗУ НЕ БЫЛО ОФИСА БЕЗ ОКНА, хотя фирмы были на порядки меньше Microsoft. Видимо в Microsoft офис с окном считают очень веским стимулом к повышению квалификации и качества работы. \r
\r
Да нет, в Майкрософте-то ребята веселые и достаточн профессиональные (сужу по ЗАО Майкрософт), но вот подспудные цели у них - это не все сразу и здорово , чтобы работа на будущее осталась. Так что менеджмент к качеству Office 2000 (с точки зрения пользователя) отношения не имеет. Кстати, в Майкрософт не так много и платят (тот же крутой спец в MCS уровня Федора Зубанова получает пордка 1500$), да и эффективность их подхода к созданию ПО оставляет желать лучшего. Для сравнения в Интел-Россия ведущие инженеры и программисты получают 1500-2000$ + нехилый соцпакет\r
\r
.. Одновременно это очень хорошо иллюстрирует отношение к людям в самой Microsoft. Мне, если честно, никогда бы в голову не пришло построить для своих людей здание, где есть офисы без окон. \r
\r
Ты все понимаешь очень буквально. Как ты себе представляешь здание без окон и в Америке? Нет, такого в Америке не бывает. В России - да. ((Я бывал в одной софтверной конторе, к-рая располгалась на ВВЦ в бывшем павильоне. Окон на средних этажах нет, только на нижнем, комнаты - это отгороженные пространства, но зато до потолка - не доплюнешь.)) В США же строгие требования к рабочему пространству и его характеристикам (освещенность, влажность, температура, наличие санузла и т.д) и в крупных компаниях они соблюдаются. Просто кто-то ( привилегированные ) сидит в офисах, к-рые по периметру здания и у них есть окна, а кто-то во внутренних офисах, в к-рых просто нет окон. Кстати, это положительное наследие СССР - такие офисные здания, когда любая комната имеет минимум 1 окно, кроме может кладовки. Но зато в США и Канаде офисы гораздо просторнее. Попробуй спросить у "папа Карло" - он небось сидит там один в таком, с кондиционером и аквариумом.. :о)\r
\r
В общем-то я достаточно хорошо представляю себе ситуацию в России и знаю, что проблем очень много. Но уже начинает раздражать, когда некоторые умники начинают кругом кричать о том, что всё российское "гавно" и что в России и СССР ничего делать не умели. \r
\r
А в этом топике что ли есть такой умник? Покажите-ка мне его и я первым брошу в него виртуальный булыжник! Также следует понимать разницу между суждениями типа "всё российское - "гавно" и "многое то, что российское - "гавно"\r
\r
2 vdimas: \r
.. Кислость - она может только у непрофессионала может быть, от осознания собственного непрофессионализма. :) На мой взгляд, в нашей профессии все очень интересно, скучать не приходиться, только успевай за технологиями. :) \r
\r
Да, а еще она может быть от того, что ты - главный в команде и можешь решать существенные вопросы, но ничего это тебе практически не дает (в материальном плане). Или еще ты просто такой хмурый человек, к-рый в себе, но к-рого собственная меркантильность или чья-то глупая воля швырнула на эту должность\r
\r
.. Кстати, кто сказал, что заражать позитивным настроем должен именно менеджер? А просто профессионал широкого профиля, несерьезный по-жизни, (но весьма качественно работающий) не пойдет? \r
\r
Подойдет, но для этого он должен общаться со всеми участниками и также регулярно как тот же менеджер. Вообщем через нек-рое время этот человек и будет выполнять 50% работы менеджера, т.е фактически и станет менеджером :о}\r
\r
.. Не подскажете, где там у вас такое происходит - резюме свое кину. Пора немного втряхнуть эту кислую московскую братию. :)) \r
\r
Только на собеседовании не проявляйте чрезмерную несерьезность или жизнерадостность. Этого не любят, так же как и чрезмерного профессионализма или требовательности к коллегам\r
\r
...К большому нашему сожалению, в эпоху раздела государственного имущества обогатились только торгаши и воры. Они же сейчас и пытаются делать бизнес в IT. Так что результат вполне ожидаемый. Просто требуется некоторое время, чтобы все вернулось на круги своя. ... \r
\r
Вот это уже слова не мальчика, а мужа! Только маленькая поправка: торгашей-воров ИТ-индустрия не интересует в отличие от той же торговли, обслуживания, серьезной промышленности или природных ресурсов. Поэтому ИТ-бизнесом руководят, как правило, бывшие начальники отделов автоматизации или программисты, порой оставшиеся еще с советских времен :о)

2 Дмитрий Мыльников:
А я тебе скажу почему "многое, что российское - гавно".
На сколько платят, на столько и работу делают. Я, кстати, в том числе. Когда заказчик не жадный, то он в итоге получает конфетку. А если жмот, то всё будет в пределах минимального соответствия техзаданию. Причём в этом случае решения будут те, на которые уйдёт меньше всего времени - лишь бы запустилось при сдаче. И так везде.

Я не понял как связана функциональность того же ПО с тем, что оно некачественное ("гавно") или что процесс его создания неэффективный ("гавно")?

Будут платить как положено - будет нормальное качество.

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

а) в процессе создания ПО нет механизмов, отвечающих за обеспечение
качества ,
б) заказчик не только особо не требует , но и не понимает какое
ему необходимо качество или что это такое вообще.

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

2 AISOFT: \r
Все зависит от того, что именно потребует заказчик, но если это качество может быть достигнуто, в приемлемое для заказчика время, и он готов за это платить, то это будет сделано. \r
\r
Вот-вот, но заказчик не будет ждать год-два, а также платить 100-200 тыс.$$. Подразумевались естественно разумно приемлимые сроки/стоимость. Большинство российских компаний просто не смогут, да и не возьмутся создавать качественное ПО в/за разумно приемлимые сроки/стоимость. Тем более традиционно сложившаяся конъюнктура и менталитет российского заказчика качества ПО/услуг не требуют . Отсюда частые сверхзатраты, сверхсроки, переделки ПО и т.д и т.п - прочие "прелести"\r
\r
\r
2 Дмитрий Мыльников: \r
В любой программе можно сделать миниум функций, при которых программа в принципе будет решать поставленную задачу. Но при этом пользоваться такой программой будет ну очень неудобно. В качестве примера см. продукты той же Microsoft ранних версий. ... \r
\r
Качество имеет точку зрения (т.з). С т.з пользователей, к-рые покупают Office - он возможно некачественный (неудобный) продукт, но с т.з менеджеров Майкрософт, отвечающих за Office и к-рые определяли требования (разработчикам Майкрософт, к-рые этот Office создавали) - Office качественный, т.е удовлетворяет их требованиямю. На всякий случай:\r
\r
Качество ПО (Вендров, Липаев)\r
совокупность свойств ПО, к-рые характеризуют способность ПО\r
удовлетворять заданным требованиям.\r
\r
или еще более общее определение:\r
\r
Качество (Розова, "Упрвление качеством")\r
совокупность характеристик объекта, относящихся к его способности\r
удовлетворять обусловленные или предполагаемые потребности.\r
\r
...Каждая потребность выражается рядом требований, которые\r
участвуют в формировании отношений пригодности объекта\r
для целей потребителя , служат для оценки соответствия\r
объекта его назначению...\r
\r
Кстати, вот и Момент Истины. Почему Б.Гейтс занялся и так разбогател именно на производстве ПО, а не производстве, например, пылесосов? Да потому что качество пылесоса (т.е требования к пылесосу) очень легко определить и тем более проверить ! Например, "длина-ширина-глбина -..см", "цвет - красный", "напряжение питания - 220В ± 5%, 50Гц", "потребляемая мощность - 1300Вт", "давление всасывания -.. ". А с ПО так просто не получится потому что это продукт со множеством характеристик :о)\r
\r
.. И, что интересно, неудобное ПО может быть вполне "качественным", также как и процесс его создания может быть ну очень эффективным. Хотя в итоге мы всё равно получим по сути "гавно". :) \r
\r
А что значит фраза: " неудобное ПО может быть вполне "качественным" "?\r
Я также не говорил, что нельзя с помощью эффективного процесса делать некачественное ПО; также как и то, что нельзя с помощью неэффективного процесса делать качественное ПО. Эффективность - это относительный показатель более низких затрат (временных, финансовых и т.д) на процесс. Определенные характеристики ПО (например, его качество) зависят от характеристик процесса (например, наличие контроля качества), но не все\r
\r
...Также как и выбор способа решения задачи. Многие задачи можно решить в лоб, просто неэффективно израсходовав ресурсы. Времени на написание такой програмы уйдёт намного меньше. При этом поставленная задача будет решаться и никаких ошибок и глюков не будет. Это "гавно" или как? :) ... \r
\r
Да, если задача решена полностью, т.е результат удовлетворяет полностью заказчика как на момент приемки, так и во время эксплуатации, то такое ПО будет качественным.\r
"Времени ... уйдёт намного меньше." - по сравнению с чем и почему это не наоборот, т.е когда ээффективно?\r
\r
Далее, какие бы эффектвиные механизмы контроля качества вы не применяли, если человеку при этом не платить, то качества вы всё равно не получите. .... \r
\r
Дмитрий, такие варианты, когда ничего не платить смысла рассматривать даже нет - в этом случае и процесса нет , т.к один и более исполнителей не фурычат вообще :о)\r
\r
... То есть, на самом деле для получения качественного продукта необходимо как минимум две составляющие. Первая - грамотная организация процесса, включая контроль качества и профессионализм исполнителей. Вторая - соответсвующая уровню затраченных усилий оплата. И никакие супер-пупер методики не помогут повысить качество, если второе условие не выполняется. \r
\r
Нет, неверно! Методики контроля и управления качеством (СУК) как раз и предназначены для "получения" качества и его улучшения. Именно эти механизмы и позволяют "выявить" безнадежного бракодела, а вторичные методики позволяют его а) либо исключить его из процесса, заменив другим более лучшим исполнителем, б) либо повысить его профессионализм. п.а) и б) естественно предполагают затраты, например, на обучение и повышение з/п, но это уже побочные затраты и прямого отношения к качеству они не имеют В идеализированном процессе с СУК, к-рый допускает постоянный подбор исполнителей все с более высоким профессионализмом даже основной процесс (создания ПО) на каком-то этапе начнет играть второстепенную роль\r
\r
То есть, я хочу сказать, что во многих случаях "российское гавно" не потому, что производящие его люди не умеют делать лучше, а потому, что для них, реальных исполнителей, это не имеет смысла. \r
\r
Дмитрий, ты опять "выступаешь" в защиту профессионализма российских разработчиков. Я с тобой солидарен! Но, пожалуйста, читай внимательнее то, что я уже писал выше. Согласно даже теории качества з/п тут не причем, т.к качество не зависит напрямую от з/п. С точки же зрения практики даже если тебе платить 1 млн $$ ты не "прыгнешь" выше своей головы, т.е выше среднего уровня твоего профессионализма\r
\r
---\r
З.Ы. Ну, "папа Карло"! Отпустил топик на самотек, скрывшись из виду. Нет чтобы рассказать как у них в Vancouver, BC борются за знак качества :о)

2 Дмитрий Мыльников:
Мне однажды довелось наблюдать как на одном из наших заводов пытались внедрить эту самую СУК. Начитались умных книжек, взяли стандарты ISO 900x и давай всякие там инструкции в больших количетсвах разрабатывать. Бились бились, а толку никакого. Почему? А потому, что всё это начианет работать только тогда, когда все участники процесса, включая конечных исполнтелей, в этом заинтересованы. Все эти ISO 900x помогают решить проблему качества на системном уровне, но лишь тогда, когда уже все остальные способы задействованы. ...

Хм, я это и так прекрасно знаю! Больее того ИСО 900х является очень общим и чрезмерно формализованным стандартом. Если делать все по нему на 100%, то можно просто погрязнуть в "лишних" процессах и документах. Если этот стандарт на предприятии еще будут внедрять и непрофессионалы , то результат будет печальным

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

Это ежу понятно. Насчет "неграмотный" - да, верно, но вот насчет "незаинтересованный" - очень сомнительно. Понятием заинтересованности почему-то часто оперируют (или спекулируют?) специалисты по качеству, хотя это понятие нигде не используется (ни в ИСО 9000, ни в TQM). Это неудачное понятие, т.к оно очень субъективное : а) не ясно как и в чем определять заинтересованность, как ее учитывать, б) не ясно как поддерживать заинтересованность исполнителей на постоянном и необходимом уровне, в) не ясна зависимость между стимулами (премии, карьерный рост и т.д) на поддержание заинтересованности определенного уровня

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

Дмитрий, это все опять абстрактные разговоры, что вот "не согласится", "хорошая зарплата" и т.д. Вообще уровень зарплаты определяется конъюнктурой рынка труда, если специалист только не уникальный. Про заинтересованность - выше.
Кстати, если обсуждать ситуацию для того же рынка Москвы и С-Петербурга, то она позволяет подготовить хорошего и относительно недорого специалиста на долгосрочной основе (контракт). Однако вместо этого те же московские компании предпочитают не подготавливать своих, а переплачивать "крутым" специалистам. Где смысл? Если начинать реорганизацию ИТ-индустрии, то ее надо начинать сверху, т.е прежде всего с руководителей

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

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

В общем, можно долго и красиво рассуждать о том, что "Согласно даже теории качества з/п тут не причем", но практика показывает, что такая зависимость есть. Причём эта зависисмость имеет, если так выразиться "точку насыщения". То есть, у каждого исполнителя есть урвоень зарплаты, после которого лучшего качества он уже обеспечить не сможет, сколько ты ему зарплату не повышай. И на счёт 1 млн. $$ ты почти прав :).

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

... Точно так же есть некая точка, ниже которой никакие СУК обеспечить качество не смогут. Просто потому, что исполнители не будут выполнять те инструкции и правила, которые эту самую СУК и формируют. В результате на бумаге всё будет красиво, завод даже может при этом иметь сертификат на соответсвие ISO 900x, но при этом всё также выпускать некачественный продукт.

Такие варианты, когда процесс не выполняется, да еще постоянно нет смысла даже и обсуждать - это либо саботаж, либо осознанное бракотворчество. А то, что зачастую в России сертификат ИСО 900х лишь для показухи я знаю :о)

2 Дмитрий Мыльников:
Слушай, Репликант, создаётся ощущение, что ты слушаешь, но не слышишь. :)

Мало ли там чего в книжках пишут. ...

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

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

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

Ну и что там твоя теория говорит по этому поводу?

По какому именно поводу? Выражайся, пожалуйста, точнее

Где качество продукции будет лучше и почему?

В твоем живописном рассказе не так много информации (имеющей отношение к качеству), чтобы делать какие-то выводы насчет качества. А вот "почему" я уже объяснял. См.мои предыдущие посты, начиная с Дата: 27 авг 03, 08:14 и позже

Какие там зависимости?

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

Замечу, что достаточно обоснованне решение задачи, поставленной первоначально приведено в книге В.Н. Буркова Д.А. Новикова " Как управлять проектами" (Ситег-ГЕО, 1997 г.) в разделе 4 "Стимулирование исполнителей" ,подраздел "Контрактные механизмы стимулирования" подраздел "Стимулирование в многоэлементных системах" \r
\r
Наконец взял я эту книжку у знакомого, чтобы посмотреть на решение. Да, решение обоснованное, но оно не является решением задачи "папы Карло" (назовем ее задачей, например, "выбора наилучшего состава команды" ). Напомню, что у него n - число участников команды не определено, т.е уже предлагался выбор из n=2 и n=3:\r
\r
Итак, у вас есть своя фирма и появился новый проект который требует ресурсы. У Вас есть 140 штук на зарплаты. Вы наймете: \r
\r
1. человека за 100 и за 40. \r
2. людей за 60, 40 и 40. \r
3. людей за 50, 50 и 40. \r
4. людей за 70 и 70. \r
\r
Выберете один из вариантов и объясните почему именно так. \r
\r
Т.е эта задача подбора наилучших исполнителей, исходя из их стоимости и уровня (знаний, опыта, навыков и т.д), а также хотя и в меньшей степени исходя из конъюктуры рынка труда.\r
Задача "стимулирования исполнителей" , к-рая в книжке - это совсем другая задача ("Стимулирование в многоэлементных системах", с.138). См. "Задача стимулирования" (с.55):\r
\r
"..Под системой стимулирования понимается соответствие между результатами деятельности\r
исполнителя и величиной выплат, получаемых им от руководства проекта. То есть выбором\r
системы стимулирования руководство проектом имеет возможность управлять выбираемым действием,\r
а, следовательно, и вероятностями оценок, то есть риском, а также сроками выполнения.\r
Итак, решив задачу стимулирования, мы определим вид взаимозависимости для исполнителей\r
качества, затрат, риска и сроков. ....\r
\r
Т.е эта задача отличается от задачи выбора наилучшего состава команды по своей цели. Однако, вот очень простая и и полезная в хозяйственном плане фраза выражающая суть решения (23) для варианта слабосвязанной системы (с.140):\r
\r
".. β характеризует «весомость» вклада результата i-го исполнителя в функцию дохода\r
ПМ. Чем больше этот вклад - тем больше надо платить. С другой стороны, C убывает по α ,\r
то есть, чем больше затраты на достижение одного и того же результата, тем меньше следует\r
платить исполнителю, так как его эффективность невысока. ....\r
\r
--\r
З.Ы. Интересно, у "папы Карло" эта книжка есть? Если нет, то придется заказывать из России (если ее вообще можно где-то заказать - тираж 3000 экз.). На всякй пожарный приведу ее полные реквизиты, т.к может еще кто заинтересуется:\r
\r
Бурков В.Н., Новиков Д.А. http://www.projectmanagement.ru/library/index.html] Как управлять проектами: Научно-практическое издание. Серия «Информатизация России на пороге XXI века». – М.: СИНТЕГ-ГЕО, 1997. – 188 с. (ISBN: 5-86639-029-9, м/о, цена: 75 р.)\r
\r
Просто немного о книжке. Книжка эта подробно и еще давно обсуждалась в паре форумов по PM и в ней ее авторы зачастую рассматривают слишком идеализированные или упрощенные ситуации (чтобы показать суть и как работает тот или иной экономический механизм, обосновать его математически), естественно, не имеющие ничего общего не то что с российской, но даже и с западной реальностью выполнения проектов, т.е книжка эта является теоретическим , а не практическим учебником по PM. Ее читателям также придется немного "пострадать" от обилия мат.выражений

1) при участии 3-х человек надежность проекта будет выше, так как в случае, если кто-то не справляется или уходит, есть человек, который уже в курсе дел и может прийти на замену \r
\r
Да, надежность будет несколько выше, а нагрузка на нек-рых или на всех меньше. Это положительный фактор. При уходе 1 исполнителя на замену придет другой, но все равно придется нанимать нового и вводить его в проект потому что 3 исполнителя это лучше, чем 2. Так же можно сказать, что и в команде из 2 исполнителей (вар.1,4), если уйдет 1, то его заменит другой. Однако это действительно было бы аргументом, если бы исполнители были подобраны так, что их навыки и характеристики проекта (сроки, объемы работ) позволяют иметь "запас" производительности. В случае если запаса нет, то в любом варианте 1-4 надо стараться избегать замен. Узнать возможен ли "запас" можно только уточнив условия задачи.\r
Просто к слову: например, на больших и длительных проектах иногда используют следующий дедовский метод - проектная команда (или ее часть) и ее работа тестируются на пилотном проекте - это небольшой проект, включающий те же работы и задания, что и будущий большой\r
\r
2) Предполагая, что эффективность людей пропорциональна их затребованной зарплате, при таком раскладе (один ведущий и, с небольшим отставанием, два ведомых), по-моему, будет более благоприятный психологический климат - менее опытные тянутся к более опытному и конкурируют между собой за право быть "основным ведомым" \r
\r
Да, такое явление имеет место быть, когда более опытные коллеги передают навыки или задают хороший стиль работы менее опытным, к-рые в свою очередь "подтягиваются" к их профессиональному уровню. Однако см.ниже :о(\r
\r
Правда, в этом варианте есть недостаток - если проект предполагает плотное взаимодействие исполнителей, возрастут потери времени на обмен информацией. \r
\r
Такие потери будут иметь место в любом проекте, где число исполнителей > 1. Всегда даже в очень маленькой команде должен быть центр ответственности, руководитель как, например, ведущий программист, если в команде происходит взаимодействие. Однако опять неясно является ли это недостатком, т.к не ясны условия задачи "папы Карло", т.е из:\r
проектные манагеры, бизнесс аналитики, тестеры и вся остальная\r
тряхомудь есть. Нужны люди которорые программить только будут по постановке задачи. \r
\r
вообще в принципе следует, что ведущий в принципе и не нужен, т.к исполнители вообще могут работать полностью независимо, если координация их работы происходит "наверху"

2 Циничный Кот: \\r
И второй момент. Прозвучало тут слово "тестер". И народ дружно позиционировал его стоимость как 25-50% от средней з/п девелопера. Это цифры как, от балды с потолка взяты или такой опыт есть? \\r
\\r
Такова статистика для з/п девелоперов и тестеров/специалистов по SQA. Разработчик всегда стоит дороже, чем последние два. Исключение может быть составляют проекты, где требуется высокая надежность, производительность и т.д (т.е сам процесс тестирования сложной системы - это отдельный проект) или когда необходимо аврально теститровать и "латать" уже готовый продукт. И потом разработчик разработчику рознь, т.е тот же программист может быть, например, Delphi+VB+Java/MSSQL+Oracle+Access, а может быть Delphi/IB. Естественно, что 1-й стоит дороже, чем 2-й при одинаковых навыках в Delphi\\r
\\r
Почему спрашиваю - мне пришлось столкнуться с людьми, обеспечивающими не совсем, правда, голое тестирование, а то, что называется умной аббревиатурой QA. Так вот, их стоимость была как минимум на 25% выше, чем средняя цифрра девелоперской зарплаты. \\r
\\r
RUP Doc:\\r
quality assurance (QA) \\r
The function of Quality Assurance is the responsibility of (reports to)\\r
the Project Manager and is responsible for ensuring that project standards\\r
are correctly and verifiably followed by all project staff.\\r
\\r
The Quality Assurance Plan is an artifact that provides a clear view\\r
of how product, artifact and process quality are to be assured. It contains\\r
the Review and Audit Plan and references a number of other artifacts developed\\r
during the Inception phase. It is maintained throughout the project.\\r
\\r
т.е в RUP под функцией QA подразумевается не только обеспечение качества создаваемого ПО, а контроль и поддержание качества процесса разработки. В том же RUP QA - это функция менеджера проекта (Project Manager). Поэтому это закономерно, что менеджер проекта стоит на 25% дороже разработчика. Но иногда QA путают или приравнивают к SQA (Software Quality Assurance), т.е эта деятельность, направленная на обеспечение качества именно ПО\\r
\\r
И могу сказать, что все эти затраты окупались с лихвой - масса проблем предотвращалась еще ДО их возникновения или давилась в зародыше. \\r
\\r
Каких именно проблем? Что касается проблем с ПО, то в зародыше - это когда проблемы с надежностью, производительностью и т.д обнаруживаются (моделированием) и устраняются еще на стадии проектирования , а не на стадии тестирования \\r
\\r
При всем моем уважении к данной идее о важности наличия толкового организатора, со словосочетанием "разное благосостояние" согласиться не могу. Это у вас Макдональдс получается какой-то - там тоже благосотояние у всех очень разное - у хозяев - известно какое, у манагеров - тоже неплохо. Ну а у простых работников - ну с голоду, говорят, не пухут... И все работают дружно и весело, зараженные специально обученными манагерами... \\r
\\r
Можете смеяться хоть до посинения, но только не понятно при чем здесь Макдональдс. В Макдональдсе менеджер может быть менее состоятельным, чем его подчиненный работник, но вот работают они действительно слаженно и дружно хотя униформа зачастую грязная. Благосостояние - это фактор, к-рый может сильно проявляться внешне и осложнять взаимодействие работников внутри проекта. Например, более состоятельные работники могут раздражать менее состоятельных своим жизненным апломбом, снисходительной манерой общения, демонстрацией дорогой одежды, аксессуаров и т.д, проще говоря, гламурностью . Задача грамотного менеджера - сделать так, чтобы все выглядели и подавали себя "одинаково", независимо от благосостояния\\r
\\r
Имхо, зависит. Не прямо, нетривиально, но положительная корреляция есть. Кто не согласен и считает что качество от з/п не зависит - ну проведите эксперимент, снизьте в два раза оплату сотрудников. Интересно, качество на том же уровне останется??? \\r
\\r
Вы бы почитали этот топик по-внимательнее, т.к мы с "Дмитрием Мыльниковым" все это уже обсуждали, см. пост (стр.2) и ниже\\r
\\r
Содержать приемлимый минимум программных ошибок и полностью соответствовать спецификации. \\r
\\r
Тем не менее, оно может быть неудобным в использовании или концептуально устаревшим или не содержать нужных функций или ... \\r
\\r
Я уже говорил (см. пост (стр.2)), что это ПО будет качественным , а не "качественным", т.к соответствует ТЗ (спецификации). Но если в ТЗ не были заданы требования к удобству эксплуатации (к эргономичности) или требования к каким-то нужным функциям, то это вина заказчика. Как результат ПО может оказаться "некачественным", т.к при приемке, почувствовав неудобства или обнаружив отсутствие каких-то функций заказчик может возопить о новых требованиях. Читайте внимательнее топик, чтобы мне не повторять по 2 раза, то, что уже говорилось. Топик Рассуждения о качестве в дурацкую погоду - продолжение темы качества\\r
\\r
В этом контексте возникает вопрос, чем должен заниматься специалист по качеству и сколько ему надо платить за т.н. "тряхомудь"... ;о) \\r
\\r
Я не специалист по "тряхомуди(ям)" :о)\\r
\\r
Не знаю как вы, а лично не встречал людей, готовых работать на износ за зарплату. \\r
\\r
Имелась в виду, конечно, не российская, а западная з/п для человека, к-рый в первый раз попал заграницу на вольные хлеба и почувствовал "запах" денег или вообще изначально "на крючке" у своего бизнес-спонсора