AppWork #3 DEMO 觀後感

        Jamie 主辦的 AppWork 在上周五 ( 10/28 ) 精彩落幕。無法躬逢其盛的我，仍慶幸地看了現場錄影觀賞全程，有興趣的人可以在下方播放。

SOP 的迷思

        最近因為新系統上線，小組依循公司組織方向擬定了『當問題發生時，處理問題的 SOP』流程。這個流程基本上如下：

        使用者反應問題  >> 第一線人員判斷不在其管轄範圍 >> 第二線人員判斷不在其管轄範圍 >> 第三線人員 ( 我們 )。

        然而，前幾天，同為第三線的同事光桑發現系統的一個異常，然而這個異常使用者尚未察覺，也可能會拖很久都不會察覺，光桑站起來問：「按照這個 SOP 我現在該怎麼做？」

『開放平台軟體選秀競賽 - 創意激發網路新商機』會後感

        對 Android 手機開發有興趣的我，在網路上看到這屆黃金企鵝獎即將徵選的講座活動，今天便跟公司告假前往。本活動是由經濟部與台北市電腦公會主辦，也是少數我覺得政府真的有用心在辦的活動，因為這次邀請了許多在這個業界已經深耕並闖出一翻天的前輩，講述自己的心路歷程和分享非常寶貴的資訊，一整天的講座聽下來，內容真的著實精彩，幾無冷場，深深讓我獲益良多！

第一次真的從網路廣告上賺到錢

        去年年底到現在，我總共製做了兩支沒啥路用的 Android 手機應用程式，也曾經寫了一篇『首月成績分享』和『開發筆記』。如今時間已屆滿一季，是該再做一次季報的成績分享了對吧？哈，首先第一個好消息，就是當初投入 Android Market 上架費用的 USD$25 成本早已經回本了，我也確確實實地從 AdMob 收到這筆款項躺在我的 PayPal 帳戶內！這筆錢，不再只是看得到摸不著的紙上富貴！

