Устранение конфликта интересов и оптимизация организации работ при проектировании РЭА

Так сложилось, что на протяжении всего периода моей работы в радиотехнике я старался не повторять имеющиеся конструкции, а на базе доступной мне информации реализовывать собственные проекты. Благодаря накопленному до и в годы учебы опыту в части проектирования РЭА и исследований в области радиотехники, я сразу начал работать в должности инженера — руководителя группы в НИИ радиосвязи. Рано, по меркам СССР, занял должность начальника КБ одного из крупнейших в СССР оборонного предприятия, позже став вторым главным конструктором, ответственным за разработку и внедрение новой техники. Наше предприятие могло себе позволить проводить ОКР, поскольку имело практически все технологии и собственное инструментальное производство, то есть обеспечивался полный замкнутый цикл.

С 2001 года и по настоящее время работаю ведущим инженером совместного украинско-английского малого предприятия (СП), которое осуществляет разработку и поставку (в том числе и на мировой рынок) наукоемкого оборудования: робототехнического, радиотелефонного, систем распознавания образов и встраиваемой электроники, изделий специального назначения. Накопленный опыт в части организации работ позволил сформировать свою систему постановки продукции на производство, минимизирующую различные организационные риски. Система использовалась, как на государственном предприятии, так и в личном бизнесе автора статьи.

Для того чтобы понять суть, сначала обрисуем проблему. Например, необходимо создать отдельно выполненный интерфейс. Он предназначен для связи нестационарного оборудования с центральной ЭВМ для передачи телеметрической информации и приема команд управления. Как видим, это рутинная задача, не несущая в себе особых сложностей. Но как она выглядит с точки зрения организации работ (здесь и далее речь идет о проектировании РЭА)? В данной ситуации мы имеем явно выраженный конфликт интересов среди разработчиков устройства как целостной единицы. И для рассматриваемой проблемы он не один — их как минимум три. Есть интерес разработчика решения — специалиста по схемотехнике (как мы говорим, радиста или электронщика). Хороший схемотехник широкого профиля — большая редкость на рынке труда, поэтому он у нас часто и заслуженно — белая кость, голубая кровь. Именно он, как считается, закладывает основу основ нового изделия, хотя это вредное заблуждение и здесь уже заложен конфликт интересов. Основу изделия, как конечного продукта, должен закладывать маркетолог. Именно он (если это действительно специалист, а не простой обладатель диплома) должен решить, что востребовано на рынке, с какими функциональными особенностями и при каком уровне цен. Хотя есть и исключения — можно вспомнить, например, знаменитый плеер Walkman компании Sony или первые персональные компьютеры Apple. Но если Apple создавались целенаправленно и, скажем так, на интуиции владельцев компании, то Walkman был буквально вытащен из рукава разработчиками одного из подразделений Sony, которым в конце 1970-х угрожало увольнение из-за реорганизации. Так что руководство компании Sony к появлению Walkman прямого отношения не имело, хотя плеер и был сделан специально для директора, любившего послушать музыку. Но исключения лишь подтверждают правило, и их не так много. Никто не запрещает генерировать идеи, но все-таки они должны быть оценены с точки зрения рынка. Основная же задача команды разработчиков — выполнить затребованный на рынке проект в кратчайшие сроки, с разумными затратами на НИОКР, оптимальной надежностью (этот вопрос поднимался, например, в [1]) и, что особенно важно, не превысив заданную себестоимость конечного изделия. Ранее имелась в виду лимитная цена, но в современных условиях важна именно себестоимость — цену определит рынок. Но что иногда получается на практике? А возникает еще один конфликт интересов по типу «мы и сами с усами» — очень часто разрабатывают то, что можно разработать, а потом уже начинают думать, как это продать, и дай бог, если это получится. Знакомая ситуация?

Если разработка осуществляется общепринятым путем, а изделие не представляется особо сложным, например, как упомянутый интерфейс, являющийся частью аппаратного комплекса, то его схема с перечнем элементов поступает в работу без особо тщательного контроля со стороны руководителя проекта. Далее к процессу подключается конструктор (как мы называем — «печатник») по разработке печатной платы. Не хочу никого обидеть или нарушить гендерный принцип, но это, как правило, женская профессия, и специфика такого инженера — исключительно печатная плата, а отнюдь не тонкости схемотехники. В лучшем случае ему дадут желаемые габариты платы. Как итог, все это (схема и чертежи печатной платы) попадает в руки конструктора по «железу». Он — конечная ступень разработки перед технологом, изготовителем деталей конструкции и сборщиком.

