Здравствуйте, мыщъх, Вы писали:

М>>>так же архитектор (и старший, и младший) собирают требования от кучи людей -- как от клиентов, так и от инженеров.
KA>>Эта прохвессия называется "аналитик"
М>профессия и название должности это две большие разницы. аналитик может быть инженером, не? впрочем, не суть. т.к. мне меняют титул с sr. engineer на architect, то я как бы в курсе своих должностных обязанностей.

Ну я ж не про ваши конкретные обязанности, я сам solutions architect, но иногда жабоскрипт в формах правлю.

М>ну или давайте ссылку на то, что не должен делать архитектор. в частности, всем известно, что задача манагера это не делать работу, а убедиться в том, что работа выполнена правильно. во всяком случае так во всех букварях написано (в реальности дело обстоит слегка иначе, ибо мир это не книга, но как-то так все и есть).

Хаха где же я возьму инструкцию о том, чего он не должен делать? Ну почитайте уголовный кодекс например )

М>в каких букварях написано, что архитектор должен работать с готовым списком требований?

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

Бизнес-аналитики делают дофига того, что очень далеко от архитекта. Например проведение фокус-групп, бреинсторминг (не по архитектуре, а по бизнесу!), моделирование процессов, прототипирование, анализ рисков, диаграммы состояний, проводят опросы, берут интервью, пишут сценарии и т.д. Всё это имхо не архитекторская тема ни разу. Не говоря уже о том, что аналитики часто торчат у клиентов, из-за чего вынуждены носить рубашку и галстук

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

KA>Здравствуйте, мыщъх, Вы писали:

М>>профессия и название должности это две большие разницы. аналитик может быть инженером, не? впрочем, не суть. т.к. мне меняют титул с sr. engineer на architect, то я как бы в курсе своих должностных обязанностей.
KA>Ну я ж не про ваши конкретные обязанности, я сам solutions architect, но иногда жабоскрипт в формах правлю.
так выбирая название (а выбирал себе я его сам -- Research Architect, HR'ам ведь по большому счету все равно) много гуглил и читал, чтобы не выбрать неправильное название, которое будет неправильно понято окружающими.

М>>ну или давайте ссылку на то, что не должен делать архитектор. в частности, всем известно, что задача манагера это не делать работу, а убедиться в том, что работа выполнена правильно. во всяком случае так во всех букварях написано (в реальности дело обстоит слегка иначе, ибо мир это не книга, но как-то так все и есть).
KA>Хаха где же я возьму инструкцию о том, чего он не должен делать? Ну почитайте уголовный кодекс например )
есть много книг по каждой должности от рядового инженера до манагера. в частности, от инженера (не sr) никто НИОКР'а не ждет, на позиции senior'а это само собой разумеется. так же есть куча литературы о том, что должен делать архитектор и чего не должен (и я приводил пример, что архитектор постоялого двора не должен вникать в конструктивные особенности wifi роутеров и свойства радиоволон, не говоря уже о том, что "короткоствольные" мобилы ведут себя сильно иначе, ибо сигнал отражается и переотражается от любой поверхности вместо того, чтобы проходить сквозь нее).

М>>в каких букварях написано, что архитектор должен работать с готовым списком требований?
KA>Не буду спорить, конечно архитекторы работают и с требованиями. Но всё-таки лучше,
KA>если требованиями занимается специально обученный вытягивать их из клиента клещами человек.
смотря о каких клиентах мы говорим. архитекторы ядра винды и NTFS уж точно не встречаются с домохозяйками, но архитекторы небоскребов нормально так встречаются с заказчиками и обсуждают волнующие их вопросы.

KA>Бизнес-аналитики делают дофига того, что очень далеко от архитекта.
кто ж спорит. аналитика -- это аналитика, архитектура -- это архитектура. постановка требований может исходить как от архитектора (давайте заюзаем видюху для ускорения вычислений), так и от аналитиков -- "четыре метра или до свиднания" (с), что, кстати, стало роковой ошибкой.

> моделирование процессов, прототипирование,
прототипирование разве не работа архитектора?

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

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

Здравствуйте, мыщъх, Вы писали:

М>смотря о каких клиентах мы говорим. архитекторы ядра винды и NTFS уж точно не встречаются с домохозяйками, но архитекторы небоскребов нормально так встречаются с заказчиками и обсуждают волнующие их вопросы.

А я вот кстати не в курсе, с кем встречаются архитекторы ядра винды? Мы-то сами не делаем коробочных продуктов.

KA>>Бизнес-аналитики делают дофига того, что очень далеко от архитекта.
М>кто ж спорит. аналитика -- это аналитика, архитектура -- это архитектура. постановка требований может исходить как от архитектора (давайте заюзаем видюху для ускорения вычислений), так и от аналитиков -- "четыре метра или до свиднания"

