Ying @ Taiwan

難得提早到現場，開了電腦正在準備，突然發現 Peter 正在遠端連線，抓圖時才發現，原來人在荷蘭的 Peter 今天是遠端分享，算是很特別的經驗。 Celine 「裸辭」上一份工作後，輾轉到了中國的攜程工作。直接破題的 Celine 以攜程旅遊網的首頁為例，告知頁面信息的排序，事實上並不只是考慮使用者的閱讀習慣與興趣，而是依據組織內部的角力，哪個組織收付的佣金夠多，排序就會提前，例如：酒店、機票、旅遊等區塊，就會有所上下排序調整。 Celine 的工作是後端的靜態信息組。攜程分為垂直式、水平式分工，垂直式分工意指從後端信息整合、API 接口到前台的 App UI 呈現和實作，水平式分工則指當重要功能需要整合時，便需要拉出平行橫跨並進的規劃作法。 在大公司工作讓 Celine 覺得任務非常複雜，例如做「需求調研」時，若功能橫跨各信息組或功能組，則一個需求便是牽一髮動全身，需要橫跨各組做繁複的溝通，甚至要召開【需求澄清會】，遭受各組的炮轟，最後再回去重寫。 若想要做一個扁平的東西，仍然需要跟開發努力爭取資源，並跟各部門 PK 優先，甚至談好資源之後，若開發部門有緊急事件，仍會不告知值接插隊延後需求實作，而為了功能，測試資源也是稀缺資源要透過血淋淋的爭取。 很多事情即使講很多次，還是會有人聽不懂！ Celine 分享開發產品時的四個主要步驟： 需求調研 需求評審 開發測試 優化迭代 理想的狀況是這樣的： 需求調研 - 開發、內部/外部訪談、PRD 撰寫 需求評審 - 內部評審、外部評審 開發測試 - 敏捷開發、測試 優化迭代 - 投訴處理、收集需求 現實中是這樣： 需求調研 - 查出接口的所有調用方、調研開發可行性、召開 N 遍 需求澄清會、梳理業務流程 需求評審 - 到 N 個部門講 N 遍 需求、跟各部門 PK 優先級、預先爭取測試資源 開發測試 - 講 N 遍 需求、確認開發負責人、開發功能微調、跨部門溝通 優化迭代 - 跨部門講 N 遍 需求、修 bug、運營流程優化、用戶反饋整理 Celine 接著分享攜程內部常用的操作方式： 盡量找到大部分的調用方（stakeholder） 項目管理工具（JIRA-cp4 + Teambetion, Lengoo, etc.） 但其實