Добрый день !
Хочется спросить совета у форумчан по одному вопросу, хотя не совсем уверен, что выбранная тема четко соотносится с ним.

Я — заказчик. Проект небольшой – ATmega168 + PCF7991, пара реле, пара ключей и десяток входных сигналов (логика). На выходе должен появится работающий образец в предфинальном варианте для запуска в серию + вся исходная информация.
Исполнителей двое, электронщик и программист. С каждым из них - своя история взаимодействия.

При отправке ПП на изготовление выяснилось, что все проводники на плате были сделаны не трассой а графикой (линии), которые естественно нормальному редактированию не поддавались. При увеличении была заметна небрежность — нахлесты, несведение в точку и т.п. Ну и апофеозом всего — невозможность автоматической проверки корректности дизайна платы в контексте правил разводки (DRC ). На мой вопрос «почему так» было сказано, что Altium в котором он работал с очень ограниченной лицензией и по другому никак ... Потратив несколько часов на обзор и вникание в имеющейся доступный софт, был сделан выбор в пользу DipTrace. Цена вопроса - 10 тыс.р (1000 выводов, 4 слоя). Плата была переделана в приемлемый срок и с надлежащим качеством. Пре передаче в Резонит выяснилось, что теперь формат DipTrace в качестве входного не принимается.
На мое указание транслировать проект в гербер и сверловку, электронщик заявляет, что это работа технолога и ничего в этом случае гарантировать не может.
Пришлось делать самому, заняло примерно пять минут с проверкой полученных герберов сторонним вьювером. Из Резонита все пришло как задумывалось и без вопросов.

Программист ... Тут сложнее — ломаный IAR. Попытка разговора в стиле «ай-яй-яй, а давай делать в Atmel Studio» (4.18 например) не привела ни к чему. Хотя изначально было сказано, что проект будет развиваться и необходим грамотный и качественный подход к проектированию и железа и софта. Ну Си он и в Африке Си, махнул на это рукой, запланировав по окончанию этой фазы переехать в студию за короткое время.
Наконец пришло время тестирования полученного образца. Детали описывать не стану. Выяснилось, что устройство при провалах питания ведет себя непредсказуемо, но чаще всего намертво «зависает». Посовещавшись пару дней и проводя какие-то эксперименты ими было заявлено, что это «плохие» микроконтроллеры ... - Не вопрос, - сказал я и приобрел с десяток ATmega168 из разных мест и партий. Снова испытания и проверки, но — безуспешно. На мой вопрос «а включен ли внутренный BOD?» было бодро ответили - «пробовали по всякому, ничего не помогает» и предложили - «а давайте на вход по питания поставим отсечку», чтобы ниже 8 вольт устройство просто отключалось.
Время поджимало — снова махнул рукой (зря) ... Прошло несколько дней на протяжении который электронщик как в старые добрые времена СЮТов взяв в руки паяльник плодил вариант за вариантом схему, приговаривая «вот уже почти ...»

Делать мне было нечего и я взялся чтение классики и истоков. Изучив варианты построения схемотехники UVLO (under voltage lock out) и внимательно почитав datasheet на микроконтроллер решил взять инициативу в свои руки ...
На моем рабочем столе помимо компьютера разместились : опытный образец, программатор, паяльная станция и лабораторный источник питания. Получив по запросу от программиста исходный код и прошивку (IAR я не устанавливал) взялся за тщательную проверку всего и вся. Собственно все заняло минут десять. За это время я убедился, что fuse bits прошиты мягко говоря странным образом. На вопрос «Это правильно?» был четкий ответ - «Да ! У нас так все устройства работают».
Пришлось распечатать нужные страницы даташита и попросить пояснить наглядно. Случился таймаут по окончании которого мне было выдано две разные версии с новыми комбинациями и «пояснениями» в стиле «а можно и вот так» ...
Я пригласил грамотного специалиста который мне шепотом сообщил, что ошибка на самом деле на генетическом уровне. Им же аргументировано объяснил, что все не так, как они себе представляли и нужно просто вдумчиво читать документацию, т.к. там все-все написано. Закончив объяснения он запрограммировал fuse bits как нужно. Устройство перестало себя вести неадекватно на что программист заявил, что он — программист а не железячник и эти конфигурационные биты не его проблемы. Электронщик в ответ показал пальцем на программиста ... Еще не занавес.
Напоследок я потратил пару часов на анализ исходного кода (лучше бы я это не делал).
Вновь не стану описывать увиденное. Сообщу только одну деталь (программная реализация SPI – это мелочи) — сбросов watchdog-а я насчитал целых 70 ! ...
На высказанное мое недоумение был ответ «Ну работает же!» ©
Занавес ...