Нет, юзание видюхи — это не требование. Это элемент архитектуры. (Который разумеется обоснован требованиями, как и вся остальная архитектура.)

>> моделирование процессов, прототипирование,
М>прототипирование разве не работа архитектора?

Ага, там обычно многие замазаны Но я имел в виду бизнес-прототипы, которые создаются, чтобы заказчик убедился в правильности требований. Бывают конечно и другие прототипы.

М>анализ рисков -- архитектурная. проектируем мост, например. учитываем риски.

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

М>аналитики это чисто российская специфика. в штатах их даже в крупных компаниях не так, чтобы много и многие продукты создаются без их участия.

Тогда как вы например объясните, что Dice по словам "business analyst" выдаёт 11800 вакансий, а "architect" — 9300?

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

KA>Здравствуйте, мыщъх, Вы писали:

KA>А я вот кстати не в курсе, с кем встречаются архитекторы ядра винды? Мы-то сами не делаем коробочных продуктов.
мы тоже коробочных продуктов не делаем. мы поставляем аппаратно-программный комплекс для крупного энерпрайза, ну а я архитектор двух основных его частей (и обе ядреные, т.е. ядерные). встреча архитектора с клиентами -- хорошая возможность реализовать фичи, которые давно чещут руки. клиенту демонстрируется макет, собранный на коленках в свободное от работы время, клиент возбуждается и говорит "хочу". конечно, манагер меня потом отымет во все дырки, но раз клиент хочет... но это не самое главное. маркетологи -- это люди, оторванные от народа. например, куча фирм поставляет DLP-системы, предотвращающие утечку данных. маркетологи вынуждают архитекторов реализовать активный режим защиты, который 99% клиентов тут же выключают и система работает исключительно в режиме мониторинга. если архитектор знает, что клиентам активный режим не нужен, но в рекламе он заявлен -- архитектор делает основной упор на мониторинг, а активный режим "чтобы було".

так же архитекторы встречаются с разработчиками железа. классический пример -- парни из интела заявились в ms и спросили -- чего бы им такого оптимизировать, чтобы винда побыстрее работала. из зала раздалось предложение -- "оптимизируйте скорость выполнения инструкции, которой нет". штука? ни фига подобного. винда таким образом бросала исключения. когда-то эта инструкция (которой нет) работала сопоставимо по скорости с теми инструкциями, которые есть, но затем разрыв стал нарастать. инженеров из интела едва святой кондратий не хватил, когда они сравнили работу винды до и после оптимизации.

KA> Нет, юзание видюхи — это не требование. Это элемент архитектуры.
KA> (Который разумеется обоснован требованиями, как и вся остальная архитектура.)
почему не требования? поддержка GPU не требование? или нормальная поддержка 64 бит? вот тут одну библиотеку юзаю сишную. ей передается указатель на данные для обработки. на 32 бита предел ~500метров. они заявили, что поддержали 64 бита. теперь можно выделять до 2 гб. точнее, можно выделять и больше, но оно гробит данные нахрен. какой-то лось использовал int для индексации. ну и где 64 бита? нету их. потому что от архитектора изначально не исходило требование -- поддерживать работу с 64 битами. именно от архитектора, потому что маркетологи такую задачу в лохматых 90х не ставили.

М>>анализ рисков -- архитектурная. проектируем мост, например. учитываем риски.
KA>Ну вообще учёт рисков это прямая обязанность манагера, потому что риски измеряются в долларах
выше я затронул вопрос о поддержке 64 бит. допустим, если писать с поддержкой это увеличивает стоимость разработки (нужно нанимать девов, которые знают чем int от size_t отличается). нужно тестировать это на 64 битах. это сейчас они очевидны, а раньше это... скажем так, в 2008 году я спросил генерального архитектора -- должен ли я поддерживать 64 битные оси в моем коде на си? генеральный ответил -- нет, не нужно, ибо мы работаем на 32 битах и переход на 64 бита не планируем. сейчас 2012 год и мы на 64 бита не перешли, т.к. во-первых, оно не нужно (клиент получает "ящик", который вставляет в рэк и клиенту по фиг сколько там бит), во-вторых, многие используемые нами библиотеки на 64 бита только переходят и жутко глючат. то есть генеральный был прав. но к своему удивлению, мой код был перенесен на 64 бита путем простой перекомпиляции и сейчас работает в куче продуктов под совсем не интеловскими ЦП.

это и есть анализ рисков. какова вероятность того, что потребуется использовать весь проект (или его часть) в условиях, отличающихся от того, что записано в ТЗ? насколько сильно это ударит по бюджету и времени разработки? ведь бывают и обратные платформы. та же винда изначально проектировалась как кросс-платформ и даже была портирована на альфу, поддерживая OS/2 и POSIX. но там она не прижилась и ms даже объявила, что не может тянуть два ядра под 32 и 64 бита и оставляет только одно ядро, а на другое забьет (что указывает на кривизну архитектурных решений, ибо никсы воркаются чуть ли не на сотнях платформ и ниче).

