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

AVK>>А вот если неизвестно ...
AF> Подобные — исследовательские проекты — особый случай.

Что такое особый случай? Если ты намекаешь на то что такая ситуация встречается редко, то это не так.

AF> Во-первых от них, как правило не требуется такое качество ПО и его надёжность кода, как для ракетостроения или финансов.

Отнюдь. Качество кода требуется всегда.

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

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

AF> Даже если это исследования связанные с теорией компиляторов или с ИИ — всё равно качество кода здесь — не на первом месте.

А вот к примеру создание ОС — там тоже качество кода не на первом месте?

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

Ну ты же сам начал оспаривать высказанное.

AF>Более того, у нас же в жизни вообще ничего больше нет, кроме нашего опыта.

Неа. Есть еще логическое мышление.

AF> Если к нему нельзя обращаться — то к чему можно? Не верь глазам своим?

Обращаться можно. Обобщать нужно очень осторожно.

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

А ты эти примеры привел?

AF>Это при условии, что он халтурит всегда. А если, как чаще всего и бывает — он хорошо работает в том проекте, который ему интересен и плохо на саппорте, например, — как тут быть?

Это означает что его квыалификация в конкретном проекте высокая, а в целом не очень.

AF>Если бы тебя на саппорт засунули лет на 10 — ты уверен, что работал бы с энтузиазмом или вообще работал бы, а не халтурил?

А меня бы туда не засунули.

AVK>>>>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
AF>>> А вот это во многом зависит от того, как распределять работу.
AVK>>Нет, это, прежде всего, зависит от задач проекта.

AF> Например?

Например пишем ядро сервера приложений. Как ты думаешь — там много кусков, которые можно поручить новичку?

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

AF>Но не всей команды в целом. А это очень существенная разница. Тем более, что достаточно квалификации всего одного члена команды — руководителя — оказаться низкой и всё на смарку.
Не надо преувеличивать роль PM, если у тебя грамотная команда разработчиков, то они не дадут PM-у завалить проект. В крайнем случае, если они увидят что PM делает полную туфту, они эскалируют проблему на более высокий уровень.
Главное, чтобы члены проектной команды были адекватно промотивированы, но это уже другая история.

AF>В связи с чем возникает интересный вопрос — чей уровень квалификации наиболее критичен для проекта — всегда ли ответ один или есть несколько вариантов — схем построения эффективной команды?

AF>>> Бывает и обратная ситуация — когда команда высококвалифицированных спецов, а руководство слабенькое. Результаты зачастую получаются удручающие.
AVM>>Бывает, и достаточно часто.
AF>Бывает. Но разве это то, к чему стоит стремиться?
Естественно, к этому стремиться НЕ надо.

AF>>>

AF>>> Как говориться лучше стадо баранов под предводительством льва, чем стадо львов под предводительством барана.

AF>>> (С) — Увы, забыл
AVM>>Понимаешь в чем тут засада. Стадо баранов под предводительством льва смогут только очень громко блеять. Если в этом суть проекта, то да success обеспечен. А вот качественный программный продукт от баранов не получить. Никак не получить.

AF>Да нет. Суть-то как раз в том, что это львы под руководством барана блеют. А вот лев может суметь заставить баранов рычать. Вот тут как раз написано об одном подобном случае.

Заставить — нет, научить — да.
Ты не сможешь заставить человека сделать то что он не умеет делать, если предварительно не научишь его делать это.
Идея понятна?

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

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

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

AVM>>>У тебя похоже проектная команда = команда студентов.
AF>>Отнюдь. Я имел в виду команды, где руководящий состав (разный, в зависимости от проекта и ситуации — иногда один менеджер, он же тим-лидер, а иногда целая группа менеджеров, спецов по предметной области, аналитиков, архитекторов) — умелый и эффективно организует процесс, ....
AVM>Я не пойму о чем мы спорим, ты говоришь то же что и я только другими словами
Так я вроде и не спорю. Просто меня удивило то, каким образом из моего поста про то, что команды студентов навичков грамотно управлялись был сделан вывод, что у них нет ПМ... Особенно когда он там был.

AF>> ... а вот исполнители — те кто пишут код или выполняют тестирование — новички, без особого опыта или квалификации.
AVM>Ты никогда не встречал архитектора, которого вот-вот хватит кандратий, после того как он в 10-й раз сделал code review "новичка, без особого опыта или квалификации"?
Встречал. Правда видел и таких, которые бедолагу доводили сами до состояния камикадзе, летящего на встречу теплому ветру...

