Короче был случай, "Карши Нефть" это Узбекистан под Бухарой. Вода два раза в день по 15 минут. Работают они там на старом оборудовании как негры, но нефть есть и ее много. Руководство решило навести порядок в деле учета нефти. Прислали нас, это начало 90х, сделать им базу данных учета добытой нефти. Как положено начали со сбора первичной информации. Главный инженер, суровый узбек, по сути местный хозяин тайги, посмотрел на меня зеленого тогда, невзлюбил и пренебрежительно отнесся к делу выдачи информации. Хорошо хоть не закопали меня тогда, а могли без вариантов. И никто искать бы не стал
Дал мне абы кого из местных в помощь, а те в соответствии с указаниями давали информацию абы какую. Через две недели я понял что учета нефти там никакого. То есть погрешность ошибки (!) двенадцать тонн нефти в день!!!
Короче, забахал я ему базу данных в соответствии с полученными данными и рассчитал ему расход, приход и прочие дела.
Главный инженер посмотрел на результаты и говорит "фигня твоя программа, я знаю реальные цифры они вообще ничего общего не имеют с твоими результатами". Я ему в ответ "исходные кто давал? Компьютер не волшебная машина, он точно посчитает но только то что ему дали, и если результат неверный, значит все исходные брехня". Ну и рожа у него была. Но одно он понял, компьютер не волшебная машина. Видимо до того момента он думал по другому

Даже в наше время много из начальства кто так думает.

Добрый день !

Тут нарисовалось небольшое продолжение истории. Пришли новые печатные платы.
Они производят монтаж. И присылают по почте фотографии с претензией - "платы некачественно сделаны", "непромыв и непротрав" ©
Мне просто любопытно - я один все это не вижу ?









Я так понимаю, лучше перед передачей ПП - все их обозначить и "поименно" сфотографировать ?
После пайки сложно что-то доказывать.

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

Давайте формулировать мысли по-русски, так что бы все их понимали. Например так:
"Производство печатных плат было заказаны в организации А, на монтаж они были отданы в организацию Б. Результат после монтажа - на фото. Правильно ли я понимаю, что брак есть и в самих платах (смещена маска), и при монтаже(непрогрев, всё засыпано не смытой паяльной пастой) ? Верен ли вывод, что организации А и Б виноваты в равной мере ?"

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

Вот фрагмент одной платы из партии ...

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


Есть закон: "Любая задача выполняется на столько же хорошо, на сколько чётко она формулируется"
Я-то сам свои мысли научился излагать понятно для окружающих не для того что бы общаться на форуме, а для того что бы грамотно писать ТЗ и договора .

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

Проблема в том, что Вы пока не видите своих ошибок, и у Вас слишком мало опыта в том деле, за которое взялись.
Но это дело наживное. Ещё 5 тыс вёдер с десяток проектных циклов, и золотой ключик... вопросы почти исчезнут.
Другой вопрос, что все вопросы не исчезнут никогда, но Вы научитесь искать на них ответы. Или не научитесь, и тогда лучше заняться чем-нибудь другим.
Короче, Вам просто следует подумать, как выстроить технологическую цепочку, а потом попытаться её реализовать.
И не заморачивайтесь пока на тему SVN, ISO-9000 и т.д. Это просто инструмент, который может быть полезен, а может и мешать. Вашу голову он не заменит.
Именно ваша голова должна уметь формулировать задачи, определять/находить подходящих специалистов, изготовителей ПП, монтажников и т.д.

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



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

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

Доброе утро !
Страна у нас большая разброс в уровнях трат-зарплат еще больше.
Есть и официальная точка зрения Зарплаты 2016
Цена разработки - есть компромиссное решение обоих сторон. Это - главное.
Договорились - пожали руки. Заложили даже 15% аварийный запас сверху.
С моей стороны все было выполнено.
Сейчас работаю над детальным ТЗ на новый проект. Скелет примерно такой :

1 Общие сведения. Плановые сроки начала и окончания работ.
2 Назначение и цели проектирования "___"
3 Состав "___"
4 Требования функциональные и специальные (в т.ч. - инф. безопасность)
5 Технические характеристики.
6 Состав и содержание работ по проектированию "___".
7 Состав и содержание работ по реализации и вводу "___" в действие.
8 Требования к документированию. Состав разрабатываемых документов.
9 Порядок контроля и приемки.
10 Нормальные условия эксплуатации. Требования к квалификации персонала.
11 Календарный план.
12 Допущения и ограничения
13 Риски
14 Глоссарий (словарь терминов и определений)