Что остается за рамками? Во-первых, не учтен такой интересный вопрос, как «а где купить микросхемы для интерфейса и сколько времени займет их поставка?». Это никто не контролировал, а схемотехник думал про схему, а не про закупку комплектующих. Нередко оказывается, что он наиболее интеллектуальный, а значит, и амбициозный работник, для него закупка комплектующих — мелочь, пусть о ней думает снабженец. Никто не спорит: разработать схемотехническое решение действительно непросто и зачастую требуются не только определенные знания, но и талант. Хотя это лишь часть проекта. Схемотехника сама по себе не является итоговым изделием, и до конца еще ой как далеко, но уже здесь мы имеем зародыш межличностного конфликта из-за высокой самооценки одного из исполнителей. Многие скажут, да ладно, сейчас купить можно все, но, тем не менее, один из конфликтов, в самом зародыше простейшей разработки, уже налицо. К чему это может привести? Автор статьи был свидетелем того, как разработчик заложил в схему прекрасно (на его взгляд) вписавшуюся в общую концепцию системы распознавания образов CMOS-матрицу. Винить его вроде бы и нельзя, матрица использовалась и ранее, была на складе компании, но такой мы уже не смогли больше купить даже у изготовителя и блок «зрения» пришлось переделывать заново.

Во-вторых, ни конструктор печатной платы, ни конструктор по общей компоновке не вник в тонкости спецификации (data sheet — англ.). В большинстве компаний это прерогатива инженера по схемотехнике. Как ни странно, но знаю по опыту, что конструкторы (в общем понимании этого определения) часто вообще не читают и не вникают в спецификации, тем более англоязычные. Максимум, что будет интересовать конструктора по печатным платам, — габариты корпуса и установочные размеры нового для него элемента. Конструктор по компоновке поинтересуется размерами разъемов, так как ему нужно предусмотреть под них выборки в корпусе. Несмотря на все реформы постсоветского образования, здесь сказывается недостаточное знание основного технического языка — английского, без которого любой инженер-разработчик скатывается до уровня ремесленника или, что еще хуже, любителя. Вероятно, причина еще и в том, что изменения в области конструирования не так динамичны и инженеру-конструктору не нужно все время быть начеку, как схемотехнику. Последний буквально каждый день получает информацию о новых радиоэлементах, открывающих более широкие возможности, и о новых технических решениях на базе этих компонентов. Их изготовители буквально заваливают его информацией, и все самое новое приходит на английском языке.

Что же касается конструкторов, то я, например, знаю прекрасного инженера по разработке печатных плат, до сих пор упорно работающего на версии PCAD-а из-под DOS (ему так удобнее), и талантливого конструктора старой школы, который мыслит только с карандашом, передавая эскизы технику для превращения их в нормальный вид через CAD. И это проблема не только конструкторов, есть такие специалисты и в области схемотехники, не использующие и не воспринимающие, скажем, возможности компьютерных симуляторов и программ для расчетов. Они до сих пор делают лишь самые общие прикидочные расчеты на калькуляторе, зачастую полагаясь на свой опыт, интуицию, и рисуют схемы от руки, а потом их уже «доводят» на макетах, теряя драгоценное время. К чему это приводит — примеры из практики.

Во время прогона изделия совершенно не прогнозируемо происходила аварийная остановка. Разработчики часами сидели с осциллографом, безуспешно пытаясь изловить импульс явно ложного сброса. Машина либо останавливалась, либо часами функционировала без сбоев, но как только «охотники» уходили, она, поработав, останавливалась. Причина оказалась в наносекундном импульсе, который возникал из-за задержки, вносимой в логические цепи транзисторным преобразователем уровня, в итоге он появлялся как команда reset. Это понимали, но вот откуда он лезет — не могли установить. Автор статьи, не прикасаясь к изделию, выловил его за час работы на симуляторе PSpice. Включение конденсатора в нужную цепь убило его навсегда. Поймать же импульс не могли, поскольку его «съедала» емкость щупа осциллографа.

Яркий случай, когда помог расчет, иллюстрирует другой пример. После замены документации усилитель (типа операционного, но на дискретных элементах) одного специфического и сто раз самым тщательным образом испытанного изделия начал возбуждаться. Проведенный мною расчет показал, что коэффициент усиления составляет порядка 50 000, что по заверению ведущего инженера явно превышало все разумные пределы. После анализа выяснилось: пропустили цепь общей отрицательной обратной связи по напряжению. Что мешало маститому ведущему инженеру провести расчеты, а не работать «методом научного втыка» при его приличной зарплате? Это уже пример внутреннего конфликта знаний исполнителя, его должности и оплаты. Мы часто, по доброте душевной, поступаем как японцы, закрывая глаза на деградацию старых кадров, прощая им многое за прошлые заслуги. Так, может быть, пусть они остаются и у нас, как «сидящие у окна», дают советы, а дорогу уступают молодым? Пусть молодые дерзают, набивают, как мы в свое время, себе шишки. Я в свое время не боялся брать на работу не только молодых специалистов, но и студентов старших курсов, которые потом весьма успешно трудились, поскольку уже были знакомы со всей кухней и не требовали времени на адаптацию. Есть конфликт поколений. Если бы новое поколение технарей было глупее предыдущего, то развитие техники остановилось бы, а мы видим обратное. Мы, инженеры 1970-х, начинали свой путь в радиотехнику, изучая в вузах радиолампы, а заканчиваем его, глядя на мощные микропроцессоры.

