這是最近做產(chǎn)品的一些雜感。放在FB 有不少回響所以貼過來。

做產(chǎn)品= 「解決問題」

很多人做產(chǎn)品，包括我很久以前做產(chǎn)品。其實(shí)都犯了一個(gè)很大的謬誤。就是太早寫code，甚至是說太早寫spec。

做產(chǎn)品，精確地來說，就是在「解決問題」。

很多產(chǎn)品之所以會失敗，就是可能下決定的那個(gè)人（有可能是CEO，有可能是PM ）看到了問題，先做了第一個(gè)假設(shè)性的解法，并決定將之implement。

因?yàn)檫@個(gè)假設(shè)性的解法，很可能是有盲點(diǎn)的。但CEO或PM 下了命令，它必須得執(zhí)行。團(tuán)隊(duì)覆對實(shí)作手法產(chǎn)生了矛盾大吵特吵。經(jīng)過了大半天，合作的眾人才可能發(fā)現(xiàn)。原先被設(shè)定的解法，可能是錯(cuò)誤的。

甚至當(dāng)初被武斷所下的結(jié)論，甚至也可能是錯(cuò)誤的。甚至再追溯下去，還可能發(fā)現(xiàn)原來的那個(gè)問題是假問題。

一旦太早由個(gè)人所推出的結(jié)論規(guī)格化，并且放到整組人馬的生產(chǎn)線上。后面自然可能巨幅浪費(fèi)資源，甚至可能因?yàn)槠渌孀踊蛘螁栴}再也難以回頭。

由這個(gè)主題延伸談下去的部分可以往下繼續(xù)談：

• 創(chuàng)業(yè)MVP
• 寫code 是否tdd, 是否需要早期架構(gòu)封裝化
• 好的稱職PM 應(yīng)該為團(tuán)隊(duì)做什么

創(chuàng)業(yè)MVP

一些活躍的網(wǎng)路從業(yè)人員，創(chuàng)業(yè)的pattern 是：因?yàn)橛兄康腸oding 技術(shù)或者其他網(wǎng)路資源，所以想創(chuàng)業(yè)時(shí)第一想到的就是蓋平臺=> 找錢?；蛘呤窍葘慶ode 再pitch 找錢。

事實(shí)上這是錯(cuò)的。

創(chuàng)業(yè)，實(shí)質(zhì)上就是解決問題并將之商業(yè)化。

要先找到了想付錢的買家，再有了初步方案，再透過前幾筆的銷售確定的這個(gè)解決方法可以work。再想要把這個(gè)過程automated 化。automated 的這一步才是寫code。

之所以為什么很多時(shí)候，想發(fā)包給接案公司的客戶或者是公司內(nèi)部的PM 連User Story 都寫不出來。那是因?yàn)樗具B自己的商業(yè)模型都沒有run 透想通。既然沒有想通，何來automated 化。

這中間大部份的實(shí)作者（aka RD）都沒有錯(cuò)，因?yàn)樵诓恢滥阆虢鉀Q什么問題之前，能做的只是能憑借著過去的經(jīng)歷與想像把類似的模型蓋出來。

創(chuàng)業(yè)與做產(chǎn)品就是在一個(gè)一個(gè)回覆客訴與處理危機(jī)的過程中，慢慢把模型砌出來。

當(dāng)然，沒有人說這個(gè)成本很低。

只是大部分沒有悟通這件事的人，會選擇在一開始就想閃避這件事的風(fēng)險(xiǎn)，例如一開始就創(chuàng)業(yè)者「想建立平臺讓大家上來用」，PM 一開始就寫出「詳細(xì)的規(guī)格」。

結(jié)果在中間實(shí)做Interact 的時(shí)候造成了更大的風(fēng)險(xiǎn)，甚至產(chǎn)生結(jié)不了案，錢提早用完的悲劇。

開發(fā)產(chǎn)品是否需要TDD，是否在早期就需要將架構(gòu)封裝化

實(shí)際上寫code 的也是會遇到類似的狀況。

有些個(gè)性過于要求完美的RD，也是會做出類似的事。明明只是一個(gè)簡單的功能，卻Over Architecture。程式碼很漂亮，但是改不動。