Ну, ТС много чего не раскрыл.
Но что верно, то верно. Финансовый вопрос чаще всего оказывается тем критическим фактором, который тянет за собою всё остальное.

Попытаюсь подсказать ТС в этом вопросе:

1) То, что изготовление печатных плат организует сам ТС, а не разработчик, косвенно указывает на то, что гонорар разработчика сопоставим со стоимостью изготовления плат, такие суммы на языке экономистов обозначаются термином "на пиво для студента".
При правильном подходе разработчик должен заказывать и платы и комплектующие и монтаж сам, оплачивая из своего кармана. Так он автоматически несёт ответственность за результат, и ему становится невыгодно ошибаться в Gerber_ах . А что бы разработчик мог работать в таких условиях, его гонорар должен в 10-100 раз превышать стоимость плат с монтажом и комплектующими.

2) Разработчик, способный сам всё грамотно спроектировать без помощи и контроля более умного спеца, выдать на выходе грамотно оформленный комплект документации - это человек с компетенцией "руководитель проекта" или "руководитель отдела". Звучит пафосно, но попробуйте аргументированно не согласится. А дальше сами смотрите их уровни зарплат, требования к работодателям, процентную концентрацию таких спецов в общей массе....

Пару лет назад, тут один товарищ хотел мед. тренажер. Когда ему объяснили, что нужно сперва ТЗ, он согласился , но был готов заплатить за него $200 . Не знаю, здесь ли он нашел ТэЗэписателей или где еще, но смысла за него платить вообще не было . Самого важного в нем не было , зато было много бессмысленной фигни и напоминало диплом , за ту же сумму. Так что не знаю сделали ему этот аппарат , какие- нибудь "ДВОЕ ИЗ ЛАРЦА" или нет , "но желаю вам друзья не бывать там никогда. Пусть туда враги наши идут." (с)

Разумеется, написать вменяемое ТЗ может только спец уровня "руководитель проекта", как я уже объяснил выше.
И всё это должен быть один спец, а не много разных. Потому что во-первых много разных хороших спецов собрать в одном месте- очень сложно и затратно, а во-вторых зачем на одну 2х слойную плату больше одного ?

Методика Agile отрицает всякое ТЗ.

Невнимательно читали. Методика Agile подразумевает, что рабочая группа уже знает что и как делать. А откуда эта самая рабочая группа узнает об этом - не регламентируется.
Ну и ни разу не видел, чтобы с помощью Agile сделали рабочее встроенное ПО. Сайтик ресторана написать, где, если что заглючит - то позвонить можно или страничку перезагрузить - это одно. А устройство, к которому нет доступа - это другое.

Что я невнимательно читал?
Мы сами эту методику разрабатываем, в каком-то смысле.

На моей памяти все проекты где пытались дать ТЗ оканчивались провалом.

У меня обратная практика- еще не видел ни одного проекта без техзадания или без Project Definition документа.

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

Upd: а, Вы про "Agile software development, agile-методы) — серия подходов к разработке программного обеспечения," ? (из википедии копирнул)
тогда наверное можно и без ТЗ и вообще без цели и понимания чего же в конце получится. Судя по качеству работы программ, сейчас этот подход очень моден и применяется много где.

Ну есть вариант, что вообще не читали. Но я про методические материалы по различным Agile-технологиям, evo, scrum, xp, и т.д.

Даже школота на педивикии, и-то что-то об этом знает:


Как видите, планирование, анализ требований, тестирование и документирование имеются. А раз они имеются, то задание таки есть, и содержит оно требования и объём работ, тестировать опять же надо на соответствие чему-то. И документировать что-то конкретное и в соответствии с определенными требованиями.


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

Я говорил об Agile методе когда разработчик один.
Обсуждение же началось с того что разработчик был один.
А тут TC выкатил какую-то нереальную форму TЗ
Я бы даже назвал это неэтичным вываливать разработчику на халтуре такое ТЗ.




А что еще в CAN-е может быть кроме "физики"?
Он так спроектирован чтобы "физики" хватало для всего и не надо было городить еще 5-ть уровней над ней.

Хотелось бы уточнить, что именно там нереально ?

Наверно, AlexandrY не понял, что это план ТЗ, и решил, что это само ТЗ и есть. План хороший.

Но хорошее ТЗ не отменит требований к уровню разработчика, как я объяснил выше.
Если Вы пишите хорошее ТЗ сами, а не предоставляете возможность всё додумать за Вас разработчику, то значит берёте на себя функцию руководителя проекта / научного руководителя. Осталось только научится разбираться в схемотехнике и программировании, и можно будет получать документацию от любых дешёвых низкоквалифицированных разработчиков, выгребая за ними ошибки и указывая что именно переделать и как.

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

