開發時要專注在"範圍(Scope)"

整理小記錄2-開發時要專注在"範圍(Scope)"，是一篇2015年的專欄，提到為什麼一些產品開發上市的遲遲延後，從中探討大多都是出自於開發範圍管理上的問題。

定義軟體開發範圍與處理細節是必要性，除了軟體外，硬體其實也差不多，但硬體較少的原因是實體製造通常進入生產階段，要變更的管理決策相對少(除了重大議題或者純粹是人為問題)。

整體上有幾個思考點：

1. 拿捏執行細節；

2. 要有切點/里程碑；

3. 設法有效管理開發範圍的異動。

有一種Scope的變動通常是好現象，那就是砍掉Scope。

==>這也是接手別人的架構，若沒意外會整個砍掉重練，但太大的系統通常就會放給它去了，畢竟牽一髮動全身，改一字而毀全系統!!

總結是(原文無刪改)：

所有參與開發的人，包括掌管Scope的權責者，總是要一直在心裡想著Scope。有明確的Scope才能開始開發。此外，Scope中的細節需要備足夠的描述，而且，總是應該要劃分出適合的斷點，在一個切典禮的Scope盡量維持它不擴展、不改變，但是可以適度地削減它。

Ref: 王建興/2015-01-18: 開發時要總是想著範圍

百日計畫：099-自問必答的七個策略問題

你該自問的七大策略問題
Stress-Test Your Strategy

羅伯 賽蒙 Robert Simons

1. 誰是主要的顧客
2. 核心價值如何排列
1. 股東、員工與顧客的順位
3. 追蹤哪些關鍵績效變數
4. 設定什麼策略界線
5. 如何製造創造性衝突
1. 指派有難度的目標
2. 依績效排名
3. 設定比控制幅度更廣的責任幅度
4. 成本分攤
5. 設立跨單位團隊與矩陣責任制
6. 員工對互助合作有多投入
1. 以目標為榮
2. 團體認同感
3. 信任感
4. 公平
7. 哪些策略的不確定性會讓你失眠
1. 向整個團隊發問：
1. 必須面對提出問題
2. 內部討論必須往下推行，不應只限於最高層
3. 營運管理人是流程關鍵
4. 討論必須對事不對人
5. 每次討論，都應針對”對此你該怎麼做？”這項挑戰

參考：

羅伯 賽蒙，七個策略問題：改善執行的簡單方法(Seven Strategy Questions: A Simple Approach for Better Execution, HBR Press, 2010)

百日計畫：091-2018末的活動紀錄

2018好似過得很快地樣子？
2018進行了很多活動，
也認識了很多新的人。

從H. Spectrum開始，途中與醫學界、學術界、創投界等等，還有在H. Spectrum裡面遇到很多很有趣的人，2018後半年，結束了H. Spectrum，發散出去更多的可能性。

有些慢慢的聯繫上，有些則是在活動後開始有所聯繫，
更很多是只有一兩次的碰面，
但都令我收穫很多，
以下紀錄了五點，
這五點也是持續在進行/或開始的項目。

百日計畫：087-『檢驗』的品質與誠信

近期看了一篇文章，描述有關中國體檢公司的假體檢，也包含體檢行業的亂象，深有感觸，但通常也是很無奈的。

有幸在分析化學領域摸索與學習，從不同的角度來看這個世界。也瞭解許多『檢驗』並不是想像中的這麼簡易、直覺，甚至是“有用”。

曾經在一間檢驗公司待過，從同事中得知，國內有許多檢驗公司（環境/食品等檢驗）連在樣品都還沒收到，報告都已經完成了，更誇張者，數據還可以自己調整。

而近期的中國新聞，則是報導生醫體檢行業的混亂，有抽了血但沒有經過儀器檢驗而出報告，就只因為得癌症率僅有千分之三。在百度（會不會被屏蔽，我沒有驗證）或估狗搜尋，應該就可以搜到非常多相關資訊。

市面上所有的癌症腫瘤標記物的檢驗，從認識的檢驗科主任得知，這些都是『馬後砲』標記，一般健康人身上也不一定會有一模一樣的匹配。（可參考臨床生物化學學會NACB的腫瘤標記物使用指南*r1）

癌症檢驗（或者部分非癌症檢驗）會有所謂的誤差，因此在檢驗技術需要得知其變異性、精確度等。然後檢驗單位，或者檢驗產品（醫材）需要透過品質品管系統（如ＩＳＯ，ＦＤＡ等認證）還有發佈後的追蹤管理等等，這些都只是為了讓『品質』維持在可以被信服的基本條件而已。

