Интересно есть ли какая нибудь литература обьясняющая специфику бизнеса по разработке электронных устройств, по сравнению со обычным IT.
?

Six Sigma for Electronics Design and Manufacturing (upload/doc/).

Chapter 1. The Nature of Six Sigma and Its Connectivity to Other Quality Tools
Chapter 2. The Elements of Six Sigma and Their Determination
Chapter 3. Six Sigma and the Manufacturing Control Systems
Chapter 4. The Use of Six Sigma in Determining the Manufacturing Yield and Test Strategy
Chapter 5. The Use of Six Sigma With High- and Low-Volume Products and Processes
Chapter 6. Six Sigma Quality and Manufacturing Costs of Electronic Products
Chapter 7. Six Sigma and Design of Experiments (DoE)
Chapter 8. Six Sigma and Its Use in the Analysis of Design and Manufacturing for Current and New Products and Processes
Chapter 9. Six Sigma and the New Product Life Cycle
Chapter 10. New Product and Systems Project Management Using Six Sigma Quality
Chapter 11. Implementing Six Sigma in Electronics Design and Manufacturing

И одна лекция примерно по этой тематике:
"Организация разработок микросхем в дизайн-центре."

Спасибо . Скачал просвящаюсь.

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

ДЛя начал предлагаю обсудить статью http://electronicsweekly.com/Articles/2005...nchiptalent.htm

"As the oil money flows more abundantly in Russia, the hope is that it will be channelled into young Russian scientists, renowned for their off-the-wall thinking, who can grow the Intels, Microsofts and Googles of the future."

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

Такие компании есть, точно знаю. Например ЮникАйСиз, знаю еще как минимум две организации занимающихся этим делом, да и собственно я сам в своей компании делаю такие разработки и с госзаказом ни грамма не связан, правда делаю только для собственных нужд, никаких сторонних заказов, на себя времени еле-еле хватает. ( http://venus.ru ). А вот что должен знать менеджер - так это точно как минимум все этапы от исходника на верилоге или схемы на транзисторах и до масок, где и для чего какая технологическая информация используется, и самое главное, четко знать, какие файлы, для чего и на каком этапе нужны (к примеру design rules, DRC-, LVS-runset, и т.д.), разбираться чем фронтэнд от бэкенда отличается, и какой объем работ и с применением чего входит в каждый из них. Самим пришлось года три назад общаться с манагерами такой тайваньской компании, пока напрямую с фабом не завязались, приходилось по часу через msn им объяснять, что же конкретно мне надо. Это не есть правильно. Если я например прошу - пришлите мне спайс-модель такой-то и такой-то IO-ячейки от такой-то технологии, для того, чтобы выбрать, какую использовать, то надо их просто прислать, тем более что договор уже подписан, а не компостировать мозги два дня, что этого у нас нет, потом что вообще не знаем что это, а потом, после отборного мата и прямого диалога с их разводильщиком - получить в течение минуты. Менеджер должен понимать, что хочет заказчик, если это касается стандартной документации и дизайн-китов по техпроцессу.

Ну на юник точно не следует ориентироваться. Впрочем если есть много бабок для попилки то и юники сойдут за образец.

Если нет много бабок, то к этой области и близко подходить не стоит. Особенно если делать разработки не для себя, а для сторонних заказчиков. Вспомните, сколько стоят одни лицензии на бэк-енд софт, не говоря о фулл кастом аналоге...

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

Точно так же, как менеджер продающий бытовую технику, должен знать параметры, отличия и тонкости каждой модели из того, что он предлагает, так же и тут, менеджер должен знать все параметры и возможности предлагаемых процессов, и свободно изъясняться с нами, разработчиками - их заказчиками, оперативно поставляя нужную информацию. Коммерческая сторона вопроса в этом деле - это мизер (по времени), основное общение происходит на тему "а позволяет ли процесс", "а скажите параметры такой или эдакой структуры", и менеджер должен знать ответы на все основные вопросы, и быть в курсе того, что можно сделать (и уже делалось) на данном процессе, а что принципиально нельзя. И не отрывать технологов и разработчиков по каждой ерунде. Я уже не первый год общаюсь с этими менеджерами (из фаблесс конторы www.pgc.com.tw ) , и вполне понимаю, что от них требуется.

А именно:
1) Предоставить мне, заказчику-разработчику, всю необходимую информацию о том процессе, который я выбрал (и может предложить альтернативы)
2) Обеспечить техподдержку на время разработки топологии.
3) Обеспечить связь с их разработчиками, если я пользуюсь какими-то доп. услугами, например backend.
4) Испечь, протестировать, запаковать чипы.

Менеджер делает пункты 1 - 3. Пункт 4 - это производство, там менеджер не работает, там другие люди - кто с фабами, тестхаусом, и т.п. работают. Итого, кроме заключения договора, у него, менеджера, сплошные технические вопросы.

If a man does only what is required of him, he is a slave. If a man does more than is required of him, he is an idiot slave. If a man does less than is required of him, he is a lazy slave. If a man does what he believes he needs to do, then he is a free man.