寫好程式,做一個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) 重要的人,更易跳出思想或傳統框架,不會容易改變計劃,更能按時完成工作項目。

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