說到底，『檢驗』的品質還是出在『檢驗』單位的『誠信』，如這兩年很紅的美國獨角獸血液檢驗生技公司，不也是敗在『誠信』！

做生意真的很難、新創更難，但難上加難的，永遠都是落在『人』這個核心議題。

Ref:
1. 可在google搜尋：National academy of clinical biochemistry guidelines for the use of tumor markers in "XXX", xxx 是各種病症，或參考此網頁。

百日計畫：086-研究/研發分享-8-人體呼氣代謝體檢驗

今年到7/16之前，待在H. Spectrum的生醫孵化器，開啟了自己規劃的生醫想法。

離開上一間生醫新創公司後，中途除了短暫加入兩個新創/專案開發公司，同時也持續的研究/著手自己的一些思路。從生醫的三大領域（基因體學、蛋白體學與代謝體學），思考著自己可以貢獻最多的地方。由過去的學習與經歷，再加上自己的本質，評估後則開啟了代謝體學的生醫檢測，除了前述外，也因為目前代謝體學中的許多知識累積的越來越多，且透過大數據的演算，使得以往只能從單一點去觀察人體與疾病的關係，可以有更進一步的可能性。而代謝體相關，可以參考文獻中的第三點，也是第二點提到的Nicholson博士所參與的生醫公司(Ref: 1-3)。

因參與過微機電微小化氣相層析儀時，也開始得知人體呼氣所包含眾多的化學分子是有機會與疾病連結，而其實這也跟中醫的“聞診”有關。如何從臨床角度上去驗證人體代謝出的揮發性氣體與疾病的正相關性，實則是個困難的議題，但若能逐漸且完整實現，對於疾病的檢驗、病患的就診體驗以及預防/精準醫學都能有大幅度的改變。

揮發性氣體的檢測，不脫三個大框架：樣品、分析儀器與數據分析。其中樣品包含待測樣品的性質、前處理與否相關；分析儀器則包含儀器架構、分析原理、量測訊號等；最後數據分析則是處理數據、訊號演算法與臨床資訊/意義等。其實所有的分析儀器也都遵循這三大框架，但根據不同的待測樣品而細節有所改變。

人體呼出的氣體多達數百種，不同文獻有不同的數值，普遍常看見的是約350種，而其中與臨床研究所證實相關的，大概只有十幾種至數十種。國際臨床試驗資料庫中，截至2017年，約有400多例與呼氣研究相關，雖然與其他基因體、蛋白體動則數千至數萬案例相比仍是小眾，但從每年逐漸上升的數量來看，已有越來越多的學研單位與新創公司投入此領域(Ref:4-7)。

在過去幾個月，也與幾個醫師討論臨床資訊，還有與學研單位評估技術的可行性等，但整體還有許多事需要去評估與執行的。

整個環節還有許多資訊，也樂於在之後分享，期待有更多的碰撞＆合作機會，這個專案會將是長期的執行。

參考文獻： 

1. 訴說生命故事的代謝體學──專訪長庚大學蕭明熙教授 

2. EMERITUS PROFESSOR- JEREMY NICHOLSON 

3. Metabometrix 

4. Metabolomics, Metabonomics and Metabolite Profiling (RSC Biomolecular Sciences) Hardcover 

5. Journal of Breath Research 

6. Owlstone Medical, UK 7. 目前診斷上，其實已有幾個與呼氣檢驗相關，如幽門桿菌（Ｃ13/14）、腸胃細菌增生（Ｈ2）、氣喘（嗜酸性球-NO）檢驗等等。

百日計畫：084-研究/研發分享-6-微機電氣相層析儀

2008年畢業後，因為當兵有個小插曲，所以需要等待入伍，那時候研究所的老師與一間新創公司合作，希望將當時從密西根大學所發展的微小化氣相層析儀進行商品化。所以詢問我是否有想要參與，所以就回來實驗室協助。

整個專案在當時（公司甚至還沒在台灣登記）人數也少，除了新創公司本身有幾位電子電機相關的高手外，我們實驗室除了我之外，還有三位碩士生參與。

微機電氣相層析儀，是利用半導體製程，將原本巨觀的裝置，如感測器、分離流道、前濃縮管與加熱裝置等微型化晶片，也就是所謂的Lab-on-Chip的一種。