Вероятно, для уникумов игнорировать нынешние возможности вычислительной и измерительной техники допустимо, но современный инженер должен и обязан развиваться. Если специалист талантлив, то современный инструмент в его руках только увеличит отдачу от таланта и упростит жизнь и ему, и коллегам, ни в коем случае не умалив его заслуг. Логарифмическая линейка (кстати, в США последняя логарифмическая линейка была выпущена 11 июля 1976 года) — это не тот уровень, которым можно гордиться в 2014-м. Я ничего не имею против радиолюбителей как таковых, но инженер должен быть инженером, нельзя работать на интуиции и разовых решениях. Все должно быть выверено и, если что-то должно быть посчитано, — это необходимо просчитать. Это не займет много времени, но значительно его сэкономит. А при необходимости не полениться и, чтобы убедиться в повторяемости непонятного результата, создать математическую модель такого, вызывающего сомнения в его повторяемости процесса (в качестве примера из практики автора статьи в [2], а результат в [3]).

Но вернемся к проекту. Инженер-схемотехник выбрал решение на базе ИМС изолированного интерфейса, скажем, ADM3251E компании Analog Devices Inc. [4]. И это, несомненно, правильное решение, поскольку оборудование разнесено по цепям питания и «землям», соответственно, возникает проблема контурных токов и синфазных помех, все это при гальванической связи по цепям интерфейса может привести к печальным последствиям. Но выбранная ИМС имеет целый ряд специфических моментов, которые необходимо учитывать при ее применении. Например: высокая частота внутреннего генератора первой секции для целей питания, частота преобразователя напряжения второй секции, особые требования по разводке (layout — англ.), общему экранированию и т. п. Все эти моменты, чтобы не пугать потенциального потребителя, описаны не в первых абзацах спецификации, а в разделах, поясняющих работу выбранной для интерфейса ИМС. Согласитесь, специалисты именно в схемотехнике часто просто просматривают вспомогательные разделы спецификации на интересующие их элементы. Тут они больше полагаются на свой опыт и интуицию, не особо вникая, например, в тонкости разводки печатной платы («не царское это дело»), оставляя данный вопрос конструктору, который в свою очередь не является знатоком в вопросах схемотехники. Кроме того, мы часто слепо доверяем общим спецификациям, забывая, что имеются не менее важные документы типа руководящий материалов (Application Note — англ.), которые есть только на сайтах изготовителей элементов, а не на сайтах, дающих доступ к спецификациям типа www.alldatasheet.com. Хотя и их лучше тоже брать у первых или специализированных, в частности, на www.datasheets.com от UBM Tech (здесь есть даже такая важная опция, как сравнение спецификаций).

А какова роль руководителя проекта в описываемой ситуации? Здесь появляется еще один из частых конфликтов интересов — руководитель проекта, как правило, по такой «малозначительной» проблеме, как интерфейс, в лучшем случае сформулирует общую задачу специалисту по схемотехнике или согласится с его предложением, мол, давай дерзай, мне не до мелочей. Что же имеем в результате? Если не сформировать четкого задания перед конструкторами, вы получите печатную плату с ровными дорожками и аккуратно выстроенными элементами с обеспечением удобной пайки. Ведь в противном случае конструктор по платам услышит много «лестных» выражений от монтажников. Тут его прямой интерес и конфликт с интересами схемотехника и конструктора по общей компоновке. Так что есть шанс, что все это будет оптимально для «печатника», но не приемлемо с точки зрения общей конструкции. В частности, разъемы могут быть установлены неправильно или далеко не лучшим образом. Как результат, кабели будут перекручены, а их подключение в общей конструкции окажется крайне неудобным.

