新創團隊合作與專案開發心得

隨著自己的工程職涯漸漸變老鳥,心中也歸納出一些工作習慣,來整理這些工作心得當紀錄,要分享給晚輩也比較方便。

前情提要:
以下分享大多以新創團隊、公司為情境,所謂「新創」不一定是指剛成立的小公司,但他跟傳統的大公司確實有許多不同,比如彈性的上下班時間,不強制在辦公室上工,當然,被賦予的任務還是會在另一個時間、地點完成。

其中團隊以敏捷思維開發,大膽嘗試新工具,不論是在新的商業模式下創新,或是跟傳統龍頭品牌競爭,分秒都是在跟時間賽跑,團隊的產品、功能生產速度與持續發布,就視代表性的特色。能夠早一天發布新服務,取得媒體曝光、吸引顧客目光、收集資料等等,這些都是搶得先機的關鍵,一切行事風格因應油然而生。

  • 新創辦公室

新創辦公室大多是開放的大空間,公開透明,找人快速方便就是其特性,部分公司也會打造咖啡吧台、遊戲室,與運動區域等,期望活絡的氣息可以為團隊互動帶來更多生產力。
但以沒有隔間的辦公空間,當然存在著一些缺點,例如味道干擾(如果有人習慣在座位飲食 XD),討論的講話聲量干擾等,此時要建議,如果找人討論不是短時間可以解決的,就盡量往個人工作區以外的區域(會議室,簡報室等),減少個體上的思緒互相干擾。

如果辦公空間有貓,是加分還是干擾請自行評估 XD
  • 例行上工起手式

一般來講在處理大專案(複雜度高的邏輯等)需要有高度專注,不被干擾的時段,若被其他事件打斷,有可能回到座位又要花好幾分鐘回到剛剛的思緒,所以準備開始進入自己的世界時,可以留意稍後的覓食、預定會議,而提前安排。

如個人事務類型是容易被詢問打斷者,建議拋出預約制,有計畫性的撥時間處理各種事物,會讓每日執行項目的思緒比較清晰;當然,上述並不是指個人進入勿擾模式就都不理外在了,整體還是要看當下外務的重要優先度。

團隊中若有類似 call center,負責收集問題轉發的值日生,這也是有助於團隊成員被各種大小問題轟炸的頻率。

關於日常工作,如果是以週會模式安排,個人建議是一個大票搭配幾個小票

呼應提過的敏捷,我們會希望團隊產出是好追蹤進度的,若整體時程要一個月才完成的專案,仍會希望是切成可以每週能夠具體審視 review 的階段,而大票搭配一些小票來處理,目的是避免手上同時有兩的大票來回修改,這容易造成兩邊時程都耽誤。

實務上小票適合的幾種情境處理:
例如剛吃飽回來,距離稍後會議還有一小段時間
快下班了但還有零碎時間可以處理部分事務,
巡視公司 email,近期上線系統 log,主機服務回報管道有無異常,
也包含工作頻道 line, slack 等有無重要未讀訊息。

  • 收票處理

當公司規模事務大到一個程度,通常不會只用 email,通訊軟體平台作為事務交辦的工具。

工作除了會議上的討論,開立與接收,也可能來自於公司中其他組別的開票,因為週會上已經有安排自己預定要處理的項目,對於突如其來的票若是來者不拒,就可能影響到自己的既有進度。
以屬性來區分,一種是許願票,開需求的人可能會希望、建議產品多什麼功能,這類建議回到主管身上,在周會時重新檢視重要性與優先度。
另一種是 bug 票,此時就建議把回報範本建立好,教育大家要把資訊寫清楚,這些都有助於收票者(值日生)解析、轉發這個問題的速度。

收到問題的票,仍要先釐清這是認知差異,還是與當初需求描述,文件描述不同?判斷問題類型跟處理優先度是蠻重要的工作

❗️補充:若是跟核心業務、關鍵營收有關的問題,請在大群大聲喊