程式碼只是表達(dá)解決方案的一種手段。

Over Architecture 或過于封裝的程式碼往往不是去除程式債，反而是新增的程式債。

因?yàn)檫@些人的過于封裝，不是增加Story 的可讀性或維護(hù)性，他們的修改手法，反而恰恰把User Story 支解到無法辨讀。大大造成隊(duì)友擴(kuò)充功能或者修改方向的困難。

同理，什么時(shí)機(jī)寫Test

• （后補(bǔ)Test ) 你已有了粗略的方案，你想要將之塑形化，并且希望他不會在意料之外的情境下發(fā)生。同時(shí)避免其他人以后修改這段程式碼時(shí)，破壞了執(zhí)行結(jié)果。
• （先寫Test ) 你手上拿到了一個(gè)非常清楚只是要重復(fù)的方案。你要用結(jié)果驗(yàn)證你的automated 方案是無誤的。

程式碼的干凈度與創(chuàng)業(yè)成功的因果關(guān)系

同理，Code 的干凈度與創(chuàng)業(yè)成功也沒有正相關(guān)，至少，在最初期沒有正相關(guān)。

Code 的干凈度與Project 成功的正相關(guān)度是受到RD 教育訓(xùn)練的影響產(chǎn)生的迷思。

大多數(shù)成功的專案，專案code 都很惡心。至少在一開始很惡心。創(chuàng)業(yè)要的是正確的解決方案，而不是優(yōu)美的coding style。就如同創(chuàng)業(yè)公司的Stage 演變。沒有人care 你是怎么優(yōu)美的解決，人人只要買解決，而不是你多優(yōu)美的解決。

什么時(shí)候code會變得干凈，當(dāng)你有A round的錢，B round的錢時(shí)候。有錢hire資深人士refactor的時(shí)候。
你的「生意模式」需要「塑形化」，需要「水平擴(kuò)展」化。這時(shí)候你的code就會變得干凈。

不是一開始你的code 就「先行塑形」「先行水平擴(kuò)展」，那么就會成功。而是一開始的主意works，由生意驅(qū)動的refactor。才帶來后面的clean code。

只是人人往往倒果為因。

PM 的職責(zé)

PM 的職責(zé)是什么？

既然創(chuàng)業(yè)做產(chǎn)品是解決問題。PM 的職責(zé)是負(fù)責(zé)去搜羅資源負(fù)責(zé)讓實(shí)作者更能設(shè)計(jì)出正確方案的或者接近類似方案的人。而不是「方案制定者」。

很多爛網(wǎng)路公司的產(chǎn)品會失敗，是因?yàn)檎埩瞬欢畬?shí)作的PM 亂寫規(guī)格，導(dǎo)致的黑暗混亂與巨幅浪費(fèi)資源。之所以這些PM 不懂實(shí)作，是許多RD 認(rèn)為「搜羅資源與需求」不需要技術(shù)（他們自己也懶，而且RD 喜歡寫code 當(dāng)戰(zhàn)士勝于在前面當(dāng)坦克）。

而PM 又認(rèn)為自己是”Manager”，既然他負(fù)責(zé)搜羅這些資源，就有權(quán)力引導(dǎo)甚至是決定專案的方向。

如果你仔細(xì)觀察，打造出成功產(chǎn)品的PM ，往往有技術(shù)背景。

一個(gè)成功的PM，應(yīng)該具備下列特性

• 能夠協(xié)助Unpack 問題本身
• 能夠協(xié)助引導(dǎo)討論方向
• 能夠協(xié)助搜集幫助討論方向的資源
• 具備一定的實(shí)作能力知道資源的限制與Tradeoff
• 引導(dǎo)溝通
• 緊盯資源的花費(fèi)與加速或放慢專案的進(jìn)度
• 花上大量的時(shí)間與專注力在improve 團(tuán)隊(duì)溝通速度與方法

因?yàn)閷?shí)作產(chǎn)品，本身就是一件協(xié)調(diào)眾人之力，厘清問題，溝通，Prototype，Implement 并balance resource 的過程。

來源：http://blog.xdite.net/posts/2015/04/11/some-thoughts-on-building-products