|
本帖最后由 滾刀魚 于 2018-1-23 10:28 編輯
我個人覺得在設(shè)計階段的方案評審和實(shí)驗(yàn)論證也很關(guān)鍵,,方案評審名義上是幫助設(shè)計人員找問題,尤其那些對客戶需求比較了解的“專家們”或者就是客戶,,在方案評審時也可以確認(rèn)一下,,現(xiàn)在的設(shè)計方案和需求是否一致,也是客戶確認(rèn)的一個過程,,不過貌似很多組織都沒有這個過程,,設(shè)計人員負(fù)責(zé)制,設(shè)計,、制造組裝和調(diào)試,,費(fèi)了九牛二虎之力,樣機(jī)到了客戶現(xiàn)場,,拆箱試用了,,才了解到根本不符合客戶需求或者部分不符合客戶需求,有人會說這是客戶當(dāng)初自己沒說清楚,,其實(shí)還是你的客戶需求收集沒做好,,客戶只是未來的使用者,客戶不是技術(shù)專家,,一般情況下是客戶給的需求都是概念的,,籠統(tǒng)的比如客戶要自動化程度高的,、要效率高的、要運(yùn)行穩(wěn)定的等等,,這些都沒有量化的標(biāo)準(zhǔn)和需求,,沒有量化就沒有辦法測量,沒有辦法測量就沒有辦法考核,,自動化程度高的就可以量化成比如減掉5個作業(yè)員或者無人工參與,,效率高的可以量化成日產(chǎn)能、月產(chǎn)能或者生產(chǎn)節(jié)拍等等,,運(yùn)行穩(wěn)定的可以量化成平均故障間隔時間,,這些數(shù)據(jù)需要你去收集、分析,、整理和量化,,客戶說不清楚的,需要你去客戶現(xiàn)場去收集和測量,,這些真實(shí)的數(shù)據(jù)就能形成你的設(shè)計方案的輸入,,而且你設(shè)計方案的輸入,,也是需要客戶確認(rèn)的,,得到客戶的首肯才是正確的輸入,如果客戶聽不懂你的術(shù)語,,你就需要演示或者翻譯成客戶聽得懂的表達(dá)方式,。
還有實(shí)驗(yàn)論證,有很多設(shè)計方案即使已經(jīng)進(jìn)入詳細(xì)設(shè)計階段,,但是方案可行性還是停留在理論上,,雖然現(xiàn)在有很多虛擬軟件可以做模擬實(shí)驗(yàn),但是模擬出來的實(shí)驗(yàn)數(shù)據(jù)的可信度,,還是需要你去實(shí)驗(yàn)論證,,所以實(shí)驗(yàn)論證一般都是到物理樣機(jī)測試階段,實(shí)際上在組織允許的情況下,,還是應(yīng)該做一些關(guān)鍵模塊的實(shí)驗(yàn)測試,,而關(guān)鍵模塊的設(shè)計就需要在總體方案設(shè)計時考慮接口,你這個關(guān)鍵模塊需要能在總方案中能夠使用,,而不只是一個實(shí)驗(yàn)?zāi)K用完就扔了,,不能造成浪費(fèi),關(guān)鍵模塊實(shí)驗(yàn)失敗了,,你收獲到的是經(jīng)驗(yàn)教訓(xùn),,實(shí)驗(yàn)成功了,說明你的方案構(gòu)想是符合實(shí)際應(yīng)用條件的,。瞎胡說,,愛看就看看,,不愛看,就當(dāng)沒看見,。呵呵,。 |
評分
-
查看全部評分
|