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

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

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 пунктов, начинаю все больше и больше испытывать желание сделать все самому.
Новый человек тянет за собой вопросы по минимизации рисков.
Если я сам могу заставить работать себя сколько нужно для достижения результата и с нужным качеством, то стороннего работника - вряд ли.

Сообщение отредактировал Hirer - Jul 19 2016, 11:15

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

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

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