Jump to content

    
Sign in to follow this  
Zuse

Организационный аспект разработки РЭА

Recommended Posts

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

Помимо меня был еще один разработчик который занимался только механикой.

Понимаю. Я вижу два крайних варианта: либо универсал, либо группа крайне узкспециализированных инженеров.

Все остальные варианты лишь производные от этих двух. А дальше уже зависит от рынка предложений и возможностей.

Share this post


Link to post
Share on other sites
Работаю на достаточно крупном госпредприятии (около тысячи работников). Контора специализируется на прецизионной электромеханике + делает электронику к ней.

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

Share this post


Link to post
Share on other sites
Попробуйте прочитать вот эту статю "Та самая цель", особенно представленную книгу, может чем вам и поможет в поисках решения на ваши вопросы

 

Мысли измученного клиентами менеджера. ИМХО.

Есть другое мнение. Цель - капитализация, а не срочное достижение прибыли.

А капитализация - это и человеческий капитал.

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

Share this post


Link to post
Share on other sites
Мысли измученного клиентами менеджера. ИМХО.

Не знаю... с автором статьи незнаком.

 

Так-то оно так... Но к сожалению гос-предприятие это не ГУГЛ... А для того что бы его сделать ГУГЛом нужно пробиться через советские стереотипы дедков которые там сидят, что практически невозможно...

Share this post


Link to post
Share on other sites
А потому, как в Google, надо сначала выделить лучших специалистов, а потом им дать их любимые темы. И что важно, без разделения обязанностей.

 

а что значит "без разделения обязанностей"?

Edited by Konrad

Share this post


Link to post
Share on other sites
В результате всех этих экспериментов и наблюдений я пришел к выводу о целесообразности:

- как минимум возложить обязанность трассировки ПП на разработчика схемы

- как максимум ликвидировать в структуре КБ КПАшный сектор и передать их тематику нам (схемотехникам-КПАшникам) усилив наш сектор парой-тройкой специалистов соответствующего профиля

В связи с такими выводами мне стало очень интересно: каким образом организуется разработка/проектирование РЭА на других предприятиях?

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

 

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

Я работаю на крупной частной конторе (несколько сотен работников), руковожу небольшим =) отделом разработки. И у нас каждый выполняет свою конкретную работу-есть отдел конструкторов-механиков, отдел ПП, в схемотехнике тоже все разбито на маленькие области- цифра/плис/аналог/питание -все отдельные узкие специалисты. Нету никаких бабушек, досиживающих до пенсии, есть конкретные профессионалы. Нету сверху советского прошлого с лишними бумажками и согласованиями. Есть плотное взаимодействие разработчиков и четкое планирование/руководство/распределение ресурсов сверху.

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

Единственное условие-люди должны хотеть работать, а не переводить друг на друга стрелки в поисках крайнего.

Share this post


Link to post
Share on other sites
В результате всех этих экспериментов и наблюдений я пришел к выводу о целесообразности:

- как минимум возложить обязанность трассировки ПП на разработчика схемы

- как максимум ликвидировать в структуре КБ КПАшный сектор и передать их тематику нам (схемотехникам-КПАшникам) усилив наш сектор парой-тройкой специалистов соответствующего профиля

 

В связи с такими выводами мне стало очень интересно: каким образом организуется разработка/проектирование РЭА на других предприятиях?

1) Если всем не хочется работать - никакой реорганизацией не поможеш.

2) баланс узких\и широких специалистов определяется спецификой розработки.

Может Вам надо суперпрограмист и так-себе механик корпус типовый сварганить и другие полезные дела поделать типа ПП розвести.

3) даже в буржуйских конторах с тисячей человек по всему миру может не быть конкретной специализации.

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

И весь обмен между отделами прямо по телефону, приездом в командировку и розговором, Е-мейлаими....

Изредка, при этом, особо немогущие и неумеющие работники не получают продления контракта....

 

Share this post