請養成開票習慣,這對於忙碌夥伴來講比較不容易忘記 (口頭答應,有可能被另一個外務插隊就忘了),有開票,背後有具體紀錄最近在忙什麼,避免像是無頭蒼蠅忙一整天卻沒什麼產出,拉長時間也可以統整出哪些業務應該要有更好的自動化作業,去改善這些痛點。

  • 功能開發中遇到規格異動,需求追加

幾個思考點,需要看改動是否與原本規劃的設計差太多?(retro 會議可以拿出來討論)若是核心邏輯,業務價值鏈有關,建議需追加調整,若要加太多工時就要審慎評估,能否改下階段再處理?不影響目前主功能架構,則建議下階段處理在敏捷的思維盡量減少擴大戰場。

站在程式開發所建立的分支(branch) 對應至 PR(pull request)角度,避免把無關的主題放在同一個 commit 、 PR中,若該分支有問題需要退版(roll back)時,結果另一個更動也得一起復原。

  • 面對使用者建議

思考背後的合理性,邏輯性,改善操作UX或是速度上的助益?
若平台本身是多種角色的 (比如拍賣平台有買家賣家),也得留意改了某東西雖然對 A 很好,卻對 B 不友善,且對另一群使用者有更大的負面影響,中間的拿捏最好是考慮到多重視角的平衡。

  • 部分需求耗費成本是否划算

收到一件任務做某件事情,要同時思考、評估背後的效益。
以新的主打功能,背後帶來多少新客?多少營收,或解決的問題間接減少人工處理多少時間?若效益太低,或發生頻率低,可能就維持個案手動處理
比買東西客服為例,如退貨運費大於商品價值,是否就不收了?針對難搞的案例,是否直接送購物金?(處理例外狀況的時間成本遠大於贈送購物金)
但也要留意,如會造成影響品牌好感的客訴類型案件,則需要慎重處理。

如收到跨部門的撈取數據需求,別急著馬上執行,要先問自己跟對方,這樣的報表有什麼幫助?會不會撈完之後對方又說他其實想看別的?

幾個觀察協助判斷,偶爾看一次的數據,且 SQL 很快就順手幫忙,若是實驗中、分析中的東西不急著包到系統中。若有行銷夥伴願意學 SQL 也可以教他簡單的語法,透過測試與唯讀 DB 讓他自己摸索。若是重要且應該開放多人檢視建議排入後台功能。報表沒有太多客製化要求的亦可考慮用 google data studio 呈現。

  • 確定要把某個寫死功能,改動態系統化

其中的變數、變動仍可依情境去選擇當下最省時的做法,如果久久改動一次(每年才發生一次的活動公告?),就不急著開發後台,程式去改動上版就是了,就是最快的做法。若異動越來越高,則可把關鍵變數對應至資料庫,讓更新不用經過系統發布流程(此時還不一定要開發編輯用的後台)。
若異動頻率高且有專職維護者,這時就很適合開發後台讓當事者自己編輯
(比如商品,活動注意事項等等)

  • 分階段上線的思維

為什麼不在發布產品時,就推出100分的作品?
以搶曝光,搶市佔率等先機角度,速度佔有極大優勢,但要推出完美的成品,往往需要更多時間去調整。
以 MVP (Minimum Viable Product)的精神可以協助在這方面的進行,
在規劃大專案切分階段計畫時,要保持每個階段都能推出可上線的目標。

MVP
MVP
Author/Copyright holder: Henrik Kniberg. Copyright terms and licence: All rights reserved

所以如果團隊中有完美主義者,也試著去說服對方別堅持全部東西做好才一起上線,分階段產出有他的好處。

  • 越早越有利的事

站在數據追蹤角度,某些動作當你知道後就要儘早啟動。
比如不知道使用者偏好什麼,某頁面或某功能的幫助性?對於業務成長過程,埋事件與追蹤通常可以讓我們更加了解目標族群。網站事件追蹤的工具有很多,也有分免費、限量免費或是收費(無效又量大的再停掉) 。
以 GA 為例,content group 是設定後才會開始收資料,越早設定就可以看到越早的歷史資料。

