Перейти к содержанию
    

Книги по управлению проектами разработки РЭА

Порекомендуйте книги, наилучшим образом подходящие для специфики отрасли.

Можно и на английском.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нифига не теоретическая книга и не учебник. Акио Морита "Сделано в Японии". Воспоминания одного из основателей фирмы Sony

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, V_G said:

Нифига не теоретическая книга и не учебник. Акио Морита "Сделано в Японии". Воспоминания одного из основателей фирмы Sony

Слащавая книга ничего не объясняющая, без описаий коллизий, нахождения решений и выходов, и пр. Чтобы все поцокали языком - как все было славно и хорошо.

Пожалел, что потратил время на ее прочтение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Западный опыт в области организации разработки и производства опытных образцов к России применим лишь частично.

Основная наша особенность, адская логистика внутри страны. Из Москвы в заграницу грузы улетают нормально, а по России адский ад.

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

Другая наша особенность, отсутствие свободных кадров в областях, требующих высокой квалификации.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

23 minutes ago, baumanets said:

придётся держать больший складской запас компонентов.

Какая связь между складом и разработкой? 

РЭА слишком большая область.
Лучше сузить охват. Вот например как делать встраиваемые системы -   Jack Ganssle , The Art of Designing Embedded Systems.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Согласен со вторым абзацем AlexandrY.

Автору темы могу посоветовать книгу "Мифический человеко-месяц". Ф.Брукс

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 6/2/2019 at 3:30 PM, Juzujka said:

Порекомендуйте книги, наилучшим образом подходящие для специфики отрасли.

а чем писание встраиваемого кода (HDL / рисование топологии / и прочая CAD ориентированная деятельность) отличается от писания программ?

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 hours ago, baumanets said:

Автору темы могу посоветовать книгу "Мифический человеко-месяц". Ф.Брукс

Великолепная книга, немного устарела, да и направленность на программные системы.

Как говорил Королев - "Когда у меня было 7 работников, я знал, кто, что, и как делает. Когда 70 - знал только что и как. Когда 700 -знал только что делают".

И это только одна из проблем.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я бы добавил ещё одну книгу:

Том Демарко Тимоти Листер Человеческий фактор: успешные проекты и команды

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо!

А книги

Управление проектами. Клиффорд

Управление высокотехнологичными программами и проектами / Рассел Д. Арчибальд

Кто-нибудь читал?

Насколько это применимо к реальной жизни?

( и написания курсовой работы )

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 6/3/2019 at 11:57 AM, AlexandrY said:

Какая связь между складом и разработкой? 

РЭА слишком большая область.
Лучше сузить охват. Вот например как делать встраиваемые системы -   Jack Ganssle , The Art of Designing Embedded Systems.

Начал читать. Прям с первых строк в точку и любителям RTOS.. KLOC - kilo lines of code.
 

Quote

 

One way to keep productivity levels high—at, say, the 20-KLOC/program number—is to break the program up into a number of discrete entities, each no more than 20 KLOC long. Encapsulate each piece of the program into its own processor. 

That ’ s right: add CPUs merely for the sake of accelerating the schedule and reducing engineering costs.

Sadly, most 21st century embedded systems look an awful lot like mainframe computers of yore. A single CPU manages a disparate array of sensors, switches, communications links, PWMs, and more. Dozens of tasks handle many sorts of mostly unrelated activities. A hundred thousand lines of code all linked into a single executable enslaves dozens of programmers all making changes throughout a byzantine structure no one completely comprehends. Of course development slows to a crawl.

Transistors are cheap. Developers expensive.

Break the system into small parts, allocate one partition per CPU, and then use a small team to build each subsystem. Minimize interactions and communications between components and between the engineers.

Suppose the monolithic, single-CPU version of the product requires 100 K lines of code. The COCOMO calculation gives a 1403–man-month development schedule. Segment the same project into four processors, assuming one has 50 KLOC and the others 20 KLOC each. Communications overhead requires a bit more code so we ’ ve added 10% to the 100-KLOC base fi gure. The schedule collapses to 909 man-months, or 65% of that required by the monolithic version.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 6/2/2019 at 3:30 PM, Juzujka said:

Порекомендуйте книги..

OFF/2:

Книги не скажу... но.. Название темы косяк...

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

Немножко из опыта: 

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

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

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

 

 

как то так

(круглый)

Изменено пользователем kolobok0

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Переписываюсь по этому поводу на канале Электронная Индустрия. https://zen.yandex.ru/id/5d53e8c80ce57b00c1d830ad  Вразумительный ответ один: Лучшая книга: "Как пасти котов" и Нашего отечественного специалиста по дистрибьюции Перминова Сергея Максимовича  "Дистрибьюция" . Подход применим к поставщикам ЭК. 

On 6/2/2019 at 3:30 PM, Juzujka said:

Порекомендуйте книги, наилучшим образом подходящие для специфики отрасли.

Можно и на английском.

Переписываюсь по этому поводу на канале Электронная Индустрия. https://zen.yandex.ru/id/5d53e8c80ce57b00c1d830ad  Вразумительный ответ один: Лучшая книга: "Как пасти котов" и Нашего отечественного специалиста по дистрибьюции Перминова Сергея Максимовича  "Дистрибьюция" . Подход применим к поставщикам ЭК. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

21.12.2019 в 14:57, kolobok0 сказал:

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

Абсолютно с этим не согласен.

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

А то, что посоветовали выше - это как пасти программистов.

Но электронщики - это не программисты. Тут своя специфика

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

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

×
×
  • Создать...