接下來會開始進行概念設計(concept design),但是很多人以為是把概念圖畫出來,當然這時候用很多的不管是圖像、文字、甚至音樂,就是給人一種代入感。
基本上會根據幾點進行,這時候會出現一個叫single-line的圖,它基本會跟之前的方案差不多,但是方案中主要是為了釐清範圍,真正開發時,可能會在我方的系統single-line 加上接頭,這樣是方便釐清子系統範圍。
那既然有single-line,那應該會有double-line吧?猜錯了,它叫multi-line,不過這差不多要等到選料完成,進到細節設計(detail design)才會有的(參考下示意圖)。在這張圖上面你會看到控制器上有幾個檔位,每個接頭以及端子,順著圖可以知道,某個接頭的哪個pin,會接到另一個接頭的pin,或是對應的燈號的
如果需要用到高電壓,線束是相當重要的一環。因為線束較粗,要考慮到應力(甚至為了抗腐蝕,有鐵氟龍塗層),這樣的線束無法有太大的彎折,憑經驗如何走線,才能既方便又省空間,有時增加一個接頭,雖然多點成本,但是維修上較方便,建議長度至少x3,再以實配方式剪取適合的長度。
很多人會忽略的,就是測試用的治具,這個有時價值也不低,而且沒有在初期排入時程,所以強調在開規格的時候,就同時決定了如何測試,並且與客戶商議允收標準,有些人可能認為允收標準越詳細越好,以我過去經驗,這個觀念有一個前提,東西成熟相對較高,詳細一點對雙方都有保障。但是如果是偏概念性質的原型機,太過詳細可能會把自己逼死,只要其中一條沒辦法達成,就可能拖著遲遲無法結案,並被要求各種配置進行測試。
建議訂立允收標準時,保險起見以must have / nice to have 切分層級,或是切割成不同合作階段,降低雙方風險。若碰到瓶頸,無法按預期結案的情形,可以在雙方同意下,即使第一階段還未結案,把下一階段打包進來,增加專案預算,同時修訂專案範疇;或是與客戶交涉,退還部分款項,避免公司在沒有前景的專案中無法抽身。
專案會議怎麼開
既然專案已經開始跑了,那就應該定期召開專案會議,有分成只有專案內部成員參加的,作為進度確認用;也有全部專案一起向高層報告的,也是一週一次,除了確認進度,索取資源,與其他專案協調,資訊量很大,要在一個小時開完有時候蠻趕的,基本上會檢討以下幾件事:
- 目前所有專案狀態,以及預算使用情形
- 距離上一次開會之後,又完成了哪些事
- 是否跟上預期進度,如果落後的話,那是什麼原因造成延遲,目前有對策嗎
- 接下來準備完成的任務,是否需要與行銷部討論進行拍攝,或是設計部提供偽裝
- 是否即將有大筆採購,以便財務部調度現金
- 其他需要高層或其他部門提供的資源或授權
排斥開會的原因
很多人很排斥開會,會議趕場似乎是每天發生的事,但如果真的能激發出想法,擬定出方案,或爭取到資源,做到「言必信,行必果」,那至少參加會議還有一點用處。多年下總結了會議的問題,不外乎以下幾點
- 討論又不做出結論,毫無意義
- 其他部門兩手空空,該準備的資料都沒有
- 會議早已有定論,只是走形式找人背書
- 除了開會還有會前會,時間都在開會上
- 與會人員不守時,等待浪費很多時間
- 臨時召開的會議太多,無法安排自己時間
其實這些問題,幾乎都可歸因於人員配置錯位、組織流程不清、知識管理分散,追根究柢都不是單一個人或部門有辦法解決的。
你們開會的時候最常發生哪些問題? 你有果很好會議的經驗嗎?
會議如果順利,那當然皆大歡喜,但是很多時候都是帶著問題進會議室,我們就來看看如果專案執行過程中,時間、成本、品質出問題,那會議上該怎麼辦。
1.時間爆炸
專案多少具有不確定性,時間爆炸的原因很多,我列在下方看看你是不是熟悉。而且大部分都在專案的後期才會浮現,因為前期都會想說拼看看,可能有機會趕上,隨著交付日逼近,及時交付的可能性越來越低,這時候不得不說。
- 規格特殊,中游庫存不足,上游每隔一段時間才會批量生產一次。
→ 之前沒有想到先下單嗎,目前已經試過哪些管道?
- 供給不足,全世界都在搶料,量少的就會被插隊 。
→ 我們一定要用這顆料嗎? 如果量產怎麼辦?
- 工程師或採購忘記訂料,或數量算錯,加量影響交期
→ 那如何避免再次發生,PM沒有核對訂單嗎
- 韌體需要客製,需要驗證完才能出貨
→ 訂單上同意交期多久? 延遲造成的損失,由誰承擔?
在箭頭中,都是你可能被問到的,但是回答它其實都有更深一層,值得探討。
像是規格特殊,可能因為應用特殊,所以能符合要求的選擇不多,團隊是否考慮增設供應商尋源,或是跟一家電子零件採購能力很強的公司結盟。至於漏下訂單這件事,一般會被認為低級錯誤,但是系統跟流程上怎麼避免,難道都要靠人力維持? 大部分公司還真的是,靠的是老員工用自己的excel在管理,人趕跑了檔案就銷毀,很多珍貴資料就此石沉大海。
2.預算爆炸
即便在立項初期就已經預估風險,但是還是有可能,最貴的零件偏偏就是不能用。所謂的不能用包括,莫名的壞掉(進料沒有檢到),或是實際輸出與原廠宣稱的規格不符,對方又消極回應,不可能因為如此上升到國際訴訟,只能鼻子摸摸認了,此時如果已經特製了測試用治具,可能有部分還要廢棄重做。另外要考慮的是污染問題,就是有些損壞,會導致系統內部使用的液體汙染,某些工業液體價格非常高,一旦污染全部換掉,會吃掉一大部份預算。
3.品質爆炸
這裡講的是專案在驗證過程中發生的品質問題,不是產品的品質問題。有些人喜歡把根本原因分析(root cause analysis)掛在嘴邊,但是那些真的事根本原因嗎,可能工程角度上,還算能讓人接受,但是從比較高的經營角度,很多問題很難再追溯下去,較真起來只會覺得很挫折。
專案驗證有兩件事很重要:
第一、紀錄很重要。很多時候品質出現問題,團隊擔心被責罰,容易陷入一種心理,就是私下想辦法搞定,這樣就不用往上報,免去一些寫報告的文書作業。但是不按照規矩,容易使情況失控。正確的描述事件經過,永遠是解決問題的關鍵第一步,然後日本公司非常重視「失效模式與影響分析(FMEA)」,失效可能是哪些元件造成的,逐一進行排查,調整前後的結果。
有時候,開發案歷經多年,團隊成員也換了好幾批人,有些問題在先前已經發生過了,紀錄不是只為單一次的事件紀錄,也是讓之後接手的人了解到,之前的產品結構如何,發生過哪些問題,已經做過哪些測試,在什麼環境,用什麼設備紀錄,數據結果如何,以及負責工程師的結論報告。這些保存下來的檔案,包括文檔、影片、會議紀錄等等,必須儲存在雲端,並且讓接手的人都知道有哪些資料,放在哪個位址,大家都能自由閱覽,所以知識管理是相當重要。開發就是站著前人的肩膀往前看。
第二、第六感也很重要。研究開發是件很科學的事,凡事講求事實及數據,但是在你只有一台原型樣機,沒有實驗組及對照組,又不適合太多次的拆裝,問題時有時無,有時候就是突然靈光一閃。一些玄妙之事,真不由得你不信。我們每個專案都有自己的乖乖,有一次我想東西送出去了,肚子有點餓就開了一包,結果電話沒多久就響,客戶那頭喊道:「東西掛了。」
總之,在風險評估時,就要讓自己很悲觀主義,所有事情都要往壞方面想,你會發現只有你想不到,沒有發生不了。例如:正負極接反,導致短路;騎腳踏車被野狗撞到,鎖骨骨折住院;焊接的高溫,導致地毯黏著劑起火。
硬體不像軟體,受傷都是家常便飯,不過我還是想說,錢能解決的都是小事,最重要大家平安。
資源篇
專案一般會放上甘特圖,PPT做甘特圖的軟體,推薦
office timeline,價格平實,或是考慮
think-cell,這個軟體不只可以做甘特圖,還有柱狀圖,功能強大但稍貴 (我提供的連結,是知名YouTuber Leila Gharani 合作,提供60天全功能免費試用)。如果經常要做PPT,建議花點錢節省很大時間。如果沒有預算,就是用Excel畫再截圖下來,豐儉由人。