K> Если есть ТЗ — то это уже не программист, а кодер. А у программиста — постановка задачи на уровне "эх, вот сделать бы нам что-то такое эдакое, чтоб плясало и пело и всем нравилось".

это совершенная неправда если работает несколько человек с пересекающимися задачами будет интересно увидеть систему через несколько месяцев....

FDS>3D-интерфейс — это не сложно?
сложно, наверное, я ниразу не видел... а зачем нужен 3Д интерфейс? если это симулятор, то это немного другое гуи (надо было перед каждым использованием термина писать, что подразумевается широкое применение термина если не сказано другое)

FDS>Интерфес, не позволяющий совершить человеку-оператору ошибки и наблюдающий за состоянием объекта управления и меняющийся вместе с ним: куча взаимосвязанных полей, которые нужно то активировать, то деактивировать, постоянно проверять, корректны ли в них значения, а сама корректность может быть зависима от состояния других полей.
ну это извине совсем не сложная задача, вообще сложность надо оценивать на сравнении — что сложнее построить и посчитать бикубический сплайн или то что вы сказали для среднестатистического программиста?

FDS>Приложения к интерфейсу на подобие: показать, где детали неправильно сопрягаются. Это ведь ещё и не просто вычислить надо, а ещё и показать хорошо. Но даже вычисление можно, в принципе, отнести к UI
какое вычисление можно связать с гуи???

FDS>За то же время? Значит эта фича и есть формочка...
см. строчку про сравнение сложностей.

Здравствуйте, Denis, Вы писали:

FDS>>3D-интерфейс — это не сложно?
D>сложно, наверное, я ниразу не видел... а зачем нужен 3Д интерфейс? если это симулятор, то это немного другое гуи (надо было перед каждым использованием термина писать, что подразумевается широкое применение термина если не сказано другое)

Для разработки деталей, моделирования, для вывода на экран состояния станка или обследуемой технической системы.

FDS>>Интерфес, не позволяющий совершить человеку-оператору ошибки и наблюдающий за состоянием объекта управления и меняющийся вместе с ним: куча взаимосвязанных полей, которые нужно то активировать, то деактивировать, постоянно проверять, корректны ли в них значения, а сама корректность может быть зависима от состояния других полей.
D>ну это извине совсем не сложная задача, вообще сложность надо оценивать на сравнении — что сложнее построить и посчитать бикубический сплайн или то что вы сказали для среднестатистического программиста?

Пожалуй мне было бы сложнее сделать такой интерфейс. Причём значительно сложнее.

FDS>>Приложения к интерфейсу на подобие: показать, где детали неправильно сопрягаются. Это ведь ещё и не просто вычислить надо, а ещё и показать хорошо. Но даже вычисление можно, в принципе, отнести к UI
D>какое вычисление можно связать с гуи???

Я же написал: вычисления неправильно сопряжённых деталей, например.

FDS>>За то же время? Значит эта фича и есть формочка...
D>см. строчку про сравнение сложностей.

Сложностей или трудоёмкостей?

Здравствуйте, FDSC, Вы писали:

FDS>М-да, человек-это звучит гордо уж точно детский бзик

Лучше бы ты сказал что-нибудь умное...

Здравствуйте, S-SH, Вы писали:

SS>Теперь макнем в каждую кастрюльку лакмусовую бумажку:
SS>

SS>
1. Кому нужен конечный финансовый результат? владельцам — очень; директору — нужен; департаменту бизнеса — неплохо бы; департаменту ИТ и ниже — по барабану
   SS>
2. Кому нужно, чтоб бананы совпали с клиентом и поездом? владельцам — по барабану; директору — по барабану; департаменту бизнеса — неплохо бы; департаменту ИТ — если не совпадут, он будет крайним; ниже — по барабану
   SS>
3. Кому нужно, чтобы ИТ потребляло вдвое меньше денег? владельцам — желательно; директору — по барабану; департаменту бизнеса — по барабану; департаменту ИТ и ниже — нафиг-нафиг такое счастье
   SS>
4. Кому нужно, чтобы ИТ выдавало вдвое большую, условно говоря, функциональность? владельцам — по барабану; директору — по барабану; департаменту бизнеса — очень нужно; департаменту ИТ и ниже — по барабану;
   SS>