三位學弟妹各自處理感測器、分離流道與前濃縮管元件，我主要進行系統設計/整合、控制軟體撰寫以及協助個別零件所遭遇的問題，當然還有整合後的實際樣品測試。過程中也遇到許多小細節需要去處理並重新設計晶片或者電路部分。

在我接到兵單準備入伍前，也終於順利在兩個月內完成實驗室等級的原型機，且也測試了樣品。這個專案原本要應用在肺結核的呼氣檢驗，所以我們用的樣品就是根據醫療文獻中得知的幾種揮發性有機氣體化學成分。也在測試後順利得到很好的分離效果與偵測能力。然後後續的部分就在我當兵去了之後，交付給實驗室的學弟妹繼續接手了。

後記： 微機電氣相層析儀的完整開發，在實務上還是有許多障礙，例如無法將所有的元件皆“微型化”，不管是設計的難度，或者是設計出來的能力有線外，如何將每個“微型”元件完整的整合在一起，都是後續試量產將面臨的問題。當然上述是在2009年，已過了八年的現在，微機電技術又更成熟，應該有更佳的設計能力可以達成。只是“達成後”是否真的在市場上有所用途呢？這就是商業策略需要思考的了～

對Micro-GC有興趣的可以由參考文獻前往得知： 

1. Ted Zeller教授的實驗室網頁：https://lnkd.in/evgk4ki 

2. Google search: MEMS + micro + GC, 有非常多的新資訊

百日計畫：083-研究/研發分享-5-藍芽品質認證＆鋰電池量測系統

畢業至今，有近1/3的時間在學術研究，離開後的2/3時間，參與了不少艱難的與有趣的專案，其中兩個較小的專案一併紀錄。

(A)藍芽品質認證，參與一個小而美的軟體開發團隊，專為藍芽的通訊品質系統成立的，一半為藍芽專家，專門將國際規範解析與規劃成量測流程，而我與另一位軟體專家則協助建立起自動化的通訊測試系統。(藍芽測試實驗室需具備：Bluetooth Qualification Test Facility，BQTF)

當時正紅的是BT 4.0（現在都5.0以上了！），我主要負責接手完成4.0的測試軟體撰寫，當時使用的是LabVIEW並使用物件導向架構，將4.0所需的演算法與測試項目/流程/通過條件等等逐漸建構起來，並建立報表產生軟體的格式部分（輸出為Microsoft Word），約一個半月將4.0測試部分完成並經過實機測試，算是蠻順利的，但仍然還有許多可以強化的地方。

(B)鋰電池量測系統，儀器是Keithley 2400，這是與一間國內鋰電池開發大廠的研發部門合作，客製化所需的量測流程，由於NI已有支援Keithley 2400的底層驅動，在撰寫上省了不少時間，專注於量測流程與使用者介面為主，雖然後續完成專案，因為研發人員所需的功能其實K2400有些並不支援，是蠻可惜的。

鋰電池的應用目前更是火紅，托能源發展的趨勢，這間公司也自主開發一條龍的服務，包含前端研發、電源管理等到後端的電動巴士等，新能源應用是個不可逆的發展，期待往後也有機會參與有挑戰與有趣的專案～

百日計畫：081-研究/研發分享-3-睡眠品質與溫度/二氧化碳相關性

做過一個小型的專案，與室內環境品質相關，由於有一年的秋天常常在凌晨三四點醒來，通常是熱醒，但睡前是涼爽的。於是查了幾個關鍵資訊，除了常見的二氧化碳外，溫度是有的，還有一個就是濕度。

利用二氧化碳檢測儀、還有手邊有的溫濕度感測器，寫了程式來抓取晚上睡眠的紀錄，然後搭配萬一醒來後，就打開冷氣並設定一至二小時。

從數據結果可以發現，當開始入睡後，二氧化碳與溫度逐漸上升，到約750~800 ppm的時候就是我悶醒開冷氣的時間，然後開了冷氣後約十分鐘後開始溫度與二氧化碳下降，但當冷氣停止後，二氧化碳與溫度又開始上升，相同的循環約三次，睡的真累。

每個人對於二氧化碳的敏感性不同，通常建築標準是室內低於1000ppm，也有其他的標準是800ppm以下，但也因人而異。這時才知道自己對於二氧化碳/溫度的反應如此敏感。

智慧家電有個是偵測室內的空氣品質，搭配可控制的室內氣體循環功能，也是希望改善並達到更舒適的生活品質。