AVM>CMMI 3 в нашей жизни очень редкая вешь. Я не в том плане, что сертификатов мало раздадено, а в том что денег эта штука жрет немеряно и не всякий заказчик захочет покупать качество по таким ценам. Причем даже наличие полного CMMI не гарантирует успех проекта.
Абсолютно согласен. Правда здесь причины неуспеха кроются уже не в качестве ПО. Обычно это уже ошибки управления, а ещё чаще — ошибки общения с клиентами.

AVM>>>Я не утверждаю, что тогоко команда из супер-пупер гуру может выдавать на гора качественный код. Я говорю, что квалификация проектной команды должна учитываться в первую очередь.
AF>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет. ....
AVM>Есть, причем прямая связь.
То есть ситуация, когда есть две команды, у первой квалификация в среднем выше, и она проваливает проект, а вторая его делает — это прямая связь?
Или всё-таки стоит рассмотреть, что вы имеете в виду под квалификацией команды? Кого конкретно в команде?

AVM>>>Ты можешь выстроить процессы, которые расчитаны на средний уровень квалификации разработчиков и делать качественный софт. Но IMHO ключевое слово тут не процессы, а средний уровень квалификации , потому что процессы ты сравнительно легко можешь менять и затачивать под конкретную ситуацию. А вот изменить уровень квалификации проектной команды обычно намного тяжелее.
AF>> Как раз-таки наоборот — гораздо важнее процессы, а квалификация — вторична.
AVM>ISO 9000 предусматривает ответственность руководства за обучение персонала.
Совершенно верно.
AVM>Если же "квалификация — вторична", то к бьющемуся в истерике гуру-архитектору, присоединиться гуру-менеджер проекта... И будут они вместе тосковать, глядя на стадо разработчиков.
А что им тосковать — будут учить. Потом никто и не предполагает в реальном проекте брать 100 новичков на одного ПМ и архитектора. Обычно есть градация от новичков до выскоквалифицированных профи, притом и тех и других должна быть определённая пропорция.

AF>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
AVM>Не надо смешивать теплое с твердым.
AVM>Представь себе другую жизненную ситуацию, тебе надо поштукатурить стены в квартире. Ты будешь искать:
AVM>a) хорошего прораба?
AVM>b) хороших штукатуров?
А вот это зависит от размеров квартиры и того, построена она или нет.
Эта аналогия не совсем применима, по той причине, что перештукатурить совсем не так дёшево, как переписать код.

AF>> Вот для управления и для ключевых сотрудников, вроде Тим-Лида — вот там квалификация действительно важна.
AVM>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.
AVM>Но мое IMHO мне подсказывает, что в реальном проекте, запросто может появляться новичек-разработчик за которым недесмотрели и который может наворотить столько, что потом три тим-лида не разберуться.
А что есть квалификация Тим-лида и ПМ'а — как не умение смортеть за этими самыми разработчиками?

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

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

AF>>Но не всей команды в целом. А это очень существенная разница. Тем более, что достаточно квалификации всего одного члена команды — руководителя — оказаться низкой и всё на смарку.
AVM>Не надо преувеличивать роль PM, если у тебя грамотная команда разработчиков, то они не дадут PM-у завалить проект. В крайнем случае, если они увидят что PM делает полную туфту, они эскалируют проблему на более высокий уровень.
AVM>Главное, чтобы члены проектной команды были адекватно промотивированы, но это уже другая история.

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

AF>>Да нет. Суть-то как раз в том, что это львы под руководством барана блеют. А вот лев может суметь заставить баранов рычать. Вот тут как раз написано об одном подобном случае.
AVM>
AVM>Заставить — нет, научить — да.
AVM>Ты не сможешь заставить человека сделать то что он не умеет делать, если предварительно не научишь его делать это.
AVM>Идея понятна?
+1
Согласен.

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

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

AVK>>>А вот если неизвестно ...
AF>> Подобные — исследовательские проекты — особый случай.

AVK>Что такое особый случай? Если ты намекаешь на то что такая ситуация встречается редко, то это не так.

Просто приведи пример. Уж тебе то наверняка хорошо известно, что новичкам и простейшее приложение с единственным окном кажется мистической задачей В каких конкретно ситуациях не известно как писать? И кому не известно — младшему? Архитектору? Тим Лиду?

AF>> Во-первых от них, как правило не требуется такое качество ПО и его надёжность кода, как для ракетостроения или финансов.

AVK>Отнюдь. Качество кода требуется всегда.
Но разное качество. Врядли кто то будет ожидать от исследовательской программы по лингвистике той же стабильности, что и от ОС реального времени.

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