Проследил за руками. В последнем пункте ошибка. Департаменту IT — возможно, и нужно, для поддержки реноме, а его сотрудникам — нафиг-нафиг такое счастье. Работать-то придется больше за те же деньги в том же составе.

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>а вообще спорить тут тоже сильно не о чем, хотя все же если какой директор ИТ отдела бодро отрапортует наверх что значительно снизил затраты или теми же силами выдал двойной план — явно ему за это может чтото обломиться, в т.ч. иногда и переход на след. уровень.

Или сокращение штатов и вопрос "А чем вы раньше занимались"? Вопрос в том, профильным ли отделом является IT в данной фирме.

Здравствуйте, FDSC, Вы писали:

FDS>А зачем нужны три монитора?

Не ко мне вопрос.

Здравствуйте, Denis, Вы писали:

IT>>1. Мы имеем дело со сложным UI. Это задача не для новичков, это вообще может оказаться самой сложной частью приложения.
D>вообще _навреное_ гуи может быть сложным, но можно пример такого сложного гуи? мы живём в эпоху интеренета и я думаю вы легко можете привети свой пример работы. если по каким-то причинам свой нельзя — то просто пример.

Пример сложного гуи в вебе я не покажу, т.к. веб гуи — это действительно не самое сложное. Но пример дам. Например, софт для трейдеров. Задача уложить на экран кучу постоянно меняющихся в реал-тайм данных. При этом одна и таже ячейка грида может одновременно иметь состояние как важная, невалидная, изменённая, отмеченная, выбранная, найденная и т.п. Данных очень много и их нужно максимально удобно расположить на экране. Обновления данных должны быть сразу видны, но не мешать текущей работе. Отклик интерфейса на действия пользователя должен быть моментальным. При вводе данных интерфейс должен предугадывать действия пользователя и производить максимум правильных подстановок сам. Валидация должна помогать, но не мешать вводу. При длительных фоновых операциях интерфейс не должен блокироваться, т.е. ни о каких стандартных MessageBox речи быть не может. Всё это усугубляется кучей фоновых операций, постоянно обновляющих интерфейс, глюками и неприспособленностью к такому режиму работы используемых компонент и постоянно, буквально ежедневно меняющимися требованиями.

IT>>2. У нас большой набор простых типовых формочек. Как правило, это дело сводится к другой задаче — генерации этих самых формочек или к примитивизму их создания. Задача сама по себе уже не простая.
D>я учавствовал в создании программы, которая генерит формаочки, сейчас это большой продукт переживший три рождения, но по опыту скажу ренераторы я встречал очень редко.

Редко. Если передо мной стоит такая задача, то я стараюсь свести её ко второму варианту, а именно сделать этот процесс примитивным, в идеале, чтобы код формы не содержал кода вообще

IT>>3. У нас простой интерфейс из нескольких простых формочек, которые один раз рисуются и дальше о них забывают. Как правило, гуру сделает это быстрее и просто не успеет заскучать на этой задаче.

D>в принципе да, на всякий случай — GURU influential expert: somebody who has a reputation as an expert leader, teacher, or practitioner in a particular field
D>Microsoft® Encarta® 2006. © 1993-2005 Microsoft Corporation. All rights reserved. (сорри, тока Энкарта под рукой)

Вообще термин гуру в этом топике возник мне кажется по недоразумению. Здесь было бы уместнее использовать более фирокий термин — профессионал.

D>но в области клепания форм те, кого можно назвать "гуру" становятся архитекторами, а не клепают фомочки, нету там challenge в задаче клепания форм. а отсутствие этого самого challenge есть смерть для профессионала.

3-й пункт не об этом. 3-й пункт о том, что если в задаче есть лишь несколько простых форм, то профи вполне может это сделать сам без привлечения недоученного персонала, который утомит своими вопросами и всё равно всё сделает не так.

IT>>Что же касается моего утверждения, что "Гуру, не желающий клепать формочки — это не гуру", то моё ИМХО таково — капризы из серии это я делать желаю, а это не желаю, не совместимы с понятием профессионализм.
D>это уже немного другое, я полностью согласен, что "это я делать не буду" неочень хороший признак, но я считаю что каждый должен быть там, где он принесёт больше пользы. к примеру про микроскоп: за то же время пока профи делал низкоквалифицироаннуй работу он бы мог добавить фичу, которая добавит value в продукт, причём эту фичу уже неквалифицированный (негуру) не сделает...

