寫APPS更要度好 Schedule（larrylo）

寫好程式，做一個APPS，設計，開會，度期，開發，測驗，調整計劃，缺一不可。上文 《寫 APPS 都要畫FLOW CHART?》講到寫APPS 前要先草擬 FLOW CHART，畫好一個流程圖，有助日後開發。今次，就要討論如何認真開會，和度期。

先說度期。度期，就是排程，俗稱排 Schedule。就是列出和預算所有工作項目的過程。 過程，是就根本已設草圖或已批准的草圖，化成模組。然後將模組的特點和要求寫下，化成一個個工作項目，然後按一個個工作項目，的性質，基於現有開發範例或基本程式工具去研究開發可行性，預算所需時間：如花 0.5 日時間完成輸入方式鑑定，符合電郵、電話號碼的格式。度期不善：時間預算有誤差、工作項目有錯漏、用錯方法完成、研習不足，足以令頂目開發比預期遲完成，時間、心血、金錢花費比預期多，會出事的。即上司或頂目主管問起你，你閃爍其詞，不明所以地說出三天完成一個模組、或肯定道出三天可完成，上司或頂目主管都會認為你三天可以完成。跟不上進度，都要延誤。

所以，研究可行性，能否完成工作項目，需要開發者先計劃好完成方法、搜集坊間做法、閱讀有關 Documentation 的資料。清楚了解要求、做法，極度需求開發者的英語水平。Documentation 都是 Google 、Apple、Oracle用英語撰寫。提問開發方式或個案分析，可到在Github、 Stackoverflow的開放論壇，不少用戶，包括中國人都是用英文提出問題和事項（Issue）。寫下 Pseudo Code 去草擬做法，將頂目細分成一個個小工序，一定要做，務求清楚了解頂目要求，和預期承受的風險。

當然，草擬好項目工序，排好個期，就要進行開發，按步完成模組。至於如何預期達標，將管理風險減到最低，就是定期開會，適時調整步伐。開會，就是跟定期跟同事和上司一赴會議室，匯報進度，解決難題。開會前，必有同事先草擬一份會議流程，教大家準備開會。如果是行政、財務部，一般會議流程都要定期匯報財政狀況，人事關係，較有規律。營業和商業行銷則先報銷售，後跟進。

如果產品開發部門的，就除了匯報走貨情況，產品測試，還有開發情況，指出困難或延誤地方，所以會議流程變數較大，控制會議時間結束較難，考起參與者的解難能力、語言表達，和決策智慧。參與者必先了解問題本質，清楚匯報，再提出解決方案或拋磚引玉，求其他人指點迷津。就我以開發遙控藍芽裝置的APPS 為例，有時達不到產品要求，不能一刀切指出責任誰屬，是APPS DEVELOPER 有錯或攻硬件指出的FIRMWARE 有問題。我們是要先說使用的流程，然後指出以上做法不合乎預期效果，電話或有藍芽硬件的狀態有異，提出開發方法或建議他人改善 FIRMWARE。指出開發困難，就是公開討論做法，然後按照剩下時間心血，優先完成重要模組或先完成簡單模組去省下時間，讓出更多時間去完成困難模組，什至抽出部份模組，完成雛型叫其他同事測試產品。

現今資料爆炸，產品繁多，行銷模式都需要由單一廣告轉移至連續公佈消息，介紹產品用法、特點，什至要求出外測試和批評外來新聞去增加曝光，凸顯產品或公司的 Vision 和特色。達到以上目的，頂目主管和測試者都要定期監察產品是否達到已經批准的用戶要求。 再達到以上目的，就需要Agile project management。Agile project management的精髓，就是定期開會和修訂排程，透過恆常檢討進度，拆彈，適時調整開發、測試，和發佈步伐。

以上管理準則，放諸四海，皆為準確。只是成效與否，因人的表達能力和決策解難而決定。重視結果 (Consequentialism) 比重視方法 (Categoricalism) 重要的人，更易跳出思想或傳統框架，不會容易改變計劃，更能按時完成工作項目。

因為，你已經計劃好，排了期，剩下都只是匯報進度，盡力完成工作。

作者：larrylo（本文章由聚言時報授權提供）