AVK>Совершенно верно, если добавить в списочек еще один пункт — решение задач программирования.
Тоже верно. Но не всегда они на первом месте.

AF>> Даже если это исследования связанные с теорией компиляторов или с ИИ — всё равно качество кода здесь — не на первом месте.

AVK>А вот к примеру создание ОС — там тоже качество кода не на первом месте?
Но это и не исследовательский проект, о котором шла речь.

AF>>Более того, у нас же в жизни вообще ничего больше нет, кроме нашего опыта.
AVK>Неа. Есть еще логическое мышление.
На основе чего?

AF>> Если к нему нельзя обращаться — то к чему можно? Не верь глазам своим?
AVK>Обращаться можно. Обобщать нужно очень осторожно.
Согласен. К чему всех нас и призываю.

AF>>Тем более, что ничто не мешает привести собственные примеры, которые опровергнут, дополнят, расширят или изменят моё утверждение.
AVK>А ты эти примеры привел?
Пожалуйста. Мне известно несколько человек из разных НИИ, которые держат эдакий кафедральный бизнес — пишут софт на сторону для промышленных заказчиков. Софт пишут при помощи студентов, чья квалификация оставляет желать лучшего. Качество софта на уровне (была возможность убедиться в этом).

AF>>Если бы тебя на саппорт засунули лет на 10 — ты уверен, что работал бы с энтузиазмом или вообще работал бы, а не халтурил?

AVK>А меня бы туда не засунули.
От тюрьмы и от сумы не зарекайся. От саппорта кстати тоже.

AVK>>>>>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
AF>>>> А вот это во многом зависит от того, как распределять работу.
AVK>>>Нет, это, прежде всего, зависит от задач проекта.

AF>> Например?
AVK>Например пишем ядро сервера приложений. Как ты думаешь — там много кусков, которые можно поручить новичку?
Это зависит от новичка и того, как поручать. Если новичок толковый, схватывает быстро, ему подробно всё обяснить и следить за тем что он делатет — то вполне можно. Другой вопрос — хотите ли вы этим заниматься и не хочется ли вам это сделать самим

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

AF>Просто приведи пример. Уж тебе то наверняка хорошо известно, что новичкам и простейшее приложение с единственным окном кажется мистической задачей В каких конкретно ситуациях не известно как писать? И кому не известно — младшему? Архитектору? Тим Лиду?

Никому не известно. Вот, к примеру, спроектировали мы некую подсистему, но совершенно неясно как ее реализовать. Никому в команде. Поручишь ее реализацию новичку?

AVK>>Отнюдь. Качество кода требуется всегда.
AF> Но разное качество. Врядли кто то будет ожидать от исследовательской программы по лингвистике той же стабильности, что и от ОС реального времени.

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

AVK>>А вот к примеру создание ОС — там тоже качество кода не на первом месте?
AF> Но это и не исследовательский проект, о котором шла речь.

Про исследовательские проекты придумал ты.

AVK>>А меня бы туда не засунули.
AF> От тюрьмы и от сумы не зарекайся. От саппорта кстати тоже.

Это почему это (я про саппорт)?

AF>>> Например?
AVK>>Например пишем ядро сервера приложений. Как ты думаешь — там много кусков, которые можно поручить новичку?
AF>Это зависит от новичка

Каким образом?

AF> и того, как поручать.

А как надо?

AF> Если новичок толковый, схватывает быстро, ему подробно всё обяснить и следить за тем что он делатет — то вполне можно.

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

AF> Другой вопрос — хотите ли вы этим заниматься и не хочется ли вам это сделать самим

Дело не в хотении, а в целесообразности.

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

AF>Более того, у нас же в жизни вообще ничего больше нет, кроме нашего опыта. Если к нему нельзя обращаться — то к чему можно? Не верь глазам своим?

AVK очень точно высказался по поводу изведанности. Для неизведанного опыт не даёт ответа на вопрос "Как надо делать?". Опыт даёт только ответ на вопрос "Как НЕ надо делать?". Поэтому, к опыту надо обязательно обращаться, но только с теми вопросами на которые он может дать ответ.

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

AF> Вот именно потому, что я её улавливаю, я и затеял этот пост.
AF> Если спросить кого-либо на прямую о том, согласен ли он с данным тезисом — врядли найдётся на форуме много тех, кто с этим согласится. Но вот если начать читать посты, то сразу бросается в глаза, что в пылу полемики об этом часто забывают. Я даже не говорю про мегафлейм вокруг оберона, даже в постах про более приземлённые языки зачастую ошибки рассматриваются исключительно в контексте языка программирования.

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