А теперь собственно суть вопроса.

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

P.S. Спасибо за терпение, проявленное при прочтении текста выше

Я так понимаю, никаких промежуточных точек приемки кода и схемоты не было? Ведь если бы были, то проблемы обнаружились бы еще на начальных этапах.

А по Вашему вопросу: надо вести какую-то историю разработки, периодически делать промежуточную приемку и верификацию наработок. Технически это можно сделать с помощью чего угодно: баг-трекер (например, redmine), CVS-ка (тот же hg). Без этих процессов у вас не будет концов - и вы не сможете увидеть где косяк зародился и, соответственно, кто в нем виновен.

Сменить программиста. С уважением, ваш КО.

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

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

Живут же люди! Атмеги в 4 слоях разводят.

Примерно так же, как добиться от музыканта попадания в ноты.

OFF: Не могу не вспомнить прогрессивные методы воспитания:
https://www.youtube.com/watch?v=eRbAKoGSods

Поддерживаю это высказывание.
Мало того, я бы сказал, что эту ситуацию Вы сами и спланировали заранее.
Было ли составлено подробное ТЗ?
Вы довели до исполнителей ДОКУМЕНТ, в котором бы было написано, ЧЕМ ЗАКАНЧИВАЕТСЯ (какими документами и файлами) их работа?
Был ли составлен алгоритм программы и был ли он согласован с Вами, как с заказчиком? И кто его разрабатывал? Учли ли там неправильные ситуации?
По каким критериям Вы брали на работу исполнителей? Какие документы они выставили в подтверждение своей квалификации?
Кто из вас несет ответственность за применение "ломаный IAR"? Где гарантии, что он будет работать правильно?

Есть еще вопросы о методах управления подчиненными. И их тоже достаточно.
Ну например такие:
Как Ваши подчиненные отчитывались о том, что сделано за определенный период времени. Например, в частной зарубежной фирме, где я работал, у каждого исполнителя была рабочая тетрадь, как на военной кафедре. Т.е. прошнурованная, с полями, с пронумерованными страницами. Все расчеты, осциллограммы, все абсолютно записывалось и приклеивалось. А руководитель темы проверял раз в день или раз в 2 дня. Хозяин проверял раз в неделю... Вот Вам - ISO9001 со всем его звериным оскалом..


Ну вот таких вопросов много. Хотите больше - могу по скайпу голосом поговорить.

Вы все сделали правильно.
Только так и можно было действовать.
Надо обращаться к сторонним программистам и разработчикам. Чтобы разобрались и объяснили.

Да дорого. Но это стандартная практика.
Был много раз в таких проектах.
За поиск и прочтение вслух нужного места в даташите разработчику заказчика беру недорого, всего 100 Евро.

Вот был случай
 Bad_PCB.JPG ( 253.3 килобайт ) Кол-во скачиваний: 243


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

Естественно у него оказалось, что все массивы переходных под силовыми транзисторами замыкали землю и питание. Несколько сотен переходных!
И он их всех вручную высверливал чтобы убрать замыкания! Пару месяцев.

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

За месяц и круглую сумму заказчику все было переделано.

На мой взгляд наиболее типовая ситуация из наиболее типовых - поясню:

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

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

Перед тем как резюмировать, позвольте пару вопросов:

1) А что за Альтиумм такой который платки рисует нередактируемой графикой?
2) Ради интереса- можете привести хотя бы скриншоты наиболее удивительных перлов на плате?
3) Почему вы думаете что человек который объявляет себя экспертом, но не может купить себе лицензионный софт, таковым и является?
4) Вы спрашивали подробное портфолио у тех персонажей?

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

Можно поставить SVN и требовать ежедневных коммитов не только кода, но и всех сопутствующих документов.
Кстати, недавно обнаружил случайно, что евоный diff может не только код, но и офисные документы разруливать.

И я того же мнения. За все отвечает руководитель. Хотел халявы, получи.

Cтандартная ситуация для "лимонадных" проектов. Отсутствие многих компетенций с обоих сторон.

Я наверное не совсем корректно выразился. Редактируется конечно. Но все соединения - наборы отрезков приставленных друг к другу.
Где гарантия, что после редакции ничего не сдвинется. Повторюсь - DRC не работает в этом случае, т.е. гарантий никаких.



Конденсаторы на кварц тоже не ставят. Аргумент тот же - "и так работает".

Сообщение отредактировал Hirer - Jul 1 2016, 08:44

Это не альтиум а скорее всего пикад. Тогда случай клинический совсем



Да да, это "их" ответ на абсолютно любой вопрос.