ДВОЕ ИЗ ЛАРЦА, Квалификация исполнителей. Качественный программный код. Опции

[Hirer]

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

Я — заказчик. Проект небольшой – 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. Спасибо за терпение, проявленное при прочтении текста выше

[Kabdim]

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

[iosifk]

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

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

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


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

[Tpeck]

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

А где можно почитать о подобном организации рабочего процесса?

[iosifk]

А где можно почитать о подобном организации рабочего процесса?

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

PS. Фраза о том, что "Так и не убедил программиста сделать детальное логирование в десктоп-приложении
для последующего анализа." говорит о том, что и этот "программист" не умеет делать промышленные изделия, ни тем более "руководитель работы" ничего более настольных игрушек не делал. Правда, кода мы делали "заправки", то нашим программистам и системщикам потребовалось всего около года, чтобы тесты ввести в состав "боевого" ПО и иметь возможность ими пользоваться штатно во время работы с изделиями... А для этого пришлось "пробивать" наше начальство и приемку заказчика... Как говорится, никаких личных обид, просто констатация фактов. Я уже привел пример про "переходный процесс"... Так вот, стандартная "планка" - 95% и 3 "тау".. Или опыт работы 1 год. (1 "тау" - это поморгать светодиодами на лабораторной на 3-м курсе) Это скажем так, специалист для ширпотреба. Посчитайте, сколько "тау" и какой опыт работы нужен для 99,9% хотя бы... Уж я не говорю про "ответственные" применения... Лет чуть более 15-ти назад я пришел работать в ЛОНИИС и там рассказывал сослуживцу о том, как велась отладка систем на "заправке"... А он был всего лет на 5 младше меня. И он рассказывал мне, как он героически на кафедре русифицировал ПЗУ в принтере...
К сожалению, сейчас мало "больших" проектов... Дальше понятно... Увы...
Вот, кстати военные все в одной форме ходят, но чтобы отличить кто круче, носят погоны. У девочек нет погонов, но есть сережки. И сразу видно, кто и что носит... А инженеры не имеют ни того, ни другого. Хотя у кого-то кандидатские, но теперь и это не показатель.. А уж термин "преподает" и совсем не дает хороших эмоций...

Ладно, много народу в этой ветке, допишу еще...
По поводу этого: "Но ТЗ детального не было (к сожалению)."
Я веду занятия по ПЛИС, чтобы не "засохнуть"... И довольно много времени уделяю описанию формализации начала проектирования.
Задания, алгоритмы, описания, стиль и наименования сигналов.
Вот пример. В сети поищите по фразе "Часы на ПЛИС"... Будет прорва текстов и фоток. Но "прикол" в том, что я знаю как минимум 3 варианта с разной архитектурой. В сети 70% - это первый вариант. 30% - второй. Третьего варианта нет вообще... А ведь "цена ошибки" в начале проекта составляет 100% и падает почти до нуля к концу проекта. И вот все это обсуждение в этой ветке на самом деле не обсуждение плохих работников, а обсуждение неправильной методики ведения проекта.

Все... Удачи всем!

[Hirer]

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

В точку.