Могут возникнуть проблемы и конфликт интересов уже на уровне электрической части, в том числе с блокировочными конденсаторами, которые будут удалены от микросхем интерфейса, что может привести к нарушению работы ИМС и вызовет повышенный уровень электромагнитных и радиопомех. Могут быть нарушены требования по электрическим зазорам, а это понизит уровень изоляции. Может возникнуть даже такая ситуация, когда конструктор на плате самовольно, по привычке, подсоединит металлические корпуса разъемов — в нашем случае это разъемы типа DB9 — к общему проводу (подключение собственного корпуса разъема на схемах не указывается, там указаны только подключения контактов!). Что из этого получится, смотрим дальше.

Конструктор по «железу» уложит эту плату в подходящую, имеющуюся в наличии коробочку. Скорее всего, в пластмассовую, а не в металлическую, которая могла бы обеспечить экранирование. О чем, как отмечалось выше, сказано в спецификации. И тут его нельзя особо винить, поскольку закупать коробочку новой модификации или, что еще хуже, разрабатывать новую с учетом дорогого оснащения, грамотный и ответственный конструктор никогда не будет, указаний, что ставить, ему не дали, а спецификацию [4] (16 страниц английского текста) он не читал. Разъемы DB9 будут прикручены к корпусу, и если он все же металлический, то изолированный интерфейс уже изолированным не будет. Для внешнего подключения может быть выбран экранированный кабель, и экранированный корпус — для ответной части разъема. В этом случае даже при пластмассовой коробочке, работа интерфейса будет нарушена.

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

Для исключения ошибок, вызванных описанными выше различными конфликтами при разработке РЭА, на отечественных государственных предприятиях, где в свое время трудился и автор статьи, при выполнении проектов существовал принцип формирования ситуативных групп из специалистов разного профиля. В основу было положено дошедшее до нас в 80-х годах прошлого века «японское чудо» в области управления в виде «групп качества». Как минимум в них были специалист по схемотехнике, конструктор по печатным палатам и конструктор по компоновке. В некоторые группы включались дизайнеры, маркетологи, специалисты по текстовой документации (например, по техническим условиям, паспортам и пр.) и технологи. И все они могли одновременно работать в нескольких группах по разным проектам или привлекаться по мере необходимости (если это специалист узкого профиля, например по моточным изделиям, к нему обращались все группы). В административном подчинении все привлеченные к проекту работники оставались в своих подразделениях, что позволяло легко заменить выбывшего по тем или иным причинам сотрудника. Для этого по возможности и с учетом психологической совместимости создавались своеобразные тандемы-двойки из инженеров одного или близкого профиля.

Главным в группе назначался специалист исходя из профиля изделия — чаще по схемотехнике, поскольку речь шла о РЭА. Такой групповой принцип ответственности не только не вредил общему делу, но и помогал избежать ситуации типа «лебедь, рак и щука» и страховал от форс-мажорных обстоятельств, вызванных неожиданным отсутствием одного из специалистов. Положенный в основу организации труда принцип коллективности дисциплинировал исполнителей, заставляя их видеть поставленную задачу в целом, а не зацикливаться лишь на своих проблемах и решениях, забывая о сложности, скажем, технологической реализации или приобретения комплектующих. А чтобы руководителям как групп, так и проекта было неповадно прикрываться исполнителями, система дополнялась жестко действовавшим принципом: «Победа — это заслуга коллектива, поражение — вина исключительно руководителя». Таким образом, для руководителя проекта не существовало «малозначащих» деталей, вникать нужно было во все подробности, от схемотехнического решения до технологических вопросов и оснащения. Особенно это важно, если возглавлял группу специалист по схемотехнике. По своему опыту могу сказать, что такие специалисты склонны преуменьшать роль конструкторов, технологов и снабжецев.

Кроме того, обязанностью руководителя было соблюдение сроков проекта. Этому в большой мере способствовало и то, что существовали (столь нелюбимые многими руководителями) должностные инструкции и положения о подразделениях. В отлаженном механизме разработки каждый сотрудник, как солдат, должен знать свой маневр. Поверьте опыту автора — это гораздо удобнее, чем пытаться поймать рыбку в мутной воде неразберихи и хаоса. Да, это сковывает руководителя, уменьшает его значимость, но и облегчает общее руководство, поскольку известно, что и с кого можно и нужно спрашивать. И не надо бояться делегировать часть своих полномочий. Мне приходилось встречать и даже работать с горе-руководителями, которые своим авторитетом подавляли подчиненных, начисто лишая их самостоятельности в принятии решений, насаждая известный принцип «я начальник — ты дурак». Чем это заканчивалось? Мало того, что такой руководитель начинал работать один за всех, что многих подчиненных устраивало, но он не в полной мере выполнял свои прямые обязанности. В результате и работа над проектом страдала, и решения такого «проектировщика» оказывались весьма далекими от оптимальных (кто будет перечить, тут себе дороже: как говорится, хозяин — барин). Сроки же работ при этом постоянно срываются, все затягивается, и проект выходит или сырым, или уже никому не нужным.

