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>менталитет? на нем иднусам и проигрываем. обидно!
А так ли обидно, что проигрываем? Индусы — это в массе своей рынок прикладного заказного ПО (где техническая реализация заранее известна большей частью, и где исполнителю нужно лишь выполнять предписанные требования). Коробочного софта они практически не выпускают. Да и софт от своего имени индусы вроде бы не делают.
Здравствуйте, 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>нижеописанное характерно для джуниоров.
А ты пытался когда-нибудь настроить суперпрограммиста делать так, как удобно всей команде, а не ему одному?
. Кто его создал? Смотрим профайл: "Пректирование и разработка систем безопасности, Сетевые драйвера под NT". Но учит-то он менеджеров проектов. Он учит людей, хотя он сам не менеджер проектов, а находится на более низком уровне абстракции.
Слава! Раз уж тут меня каким-то образом склоняют, придётся немного представится... Я даже не менеджер проекта , а "немного" повыше ... И даже уж давно как... И учу я их.... хотя.... совсем не учу, а лишь рассказываю, что есть такая наука как управление людьми и есть такая наука как маркетинг... и есть такая наука как менеджмент и психология.... Да и вам бы как начинающему шароварщику... (забавный бизнес) неплохо было бы подучится для того чтобы понимать, ну в объщем то конечно не очень простую штуку как торговля, со своими терминами и понятиями.... но не настолько уж...
Ну да ладно... Посмотрим, что вы тут написали в соседних ветках....
СШ> Зачем нужен программист, который не понимает, что другой человек знает что-то лучше? Типичный пример. Просишь человека доработать модуль. Выкатываешь детальное ТЗ. В ТЗ прописано даже требование соблюсти стиль оформления кода.
Налицо явная обида, только на кого надо обижаться? В этой ситуации Слава надо обижаться только на себя. А иначе мы начнём напомитать королей которые недовольны своим народом. Запомните Слава, всё неудачи подчиненных это неудачи только их руководства, начиная с той, что именно на эту позичию назначили человка котрый ни морально но психологически не соответсвует ей. Небывает плохих солдат бываю только плохие генералы. Я это понял ещё в далёком 1990 году, когда руководил лабораторией системного программирования в НИИ ПС, и у меня в подчинении было 10 человек. Люди всё разные, к каждому, Слава, нужен индивидуальный подход.
СШ>Статья указывает очень известную в ряду наших аутсорсеров проблему. Решение её известно: надо писать и продавать свои высокотехнологичные продукты (Касперы, Abby, Орфо, Промт и пр.). А всю рутину оставить индусам.
Статья утверждает, что индийские программисты лучше Российских. И само возникновение этой статьи это проблема, и проблема не только наша и совсем не программистов. И в каждой издушке свои погремушки, в штатах это проблема стимости рабочей силы, у них есть даже такое выражение — "мою работу сбангалорили" и что американские программисты по вашему тоже плохие, раз индусам работу их отдают... У нас,(и это уже очень острая проблема!) это качество и количестов качественных менеджеров. У нас ведь как известно, каждый знает как правильно управлять государством, и учится этому совсем не требуется... Ну а уж отделом или командой так вообще как два пальца... Ну вот и вы кстати тому яркий пример...
Одним словом, Слава рекомендую вам поинтересоваться трейдингом, психологией, маркетингом и менедженментом... И ваших проблем не будет как класс, то что вы назаваете проблемой, это просто ежедневный рутинный труд управленцев... С людми конечно труднее чем с программами, они живые.
А мотивом написать всё это, стало то, что мои менеджеры точно также, совершенно не справляются со своими задачами, и где найти других совершенно не вижу... Нехотят люди учится, а плохо это на самом деле....
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW> Слава! Раз уж тут меня каким-то образом склоняют, придётся немного представится... Я даже не менеджер проекта , а "немного" повыше
Тогда беру все свои слова в Ваш адрес назад.
AWW>Налицо явная обида, только на кого надо обижаться?
Нет, не обида. Пример. Это была ожидаемая реакция работника. За слова — спасибо.
AWW>У нас ведь как известно, каждый знает как правильно управлять государством, и учится этому совсем не требуется... Ну а уж отделом или командой так вообще как два пальца... Ну вот и вы кстати тому яркий пример...
Слава Шевцов wrote:
> А ты пытался когда-нибудь настроить суперпрограммиста делать так, как > удобно всей команде, а не ему одному?
Зачем суперпрограммисту команда ? Супера анекдотично неуживчивы, вне
зависимости от места рождения и страны проживания. Их мало, и терпят
их не за красивые глаза, и уж точно не за коммуникабельность. И
проблем соответственно огребают. Просто результат того стоит. Иногда.
Вы же, наверно, имели в виду обычных запущенных junior-ов. Им нужен
всего лишь нормальный менеджмент и стажировка в правильном месте,
где таких много.
Здравствуйте, savaDAN, Вы писали:
DAN>Давайте попробуем найти компромисс. ИМХО, в любом деле присутсвует две составляющие: рутинный, хорошо формализуемый труд, и неформализуемая часть [...] DAN>К исскуству, на мой взгляд, это отношения по прежнему никакого не имеет, т.к. на мой взгляд искусство это то, что призвано приносить эстетическое наслаждение.
Ага. А работа должна приносить ощущение непрерывной кровищщи и ########. А хрена ж ишшо?
DAN>То что имеет какую-то другую цель (полезность) искусством являться не может.
Может. Потому что искусством в данном случае является процесс, а не результат.
DAN>Несомненно, в хорошо сделанном проекте присутствует элемент эстетического удовольствия, но этот компонент побочный, если продукт не будет выполнять своей цели — он никому не нужен, если он будет решать задачу, но не приносить эстетического удовольствия — это по прежнему продукт.
Конечно, это по-прежнему продукт. От которого у всех появляется головная боль и желание расколошматить компьютер. Плавали, знаем. Сыты по самые уши.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DAN>>К исскуству, на мой взгляд, это отношения по прежнему никакого не имеет, т.к. на мой взгляд искусство это то, что призвано приносить эстетическое наслаждение. ГВ>Ага. А работа должна приносить ощущение непрерывной кровищщи и ########. А хрена ж ишшо?
Прокомментируйте, пожалуйста, вашу мысль.
Не совсем понял что вы хотели этим сказать.
DAN>>То что имеет какую-то другую цель (полезность) искусством являться не может. ГВ>Может. Потому что искусством в данном случае является процесс, а не результат.
Хм, тогда почему индустрия старается элемент "искусства" из этого процесса всячески удалить? См. RUP, CMM, ISO, etc...
Правильность применения методики на мой взгляд является просто здравым смыслом, а не искусством.
Опять же, искусство и "отвечает требованиям", на мой взгляд, вещи если не полностью противоречащие то уж точно мещающие друг-другу.
DAN>>Несомненно, в хорошо сделанном проекте присутствует элемент эстетического удовольствия, но этот компонент побочный, если продукт не будет выполнять своей цели — он никому не нужен, если он будет решать задачу, но не приносить эстетического удовольствия — это по прежнему продукт. ГВ>Конечно, это по-прежнему продукт. От которого у всех появляется головная боль и желание расколошматить компьютер. Плавали, знаем. Сыты по самые уши.
На мой взгляд "Головоболящие" программы появятся скорее в результате творчества некоего художника (потому что он так увидел) нежели у приложения, выполненного в соответствии со стандартами по usability, грамотно оттестированному и т.п.
, а "немного" повыше 
