基於現任軟體PM的角色，同時也自己下海寫一些東西，對於軟體的切入角度，有了許多不同的認識跟想法，剛好同事有天提到了《約耳續談軟體：探究軟體經營的根本實學》(已絕版)，就跟同事借來，每天抽點時間把它啃完之後，也留下一些自己的心得跟記錄，也許再過一段時間回頭來看，也可以知道自己實證了多少。
這本書(中文版)出版至今，也已過了七年多，我想這本書對於軟體相關產業的人來，應該看過的各路高手也不少，甚至對於RD來說，不是純技術相關的書還留在身邊的，應該有它精闢之處吧？(至少我是這麼想的)
其實隨手Google一下，也可以找到不少有關這本書的心得跟想法，畢竟原作者(Joel on Software)也是大神等級的存在，不過我還是習慣在陌生的狀態下去看一本書、一部電影或是一個人，畢竟太早有先入為主的觀念，往往容易失去看清全貌的機會。
不過，因為知道這本書有點歷史，所以對於裡面很多的舉例，都是約在十年前的產物或是故事，也比較能夠接受，這應該算是我在開始看這本書前唯一的先入為主吧？(不過，自己也其實都還跟得上那段歷史，真不知是好是壞)
這本書一共9大部分36個章節，我當然不可能像寫作業一般，對於每一部份、每一個章節去寫下想法，畢竟一本書，對於每個人來說，總是可以產生出一些不同的衝擊、想法，我這邊只引用九大部分的部分標題來記錄自己對於看完這本書的一些想法。
人員管理：
在書中提到了不少跟程式設計師(RD)共處的方式，還有一些管理技巧，雖然我不是RD們的直屬主管，不過，我自認跟RD還算能夠打成一片(?)，在這互動當中，自己也深知沒有一定正確的方式，對於每一個RD，我相信也沒有一招適用全部的做法，不過，有些他們一定需要的是：認同、尊重，以及每個人都需要的空間與時間。
但是，在現實生活中，我相信還是要基於管理者對於每個RD的瞭解程度，而有所斟酌，畢竟寫過程式的人都知道，在一天之中，其實真的在產出程式碼的時間，其實比重並不高，更多時候是在(該死的)開會、構思(想著快點回家打怪)、釐清(有但不一定看得懂的SA、SD文件)或統整相關資訊(怎麼可以搶到心愛的限量品)的時間，一般來說，若有50%的時間在產出，就已經很不得了。
當然這也跟身處於純軟體公司或是公司內的軟體資訊部門又有著天差地遠的差異，其實這本書中也提及了不少相關的實例，這邊也不多加贅述。
不過，簡單說：無論是軟體或其它的人員管理上，認同、尊重，是留給真得懂得自律跟能夠對於自己的承諾，並且能履行95%的人，一定有人會覺得很奇怪，那剩下的5%呢？
那是留給非預期狀況所產生的容錯空間，同時也是管理者需要多擔下的部份，因為，那時需要的是怎麼解決問題的共識，而不需要一直在找代罪羔羊證明自己沒錯，至少，絕不是當下最重要的事。
因此，才留有那5%的空間，每個人都有可能會犯錯，況且，若只是一心想著把責任或風險推出去，甚至是在別人面前演一場打小孩的戲，那是件消費自己信用，同時也損傷自己團隊信心的利刃。
雖說如此，我想身處軟體業界的各位，看看彼此周遭，再回頭來想想自己身處什麼角色？正在做什麼事情呢？有時靜下來看看，會很有感觸。
管理大型專案：
書中提及的大型專案，我想也不是一般人真有機會可以碰得到，畢竟作者在微軟待過，看完它在大型專案管理的描述後，也讓我更理解專案規模的大小，其實會有很多不同面向的決定。
有時因為特定的時空背景或過往的餘毒，得要進行不得不的處置方式(workaround solution)，但是，對於這種過渡時期所產生出來的狀況，未來也會變成另一種型態的技術債，對於軟體本身，它都會是一個需要被持續追蹤及管控的部分。
或許沒有辦法砍掉重寫(那是一件風險極高的事，愈是穩定的軟體，帶來的影響愈大)，但是在未來有餘力，或是對於純軟體公司來說，它勢必是未來得要面對的一部份，短則半年，長則在下一個年度就應該做出適當的處置，否則最後它可能會成為壓倒自己的最後一根稻草。
反過來說，這也是為什麼公司內的軟體部門，經常會對看起來奇妙的設計早已見怪不怪呢？
因為當下做出來的產品很有可能生命週期短到嚇人，甚至是實驗性質的都有，因此，高效率的產出成品(?)，很多時候會比完善來得更為重要。
不過，對於還在學習跟熟稔核心技能的RD來說，這樣子的環境究竟是好是壞，就讓大家自己思索，況且，在那樣子的環境之下，那還有心力來統一變數形態，讓RD彼此之間，能夠更快地看出錯誤在那？。
更別提還想要在趕時程的狀況下，遵循著特定的Coding Style，或是很快地能夠融入正在趕東西的團隊，尤其是在多人分工專案上，經常會看見每個人都像關起門來進行困獸之鬥，結果外面早已在思索著怎麼用機器來取代馬戲團了。
總使能夠快速地接軌，成為專案內的急戰力，只要遭遇到「不平等」的感受，卻又無法得到救贖的拼命三郎，比較的心態絕對也不亞於在市場吆喝砍價的婆婆媽媽們，只是他們往往不擅長說出口而已，或是再也不將重心擺在眼前的事情上。
這也可以看出在團隊中，一個消極面對問題的管理者，往往才是Co-Work失敗最大的主因，縱使能力資質有差異，但是怎麼把對的人放在對的位置，同時讓它們持續精進，才是團隊最需要的管理者吧？畢竟管理者真的下來親自Coding的時間也不太多了吧？
無論是那一種狀況，對於團體(公司)、個人(主管)或產品(專案)來說，應該是三輸的狀況吧？
其實這也與專案(產品)及整個團隊的工作文化有關，當你發現RD流動率為何如此之高，或是產品總是看不見能見度時，就該停下角度思索一下，究竟環節錯在那兒，當然，若是問題出在自己身上(默)，可能就需要天時、地利、人和，才有機會看清事實(當然也有可能刻意不想看)。
這時候若身旁有個還願意說真話且有實際可執行對策的人，相信我，愈在關鍵時刻愈能發現他所存在的價值，如果連這樣子的人都先一步背棄了，也似乎只能自求多福。
開創軟體事業及經營軟體業務：
作者在書中常以自己創立的問題追蹤軟體為例，因此，在整本書中，很多時候可以看見他以實例說明，更能夠證實它所提及的論點及實證，只是不知有多少買家是因為他的書而買了他的軟體？也是種很棒的行銷方式。
不過，他的許多做法，對於軟體來說，的確有很多不錯的見解，例：原始碼型態提供軟體、近乎無損的退貨(款)流程、發版方式、定價策略(嗯...這一點它不算有說，不過很值得參考他所提的評估方式)，以及重要功能的篩選方式等。
我想對於軟體圈來說，應該很多人心裡都會有過一個夢想，希望自己也可以做出個屬於自己的產品，開創屬於自己的軟體事業並能夠經營、茁壯，不過，大家也都清楚新創的成功率往往不到一成，更何況是軟體的新創，可能在集資平台上也相對少了許多。(因為硬體的集資至少還可以拿到實品，軟體的就...上Google Play or APP Store ???)
雖然，近幾年有幾個不錯軟體或平台，被海外的大公司併購或是獲得高額的資金，挾帶著實力跟資金能夠走出台灣，進軍亞洲或全球市場。
不過，身處台灣還是有不得不面對的現實，那個靠著免費服務來拉攏到大量使用族群，再來透過流量換現的方式，其實愈來愈不可行，至少在新創或限定台灣地區的服務來說，更是如此。
作者切入的角度，也是我吸引我的地方之一，雖然美國的市場跟文化也非台灣所能比擬，對於一個能夠確實抓到供需的服務或平台，其實還是有它能夠生存的價值(例：特定應用領域的SDK，就可以一直賣一直賣....)。
或許，以現在的新創軟體來說，小而精美或許比大型巨獸來得更為容易生存，唯一要擔心的就是目前機器學習和AI可能帶來的衝擊。
當然，以現代人網路不離身的習慣來說，若是你能夠想到一個免費服務(內容網站？你自己先去實做一個出來再說吧？)，進而拉攏到夠多的使用者(千萬或破億等級？)，那絕對也是能夠大紅大紫，只是你得先確定在你等待使用者成長的過程中，有足夠的銀彈可以燒，或是你那微薄的點擊廣告費用足以支撐你一直持續下去的熱情？
有人或許會說現在的雲端服務比以前便宜多了，應該不會太難撐吧？
請自己去刷卡租個一台機器試試，就知道它究竟貴或是不貴了，不要太過習慣於公司保護傘或不是自己的錢，你會看見更多值得你在意的成本與效能，不信的話，你可以去問問有些內容平台的經營者，反而會擔心流量太高，尤其是無效流量，無法轉換成有效利潤時的傷害有多大。
這本書其實還有許多值得一提的部份，但是對我來說，上述這些，對我來說價值，可能遠高於其它部分，如同我一開始所說，每本書對於每個人總是能夠產生不一樣的共鳴，剩下的就留給各位自己去挖掘屬於你自己的天空吧。
沒有留言:
張貼留言