2013年11月30日 星期六

[連載]新創公司歷險記-1:臨危受命,掌握資訊

        今年四月,正徘徊在職涯下一步的十字路口,當時剛好接到前同事電話力邀我加入一個剛成立半年的新創公司團隊,一起打造一個全新的新產品而努力。

        當時被原公司既有的營運系統基於管理上風險的考量,而搞得拳腳難伸的我,在與灰心喪志之下,很受眼前這個可以盡情嘗試各種全新技術與各種假設的創業機會所吸引,毅然訣然地揮別前公司

        由於要能盡情試驗新技術、開發流程與團隊合作的模式,我加入的條件就是我必須擔任掌握這些權力的  Team Lead(這篇)

        然而真正置身此處,才發現事情也沒有想像中那般美好。


        如今我們孵育的產品終於要推出市場接受真實的考驗。我一直想回顧與檢討這過程中我所採取的做法和決定,在產品推出的這個時間點,我想是最好不過。

        一直在猶豫到底這個連載該放在我專談論「工作與雜想」的部落格,或是「IT見聞與思維」的這裡,最後我決定以比較“技術性”軟體工程、專案管理、技術性抉擇)的方式來撰寫這個過程。

        剛進來,就發現這個已經 RUN 了半年的新創公司已經陷入產品開發進度嚴重落後的慘況,團隊成員能力青澀,解決問題能力有限,而大量採用的新穎的新技術也造成團隊冗長的瞎子摸象的適應期,讓我第一天到任就加班到超過凌晨,只為了解決最初股東用展示版本的佈署(Deployment)。

        原本我打算引入原公司無法實現的 SCRUM 開發方法,以及完整且全面性的『測試驅動開發』(TDD),在火燒屁股的專案時間限制下根本無法實現。

        面對用不熟悉的技術而已經亂了陣腳的團隊,我判斷這時候再冒然導入 SCRUM 和 TDD 改變他們的做事方式,只會落得水土不服,導至更嚴重的混亂和團隊對朝令夕改的反感情緒。

        當時團隊採用沒人熟悉的“全新”工具清單如下:
  • 全新沒用過的開發工具:VisualStudio 2012
  • 全新超難用的開發機 OSWindows 8
  • 全新超難用常用功能總是被藏起來的辦公軟體:Office 2012
  • 全新沒人熟悉的版本控管工具:GitHub(之前大家都是喝 SVN 奶水長大的,我的轉換新心得在此)
  • 全新的開發框架:.NET 4.5 + ASP.NET MVC4
  • 全新的 Web 溝通技術:.NET SignalR + WebSocket
  • 全新的竟然把手機平板的操作搬給伺服器用的白痴設計 Server OS:Windows Server 2012(完全是為了 IIS8 有 WebSocket 功能)
  • 全新的 Socket 通訊技術框架:ZeroMQ
  • 全新的資料封裝技術框架:Google ProtoBuf Message
        公司 CEO 曾說:「專案採用新技術的比例最好低於 30%,否則很容易有許多無法預期的風險讓專案進度失控。

        但我們當時大概採納了 50%~60% 的新東西吧?總之一團混亂下,我加入公司的第一週依計劃中的進度,部分系統就應該要衝 QAT 給 QA 測試,然後隔週股東從國外飛來台灣參訪看 DEMO。

        哈,我搶著當 Team Lead 的行為就好像搶著把自己人頭擺上斷頭台上,還怕讓給別人咧~。

        沒辦法多想怎麼導入我原本期望中的東西,當務之急是『掌握專案實際進度』、『釐清工作順序』、『確保計劃發生』。

        SCRUM 裡面我能先借用的,就是 Daily stand-up meeting,只不過我改良成 Daily “sit-down” meeting⋯⋯XD。

        我的 Daily meeting 的三大重點:
  1. 回報「昨天我完成什麼」?
  2. 若昨天的項目沒有如期完成,原因為何?遇到什麼樣的阻礙、困難?
  3. 宣告「今天預計要完成什麼」?
        這讓我每天一早都可以更新最新的工作進度情報,並且儘早知道開發所遇到的障礙,急救的效果非常好。

        但沒多久我就發現,團隊成員回報的“完成”,和我理解的“完成”差別很大,常常我聽到某人回報說“已經完成”,然後我派人接續後面的開發立刻壞掉,後面整合的人做不下去。

        然後追問之下,得到類似以下的答覆:

        「我完成的是“程式碼撰寫”,但我“還沒測試過”
        「我完成的是“我目前能做的部分”,剩下沒做的是在等 B 寫完,我才能繼續
        「我完成的是“基本功能”,你只能用我 hardcode 的測試資料來呼叫我
        「我完成的是“正常使用的流程”還沒做“資料驗證”或是“錯誤處理”,你必須送正確的資料給我才行。
        最經典的,就是說:“寫完了”就下班,結果別人要進行整合時卻找不到那個東西,然後通電話追問,居然給我回答說:「我寫完啦,但是“還沒 commit 和 push”

        會不會想丟筆、摔電話?

        這讓我在掌握實際進度與工作派工上非常困擾,於是我利用一次晨會,非常慎重的跟團隊對“完成”兩字,作了明確的定義 - DoD(Definition of Done)。
Completed = Deliverable
Partial completed = Partial Deliverable
IF the part is unable to be delivered, the part doesn't existed (0%)
完成多少 = 交付多少
部分完成 = 部分交付 
別人無法接手的部分 = 該部分視同完成度 0%
        也就是說,你交不出來的東西,別人無法接手,無法幫你修 BUG,我就當這東西不存在,當你混了一天什麼都沒做。什麼完成 50%、70%,只要別人看不到摸不著,就當你這數字喊爽喊虛的,是真實還是吹牛我分不出來,就毫無意義。

        接著我採取每週一個 Sprint 的做法,透過 Google Doc 的雲端硬碟上的試算表做任務管理和進度控管,力求資訊共享、透明、準確,跟緊團隊緊追 Weekly goal 衝刺!



        掌握正確的局勢與確保團隊說出做到的共識,只是起手式,而後面還有許多嚴苛的挑戰必須面對⋯⋯。


未完待續

附錄,這過程中,我做出一些跟『人』相關的管理行動,在另一個針對工作雜想的部落格也略有所提:

Google+ Badge