Задача грамотного руководителя проекта — это не замена собой всех специалистов, в таком случае их можно было бы всех уволить, не так ли? Его задача — решение проблем организации работ, постановка общих вопросов, координация деятельности групп, выбор оптимальных вариантов, контроль, помощь группам в случаях, если возникают трудности, которые они не могут сами преодолеть, своевременное привлечение нужных специалистов или дополнительных сил и средств. Но главное, повторюсь, контроль, контроль и еще раз контроль. Причем не придирчивый и мелочный, превращающий работу подчиненных в ад, а помогающий и предотвращающий вероятность каких-либо срывов. Автор статьи, например, практически полностью исключил у себя нудные общие технические совещания. Работа группами позволяла решать возникающие вопросы минимальным количеством ведущих специалистов (руководителей групп) или делать это в режиме одной группы. Согласитесь, намного проще и эффективнее руководителю пройти по группам и получить нужную информацию, чем отвлекать от работы всех исполнителей, занятых в проекте. Например, зачем специалистам по печатным платам тратить время и слушать о проблемах в схемотехнике, а схемотехникам — о проблемах в выборе гальванического покрытия для сборочной единицы?

Взаимодействие по вопросам проведения НИОКР и внедрению новой техники на уровне подразделений завода регламентировал разработанный автором статьи стандарт предприятия — СТП «Порядок разработки конструкторской документации и постановки на производство продукции». В его основу был положен алгоритм принятия решения (рисунок), неожиданно увиденный им в [5] и поразивший свей элегантностью и универсальностью.

Рисунок. Алгоритм принятия решения о запуске изделия в производство

Этот алгоритм, выполненный в виде плаката c девизом «Совершенство и красота заключаются в простоте», украшал общий зал, в котором находились разработчики. Может, это и из псевдонаучной области, но, по мнению автора статьи, красивые и простые решения, как в части схемотехники, так и конструкции работают и лучше и надежнее. Конечно, нельзя уподобляться известному промышленнику Эрлу Мюнцу по прозвищу Безумный [6], который выкусывал кусачками из телевизоров «лишние» на его взгляд элементы, но и думать о красоте технических решении проектируемого изделия никогда не помешает. Позднее упомянутый стандарт в виде СТП ЯГ0.091.441-99 стал основой системы управления качеством продукции предприятия и позволил легко пройти сертификацию по ISO-9001.

Вводился он не без проблем, так как ломал устоявшиеся годами традиции, уменьшая количество контролирующих и увеличивая количество участвующих в процессе разработки и внедрения новой продукции. Самым революционным изменением стала передача функций серийного сопровождения с правом внесения изменений в КД в техническом бюро сборочных цехов (им в штат добавили конструкторов). Это освободило разработчиков от сопровождения серийных изделий, устранив еще один конфликт интересов, и начисто уничтожило такое явление, как пресловутый конструкторский вопрос (пример в [7]), особенно часто возникающее в цехах в конце месяца. За разработчиками остался авторский контроль, а решающее слово в корректировке документации — за главным конструктором, которому были передана часть полномочий главного инженера. Так был устранен еще один конфликт, поскольку главный инженер не всегда мог оценить изменения в связи с загруженностью техническими вопросами обеспечения деятельности предприятия.

Для работы над проектом внутри коллектива основных специалистов была сформирована и действовала универсальная система в виде сетевого планирования. Ее основа — определение необходимых этапов разработки и оценка ожидаемых затрат времени на выполнение работ. Поскольку имелся большой опыт создания изделий разного профиля (от систем многоканальной связи с уплотнением каналов до скобяных изделий), сроки основывались на аналогии. Как правило, это помогало. А вот для оценки трудоемкости и себестоимости конечного изделия успешно использовался метод удельных весов, обычно за основу бралась стоимость комплектующих (она очень легко просчитывается) и по этому показателю велось прогнозирование экономических показателей проектируемого изделия по близкому серийному аналогу. Таким образом удавалось избежать конфликта интересов между разработчиками, изготовителями и экономистами.