百日計畫：074-醫療新創公司的法規品質與公司價值-Part III-Final

<醫療法規/品質-Part III, Final>
前兩篇簡單點到兩個案例以及相關的觀念，而法規/品質系統的重要性是不可言喻的，但有個核心的概念也不能忘記-產品。

畢竟商業的中心還是提供產品（有型的物品與無形的服務），所以並非：
“好的法規/品質系統 = 產品大賣/授權賺多多”
反之亦然，其中有許多需要併入考量的；
而法規/品質系統代表的是A=>A+的加乘效果。

回到醫療產品 (MedTech)，與一位律師前輩的某次交流，以及閱讀完他的著作，有幾點在醫療器材（Medical Device）領域的新創可以記錄下來讓自己時時刻刻思考與評估如何去做？怎麼去做？何時去做？

1. 研發題目的選定
2. 智慧財產的保護
3. 醫療與技術的合作
4. 從第一天就開始的法規遵循
5. 外部資源的取得與利用

四件要務：
1. 財務
2. 業務
3. 法務
4. 股務

以上是擷取專書中的章節名稱，我並非上述專家，因此不進一步解釋，有興趣可由參考文獻資料去深入瞭解。

而文中提到國外生醫新創公司，有兩大職務：CMO & CCO：
CMO, chief medicine officer:
CCO, chief compliance officer:
從這兩職務，可看出MedTech的核心價值所在，而CEO, CTO也許會與其任務重疊，或者（短期）兼任。

在台灣，生醫新創有更多的困難要去克服，不若國外的資金充沛、題目新穎、市場規模或國際交流經驗與能見度等等。大多國內做得不錯的廠商，不是做OTC產品，就是做生產製造的角色（但近年後者也逐漸被中國製造廠超越）。

文章小結論：
紀錄這三篇是聽到一些實際狀況，尤其又與自己有切身經歷的有感而發。一個產品（或事業）能否有所發展，牽扯的問題實在是非常多，也可以在媒體上看到各領域的精神領袖所提出的信念皆不相同（有市場導向、技術導向、潮流導向等等）。能否在這些眾多複雜因素中，理出一條條通往“有效發展“的方向，考驗著每個創業的人，以及跟隨新創的人。

參考文獻：
1. （書籍）醫療器材的研發與創業, 劉承愚/趙蘭英, 2014, 翰蘆圖書
2. 醫療法規/品質-Part I
3. 醫療法規/品質-Part II

百日計畫：064-國際專案的第一個里程碑

今日接到台銀的來電確認國際匯款項目，終於！
經過漫長的行政流程，
我與紐西蘭大學的專案合作也進入一個新的里程碑。

舊文參考：052-能做國際專案的國際團隊

雖然初步是個小專案，但在彼此團隊討論慢慢的往前推進，雖然自己在技術上面提供的就幾乎為零了。

衷心感謝合作夥伴與對方（客戶）選擇了我共同參與此專案，如前文提到的團隊，透過今年初開始的新創，也是逐步地摸索與大量的溝通。

前幾天也意外的與一位埃及的新朋友聊到，也許也有機會合作有趣的專案。

同樣的，有幾位朋友我也在評估（英國、日本、哥倫比亞等），同時也讓這幾位評估我，期待有朝一日這些夥伴將成為真正的夥伴，玩一場國際的遊戲。

外包隨便聊

昨日抽空到台科大去給學生程式上的建議與討論，聊了一個半小時，其實也不知道是否真的對他有幫助，畢竟他原本是想將他無法解決的問題尋求外包資源！我認為研究期間最大的本錢就是學習可以接受失敗，畢竟沒持續努力的人不會持續得到失敗。希望對他有些啓發了，至少我也只接受他一杯小七咖啡，不像之前一位哪間學校（？）的學生，討論半小時多我收他五百塊，後來他也沒有後續的進展，讓我稍稍覺得可惜，也因此後來決定不再收這種討論費用。😱

後來晚上在公館走了好幾間舊書店與一般書店找書，最後還是在一般書店找到我想要的藏書，雖然有點舊，但還是很開心找到了！😍

逛書店的途中，在資源回收桶旁發現了一個好玩意！復古造型的“廣播接收器”，可以放ＣＤ，暫時還不知道被丟棄的原因，週末來檢查看看是什麼樣的問題。也算是小古董了！

能力圈、知彼知己 與 隨機性