Чтобы более полно проконсультироваться на форуме по конкретным вопросам сделал ветку в "Печатные платы (PCB) > Работаем с трассировкой > Примеры плат" - "Вопреки рекомендациям от производителей ..."
Тема проектирования ПП в настоящий момент на первом месте.



Разумеется это только план. Более того, "заполняя" первые 6 пунктов, начинаю все больше и больше испытывать желание сделать все самому.
Новый человек тянет за собой вопросы по минимизации рисков.
Если я сам могу заставить работать себя сколько нужно для достижения результата и с нужным качеством, то стороннего работника - вряд ли.

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

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

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

1). "Ну вы блин даёте!"

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

Единственное исключение - это повремённая оплата, которую так любят забугорные фирмачи.
Но при разработке оборудования и там лучше выходить на некие поэтапные спецификации типа ТЗ.
Если этого не делать, вероятность скандалов с заказчиком резко увеличивается.

2). У Вас очень странное представление о Agile.

Agile не имеет смысла, если разработчик один, т.к. к нему нужен ещё и начальник.
Грубо говоря, Agile - это нормирование по длине и толщине палок-погонялок, предназначенных для управления группами разработчиков.
В основном используется на чисто софтовых проектах. Так проще заставить работать среднестатистическую группу разработчиков-программеров.
Пришло на смену классическим ненормированным пинкам, после которых среднестатистический программер может самостоятельно проработать примерно неделю.
Кроме того, наличие погонялки вселяет уверенность в заказчика по поводу того, что при повремённой оплате все его деньги будут потрачены только на его хотелки(что далеко не так), а сроки не накроются при наличии качественных спеков и КП.
И Agile не исключает спецификаций (считай ТЗ) на разрабатываемый продукт. Просто отношение к ним немного другое.
Как раз погоняльщик (руководитель проекта, тимлид и т.п.) спецификациями и занимается.

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

Я как представил разработку авианосца и всего его нутра за несколько коротких итераций.. Сразу повеселел.



На моей памяти (а это 40 лет работы в отрасли), все, что начиналось без ТЗ - заканчивалось провалом.

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

Однажды столкнулся с одним СТП - смотрите во вложении. Подобный документ можно прикрепить приложением к договору/ТЗ. Мне в этих требованиях самому не все нравится, вы их можете взять за основу для разработки своего документа.

Фееричная помесь стиля кодирования и запретов на очевидные ошибки. И так же очевидно не имеющая ничего общего с получением качественного кода. Вот например правильный документ на стиль исходников, к примеру : https://google.github.io/styleguide/cppguide.html Ну а по поводу отсутствия глупых ошибок спасет только уровень знаний и опыта. Если "програмизд" не осилил правильных книг, а только нахватался по верхам, от такого вредителя никакой документ не поможет.

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

ИМХО, но не верно ни то, ни другое.

Самое важное инструменты!

Ага, нажал на кнопку - получил результат

Непонятно еще что понимается под "качественным кодом". Может под этой фразой каждый свое понимает. Для меня - это когда на проекте меняется программист, и новый программист въезжает и разбирается в коде очень быстро. По идее должно быть что то типа ЕСКД для кодов, но т.к. такого вроде нет, фирмы для себя пытаются разрабатывать свои СТП.

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

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

Вот, кстати, кое-что.
Единая система программной документации (ЕСПД)

Не, ЕСПД - это совсем не то. Это о том как по единым правилам блок-схему рисовать и всякие инструкции и формуляры писать. К тому же сто лет назад как вышла, так и не модернизируется в отличии от ЕСКД.

Вариантов тьма и холиваров тьма.
Лучше внедрить СТП под свои цели с учетом местных особенностей.
Можно в качестве лирической основы взять какую-нибудь философию/декларацию и нарастить на нее конкретные и детальные требования в виде СТП.
Лирика:
https://en.wikipedia.org/wiki/Zen_of_Python
https://ru.wikipedia.org/wiki/Python
https://en.wikipedia.org/wiki/Unix_philosophy
https://ru.wikipedia.org/wiki/Философия_UNIX


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

Вот тут толковый перечень правил.
"10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками"
https://habrahabr.ru/company/hexlet/blog/303160/

MiklPolikov, спасибо за ссылку по правилам программирования. Многие и я в том числе потеряли годы на "изобретение" аналогичных правил.