Во всех без исключения проектах обязательно придерживались двух пунктов (рисунок). Во-первых, это подбор стандартов, под которые подпадает новое изделие. Работа выполнялась в тесном взаимодействии со службой стандартизации, чтобы потом не обнаружилось что-то неучтенное и не отбросило проект назад. Во-вторых, поиск решений по данной теме, чтобы не изобретать велосипед, а по возможности довести его до кондиции в нужном ракурсе. На первый взгляд это воспринимается как само собой разумеющееся. Но вот пример из моего опыта. Придя уже на совместное предприятие, я принял участие в разработке изделия для поставки на европейский рынок. Сложное в техническом плане устройство было практически завершено, но тут вдруг узнали о Директиве RoHS [8]! В результате столь позднего «узнавания» пришлось фактически заново проектировать изделие и приобретать новые комплектующие, соответствующие требованиям Директивы. А это срыв сроков, который вышел нам боком, и дополнительные затраты, сократившие наш заработок. Единственное, но слабое утешение, — новый вариант был лучше прежнего. К сожалению, и это достаточно частое явление, разработчики не утруждают себя предварительным изучением стандартов, занимаясь более приятным для них процессом — творческим поиском. Это тоже конфликт, но другого уровня.

Есть еще два важных принципа успешной разработки. Первый — «для нового изделия разрабатывается только то, что нельзя купить». Действительно, никому в голову не придет создавать, например, собственный операционный усилитель или триггер, но вот стремление «слепить» оригинальный блок питания сомнений почему-то не вызывает. А уже потом вспоминают о проблемах при его сертификации. Второй принцип: «лучшее— враг хорошего». Он действует в соответствии с известным постулатом «разработку нельзя закончить, ее можно только остановить». Это не значит, что нужно без критики принимать все предложенное группами. Истина рождается в споре. Но здесь, по сути, два конфликта. Многие, думаю, встречали на своем веку разработчиков, которые не могли остановиться в принятии окончательного решения. Одни просто боялись это сделать из-за нерешительности и неуверенности, а другие находили все лучшее и лучшее. Если первых нужно просто убирать (у них нет знаний), то результат творческих мук по улучшению улучшений тоже хорошо известен: сроки работ срываются, а проект уже становится никому не нужным. Так что здесь свою роль должен сыграть руководитель проекта и в нужный момент сказать «стоп!», оценить варианты, выбрать оптимальный или приемлемый, прекратив творческие изыски. Второй конфликт возникает, когда руководитель чересчур ревниво относится к идеям исполнителей, действуя по принципу «начальник всегда прав». Например, в изделии нужен генератор. Его функция — сформировать сигнал определенной частоты, и иногда формы. Что важно: схема генератора или получение нужного сигнала? Я был свидетелем ситуаций, когда подобные вопросы решались неделю в жарких спорах, поскольку руководитель проекта в ущерб делу ломал исполнителя, доказывая ему, кто тут начальник, а кто… Такие конфликты опасны тем, что исполнитель, если у него тоже есть амбиции и он видит всю глупость ситуации, найдет себе более умного руководителя. (Это все из серии конфликтов типа «я начальник — ты дурак».) Здесь слово за вышестоящим руководством, его задача — не допустить подобного. Ценить нужно не самовлюбленного руководителя, а коллектив. Иногда такого руководителя могут вольно или невольно просто подставить, для науки. И это еще один тип конфликтов — несовместимость с функцией руководства, граничащая с некомпетентностью самого руководителя. Человек может быть посредственным инженером, но прекрасным администратором, использующим возможности коллектива на 100% и даже более. Разве импресарио певца должен тоже быть вокалистом, к тому же лучшим, чем его подопечный? Конечно нет. Но почему это считается незыблемым для разработки? В то же время прекрасный инженер может оказаться нулевым руководителем. Мне приходилось встречать и тех, и других. Первый, кстати, помог мне сделать успешную раннюю карьеру, рискнув поручить (еще и не члену КПСС, кто жил при СССР, тот понимает!) КБ, введя в высокие кабинеты министерства и предоставив возможность проводить эксперименты в области не только техники, но и управления. А вот второй, в конце концов, фактически развалил успешное и многообещающее предприятие, создав при этом огромные долги по зарплате.

Еще один важный момент, в котором решающее слово остается за руководителем проекта, — испытания. Здесь тоже не без конфликта интересов. Перефразирую известное умозаключение: испытаний никогда не бывает мало. Чем больше потрачено сил и времени на проведение испытаний в ходе проектирования, тем меньше вероятность, что разработчик будет сидеть с умным видом у заказчика или в цехе-изготовителе и, извините, вешать лапшу на уши, при этом думая, как бы побыстрей добраться до лаборатории и начать исправлять содеянное. Важно, чтобы испытания не были хаотическими и давали достоверный результат — не тот, который хочется, а тот, который есть. Лучше когда их проводит независимое лицо, а не заинтересованный в положительном итоге исполнитель проекта. В системе автора статьи, оптимальность в этом вопросе достигалась стандартом предприятия. В нем нормировалась программа испытания и конечный документ — протокол. Кроме того, было установлено, кто и на каких этапах проводит данные испытания.

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