好一陣子討論不完的職場就業問題，實在令人看了又是擔心又是高興。擔心的是環境的確有所不佳，高興的是越來越多人願意出聲（有無動作則是其次）。在看了這麼多的文章、討論串以及新聞等等，覺得議題中正反兩面都有討論到，但也常偏頗於單一觀念，於是想提出一些概念來整理自己的思緒。

Charles T. Munger 提到，每個人都需要認清自己的能力圈，只在能力圈裡面做好自己擅長的。而這點其實就跟中國古語的『知彼知己』的知己，瞭解自己的特質、能力以及心態。並不是說不能去做自己不擅長的，而是如何“評估”做事成功的『機率』。機率概念可從 Nassim Nicholas Taleb 的一些著作中看到，隨機性充斥着社會中，有沒有認清這一事實也是非常重要的。

回到文章開頭，花點時間去思考自己可以做什麼、不可以做什麼；能學什麼、不太能學什麼。是理解自己的能力所及，然後將其磨鍊、深入以及延展（有些微違反能力圈概念）。接著是『主動』地去創造『機率』，看似很簡單的想法，但並不是每個人都願意花這麼多時間去嘗試。

這裡提出了是偏向自身能力以及取得機會的超短簡述。其它還有更接近人的議題，如做人處事，那又是另外深入的議題了。

敏捷 or 穩健 開發??

接觸軟體工作一陣子，接觸了蠻多敘述與實際案例的開發訊息。其中有幾個如精實開發，敏捷開發或者比較傳統的穩健開發類型。在互相比較之下，可以看到各有其優缺點的觀點。

我對兩者個粗略概念如下：(以下概念不單只是存在於軟體開發)

A：敏捷開發是早期設計與取得雛型並得到實際的使用者(非開發者本人)的回饋，而不斷的精實修改朝向正確的方向。

B：而穩健開發比較著重在於完善的規劃，從大方向到小細節都定義完整在進行專案。

以上很粗略也可能不是針對其各家領域的核心思想，而我的看法以及應用的方向則是：

A：敏捷開發的應用是建立在"精實團隊人數"、"開發工具熟練度"、"未有正規化流程"三個點。(可能還有其他，有想到待補充)

B：穩健開發則是建立於"專業分工度"、"系統複雜度"、"已有正規化流程"等三個點。

只先各提出三點，而其中的定義套用在這兩種開發則可以簡易的敘述如下：

1. 團隊人數-有些團隊可能會受限於經費或者其他原因，希望/必須維持小型團隊
2. 開發工具熟練度-對於開發工具的熟練度，是否有深度與廣度的實際實力
3. 正規化流程-這點很重要，因為這包含了是否需要有對系統的"分析"、"設計"、"整合"等三大能力
4. 系統複雜度-複雜度建立在"跨領域的廣度"，以及"單一領域的深度"。
5. 專業分工度-與[開發工具熟練度][團隊人數]有交互涵蓋，這邊會想表達的是分工需要切割到多細。

以上，是對於一個系統進行開發時，其團隊所採取的方式所需考量的點。我的經驗只在於狹隘的幾個領域中，所以可能還需要在遇到新的專案或者在汲取新的概念消化後，進行增減的修正。後面會繼續記錄以上有提到的延伸文章。

軟體不軟體，硬體不硬體

我很幸運有些機會去過不同的工作工作過。想提出一些可能不應該提的檯面下問題，只是好奇心可以殺死一隻貓(若在While/ for loop內可以設定殺死無限多次)。

關於軟體的正版問題，因為我待過的某間公司，當初在推行自動化時，前一年並不是購買正版軟體(買什麼就別問了，跟我工作相關)，然後我曾經接案的公司也是如此。再來要提的是使用"流行版本軟體"本來就不是什麼不能說的秘密，學生時期或多或少都會使用到這類型的，而且現在大多數的學校都願意買校際版或者系所版本。只是一間公司營收數億到數十億，公司副總可以開千萬跑車，卻不願意花個幾萬到十幾萬的軟體，有點可笑。而在我待過的公司之間，曾經跟曾經為前主管的人討論過，他說了這麼有趣的一段話:

若公司要整合系統不買硬體那就是太過分了，而軟體還好。

所以軟體可以"偷用"(因為Copy & Paste即可)，而硬體不行，這樣說反而驗證就是因為幾乎沒有哪間公司可以跟廠商借儀器，然後一晚就可以複製出一台一樣的能力。