如果介面上的新設計,focus 熱點追蹤或是 click event,都可以用來評估使用者是否關注該區塊,點擊率、pageviews 等數據都是協助決策優化的重點跟順序。

除了問卷訪談,系統可以用一些 AB test 機制去觀察使用者迴響,決定某東西是要繼續優化還是要就此關閉。

經過測試才知道貓咪喜歡什麼 XD
  • 關於系統穩定性

發展的業務已經相當成熟,代表每一刻都有線上使用者,這樣的情境在處理做主機升級或例行發佈,就要多留意備援機制,保持服務不中斷,體驗會比較好。換言之,如果是初期很少人在線上的系統,要做停機也不用考慮太多關於離峰或是影響使用者權益的問題。

實務經驗,以新功能要搭配新的資料表欄位,可以把後端功能拆兩階段上線:
第一段純做 DB migrate (比如單純新增資料表或是欄位)
第二階段再上有取到新欄位的功能 (此時資料源已經 ready)

若是團隊在研發的功能還算是實驗中,初期不用花太嚴謹漂亮的工程架構
(比如做好根本沒人用?),如視角為自己人使用(比較有容錯空間),比較能先上線,後續再收集反饋繼續調整。

還有另一種思維,以棒球比賽為例,雖然投手表現往往左右勝負,當無法三振對手時,把被擊出的球交給野手協防也是一種策略。
亦即,上線之前工程團隊實在無法保證一定沒問題,不如就大膽推出,在基礎設施有搭配健全的錯誤追蹤與警報系統,再用最快的時間去進行修復。

  • 實作前規劃與討論

以上線追求高品質的穩定性,事前的測試與 code review 相對重要,而實作前規劃的目的是為了縮短實際開發時間與 code review 階段的修改,在這個過程可以讓兩個人以上,確認邏輯改動有沒有瑕疵,是否再跟需求者、PM 再次確認規格,目標與範疇。

以開發網頁為情境,實際功能端若有前後端兩位工程,亦可先定義好溝通的API介面與 json 結構,讓兩位開發進度不互卡。若 api 也有提供 app 使用,則建議用完整的 api 工具去定義,例如:Swagger、Apiary

  • 在開發與發佈上的衝刺

為了搶上線時效性,可能讓工程前端後端同時動工(在約好溝通規格後),後續整合測試與 code review 也可能是同時進行。此時有個議題,會有測試都 ok 後因為 review 改動又有失敗,或是 review 過了,但測試有漏而需要修改的多次 review。不同的檢測時機點各有利弊,站在慎重的多次審視角度,
無疑就是想避免 bug 發生在最後追加的 commit 上。

  • 面對開發或是團隊的負面情緒

每當火箭發射就抱著緊張又怕受傷害嗎?
程式都難免有 bug,站在正面的角度,就在每次的出槌案例中,去反思是規劃不夠仔細,還是測試涵蓋度不夠,團隊溝通合作不夠契合?
以 retro (Sprint Retrospective Meeting)的進行,團隊成員持續溝通,找出個人與團隊能一起進步的方式,分享各種卡點以及可能的解法,從中聆聽學習、嘗試與回饋。

  • 構思適當程式架構及避免過度設計

有經驗的工程師在開發功能時,也會針對未來可能的需求變更去預留彈性,比如之後會切換資料儲存點,或新增第三方金流付款。

當擴充時盡量漸少從UI到底層都需要跟著異動的狀況。在一般原則下,開發程式盡量遵循 SOLID 原則,讓程式模組間有良好的耦合關係。在遵守良好的開發心法之餘,同時我們也要留意 over design,亦即當一個未知的需求在短期、中期根本不會有,那不如就把這份工程成本省下來,等真的遇到了再來調整。

後記:把隨手筆記整理一番發現還蠻長的,有些歸納為心法是很精鍊但可能是有遇過的人才懂,部分情境有案例輔助會比較白話(有遇到新的好例子會再補充)。針對比較偏軟體工程等工具或小撇步,之後有空再分享。😛

自然踏青認識土地,推廣友善環境,分享影像紀錄,持續關注文化

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store