Это всё зависит от менеджмента. Если менеджер будет заколачивать (использовать) микроскопом (гуру) гвозди (для выполнения низкоквалифицированной работы), то это просто плохой менеджер. Но из того, что бывают плохие менеджеры совершенно не вытекает то, что не должен уметь делать такую работу. Это моё ИМХО и основывается оно на том факте, что буквально все встреченные мной когда-либо такие 'гуру' оказыались вовсе не гуру, а обыкновенными безответственными лентяями и трепачами.

И вообще, выполнение задач профессионалом от IT у меня ассоциируется не с фрезеровщиками 16-разряда, а скорее со старшими офицерами спецназа, которые по-прежнему ходят на задания и выполняют их вместе с молодыми лейтенантами. В такой ситуации сложно себе представить, что кто-то будет торговаться насчёт того, кому клепать формочки.

Здравствуйте, w00zle, Вы писали:

ГВ>>Не понял, какое начальство имеется ввиду?

W>Его непосредственному. Т.н. куратору проекта. То есть человеку, который по мере сил помимо продаж и обеспечения сотрудников работой пытается ещё и отследить её, работы, выполнение.

Куратор в данном случае — это ПМ? А тебе не кажется, что этого куратора в таком случае нужно оставить без сладкого (по минимуму) или прогнать в шею (по максимуму)? Чем он в таком случае занимается? "Продает проект начальству на всем его протяжении"(с)? Конечно, это хорошее и нужное дело, но если начальство этим ограничивается, то проект обычно загибается. Потому что связь с заказчиком оказывается на разработчиках, причем слабо контактирующих между собой, из-за чего требования никто не формализует, а ТЗ становится абстрактным руководством на манер святого писания. В результате к середине проекта все расползается, как снежок по весне. Тогда мудрое начальство разводит руками и говорит: "Ну как можно работать с такими людьми! Где ж мне найцти гурей прогуристее, чтоб и ТЗ за меня написали, и выполнение его за меня отслеживали, и с заказчиком общались, да еще и продавали продукт сами..." И на челе его от осознания несовершенства мира появляются скорбные морщины...

Здравствуйте, Kolhoz, Вы писали:

K> Если есть ТЗ — то это уже не программист, а кодер. А у программиста — постановка задачи на уровне "эх, вот сделать бы нам что-то такое эдакое, чтоб плясало и пело и всем нравилось".

Товарищ Колхоз, Вы удостаиваетесь звания "Первого понимающего". Вы пока единственный, кто смог вкратце мою точку зрения по данному топику в несколько слов выразить. Сам я это боялся сделать, ибо набросятся сейчас тут, кхм, кодеры

Здравствуйте, w00zle,

Так...

W>И описание вакансии.. Хотел раньше попросить, да не хватало смелости. Как бы ты описал вакансию для товарища, который мне нужен?

Ключевые слова: служба качества. Вот ещё интересная ссылка.

Здравствуйте, IT, Вы писали:

IT>Вообще термин гуру в этом топике возник мне кажется по недоразумению. Здесь было бы уместнее использовать более фирокий термин — профессионал.
именно.

2 all:
во избежание неправильного понимания\толкования была мысль не писать в терминах 2К и не использовать, пусть и не мной введенных, "гениев-монстров-гуру и обезьян", а использовать "крепких толковых опытных ребят с коэффициентом 3, объединенных общей целью" — т.е. действительно профессионалов. Однако это показалось затруднительным так как шло сравнение с "профессионалами" коими являются и новички\студенты — ведь они зарабатывают программированием и работают за ту же самую ЗП и тянут в 50 персон нормальные реальные проекты — нельзя же их всех вот так сразу записать в непрофессионалы Да и ассоциции с 2К и "гуру" кому-то наоборот лучше понятны — решил ничего не менять.

тем не менее некоторых действительно стереотипы сбивают — если гуру, то это отчего-то означает что занимается чем-то недоступным никому больше, если 2К так тут же включается сверка с ЗП в своем отделе... уже неск. раз в ветке такое встречал и разъяснял

так вот, Игорь очень хорошо этот момент, мной похоже упущенный или не показанный ясно, уточнил:
IT>И вообще, выполнение задач профессионалом от IT у меня ассоциируется не с фрезеровщиками 16-разряда, а скорее со старшими офицерами спецназа, которые по-прежнему ходят на задания и выполняют их вместе с молодыми лейтенантами. В такой ситуации сложно себе представить, что кто-то будет торговаться насчёт того, кому клепать формочки.
вот это и в моем тексте подразумевалось — про состав эффективной команды. +1
/2all OFF