AF> Да и потом, Влад, я же вовсе не тебя имел в виду

Это не важно.


AF> Я же не говорил, что она не является достоинством. Тем более, что сам думаю, что она полезна. Но как прекрасно показано здесь

Автор: eao197
Дата: 05.06.05

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

AF> Спасибо! Про рефакторинг и средства разработки я вообще не подумал, хотя следовало бы

Чем дальше в лес, тем они играют все большую и большую роль.

AF> А как по твоему влияют на оное процесс разработки и менеджмент проекта?

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

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

AVM>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.

Власть сама по себе не страшна. Страшна власть, которая потворствует принятию "судьбоносных" решений.

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

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

AF>>Просто приведи пример. Уж тебе то наверняка хорошо известно, что новичкам и простейшее приложение с единственным окном кажется мистической задачей В каких конкретно ситуациях не известно как писать? И кому не известно — младшему? Архитектору? Тим Лиду?

AVK>Никому не известно. Вот, к примеру, спроектировали мы некую подсистему, но совершенно неясно как ее реализовать. Никому в команде. Поручишь ее реализацию новичку?
Нет конечно.
Правда тут есть два момента. Проектирование и реализация. Проектирование — конечно не поручишь, а вот реализацию вполне можно. Хотя согласен, что гораздо надёжнее её поручить профи.

AVK>>>А меня бы туда не засунули.
AF>> От тюрьмы и от сумы не зарекайся. От саппорта кстати тоже.

AVK>Это почему это (я про саппорт)?
Потому как неисповедимы пути БГ... Я вот знаю бывшую звезду советской науки — который сейчас как раз в саппорте и работает.

AF>>>> Например?
AVK>>>Например пишем ядро сервера приложений. Как ты думаешь — там много кусков, которые можно поручить новичку?
AF>>Это зависит от новичка

AVK>Каким образом?

AF>> и того, как поручать.

AVK>А как надо?

AF>> Если новичок толковый, схватывает быстро, ему подробно всё обяснить и следить за тем что он делатет — то вполне можно.

AVK>Как показывает практика — не помогает. Вышеозначенный тип кода обладает одной особенностью — затраты на его реализацию сильно меньше затрат на проектирование. Если составить подробнейший план, то новичек конечно справится. Но на практике же поступают обычно так: проектируют не столь тщательно и все тонкие места программист допроектирует при реализации. Это сильно быстрее вариант с подробнейшим проектом. Есть еще одна засада — зачастую при добавлении нового функционала требуется рефакторинг старого. Предусмотреть это заранее очень сложно. Итого — попытка использовать новичка в подобных проектах приводит к отрицательному результату. Хотя, конечно, иногда так поступают, но не ради того чтобы получить пользу от новичка, а для того чтобы из новичка сделать спеца.

AF>> Другой вопрос — хотите ли вы этим заниматься и не хочется ли вам это сделать самим

AVK>Дело не в хотении, а в целесообразности.

Вот с этим я полностью согласен.

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

AVK>>Никому не известно. Вот, к примеру, спроектировали мы некую подсистему, но совершенно неясно как ее реализовать. Никому в команде. Поручишь ее реализацию новичку?
AF> Нет конечно.
AF> Правда тут есть два момента. Проектирование и реализация. Проектирование — конечно не поручишь, а вот реализацию вполне можно.

Ты сам себе противоречишь.

AF> Хотя согласен, что гораздо надёжнее её поручить профи.

И гораздо эффективнее, что характерно. И качество результата кардинально лучше.

AVK>>Это почему это (я про саппорт)?
AF> Потому как неисповедимы пути БГ... Я вот знаю бывшую звезду советской науки — который сейчас как раз в саппорте и работает.

Его личные проблемы. У меня пока таких планов нет и работу пока можно выбирать свободно.

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

AF> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.

так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

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

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

AVK>>>Никому не известно. Вот, к примеру, спроектировали мы некую подсистему, но совершенно неясно как ее реализовать. Никому в команде. Поручишь ее реализацию новичку?
AF>> Нет конечно.
AF>> Правда тут есть два момента. Проектирование и реализация. Проектирование — конечно не поручишь, а вот реализацию вполне можно.

AVK>Ты сам себе противоречишь.
В чём?
С тем, что новичку врядли стоит поручать решение вопроса о том, что и как делать — я согласен. Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно. В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