кстати, про никсы. симпатичная девушка решила курить асм. установила 64 битные никсы и скачала пример "hello, world" под 32 nasm. ес-но, у нее он не скомпилился. тогда она форсировала 64 битный режим компиляции и получила 64 разрядный ELF файл. ага, с 32 разрядными регистрами и 32 разрядными сискалами через int 80h. но файл нормально запустился и вывел заветную строку на экран. охренеть какие никсы умные. попробуйте повторить этот трюк с виндой. создайте 64-битный PE-файл и юзайте в нем 32-битные функции ядра. а вот хренушки вам!!!

М>>аналитики это чисто российская специфика. в штатах их даже в крупных компаниях не так, чтобы много и многие продукты создаются без их участия.
KA>Тогда как вы например объясните, что Dice по словам "business analyst" выдаёт 11800 вакансий, а "architect" — 9300?
числа одного порядка. обе специальности -- редкие. а вы точно уверены, что архитектор это тот, кто программы пишет, а не мосты строит? а бизнес аналитик это тот, который в софтверной компании считает какие-то непонятные цифы, а не калькулирует кредитную ставку на основе кредитной истории, по формуле из учебника для носорогов?

Здравствуйте, мыщъх, Вы писали:

М>кстати, про никсы. симпатичная девушка решила курить асм. установила 64 битные никсы и скачала пример "hello, world" под 32 nasm. ес-но, у нее он не скомпилился.
Вообще-то, должен был. 64-битное ядро полность совместимо с 32-битным userland'ом.

Вполне можно взять обычный 32-битный Линукс, воткнуть туда 64-битное ядро и оно всё будет прекрасно работать. Причём будет использовать всю память, и отдельно взятый 32-битный процесс спокойно сможет съесть почти 4Гб (так как почти всё адресное пространство свободно).

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

C>Здравствуйте, мыщъх, Вы писали:

М>>кстати, про никсы. симпатичная девушка решила курить асм. установила 64 битные никсы и скачала пример "hello, world" под 32 nasm. ес-но, у нее он не скомпилился.
C>Вообще-то, должен был. 64-битное ядро полность совместимо с 32-битным userland'ом.
вообще-то, если точно, то скомпилился, но не слинковался, ld обругал матом и ничего не собрал. я посоветовал ключ -f elf64. помогло.

C> Вполне можно взять обычный 32-битный Линукс, воткнуть туда 64-битное ядро и оно всё будет прекрасно работать.
да я в курсе. но у нее был 64 битный линух с 64 битным ядром на 64 битном маке под виртуалкой.

C> Причём будет использовать всю память, и отдельно взятый 32-битный процесс спокойно сможет
C> съесть почти 4Гб (так как почти всё адресное пространство свободно).
меня поражает не это. меня поражает, что даже если в заголовке эльфа указано, что он под 64 бита, а сам эльф юзает 32-битные сискалы, то все работает и дает возможность писать смесь 32- и 64-разрядного кода от которой ида едва не отбросила копыта.

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

S>потрясающее название должности
S>только что пришло от рекрутера


S>

S>My direct client is in need of a Junior Web Architect.

Это вакансия архитектора на з/п джуниора

Здравствуйте, мыщъх, Вы писали:

М>клиенту демонстрируется макет, собранный на коленках в свободное от работы время, клиент возбуждается и говорит "хочу". конечно, манагер меня потом отымет во все дырки, но раз клиент хочет... но это не самое главное

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

Вы даже не представляете, что в прежние времена означала должность
МЕНЕДЖЕР. А сейчас есть "менеджер" по продажам окна-двери методом
приставания к людям в переходе.

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

KA>Здравствуйте, мыщъх, Вы писали:

М>> клиенту демонстрируется макет, собранный на коленках в свободное от работы время,
KA> И зачем это? Из любви к искусству?
представим, что вы на оружейном заводе работаете и выпускаете очень мощные автоматы, которые пробивают любую броню. в свободное от работы время мы смотрите новости и узнаете, что на западе есть люди, которых называют террористами, которых проще пристрелить, чем договориться. вы тут же соображаете, что в таких условиях мощные автоматы бесполезны, неудобны, а пули (дуры) рикошетом бьют по заложникам и своим. неожиданно вы обнаруживаете, что необходима специальная модель автомата для спецназа и что этой модели ни на западе, ни на востоке нет, т.к. террористы только появились и оружейная промышленность не успела отреагировать.

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


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

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

в быстро меняющемся мире очень важно улавливать новые тенденции и начинать работать над ними еще до того, как они станут видны невооруженным глазом, а рынок окажется захваченным конкурентами.

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