[prig 0]

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

 

Ну, ТС много чего не раскрыл.

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

 

[MiklPolikov 0]

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

 

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

 

1) То, что изготовление печатных плат организует сам ТС, а не разработчик, косвенно указывает на то, что гонорар разработчика сопоставим со стоимостью изготовления плат, такие суммы на языке экономистов обозначаются термином "на пиво для студента".

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

 

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

[muravei 3]

Финансовый вопрос чаще всего оказывается

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

[MiklPolikov 0]

Когда ему объяснили, что нужно сперва ТЗ, он согласился , но был готов заплатить за него $200 . Не знаю, здесь ли он нашел ТэЗэписателей или где еще, но смысла за него платить вообще не было . Самого важного в нем не было , зато было много бессмысленной фигни и напоминало диплом

 

Разумеется, написать вменяемое ТЗ может только спец уровня "руководитель проекта", как я уже объяснил выше.

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

[AlexandrY 3]

Разумеется, написать вменяемое ТЗ может только спец уровня "руководитель проекта", как я уже объяснил выше.

 

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

 

 

 

[one_eight_seven 3]

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

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

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

[AlexandrY 3]

Невнимательно читали. Методика Agile подразумевает, ...

 

Что я невнимательно читал?

Мы сами эту методику разрабатываем, в каком-то смысле.

 

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

[Ruslan1 16]

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

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

 

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

 

Upd: а, Вы про "Agile software development, agile-методы) — серия подходов к разработке программного обеспечения," ? (из википедии копирнул)

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

[one_eight_seven 3]

Что я невнимательно читал?

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

 

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

Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.

 

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

 

Судя по качеству работы программ, сейчас этот подход очень моден и применяется много где.

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

[AlexandrY 3]

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

 

Я говорил об Agile методе когда разработчик один.

Обсуждение же началось с того что разработчик был один.

А тут TC выкатил какую-то нереальную форму TЗ

Я бы даже назвал это неэтичным вываливать разработчику на халтуре такое ТЗ.

 

 

и уродцев различных (например тех, где заявлен CAN, а на самом деле от CAN - только физика)

 

А что еще в CAN-е может быть кроме "физики"?

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

[Hirer 0]

... А тут TC выкатил какую-то нереальную форму TЗ

 

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

 

[MiklPolikov 0]

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

 

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

 

Но хорошее ТЗ не отменит требований к уровню разработчика, как я объяснил выше.

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

 

 

[one_eight_seven 3]

А что еще в CAN-е может быть кроме "физики"?

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

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

[Hirer 0]

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

Тема проектирования ПП в настоящий момент на первом месте.

 

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

Но хорошее ТЗ не отменит требований к уровню разработчика, как я объяснил выше.

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

 

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

Новый человек тянет за собой вопросы по минимизации рисков.

Если я сам могу заставить работать себя сколько нужно для достижения результата и с нужным качеством, то стороннего работника - вряд ли.

Изменено 19 июля, 2016 пользователем Hirer

[adnega 10]

Новый человек тянет за собой вопросы по минимизации рисков.

Если я сам могу заставить работать себя сколько нужно для достижения результата и с нужным качеством, то стороннего работника - вряд ли.

Разработчики разные бывают. Хорошие разработчики не будут работать за копейки.

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

При этом оставив Заказчика довольным, чтобы иметь положительную репутацию

и повторные заказы.

 

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

набью руку, поработаю с его инструментами и т.п. Т.е. оплату времени такой категории

Заказчик производит не деньгами, а своим временем и предоставлением в пользование

своих технических ресурсов, плюс научит как надо и как не надо.

 

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

вы бы сами согласились работать за те деньги "сколько нужно для достижения результата с нужным качеством"?