AF>> Хотя согласен, что гораздо надёжнее её поручить профи.

AVK>И гораздо эффективнее, что характерно. И качество результата кардинально лучше.
А вот это большой вопрос. Если соотношение проектирование к реализации — заметно в пользу проектирования — тогда конечно. А вот если соотношение обратное...

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

VD>Так может это просто твое восприятие? Просто когда речь идет о языке, то не логично обсуждать, к примеру, качества программиста. Сравнивая языки мы подразумеваем, что инструмент в руках приблизительно одинаковых по классу специолистов.

Согласен. Но как быть с тем, что можно вязть одну пару специалистов одного уровня — которые не занимаются тестированием и другую — которые занимаются тестированием. Результаты будут разными. Потому, что не языком единым определяется качество ПО.

VD>Чем дальше в лес, тем они играют все большую и большую роль.
Да, такая тенденция хорошо прослеживается.

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

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

AF>> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.

Д>так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

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

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

AVK>>Ты сам себе противоречишь.
AF>В чём?

AVK>>Поручишь ее реализацию новичку?
AF> Нет конечно.

...

AF>Проектирование — конечно не поручишь, а вот реализацию вполне можно.

AF>Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно.

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

AF>В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

Вон как ты заговорил. А помнишь о чем я изначально написал? О том, что возможность использования слабоквалифицированной рабочей силы зависит от проекта.

AVK>>И гораздо эффективнее, что характерно. И качество результата кардинально лучше.
AF>А вот это большой вопрос. Если соотношение проектирование к реализации — заметно в пользу проектирования — тогда конечно.
AF> А вот если соотношение обратное...

Но изначально ты спорил с тем что это зависит от проекта.

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

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

AVK>>>Ты сам себе противоречишь.
AF>>В чём?

AVK>

AVK>>Поручишь ее реализацию новичку?
AF>> Нет конечно.

AVK>...

AF>>Проектирование — конечно не поручишь, а вот реализацию вполне можно.

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

AF>>Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно.

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

В зависимости от системы, а так же от того, какова цель — если научить новичка (о чём ты же сам и написал) — то вполне можно делать и так.

AF>>В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

AVK>Вон как ты заговорил. А помнишь о чем я изначально написал? О том, что возможность использования слабоквалифицированной рабочей силы зависит от проекта.

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

AVK>>>И гораздо эффективнее, что характерно. И качество результата кардинально лучше.
AF>>А вот это большой вопрос. Если соотношение проектирование к реализации — заметно в пользу проектирования — тогда конечно.
AF>> А вот если соотношение обратное...

AVK>Но изначально ты спорил с тем что это зависит от проекта.
А спорил не с тем, что это зависит от проекта, а с неявно высказанным тезисом о том, что невозможно обеспечить высокое качество при низкой квалификации части команды. Вот этого возможно достичь в любом проекте. Подчёркиваю: при условии, что прочие требования к проекту (сроки, деньги, политическая обстановка и т.п.) принципиально это позволяют.

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

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

В любом (почти) проекте есть части, которые не требуют квалификации, но требуют рутинной работы и терпения. Рисование формочек, написание оберток к библиотекам, и т.д. и т.п. И что, за такую работу ты тоже посадишь специалистов высокой квалификации?

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

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

AF>В зависимости от системы,

Что, собственно, и требовалось доказать.

AVK>>Вон как ты заговорил. А помнишь о чем я изначально написал? О том, что возможность использования слабоквалифицированной рабочей силы зависит от проекта.

AF>Я сколько помню придерживаюсь одной и той же точки зрения с самого начала.

А о чем ты тогда спорил со мной? Я ничего другого и не утверждал.

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

Не зависит это от сроков. Это зависит только и исключительно от целей проекта. Если уже есть профессиональная команда, то разьавление ее новичками только ухудшит ситуацию.

AVK>>Но изначально ты спорил с тем что это зависит от проекта.
AF>А спорил не с тем, что это зависит от проекта, а с неявно высказанным тезисом о том, что невозможно обеспечить высокое качество при низкой квалификации части команды.

Здорово. Сам придумал и сам же споришь с чем придумал.

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

Д>В любом (почти) проекте есть части, которые не требуют квалификации, но требуют рутинной работы и терпения.

Вопрос только в количестве такой работы. Бывает что ее недостаточно чтобы загрузить даже одного единственного человека.

Д> Рисование формочек, написание оберток к библиотекам, и т.д. и т.п. И что, за такую работу ты тоже посадишь специалистов высокой квалификации?

Да, если ее немного. В итоге обойдется дешевле.