Posts

Showing posts from October, 2018

ProductTank Taipei #12 - 大型組織的產品管理與協作

Image
難得提早到現場,開了電腦正在準備,突然發現 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.) 但其實提完需求後,需求也只是被加入到「需求池」,進入漫長的排隊中。 在大公司中事情太多,沒辦法一次只做一件事情,每個人需要同時多工處…