只是想說，同樣在評估專案計畫，軟體就如此隨性，硬體卻可以變通。硬體有所謂的租借日期，軟體一樣有試用日期。若硬體可以在短時間(租用日期內)可以評估是否可以使用，那軟體應該也行。當然!在台灣普遍不注重軟體的氛圍之下，很多公司都是從舊有人員去轉軟體(換領域很好，多學習也很好)，但是整體上根本不利業界的發展。(從此可以在衍生討論很多其他相關的問題!!!)

更甚者，當初一年多沒買正版軟體的前公司，卻願意花十幾到幾十萬讓員工去上教育訓練(一些教育訓練的價錢都很有"價值")，這種錯亂的價值觀念只能說令我啞口無言。

那時候沒想到，事後才想到想對那位先生說的是:
下次要評估新的系統，可以先去跟某某公司"借"一台儀器，借個一兩年等到系統可以使用後，再跟那間公司說我們想要跟你們買正版整套的儀器。不知道業界哪間儀器商可以說沒問題的，以後我要買儀器一定跟您們買(當然也會先借個一兩年評估啦，最好可以借了就不必付費，連租金都免!)~

PS:此文原本發布在其他專業論壇，稍微修正一些用詞遣字，重新發布在此，希望也有不同/相同想法的人回饋，以及有共同經驗的人可以提出。

當然我朋友是說:反正就是老闆貪小便宜心態.....

醫療儀器研究與開發

昨日聽到了一段話：

Device by Design; Drug by Discover.

從FDA的歷年演進也可以看出個所以然，畢竟在1997年以前，醫療器材只針對製造端的品保與品管等相關GMP之類的控管，但在後來的醫療器材回收樣品中去分析(大量的錯誤產生)，發現大多數是並不是因為製造端的問題，而是在進入製造端"之前"的"設計"就有問題，也因此才會要求有Design Control等相關文件。

BUT, 這個"But"就是最重要的~

What is Design ? or How to define Design ?

我的註解是：根據"產品使用者預期的情景"而成的商品，就該從這個角度去定義如何設計。

越是跨領域的研究與開發，就更是需要更高視野的思考，或者白話一點就是很常見的"系統化"。只是當定義了系統的深度與廣度時，將同時也定義了團隊的組成與研究&開發的方法。

若是選了不符合的"方法"，那就容易導致不符合的"結果"了。
至於如何去定義方法、定義設計、定義團隊等等一堆無趣的名詞遊戲，將在後續不斷的修正自己的思緒而留下註解。

參考資料：
http://www.fda.gov/downloads/MedicalDevices/.../ucm070642.pdf

好丘~丘的是自我型式上的滿足仰或內心裡的喜悅

今日參與一個研討會，休息時間到附近的商品買個涼爽飲品，剛好經過一個算是古蹟(?)的區域，而其中面向馬路的建築物外牆放置如下影像。

最近也因為一些事情煩心，再次的驗證每個人都是獨立的個體，但也易受團體牽引。而其中最接近藝術的就是" 溝通"了。

之前有回應一則文章，提到"信任"，不知道在沒有信任的前題下，再精湛的溝通是否也有幫助??

越發覺得團隊的組成以及發起凝聚人(被稱呼為領導者)與呼應理念的接受者(被稱呼為跟隨者)是極為重要的。

除了不斷的付出與學習外，我也持續地找尋與挖掘這樣的地方。

Prototype的想法 （系統分析、設計與整合）

玩了一些儀器的研究與開發，雖然都是沾醬油式來來去去。
不過一直對如何進行Prototype (原型機）有著莫名的熱情、毅力。

從過去的經驗與想法，整理了一些初步的想法，希望在不久的將來可以更完善這個想法。
受限於一些研發是屬於不便公開，但仍希望可以分享一些經驗，也是練習自己的敘述能力。

＞＞＞＞＞＞＞＞正文＞＞＞＞＞＞＞正文＜＜＜＜＜＜＜＜
小結論：
在參與一些的研發專案的感想是：沒有事前做好規劃。而最常見的理由則是：”我們不確定最後的產品是否可行”，但是卻花了不少時間在單一細節的研究。在科學研究上，尚且可以走一步、看一步、做一步（當然亦有非常具規劃模式的科學發展），但在時間即金錢的產業上，如何將時間與金錢花在正確的路上，這就是在風險管理的前提下所必須考量的方法之一。

下一次會將自己的內容精進且圖像化，需要理解與學習的事物還很多。