Насколько важны испытания и их правильная методика, как на стадии проектирования, так и при внесении изменений в серийный проект, можно показать на нескольких примерах, участником или свидетелем которых был автор статьи. Вот пример неправильной методики. В мощной звуковоспроизводящей установке использовался дорогой выходной трансформатор собственного изготовления. Ведущий инженер по сопровождению изделия совместно с некоторыми руководителями (знакомая практика проталкивания рацпредложений?) подал рационализаторское предложение по замене этого трансформатора дешевым покупным, но не звуковым, а сетевым. Типовые испытания были проведены и подтвердили возможность такой замены. Однако начался массовый выход из строя оконечных транзисторов. Причина оказалась в том, что наработка установки проводилась не от генератора, а от источника реального звукового сигнала, нижняя частота спектра совпадала с частотой последовательного резонанса колебательного контура, образованного индуктивностью «нового» трансформатора, и разделительным конденсатором. Но на испытаниях проверку делали только в заданной согласно ТУ от генератора и только рабочей полосе частот.

Еще пример, положительный. Один из руководителей завода узрел в блоке управления, установленном на колесную технику, «лишнюю» дорогую деталь (массивное основание) из алюминиевого сплава. Приказ был краток — убрать, заменить! Автор статьи настоял на типовых механических испытаниях (изделие находилось в его юрисдикции, и его слово было решающим). Дело в том, что такие изделия испытываются не только на удары, но и на резонансы в полосе частот до 100 Гц. На глазах испытателей «улучшенное» волевым решением изделие буквально разнесло вдребезги на появившемся резонансе.

Пример на тему оптимального количества образцов. Будучи начинающим специалистом, автор статьи переработал плату чувствительного усилителя. Проверка показала прекрасные результаты, отношение сигнал/шум было значительно лучше, чем у прототипа. Плате дали добро в серийное производство. Но ни одна из первых семнадцати серийных плат не была работоспособной из-за самовозбуждения. Плата была размером примерно в лист формата А4, ее опытный образец автор статьи собирал сам, делать несколько таких плат ему было просто лень. И проблема оказалась именно в разводке платы, она нормально работала только с первым комплектом деталей и более ни с каким работать не желала! После этого я дал себе зарок: никогда не испытывать менее пяти опытных образцов, что и было закреплено в разработанном стандарте.

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

В личном бизнесе автора руководители групп имели в своем распоряжении определенные средства на поощрение, но не могли использовать их в своих целях: им поощрения выдавали вышестоящие руководители. На предприятии через отдел труда и заработной платы было проведено положение о поощрение разработчиков на основе системы КТУ (коэффициентов трудового участия). Это устраняло уравниловку и сводило на нет даже попытки паразитизма. Можно сказать, что известный социалистический принцип Пьера Прудона «от каждого по его способностям, каждому — по его труду» реализовывался достаточно полно. Хотя советскому социализму, да и текущей ситуации больше свойственен другой принцип «от каждого по потребности (максимально), каждому — по возможности (минимально)». И это еще один конфликт интересов, причем очень сильно влияющий на производительность и психологический климат в коллективе. Несправедливая оплата приносит огромный вред, она источник явного и неявного саботажа. И если с явным еще можно как-то бороться, например, уволить работника, то с неявным — очень проблематично; причем это заражает если не весь коллектив, то его большую часть, всплывают забытые обиды, и тут уже не работы. Чтобы избежать конфликта и злоупотреблений, в комиссию по распределению на предприятии (в частных структурах в этом нет необходимости — тут все на свой риск решают руководители и собственники, а доходы исполнителей должны быть скрыты) был включен представитель профсоюза, но руководитель проекта имел право вето на выплаты. Кроме обычных выплат основные разработчики, а не только руководители, как это обычно практикуется, получали в течение двух лет определенный процент от реализации разработанных ими изделий, что оформлялось как рацпредложение по внедрению нового изделия. Обычно хороший разработчик в квартал, кроме премиальных, получал еще один дополнительный оклад, как минимум. Мой совет: лучше платить работникам честно и вовремя. Если вы понимаете, что это невозможно сделать в текущей ситуации, то лучше сразу предупредить работника(ов), а не заводить дело в тупик. Если это делать открыто, то люди, как правило, понимают и идут навстречу. Ведь можно подумать и предложить разумную компенсацию, не всегда материальную, а например, гарантировать отпуск. Поймите, вы собственник и отсутствие средств на оплату труда — это ваши проблемы, а не наемных работников. Если вы видите вину работника, то можете его уволить, нанять другого более квалифицированного, но вас работники уволить не могу. Инженерные коллективы, как правило, не прибегают к открытым забастовкам, как рабочие, которым, по определению К. Маркса, нечего терять. Если эту статью читает исполнитель, попавший в ситуацию «задержка выплаты заработной платы», — увольняйтесь, лучше ужасный конец, чем ужас без конца. В такой компании нельзя продолжать работать. Как грамотно уволиться и вернуть все невыплаченное и с компенсацией, вам подскажет юрист, тут есть, как проучить нерадивого работодателя.

