相信工具 讓事情開始進行
相信工具 讓事情開始進行
隨著接觸過的專案越多，考慮的點也跟著的變多。開始的時候滿足於自己能夠「顧全大局」的成就感，但是也漸漸發現自己撰寫程式的速度不如以往。雖然寫出來的程式品質有跟著提高，但也隨著專案進行，發現許多當時考量的東西，最後不是沒有用到，就是需求改變而不敷使用，時間在無形中被浪費掉。倒不如早早開始動工，相信以依照現在的方法和工具，都有機會能夠將偏離的方向導回，沒考量到的部分予以補齊。當然光是「相信工具」是遠遠不夠的，還要去學，去實踐那些工具和原則。像是不斷確認開發是朝著目標走，以此定義單元測試，並在發展的過程中反覆進行程式碼的重構。否則，只是單純的盲目前進，以及天真的期望哪天醒來，所有的問題會自然消失。
真正了解工具的背後意義，相信它們能夠幫助修正問題，然後就開始實作吧！不斷讓這些工具加入，讓事情發生！
解決問題 遠比用新技術更重要
無論一台機器功能再多，性能再好，如果不能用來打電話就算不上是一台手機。當為了追求的新的技術、新的管理方法、新的設計流程，一旦遺忘了根本的初衷，那麼產出的只一個堆積許多功能的四不像。一個連自己都不知道有什麼價值的東西，當然難以得到其它人的認同。所以產品的定位，想要解決的問題以及讓使用的人得到什麼價值，遠比用哪一種技術重要得多。不管是 Scurm 專案發展、UML 圖或是 Big Data 、RWD ⋯⋯等等技術，都是為了解決在產品開發上，會遇到的一些問題。但也大多止於「產品開發」上，而不是「滿足客戶需求」或是「創造價值」。雖然學習各種新技術，能夠減少一些時間的無謂浪費，增加一些新的可能。但絕對不應該將所有的焦點都放在「新技術」這個議題上。選擇、引用，甚至是學習新技術，顯然比研究客戶問題、提出解決方案要簡單、不費腦力。看過一些人沉浸在新技術的堆疊，近乎在逃避解決客戶問題的責任。必須引及為戒，不能陷到這種狀況中。
片段時間 就開始 重要的是方向定下來
「我有想法，但沒有時間，找不到適合開始的時間點。」這個問題困擾了我許久，總是在一個念頭的開始，伴隨著公司加班，或是親友或自己的事情干擾，導致最終念頭仍然只是一個念頭，還是沒有被實現。因為如此，我的在職碩士，花了我整整五年的時間才完成，回頭來看還滿有趣的。前兩年我順利的完成所有的該上的課，沒有一科被當或出現危機。然而一個碩士論文卻花了我三年，而實際用在製作我的畢業論文的時間，大概才半年，那忙亂的半年中產出了一篇足以讓我畢業的碩士論文。而那半年之中，還有公司的專案趕工、上線等壓力在，常常強迫自己早點睡，六點起來寫一點文字，最後組成整篇論文。事實上，我在完成論文的那個時段並沒有比較輕閒，所有的文字都是在片斷時間中撰寫，最後一兩週才抽出比較完整一些的時間去順槁。因此由小看大，表示別等著完整的時間才開始想作的事，既使只是片斷的工作成果，也能夠積少成多讓自己離目標更近一些。有一個明確，短時間不會被改變、大幅調整的目標，就可以開始動工了。大原則不變，其它的東西一面作一面微調方向就可以了。讓事情發生！比大量的規劃卻零產出有意義得多。
需求優先 別卡在細節
一個功能能夠有多少種變化？使用者操作上會不會看不懂？需不需要防呆機制？網站的安全性夠不夠？效能能不能讓主機承受上萬人同時操作？雖然這些問題對於一個成熟產品來說是必要的，需要常常去檢視，研究尋找更有好的解決方案。不過對於一個剛開始的計劃而言，這些都太遠了，不值得讓它們佔用本來就不太夠用的腦袋空間。人們可以忍受要等上一兩秒才算出報表的統計程式，但不能接受一個全世界最快，但只能算加法減法的計算機。專案的目的是什麼？最核心想達成的功能為何？什麼是達到功能的最小可檢視流程？這些才是最需要常常問自己的問題。不斷的探索使用者遇到的問題，嘗試想出各種滿足需求的可能，去驗證它，分享它，再回頭去看看和大方向是不是一致。等到組合成一個夠完整的解決方案，再回頭去思考其它和需求比較沒有關連的問題或是優化產品的效能。
如果擔心一開始的程式規劃無法面對未來的變化，那就要在每一次的開發流程中，導入重構的技術。去相信重構的技術能幫助我們重新設計程式規劃，然後，開始進行吧！
第一個版本在哪裡？prototype？
產品終究是要給自己以外的人使用，所以，可展示的版本，或稱之為產品的原型，是發展的里程碑。最終目標太遠，往往會讓人失去想要達成的動力。最好能夠早一點作出能夠給別人看的原型產品，一來目標較近，有機會能在燒完全部熱情前完成，二來可以聽聽其它人對於這個東西的看法，能夠早一點作出修改，或是增強部分功能的力度。總之，都要比自己閉門造車完成後，才發現不合交通法規上不了路的好。也許現在的想法有一些未盡理想之處，不過就像前面所說的，總是要先起了個頭，才能知道要如何改進，才知道對的方向在哪裡。
沒有留言:
張貼留言