## 產品設計體會(五)——有關流程
這次談一下網店版項目從小到大,直到最近幾周整理出來的日常需求發布流程(寫完發現流程本身沒有談及,下周再說吧)。
?
去年底項目最初的時候,完全是白板一塊,當時連要做什么都不知道,所以靠的是幾位老大和我們依靠“隨機應變”式的個人控制來把握項目進程,那時每個人都對產品的一切非常了解。對一個需求的響應速度超快,可能晚上發布,下午PD還會直接跟開發提一個需求,而開發也馬上就開始coding了,完了測試點兩下沒問題也就上去了。這種猛打猛沖團隊的核心優勢就如一位著名人士所說——天下武功,無堅不破,唯快不破(《功夫》里的火云邪神)。
?
到 了后來,加入的人越來越多,產品也越來越龐大,特別是最近幾周,越來越感覺已經不能掌握產品的全部,經常需要詢問別人,有的時候甚至找不到一個知道的人。 (插話:不過這似乎也有一點好處,那就是當你對一個產品不太熟悉的時候才更容易體會到產品是否易用,這在對產品了如指掌的時候是體會不到的,昨天QA也笑言我們經常做一些超越人類理解力、違背人類常識的東西。)
?
項目龐大了以后,再依靠個人英雄主義是不行的,那樣英雄會累死,項目也會失敗。這時候出現的流程和規范都是一種管理的方法。在淘寶UED群blog上看到一句話很認同:設計流程的目標,在于保證“無論誰來做這個產品的設計,都能達到80分”。沒錯,80分已經很難了,當產品越大的時候,誕生天才產品的概率也就越小。“又快又穩定又有才”的產品是可遇不可求的。
?
華為的同學也跟我說過他對流程的體會:流程的好處是人走了,事還能做,減少特定的人的影響。一個事情總是有它的兩面,想到一個故事作為結尾:說古代有個名餐館有幸花重金請到了御膳房的一名廚子,老板畢恭畢敬的請他做一道拿手菜。
廚子:我不會做菜。
老板:啊?
廚子:我只是御膳房“調料部”的。
老板非常失望,轉而又想調料也不錯啊,很重要,至少能嘗到地道的宮廷味道,于是又畢恭畢敬的說:那煩請大師做一份宮廷特制的調料吧。
廚子:這個我也不會。
老板:啊?
廚子:我是調料部“青蔥組”的。
老板:……,轉而一想,實在不行就嘗個宮廷的蔥味吧!
廚子:我也不會做蔥的全部……
……
廚子:我是負責切蔥的……
- 前言
- (一)——變態吧,開始帖周報了
- (二)——數據分析
- (三)——性價比:做不做?
- (四)——需求管理
- (五)——有關流程
- (六)——再談流程
- (七)——需求探針
- (八)——產品與項目
- (九)——關于學習
- (十)——團隊合作
- (十一)——市場掃描
- (十二)——少而精
- (十三)——再說需求分析
- (十四)——做過的幾個項目
- (十五)——PM、PD、UE與UI
- (十六)——Feature List
- (十七)——PD的幾種文檔
- (十八)——概念設計
- (十九)——UPA年會的流水賬
- (二十)——有關改版
- (二二)——封閉開發
- (二三)——用戶研究
- (二五)——當交互設計遇到敏捷開發
- (二六)——PD就是出來賣的
- (二七)——大產品設計
- (二八)——細節之文案
- (二九)——產品設計的五個層次
- (三十)——“體會”導讀的思維導圖
- (三二)——零散的體會
- (三三)——用戶大會
- (三四)——土老板破冰必殺技
- (三五)——QA與測試
- (三六)——再理解“敏捷”
- (三七)——可用性測試
- (三八)——項目外包!=開發外包
- (三九)——CSDN專訪精編版
- (四十)——銷售渠道
- (四一)——用戶創意無限
- (四二)——又是零散體會
- (四三)——說說評審會
- (四四)——項目外包不適合“敏捷”?
- (四五)——外行眼中的技術分工
- (四六)——UML學習摘錄(上)
- (四七)——UML學習摘錄(下)
- (四八)——資源戰爭與BRD
- (四九)——產品市場化
- (五十)——終點:Matrix
- (五一)——敏捷的估計與規劃
- (五二)——MS Office使用心得
- (五三)——產品文檔與規范
- (五四)——PD招聘廣告詞
- (五五)——項目Kick Off
- (五六)——《需求工程》培訓記錄
- (五八)——《項目化管理》培訓記錄