Для исключения внутригрупповых конфликтов члены групп максимально подбирались с учетом психологической совместимости. Играть на амбициях и противоречиях оказалось непродуктивно. Конкуренция давала лишь краткосрочный эффект, а потом начинались конфликты, и работа стопорилась. Для оценки пригодности к проектным работам исполнители, кроме проверки технических знаний, проходили тестирование на общий IQ (использовался IQ-тест Айзенка [9]). В частности, из новой группы молодых специалистов была выделена девушка с обычными в подобных случаях техническими знаниями, но с очень высоким IQ, которая впоследствии стала ведущим специалистом по источникам питания, да и потом ее техническая карьера оказалась более чем успешной. При другой организации работ она традиционно занималась бы бумажками, а так была и сама очень удивлена предложением попробовать себя в разработке.

Кроме ясной и понятной организационной системы, повышению производительности способствовало обеспечение разработчиков современной вычислительной техникой, средствами измерений и испытаний, имелась своя макетная мастерская, были организованы постоянно действующие (не на бумаге для галочки) курсы повышения квалификации. Лекции были обязаны читать все ведущие специалисты (велись в рабочее время и дополнительно оплачивались). Это помогало осваивать новые знания и лекторам, и слушателям. Согласитесь, для того чтобы прочитать лекцию, нужно сначала самому детально разобраться в сути вопроса, а тут ведь придется выступать перед коллегами-специалистами. Одно время была даже спортивная комната, но «доброжелатели», дошедшие со своими кляузами до генерального директора, добились-таки ее закрытия. Для создания уютной атмосферы были сделаны некоторые поблажки в части режима: полчаса не считалось опозданием, попить чаю или кофе разрешалось когда угодно, можно было день-два просто не выйти на работу, поработать дома или решить какие-то свои вопросы. Распечатка десятка листов своего текста на принтере или ксероксе преступлением не считалась, можно было и что-то свое смастерить, просто поставив руководителя в известность. Они и так бы это сделали, но тайно, нервничая и оглядываясь по сторонам. Таким простым путем устранялся еще один конфликт, назовем его «тупой дисциплины ради дисциплины», и возникала ответная доброжелательная реакция работников на просьбу помочь или поработать сверхурочно. Могу привести пример, как это решается не у нас. У меня был хороший знакомый — начальник цеха из Южной Кореи. У него в цеху, как это бывает и у нас, «пропадал» инструмент. Он поступил просто: купил (им выдаются деньги на такие непредвиденные расходы) несколько наборов инструмента и раздал рабочим. Конфликт исчез, больше цеховой инструмент «на дачу» не уносили.

Единственная проблема, по которой так и не было найдено оптимальное решение, — всем известные «дни рожденья», отмечаемые на рабочем месте. Тут есть конфликт спаивания и «спаивания» коллектива. Автору статьи «спаивания» не нравилось, но приходилось мириться, введя этот процесс в максимально нерегулярный режим, и того хуже, пользуясь своим положением, иной раз самому проносить через проходную (предприятие было режимным, с разрешением обыска работников охраной) известные напитки, чтобы подчиненные не попались. Но вот любители зеленого змия (на заводе спирт был легко доступен) изгонялись мгновенно.

В итоге хочу отметить, что далеко не все были счастливы от работы в описываемой системе, особенно это касалось специалистов со стажем, привыкших работать по старинке и инженеров без инициативы. Поэтому не буду кривить душой. Но, и это самое главное, количество ошибок, вызванных нестыковкой и конфликтом интересов разработчиков, благодаря описанным подходам было сведено к минимуму, а сроки разработки достаточно сложных проектов сокращены с полутора лет до рекордных шести месяцев. Важен и еще один конфликт в виде «роли личности в истории». После трагической гибели генерального директора предприятия, который поддерживал инновации, пришедший на его место решил обойтись без подразделений разработки, уж очень это ему показалось хлопотным и затратным делом — это же накладные расходы! Так, уже после моего вынужденного ухода с предприятия описанная система, поработав какое-то время по инерции, позволила создать последнее технически сложное изделие. А затем была уничтожена вместе с инженерным центром, его уникальным коллективом и школой разработки. Несколько позже и само предприятие тоже постигла печальная участь. Тут уж, как говорится, ломать — не строить.