Здравствуйте, MxMsk, Вы писали:
MM>вчерашние студенты, которые даже грамотно составить резюме не умеют .
А я подержу — тут, на РСДН, у многих, даже у компететных, с руским ну-просто беда.
Здравствуйте, DarkGray, Вы писали:
DG>рабочий — гонит объем по инструкции(алгоритму), если произошло что-то выходящее за рамки инструкции, останавливает свою работу.
Это по твоему определение рабочего в общем случае? Вот к тебе сантехник пришел. Он рабочий? Ты что для него инструкцию как работать пишешь? Нет. Ты ему ставишь задачу как заказчик, т.е. в общих словах и не вдаваясь в специфику сантехники, т.к. ничего в этом не понимаешь. И принципиально постановка заказчиком задачи сантехнику ничем не отличается от постановки заказчиком задачи программисту. Соответственно вовсе не работа по инструкции является ключевым отличием рабочего от инженера.
Никаких инструкций у сантехника нет, сантехник руководствуясь требованиями заказчика сам принимает решения что ему делать, как ему делать и сам же выполняет собственно работу. Пока программист работает над задачей заказчика в одиночку его действия принципиально ничем от действий сантехника не отличаются. Различие начинается, когда мы сталкиваемся с более сложной задачей, которую невозможно (слишком долго) решать в одиночку. Вот когда над задачей работает несколько рабочих (например, программистов), тогда и возникает потребность в человеке, который будет способен охватить решаемую задачу целиком и за счет этого сможет координировать деятельность рабочих, т.е. возникает потребность в конструкторе. И тогда же возникает потребность в человеке, который будет думать как какую-то операцию можно сделать в принципе и как ее можно упростить, чтобы ее мог выполнять рабочий с меньшей квалификацией и/или с меньшими трудозатратами, и который будет заниматься формализацией действий рабочих, чтобы сделать возможным передачу опыта другим рабочим, т.е. возникает потребность в технологе.
Соответственно само понятие инженера имеет смысл только при наличии вертикального разделения труда. Если же в коллективе программистов вертикального разделения труда нет, а есть только горизонтальное, то инженеров в таком коллективе нет, в нем есть только рабочие, хотя возможно и очень высокой квалификации. В материальном производстве такое тоже было всего лишь полтысячелетия назад, называлось это ремесленничество.
U>Это по твоему определение рабочего в общем случае? Вот к тебе сантехник пришел. Он рабочий? Ты что для него инструкцию как работать пишешь?
рабочий, конечно. инструкции у него уже все написаны (и получил он их в колледже)
сантехник не устраняет никаких противоречий, и не проводит никакой оптимизации, он берет имеющуюся деталь, и прикручивает ее туда куда написано.
U> который будет способен охватить решаемую задачу целиком и за счет этого сможет координировать деятельность рабочих, т.е. возникает потребность в конструкторе.
вот только это уже управленец (менеджер), а не конструктор.
конструктор — устраняет противоречия и оптимизирует конструкцию изделия. рабочих еще может никаких не быть.
управленец — устраняет противоречия и оптимизирует деятельность группы людей (и не надо управленца мешать с конструктором в единое целое)
тот же берт монро — конструктор, хотя никаких рабочих у него не было.
торвальдс, брин/пейдж, цукерберг и т.д. — даже в начале своей карьеры точно были конструкторами, а не рабочими, хотя и работали в одиночку без всякого вертикального разделения труда.
U> И тогда же возникает потребность в человеке, который будет думать как какую-то операцию можно сделать в принципе и как ее можно упростить, чтобы ее мог выполнять рабочий с меньшей квалификацией и/или с меньшими трудозатратами, и который будет заниматься формализацией действий рабочих, чтобы сделать возможным передачу опыта другим рабочим, т.е. возникает потребность в технологе.
технолог — устраняет противоречия и оптммизирует удешевление производства изделия. рабочих опять же может не быть.
например Матти Хольцберг — технолог, но рабочих у него нет.
U>Соответственно само понятие инженера имеет смысл только при наличии вертикального разделения труда. Если же в коллективе программистов вертикального разделения труда нет, а есть только горизонтальное, то инженеров в таком коллективе нет, в нем есть только рабочие, хотя возможно и очень высокой квалификации. В материальном производстве такое тоже было всего лишь полтысячелетия назад, называлось это ремесленничество.
т.е. ты делишь людей на рабочих и инженеров чисто по формальному признаку: если человек ставит задачу другим, то он — инженер, если человек ставит задачу сам себе — то он рабочий?
зы
есть такой человек — как прораб, он ставит задачи другим, но при этом он инженером не является.
сержант тоже ставит задачи другим, и он тоже не является инженером.
что самое интересное, когда лейтенант ставит задачи сержанту — он не выписывает ему инструкций, а лишь ставит задачу в общих чертах "построить взвод", "здесь и здесь отрыть окопы" и т.д.. инструкции сержант получил (также как и сантехник) в учебке.
можно взять и обратный пример — медицину. там врачи почти все поголовно инженеры при минимальном вертикальном разделении труда.
Если же в коллективе программистов вертикального разделения труда нет, а есть только горизонтальное, то инженеров в таком коллективе нет, в нем есть только рабочие, хотя возможно и очень высокой квалификации.
Выделенное нужно заменить на ремесленники, т.к. рабочие это тоже продукт вертикального разделения труда, и если нет такого разделения, то нет и рабочих.
U>> который будет способен охватить решаемую задачу целиком и за счет этого сможет координировать деятельность рабочих, т.е. возникает потребность в конструкторе.
DG>вот только это уже управленец (менеджер), а не конструктор.
Ключевые навыки конструктора: 1) способность охватить задачу целиком (т.е. включая детали) 2) способность формализовать задачу и разбить ее на подзадачи таким образом, чтобы для понимания подзадачи не требовалось понимания задачи в целом.
DG>конструктор — устраняет противоречия и оптимизирует конструкцию изделия. рабочих еще может никаких не быть.
DG>управленец — устраняет противоречия и оптимизирует деятельность группы людей (и не надо управленца мешать с конструктором в единое целое)
Чистый управленец не способен ни охватить задачу целиком, ни формализовать ее и разбить на подзадачи. Его работа заключается в том, чтобы подобрать людей, которые смогут это сделать. К примеру, толковый управленец товарищ Сталин для разработки пушки привлекает толкового конструктора товарища Грабина, т.к. сам товарищ Сталин при всех своих способностях управленца не может ни охватить задачу разработки пушки целиком, ни разбить ее на подзадачи.
DG>тот же берт монро — конструктор, хотя никаких рабочих у него не было.
Берт Монро это ремесленник. Все до последнего винтика он изготавливал понимая задачу целиком, т.е. он не занимался вопросами формализации и разбиения задачи на подзадачи.
DG>есть такой человек — как прораб, он ставит задачи другим, но при этом он инженером не является.
Прораб не обладает ни способностью охватить задачу целиком, ни способностью формализовать задачу и разбить ее на подзадачи. Координировать деятельность рабочих прораб может только за счет того, что разбиение на подзадачи за него уже произвели конструкторы и технологи.
DG>сантехник не устраняет никаких противоречий, и не проводит никакой оптимизации, он берет имеющуюся деталь, и прикручивает ее туда куда написано.
Про большинство программистов можно сказать тоже самое. Само по себе умение писать код человека инженером не делает.
DG>торвальдс, брин/пейдж, цукерберг и т.д. — даже в начале своей карьеры точно были конструкторами, а не рабочими, хотя и работали в одиночку без всякого вертикального разделения труда.
Если человек способен формализовать задачу и разбивать ее на подзадачи таким образом, что для их понимания не требуется понимания задачи в целом, то да у него есть задатки конструктора, даже если он работает в одиночку. Но убедиться в том, что человек действительно обладает способностями конструктора можно только тогда, когда решать задачу начинает несколько человек. Т.е. если человек в одиночку успешно решает сложные задачи, то из этого безусловно следует, что он ремесленник высокой квалификации, но вовсе не факт, что этот человек способен быть конструктором.
U>> И тогда же возникает потребность в человеке, который будет думать как какую-то операцию можно сделать в принципе и как ее можно упростить, чтобы ее мог выполнять рабочий с меньшей квалификацией и/или с меньшими трудозатратами, и который будет заниматься формализацией действий рабочих, чтобы сделать возможным передачу опыта другим рабочим, т.е. возникает потребность в технологе.
DG>технолог — устраняет противоречия и оптммизирует удешевление производства изделия. рабочих опять же может не быть.
DG>например Матти Хольцберг — технолог, но рабочих у него нет.
Хольцберг выполнял работу и конструктора, и технолога, и рабочего, т.е. являлся ремесленником.
DG>можно взять и обратный пример — медицину. там врачи почти все поголовно инженеры при минимальном вертикальном разделении труда.
С чего ты взял, что врачи инженеры? Из-за того, что у них диплом есть? А филолог с дипломом тоже инженер что ли?
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Ларик, Вы писали:
Л>>Подумал поработать, что не вакансия так минимум похоже я буду один операционную систему писать, судя по количеству необходимых знаний, ну я например много технологий знаю, причем не по книжкам, а реально сталкивался, разбирался, писал. Например работал с MSXML, но задай мне вопрос с которым я не сталкивался, я ноль, хотя за пару минут найду и примеры и пойму алгоритм решения. Т.е. если перечислить то что я "знаю" большой список получится, но если начать меня по нему тестировать завалить меня нечего делать. Л>>Собственно вот и возникает вопрос, а просто кодеры сейчас не нужны что-ли? Который может и не гуру в 20 темах, но решать вопросы нехватки знаний умеет. Или студенты эту нишу забивают? MM>На сабжевый вопрос захотелось ответить, что программеры в этом сами и виноваты, превратив понятие простого кодинга в нечто унизительное и оскорбительное, словно этим какие-то недочеловеки занимаются. Далеко ходить не надо. На этом форуме то и дело проскакивают соответствующие фразенки в стиле "я же не кодер" или "да эту херню может просто кодер написать". Вот и фирмах теперь также: "нам простой кодер не нужен". Ну, а раз не нужен, то на тебе списочег на 500 наименований. Думаете HR-ы определяют запросы вакансии? Да всё те же программеры и определяют, HR просто передает.
Программисты тут ни при чем, это наследие страшных времен, когда стандартным устройством компании были дизайнеры/архитекторы, которые дизайнили структуру программы и рисовали спецификации разной степени подробности, и кодеры, которые по этим спецификациям все делали, не отступая ни на шаг. Работа последних, по большому счету, требует исключительно низких знаний, ибо спецификации были типа "класс с именем А, поля с типами Б и В и именами Г и Д....", которые может написать любой освоивший синтаксис языка и умеющий бороться с ошибками компиляции. После чего написанный код проходит через несколько стадий ревью и тестирования, так что совсем уж даунский код отсекается. Соответственно, можно набрать почти что бесплатных "индусов"-(быдло)кодеров и сэкономить на зарплатах. Если не ошибаюсь, в Микрософте как раз такой подход рулил, не знаю, как сейчас.
U>Выделенное нужно заменить на ремесленники, т.к. рабочие это тоже продукт вертикального разделения труда, и если нет такого разделения, то нет и рабочих.
вводя термин "ремесленники" ты неявно вводишь деление ремесленный подход/производственный(научный) подход.
ремесленный подход — характеризируется наивной формой накопления опыта. когда улучшения делаются случайно, передача опыта делается методом делай также.
паре сотен лет назад в пику этому появился производственный(научный) подход, когда накопление опыта (улучшения) — делаются целенаправленно: формируются критерии, выстраиваются модели, проводятся исследования и ставятся эксперименты.
здесь тоже никакой корреляции с вертикальным разделением труда нет, а есть смена парадигмы накопления опыта через переход от наивного способа к целенаправленному.
U>Ключевые навыки конструктора: 1) способность охватить задачу целиком (т.е. включая детали) 2) способность формализовать задачу и разбить ее на подзадачи таким образом, чтобы для понимания подзадачи не требовалось понимания задачи в целом.
разбиение целого на части (она же декомпозиция) — это есть общая часто используемая задача.
ее делает и конструктор (разбивая изделие на части), и технолог (разбивая процесс изготовления на части), и сантехник (формируя образ что за чем крутить), и прораб(и сержант) — разбивая задачи по подчиненным
уж точно декомпозию делают дизайнеры, художники, ландшафтные дизайнеры, землеры и т.д. и т.п.
и на основе даже этого перечисления видно — что задача декомпозиции может быть сложная (когда необходимо проводить оптимизацию и устранять противоречия), а может быть шаблонной (когда деление жестко заданное и делается по алгоритму)
в тоже время, даже при наличии простой шаблонной декомпозиции — задача все равно может оставаться сложной.
декомпозиция автомобиля на узлы не меняется последние лет 20(если не последние лет 80), но несмотря на это — конструкционно задача все равно остается очень сложной, т. к. требуется устранить и оптимизировать кучу критериев.
U>Чистый управленец не способен ни охватить задачу целиком, ни формализовать ее и разбить на подзадачи. Его работа заключается в том, чтобы подобрать людей, которые смогут это сделать. К примеру, толковый управленец товарищ Сталин для разработки пушки привлекает толкового конструктора товарища Грабина, т.к. сам товарищ Сталин при всех своих способностях управленца не может ни охватить задачу разработки пушки целиком, ни разбить ее на подзадачи.
вижу передергивание на передергивании
задачу можно видеть в целом, по задаче можно видеть детали.
из-за ограничености ресурсов: на задачу смотрится либо в целом, либо смотрится детально.
тогда в паре Сталин/Грабин — Сталин смотрит в целом, что нужно стране, но не лезет в детали как делать пушки,
Грабин не лезет в целое — что лучше для страны, но разбирается с деталями — как лучше делать пушки.
> Чистый управленец не способен ни охватить задачу целиком, ни формализовать ее и разбить на подзадачи. Его работа заключается в том, чтобы подобрать людей, которые смогут это сделать.
подбор людей автоматически подразумевает декомпозицию задачи (как минимум декомпозируются сферы ответственности, сферы полномочий, бюджет и т.д.): вот этот будет отвечать за пушки, этот за армию, этот за транспорт, а этот будет бумажки перебирать.
DG>>тот же берт монро — конструктор, хотя никаких рабочих у него не было.
U>Берт Монро это ремесленник. Все до последнего винтика он изготавливал понимая задачу целиком, т.е. он не занимался вопросами формализации и разбиения задачи на подзадачи.
значит ты плохо прочитал статью.
там русским по белому написано — что он в одиночку в течении нескольких десятилетий(т.е. это не случайное озарение) совершенствовал свой мотоцикл в темпе всей мировой отрасли.
это возможно лишь при целенаправленном производственном подходе, и это не возможно при ремесленном подходе.
если читать более полные статьи о нем: то там видно, что Монро даже ближе к ученому чем к инженеру — он активно проводил исследования, ставил эксперименты, целенаправленно искал как сделать так, чтобы мотоцикл двигался еще быстрее.
U>Про большинство программистов можно сказать тоже самое. Само по себе умение писать код человека инженером не делает.
ты кстати сколько можешь назвать требований к хорошо сделанной форме?
U>Если человек способен формализовать задачу и разбивать ее на подзадачи таким образом, что для их понимания не требуется понимания задачи в целом, то да у него есть задатки конструктора, даже если он работает в одиночку. Но убедиться в том, что человек действительно обладает способностями конструктора можно только тогда, когда решать задачу начинает несколько человек. Т.е. если человек в одиночку успешно решает сложные задачи, то из этого безусловно следует, что он ремесленник высокой квалификации, но вовсе не факт, что этот человек способен быть конструктором.
в этом абзаце ты сейчас как раз руководствуешься ремесленным подходом (наивное наблюдение без целенаправленного движения), ты не проводишь ни анализа, ни построения модели, ни поиска готовых решений.
1. человек либо умеет делать сложную декомпозицию/либо не умеет
2. человек делает это либо осознанно, либо не осознанно.
3. человек либо умеет отслеживать как он думает, либо не умеет
4. человек либо умеет формулировать для других свои образы, либо не умеет.
решение сложные задач требует декомпозиции задачи хотя бы в голове, хотя бы не осознанно.
> Т.е. если человек в одиночку успешно решает сложные задачи, то из этого безусловно следует, что он ремесленник высокой квалификации, но вовсе не факт, что этот человек способен быть конструктором.
твое высказывание, что человек умеет решать сложные задачи, но при этом не является по твоей терминологии конструктором (т.е. не может разбить задачу для других) можно записать как:
человек умеет делать сложную декомпозицию = верно
(человек делает это осознанно И человек умеет отслеживать как он думает И человек умеет формулировать для других своих образы) = не верно
но отсутствие 2, 3, 4 — легко компенсируется кучей техник.
самая банальная — это приставление наблюдателя-аналитика, с параллельным использованием техник вопрошания.
т.е. из одного человека получался только недоконструктор (по твоей терминологии), а тут глядишь из двух человек — получился уже целый конструктор.
вот это как раз пример задачи, которую решает управленец (как скомбинировать неидеальных людей в хорошую систему).
говоря все это: ты явно или неявно выстраиваешь модель. но ты можешь ответить почему выстраиваемая тобой модель хорошая?
модели сравниваются по предсказательной силе — чем больше можно предсказать по модели, тем она лучше.
я не виже в твоей модели предсказательной силы. и соответственно не могу назвать твою модель хорошей.
есть определенный участок работы. туда надо посадить человека. как по твоей модели определить какого человека туда посадить?
при чем уже есть готовое наблюдение — посадишь одного человека, он не тянет; посадишь другого — а он выше на голову, чем проблемы на участке.
Здравствуйте, мыщъх, Вы писали:
М>если вы говорите, что вы это не умеете, то это это минус, но небольшой; М>если вы говорите, что вы это умеете, но валитесь на первом же вопросе -- это два минуса, образующих крест; М>если вы говорите, что вы это умеете, но вас через полчаса все равно валят -- это два минуса, оборазующих плюс (нащупали границы ваших познаний); М>если вы говорите, что вы это умеете и завалить вас не удается -- вы вылетаете по исключению, обрабатываемому (или необрабатываемому) вышестоящим манажментом;
Если собеседующий пытается меня "валить", то это те самые два минуса, образующие крест. На конторе.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
aik>>Я лет 10 назад собеседовал чувака одного — нужен был человек, знакомый с ядром линукса. Пришел товарищ и наплел что он в ядре какой то драйвер пишет-поддерживает (ntfs или что то похожее). После я написал парням, которые в драйвере упомянуты — они говорят "ну да, приходил такой то полгода назад, предлагал помощь, дали работу — а он и пропал напрочь". Такие сказочники попадаются
P>Ну так может это они думают, что пропал, а он на самом деле пишет-поддерживает. Только никому не показывает.
На работе он тоже так делать будет? Что-то там писать, но не выкладывать?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, мыщъх, Вы писали:
E__>Если собеседующий пытается меня "валить", то это те самые два минуса, образующие крест. На конторе.
каждый волен сам выбирать с кем ему работать, особенно когда есть выбор. мне как-то все равно пытаются меня валить или нет. сейчас вот начальство точно меня завалить решило, а подчиненные дружно устроили саботаж. ну да испортили настроение... зато есть возможность научиться разруливать такие ситуации...
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Undying, Вы писали:
U>Я еще раз повторяю, что конвейер это отличный способ производства серийного изделия, в программировании серийных изделий нет в принципе, есть только опытные. Соответственно было бы странным, если бы у японцев что-то получилось.
Насчет японцев не скажу, но у немцев я могу заказать машину, накликав в конфигураторе нужный мне комплект опций из немаленького такого списка вариантов. Да и по опыту часть задач в программировании действительно решается как "опытное производство", но в общем объеме производства она в целом не настолько велика на сегодняшний день и даже более того: программирования как такового остается все меньше, а все больше — "интеграции". Пусть даже в это слово включается и "создание дополнительных программных модулей в ходе кастомизации общего решения под конкретное приложение" — общего положения вещей это не отменяет: большая часть задач при этом — обыкновенный конвейер и серийное производство давно разработанных деталей и узлов и схем их сложения в готовую машину.
ЗЫ: а что, сегодня все еще пишут люди "свои собственные опытные, а не серийные изделия типа контейнера и пр."?
Здравствуйте, FR, Вы писали:
FR>Ну и даже квалификация "подсобного рабочего" в программировании или "кодера" требуется достаточно высокой, для других областей работник с таким требуемым временем обучения и требуемыми навыками считается достаточно высококвалифицированным специалистом.
Глупости. "Квалификация подсобного кодера" — это излишки нашей системы образования, которая до сих пор клепает программистов на уровне университетов. А это — уровень техникума и полугодичных курсов.
Здравствуйте, samius, Вы писали:
S>Конечно, они решали разные задачи, но связка 3 в одном оказывалась более плодовита чем команда людей с разными специализациями. Случаев явно маловато для того чтобы говорить о каких-то правилах, но они имеют место.
Ровным счетом ни о чем не говорит — бардак с тем же успехом организовывается и в собственной голове "3 в 1". С тем же успехом на всех без исключения научных производствах (не знаю как назвать: производящих науку в общем — научными исследованиями занимающихся) можно выгонять лаборантов и техников и пускай "умы" занимаются рутиной всякой в т.ч. — ведь им легче "самим с собой договориться"?
TL>Глупости. "Квалификация подсобного кодера" — это излишки нашей системы образования, которая до сих пор клепает программистов на уровне университетов. А это — уровень техникума и полугодичных курсов.
Индусы пошли этим путем, результат не радует, во всяком случае нам (Россия, СНГ, Восточная Европа) не подходит.
Здравствуйте, The Lex, Вы писали:
TL>Насчет японцев не скажу, но у немцев я могу заказать машину, накликав в конфигураторе нужный мне комплект опций из немаленького такого списка вариантов. Да и по опыту часть задач в программировании действительно решается как "опытное производство", но в общем объеме производства она в целом не настолько велика на сегодняшний день и даже более того: программирования как такового остается все меньше, а все больше — "интеграции". Пусть даже в это слово включается и "создание дополнительных программных модулей в ходе кастомизации общего решения под конкретное приложение" — общего положения вещей это не отменяет: большая часть задач при этом — обыкновенный конвейер и серийное производство давно разработанных деталей и узлов и схем их сложения в готовую машину.
Здравствуйте, DarkGray, Вы писали:
DG>ремесленный подход — характеризируется наивной формой накопления опыта. когда улучшения делаются случайно, передача опыта делается методом делай также. DG>паре сотен лет назад в пику этому появился производственный(научный) подход, когда накопление опыта (улучшения) — делаются целенаправленно: формируются критерии, выстраиваются модели, проводятся исследования и ставятся эксперименты.
Т.е. если человек тупой, то он ремесленник, если человек умный, то он инженер, а если особо умный, то ученый. Исключительно глубокая мысль.
U>>Ключевые навыки конструктора: 1) способность охватить задачу целиком (т.е. включая детали) 2) способность формализовать задачу и разбить ее на подзадачи таким образом, чтобы для понимания подзадачи не требовалось понимания задачи в целом.
DG>разбиение целого на части (она же декомпозиция) — это есть общая часто используемая задача. DG>ее делает и конструктор (разбивая изделие на части), и технолог (разбивая процесс изготовления на части), и сантехник (формируя образ что за чем крутить), и прораб(и сержант) — разбивая задачи по подчиненным DG>уж точно декомпозию делают дизайнеры, художники, ландшафтные дизайнеры, землеры и т.д. и т.п.
Ты мысль целиком можешь воспринимать? Где сантехник или художник формализует разбиение задачи на подзадачи, делая их доступными для понимания другими людьми? Где прораб понимает задачу целиком? Он что может объяснить, почему здесь балка в 10 см, а не в 15 см? Нет, не может, все что он может это следовать чертежу.
DG>декомпозиция автомобиля на узлы не меняется последние лет 20(если не последние лет 80), но несмотря на это — конструкционно задача все равно остается очень сложной, т. к. требуется устранить и оптимизировать кучу критериев.
Опять же ты воспринимаешь только полмысли. Разбиение задачи на подзадачи не отменяет необходимость увязывания подзадач как единого целого, а это само по себе очень сложная задача в случае автомобиля. Т.е. для конструктора типового автомобиля требования ко второму навыку (разбиение на подзадачи), благодаря имеющимся наработкам, может быть и не такие высокие, а требования к первому навыку (способность охватить задачу целиком) по прежнему очень высокие.
>> Чистый управленец не способен ни охватить задачу целиком, ни формализовать ее и разбить на подзадачи. Его работа заключается в том, чтобы подобрать людей, которые смогут это сделать.
DG>подбор людей автоматически подразумевает декомпозицию задачи (как минимум декомпозируются сферы ответственности, сферы полномочий, бюджет и т.д.): вот этот будет отвечать за пушки, этот за армию, этот за транспорт, а этот будет бумажки перебирать.
Управленец занимается обеспечением разработки продукта ресурсами: кадрами, материалами, финансами, а также оцениваем нужность и качество продукта с точки зрения заказчика. Собственно разработкой управленец не занимается, для этого у него нет достаточной квалификации, разработкой занимаются инженеры.
DG>это возможно лишь при целенаправленном производственном подходе, и это не возможно при ремесленном подходе. DG>если читать более полные статьи о нем: то там видно, что Монро даже ближе к ученому чем к инженеру — он активно проводил исследования, ставил эксперименты, целенаправленно искал как сделать так, чтобы мотоцикл двигался еще быстрее.
Т.е. Монро был не просто умный, а очень умный, значит, он даже не инженер, а цельный ученый. Глубина мысли поражает.
U>>Про большинство программистов можно сказать тоже самое. Само по себе умение писать код человека инженером не делает. DG>ты кстати сколько можешь назвать требований к хорошо сделанной форме?
В смысле? Это к чему вопрос?
DG>1. человек либо умеет делать сложную декомпозицию/либо не умеет DG>2. человек делает это либо осознанно, либо не осознанно. DG>3. человек либо умеет отслеживать как он думает, либо не умеет DG>4. человек либо умеет формулировать для других свои образы, либо не умеет.
DG>решение сложные задач требует декомпозиции задачи хотя бы в голове, хотя бы не осознанно.
Вот тот человек, который декомпозицию задачи умеет делать только в голове, это ремесленник. А тот кто способен сделать декомпозицию задачи понятной другим людям это инженер.
DG>самая банальная — это приставление наблюдателя-аналитика, с параллельным использованием техник вопрошания. DG>т.е. из одного человека получался только недоконструктор (по твоей терминологии), а тут глядишь из двух человек — получился уже целый конструктор. DG>вот это как раз пример задачи, которую решает управленец (как скомбинировать неидеальных людей в хорошую систему).
Такой недоконструктор может в лучшем случае выступать в роли эксперта, но никак не руководить разработкой.
Здравствуйте, FR, Вы писали:
TL>>... обыкновенный конвейер и серийное производство давно разработанных деталей и узлов и схем их сложения в готовую машину.
FR>Выделенное в программировании вообще невозможно, все серийное производство это нажатие F5 и команда "copy" FR>Вообще тут http://www.rsdn.ru/forum/philosophy/3808250.1.aspx
Здравствуйте, DarkGray, Вы писали:
DG>говоря все это: ты явно или неявно выстраиваешь модель. но ты можешь ответить почему выстраиваемая тобой модель хорошая? DG>модели сравниваются по предсказательной силе — чем больше можно предсказать по модели, тем она лучше.
DG>я не виже в твоей модели предсказательной силы. и соответственно не могу назвать твою модель хорошей.
были показаны 4 конкретных проблемы, которые являются следствием ремесленного подхода в программировании. Ты с чем там не согласен?
DG>есть определенный участок работы. туда надо посадить человека. как по твоей модели определить какого человека туда посадить? DG>при чем уже есть готовое наблюдение — посадишь одного человека, он не тянет; посадишь другого — а он выше на голову, чем проблемы на участке.
Часть ответа на этот вопрос есть в исходном сообщении.
.
Гапертон — тренер.
