新創團隊合作與專案開發心得
隨著自己的工程職涯漸漸變老鳥，心中也歸納出一些工作習慣，來整理這些工作心得當紀錄，要分享給晚輩也比較方便。
前情提要：
以下分享大多以新創團隊、公司為情境，所謂「新創」不一定是指剛成立的小公司，但他跟傳統的大公司確實有許多不同，比如彈性的上下班時間，不強制在辦公室上工，當然，被賦予的任務還是會在另一個時間、地點完成。
其中團隊以敏捷思維開發，大膽嘗試新工具，不論是在新的商業模式下創新，或是跟傳統龍頭品牌競爭，分秒都是在跟時間賽跑，團隊的產品、功能生產速度與持續發布，就視代表性的特色。能夠早一天發布新服務，取得媒體曝光、吸引顧客目光、收集資料等等，這些都是搶得先機的關鍵，一切行事風格因應油然而生。
- 新創辦公室
新創辦公室大多是開放的大空間，公開透明，找人快速方便就是其特性，部分公司也會打造咖啡吧台、遊戲室，與運動區域等，期望活絡的氣息可以為團隊互動帶來更多生產力。
但以沒有隔間的辦公空間，當然存在著一些缺點，例如味道干擾(如果有人習慣在座位飲食 XD)，討論的講話聲量干擾等，此時要建議，如果找人討論不是短時間可以解決的，就盡量往個人工作區以外的區域(會議室，簡報室等)，減少個體上的思緒互相干擾。
- 例行上工起手式
一般來講在處理大專案(複雜度高的邏輯等)需要有高度專注，不被干擾的時段，若被其他事件打斷，有可能回到座位又要花好幾分鐘回到剛剛的思緒，所以準備開始進入自己的世界時，可以留意稍後的覓食、預定會議，而提前安排。
如個人事務類型是容易被詢問打斷者，建議拋出預約制，有計畫性的撥時間處理各種事物，會讓每日執行項目的思緒比較清晰；當然，上述並不是指個人進入勿擾模式就都不理外在了，整體還是要看當下外務的重要優先度。
團隊中若有類似 call center，負責收集問題轉發的值日生，這也是有助於團隊成員被各種大小問題轟炸的頻率。
關於日常工作，如果是以週會模式安排，個人建議是一個大票搭配幾個小票
這邊的票(task)就是一般被賦予的工作，可能是內部需求，功能修改，專案項目等等呼應提過的敏捷，我們會希望團隊產出是好追蹤進度的，若整體時程要一個月才完成的專案，仍會希望是切成可以每週能夠具體審視 review 的階段，而大票搭配一些小票來處理，目的是避免手上同時有兩的大票來回修改，這容易造成兩邊時程都耽誤。
實務上小票適合的幾種情境處理：
例如剛吃飽回來，距離稍後會議還有一小段時間
快下班了但還有零碎時間可以處理部分事務，
巡視公司 email，近期上線系統 log，主機服務回報管道有無異常，
也包含工作頻道 line, slack 等有無重要未讀訊息。
- 收票處理
當公司規模事務大到一個程度，通常不會只用 email，通訊軟體平台作為事務交辦的工具。
比如 Asana 是在作為賦予任務跟追蹤是蠻強大的平台工作除了會議上的討論，開立與接收，也可能來自於公司中其他組別的開票，因為週會上已經有安排自己預定要處理的項目，對於突如其來的票若是來者不拒，就可能影響到自己的既有進度。
以屬性來區分，一種是許願票，開需求的人可能會希望、建議產品多什麼功能，這類建議回到主管身上，在周會時重新檢視重要性與優先度。
另一種是 bug 票，此時就建議把回報範本建立好，教育大家要把資訊寫清楚，這些都有助於收票者(值日生)解析、轉發這個問題的速度。
問題回報欄位包含問題網址，畫面，發生裝置(如果是 app，可以包含版本，如果是瀏覽器也可以多詢問)，情境能否重現問題，維度更細可能有：角色，輸入變數，時間點，並且幫票下一些適當標籤或是群組。收到問題的票，仍要先釐清這是認知差異，還是與當初需求描述，文件描述不同？判斷問題類型跟處理優先度是蠻重要的工作
❗️補充：若是跟核心業務、關鍵營收有關的問題，請在大群大聲喊
請養成開票習慣，這對於忙碌夥伴來講比較不容易忘記 (口頭答應，有可能被另一個外務插隊就忘了)，有開票，背後有具體紀錄最近在忙什麼，避免像是無頭蒼蠅忙一整天卻沒什麼產出，拉長時間也可以統整出哪些業務應該要有更好的自動化作業，去改善這些痛點。
- 功能開發中遇到規格異動，需求追加
幾個思考點，需要看改動是否與原本規劃的設計差太多？(retro 會議可以拿出來討論)若是核心邏輯，業務價值鏈有關，建議需追加調整，若要加太多工時就要審慎評估，能否改下階段再處理？不影響目前主功能架構，則建議下階段處理在敏捷的思維盡量減少擴大戰場。
站在程式開發所建立的分支(branch) 對應至 PR(pull request)角度，避免把無關的主題放在同一個 commit 、 PR中，若該分支有問題需要退版(roll back)時，結果另一個更動也得一起復原。
- 面對使用者建議
思考背後的合理性，邏輯性，改善操作UX或是速度上的助益？
若平台本身是多種角色的 (比如拍賣平台有買家賣家)，也得留意改了某東西雖然對 A 很好，卻對 B 不友善，且對另一群使用者有更大的負面影響，中間的拿捏最好是考慮到多重視角的平衡。
- 部分需求耗費成本是否划算
收到一件任務做某件事情，要同時思考、評估背後的效益。
以新的主打功能，背後帶來多少新客？多少營收，或解決的問題間接減少人工處理多少時間？若效益太低，或發生頻率低，可能就維持個案手動處理
比買東西客服為例，如退貨運費大於商品價值，是否就不收了？針對難搞的案例，是否直接送購物金？(處理例外狀況的時間成本遠大於贈送購物金)
但也要留意，如會造成影響品牌好感的客訴類型案件，則需要慎重處理。
如收到跨部門的撈取數據需求，別急著馬上執行，要先問自己跟對方，這樣的報表有什麼幫助？會不會撈完之後對方又說他其實想看別的？
幾個觀察協助判斷，偶爾看一次的數據，且 SQL 很快就順手幫忙，若是實驗中、分析中的東西不急著包到系統中。若有行銷夥伴願意學 SQL 也可以教他簡單的語法，透過測試與唯讀 DB 讓他自己摸索。若是重要且應該開放多人檢視建議排入後台功能。報表沒有太多客製化要求的亦可考慮用 google data studio 呈現。
- 確定要把某個寫死功能，改動態系統化
其中的變數、變動仍可依情境去選擇當下最省時的做法，如果久久改動一次(每年才發生一次的活動公告？)，就不急著開發後台，程式去改動上版就是了，就是最快的做法。若異動越來越高，則可把關鍵變數對應至資料庫，讓更新不用經過系統發布流程(此時還不一定要開發編輯用的後台)。
若異動頻率高且有專職維護者，這時就很適合開發後台讓當事者自己編輯
(比如商品，活動注意事項等等)
- 分階段上線的思維
為什麼不在發布產品時，就推出100分的作品？
以搶曝光，搶市佔率等先機角度，速度佔有極大優勢，但要推出完美的成品，往往需要更多時間去調整。
以 MVP （Minimum Viable Product）的精神可以協助在這方面的進行，
在規劃大專案切分階段計畫時，要保持每個階段都能推出可上線的目標。
以最後生產一台汽車目標為例，階段性產出不是一次推出一個方向盤或幾個輪子，而是能以先推出滑板車，接著三輪車、機車到最後的汽車的概念。所以如果團隊中有完美主義者，也試著去說服對方別堅持全部東西做好才一起上線，分階段產出有他的好處。
- 越早越有利的事
站在數據追蹤角度，某些動作當你知道後就要儘早啟動。
比如不知道使用者偏好什麼，某頁面或某功能的幫助性？對於業務成長過程，埋事件與追蹤通常可以讓我們更加了解目標族群。網站事件追蹤的工具有很多，也有分免費、限量免費或是收費(無效又量大的再停掉) 。
以 GA 為例，content group 是設定後才會開始收資料，越早設定就可以看到越早的歷史資料。
如果介面上的新設計，focus 熱點追蹤或是 click event，都可以用來評估使用者是否關注該區塊，點擊率、pageviews 等數據都是協助決策優化的重點跟順序。
除了問卷訪談，系統可以用一些 AB test 機制去觀察使用者迴響，決定某東西是要繼續優化還是要就此關閉。
- 關於系統穩定性
公司發展的業務已經相當成熟，代表每一刻都有線上使用者，這樣的情境在處理做主機升級或例行發佈，就要多留意備援機制，保持服務不中斷，體驗會比較好。換言之，如果是初期很少人在線上的系統，要做停機也不用考慮太多關於離峰或是影響使用者權益的問題。
實務經驗，以新功能要搭配新的資料表欄位，可以把後端功能拆兩階段上線：
第一段純做 DB migrate (比如單純新增資料表或是欄位)
第二階段再上有取到新欄位的功能 (此時資料源已經 ready)
若是團隊在研發的功能還算是實驗中，初期不用花太嚴謹漂亮的工程架構
(比如做好根本沒人用？)，如視角為自己人使用(比較有容錯空間)，比較能先上線，後續再收集反饋繼續調整。
還有另一種思維，以棒球比賽為例，雖然投手表現往往左右勝負，當無法三振對手時，把被擊出的球交給野手協防也是一種策略。
亦即，上線之前工程團隊實在無法保證一定沒問題，不如就大膽推出，在基礎設施有搭配健全的錯誤追蹤與警報系統，再用最快的時間去進行修復。
- 實作前規劃與討論
以上線追求高品質的穩定性，事前的測試與 code review 相對重要，而實作前規劃的目的是為了縮短實際開發時間與 code review 階段的修改，在這個過程可以讓兩個人以上，確認邏輯改動有沒有瑕疵，是否再跟需求者、PM 再次確認規格，目標與範疇。
以開發網頁為情境，實際功能端若有前後端兩位工程，亦可先定義好溝通的API介面與 json 結構，讓兩位開發進度不互卡。若 api 也有提供 app 使用，則建議用完整的 api 工具去定義，例如：Swagger、Apiary
因為 api 可能被舊版 app 呼叫，保留 api 歷史改動紀錄相對重要。- 在開發與發佈上的衝刺
為了搶上線時效性，可能讓工程前端後端同時動工(在約好溝通規格後)，後續整合測試與 code review 也可能是同時進行。此時有個議題，會有測試都 ok 後因為 review 改動又有失敗，或是 review 過了，但測試有漏而需要修改的多次 review。不同的檢測時機點各有利弊，站在慎重的多次審視角度，
無疑就是想避免 bug 發生在最後追加的 commit 上。
若功能模組已經導入自動化測試，就可以減少失誤。- 面對開發或是團隊的負面情緒
每當火箭發射就抱著緊張又怕受傷害嗎？
程式都難免有 bug，站在正面的角度，就在每次的出槌案例中，去反思是規劃不夠仔細，還是測試涵蓋度不夠，團隊溝通合作不夠契合？
以 retro (Sprint Retrospective Meeting)的進行，團隊成員持續溝通，找出個人與團隊能一起進步的方式，分享各種卡點以及可能的解法，從中聆聽學習、嘗試與回饋。
- 構思適當程式架構及避免過度設計
有經驗的工程師在開發功能時，也會針對未來可能的需求變更去預留彈性，比如之後會切換資料儲存點，或新增第三方金流付款。
呼應物件導向的開放封閉原則，在設計當下這個類別時，把可能的情況考慮進去。
中間的不變是被精煉過的抽象，透過介面設計進行隔離。當擴充時盡量漸少從UI到底層都需要跟著異動的狀況。在一般原則下，開發程式盡量遵循 SOLID 原則，讓程式模組間有良好的耦合關係。在遵守良好的開發心法之餘，同時我們也要留意 over design，亦即當一個未知的需求在短期、中期根本不會有，那不如就把這份工程成本省下來，等真的遇到了再來調整。
後記：把隨手筆記整理一番發現還蠻長的，有些歸納為心法是很精鍊但可能是有遇過的人才懂，部分情境有案例輔助會比較白話(有遇到新的好例子會再補充)。針對比較偏軟體工程等工具或小撇步，之後有空再分享。😛