Link to post
Share on other sites
В связи с такими выводами мне стало очень интересно: каким образом организуется разработка/проектирование РЭА на других предприятиях?

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

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

Share this post


Link to post
Share on other sites
Проблемы взаимодействия подразделений сейчас пытаемся решать через проектное управление - под разработку создается временная команда специалистов из разных отделов. Не идеально, конечно, но в целом работает.

 

Как эти люди между собой взаимодействуют? Кто их непосредственный руководитель и кому он в свою очередь подчинен?

 

 

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

 

 

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

 

Если всем не хочется работать - никакой реорганизацией не поможеш.

 

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

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

Edited by Konrad

Share this post


Link to post
Share on other sites
Тут ведь в чем дело... на советском, по сути, предприятии невозможно устроить революцию. Нельзя быстро повысить производительность, поднять мотивацию, радикально улучшить организацию, ....пока зреет идея ползучего переворота

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

Такого работника легко стимулировать приказом и страхом увольнения, чего нельзя сделать с работником из другого отдела.

 

А что Вам мешает договорится по хорошему с начальником другого отдела или даже напрямую с исполнителем?

Какие есть способы и возможности его мотивировать выполнять именно Вашу роботу быстро и качественно?

 

----

И кстати. То что Вы передаёте девочкам на розводку качественно сделано?

Коректная база данных, полная информация о компонентах, описание критических цепей.....

Share this post


Link to post
Share on other sites
Как эти люди между собой взаимодействуют? Кто их непосредственный руководитель и кому он в свою очередь подчинен?

У нас т.н. сбалансированная матричная структура: есть функциональные вертикали (отделы) и есть проектные горизонтали. Начальники отделов на старте проекта выделяют специалистов, а рулит работой по проекту менеджер проекта. В общем, классика PMBook. Для разборок между менеджерами и общего планирования уже появился проектный офис :))

Share this post


Link to post
Share on other sites
В Вашем случае я вижу попытку заполучить подчинённого который будет выполнять именно Ваши команды, а не начальника другого отдела.

Такого работника легко стимулировать приказом и страхом увольнения, чего нельзя сделать с работником из другого отдела.

Это все правильно замечено. Т.е. фактически есть уверенность в том что процесс контролируется вами хоть в какой то мере.

А что Вам мешает договорится по хорошему с начальником другого отдела или даже напрямую с исполнителем?

Какие есть способы и возможности его мотивировать выполнять именно Вашу роботу быстро и качественно?

Выше автор темы уже писал что в плане гибкости старые конторычрезвычайно закостеневшие. И в этом я с ним согласен. Да и к чему все эти переговоры. Закладывать себе самому же мину наперед? Случалось сталкиваться с некоторыми "тертыми кадрами", которые четко остлеживают кто, кому и что должен, тщательно архивируют любую бумажку. Сама суть работы им в принципе не важна. А тут под боком молодой товарищ "бъет копытом и сгорает на работе"... В итоге любая неприятная ситуация будет на счету второго. Поэтому лучше такие внешние связи сводить к минимуму. И не давать держать себя за то, что не должно быть в чужих руках. Прошу простить за избыточную лирику.

Konrad

Уверен, что ваш отдел называется не "отдел схемотехников примерно одинаковых плат". Поэтому ничего страшного в том что появится 1-2 конструктора не произойдет.

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

Не стоит заморачиватся этими самыми, выше названными PMBook. Поверьте, что это забота руководителей совсем другого уровня и совсем для других задач.

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

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

Запомнился один рекламный "перл", рожденный ДУПом в маркетинговых потугах.

"Ваши проблемы-наши эффективные решения". Читай как хочешь, но как правило воспринималось в негативном контексте. :)

Мобильные группы у нас тоже практиковались. Приказом директора предприятия по каждому конкретному договору или проекту определялся круг причастных и ответственных + сроки. Это реализуемо даже внутри одного отдела.

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

Вот вам сейчас надо двух конструкторов - пусть они будут. Если через год работы результаты будут не очень - переиграете. Главное чтобы были результаты.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this