失敗專案的教訓

        今天，收到客戶回傳的『專案取消同意書』，終結了我人生第一個失敗賠錢的專案。這個專案說來也創下我許多第一次經驗與嘗試，是值得回顧研究的特殊案例，也該好好想想原本是一個十拿九穩鈔票輕鬆入袋的專案，怎麼會搞到認賠收場這樣的結局？

        話說這個專案來得有趣，是因為我大學時期寫的一支 Freeware 工具程式，客戶因為想根據這個工具程式做出功能強化的版本而找上門。對方剛開始提出的功能需求，讓我覺得這個案子除了賺錢外，對我來說似乎沒有更多的附加價值，學不到新東西，程式碼也可能沒有再利用的機會。

        於是乎，一開始我就強調軟體量身訂做的費用高昂，對他不划算，採取比較高調的回應希望客戶知難而退。沒想到對方意志堅決不肯放棄，硬要我開出一個價碼。

        既然價格策略失敗，面對這樣吸血的條款客戶仍高興地抬高脖子面著我，卻也開啟我另一個經驗學習的機會－專案轉包。

        這個案子我估計的實際價值和我開出的價格有相當大的落差，工期也從只要一個月結束的東西，硬拉長到半年，轉包的利潤空間和時間上的緩衝俱在，加上專案本身技術層次不高，若轉包的下游出了問題，我不管是再次轉包他人或是自己跳下去完成，都在風險與獲利可以兼顧的範圍內。

        最重要的，我可以試試水溫，有實際的轉包管理與溝通經驗，增加我擴大工作室團隊的機會，這個原本學不到東西的案子換個方向竟然也可以讓我學到更多轉包管理的議題。

        怎麼看都覺得天時地利人和，是個機會。

        然而，從找人就是一種挑戰。在 104 和 JCASE 與程式設技俱樂部刊登外包專案，雖然一開始不少人來詢問，但是真正誠心願意回覆的人太少，大多喜歡讓案主空等，真不懂這心態是怎麼回事？還有人請他回覆報價和時程後竟然沉默了快一個月後，突然來信說他已經開發了七八成了，問這案子還能不能給他接，簡直莫名其妙。

        第一次當發案方的經驗，和事前的想像頗有差距，至少這些 SOHO 給我的感受是不好的。想想也該反省自己是否也犯了一樣的毛病，讓案主感到不受重視。至於發案如此不順，是否我的態度太過高傲讓其他 SOHO 一開始就有難纏奧客的預感？

        總之，發案的過程比我預料的要久，超過一個多月才找到有合作意願的 M 先生。

        初次與 M 先生見面時，有些訝異他的歲數，是個近五十歲的中年人，這跟我一開始期盼年輕有活力的工程師不同。在解說需求和規格說明過程中，我數次有溝通障礙與觀念鴻溝的感覺，對方一直想提出他自己的建議來修改我的規格。這本來也不是甚麼壞事，但簡單的東西一直想複雜化，做些畫蛇添足的舉動，以為好像物超所值，我還怕到時候做不出來無法如期交件呢！

        還好我們有約定檢核點，在第一次線上 UI 展示，就發覺 M 仍然依自己的意思擅改了架構和設計，或許也不見得是他擅改，而是真的是我和他的溝通與理解出了問題，總之展示出來的東西不是我要的。面對這個當下，就當磨練自己的溝通技巧，怎麼帶領下游把案子往正確的方向進行。於是我捨棄了原本的口述和電子郵件文字說明的方式，開始製作流程圖表的設計文件表達真正要的東西，管理面的工作開始浮現，這樣小小的案子竟然不是只有轉包賺差價這麼簡單，心想，以後更大型的專案這樣的設計文件真是不能少。

        就在好不容易跟 M 先生磨合了，這時候晴天霹靂的事情發生，原來我和上游原發案主對需求與規格認知本來就有落差！

        這個落差原來隱藏在案主言語沒有表達的言外之意。舉個例子，這就好比外包寫一個自動發信的軟體，對接案的工程師而言，就是一個可以給郵件地址清單自動化發信的程式，但對案主而言，這個發信軟體必須能躲避垃圾信的偵測並且成功寄入名單內的收件夾。

        工程師寫出了一個滿足自動化定義的寄信程式，但案主卻因為這個程式發出的信會被大部分的信相當垃圾信而拒絕驗收：「我花錢請人開發就是因為要躲過垃圾信偵測啊，不然我用現成的 outlook 就好還花大錢外包幹嘛？」

        當時我的盲點在於，誤解案主的重點在『自動化』上，完全沒想到過案主真正的重點其實在『躲避廣告信偵測』這件事上，而合約內文對這部分也並沒有明確的說明。畢竟發信軟體寄出的信對方會因未知的理由而收不到，這的確也可以歸咎為一個 bug。

        雖然發覺案情這樣的轉變，我立刻親自投入研究也學到些寶貴的經驗和技術，但考慮到這個案子一開始估計的方向就是錯誤的，不管報價或是時程都完全不同，想閉後續麻煩也會接踵而來，成為一個燙手山芋。於是抱著壯士斷腕的決心，我提議取消整個專案，將訂金全數退回。

        而對下游，我主動終結此案，自然是賠掉了已經支付給 M 先生的訂金和第一階段的款項。案子雖然不順利，但面對好不容易磨合的 M，至少保持了對方下次再合作的意願。

        「天下沒有白吃的午餐。」看到有人執意要花大錢做一個看似簡單的功能，就見獵心喜，把客戶當肥羊來宰，反而奠定了我失敗的報應。

        這次專案失敗的教訓，在於我只單純以工程師技術的角度來評估專案和需求，卻沒有真正關心案主到底是出於甚麼樣的原因要做這個案子。對於不是從技術觀點出發的客戶提出來的功能，我們更應該撇開技術觀點，嘗試用一般人的想法去引導與理解對方真正的需求在哪裡，畢竟出錢買單的是這些非技術出身的客戶，多點用心去理解他們，避免吃力不討好是應該的。

註：文中所提的發廣告信的軟體只是個方便理解的比喻，實際專案與此類功能並無關連。