Aviant wrote: > Человеку была поставлена задача: за 2 недели нужно сделать то-то и > то-то. Это ДОЛЖНО работать и на экране я хочу увидеть вот такую то > функциональность. Причем, если я увижу это через 2 недели, то мы будем > использовать его задумку. Если нет — нет. Через 2 недели мне показали > solution из 12 проектов, штук 50 классов и форму с одной кнопкой. > Рассказали, что за этим скрывается мега-механизм, надо его только > доработать. > > Как и было обещано, при таком результате от его предложения отказались в > пользу более простого решения. С человеком случилась истерика, и он > сказал, что "к проекту в целом у него пропал интерес" (цитирую). И он > уволился. Удерживать не стал. > > PS: штука в том, что "генальная" идея отнюдь не нова и не гениальна. Ей > уже лет 8 как и она всегда, всегда возникает при разработке системы с > определенной архитектурой. Юное дарование не обладает каким-то особым > "даром". Обычный неплохой программист, с отсутствием опыта и > уверенностью, что он "творит".
Лично я бы уволил тут же менеждера этого человека.
Не понимаю, как можно дать подчиненному задачу, зная заранее, что он
собирается повторить туже ошибку, что уже совершали 8 лет назад.
Не понимаю, как можно потратить 2 недели труда "неплохого программиста"
(ваши слова), только на то, чтобы он убедился в том, что ошибается и
после этого фактически уволить его.
По крайней мере так я понял ваш пост.
P.S.
Ну а фраза "Юное дарование не обладает каким-то особым "даром".Обычный
неплохой программист, с отсутствием опыта и уверенностью, что он
"творит"." ???????
Ни в коем случае не хочу обидеть, но может вы поспешили стать
руководителем. Люди, однако, не винтики и не муравьи, они — личности, со
всеми вытекающими отсюда плюсами и минусами.
Знакомо, задавали данный вопрос своему англицкому менеджеру, типа нафига тебе русские, когда полно индусов, да еще китайцы на подходе. Его позиция примерно такая
1. Timezone. Очень важный фактор. Крайне сложно управлять командой, если разница в 6 часов. Пришел утром, отписал команде, ответ придет на след. день. Лаг большой получается. Разница с Москвой 3 часа, за счет измененного графика лаг сокращается до 2 часов. Терпимо.
2. Менталитет. Все-таки мы достаточно близки к европейцам, без проблем ассимилируемся, нет непонятных закидонов. Привел типичный пример — "спрашиваешь индуса, сделаешь завтра эту фичу (что невозможно физически)? ответ — "да". продашь себя и семью в рабство? ответ — "да". Русские же отвечают — "а денег сколько?".
И это, если брать примерно равную стоимость — при более качественном девелопере. Рассуждения об искусстве, тех. процессе и прочем — ерунда. Организация процесса вообще говоря занятие менеджера, а профессиональный девелопер способен работать при любом процессе, делая свое дело, а не занимаясь самодельщиной.
На мой взгляд, нам нужно позиционироваться, не как дешевая раб.сила, типа индусов, а как высококачественная раб. сила за нормальные деньги, даже если платить нам среднюю по европе з/п типа 3К, все равно мы будем дешевле за счет меньших налогов и дешевой инфраструктуры.
Поэтому нафиг не надо гнать на потоке сотни тысяч девелоперов, все равно индусов не обойдем. Лучше меньше, да лучше (с) Ильич
Здравствуйте, Аноним, Вы писали:
А>Это действительно не смешно. Ужасно много времени уходит на борьбу с очередной гениальной идеей какого-нибудь юного дарования с 2 годами опыта.
Я всё жду когда талантливых программистов будут сдавать в аренду или продавать как футболистов... Я бы это юное дарование купил бы... Вы просто не умете с ними работать...
А статья бред, мы именно тем и лучьше индусов, что у нас есть ребята которые не за бабки, а за интерес... А за бабки можно или у конвереа, или двор мести... эффективно... Типа не думай, а делай то, что сказали....
Россия — порядка 40 000 программистов
Индия — порядка 800 000 программистов
Чисто конкретно. Разводка не катит. У индусов последнии 10 лет работала программа обучения программеров, в которую вбухали 20 млрд $. А у нас институты закрывали.
Здравствуйте, bastrakov, Вы писали:
B>2) авторитет. вы работаете на людей, которых никогда в жизни не видели. авторитет вашего директора — дефолтный? или он должен предварительно морду бить всем ньюкамерам? что должны сделать манагеры среднего звена, что бы вы их зауважали? если вы согласны только с идеологией сильного... скажите вашему боссу, что бы пригласил ближайшего секьюрити. это будет достаточной демонстрацией силы?
Все от незнания, не может быть руководителя без авторитета, это а-к-с-и-о-м-а! И если у вас возникло несогласие с этим, то вам следует либо повзрослеть ещё немного, либо заиметь побольше опыта в руководстве, либо подучить матчасть.... и теоретические основы...
И вообще у меня _лично_ сладывается два представления из постов на этом форуме, первое и немного для меня не ожиданное, скажу често, это то что все слабоспособные программисты переходят в менеджеры, и на этой должности скучают и бесятся от того, что занимаются не тем делом. И второе, что почти всё здесь выступающие за команду "МЕНЕДЖЕР" наивные теоретики...
Уважаемы господа самоидентифицирующие себя как МЕНЕДЖЕРЫ .... управление людьми это тоже искуство, так же как и програмирование... Потому как "сколько не учи но если Бог недАл, то и толку не будет"... И этому кстати надо учится, или самоучится, покрайней мере...
B>ни к чему не призываю, но обьявлять новому манагеру, что он "не имеет авторитера в группе" — показать свой глубокий непрофессионализм.
Нормально, абсолютно нормально... Приходит такой мальчик, типа Кириенко, и нихрена не понимая ни в управлении людьми, и не имея ни малейшего представления в технических вопросах, начинает бодренько так руководить, причем чисто но наитию... Устривая всякие опросы типа "Что вас мотивирует?" А потом обижается, на то что команда, не им кстати собраная разбегается, на то что на его указания забивается болт, и в ответ на его "Я ТРЕБУЮ ПОДЧИНЕНИЯ!!!!" ему говорят, а пошёл ты на...
Не его это... не родился он руководителем...вот и всё... ИЛИ не созрел еЩо...
Здравствуйте, ggg, Вы писали:
_>>Знаем мы таких "слушающих руководителей", были такие. Иногда проще уволиться чем пытаться объяснять что-то человеку, который не намерен даже пытаться понять то, о чем ты говоришь.
ggg>По-хорошему, у руководителя должен быть некий авторитет, чтобы его слушали. Какие-то удачные проекты (предыдущие), значимый опыт, ценные знания и т.д. Тогда и сотрудники (хоть с 1-2 годами опыта) будут прислушиваться. ggg>В России же, имхо, относительно часто ситуация, когда не совсем очевидно, почему этот самый менеджер (аналитик, архитектор, руководитель, начальник — где как назвать) должен предложить лучшее техническое решение. Невсегда очевидно, за какие такие свои предыдущие заслуги этот менеджер дает указания программисту, как и что делать. ggg> Аргументация "я менеджер, слушай меня" — далеко не лучший способ договариваться. Вот если за плечами руководителя удачные проекты (значимые модули в каких-либо проектах), и подчиненный в курсе этого, то скорее всего, ему легче будет прислушаться. Ну и договориться, соответственно, тоже легче.
интересный спич...
в банде, где все готовы сорвать куш и разбежаться нужен авторитетный пахан.
если мы с вами беседуем о промышленном(!) производстве программного обеспечения, тогда давайте промышленно и рассуждать.
1) кто дал право заказчику ставить нам задачу? извините за банальность, деньги, которые он пратит за выполнение заказа!
пример из вашего спича: когда вы делаете заказ, вы видимо ожидаете, что человек, которому вы платите деньги, подойдет к вопросу творчески, и потратит ваши деньги так, как он считает правильным. после чего обьяснит вам, почему он это сделал. вы будете счастливы отказаться от своего заказа в пользу его новой идеи.
2) авторитет. вы работаете на людей, которых никогда в жизни не видели. авторитет вашего директора — дефолтный? или он должен предварительно морду бить всем ньюкамерам? что должны сделать манагеры среднего звена, что бы вы их зауважали? если вы согласны только с идеологией сильного... скажите вашему боссу, что бы пригласил ближайшего секьюрити. это будет достаточной демонстрацией силы?
3) а кто отчитывается за заказ, потраченые деньги, отработаные часы? каждый персонально перед заказчиком, или там все же существует некоторая иерархия? когда каждый уровень отчитывается только перед одним конкретным человеком? или вам лично необходимо ежедневно отчитываться перед списком людей, при этом для каждого по-своему? ну вот просто интересно — чисто поржать.
ни к чему не призываю, но обьявлять новому манагеру, что он "не имеет авторитера в группе" — показать свой глубокий непрофессионализм.
профессионалу совершенно фиолетово: где, что, как и когда делать, если за это платят. если его что-то не устраивает, он решает свои проблемы по минимуму загружая других людей.
чайник: ...нет хуже дурака, да с инициативой.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Здравствуйте, Аноним, Вы писали: AWW>Я всё жду когда талантливых программистов будут сдавать в аренду или продавать как футболистов... Я бы это юное дарование купил бы...
Пожалуйста, он недавно уволилился.
AWW>А статья бред, мы именно тем и лучьше индусов, что у нас есть ребята которые не за бабки, а за интерес...
А у него пропал интерес
Человеку была поставлена задача: за 2 недели нужно сделать то-то и то-то. Это ДОЛЖНО работать и на экране я хочу увидеть вот такую то функциональность. Причем, если я увижу это через 2 недели, то мы будем использовать его задумку. Если нет — нет. Через 2 недели мне показали solution из 12 проектов, штук 50 классов и форму с одной кнопкой. Рассказали, что за этим скрывается мега-механизм, надо его только доработать.
Как и было обещано, при таком результате от его предложения отказались в пользу более простого решения. С человеком случилась истерика, и он сказал, что "к проекту в целом у него пропал интерес" (цитирую). И он уволился. Удерживать не стал.
PS: штука в том, что "генальная" идея отнюдь не нова и не гениальна. Ей уже лет 8 как и она всегда, всегда возникает при разработке системы с определенной архитектурой. Юное дарование не обладает каким-то особым "даром". Обычный неплохой программист, с отсутствием опыта и уверенностью, что он "творит".
V>Лично я бы уволил тут же менеждера этого человека. V>Не понимаю, как можно дать подчиненному задачу, зная заранее, что он V>собирается повторить туже ошибку, что уже совершали 8 лет назад. V>Не понимаю, как можно потратить 2 недели труда "неплохого программиста" V>(ваши слова), только на то, чтобы он убедился в том, что ошибается и V>после этого фактически уволить его.
V>По крайней мере так я понял ваш пост.
Ребенок хочет прыгнуть с балкона, чтобы полететь.
Ему можно запретить. Тогда он обидится и будет ходить обиженный и когда-нибудь таки попробует.
Можно обьяснить, что папа прыгнул 30 лет назад и показать вмятину на асфальте и голове у папы. Ребенок может и согласится, но в душе будет уверен, что папа просто не умел прыгать и когда-нибудь таки попробует.
А можно дать прыгнуть со шкафа на матрас. Тогда он ударится, заплачет и убежит в другую комнату. Но прыгать уже не будет.
Никто никого не собирался увольнять, если вы не поняли.
Речь шла о том, чем опасны программисты, работающие "потому что интересно".
PS: с ним надо было бы после всего сесть, разобрать ситуацию и показать почему его идея была изначально гиблой. Вооруженный некоторым опытом, он бы наверное понял. Но он предпочел уволиться.
Сгибатель wrote: > > Применим, ещё как применим. Меня как заказчика программного обеспечения > интересуют всего три величины: качество, сроки и $стоимость$.
Итого три желания: денег, еще денег, и еще 100 желаний.
Вас, скорее всего, интересует гораздо больше чем просто три
величины, вы просто спрятали большинство из них под одним
словом "качество". Да и со стоимостью непросто — речь
идет о стоимости производства, стоимости поддержки, или
общей стоимости владения ? В последних случаях, на какой
срок использования это все рассчитывается ? И т.д. и т.п.
Если речь только о соответствии спецификациям и низкой
стоимости исходной разработки, то с высокой вероятностью
будет классический сценарий с write-only кодом и наймом
студентов для его якобы простой поддержки. Вы уверены,
что вас именно это интересует ? А под описание подходит.
. Кто его создал? Смотрим профайл: "Пректирование и разработка систем безопасности, Сетевые драйвера под NT". Но учит-то он менеджеров проектов. Он учит людей, хотя он сам не менеджер проектов, а находится на более низком уровне абстракции.
Слава! Раз уж тут меня каким-то образом склоняют, придётся немного представится... Я даже не менеджер проекта , а "немного" повыше ... И даже уж давно как... И учу я их.... хотя.... совсем не учу, а лишь рассказываю, что есть такая наука как управление людьми и есть такая наука как маркетинг... и есть такая наука как менеджмент и психология.... Да и вам бы как начинающему шароварщику... (забавный бизнес) неплохо было бы подучится для того чтобы понимать, ну в объщем то конечно не очень простую штуку как торговля, со своими терминами и понятиями.... но не настолько уж...
Ну да ладно... Посмотрим, что вы тут написали в соседних ветках....
СШ> Зачем нужен программист, который не понимает, что другой человек знает что-то лучше? Типичный пример. Просишь человека доработать модуль. Выкатываешь детальное ТЗ. В ТЗ прописано даже требование соблюсти стиль оформления кода.
Налицо явная обида, только на кого надо обижаться? В этой ситуации Слава надо обижаться только на себя. А иначе мы начнём напомитать королей которые недовольны своим народом. Запомните Слава, всё неудачи подчиненных это неудачи только их руководства, начиная с той, что именно на эту позичию назначили человка котрый ни морально но психологически не соответсвует ей. Небывает плохих солдат бываю только плохие генералы. Я это понял ещё в далёком 1990 году, когда руководил лабораторией системного программирования в НИИ ПС, и у меня в подчинении было 10 человек. Люди всё разные, к каждому, Слава, нужен индивидуальный подход.
СШ>Статья указывает очень известную в ряду наших аутсорсеров проблему. Решение её известно: надо писать и продавать свои высокотехнологичные продукты (Касперы, Abby, Орфо, Промт и пр.). А всю рутину оставить индусам.
Статья утверждает, что индийские программисты лучше Российских. И само возникновение этой статьи это проблема, и проблема не только наша и совсем не программистов. И в каждой издушке свои погремушки, в штатах это проблема стимости рабочей силы, у них есть даже такое выражение — "мою работу сбангалорили" и что американские программисты по вашему тоже плохие, раз индусам работу их отдают... У нас,(и это уже очень острая проблема!) это качество и количестов качественных менеджеров. У нас ведь как известно, каждый знает как правильно управлять государством, и учится этому совсем не требуется... Ну а уж отделом или командой так вообще как два пальца... Ну вот и вы кстати тому яркий пример...
Одним словом, Слава рекомендую вам поинтересоваться трейдингом, психологией, маркетингом и менедженментом... И ваших проблем не будет как класс, то что вы назаваете проблемой, это просто ежедневный рутинный труд управленцев... С людми конечно труднее чем с программами, они живые.
А мотивом написать всё это, стало то, что мои менеджеры точно также, совершенно не справляются со своими задачами, и где найти других совершенно не вижу... Нехотят люди учится, а плохо это на самом деле....
В результате, выпускники наших вузов до сих пор считают разработку ПО разновидностью искусства а не производственным процессом (о последнем они зачастую не имеют ни малейшего понятия). Отсюда проблемы с клиентами, поскольку зачастую требования клиента противоречат понятиям российского программиста об искусстве (никто не сравнится с нашими соотечественниками в постоянном желании переписать все к чертовой матери с нуля, какой бы сложности не был первоначальный продукт).
При правильной постановке процесса в компании, впрочем, эту национальную черту удается успешно нивелировать и со временем это проходит
А зачем нивелировать? Чтобы составить конкуренцию индусам? Но "как у них" не получится. Равняясь на кого-то постоянно остаёшься на шаг позади. Может лучше наоборот, стараться найти нишу, которая соответствует национальному характеру? Конечно, это не снимает проблем грамотного менеджмента, организации технологического процесса. И проблема, скорее, как раз в отсутствии в нашем национальном характере склонности к менеджменту, а не в избытке творческого потенциала.
Здравствуйте, execve, Вы писали:
E>Здравствуйте, Joker6413, Вы писали:
J>>Здравствуйте, Аноним, Вы писали:
А>>>здесь
J>>тот кто писал — профан...
J>>рассияния — порядка 40 000 программистов J>>индия — порядка 800 000 программистов
E>Писавший знал о чём пишет.
Ну давайте научит 40 000 английскому догонит тогда рассияния по обьема аутсорсинга индию или нет?
E>У нас никогда не учили и не учат промышленному программированию.
А что мешало? Почему индусов учат, а наших нет?
E>Причём здесь сравнение "длин" — непонятно.
Название статьи читали? Почему программы чаще заказывают индийцам
так у меня готовый ответ и без демагогии и п.р: — да патамушта индусская отрась в 20 РАЗ крупнее!!!
Следовательно согласно экономич. целесообразности, они получат как минимум в 20 РАЗ больше заказов! Что бы не понять этого, а бормотать глупости по поводу английского языка, автору надо быть имбициллом.
Это вызвано пробелами в системе образовании, которая до сих пор ориентирована более на технологии (читай – искусство программирования), чем на процесс производства програмного обеспечения. В результате, выпускники наших вузов до сих пор считают разработку ПО разновидностью искусства а не производственным процессом (о последнем они зачастую не имеют ни малейшего понятия). Отсюда проблемы с клиентами, поскольку зачастую требования клиента противоречат понятиям российского программиста об искусстве (никто не сравнится с нашими соотечественниками в постоянном желании переписать все к чертовой матери с нуля, какой бы сложности не был первоначальный продукт).
Подписался.
Это действительно не смешно. Ужасно много времени уходит на борьбу с очередной гениальной идеей какого-нибудь юного дарования с 2 годами опыта.
Очень часто звучащий аргумент о том, что дескать у индусов "родной английский" — это очень сомнительный аргумент. Родной язык у них все же другой. Среднестатистическому индусу английский язык нужен не чаще чем среднестатистическому жителю России. И многие индусы (в том числе и программисты) по английски вообще не говорят, или говорят так, что их никто не понимает, в том числе и те, для кого английский — родной.
И уж особенно смешно видеть преимущество индусов "в вопросах ориентации на потребителя" — с чего бы это? Индусы в своей стандартной жизни не вращаются в англоязычной среде, и сокровенных знаний об анлоязычных потребителях имеют не больше россиян.
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% таланта".
Имхо роль харизмы и таланта в жизни руководителя сильно переоценена.
A>Человеку была поставлена задача: за 2 недели нужно сделать то-то и то-то. Это ДОЛЖНО работать и на экране я хочу увидеть вот такую то функциональность. Причем, если я увижу это через 2 недели, то мы будем использовать его задумку. Если нет — нет. Через 2 недели мне показали solution из 12 проектов, штук 50 классов и форму с одной кнопкой. Рассказали, что за этим скрывается мега-механизм, надо его только доработать.
А в течение этих двух недель можно было пару раз подойти, спросить, что и как планируется-делается?
"Юность" тут непричем. Мне, к сожалению, приходилось работать и с опытными людьми, любящими плодить абстракции там где это ну совершенно не требуется, и наоборот, даже мешает.
Умение адекватно воспринимать поставленные задачи не всегда от опыта работы зависит.
Более того, человеку с "значительным опытом" порой бывает просто невозможно объяснить, что он неправильно понимает задачу.
Здравствуйте, Сгибатель, Вы писали:
С>>>Применим, ещё как применим. Меня как заказчика программного обеспечения интересуют С>>>всего три величины: качество, сроки и $стоимость$.
AWW>>Заиметь приимущество продукта можно только предложив новую идею, усовершенствовав или возродив старую... С>Это пять! Без тени иронии. Только вот генерация серьёзных идей это удел стратегического менеджмента, С>но никак не программистов, если только не считать программистом каждого, кто хотя бы пишет "электронные письма".
Вам нравится слово менеджер? Тогда на здоровье, будьте менеждером... А мне нравится программист, потому как мы всё равно именно этим и занимается даже будучи на руководящей должности... Только програмируем мы без кодирования, опосредованно так сказать...
С>Искусство — специфический вид отражения и формирования действительности человеком в процессе художественного творчества в С> соответствии с определенными эстетическими идеалами.
Не удачное определение, скажем так совсем не удачное, типа из энцеклопидического словаря... чтоб всем и каждому...
Искуство это от слова искустно... То есть виртуозно, профессионально, лучше многих и т.д. ... А так получается смешно, согласитесь — "Искуство управления предприятием" ... или "Искуство дипломатии" Какое уж тут художественное творчество Или ещё смешнее — "Искуство рукопашного боя"
С>Даже широко рассматривая термин скусство, я никак не могу назвать программирование таковым.
А я могу, потому как это талант, и если вы не видели понастоящему талантлевых програмистов, то вам очень не повезло... Если бы это был не талант, то небыло бы такого кадрового дифицита, причем что характерно — во всём мире...
И тут уж как ни крути но если от бога нет, то и не научишь...
Т>Ну зачем же так =) Хотя старушка Евпропа меня разочаровала... Бюрократией они могут заниматься... Вообще последнее время в IT рулит азия — Япония, Корея — но там очень закрытый рынок и они предпочитаю скупать технологии и потом продавать как свои... Т>Меня последнее время очень радует компания Самсунг — они очень хитро...ные, ездят по России, смотрят кто-что делает, многие кидаются на известное имя, рассказывают всё и как, а оные тырят идеи, если не запатентованы, а потом если видят перспективность, сами разрабатывают и выпускают, мелкая контора не может конкурировать и продвинуть на рынок, а они на этом делают деньги. Вообще у многих IT компаний в России есть главная проблема — делают, изобретут, а раскрутить не могут...
Это всегда так было — мне еще отец рассказывал как японцы скупали журналы типа "Наука и Жизнь", где наши самоделкины придумывали что-то, а японцы у себя ставили на поток. Элементарный пример — крышки для сковородок: их неудобно брать за ручку (они же металлические и нагреваются => ручка у крышечки нагревается). Кто-то придумал в крышку засовывать пробку (от бутылки с вином) — за нее очень удобно брать. Идея нашла таки массовое применение.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Aviant, Вы писали:
A> мне кажется, что челоеку с опытом в 7-8 лет проще что-то обьяснить и о чем то с ним договориться, чем с опытом в 1-2 года.
моё мнение, что дело здесь совсем не в стаже работы, а в умении "договариваться" вообще...
Здравствуйте, Andrew.W Worobow, Вы писали:
С>>Применим, ещё как применим. Меня как заказчика программного обеспечения интересуют С>>всего три величины: качество, сроки и $стоимость$.
AWW>Заиметь приимущество продукта можно только предложив новую идею, усовершенствовав или возродив старую...
Это пять! Без тени иронии. Только вот генерация серьёзных идей это удел стратегического менеджмента,
но никак не программистов, если только не считать программистом каждого, кто хотя бы пишет "электронные письма".
AWW>Да! И что очень важно надо определиться терминологически — на мой взгляд есть кодирование, а есть програмирование... Если продукт небольшой, то это выполняет один человек, ну а если большой то програмирует только небольшая группа, а кодирует (выполняя задания первых) все остальные...
Действительно, разобраться в терминологии нам просто необходимо.
Программирование — в широком смысле — процесс подготовки и составления программы деятельности, выполнение которой должно привести к
определенным целям.
Программирование — процесс подготовки задач для их решения с помощью компьютера; итерационный процесс составления программ.
Искусство — специфический вид отражения и формирования действительности человеком в процессе художественного творчества в
соответствии с определенными эстетическими идеалами.
Даже широко рассматривая термин скусство, я никак не могу назвать программирование таковым.
Увы и ах.
Здравствуйте, savaDAN, Вы писали:
DAN>вопрос в другом: как подчиненный должен относиться к руководителю "по умолчанию"? Должен ли он предполагать что у руководителя авторитет есть (раз его начальником назначили) или же наоборот должен считать, что начальник дурак, и каждое его слово подвергать сомнению?
Не должен, он не должен предпологать наличие... А вот руководитель должен быть таким.... и вести себя так.... чтобы у подчиненных не возникало сомнения в его авторитетности...
DAN>В технических деталях он может быть более слабым, чем разработчики которыми он руководит. Это нормально, хотя бы потому, что невозможно быть в курсе деталей постоянно меняющейся отрасли. У менеджера задача и области другие.
Нет! Он должен, даже обязан! По своей должности разбираться в новинках, а вот исполнитель как раз не должен... Его обязанность в той или иной степени владеть теми инструментами и приемами которые он обьявил в своём резюме...
DAN>Или вы считаете что директор завода должен уметь выточить хитрую деталь на станке лучше чем рабочий с 30и летним стажем?
Давайте-ка лучше рассмотрим не завод, с его 10 тысячками рабочих... А футбольную команду, что годаздо ближе к нашим структурам... Тогда ваш вопрос можно перефразировать так — "должел ли тренер играть в футбол лучше своих игроков?" Ответ нет не должен, но он должен знать как это делается гораздо лучше их... И за это игроки должны его уважать и верить в его правоту, иначе команда обречена на проигрыш...
DAN>Давайте попробуем найти компромисс. ИМХО, в любом деле присутсвует две составляющие: рутинный, хорошо формализуемый труд, и неформализуемая часть, которую можно назвать "талант", "дал бог" и т.п.
Ну да, это очевидно, и....?
DAN>К исскуству, на мой взгляд, это отношения по прежнему никакого не имеет, т.к. на мой взгляд искусство это то, что призвано приносить эстетическое наслаждение.
Трёхтомник Кнута под название "Искуство програмирования" видели?
Уже писал, искуство это от русского слова искустно, то есть виртуозно, мастерски и.д. Например "искустная вышивка" "искустная рукодельница"
DAN>То что имеет какую-то другую цель (полезность) искусством являться не может.
Может!... и является — мебель, одежда, архитектура... и т.д.
DAN>Подождите, так _не умеет_ управлять (т.е. не знает как это делается) или _не родился_ (бог не дал, а сколько не учи — толку не будет)?
Страно что не понятно... — умение руководить это врожденное, и оно может быть как у всё другое в той или иной степени представлено у индивидуума.... И если имеет место полное отсутствие наличия, то тут сколько не учи, сколько не развивай ничего не выдет — "Бог не дал!"... Харизма не та... Тут также как с музыкальным слухом... Сколько книжек не читай, на курсы не ходи, на скрипке играть не станешь...
Здравствуйте, Сгибатель, Вы писали:
С>В любой деятельности есть место фантазии, нестандартным решениям etc, С>но таки "искусство" это вы, право слово, слишком.
Ну да, ну да. Онако разные реализации одной и той же задачи могут выглядеть (работать) по разному, даже если они работают с точки зрения заказчика одинаково. И даже в этом случае одна из них может быть сделана бездарно, а другая красиво, только определить это будет под силу специалисту.
Может быть искусство это создать, что то в правильные сроки (время) и с правильными функциями (идеями), но так как этого хочет автор, и так как для него это правильно-красиво? Знающий скажет, что это искусство. Не знающий скажет, что это хорошо сделанная работа.
AWW>Все от незнания, не может быть руководителя без авторитета, это а-к-с-и-о-м-а! И если у вас возникло несогласие с этим, то вам следует либо повзрослеть ещё немного, либо заиметь побольше опыта в руководстве, либо подучить матчасть.... и теоретические основы...
Это само собой, вопрос в другом: как подчиненный должен относиться к руководителю "по умолчанию"? Должен ли он предполагать что у руководителя авторитет есть (раз его начальником назначили) или же наоборот должен считать, что начальник дурак, и каждое его слово подвергать сомнению?
Я конечно скажу банальность, но в этом различии кроется очень многое. Задача менеджера: обеспечение коммуникаций между участниками проекта и координация работы. В технических деталях он может быть более слабым, чем разработчики которыми он руководит. Это нормально, хотя бы потому, что невозможно быть в курсе деталей постоянно меняющейся отрасли. У менеджера задача и области другие. Или вы считаете что директор завода должен уметь выточить хитрую деталь на станке лучше чем рабочий с 30и летним стажем?
Когда разработчик это понимает получается конструктивный диалог, в котором оба участника поправляют друг-друга в тех областях, в которых они наиболее сильны. Когда пытается доказать что менеджер глупее его, ничего кроме "раскачивания лодки" не происходит.
AWW>И вообще у меня _лично_ сладывается два представления из постов на этом форуме, первое и немного для меня не ожиданное, скажу често, это то что все слабоспособные программисты переходят в менеджеры, и на этой должности скучают и бесятся от того, что занимаются не тем делом. И второе, что почти всё здесь выступающие за команду "МЕНЕДЖЕР" наивные теоретики...
Приведите, пожаулйста, конкретные примеры.
AWW>Уважаемы господа самоидентифицирующие себя как МЕНЕДЖЕРЫ .... управление людьми это тоже искуство, так же как и програмирование... Потому как "сколько не учи но если Бог недАл, то и толку не будет"... И этому кстати надо учится, или самоучится, покрайней мере...
Давайте попробуем найти компромисс. ИМХО, в любом деле присутсвует две составляющие: рутинный, хорошо формализуемый труд, и неформализуемая часть, которую можно назвать "талант", "дал бог" и т.п.
К исскуству, на мой взгляд, это отношения по прежнему никакого не имеет, т.к. на мой взгляд искусство это то, что призвано приносить эстетическое наслаждение. То что имеет какую-то другую цель (полезность) искусством являться не может. Несомненно, в хорошо сделанном проекте присутствует элемент эстетического удовольствия, но этот компонент побочный, если продукт не будет выполнять своей цели — он никому не нужен, если он будет решать задачу, но не приносить эстетического удовольствия — это по прежнему продукт.
B>>ни к чему не призываю, но обьявлять новому манагеру, что он "не имеет авторитера в группе" — показать свой глубокий непрофессионализм. AWW>Нормально, абсолютно нормально... Приходит такой мальчик, типа Кириенко, и нихрена не понимая ни в управлении людьми, и не имея ни малейшего представления в технических вопросах, начинает бодренько так руководить, причем чисто но наитию... Устривая всякие опросы типа "Что вас мотивирует?" А потом обижается, на то что команда, не им кстати собраная разбегается, на то что на его указания забивается болт, и в ответ на его "Я ТРЕБУЮ ПОДЧИНЕНИЯ!!!!" ему говорят, а пошёл ты на... AWW>Не его это... не родился он руководителем...вот и всё... ИЛИ не созрел еЩо...
Подождите, так _не умеет_ управлять (т.е. не знает как это делается) или _не родился_ (бог не дал, а сколько не учи — толку не будет)?
Здравствуйте, Joker6413, Вы писали:
J>Здравствуйте, Аноним, Вы писали:
А>>здесь
J>тот кто писал — профан...
J>рассияния — порядка 40 000 программистов J>индия — порядка 800 000 программистов
Писавший знал о чём пишет.
У нас никогда не учили и не учат промышленному программированию.
Здравствуйте, Сгибатель, Вы писали:
С>Управленец и исполнитель суть разные "должности". А-то я крановщик, но таки и космонавт, опосредованно так сказать.
На мой взгляд очень толково расказывается почему нельзя управлять программистами так же как водопроводчиками или инжинерами-электронщиками... Если вы хотите получить от них хоть какой-то полезный результат...
С>>>Искусство — специфический вид отражения и формирования действительности человеком в процессе художественного творчества в
С>>> соответствии с определенными эстетическими идеалами.
AWW>>Не удачное определение, скажем так совсем не удачное, типа из энцеклопидического словаря... чтоб всем и каждому...
С>Вы правильно указали, из словаря и взято. Так как именно они дают общепринятую формулировку.
AWW>>Искуство это от слова искустно... То есть виртуозно, профессионально, лучше многих и т.д. ... А так получается смешно, согласитесь — "Искуство управления предприятием" ... или "Искуство дипломатии" Какое уж тут художественное творчество Или ещё смешнее — "Искуство рукопашного боя"
С>А какое художественное творчество вы увидили в программировании?
С>Программный код, как таковой, является предметом авторского права, но вот, чтобы он ещё имел художественную ценность
Я то как раз и невижу там ничего художественного, но от этого это не станивится не искуством... Специально оставил цитаты, ещё раз пробегителсь глазами...
AWW>>А я могу, потому как это талант, и если вы не видели понастоящему талантлевых програмистов, то вам очень не повезло... Если бы это был не талант, то небыло бы такого кадрового дифицита, причем что характерно — во всём мире...
С>А какое отношение талантливый программист имеет к искусству по роду своей деятельности? С>Код подобный полотнам Дали ещё видеть не приходилось
Да потому, что искуство это не художество.... Точнее не только художественное творчество...
С>Возможно мы с вами немного по разному это самое программирование понимаем. С>Но как бы то ни было, ... не верую, что искусство
Скажите вы сами програмировали, или только руководили?
Здравствуйте, Сгибатель, Вы писали:
AWW>>Искуство это от слова искустно... То есть виртуозно, профессионально, лучше многих и т.д. ... А так получается смешно, согласитесь — "Искуство управления предприятием" ... или "Искуство дипломатии" Какое уж тут художественное творчество Или ещё смешнее — "Искуство рукопашного боя"
С>А какое художественное творчество вы увидили в программировании? С>Программный код, как таковой, является предметом авторского права, но вот, чтобы он ещё имел художественную ценность
А какое художественное творчество вы увидили, к примеру, в литературе?
Книги тоже являются предметом авторского права, но вы же не спорите, что они имеют художественую ценность?
Сам программный код — конечно не имеет, но вот способ реализации конкретной задачи — очень даже.
Так же как слова в книге не являются чем-то особенным, но вот выражаемые ими мысли очень часто заставляют задуматься.
Здравствуйте, Me_, Вы писали:
Me_>Ну хоть бы описали, что это такое — процесс производства програмного обеспечения, если не искусство. А то складывается впечатление, что автор призывает не особо-то фантазировать над архитектурой и прочим, а делать все быстро. Как на заводе: пришла болванка, обточил, отправил дальше по конвееру — хороший пример производственного процесса. Только вот применим ли он в разработке ПО
Ну конечно же, и обтачивание болванок искусство, и выпечка хлеба искусство, и самогон гнать или там пиво варить — все это искусства.
Собственно автор статьи именно о таком отношении, имхо, и пишет.
Ну ничем производство ПО не отличается от любого другого процесс — программирование и вообще ИТ давно перестали быть уделом избранных, а стали обычной индустрией — не хуже и не лучше остальных. Везде есть место для творчества, но ни одно производство не состоит на 100% из него.
Здравствуйте, Me_, Вы писали:
Me_>Ну хоть бы описали, что это такое — процесс производства програмного обеспечения, если не искусство. А то складывается впечатление, что автор призывает не особо-то фантазировать над архитектурой и прочим, а делать все быстро. Как на заводе: пришла болванка, обточил, отправил дальше по конвееру — хороший пример производственного процесса. Только вот применим ли он в разработке ПО
Применим, ещё как применим. Меня как заказчика программного обеспечения интересуют
всего три величины: качество, сроки и $стоимость$.
Заметьте, что Петровы-Водкины от области постикремента и амперсанда сюда вписываются
крайне опосредованно.
Так что более подходящее сравнение именно с конвеером. Не даром же понаписано несчётное
количество библиотек(читай болванок).
В любой деятельности есть место фантазии, нестандартным решениям etc,
но таки "искусство" это вы, право слово, слишком.
Здравствуйте, execve, Вы писали:
E>Писавший знал о чём пишет.
Не совсем.
E>У нас никогда не учили и не учат промышленному программированию.
Это ты сейчас не о программистах говоришь, а о ПМ-ах... Этих — да, действительно не учат. Но непосредственно к программированию это имеет довольно посредственное отношение.
Здравствуйте, Сгибатель, Вы писали:
С>Здравствуйте, Me_, Вы писали:
Me_>>Ну хоть бы описали, что это такое — процесс производства програмного обеспечения, если не искусство. А то складывается впечатление, что автор призывает не особо-то фантазировать над архитектурой и прочим, а делать все быстро. Как на заводе: пришла болванка, обточил, отправил дальше по конвееру — хороший пример производственного процесса. Только вот применим ли он в разработке ПО
С>Применим, ещё как применим. Меня как заказчика программного обеспечения интересуют С>всего три величины: качество, сроки и $стоимость$.
Заиметь приимущество продукта можно только предложив новую идею, усовершенствовав или возродив старую...
Одним словом в рыночной гонке побеждают только по конкурсу конструкторов, а не по скорости прохождения круга... А конструирование это творчество, а не производство... производство это выпуск программного продукта на заводе в виде коробки, видели как Windows в коробки складывают... или организация продаж его через интернет...
И если уж даже рассматривать конструирование как продукт, так же можно рассматривать и как продукт — получение золотых медалей на олимпийских играх, рисование картин с этой точки зрения получается также производство, как сообственно и писание романов и т.д.
Единственное где програмирование можно рассматривать как производство так это при изготовлении программ на заказ... Типа автоматизации производства или бухгалтерии... А если же мы говорим про коробочные продукты или продукты для продажи то здесь програмирование не есть производство это чистой воды искуство, а вот развитие этих же продуктов ввиде новых версий это уже производство...
Да! И что очень важно надо определиться терминологически — на мой взгляд есть кодирование, а есть програмирование... Если продукт небольшой, то это выполняет один человек, ну а если большой то програмирует только небольшая группа, а кодирует (выполняя задания первых) все остальные...
Так что в варианте с индусами надо говорить, что они не програмисты, а кодировщики... Типа переводчиков или машинисток...
Здравствуйте, ggg, Вы писали:
ggg>А в течение этих двух недель можно было пару раз подойти, спросить, что и как планируется-делается?
Подходил конечно. "Все идет по плану, пишу механизм". Человек был уверен, что собственно функциональность он нарисует быстренько за один вечер. Конечно не нарисовал. Более того, шансов сделать то, что нужно так, как он хотел, за сроки, которые были нужны мне, у него не было никаких. О чем я его предупреждал с самого начала. Но он попросил предоставить возможность доказать свою правоту. Возможность была предоставлена.
ggg>"Юность" тут непричем. Мне, к сожалению, приходилось работать и с опытными людьми, любящими плодить абстракции там где это ну совершенно не требуется, и наоборот, даже мешает. ggg>Умение адекватно воспринимать поставленные задачи не всегда от опыта работы зависит. ggg>Более того, человеку с "значительным опытом" порой бывает просто невозможно объяснить, что он неправильно понимает задачу.
Вы абсолютно правы. Просто мне кажется, что челоеку с опытом в 7-8 лет проще что-то обьяснить и о чем то с ним договориться, чем с опытом в 1-2 года.
Здравствуйте, kittown, Вы писали:
K>Где как. Существуют типы задач, где исскуству места нет. Но эта область K>сильно ограничена. Кастомизация и другие откровенно типовые задачи.
K>Есть и другие случаи. Интересны проблемы чрезмерно обьемных проектов, K>когда их описание просто необходимо упрощать за счет введения новых K>терминов и понятий, иначе трудно оценить общую картину и избежать K>многократного изобретения велосипедов. Задача придумать хорошую K>шаблонную конструкцию уже находится на грани исскуства.
Для вас это на грани искусства, для меня же это проявление выской степени
профессионализма и хорошей интуиции.
K>У нас проект не сильно большой, но из-за нежелания обобщать K>повторяющиеся конструкции существует куча переизобретенных K>велосипедов. Тех же библиотек работы с сокетами в отдельных K>частях проекта своих нагородили. Изучать различия между K>ними — атас. То же самое про типичный клиенский и серверный K>код. Загнать все под один стандарт и в библотеку, треть K>кода стала бы проще и понятней. Однако, разработка ведется K>по четко организованному процессу, и ничего такого в нем K>не подразумевается. "Исскуство" исключили, получили издержки.
Наличие нескольких библиотек, с одинаковой функциональностью, в рамках одного прокета
это грубая ошибка. На мой взгляд не стоит утрировать, мол такое произошло из-за
ислючения "Искусства". Думаю причины совсем другие...
K>Когда из-за неумеренной обьемности вычислений придется K>вводить новые теоремы, сразу выходим на грань технологии и K>исскуства. Ситуация аналогичная приведенной выше.
Грань? Возможно вы и правы, но те ли это грани о которых вы говорите.
Есть у меня глубокие сомнения, что будь-то теорема Ферма или Standard Template Library
имеют какую-то художественную ценность. Может я конечно и ошибаюсь.
K>Но это другая тема. Предыдущее письмо было о том, что сокращение K>обсуждения до "сроки, деньги, качество" сводит дискуссию к K>банальностям и иногда бессмыслицам, а все интересное остается K>среди опущенных деталей.
Соглашусь, факт банальный, но таки имеющий место быть.
Но и сводить всё обсуждение к наличию "велосипедов" к некотором проекте
так же неконструктивно.
Резюмирую, скажу следующее. С вашим взглядом на этот вопрос согласен только отчасти
(что и в программировании есть место для творческого подхода), но никак не готов назвать это искусством. K>Mikhail
_>Знаем мы таких "слушающих руководителей", были такие. Иногда проще уволиться чем пытаться объяснять что-то человеку, который не намерен даже пытаться понять то, о чем ты говоришь.
По-хорошему, у руководителя должен быть некий авторитет, чтобы его слушали. Какие-то удачные проекты (предыдущие), значимый опыт, ценные знания и т.д. Тогда и сотрудники (хоть с 1-2 годами опыта) будут прислушиваться.
В России же, имхо, относительно часто ситуация, когда не совсем очевидно, почему этот самый менеджер (аналитик, архитектор, руководитель, начальник — где как назвать) должен предложить лучшее техническое решение. Невсегда очевидно, за какие такие свои предыдущие заслуги этот менеджер дает указания программисту, как и что делать.
Аргументация "я менеджер, слушай меня" — далеко не лучший способ договариваться. Вот если за плечами руководителя удачные проекты (значимые модули в каких-либо проектах), и подчиненный в курсе этого, то скорее всего, ему легче будет прислушаться. Ну и договориться, соответственно, тоже легче.
Я долгое время работал с индусами, в Индии был не раз. Не претендую на абсолютную истину, но, думаю, что с обсуждаемым вопросом знаком в достаточной мере.
У меня другие сведения на этот счёт, из первых рук так сказать В нормальную школу (в ту из которой потом можно стать программистом) без элементарных знаний английского не принимают (речь идёт о первом классе). Обучение едёт на английском языке все 10 или сколько их там у них лет. По результатам учёбы лучшим даётся возможность учиться дальше, в том числе и на программиста.
А как это противоречит моему утверждению? В статье говорилось, что для индусов английский язык — родной, что является несомненной ложью. Английский язык для индусов — иностранный язык, так же как и для жителей России. В повседневной жизни он не используется, масса людей его не понимают и на нем не говорят. Поэтому говорить о некоем изначальном преимуществе индусов на этом направлении — нельзя.
Другое дело, что у амбициозного молодого индуса есть понимание, что знание иностранного языка — это обязательное условие для того, чтобы сделать карьеру и добиться чего-то. И это всячески поддерживается как государством (школы и т.п.), так и на уровне семьи — родители стараются обеспечить изучение языка детьми с малых лет и т.д.
Акцент у них конечно своеобразный, иногда трудно понимабельный, но даже у вновь прибывших в штаты речь всегда беглая и в целом грамотная. Проблем с пониманием тоже нет. А вот проблемы с английским у русских и китайцев — это обычное дело. Правда, надо отметить, что так же я знаю нескольких русских, которые говорят по английски практически без акцента, но я не знаю ни одного такого индуса
Акцент у них действительно сильный. Насчет грамотной речи — не согласен. Как раз "грамотности" им обычно не хватает, именно из-за того, что они не варятся в англоязычной среде.
А насчет русских — так наши партнеры из Европы/США, например, постоянно твердят насколько легче им общаться с нами, нежели с индусами. Все-таки, менталитет, что ни говори, у нас не столь различается, да и акцент получше .
Ну зачем же так =) Хотя старушка Евпропа меня разочаровала... Бюрократией они могут заниматься... Вообще последнее время в IT рулит азия — Япония, Корея — но там очень закрытый рынок и они предпочитаю скупать технологии и потом продавать как свои...
Меня последнее время очень радует компания Самсунг — они очень хитро...ные, ездят по России, смотрят кто-что делает, многие кидаются на известное имя, рассказывают всё и как, а оные тырят идеи, если не запатентованы, а потом если видят перспективность, сами разрабатывают и выпускают, мелкая контора не может конкурировать и продвинуть на рынок, а они на этом делают деньги. Вообще у многих IT компаний в России есть главная проблема — делают, изобретут, а раскрутить не могут...
Здравствуйте, Sh1ZoID, Вы писали:
SZI> Вывод: британцы — полнейшие дебилы!
Неправильный вывод. У меня сложилось впечатление, что хорошие британские девелоперы, либо сидят на очччень неплохих местах, либо работают консалтерами за 500-1000 фунтов/день. По крайней мере уровень у тех, кого я встречал был весьма приличный, лучше, чем у 80% наших, кого мне приходилось собеседовать.
Здравствуйте, 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. я пишу на основании своего опыта из реальной жизни. ваши мечты об идеальной работе с изумительным манагером я понял.
B>напоминаю: B>1) изначально речь шла об отличии индийских программистов от русских. B>2) потом был приведен пример, как молодой программист отказался делать задание, которое ему выдали, B>и попытался сделать (внимание, не предложил к обсуждению, а попытался сделать) свое решение, B>на которое ему разрешили убить 2 недели оплачиваемого времени.
Еще раз — да, это плохо (то, что убил время, не сделал, не послушался). Но это не зависит от того — "начинающий с 1-2 годами опыта" или нет. В случае более опытных может сложиться и хуже.
B>в 2) был пример именно некомпетенции разработчика. считаете ли вы, что его не надо было принимать на работу, а если уж приняли — разрешить ему делать, то, что он хочет?
По-хорошему,должен был найтись человек, который грамотно (технически) объяснил бы ему, что его способ в разумное время не сделаешь.
Или бы просто сказал: "теоретически твое решение правильнее-грамотнее, но вот у нас так сложилось, что надо бы быстрее и проще. На практике, менее технлогочное, но сделанное решение лучше "правильного", но недоделанного".
B>делать что?.. я знаю таких не один пример. что делать манагеру? B>я знаю, как решают обычно такие ситуации. обычно человек снимается с проекта. B>его нельзя уволить. ...пока. но снять с работ — можно. в одном месте — это ударит рублем. в другом — нет. B>в любом — ударит по самолюбию. предложите свой вариант решения проблемы.
Если не помогают технические доводы, если не помогает фраза в стиле "нам сейчас нужен менее технологичный, но более быстрореализуемый результат", то снять с проекта, дать другую задачу.
B>конкретно по данному примеру. B>девелоперу дали 2 недели на подтверждение своих взглядов. вы считаете мало?
Ну, смотря какая задача.
B>сколько дней надо вам, что бы "протолкнуть" свое решение? B>у нас в команде считается нормальный 2-3 дня на "доказательство". мне давали день. рядом сидит человек, которому дали 3.
Где-то все разбивают на мелкие подзадачи, где действительно 1-2 дня достаточно.
Бывают более объемные задачи (просто никто не лезет в них, не конкретизирует, не разбивает на мелкие), когда 2 недели вполне нормально. Тут не зная области (прикладная, системные задачи и т.д.) нельзя сказать.
B>но я не понимаю, что такое "профессиональный авторитет". типа 100 человек должно сказать, что уважают вот этого конкретно?..
Что человек не просто занимает руководяющую должность (потому что у него друзья еще большие начальники), а что он до этого (с)делал то-то и то-то, и это (с разной степенью подробности) известно подчиненным.
B>ээээээээээээээээ... у нас тех.задания попроще. должно работать так-то. все.
Если из постановки "должно работать так и так" всем понятны примерные сроки, то ОК. Как бы в крайность не удариться (тут был не раз тред о работе в Ultra computers, где для торговой системы, отслеживающей склад и заказы, писали свой интерпретатор своего языка, причем за неделю — как утверждал работодатель. И что же, если один человек не напишет за неделю интерпретатор какого-то макроязыка для отчетов по складским операциям — его сразу в лохи? А начальство, поставившее такую задачу, премию получит?)
B>другой пример. вы переходите в другой проект. вот данного program-manager вы лично уважаете. B>что это значит?
Что я знаю, что это благодаря чуткому руководству и замечательным навыкам этого program manager'а проекты А, Б, В, Г были успешнои в срок выполнены
Когда приходишь в совсем новый коллектив, этого, конечно, никто не знает В этом случае по умолчанию считаю, что у него достаточно навыков и опыта для правильных решений. Но если несколько раз в ходе работы что-то проявится, то уважение (дефолтное) сойдет на нет.
B>человек, который ставит задачу _должен_ быть рядом с заказчиком. это аксиома.
Коробочные продукты. Иногда явного заказчика нет.
B>иначе будет плохой продукт. значит ли это, что между заказчиком и вами должно быть 2 человека?
Может и 2 быть. Абстрактно (от предметной области, от задачи) нельзя ничего сказать.
>да. если он просто поставит задание без указания, как писать код, это будет достаточно, что бы проблемы не возникло?
"Обсуждение, как писать код" нужно только тогда, когда это помогает четче определить сроки.
B>возможно я что-то забыл. но вы защищаете пример, в котором это было.
Не, я не пример защищаю (я там к "1-2 года опыта" прицепился, так как подобная позиция с опытом только усилится). Если амбициозный человек с годом опыта никого не стал слушать, то думаю, с 3-5 годами опыта он и подавно не послушает.
И все-таки, возможность договариваться — она не от одного человека зависит. Значит, не нашлось людей, которые убедить смогли (что странно, убедить начинающего несложно).
B>я уже писал про свой обыт работы с индусами. гору сроют, если показать, с которой стороны копать. B>в исходной статье — очень много правильного. видно, что человек пишет на основе своего опыта. B>так вот у них в бизнесе авторитет начальства зависит только от занимаемой должности.
Хмм. В нынешних условиях в России это, наверное, не очень сработает. Иногда начальниками не пойми за что становятся ;(
B>чем это плохо — проект может завалить один идиот.
Да! Вот против подобного я и выступаю!
B>чем хорошо — все знают, что если проект завалят, то только он будет виноват.
Хе-хе, как бы не вышло так, что начальство "отмажется", а разработчикам зарплату снизят.
B>менталитет? на нем иднусам и проигрываем. обидно!
А так ли обидно, что проигрываем? Индусы — это в массе своей рынок прикладного заказного ПО (где техническая реализация заранее известна большей частью, и где исполнителю нужно лишь выполнять предписанные требования). Коробочного софта они практически не выпускают. Да и софт от своего имени индусы вроде бы не делают.
Здравствуйте, Слава Шевцов, Вы писали:
КД>>Мой вывод — надо размножать русских
КД>>... возражающие есть?
СШ>Да, есть. Надо тотально переучить наших программистов. Точнее урезать ту часть их функционала, которая излишне новаторская и творческая.
Суицидом предлагаешь мне занятся?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Зачем нужен программист, который не понимает, что другой человек знает что-то лучше? Типичный пример. Просишь человека доработать модуль. Выкатываешь детальное ТЗ. В ТЗ прописано даже требование соблюсти стиль оформления кода.
Ну, вообщем, я сам такой, каким ты описал этого программиста... У меня, правда, хуже. Я когда рефакторю или дорабатываю модуль очень часто цепляю все его окружение. Наверное это выглядит как круги на воде. Например, вчера задумавшись над необходимостью написать три строчки на VB (копирование из одного контейнера в другой), грязно выругался, и написал сотню на плюсах (параллельно понял то, вспомнил это, исправил баги в очень старом коде). И только потом написал 1 строчку на VB. Я знаю что это — ненормально. Ненормально по всем параметрам. Но видать судьба такая.
Тут нужно с другой стороны подходить. Например, попробуй ему втолковать что "не научившись подчиняться — не научишься командовать" и скажи что это слова ... ну, например, Наполеона
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Это вызвано пробелами в системе образовании, которая до сих пор ориентирована более на технологии (читай – искусство программирования), чем на процесс производства програмного обеспечения. В результате, выпускники наших вузов до сих пор считают разработку ПО разновидностью искусства а не производственным процессом (о последнем они зачастую не имеют ни малейшего понятия). Отсюда проблемы с клиентами, поскольку зачастую требования клиента противоречат понятиям российского программиста об искусстве (никто не сравнится с нашими соотечественниками в постоянном желании переписать все к чертовой матери с нуля, какой бы сложности не был первоначальный продукт).
Ну хоть бы описали, что это такое — процесс производства програмного обеспечения, если не искусство. А то складывается впечатление, что автор призывает не особо-то фантазировать над архитектурой и прочим, а делать все быстро. Как на заводе: пришла болванка, обточил, отправил дальше по конвееру — хороший пример производственного процесса. Только вот применим ли он в разработке ПО
Здравствуйте, Me_, Вы писали:
Me_>Ну хоть бы описали, что это такое — процесс производства програмного обеспечения, если не искусство.
Процесс создания нового холодильника это искусство ?
Частично, очень частично. Вот так и тут.
Me_>А то складывается впечатление, что автор призывает не особо-то фантазировать над архитектурой и прочим, а делать все быстро.
Я не автор, за него не скажу, но IMO, к этому и призывает.
Me_>АКак на заводе: пришла болванка, обточил, отправил дальше по конвееру — хороший пример производственного процесса. Только вот применим ли он в разработке ПО
Еще как применим
Здравствуйте, execve, Вы писали:
E>Здравствуйте, Joker6413, Вы писали:
J>>Здравствуйте, Аноним, Вы писали:
А>>>здесь
J>>тот кто писал — профан...
J>>рассияния — порядка 40 000 программистов J>>индия — порядка 800 000 программистов
E>Писавший знал о чём пишет. E>У нас никогда не учили и не учат промышленному программированию.
У нас много чему толком не учат.
Проблема не только в обучении "промышленному программированию".
Если в стране в целом провал (во многих смыслах) в системе образования,
то с чего вдруг будут нормально учить "промышленному программированию".
Думаю Joker6413 это имел ввидую
Ситуация, кстати, на мой взляд, улучшается и уже есть грамотные спецы,
которые не по наслышке знают об управлении требованиями.
Здравствуйте, bkat, Вы писали:
А>>>>здесь
E>>У нас никогда не учили и не учат промышленному программированию. B>У нас много чему толком не учат. B>Проблема не только в обучении "промышленному программированию".
кроме шуток...
однажды я спросил: вот у меня сейчас за спиной реальный опыт "АСУчивания"
нескольких техпроцессов в крупных промышленых производствах. куда мне пойти преподавателем, рассказать об этом?
ответ: а нафиг ты нам нужен без степени и без связей в вузе?
студентам: никто вас в вузе "реальной жизни" учить не будет.
учитесь "налету" в "реальной жизни".
Здравствуйте, bastrakov, Вы писали:
B>Здравствуйте, bkat, Вы писали:
А>>>>>здесь
E>>>У нас никогда не учили и не учат промышленному программированию. B>>У нас много чему толком не учат. B>>Проблема не только в обучении "промышленному программированию".
B>кроме шуток... B>однажды я спросил: вот у меня сейчас за спиной реальный опыт "АСУчивания" B>нескольких техпроцессов в крупных промышленых производствах. куда мне пойти преподавателем, рассказать об этом? B>ответ: а нафиг ты нам нужен без степени и без связей в вузе?
Да, такие маразмы есть и будут.
Но есть и другие случаи когда преподы только рады,
когда какие-то спецкурсы студентам читают именно люди с реальным опытом.
Здравствуйте, kittown, Вы писали:
K>Итого три желания: денег, еще денег, и еще 100 желаний.
Тут вы бесспорно правы — желаний даже не сотни, а тысячи, но к
разработке программного обеспечения они имеют малое отношение, если имеют вообще
K>Вас, скорее всего, интересует гораздо больше чем просто три K>величины, вы просто спрятали большинство из них под одним K>словом "качество". Да и со стоимостью непросто — речь K>идет о стоимости производства, стоимости поддержки, или K>общей стоимости владения ? В последних случаях, на какой K>срок использования это все рассчитывается ? И т.д. и т.п.
Этот "треуголник величин" не мною придуман. Конечно же, его составляющие
образы "собирательные", скажем так. Но не совсем понимаю: вы хотите сказать, что
я за словами "качество" и "стоимость" спрятал рояль(читай Марью искусницу от программерского рода)?
Отнюдь, ничего я там не прятал
Суть моей мысли заключалась в том, что к исскуству это отношения не имеет.
K>Если речь только о соответствии спецификациям и низкой K>стоимости исходной разработки, то с высокой вероятностью K>будет классический сценарий с write-only кодом и наймом K>студентов для его якобы простой поддержки. Вы уверены, K>что вас именно это интересует ? А под описание подходит.
Михаил, мы кажется начали обсуждать совсем не то. Скоро скатимся до "великие троечники vs серые краснодипломники".
Я хочу выразить своё согласие с тем тезисом статьи, который говорит, что программирование не есть искусство,
но вид деятельности, высокоинтеллекуальной деятельности.
Математику, же никто искусством не называет. Хотя, согласитесь, здесь требуется куда более "изощрённое" мышление.
"Это я вас как математик математика спрашиваю:"Что такое математика? Один из законов Божьих, или сам Бог и есть?"" (с) K>Mikhail
На редкость правильно. В прочем, все это уже здесь не раз обсуждалось, и про "программирование как профессия для избранных" и про то, что индусы якобы дешевле.
Сгибатель wrote: > > Этот "треуголник величин" не мною придуман. Конечно же, его составляющие > образы "собирательные", скажем так. Но не совсем понимаю: вы хотите > сказать, что я за словами "качество" и "стоимость" спрятал рояль(читай > Марью искусницу от программерского рода)?
Я хочу сказать, что если выражаться более точно, то общая картина будет
вырисовываться несколько иная, чем если выражаться обобщенно и
упрощенно.
> Суть моей мысли заключалась в том, что к исскуству это отношения не имеет.
Где как. Существуют типы задач, где исскуству места нет. Но эта область
сильно ограничена. Кастомизация и другие откровенно типовые задачи.
Есть и другие случаи. Интересны проблемы чрезмерно обьемных проектов,
когда их описание просто необходимо упрощать за счет введения новых
терминов и понятий, иначе трудно оценить общую картину и избежать
многократного изобретения велосипедов. Задача придумать хорошую
шаблонную конструкцию уже находится на грани исскуства.
У нас проект не сильно большой, но из-за нежелания обобщать
повторяющиеся конструкции существует куча переизобретенных
велосипедов. Тех же библиотек работы с сокетами в отдельных
частях проекта своих нагородили. Изучать различия между
ними — атас. То же самое про типичный клиенский и серверный
код. Загнать все под один стандарт и в библотеку, треть
кода стала бы проще и понятней. Однако, разработка ведется
по четко организованному процессу, и ничего такого в нем
не подразумевается. "Исскуство" исключили, получили издержки.
> Я хочу выразить своё согласие с тем тезисом статьи, который говорит, что > программирование не есть искусство, но вид деятельности, > высокоинтеллекуальной деятельности.
> Математику, же никто искусством не называет. Хотя, согласитесь, здесь > требуется куда более "изощрённое" мышление.
Когда из-за неумеренной обьемности вычислений придется
вводить новые теоремы, сразу выходим на грань технологии и
исскуства. Ситуация аналогичная приведенной выше.
Но это другая тема. Предыдущее письмо было о том, что сокращение
обсуждения до "сроки, деньги, качество" сводит дискуссию к
банальностям и иногда бессмыслицам, а все интересное остается
среди опущенных деталей. В зависимости от них те же "художники"
и "скоростные кодеры" могут быть полезны, бесполезны или вредны,
а ввиду недостатка информации непонятно о чем вообще дисскуссия.
В примере про описания дизайна упрощение — благо. А тут — зло.
A>PS: с ним надо было бы после всего сесть, разобрать ситуацию и показать почему его идея была изначально гиблой. Вооруженный некоторым опытом, он бы наверное понял. Но он предпочел уволиться.
Знаем мы таких "слушающих руководителей", были такие. Иногда проще уволиться чем пытаться объяснять что-то человеку, который не намерен даже пытаться понять то, о чем ты говоришь.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Melo, Вы писали:
M>И многие индусы (в том числе и программисты) по английски вообще не говорят, или говорят так, что их никто не понимает, в том числе и те, для кого английский — родной.
100% верно, лапочут что-то даже не запариваясь хоть чуть-чуть с произношением поработать... И иногда смешно смотреть на носителей языка, которые примерно минут через пять начинают сообразать, что с ними оказавается по ангийски разговаривали...
E>>Писавший знал о чём пишет. J>Ну давайте научит 40 000 английскому догонит тогда рассияния по обьема аутсорсинга индию или нет?
нет конечно, тут ты прав да и опыта менеджмента проектами с большим количеством народа я так понимаю у России нет.
E>>У нас никогда не учили и не учат промышленному программированию. J>А что мешало? Почему индусов учат, а наших нет?
в статье написано — в Индии в это дело вкладывались деньги (равно как и в строительство технопарков, которые у нас еще только начинают собираться строить).
J>так у меня готовый ответ и без демагогии и п.р: — да патамушта индусская отрась в 20 РАЗ крупнее!!! J>Следовательно согласно экономич. целесообразности, они получат как минимум в 20 РАЗ больше заказов! Что бы не понять этого, а бормотать глупости по поводу английского языка, автору надо быть имбициллом.
тут еще в дешевизне дело — деньги в штатах решают оооочень многое
...Ei incumbit probatio, qui dicit, non qui negat...
AWW>100% верно, лапочут что-то даже не запариваясь хоть чуть-чуть с произношением поработать... И иногда смешно смотреть на носителей языка, которые примерно минут через пять начинают сообразать, что с ними оказавается по ангийски разговаривали...
очень знакомая ситуация
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Вам нравится слово менеджер? Тогда на здоровье, будьте менеждером... А мне нравится программист, потому как мы всё равно именно этим и занимается даже будучи на руководящей должности... Только програмируем мы без кодирования, опосредованно так сказать...
Управленец и исполнитель суть разные "должности". А-то я крановщик, но таки и космонавт, опосредованно так сказать.
С>>Искусство — специфический вид отражения и формирования действительности человеком в процессе художественного творчества в С>> соответствии с определенными эстетическими идеалами.
AWW>Не удачное определение, скажем так совсем не удачное, типа из энцеклопидического словаря... чтоб всем и каждому...
Вы правильно указали, из словаря и взято. Так как именно они дают общепринятую формулировку.
AWW>Искуство это от слова искустно... То есть виртуозно, профессионально, лучше многих и т.д. ... А так получается смешно, согласитесь — "Искуство управления предприятием" ... или "Искуство дипломатии" Какое уж тут художественное творчество Или ещё смешнее — "Искуство рукопашного боя"
А какое художественное творчество вы увидили в программировании?
Программный код, как таковой, является предметом авторского права, но вот, чтобы он ещё имел художественную ценность
AWW>А я могу, потому как это талант, и если вы не видели понастоящему талантлевых програмистов, то вам очень не повезло... Если бы это был не талант, то небыло бы такого кадрового дифицита, причем что характерно — во всём мире...
А какое отношение талантливый программист имеет к искусству по роду своей деятельности?
Код подобный полотнам Дали ещё видеть не приходилось
AWW>И тут уж как ни крути но если от бога нет, то и не научишь...
Согласен, программирование требует не только хороших знаний, но и ещё "чего-то"...
Но не боги горшки обжигают
Возможно мы с вами немного по разному это самое программирование понимаем.
Но как бы то ни было, ... не верую, что искусство
Сгибатель wrote: > > K>Есть и другие случаи. Интересны проблемы чрезмерно обьемных проектов, > K>когда их описание просто необходимо упрощать за счет введения новых > K>терминов и понятий, иначе трудно оценить общую картину и избежать > K>многократного изобретения велосипедов. Задача придумать хорошую > K>шаблонную конструкцию уже находится на грани исскуства. > > Для вас это на грани искусства, для меня же это проявление выской степени > профессионализма и хорошей интуиции.
Я осторожен в подобных фразах и оборот "на грани" вписал не зря.
Причем, что любопытно, вы упомянули интуицию, а разговоры об интуиции
начинаются примерно там же. Это можно описать также как проявление
профессионализма, одной ногой уже вплотную приближенного к исскуству.
Игра слов, конечно, но главное — об отрыве от правил промышленного
программирования речи не шло, речь скорее о работе на грани сферы
их применимости.
> Наличие нескольких библиотек, с одинаковой функциональностью, в рамках > одного прокета это грубая ошибка. На мой взгляд не стоит утрировать, > мол такое произошло из-за ислючения "Искусства". Думаю причины совсем
другие...
Просто исторически сложилось. Старые библиотеки писались под
нужды старых фич и не были достаточно гибкими, чтобы использовать
в новых, а переводить старые фичи на новые библиотеки
нецелесообразно. Новой функциональности это не даст, код
уже отлажен, а тестирование затратно (очень ограниченный
доступ к целевому железу). В итоге нет никакого способа
веско обосновать необходимость изменений. Да и необходимости
строго говоря нет, затруднения в работе с текущим кодом
ниже геморроя по его переделке.
> Резюмирую, скажу следующее. С вашим взглядом на этот вопрос согласен > только отчасти (что и в программировании есть место для творческого > подхода), но никак не готов назвать это искусством.
То, с чем вы согласились отчасти, и есть моя точка зрения. Место
есть. Как и всему, в меру.
Здравствуйте, kittown, Вы писали:
>> Резюмирую, скажу следующее. С вашим взглядом на этот вопрос согласен >> только отчасти (что и в программировании есть место для творческого >> подхода), но никак не готов назвать это искусством.
K>То, с чем вы согласились отчасти, и есть моя точка зрения. Место K>есть. Как и всему, в меру.
Здравствуйте, last_hardcoder, Вы писали:
_>И проблема, скорее, как раз в отсутствии в нашем национальном характере склонности к менеджменту, а не в избытке творческого потенциала.
Данная проблема успешно решается заменой русского менеджмента на западный.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Есть такая неплохая книжка, "Herding Cats" Ханка Райнвотера, почему-то в русском переводе ставшего то-ли Джоржем то-ли Джоном, Herding Cats: A Primer for Programmers Who Lead Programmers
AWW>На мой взгляд очень толково расказывается почему нельзя управлять программистами так же как водопроводчиками или инжинерами-электронщиками... Если вы хотите получить от них хоть какой-то полезный результат...
Коли советуете, отчего же пренебрегать? Постараюсь прочесть в свободное время.
AWW>[q] С>>>>Искусство — специфический вид отражения и формирования действительности человеком в процессе художественного творчества в С>>>> соответствии с определенными эстетическими идеалами.
AWW>Я то как раз и невижу там ничего художественного, но от этого это не станивится не искуством... Специально оставил цитаты, ещё раз пробегителсь глазами...
По части дефениций различных терминов, склонен обращаться и доверять словарям, с их общепринятыми формулировками,
и в меньшей степени к своему пониманию этих понятий.
(Был опыт горький, который сын ошибок ... ну да это лирика )
С>>А какое отношение талантливый программист имеет к искусству по роду своей деятельности? С>>Код подобный полотнам Дали ещё видеть не приходилось
AWW>Да потому, что искуство это не художество.... Точнее не только художественное творчество...
Тогда ваша трактовка искусства не совпадает с моей
(хотя оную вы чётко не озвучили)
AWW>Скажите вы сами програмировали, или только руководили?
А как же! Да и сейчас этим занимаюсь
А вот из каких моих слов вы сделали вывод, что я рукодил/руковожу... честно говоря, не понимаю
ну да не важно это
По всей видимости, мы с вами немного расходимся в трактовке исходных терминов.
Тут или филигранные формулировки или пиво пить, конец рабочего дня однако.
Здравствуйте, Melo, Вы писали:
M>Очень часто звучащий аргумент о том, что дескать у индусов "родной английский" — это очень сомнительный аргумент. Родной язык у них все же другой. Среднестатистическому индусу английский язык нужен не чаще чем среднестатистическому жителю России. И многие индусы (в том числе и программисты) по английски вообще не говорят, или говорят так, что их никто не понимает, в том числе и те, для кого английский — родной.
Откуда дровишки?
У меня другие сведения на этот счёт, из первых рук так сказать В нормальную школу (в ту из которой потом можно стать программистом) без элементарных знаний английского не принимают (речь идёт о первом классе). Обучение едёт на английском языке все 10 или сколько их там у них лет. По результатам учёбы лучшим даётся возможность учиться дальше, в том числе и на программиста.
Акцент у них конечно своеобразный, иногда трудно понимабельный, но даже у вновь прибывших в штаты речь всегда беглая и в целом грамотная. Проблем с пониманием тоже нет. А вот проблемы с английским у русских и китайцев — это обычное дело. Правда, надо отметить, что так же я знаю нескольких русских, которые говорят по английски практически без акцента, но я не знаю ни одного такого индуса
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
И это только "поверхностный осмотр"...
Тем не менее, библиотека распространяется и вроде как работает.
Вот только лично у меня закрадываются сомнения — стоит ли ее использовать.
Они берут массовостью и дешевизной.
Где в России на конкретную задачу кидают 1 программиста и он её делает качественно но за 1500, в индии на это кинут десяток по 100ке =)
А вообще помню к нам на стажеровку приезжали программисты из великобритании — по моему из всех 3х что были, самым толковым был индус... ему только основы COM рассказал, немного показал как пользоваться CComPtr и CComQIPtr и можно было рассказывать дальше уже про нашу объектную модель =)
Здравствуйте, bastrakov, Вы писали:
B>1) кто дал право заказчику ставить нам задачу? извините за банальность, деньги, которые он пратит за выполнение заказа!
О заказчиках я ни слова не говорил.
B>2) авторитет. вы работаете на людей, которых никогда в жизни не видели. авторитет вашего директора — дефолтный? или он должен предварительно морду бить всем ньюкамерам?
Причем тут директор?
Но аналитик (а может, у вас это "менеджер" называется, или технический руководитель), ставящий некую задачу программисту, и при этом сам не имеющий завершенных проектов в данной области, — имхо нонсенс.
B>3) а кто отчитывается за заказ, потраченые деньги, отработаные часы?
Речь шла чисто о технических вещах. Тот, кто отчитывается за заказ-деньги-часы, может понятия не иметь о технических программистских вопросах.
B>ну вот просто интересно — чисто поржать.
Поржите над собой, если не можете прочитать всю ветвь дискуссии, а отвечаете на вырванное сообщение, и невпопад.
B>ни к чему не призываю, но обьявлять новому манагеру, что он "не имеет авторитера в группе" — показать свой глубокий непрофессионализм. B>профессионалу совершенно фиолетово: где, что, как и когда делать, если за это платят. если его что-то не устраивает, он решает свои проблемы по минимуму загружая других людей.
Если профессионалу идиот-аналитик (идиот-руководитель) (нифига не разбирающийся ни в предметной области, и не имеющий никакого опыта в программировании таких вещей) дает идиотское ТЗ, то уже не фиолетово.
А вы совсем не туда. Я отвечал на посты, где именно руководитель-программист и подчиненный-программист. Никаких заказчиков и прочих вышестоящих. "Менеджером" я назвал лишь условно.
Если интересно, перечитайте.
Обсуждались две противоположные ситуации:
1) начальник (программист) дает задание начинающему программисту, последний его не хочет слушать, делает по-своему. Результат плохой. Начальник-программист пишет на форуме, что с начинающими трудно договориться, они никого не хотят слушать, а чуть что — обижаются и увольняются.
2) (другой случай)Программист говорит, что бывают такие начальники (технические — чтоб вы поняли), которые сами толком не разбираются, и проще уволиться, чем пытаться им что-либо объяснить.
Здравствуйте, Тануки, Вы писали:
Т>Они берут массовостью и дешевизной. Т>Где в России на конкретную задачу кидают 1 программиста и он её делает качественно но за 1500, в индии на это кинут десяток по 100ке =)
Т>А вообще помню к нам на стажеровку приезжали программисты из великобритании — по моему из всех 3х что были, самым толковым был индус... ему только основы COM рассказал, немного показал как пользоваться CComPtr и CComQIPtr и можно было рассказывать дальше уже про нашу объектную модель =)
B>ни к чему не призываю, но обьявлять новому манагеру, что он "не имеет авторитера в группе" — показать свой глубокий непрофессионализм.
Чтобы вы лучше поняли, о каких руководителях (менеджерах, аналитиках) я говорил — простой пример.
Непосредственный руководитель ставит задание начинающему программисту — заставить win ce приложение работать в true VGA режиме на VGA экранах.
Программист-исполнитель пытается сказать о hi-res-aware ресурсе или о работе утилит типа ozVGA. На что непосредственный руководитель говорит: "Да что ты понимаешь, начинающий! Тебе дается элементарное задание, поменять поле Width у формы".
Так вот, такой "непосредственный руководитель" не будет иметь никакого авторитета в группе. И правильно.
А учет заказов-часов-сроков — это уж отдельная песня (и совсем других людей).
Здравствуйте, Melo, Вы писали:
M>А как это противоречит моему утверждению? В статье говорилось, что для индусов английский язык — родной, что является несомненной ложью. Английский язык для индусов — иностранный язык, так же как и для жителей России.
Но их, в отличии от жителей России, десять лет в школе учат на английском. Причём учат не только понимать, но и говорить, а не как у нас "техническому английскому".
M>В повседневной жизни он не используется, масса людей его не понимают и на нем не говорят.
В повседневной жизни два индуса будут говорить на английском. Хотя бы даже из-за того, что на родине они говорят на разном хинди. Два русских, если по близости нет американцев, мгновенно переключаются на русский.
M>Поэтому говорить о некоем изначальном преимуществе индусов на этом направлении — нельзя.
Преимущество есть и довольно серьёзное. Нас практически не учат английскому, у них это второй (или какой там по счёту) официальный язык.
M>А насчет русских — так наши партнеры из Европы/США, например, постоянно твердят насколько легче им общаться с нами, нежели с индусами. Все-таки, менталитет, что ни говори, у нас не столь различается, да и акцент получше .
Понятное дело. Но это только в случае, если у русского приличный английский. А если его нет совсем или он в зачаточном состоянии?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>Но их, в отличии от жителей России, десять лет в школе учат на английском. Причём учат не только понимать, но и говорить, а не как у нас "техническому английскому".
Изначально я всего лишь сказал, что утверждение о "родном английском" — неверно. Родной — это когда на этом языке говорят все и с младенческого возраста. В Индии это не так, а значит автор статьи неправ. Что касается сравнения уровня обучения английскому в школах (не всех индусов (и даже не большинство) 10 лет учат в школе исключительно на английском), то я не готов говорить об этом, поскольку не владею информацией. Однако, я знаю точно, что огромное количество индусов (в том числе и знакомых мне программистов) владеют английским весьма слабо, как устным, так и письменным. Короче говоря, поголовной "англоязычности" среди населения Индии нет.
IT>В повседневной жизни два индуса будут говорить на английском. Хотя бы даже из-за того, что на родине они говорят на разном хинди.
В повседневной жизни они будут говорить на хинди. Разные хинди (точнее, разные диалекты) — это в географически удаленных друг от друга областях. В повседневной жизни, человек в основном общается со своими "земляками" и диалект один и тот же. То есть если уж совсем никак — да, английский может стать связующим звеном, но как часто такое требуется? На статистику не влияет...
IT>Преимущество есть и довольно серьёзное. Нас практически не учат английскому, у них это второй (или какой там по счёту) официальный язык.
Вы попробуйте выйти на улицу в Мумбае и обьясниться на "официальном" языке. 70% людей не поймут ни слова.
IT>Понятное дело. Но это только в случае, если у русского приличный английский. А если его нет совсем или он в зачаточном состоянии?
Еще раз — в Индии тоже дофига таких, у которых "его нет совсем или он в зачаточном состоянии"
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...
Aviant wrote: > >> > Речь шла о том, чем опасны программисты, работающие "потому что > интересно". > V>Только опасность эта существует в очень узком кругу контор, где через > V>пару лет остаются одни выпускники вузов и дикая текучка, впрочем, > V>конечно — это гипербола. > IMO как раз наоборот, в маленьких фирмочках, где работают энтузиасты. > Энтузиазм пропадает — проект гаснет. Таких фирмочек очень много, > постоянно появляются и исчезают. > Характерная черта: на собеседовании в них говорят "да, у нас работают 6 > человек, но они все — лучшие из лучших !"
Вы меня не поняли, это не связано с размером фирмы.
Просто программист, работающий больше "потому что интересно", при
поставленном процессе разработки вполне себе вписываем в процесс, причем
в то место, где от него может быть наибольшая польза и в первую очередь
задача руководителя найти это место. Конечно, бывают ситуации-проекты,
где люди с определенным жизненным подходом работать не могут, но в
данном варианте лучшее для всех разойтись в разные стороны.
И кроме того "потому что интересно" — это очень сильная мотивация и
может перекрывать разницу оплаты в несколько сотен долларов.
> О. Тут по ветви обсуждается что есть программирование и чего там больше > искусства или рутины. > "Творцы" как раз руководствуются в первую очередь эмоциями, а разумом > потом, иногда, может быть. > Считаю, что такой подход применим при написании картин, ваянии > скульптур, сочинении музыкальных произведений или игре в театре. Если у > человека эмоции на первом месте — в IT ему делать нечего. > Тут 2 + 2 равно 4, несмотря на то что это "неизящно и некрасиво".
Почему, вполне себе "красиво и изящно".
Не всегда, бывает по разному, причем я большей частью сталкивался с
ситуациями, что если красиво и изящно (спроектирован продукт, написан),
то обычно он и работает хорошо. Конечно, это не говорит от том, что
некрасиво работать не будет, а красиво работает всегда. Причем понятие
красоты сугубо индивидуально.
Думаю, в программировании, как и в любом производстве есть элементы
искусства, но есть и куча рутинной работы.
Здравствуйте, Joker6413, Вы писали:
J>Здравствуйте, Аноним, Вы писали:
А>>здесь
J>тот кто писал — профан...
Статья указывает очень известную в ряду наших аутсорсеров проблему. Решение её известно: надо писать и продавать свои высокотехнологичные продукты (Касперы, Abby, Орфо, Промт и пр.). А всю рутину оставить индусам.
J>Россия — порядка 40 000 программистов
Откуда данные?
J>Индия — порядка 800 000 программистов
J>Чисто конкретно. Разводка не катит. У индусов последнии 10 лет работала программа обучения программеров, в которую вбухали 20 млрд $. А у нас институты закрывали.
Какие именно институты? В России сейчас вдвое больше студентов, чем в 1989 г. Кроме того, почитай этот подфорум — проблема налицо.
Здравствуйте, ggg, Вы писали:
ggg>Что человек не просто занимает руководяющую должность (потому что у него друзья еще большие начальники), а что он до этого (с)делал то-то и то-то, и это (с разной степенью подробности) известно подчиненным.
1) вы можете мне не верить, но начальниками становяться именно по не техническим скилзам.
2) очень часто "проваливающийся проект" (хроника пикирующего...) берет на себя самый "тихий" член команды. надо кому-то отвечать за это безобразие. у него точно минимальный авторитер в команде.
ggg>Если из постановки "должно работать так и так" всем понятны примерные сроки, то ОК. Как бы в крайность не удариться (тут был не раз тред о работе в Ultra computers, где для торговой системы, отслеживающей склад и заказы, писали свой интерпретатор своего языка, причем за неделю — как утверждал работодатель. И что же, если один человек не напишет за неделю интерпретатор какого-то макроязыка для отчетов по складским операциям — его сразу в лохи? А начальство, поставившее такую задачу, премию получит?)
я сторонник противоположной точки зрения. за все пролеты отвечает манагер. я обьясняю это с начала своего включения в тему.
я обрашаю внимание именно на это отличие между русскими и индийскими разработчиками.
вопрос в том, как управлять "низкоуправляемыми" русскими? (далеко не все. не больше 5%.)
ggg>Коробочные продукты. Иногда явного заказчика нет.
это плохой коробочный продукт, если постановщик задачи понятия не имеет, кто и как пользует его продукт.
ggg>Не, я не пример защищаю (я там к "1-2 года опыта" прицепился, так как подобная позиция с опытом только усилится). Если амбициозный человек с годом опыта никого не стал слушать, то думаю, с 3-5 годами опыта он и подавно не послушает.
правильно ли я понимаю, что вы против _продвижения_ такого специалиста?
ggg>И все-таки, возможность договариваться — она не от одного человека зависит. Значит, не нашлось людей, которые убедить смогли (что странно, убедить начинающего несложно).
гм... ну попробуйте. свято верю, что вам таки попадеться "гений" в команду, который в первый день работы обьявит проет ужасным и через неделю предложит переписать все по другому.
ggg>Хмм. В нынешних условиях в России это, наверное, не очень сработает. Иногда начальниками не пойми за что становятся ;(
начальниками не становяться. их назначают обычно.
для того, что бы понять почему, надо находиться рядом с принимающим решение. а это — уровнем выше.
ggg>Да! Вот против подобного я и выступаю!
не в ваших силах это изменить. любые трения в команде завалят проект еще быстрее и с большим "треском".
правильная команда способна поднять провальный проект. плохая — провалить успешный.
в большей степени это определяется лидером.
ggg>Хе-хе, как бы не вышло так, что начальство "отмажется", а разработчикам зарплату снизят.
я даже в россии такое ни разу не видел. начальник на уши встает, если его подставить могут.
поэтому если могут и хотят — сразу надо выводить из проекта.
ggg>А так ли обидно, что проигрываем? Индусы — это в массе своей рынок прикладного заказного ПО (где техническая реализация заранее известна большей частью, и где исполнителю нужно лишь выполнять предписанные требования). Коробочного софта они практически не выпускают. Да и софт от своего имени индусы вроде бы не делают.
обидно — так.
они делают любые проекты.
а вы не знали? для примера: oracle разрабатывается в индии.
Слава Шевцов wrote: > > КД>Мой вывод — надо размножать русских > > КД>... возражающие есть? > > Да, есть. Надо тотально переучить наших программистов. Точнее урезать ту > часть их функционала, которая излишне новаторская и творческая.
Эта проблема, она же одновременно и стратегическое преимущество.
Предпочитаете избавляться от спермотоксикоза путем кастрации ?
Здравствуйте, kittown, Вы писали:
>> КД>Мой вывод — надо размножать русских >> >> КД>... возражающие есть? >> >> Да, есть. Надо тотально переучить наших программистов. Точнее урезать ту >> часть их функционала, которая излишне новаторская и творческая.
K>Эта проблема, она же одновременно и стратегическое преимущество. K>Предпочитаете избавляться от спермотоксикоза путем кастрации ?
Слава Шевцов wrote: > >> > Да, есть. Надо тотально переучить наших программистов. Точнее урезать ту >> > часть их функционала, которая излишне новаторская и творческая. > > K>Эта проблема, она же одновременно и стратегическое преимущество. > K>Предпочитаете избавляться от спермотоксикоза путем кастрации ? > > Термин "излишне" программист как всегда опустил.
Безусловно. Эта характеристика соответствия программиста конкретным
задачам и вне контекста данных задач смысла не имеет.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>>Мой вывод — надо размножать русских
КД>>>... возражающие есть?
СШ>>Да, есть. Надо тотально переучить наших программистов. Точнее урезать ту часть их функционала, которая излишне новаторская и творческая.
КД>Суицидом предлагаешь мне занятся?
Зачем нужен программист, который не понимает, что другой человек знает что-то лучше? Типичный пример. Просишь человека доработать модуль. Выкатываешь детальное ТЗ. В ТЗ прописано даже требование соблюсти стиль оформления кода.
В итоге получаешь переформативанный код (ему кажется, что такое форматирование на порядок лучше), какие-то навороты по функциональности, какие-то дополнительные функции (а я просил?). В итоге, дополнительные функции в помойку из-за того, что работать стало значительно менее удобно. Например, было подтверждение отправки письма простым нажатием на ссылку, стало нажатием на ссылку и введением логина с паролем (они сложные, я их не помню . Код форматируешь обратно сам — легче самому отформатировать, чем объяснить человеку, что мне нужен прежний формат. Ведь программист самый умный. Ведь он знает, что его форматирование значительно экономит время на чтении (его время), что это форматирование значительно снижает количество ошибок, что оно модное. Подумаешь, в коде все переменные были в венгерке (lpszString), а он использовал стиль Кэмел (StringPtr). Подумаешь, это лишь один модуль, а есть ещё и другие модули, которые написаны в прежних нотации и стиле.
Я понимаю, человек казалось бы, везде был прав в рамках модуля. Так было бы лучше. Но он забыл о программе. Он забыл о других людях. Он забыл, что священные войны — это для спецфорума RSDN, а не для переписки с работодателем. Он посчитал, что он умнее чем тот, кто составлял ТЗ и сделал так, как он считал нужным. Даже не спросив.
И таких людей в программировании много. Они называют это креатив, творческий подход. Они говорят, что программирование — это искусство. Они считают, что могут учить работодателя как заказывать работу, что делать и как делать. Читайте RSDN.job. Только если они такие умные, то я не понимаю, почему они не пошли путём, указанным ниже:
Слава Шевцов wrote: > > Зачем нужен программист, который не понимает, что другой человек знает > что-то лучше?
Звезды — чтобы делать то, что знают все же лучше сами. Остальное
нижеописанное характерно для джуниоров.
> И таких людей в программировании много. Они называют это креатив, > творческий подход. Они говорят, что программирование — это искусство.
Здравствуйте, kittown, Вы писали:
K>Безусловно. Эта характеристика соответствия программиста конкретным K>задачам и вне контекста данных задач смысла не имеет.
О, да. Если бы. Цитата из начинающих шароварщиков (начинающий шароварщик это программист, который возомнил себя предпринимателем и решил деньги заработать своим трудом):
> Софтом соблюдаются лицензии Гугля и Яндекса на сканирование роботами?
Вопрос не простой. На наш взгляд, да. На взгляд юристов Яндекса -- не знаем.
Вот так вот. У человека есть свой взгляд на пользование поисковиком, ему текст лицензии не указ.
. Кто его создал? Смотрим профайл: "Пректирование и разработка систем безопасности, Сетевые драйвера под NT". Но учит-то он менеджеров проектов. Он учит людей, хотя он сам не менеджер проектов, а находится на более низком уровне абстракции.
Я вот тут сижу и занимаюсь радикальным улучшением мира. А меня кто просил? Опять типичный пример программиста. Ну сиди ты, Слава, и занимайся своим сервисом. Достал уже примерами. Слушаюсь, удаляюсь.
Здравствуйте, kittown, Вы писали:
>> Зачем нужен программист, который не понимает, что другой человек знает >> что-то лучше?
K>Звезды — чтобы делать то, что знают все же лучше сами. Остальное K>нижеописанное характерно для джуниоров.
А ты пытался когда-нибудь настроить суперпрограммиста делать так, как удобно всей команде, а не ему одному?
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW> Слава! Раз уж тут меня каким-то образом склоняют, придётся немного представится... Я даже не менеджер проекта , а "немного" повыше
Тогда беру все свои слова в Ваш адрес назад.
AWW>Налицо явная обида, только на кого надо обижаться?
Нет, не обида. Пример. Это была ожидаемая реакция работника. За слова — спасибо.
AWW>У нас ведь как известно, каждый знает как правильно управлять государством, и учится этому совсем не требуется... Ну а уж отделом или командой так вообще как два пальца... Ну вот и вы кстати тому яркий пример...
Слава Шевцов wrote:
> А ты пытался когда-нибудь настроить суперпрограммиста делать так, как > удобно всей команде, а не ему одному?
Зачем суперпрограммисту команда ? Супера анекдотично неуживчивы, вне
зависимости от места рождения и страны проживания. Их мало, и терпят
их не за красивые глаза, и уж точно не за коммуникабельность. И
проблем соответственно огребают. Просто результат того стоит. Иногда.
Вы же, наверно, имели в виду обычных запущенных junior-ов. Им нужен
всего лишь нормальный менеджмент и стажировка в правильном месте,
где таких много.
Здравствуйте, savaDAN, Вы писали:
DAN>Давайте попробуем найти компромисс. ИМХО, в любом деле присутсвует две составляющие: рутинный, хорошо формализуемый труд, и неформализуемая часть [...] DAN>К исскуству, на мой взгляд, это отношения по прежнему никакого не имеет, т.к. на мой взгляд искусство это то, что призвано приносить эстетическое наслаждение.
Ага. А работа должна приносить ощущение непрерывной кровищщи и ########. А хрена ж ишшо?
DAN>То что имеет какую-то другую цель (полезность) искусством являться не может.
Может. Потому что искусством в данном случае является процесс, а не результат.
DAN>Несомненно, в хорошо сделанном проекте присутствует элемент эстетического удовольствия, но этот компонент побочный, если продукт не будет выполнять своей цели — он никому не нужен, если он будет решать задачу, но не приносить эстетического удовольствия — это по прежнему продукт.
Конечно, это по-прежнему продукт. От которого у всех появляется головная боль и желание расколошматить компьютер. Плавали, знаем. Сыты по самые уши.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DAN>>К исскуству, на мой взгляд, это отношения по прежнему никакого не имеет, т.к. на мой взгляд искусство это то, что призвано приносить эстетическое наслаждение. ГВ>Ага. А работа должна приносить ощущение непрерывной кровищщи и ########. А хрена ж ишшо?
Прокомментируйте, пожалуйста, вашу мысль.
Не совсем понял что вы хотели этим сказать.
DAN>>То что имеет какую-то другую цель (полезность) искусством являться не может. ГВ>Может. Потому что искусством в данном случае является процесс, а не результат.
Хм, тогда почему индустрия старается элемент "искусства" из этого процесса всячески удалить? См. RUP, CMM, ISO, etc...
Правильность применения методики на мой взгляд является просто здравым смыслом, а не искусством.
Опять же, искусство и "отвечает требованиям", на мой взгляд, вещи если не полностью противоречащие то уж точно мещающие друг-другу.
DAN>>Несомненно, в хорошо сделанном проекте присутствует элемент эстетического удовольствия, но этот компонент побочный, если продукт не будет выполнять своей цели — он никому не нужен, если он будет решать задачу, но не приносить эстетического удовольствия — это по прежнему продукт. ГВ>Конечно, это по-прежнему продукт. От которого у всех появляется головная боль и желание расколошматить компьютер. Плавали, знаем. Сыты по самые уши.
На мой взгляд "Головоболящие" программы появятся скорее в результате творчества некоего художника (потому что он так увидел) нежели у приложения, выполненного в соответствии со стандартами по usability, грамотно оттестированному и т.п.
savaDAN wrote: > > Хм, тогда почему индустрия старается элемент "искусства" из этого > процесса всячески удалить? См. RUP, CMM, ISO, etc...
Применение указанных методологий тоже в своем роде исскуство.
> Правильность применения методики на мой взгляд является просто здравым > смыслом, а не искусством.
Здравый смысл ходит рука об руку с исскуством.
> Опять же, искусство и "отвечает требованиям", на мой взгляд, вещи если > не полностью противоречащие то уж точно мещающие друг-другу.
Да никак они друг другу не противоречат.
> На мой взгляд "Головоболящие" программы появятся скорее в результате > творчества некоего художника (потому что он так увидел) нежели у > приложения, выполненного в соответствии со стандартами по usability, > грамотно оттестированному и т.п.
Качественное приложение guideline-ов по usability (четких стандартов
в этой области нет) тоже носит в себе элементы исскуства.
Исскуство — это не только сободный полет с непредсказуемым результатом.
Художник ограничен холстом, скульптор — своими инструментами и
доступными материалами, а у программиста есть инструменты, требования
и стандарты. Воображаемый вами програмист-"творец", делающий
фигню, это просто скульптор, пытающийся работать по неподходящему
материалу неподходящим инструментом, с соответствующим результатом.
... >> приложения, выполненного в соответствии со стандартами по usability, >> грамотно оттестированному и т.п.
K>Качественное приложение guideline-ов по usability (четких стандартов K>в этой области нет) тоже носит в себе элементы исскуства.
вы можете мне не верить, но я изучал то, что сейчас называют usability, 20 лет назад в _техникуме_ .
этому обучают разработчиков рэа и в вузах.
данное "искусство" давно измеряно, посчитано, опробовано и описано в учебниках.
> Здравствуйте, Andrew.W Worobow, Вы писали: > > > AWW>Так что в варианте с индусами надо говорить, что они не програмисты, > а кодировщики... Типа переводчиков или машинисток... > > Может, немного не "в тему", но все же... > Скачал недавно библиотеку > <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/cab.asp> > от Microsoft, решил полазить в коде, в первом же попавшемся файле: > > if (DesignMode == false)... > ... > if (list.Contains(key) == false) ...
, а "немного" повыше 
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
