Comments 4
еще важно определица с основным функцыоналом, а то может оказаца что разные необязательные примочки отнимают 80% времени разработки
Интересно почитать о тормозах разработки со стороны конструкторов. В целом особых претензий нет, но дьявол как всегда в деталях. Разделить ответственность - здравая идея. Но мы правда готовы к такому шагу? У нас адекватные заказчики, грамотно составляющие ТЗ? Или может быть у нас все четко по ТЗ, а ситуация "мусор на входе - мусор на выходе" это исключительно проблема заказчика?
Вопрос размена сроков на качество он всегда сложен. Особенно что при этом всегда фигурируют еще и деньги. Впрочем - это разработка. Это отдельный филиал ада. И реально его познал, только тот кто сидя на раскаленной сковороде кричит вновь входящим "Дверь закройте, холодно". К счастью этому не учат. Иначе бы разработчиков не было совсем.
Со стороны разработчика электроники готов со многим согласиться. Однако все же не могу не заметить - отличие мастера от ремесленника ровно в одном. Ремесленник может сделать хорошо. А мастер не может сделать плохо.
У нас адекватные заказчики, грамотно составляющие ТЗ? Или может быть у нас все четко по ТЗ, а ситуация "мусор на входе - мусор на выходе" это исключительно проблема заказчика?
Ну нельзя тут употреблять «адекватные» и «грамотно составляющие» — он, заказчик и не должен по большому счету. Как раз сутейно про это текст — ты выбери что тебе надо от проекта, чтобы ехать дальше. Остальное «приложится».
Я много раз видел, когда конструктор со стороны заказчика перезакладывается по требованиям по каким-то причинам. Неопытный, боится ответственности, просто не понимает цену решений — не важно, не про это. Но когда садишься с ним и начинаешь тыкать в каждый пункт с вопросом «а мы можем выпустить продукт и продавать его спокойно клиенту?» — сразу по другому начинают думать про важность или неважность требования. Я даже не трогаю случаи когда там что-то неразумное, например, в настольный прибор для помещений закатываются требования по всепогодному или полевому исполнению, сплошь и рядом. Просто отбить мысль, что вот это и это можно варьировать, но и тот и тот вариант можно выпускать и продавать.
Ну и чтобы два раза не вставать — разработка всегда про отшелушивание решений из множества. И есть тот кто понимает процесс и понимает, сколько это отшелушивание занимает времени.
А есть кто нет. Для них моя заметка :)
... когда садишься с ним и начинаешь тыкать в каждый пункт с вопросом «а мы можем выпустить продукт и продавать его спокойно клиенту?» — сразу по другому начинают думать про важность или неважность требования.
Собственно это один из признаков того самого сферического "адекватного" заказчика. Понятно, что в первом приближении всегда "хочу хорошо, не хочу плохо". А дальше начинаем выяснять так ли хорошо это "хорошо", и так ли плохо то "плохо".
Беда в том, что очень часто получается по другому. Заказчик, тот который за разработку платит, верит своему специалисту. А тот свято уверен в том, что кругом криворукие жадные уроды, которые за 30 серебряников готовы его втоптать в грязь и всеми правдами и неправдами протащить свою дичь с которой ему потом разбираться. И, самое плохое, в том что мнение это - не блажь или откровенная глупость. Это "опыт - сын ошибок трудных".
Кого в такой ситуации убеждать? Чем дальше, тем больше убеждаюсь - единственное правильное решение в такой ситуации бежать без оглядки. Пусть "главный специалист" в очередной раз найдет тех, кто его обманет. В конце-концов каждый равняет по себе и подобное притягивает подобное.
Беда в том, что таких вот, от которых бежать без оглядки - подавляющее большинство. А уж если с ними работать - то точно надо закладывать сроки на движение этого монолита и обучение (аккуратное, чтоб и мысли не возникло что его учат) специалиста от заказчика. А это, просто вернувшись к теме статьи, и есть те самые "тормоза разработки". Что бы это не значило.
Как пнёшь, так и полетит. 3 приёма ускорения разработки в приборостроении