Здравствуйте, Undying, Вы писали:
U>Т.е. я утверждаю, что разработка программы принципиально не отличается от разработки автомобиля и изготовления его опытного образца. Соответственно подходы применяемые в разработке автомобилей и изготовлении опытных образцов автомобилей вполне могут работать и в программировании. Как, к примеру, программистские шаблоны проектирования появились на основе изучения архитектурных шаблонов проектирования. А вот между изготовлением серийного образца программы и серийного автомобиля нет ничего общего, т.к. серийная программа изготавливается по нажатию F5, а для изготовления серийного автомобиля надо еще пахать и пахать. Соответственно подходы пригодные для изготовления серийных изделий, совершенно не пригодны для изготовления программ.
Угу вот только опытные образцы как раз изготавливаются высококвалифицированными разработчиками, (и это не только конструкторы и дизайнеры, но и слесаря) места для индусов там нет, практически получается описанный тобой первый вариант. Правда ты почему-то считаешь что он исключает специализацию, но это не так.
Здравствуйте, Undying, Вы писали:
U>Gaperton описывает не производственный подход, а лишь его часть в виде изготовления серийных изделий. Естественно этот подход не пригоден для разработки программ, равно как он не пригоден и для разработки автомобилей. Т.к. технологическая карта это результат работы конструкторов и технологов, а не методика описывающая как конструкторам и технологам надо работать. Соответственно все эти IDEF0/SADT пригодны для описания работы рабочего на конвейере, но не пригодны ни для описания работы рабочих опытных цехов, ни уж тем более для описания работы конструкторов и технологов.
Угу только очень большая часть IT управленцев даже этого не понимает.
U>Еще двадцать лет назад программисты были очень сильно лимитированы в ресурсах, соответственно требования эффективности не позволяли широко использовать универсальные решения, поэтому тогда перейти к специализации труда возможности не было. И только в последние двадцать лет ситуация поменялась, соответственно программирование в его современном виде очень молодая профессия.
Спорно, в том же автомобилестроении скудность ресурсов не мешала, не помешала она и японцам организовывать фабрики программирования на ассемблере, там все было заиндустриализировано до предела, что не помешало им пролететь, они кстати вполне аналог и по времени и по организации фордовского конвейера. Да и 20 лет срок более чем достаточный.
Здравствуйте, FR, Вы писали:
FR>Угу вот только опытные образцы как раз изготавливаются высококвалифицированными разработчиками, (и это не только конструкторы и дизайнеры, но и слесаря) места для индусов там нет, практически получается описанный тобой первый вариант. Правда ты почему-то считаешь что он исключает специализацию, но это не так.
Для изготовления опытного образца обычно нужны работники самой различной квалификации, от токаря 6 разряда, которого действительно нужно готовить дольше, чем основную массу конструкторов и технологов, до подсобного рабочего, от которого по большему счету кроме исполнительности ничего не требуется. В программирование все тоже самое.
Здравствуйте, FR, Вы писали:
FR>Угу только очень большая часть IT управленцев даже этого не понимает.
Это их проблемы.
FR>Спорно, в том же автомобилестроении скудность ресурсов не мешала, не помешала она и японцам организовывать фабрики программирования на ассемблере, там все было заиндустриализировано до предела, что не помешало им пролететь, они кстати вполне аналог и по времени и по организации фордовского конвейера. Да и 20 лет срок более чем достаточный.
Я еще раз повторяю, что конвейер это отличный способ производства серийного изделия, в программировании серийных изделий нет в принципе, есть только опытные. Соответственно было бы странным, если бы у японцев что-то получилось.
Здравствуйте, Aviator, Вы писали:
A>Проблема в том что покупаешь кота в мешке. Как например проверить, что кандидат не зная веба сможет за два месяца войти в струю и начать приносить пользу?
Я правильно понимаю, что мы ведем речь о случае, когда специалисты по вебу у нас есть и решения типовых задач уже написаны?
В этом случае если нужен кодер, то нас должны интересовать следующие качества: определенный уровень (не особо высокий) алгоритмических и архитектурных навыков, способность решать задачи по аналогии, умение работать с документацией, исполнительность, здравый смысл. Собственно опыт работы с вебом будем бонусом, но не особо большим.
U>Для изготовления опытного образца обычно нужны работники самой различной квалификации, от токаря 6 разряда, которого действительно нужно готовить дольше, чем основную массу конструкторов и технологов, до подсобного рабочего, от которого по большему счету кроме исполнительности ничего не требуется. В программирование все тоже самое.
Конечно, но проблема в том, что подсобных рабочих много не требуется, часто даже меньше чем квалифицированных, и схема пять высокооплачиваемых инженеров плюс 100 низкоквалифицированных и соответственно низкооплачиваемых рабочих не работает.
Ну и даже квалификация "подсобного рабочего" в программировании или "кодера" требуется достаточно высокой, для других областей работник с таким требуемым временем обучения и требуемыми навыками считается достаточно высококвалифицированным специалистом.
Здравствуйте, Undying, Вы писали:
U>Я еще раз повторяю, что конвейер это отличный способ производства серийного изделия, в программировании серийных изделий нет в принципе, есть только опытные. Соответственно было бы странным, если бы у японцев что-то получилось.
Ну так они по сути и воплотили то что ты предложил:
пойти по пути других производственных профессий, разделяя программистов на конструкторов, технологов и рабочих(кодеров)
Здравствуйте, FR, Вы писали:
FR>Конечно, но проблема в том, что подсобных рабочих много не требуется, часто даже меньше чем квалифицированных, и схема пять высокооплачиваемых инженеров плюс 100 низкоквалифицированных и соответственно низкооплачиваемых рабочих не работает.
Так и в непрограммной разработке все то же самое. Опытные цеха обычно по численности как бы не меньше, чем ИТР будут.
FR>Ну и даже квалификация "подсобного рабочего" в программировании или "кодера" требуется достаточно высокой, для других областей работник с таким требуемым временем обучения и требуемыми навыками считается достаточно высококвалифицированным специалистом.
А что в других производствах не бывает высококвалифицированных рабочих? Того же высококлассного токаря нужно готовить лет пятнадцать, куда там программистам. Деление на конструкторов, технологов и рабочих это в первую очередь не деление по квалификации и времени подготовки, а деление по классу решаемых задач.
Здравствуйте, FR, Вы писали:
FR>Ну так они по сути и воплотили то что ты предложил: FR>
FR>пойти по пути других производственных профессий, разделяя программистов на конструкторов, технологов и рабочих(кодеров)
Ты вроде только что утверждал, что они пытались внедрить в программирование аналог конвейера, а не просто ввести разделение на конструкторов, технологов и рабочих. Если не сложно опиши в общем в чем состояла идея японцев.
Здравствуйте, Undying, Вы писали:
U>Ты вроде только что утверждал, что они пытались внедрить в программирование аналог конвейера, а не просто ввести разделение на конструкторов, технологов и рабочих. Если не сложно опиши в общем в чем состояла идея японцев.
Они пытались внедрить самые передовые тогда методы промышленности в софтостроение, тошиба хитачи и другие монстры этим занимались,
цель была обогнать Америку
Ну и благих целей было немало, и улучшение качества и меньшая зависимость от разработчиков и предсказуемость и т. п. http://www5d.biglobe.ne.jp/~y-h-m/An%20Approach%20to%20Cell-Based%20Software%20Factory-v.01.pdf
В результате у них получалось надежное ПО с достаточно предсказуемыми сроками, но при этом сами эти сроки разработки были
в разы дольше чем у американцев и требовали в те же разы больше рабочих ресурсов. Говорят их опыт частично переняли
индусы, ну и один из их главных идеологов до сих проталкивает (уже сильно измененную) технологию http://www.xosoftware.co.uk/Articles/WhatIsASoftwareFactory/
Здравствуйте, Undying, Вы писали:
FR>>Конечно, но проблема в том, что подсобных рабочих много не требуется, часто даже меньше чем квалифицированных, и схема пять высокооплачиваемых инженеров плюс 100 низкоквалифицированных и соответственно низкооплачиваемых рабочих не работает.
U>Так и в непрограммной разработке все то же самое. Опытные цеха обычно по численности как бы не меньше, чем ИТР будут.
Тогда не вижу плюсов твоей второй схемы.
FR>>Ну и даже квалификация "подсобного рабочего" в программировании или "кодера" требуется достаточно высокой, для других областей работник с таким требуемым временем обучения и требуемыми навыками считается достаточно высококвалифицированным специалистом.
U>А что в других производствах не бывает высококвалифицированных рабочих? Того же высококлассного токаря нужно готовить лет пятнадцать, куда там программистам. Деление на конструкторов, технологов и рабочих это в первую очередь не деление по квалификации и времени подготовки, а деление по классу решаемых задач.
Бывает, но почти нигде нет такого что совсем неквалифицированные работники вовсе не требуются.
Проблема в том что у нас "рабочему" требуются навыки "конструктора" и наоборот.
U>1) Трудности с набором сотрудников. Понятно, что точно также как и в любой другой профессии количество высококвалифицированных работников много меньше, чем общее число работников. Соответственно высококвалифицированных работников на всех не хватет и хватать не может. Если же мы берем (по ошибке или потому что других нет) работника менее квалифицированного, то он оказывается малополезен, т.к. при такой организации труда нет явно выделенных конструкторов и технологов, задачей которых было бы переформулирование исходной задачи в понятную менее квалифицированному программисту форму.
Вот тут кстати одна проблемка, часто это переформулирование занимает времени сопоставимо с тем которое требуется чтобы просто ее самому решить.
А в результате то, что первовариантный программист сделает скажем за N человеко-часов "технолог" и "рабочие" затратят 2N тех же человеко-часов.
При этом у первого качество наверняка будет лучше.
Схема архитектор — разработчики (это "технолог" + "рабочий" в одном флаконе) мне кажется более адекватной для
совтостроения чем "конструктор" + "технологи" + "рабочие".
Здравствуйте, FR, Вы писали:
FR>Вот тут кстати одна проблемка, часто это переформулирование занимает времени сопоставимо с тем которое требуется чтобы просто ее самому решить. FR>А в результате то, что первовариантный программист сделает скажем за N человеко-часов "технолог" и "рабочие" затратят 2N тех же человеко-часов. FR>При этом у первого качество наверняка будет лучше. FR>Схема архитектор — разработчики (это "технолог" + "рабочий" в одном флаконе) мне кажется более адекватной для FR>совтостроения чем "конструктор" + "технологи" + "рабочие".
Есть что добавить. Работал я раньше в одном НИИ. Там очень распространена схема "физик" + "математик" + вагон и тележка программистов = несколько лет работы.
В противовес этой схемы я знаю двух человек, которые занимались сами от и до своими задачами. Вот слова одного из них:
— Я посредственный физик, хреновый математик, и совсем никакой программист (тут он явно скромничал). Но трем человекам в моей голове очень легко договориться между собой.
Конечно, они решали разные задачи, но связка 3 в одном оказывалась более плодовита чем команда людей с разными специализациями. Случаев явно маловато для того чтобы говорить о каких-то правилах, но они имеют место.
Насколько я понял идея заключается в следующем. Используйте наши мегакрутые и мегауниверсальные решения и для разработки программного обеспечения вам понадобится только главный конструктор (архитектор) и толпа рабочих (кодеров). Это примерно тоже самое, что разрабатывать автомобиль не имея своего конструкторского бюро и используя только универсальные решения разработанными другими КБ. Честно говоря я сильно удивляюсь как такой подход хоть у кого-то работает. Для того, чтобы кодеры были эффективны, необходимо наличие прослойки конструкторов и технологов, которые будут переводить исходную задачу на понятный кодерам уровень.
FR>http://www5d.biglobe.ne.jp/~y-h-m/An%20Approach%20to%20Cell-Based%20Software%20Factory-v.01.pdf FR>В результате у них получалось надежное ПО с достаточно предсказуемыми сроками, но при этом сами эти сроки разработки были FR>в разы дольше чем у американцев и требовали в те же разы больше рабочих ресурсов.
Здесь в чем фишка вообще не понял, осталось только впечатление как о чем-то крайне зарегулированном. В творческой работе зарегулированность обычно работает плохо, и если это не взлетело даже у японцев с их специфическим менталитетом, то у остальных не взлетит подавно.
U>Насколько я понял идея заключается в следующем. Используйте наши мегакрутые и мегауниверсальные решения и для разработки программного обеспечения вам понадобится только главный конструктор (архитектор) и толпа рабочих (кодеров).
Это сейчас у них такая идея, наверно для индусов стараются
Раньше был прямой перенос индустриальных методов, вот тут http://www5d.biglobe.ne.jp/~y-h-m/EssenceOfToshibaSoftwareFactory.pdf более подробно
в историческом плане.
U>Это примерно тоже самое, что разрабатывать автомобиль не имея своего конструкторского бюро и используя только универсальные решения разработанными другими КБ. Честно говоря я сильно удивляюсь как такой подход хоть у кого-то работает.
Работает, и гораздо худшие работают, если не думать об эффективности.
U>Для того, чтобы кодеры были эффективны, необходимо наличие прослойки конструкторов и технологов, которые будут переводить исходную задачу на понятный кодерам уровень.
А вот тут по моему спорно. Программирование это практически конструкторское бюро и есть, и кодер это и есть аналог технолога для индустрии. Технологи же по сути и выполняют работу кодера переводят теоретически готовый продукт на реальное производство, кодер практически занимается этим же.
U>Здесь в чем фишка вообще не понял, осталось только впечатление как о чем-то крайне зарегулированном. В творческой работе зарегулированность обычно работает плохо, и если это не взлетело даже у японцев с их специфическим менталитетом, то у остальных не взлетит подавно.
Да, но до сих пор многие не понимают, Gaperton прав ментальность выработалась.
даже на реальном производстве рабочих поджимают станки, автоматы и т.д.
т.е. как только появляется значительный объем одинаковой рутиной работы он заменяется на специализированный станок, или на автомат.
в программированием с заменой рутиной работы на автоматику еще проще. если в реальном мире продвижение автоматики упирается в сложность распознавания картинки, сложность манипуляции с реальным миром, то внутри компьютера таких проблем нет.
можно зайти и с другой стороны:
больше всего программистов занято в прикладном программировании аля 1с и сайт-морда компании. но здесь основная трудность — это понять заказчика и переложить это на компьютер, и здесь требуется очень малый объем кодирования.
т.е. даже в самой распространенной группе нет потребности в кодировщиках, а есть высокая потребность в специалистах, которые могут поговорить с другими людьми, а потом это формализовать в той мере, которую понимает текущий уровень компьютеров.
если смотреть на рынок программирования, то в кодировщиках заинтересованы только крупные интеграторы — задачей которых является решать простые, но большие задачи.
у них из-за того, что задачи простые — нет потребности нанимать крутых программистов, и в тоже время из-за того, что задачи большие, тот человек который общался с заказчиком самостоятельно не может это закодить, а вынужден прибегать к помощи кодировщиков.
Здравствуйте, DarkGray, Вы писали:
DG>в программированием с заменой рутиной работы на автоматику еще проще. если в реальном мире продвижение автоматики упирается в сложность распознавания картинки, сложность манипуляции с реальным миром, то внутри компьютера таких проблем нет.
Так кто должен заниматься рутинными задачами? К примеру, клепать формочки на основе GridSynchronizer'а? Что такой работы мало? Для нее нужна высокая квалификация? Или ты такую работу уже автоматизировал?
Здравствуйте, DarkGray, Вы писали:
DG>первая работа — это работа постановщика задачи, а не кодировщика DG>второй работы, после того как сделана первая работа — очень и очень мало.
Я бы сказал, наоборот, первая часть работы это в типовых случаях 10% времени, а реализация — 90%.
DG>и если первое делается с помощью какого-то специализированного инструмента, а не с помощью paint-а, то вторая работа вообще нивелируется
Ты эти специализированные инструменты уже используешь или восхищаешься ими издали?
можно выделить три уровня исполнителей:
рабочий,
инженер,
ученый.
рабочий — гонит объем по инструкции(алгоритму), если произошло что-то выходящее за рамки инструкции, останавливает свою работу.
инженер — выполняет задачу разрешения противоречий (задачу оптимизации) на основе готовых наработок. так же формирует инструкции для рабочих
ученый — исследует классы задач, формируя готовые наработки по их решению.
этой классификации соответствуют уровни образования:
рабочий — колледж (реже только школа)
инженер — институт
ученый — университет+аспирантура
задача размещения элементов на форме — это оптимизационная задача, где необходимо свести воедино кучу противоречий и критериев.
в общем виде — эта задача не имеет пошагового алгоритма. (есть частные варианты, легко алгоритмизирующиеся, но обычно они сразу же и автоматизируются)
все это нас приводит к тому — что эта проблема требует уровня инженера, а не рабочего.
кодировщик — это уровень рабочего, а не инженера, и для данной задачи не подходит.