D>>но в области клепания форм те, кого можно назвать "гуру" становятся архитекторами, а не клепают фомочки, нету там challenge в задаче клепания форм. а отсутствие этого самого challenge есть смерть для профессионала.

IT>3-й пункт не об этом. 3-й пункт о том, что если в задаче есть лишь несколько простых форм, то профи вполне может это сделать сам без привлечения недоученного персонала, который утомит своими вопросами и всё равно всё сделает не так.
+1

Здравствуйте, w00zle, Вы писали:

K>> Если есть ТЗ — то это уже не программист, а кодер. А у программиста — постановка задачи на уровне "эх, вот сделать бы нам что-то такое эдакое, чтоб плясало и пело и всем нравилось".

W>Товарищ Колхоз, Вы удостаиваетесь звания "Первого понимающего".

Товарищу Колхозу это уже не поможет. Его больше нет с нами, он навечно забанен злобным модератором в моём лице.

W>Вы пока единственный, кто смог вкратце мою точку зрения по данному топику в несколько слов выразить. Сам я это боялся сделать, ибо набросятся сейчас тут, кхм, кодеры

Такое качество у людей нужно культивировать, а не ждать, пока оно само появится.

Здравствуйте, S-SH, Вы писали:

SS>С большой вероятностью мы выберем, учитывая не слишком конкурентную зарплату, обычного опытного программиста.

ну тогда это не по теме

Здравствуйте, w00zle, Вы писали:


W>Вариант 2. Девелопер находит гаечный ключ и прикручивает датчик.

Вариант 2а: Девелопер находит гаечный ключ, лезет к рельсе и остается лежать перееханный поездом.
Вариант 2б: Девелопер находит гаечный ключ, лезет к рельсе и оказывается в КПЗ с отбитыми почками, т.к. бдительные сотрудники ЖД сообщили "куда надо" о "террористе"
Вариант 2в: Девелопер находит ключ, начинает прикручивать датчик и убивается нафиг тяговым током (невозможно? Отнюдь)

Мораль такова — каждый должен делать свою работу. Кто "турма сидеть" будет, если из-за криво привинченного датчика крякнется сигнализация или поезд под откос пойдет?


ЗЫ: Если интересно, могу рассказать, как работают девелоперы на объектах в "цивилизованных странах".

Здравствуйте, Denis, Вы писали:

D>это совершенная неправда если работает несколько человек с пересекающимися задачами будет интересно увидеть систему через несколько месяцев....

Я такое не раз видел. Душераздирающее зрелище

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>кстати, буду признателен, если опишите в 2х словах — можно ли ее включать в must read категорию, или ничего существенного\нового к Peopleware Ларри не добавляет?

на самом деле, это сборник статей на разные темы. На must read не потянет, но почитать однозначно стоит — интересные идеи там есть.

VAB>увы. но еще говорят: кто ищет — тот найдет! поэтому давайте верить в лучшее

Здравствуйте, Kolhoz, Вы писали:

K> Это не программист, это тупица. Умный человек легко может оценить, насколько другой специалист в его области лучше него сечёт фишку — ведь теоретическая база то у них общая, так что уровень получаемых на ней выводов оценить может каждый.

Согласен. Но ты знаешь, мне все время кажется, что умные люди постоянно в дефиците

K> Глуп был классик. Сложно найти физика, кто не способен оценить уровень квалификации Эйнштейна, Гамова или Ландау. Чем программахеры должны быть хуже?

Это сейчас Эйнштейн, Гамов или Ландау — признанные авторитеты. А вообще Эйнштейна долго не признавали, в школе ему ставили плохие оценки и даже считали умственно отсталым, и ему стоило немалых трудов пробить себе путь. А Шаляпина, например, не приняли в школьный хор.
В общем, задним умом все крепки.

Здравствуйте, Denis, Вы писали:

D>это совершенная неправда если работает несколько человек с пересекающимися задачами будет интересно увидеть систему через несколько месяцев.... А взаимодействовать им религия не позволяет? В конце концов, почти весь open source пример такого подхода. И ничего, не жалуются.