AWW>Не должен, он не должен предпологать наличие... А вот руководитель должен быть таким.... и вести себя так.... чтобы у подчиненных не возникало сомнения в его авторитетности...
Мифический какой-то зверь получается, а не руководитель: при его появлении у подчиненных наблюдается ступор и щенячья преданность в глазах, все женщины в тайне о нем мечтают, любая проблема решается одним словом и т.п.
Вы по моему сами себе противоречите: с одной стороны говорите что руководитель должен быть компетентен больше чем всего его сотрудники вместе взятые, с другой стороны говорите что у него должна быть харизма ого-го (чуть не сказал 25 см. )
Уважение достигаемое харизмой и уважение достигаемое компетентностью это в общем-то ортогональные качества, и на мой взгляд в жизни одновременно не встречающиеся.
Опять же, имхо, руководитель это прежде всего часть команды. И отношение к нему должно быть такое же как и к остальным членам команды.
скажу немного другими словами: задача руководителя сделать так, чтобы команда вместе делала больше, чем каждые из них по отдельности.
Он не обязан быть компетентней всех сотрудников в команде. Это к тому же не возможно практически.
DAN>>В технических деталях он может быть более слабым, чем разработчики которыми он руководит. Это нормально, хотя бы потому, что невозможно быть в курсе деталей постоянно меняющейся отрасли. У менеджера задача и области другие. AWW>Нет! Он должен, даже обязан! По своей должности разбираться в новинках, а вот исполнитель как раз не должен... Его обязанность в той или иной степени владеть теми инструментами и приемами которые он обьявил в своём резюме...
я говорил о _деталях_. Скажем так: руководитель должен знать чем GC в Java отличается от GC в .net, но он не должен знать каким вызовом какого метода какого класса обеспечивается принудительная сборка мусора в java и .net.
DAN>>Или вы считаете что директор завода должен уметь выточить хитрую деталь на станке лучше чем рабочий с 30и летним стажем? AWW>Давайте-ка лучше рассмотрим не завод, с его 10 тысячками рабочих... А футбольную команду, что годаздо ближе к нашим структурам... Тогда ваш вопрос можно перефразировать так — "должел ли тренер играть в футбол лучше своих игроков?" Ответ нет не должен, но он должен знать как это делается гораздо лучше их... И за это игроки должны его уважать и верить в его правоту, иначе команда обречена на проигрыш...
Ну так я о том же и говорю. Он знает как играть, но ударить по мячу он не может (живот мешает )
Т.е. у любого руководителя есть уровень в котором он будет менее компенентен чем его подчиненные. Т.е. обязанность руководителя мыслить широко, обязанность разработчика — глубоко.
Кстати, это обычно выпадает из рассуждений разработчиков, когда они судят о решениях руководителя: у разработчика перед глазами небольшой кусочек проекта. У руководителя перед глазами целый проект + еще куча всякого о чем разработчику неведомо (бюджет, другие проекты, политические всякие вещи и т.п.). Зачастую решения руководителя непонятны (или кажутся неправильными разработчику) просто потому, что он не видит всей картинки.
DAN>>Приведите, пожаулйста, конкретные примеры. AWW>Зачем?!
Ну тогда будем считать что вы этого не говорили, и эту часть диалога опустим.
DAN>>К исскуству, на мой взгляд, это отношения по прежнему никакого не имеет, т.к. на мой взгляд искусство это то, что призвано приносить эстетическое наслаждение. AWW>Трёхтомник Кнута под название "Искуство програмирования" видели?
Это единственный ваш аргумент?
Устройте опрос сколько из программистов этот самый трехтомник
1. читали
2. использовали хотя бы 5 раз за всю свою карьеру.
Я не спорю, есть вещи которые уже ближе к искусству, нежели к рутине, но таких в нашей индустрии подавляющее меньшинство. И пытаться ко всем задачам подходить с точки зрения искусства — раздувать бюджет, увеличивать риски и тому подобные никому не нужные и неприятные вещи.
AWW>Уже писал, искуство это от русского слова искустно, то есть виртуозно, мастерски и.д. Например "искустная вышивка" "искустная рукодельница"
А.. понял, я предпочитаю слово "профессиональный", т.к. оно предполагает куда меньше толкований. в таком случае вопрос снимается.
DAN>>Подождите, так _не умеет_ управлять (т.е. не знает как это делается) или _не родился_ (бог не дал, а сколько не учи — толку не будет)? AWW>Страно что не понятно... — умение руководить это врожденное, и оно может быть как у всё другое в той или иной степени представлено у индивидуума.... И если имеет место полное отсутствие наличия, то тут сколько не учи, сколько не развивай ничего не выдет — "Бог не дал!"... Харизма не та... Тут также как с музыкальным слухом... Сколько книжек не читай, на курсы не ходи, на скрипке играть не станешь...
"Гений это 99% труда и 1% таланта".
Имхо роль харизмы и таланта в жизни руководителя сильно переоценена.
IT>Но их, в отличии от жителей России, десять лет в школе учат на английском. Причём учат не только понимать, но и говорить, а не как у нас "техническому английскому".
Изначально я всего лишь сказал, что утверждение о "родном английском" — неверно. Родной — это когда на этом языке говорят все и с младенческого возраста. В Индии это не так, а значит автор статьи неправ. Что касается сравнения уровня обучения английскому в школах (не всех индусов (и даже не большинство) 10 лет учат в школе исключительно на английском), то я не готов говорить об этом, поскольку не владею информацией. Однако, я знаю точно, что огромное количество индусов (в том числе и знакомых мне программистов) владеют английским весьма слабо, как устным, так и письменным. Короче говоря, поголовной "англоязычности" среди населения Индии нет.
IT>В повседневной жизни два индуса будут говорить на английском. Хотя бы даже из-за того, что на родине они говорят на разном хинди.
В повседневной жизни они будут говорить на хинди. Разные хинди (точнее, разные диалекты) — это в географически удаленных друг от друга областях. В повседневной жизни, человек в основном общается со своими "земляками" и диалект один и тот же. То есть если уж совсем никак — да, английский может стать связующим звеном, но как часто такое требуется? На статистику не влияет...
IT>Преимущество есть и довольно серьёзное. Нас практически не учат английскому, у них это второй (или какой там по счёту) официальный язык.
Вы попробуйте выйти на улицу в Мумбае и обьясниться на "официальном" языке. 70% людей не поймут ни слова.
IT>Понятное дело. Но это только в случае, если у русского приличный английский. А если его нет совсем или он в зачаточном состоянии?
Еще раз — в Индии тоже дофига таких, у которых "его нет совсем или он в зачаточном состоянии"
Здравствуйте, savaDAN, Вы писали:
DAN>Мифический какой-то зверь получается, а не руководитель: при его появлении у подчиненных наблюдается ступор и щенячья преданность в глазах, все женщины в тайне о нем мечтают, любая проблема решается одним словом и т.п.
Это идеал... К этому надо стремиться... Соласитесь, что тогда не будет возникать вопрос как мотивировать сотрудников...
DAN>Уважение достигаемое харизмой и уважение достигаемое компетентностью это в общем-то ортогональные качества, и на мой взгляд в жизни одновременно не встречающиеся.
А вы не рассматривайте обьекты управление как полностью информированные... Тогда вопрос про уважение через компетентность снимется... Это раз, а два это то, что у контретного индивидуума может быть то или иное соотношение харизмы и компетентности, а авторитет это штука ввиде суммы этих вещей, вот и всё....
DAN>Опять же, имхо, руководитель это прежде всего часть команды. И отношение к нему должно быть такое же как и к остальным членам команды. DAN>скажу немного другими словами: задача руководителя сделать так, чтобы команда вместе делала больше, чем каждые из них по отдельности.
100% верно!
...
DAN>я говорил о _деталях_. Скажем так: руководитель должен знать чем GC в Java отличается от GC в .net, но он не должен знать каким вызовом какого метода какого класса обеспечивается принудительная сборка мусора в java и .net.
Чем выше поднимается руководитель, тем шире становится его зона ответсвенности, но глубина знаний в этой зоне у него будет различная... Он может вполне оставаться компетентным в какой то одной области...
НО! Что важно, мы сейчас говорим не о втором уровне, а о первом... Для второго уровня, это когда подчиненные руководителя сами есть руководители... То тут всё вообще становится по другому... Тут управленец может быть вообще не компетентным как технарь... Но это уже совсем другой вопрос....
DAN>Ну так я о том же и говорю. Он знает как играть, но ударить по мячу он не может (живот мешает )
Заметьте знаеть... как и уметь это разные вещи. Поэтому директор завода должен знать как выточить деталь но уметь её вытачивать не обязан...
DAN>>>Приведите, пожаулйста, конкретные примеры. AWW>>Зачем?! DAN>Ну тогда будем считать что вы этого не говорили, и эту часть диалога опустим.
Опустим-опустим... Я лищь говорил о своих впечатлениях, и только...
AWW>>Трёхтомник Кнута под название "Искуство програмирования" видели? DAN>Это единственный ваш аргумент?
Ну этот ваш весомее... А вообще-то и одного дастаточно....
DAN>Я не спорю, есть вещи которые уже ближе к искусству, нежели к рутине, но таких в нашей индустрии подавляющее меньшинство. И пытаться ко всем задачам подходить с точки зрения искусства — раздувать бюджет, увеличивать риски и тому подобные никому не нужные и неприятные вещи.
Искуство програмировангия как раз и состоит в обратном, чтобы затраты и риски снижать а качество увеличивать...
DAN>>>Подождите, так _не умеет_ управлять (т.е. не знает как это делается) или _не родился_ (бог не дал, а сколько не учи — толку не будет)?
AWW>>Страно что не понятно... — умение руководить это врожденное, и оно может быть как у всё другое в той или иной степени представлено у индивидуума.... И если имеет место полное отсутствие наличия, то тут сколько не учи, сколько не развивай ничего не выдет — "Бог не дал!"... Харизма не та... Тут также как с музыкальным слухом... Сколько книжек не читай, на курсы не ходи, на скрипке играть не станешь...
DAN>"Гений это 99% труда и 1% таланта". DAN>Имхо роль харизмы и таланта в жизни руководителя сильно переоценена.
Заметьте один процент! Потому как гений это результат, а результат это труд умноженный на талант...
Если таланта 99% то труда надо 1%.... Но НАДО! Поэтому если нет харизмы, то есть она равна нулю, то сколько не учись и не трудись результата не будет...
Что-то мы уже в какую-то другую облать скатились... И вообще про индусов всё начиналось....
Здравствуйте, ggg, Вы писали:
ggg>Здравствуйте, bastrakov, Вы писали:
ага, писал. причем в ответ на совершенно определенные заявления.
почему ваши исходные заявления пропали из этого ответа?
я читал ветку. причем за один заход. т.е. — в теме. с автором противоположного мнения — не согласен в некоторых моментах, но он ближе к истине. imho.
B>>1) кто дал право заказчику ставить нам задачу? извините за банальность, деньги, которые он пратит за выполнение заказа! ggg>О заказчиках я ни слова не говорил.
для программиста заказчиком выступает постановщик задачи. я не прав?
B>>2) авторитет. вы работаете на людей, которых никогда в жизни не видели. авторитет вашего директора — дефолтный? или он должен предварительно морду бить всем ньюкамерам? ggg>Причем тут директор?
ну я ждал...
значит авторитет, это тот, кто пишет код, который вы считаете авторитетным? или кто?
ваша реплика была про прямого руководителя.
ggg>Но аналитик (а может, у вас это "менеджер" называется, или технический руководитель), ставящий некую задачу программисту, и при этом сам не имеющий завершенных проектов в данной области, — имхо нонсенс.
да. но встречается, и далеко не редкость.
в качестве примера: человек пытается поднять свой личный проект. первый в жизни.
какая разница, какую чушь он несет? он рискует своими деньгами, репутацией... своей, не вашей.
B>>3) а кто отчитывается за заказ, потраченые деньги, отработаные часы? ggg>Речь шла чисто о технических вещах. Тот, кто отчитывается за заказ-деньги-часы, может понятия не иметь о технических программистских вопросах.
гм... т.е. в вашей работе финансовые вопросы не стоят? курсовая работа?
B>>ну вот просто интересно — чисто поржать. ggg>Поржите над собой, если не можете прочитать всю ветвь дискуссии, а отвечаете на вырванное сообщение, и невпопад.
гм... ок.
B>>ни к чему не призываю, но обьявлять новому манагеру, что он "не имеет авторитера в группе" — показать свой глубокий непрофессионализм. B>>профессионалу совершенно фиолетово: где, что, как и когда делать, если за это платят. если его что-то не устраивает, он решает свои проблемы по минимуму загружая других людей. ggg>Если профессионалу идиот-аналитик (идиот-руководитель) (нифига не разбирающийся ни в предметной области, и не имеющий никакого опыта в программировании таких вещей) дает идиотское ТЗ, то уже не фиолетово.
почему? деньги запахли?
ggg>А вы совсем не туда. Я отвечал на посты, где именно руководитель-программист и подчиненный-программист. Никаких заказчиков и прочих вышестоящих. "Менеджером" я назвал лишь условно.
ок.
ggg>Если интересно, перечитайте.
перечитал.
ggg>Обсуждались две противоположные ситуации:
а знаю.
ggg>1) начальник (программист) дает задание начинающему программисту, последний его не хочет слушать, делает по-своему. Результат плохой. Начальник-программист пишет на форуме, что с начинающими трудно договориться, они никого не хотят слушать, а чуть что — обижаются и увольняются.
оба не правы. и что? первого — уволить, второго — вернуть?
ggg>2) (другой случай)Программист говорит, что бывают такие начальники (технические — чтоб вы поняли), которые сами толком не разбираются, и проще уволиться, чем пытаться им что-либо объяснить.
и кому от этого хуже?
мое отношение к комфортной работе знают вроде как все.
если человек несработался в коллективе — надо так и сказать.
к сожалению, русские программисты отличаются unmanageable. в данном случае — оно и есть, наложившееся на не бест манагера.
еще раз реплика, на которую я и отвечал:
вы считаете, что для того, что бы взять задание в работу, вам лично его должен дать человек, к которому вы имеете глубокое личное уважение.
я правильно понял? отсюда вопросы:
1) уважение по поводу чего и на основании чего? человеческое, профессиональное... что должен сделать вновь пришедший манагер, что бы таки всучить вам задание?
2) финансовый вопрос никак не решает вопрос некомпетенции заказчика? или по другому: сколько вам надо заплатить, что бы вы сделали любое задание?
в качестве примера — неделю писали xml-файл (средняя работа среднего индуса).
3) вы лично скольким людям в вашей команде готовы дать задание на тех же условиях?
4) предположим, человек изначально позиционируется как манагер. он год посидел в девелоперах (посоветовали) и пытается взять под себя команду. что он должен сделать, что бы вы взяли его задание, а не делали то, что вам лично больше нравиться?
5) что он должен сказать, что бы остановить вашу работу, которую, как он считает, он не сможет "продать" заказчику? (т.е. сделать что-то, что бы это время оплатили)
p.s. я пишу на основании своего опыта из реальной жизни. ваши мечты об идеальной работе с изумительным манагером я понял.
Aviant wrote: > Никто никого не собирался увольнять, если вы не поняли. > Речь шла о том, чем опасны программисты, работающие "потому что интересно".
Только опасность эта существует в очень узком кругу контор, где через
пару лет остаются одни выпускники вузов и дикая текучка, впрочем,
конечно — это гипербола.
> PS: с ним надо было бы после всего сесть, разобрать ситуацию и показать > почему его идея была изначально гиблой. Вооруженный некоторым опытом, он > бы наверное понял. Но он предпочел уволиться.
А вот здесь я с вами категорически не согласен.
Любой опыт всегда имеет сильную эмоциональную окраску. А человек, это то
существо, которое в первую очередь руководствуется своими эмоциями, а
потом уже, иногда, холодным разумом.
Менеджеру надо было приложить все усилия, чтобы не доводить ситуацию до
подобного абсурда. Конечно, может ничего не получится, но в таком случае
выгоднее сменить подчиненному вообще задачу на другую под предлогом
срочности, еще чего-нибудь. Или если уж приходиться вступать в такую
ситуацию, то этот подчиненный и его работа должны быть под полным
контролем менеджера, а не через две недели гора кода, делающего совсем
не то, что нужно. Чем раньше удасться прекратить этот эксперимент, тем
лучше всем, и программисту, и начальнику, и фирме.
B>гм... т.е. в вашей работе финансовые вопросы не стоят?
Они стоят в любой работе. Но техническое руководство часто отделено от финансового (эти люди даже не пересекаются). Я — про техническое руководство.
B>курсовая работа?
Не хамите. Странно, что мой простой пост вызвал столько домыслов о "курсовой работе", "мечтах об изумительных менеджерах".
ggg>>Если профессионалу идиот-аналитик (идиот-руководитель) (нифига не разбирающийся ни в предметной области, и не имеющий никакого опыта в программировании таких вещей) дает идиотское ТЗ, то уже не фиолетово.
B>почему? деньги запахли?
Потому что с идиотами связываться — себе дороже.
ggg>>1) начальник (программист) дает задание начинающему программисту, последний его не хочет слушать, делает по-своему. Результат плохой. Начальник-программист пишет на форуме, что с начинающими трудно договориться, они никого не хотят слушать, а чуть что — обижаются и увольняются.
B>оба не правы. и что? первого — уволить, второго — вернуть?
Вот я и высказал свое мнение о том, что помешало им договориться.
B>вы считаете, что для того, что бы взять задание в работу, вам лично его должен дать человек, к которому вы имеете глубокое личное уважение.
Личное уважение тут непричем. К профессиональному авторитету оно отношения не имеет.
Если человек конкретизирует техническое задание, но при этом сам в теме не разбирается — это плохо.
Если человек занимается финансовыми вопросами, то пусть не лезет в технические (читай, не несет околотехническую чушь про width на форме для true VGA)
B>1) уважение по поводу чего и на основании чего? человеческое, профессиональное... что должен сделать вновь пришедший манагер, что бы таки всучить вам задание?
Если технический руководитель — то профессиональное уважение.
Если менеджер, занимающийся заказчиками и финансами, — то пусть не порет техническую чушь (просто занимается своим делом).
B>2) финансовый вопрос никак не решает вопрос некомпетенции заказчика? или по другому: сколько вам надо заплатить, что бы вы сделали любое задание?
"Любое" ко мне неприменимо. B>в качестве примера — неделю писали xml-файл (средняя работа среднего индуса).
Я совсем в другой области работаю. Но если придет _финансовый_ руководитель и скажет, что необходимо неделю поделать "среднюю работу среднего индуса", иначе денег не будет, — то, вполне себе, соглашусь.
B>3) вы лично скольким людям в вашей команде готовы дать задание на тех же условиях?
Всем.
B>4) предположим, человек изначально позиционируется как манагер. он год посидел в девелоперах (посоветовали) и пытается взять под себя команду. что он должен сделать, что бы вы взяли его задание, а не делали то, что вам лично больше нравиться?
Вы читали мой пример про true VGA?
Где я говорил, что нужно делать то, что "лично программисту больше нравится"?
Задание менеджера в вашем гипотетическом примере — это, скорее всего, и будет техническая чушь, которая "менеджеру больше нравится". Потому что менеджер, год работавший программистом, потому что ему _посоветовали_, вряд ли проявит серьезную заинтересованность именно в технических вещах.
B>5) что он должен сказать, что бы остановить вашу работу, которую, как он считает, он не сможет "продать" заказчику? (т.е. сделать что-то, что бы это время оплатили)
О5 25. Я про технических руководителей говорю.
Если придет менеджер, решающий финансовые вопросы и вопросы отношений с заказчиком, и скажет — ваш проект решили закрыть, потому что денег на это нет и не будет, то ради бога.
Но если придет технический руководитель и скажет, что проект нужно закрыть, потому что ему пришла в голову якобы гениальная идея (а он даже толком не работал в этой области), бросайте все, делайте как он придумал — то лесом.
B>p.s. я пишу на основании своего опыта из реальной жизни. ваши мечты об идеальной работе с изумительным манагером я понял.
Попытка перейти на личности и на неизвестный собеседнику "свой опыт из реальной жизни" не делает вам чести. Не нужно бросаться громкими фразами. Я же об абстрактных (ну или о пересказанных другими людьми) ситуациях говорю.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Тануки, Вы писали:
Т>>Просто они правильно всё поняли — лучше руководить, чем программить.
O>Чем же это лучше? Хороший девелопер на перманенте получает примерно столько же, сколько и менеджер. Консалтер получает в разы больше менеджера.
IT>Ладно, давай на это посмотрим иначе. Возьмём среднего русского программиста и среднего индусского. У кого по твоему английский лучше?
В принципе, готов допустить, что у среднего индуса английский лучше. Но считать это серьезным аргументом в соперничестве русских и индусских программистов не готов. На самом деле, вес этого фактора ничтожно мал.
Индия обходит Россию в аутсорсинге совсем по другим причинам (некоторые из которых в статье указаны верно).
напоминаю:
1) изначально речь шла об отличии индийских программистов от русских.
2) потом был приведен пример, как молодой программист отказался делать задание, которое ему выдали,
и попытался сделать (внимание, не предложил к обсуждению, а попытался сделать) свое решение,
на которое ему разрешили убить 2 недели оплачиваемого времени.
я удалил все, что может быть расценено опонентом как провокация, и постараюсь оставаться very polite.
ggg>>>Если профессионалу идиот-аналитик (идиот-руководитель) (нифига не разбирающийся ни в предметной области, и не имеющий никакого опыта в программировании таких вещей) дает идиотское ТЗ, то уже не фиолетово. B>>почему? деньги запахли? ggg>Потому что с идиотами связываться — себе дороже.
в 2) был пример именно некомпетенции разработчика. считаете ли вы, что его не надо было принимать на работу, а если уж приняли — разрешить ему делать, то, что он хочет?
ggg>>>1) начальник (программист) дает задание начинающему программисту, последний его не хочет слушать, делает по-своему. Результат плохой. Начальник-программист пишет на форуме, что с начинающими трудно договориться, они никого не хотят слушать, а чуть что — обижаются и увольняются. B>>оба не правы. и что? первого — уволить, второго — вернуть? ggg>Вот я и высказал свое мнение о том, что помешало им договориться.
делать что?.. я знаю таких не один пример. что делать манагеру?
я знаю, как решают обычно такие ситуации. обычно человек снимается с проекта.
его нельзя уволить. ...пока. но снять с работ — можно. в одном месте — это ударит рублем. в другом — нет.
в любом — ударит по самолюбию. предложите свой вариант решения проблемы.
конкретно по данному примеру.
девелоперу дали 2 недели на подтверждение своих взглядов. вы считаете мало?
сколько дней надо вам, что бы "протолкнуть" свое решение?
у нас в команде считается нормальный 2-3 дня на "доказательство". мне давали день. рядом сидит человек, которому дали 3.
B>>вы считаете, что для того, что бы взять задание в работу, вам лично его должен дать человек, к которому вы имеете глубокое личное уважение. ggg>Личное уважение тут непричем. К профессиональному авторитету оно отношения не имеет.
в чем разница. обозначте пожалуйста. для меня есть разница в работе и личном отношении.
но я не понимаю, что такое "профессиональный авторитет". типа 100 человек должно сказать, что уважают вот этого конкретно?..
армия, рота, командир взвода.
ggg>Если человек конкретизирует техническое задание, но при этом сам в теме не разбирается — это плохо.
неоспоримо. в приведенном примере было наоборот.
ggg>Если человек занимается финансовыми вопросами, то пусть не лезет в технические (читай, не несет околотехническую чушь про width на форме для true VGA)
ээээээээээээээээ... у нас тех.задания попроще. должно работать так-то. все.
реализация, в том числе, форм — на совести программиста.
если задание написано с конкретизацией, то может его и писать не надо? там сразу код может быть.
B>>1) уважение по поводу чего и на основании чего? человеческое, профессиональное... что должен сделать вновь пришедший манагер, что бы таки всучить вам задание? ggg>Если технический руководитель — то профессиональное уважение.
что это такое? завтра примут нового манагера к вам в проект. program-manager.
другой пример. вы переходите в другой проект. вот данного program-manager вы лично уважаете.
что это значит?
ggg>Если менеджер, занимающийся заказчиками и финансами, — то пусть не порет техническую чушь (просто занимается своим делом).
человек, который ставит задачу _должен_ быть рядом с заказчиком. это аксиома.
иначе будет плохой продукт. значит ли это, что между заказчиком и вами должно быть 2 человека?
B>>2) финансовый вопрос никак не решает вопрос некомпетенции заказчика? или по другому: сколько вам надо заплатить, что бы вы сделали любое задание? ggg>"Любое" ко мне неприменимо.
понял. т.е. вы позиционируете себя, как работник с повышеными требованиями к условиям труда в команде.
нет проблем, просто это обьясняет вашу позицию.
B>>в качестве примера — неделю писали xml-файл (средняя работа среднего индуса). ggg>Я совсем в другой области работаю. Но если придет _финансовый_ руководитель и скажет, что необходимо неделю поделать "среднюю работу среднего индуса", иначе денег не будет, — то, вполне себе, соглашусь.
понял. здравый человек, не понимаю, почему у вас нет опыта работы с "гениями".
B>>3) вы лично скольким людям в вашей команде готовы дать задание на тех же условиях? ggg>Всем.
у нас 10 человек. я знаю одного, кто может дать любому. он и возглавляет команду.
в другой комбинации — будут "трения". причем точно знаю, кто будет точно делать так же как в примере 2).
B>>4) предположим, человек изначально позиционируется как манагер. он год посидел в девелоперах (посоветовали) и пытается взять под себя команду. что он должен сделать, что бы вы взяли его задание, а не делали то, что вам лично больше нравиться? ggg>Вы читали мой пример про true VGA?
да. если он просто поставит задание без указания, как писать код, это будет достаточно, что бы проблемы не возникло?
в 2) человеку не ставили рамки кодирования.
ggg>Где я говорил, что нужно делать то, что "лично программисту больше нравится"?
возможно я что-то забыл. но вы защищаете пример, в котором это было.
ggg>Задание менеджера в вашем гипотетическом примере — это, скорее всего, и будет техническая чушь, которая "менеджеру больше нравится". Потому что менеджер, год работавший программистом, потому что ему _посоветовали_, вряд ли проявит серьезную заинтересованность именно в технических вещах.
точно. они обычно не лезут в это, отдавая реализацию на руки разработчику.
B>>5) что он должен сказать, что бы остановить вашу работу, которую, как он считает, он не сможет "продать" заказчику? (т.е. сделать что-то, что бы это время оплатили) ggg>О5 25. Я про технических руководителей говорю.
я тоже.
ggg>Но если придет технический руководитель и скажет, что проект нужно закрыть, потому что ему пришла в голову якобы гениальная идея (а он даже толком не работал в этой области), бросайте все, делайте как он придумал — то лесом.
вы все перепутали. в 2) это было сказано разработчиком.
теперь про 1)
я уже писал про свой обыт работы с индусами. гору сроют, если показать, с которой стороны копать.
в исходной статье — очень много правильного. видно, что человек пишет на основе своего опыта.
так вот у них в бизнесе авторитет начальства зависит только от занимаемой должности.
чем это плохо — проект может завалить один идиот.
чем хорошо — все знают, что если проект завалят, то только он будет виноват.
но я ни разу не видел разборок на тему "я так делать не буду, потому что считаю это не правильным".
отвечать за неправильный результат человеку, который ставит задачу. и если он ставит одну, а делают по другому — все равно с него спросят, почему дал возможность... короче... в россии встречается довольно часто такая подстава: "ты начальник — ну вот и иди лесом".
вообще тема больная. во-первых видел это не раз. во вторых... некоторое время назад сидел за столом с директором завода.
он жалуется, что не знает, "как заставить работать. говорит: и штрафовал, и платил, и награждал, и тренинги... не могу заставить нормально работать."
менталитет? на нем иднусам и проигрываем. обидно!
>> Речь шла о том, чем опасны программисты, работающие "потому что интересно". V>Только опасность эта существует в очень узком кругу контор, где через V>пару лет остаются одни выпускники вузов и дикая текучка, впрочем, V>конечно — это гипербола.
IMO как раз наоборот, в маленьких фирмочках, где работают энтузиасты.
Энтузиазм пропадает — проект гаснет. Таких фирмочек очень много, постоянно появляются и исчезают.
Характерная черта: на собеседовании в них говорят "да, у нас работают 6 человек, но они все — лучшие из лучших !"
V>А вот здесь я с вами категорически не согласен.
Взаимно
V>А человек, это то V>существо, которое в первую очередь руководствуется своими эмоциями, а V>потом уже, иногда, холодным разумом.
О. Тут по ветви обсуждается что есть программирование и чего там больше искусства или рутины.
"Творцы" как раз руководствуются в первую очередь эмоциями, а разумом потом, иногда, может быть.
Считаю, что такой подход применим при написании картин, ваянии скульптур, сочинении музыкальных произведений или игре в театре. Если у человека эмоции на первом месте — в IT ему делать нечего.
Тут 2 + 2 равно 4, несмотря на то что это "неизящно и некрасиво".
V>Чем раньше удасться прекратить этот эксперимент, тем V>лучше всем, и программисту, и начальнику, и фирме.
Это да. Эксперимент продолжался отведенное на него время и принес ожидаемые результаты.
B>напоминаю: B>1) изначально речь шла об отличии индийских программистов от русских. B>2) потом был приведен пример, как молодой программист отказался делать задание, которое ему выдали, B>и попытался сделать (внимание, не предложил к обсуждению, а попытался сделать) свое решение, B>на которое ему разрешили убить 2 недели оплачиваемого времени.
Поправка. Он не отказался, он предложил идею, подход, к построению архитектуры системы. Ему дали "потренироваться на кошках" и реализовать в упрощенном виде некоторую функциональность, базируясь на своем подходе. В оговоренное время он не смог этого сделать.
B>>напоминаю: B>>1) изначально речь шла об отличии индийских программистов от русских. B>>2) потом был приведен пример, как молодой программист отказался делать задание, которое ему выдали, B>>и попытался сделать (внимание, не предложил к обсуждению, а попытался сделать) свое решение, B>>на которое ему разрешили убить 2 недели оплачиваемого времени. A>Поправка. Он не отказался, он предложил идею, подход, к построению архитектуры системы. Ему дали "потренироваться на кошках" и реализовать в упрощенном виде некоторую функциональность, базируясь на своем подходе. В оговоренное время он не смог этого сделать.
Если дело было в сроках — то непонятно почему его направили не на разработку проекта (раз сроки так поджимают), а на что-то другое. А если дело было не в сроках (но допустим его идея хороша), то непонятно почему ее не довершили, не помогли ему.
Значит, идея была неправильна изначально (или ее просто не смотрели, что мне видится более вероятным), а человеку не стали этого объяснять, а просто поставили маленький срок.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Сгибатель, Вы писали:
AWW>>Искуство это от слова искустно... То есть виртуозно, профессионально, лучше многих и т.д. ... А так получается смешно, согласитесь — "Искуство управления предприятием" ... или "Искуство дипломатии" Какое уж тут художественное творчество Или ещё смешнее — "Искуство рукопашного боя"
С>А какое художественное творчество вы увидили в программировании? С>Программный код, как таковой, является предметом авторского права, но вот, чтобы он ещё имел художественную ценность
А какое художественное творчество вы увидили, к примеру, в литературе?
Книги тоже являются предметом авторского права, но вы же не спорите, что они имеют художественую ценность?
Сам программный код — конечно не имеет, но вот способ реализации конкретной задачи — очень даже.
Так же как слова в книге не являются чем-то особенным, но вот выражаемые ими мысли очень часто заставляют задуматься.
Aviant wrote: > >> > Речь шла о том, чем опасны программисты, работающие "потому что > интересно". > V>Только опасность эта существует в очень узком кругу контор, где через > V>пару лет остаются одни выпускники вузов и дикая текучка, впрочем, > V>конечно — это гипербола. > IMO как раз наоборот, в маленьких фирмочках, где работают энтузиасты. > Энтузиазм пропадает — проект гаснет. Таких фирмочек очень много, > постоянно появляются и исчезают. > Характерная черта: на собеседовании в них говорят "да, у нас работают 6 > человек, но они все — лучшие из лучших !"
Вы меня не поняли, это не связано с размером фирмы.
Просто программист, работающий больше "потому что интересно", при
поставленном процессе разработки вполне себе вписываем в процесс, причем
в то место, где от него может быть наибольшая польза и в первую очередь
задача руководителя найти это место. Конечно, бывают ситуации-проекты,
где люди с определенным жизненным подходом работать не могут, но в
данном варианте лучшее для всех разойтись в разные стороны.
И кроме того "потому что интересно" — это очень сильная мотивация и
может перекрывать разницу оплаты в несколько сотен долларов.
> О. Тут по ветви обсуждается что есть программирование и чего там больше > искусства или рутины. > "Творцы" как раз руководствуются в первую очередь эмоциями, а разумом > потом, иногда, может быть. > Считаю, что такой подход применим при написании картин, ваянии > скульптур, сочинении музыкальных произведений или игре в театре. Если у > человека эмоции на первом месте — в IT ему делать нечего. > Тут 2 + 2 равно 4, несмотря на то что это "неизящно и некрасиво".
Почему, вполне себе "красиво и изящно".
Не всегда, бывает по разному, причем я большей частью сталкивался с
ситуациями, что если красиво и изящно (спроектирован продукт, написан),
то обычно он и работает хорошо. Конечно, это не говорит от том, что
некрасиво работать не будет, а красиво работает всегда. Причем понятие
красоты сугубо индивидуально.
Думаю, в программировании, как и в любом производстве есть элементы
искусства, но есть и куча рутинной работы.
Здравствуйте, Сгибатель, Вы писали:
С>В любой деятельности есть место фантазии, нестандартным решениям etc, С>но таки "искусство" это вы, право слово, слишком.
Ну да, ну да. Онако разные реализации одной и той же задачи могут выглядеть (работать) по разному, даже если они работают с точки зрения заказчика одинаково. И даже в этом случае одна из них может быть сделана бездарно, а другая красиво, только определить это будет под силу специалисту.
Может быть искусство это создать, что то в правильные сроки (время) и с правильными функциями (идеями), но так как этого хочет автор, и так как для него это правильно-красиво? Знающий скажет, что это искусство. Не знающий скажет, что это хорошо сделанная работа.
Если нам не помогут, то мы тоже никого не пощадим.
в россии встречается довольно часто такая подстава: "ты начальник — ну вот и иди лесом".
