特別說明：細(xì)節(jié)黑洞時(shí)間這個(gè)詞來源于一條微博，作者畫了一張很大很糾結(jié)的一個(gè)產(chǎn)品研發(fā)流程。看完頗多感慨感染，結(jié)合自己的感慨感染寫出了以上文字。

    最后，提到“唯快不破”，忍不住多嘮叨一句。不要被“互聯(lián)網(wǎng)產(chǎn)品唯快不破”帶到溝里了，這句話原本沒錯(cuò)，但是要留意2個(gè)條件：第一槍一定要打響，不然以后你就算再勃起的高也沒人看了；在快的同時(shí)需要考慮自己是否有能力應(yīng)對(duì)“快題目”并及時(shí)完美解決掉，是否有足夠精力應(yīng)付快之后被拉長的戰(zhàn)線，不然就是快刀子也輕易剌得手！

    當(dāng)然，這個(gè)案例中提到的情況仍是相對(duì)可控的，由于產(chǎn)品職員有相對(duì)獨(dú)立的控制權(quán)。假如再有權(quán)力高層摻合進(jìn)來，不斷的增加功能，不斷的開釋需求，那么，整個(gè)產(chǎn)品研發(fā)過程將更加糟糕了。最近微博上流行一張圖，那才是真正的糾結(jié)（點(diǎn)這里圍觀）

    是的，就是這樣，由于要快，所以我們?cè)谮s進(jìn)度，我們健忘了產(chǎn)品邏輯，凌亂了產(chǎn)品架構(gòu)，忽視了頁面流。這部門時(shí)間在排期的時(shí)候被忽略了，而這就是個(gè)大大的細(xì)節(jié)時(shí)間黑洞，這個(gè)黑洞影響著我們每一個(gè)產(chǎn)品。假如在研發(fā)過程中，我們發(fā)現(xiàn)之前的邏輯是錯(cuò)誤的，那么題目將更加嚴(yán)峻……

    當(dāng)大的產(chǎn)品架構(gòu)出來之后接下來要做的事情是按照每條支線模擬一遍流程，使用流程圖的方式來做，每個(gè)模塊都需要。一般的處理方式是直接用相關(guān)的頁面原型來走流程圖，每個(gè)頁面的下一個(gè)頁面是什么，有幾個(gè)支線，分別導(dǎo)向了什么頁面。這樣走一遍之后就能最大程度的避免“細(xì)節(jié)時(shí)間黑洞”。

    業(yè)務(wù)邏輯的轉(zhuǎn)換凌亂必定導(dǎo)致產(chǎn)品大的架構(gòu)凌亂。按照我個(gè)人的習(xí)慣，在任何一個(gè)產(chǎn)品甚至產(chǎn)品模塊開始之前都需要先畫一張產(chǎn)品架構(gòu)圖，這個(gè)架構(gòu)圖會(huì)存在在MRD的最前面和原型圖的最前面。這樣有2個(gè)好處，產(chǎn)品自己可以很好的梳理整個(gè)產(chǎn)品的結(jié)構(gòu)及每個(gè)支點(diǎn)假如有風(fēng)險(xiǎn)會(huì)影響的范圍；需求被傳遞的時(shí)候下一個(gè)流程能夠先很清楚的有所認(rèn)知。

    在需求的初期，產(chǎn)品職員并沒有能夠很好的將業(yè)務(wù)邏輯轉(zhuǎn)換成產(chǎn)品邏輯。整個(gè)業(yè)務(wù)的核心鏈條是什么？用戶被什么動(dòng)力所驅(qū)動(dòng)，這些動(dòng)力在產(chǎn)品上由什么來體現(xiàn)？圍繞這個(gè)核心鏈條哪些是我們必需要做的產(chǎn)品模塊？

    那么，在這個(gè)案例中整個(gè)產(chǎn)品研發(fā)過程的題目出在哪？自我反思，我以為是產(chǎn)品職員造成“細(xì)節(jié)黑洞時(shí)間”過長，導(dǎo)致工程師對(duì)研發(fā)過于樂觀，項(xiàng)目開發(fā)周期評(píng)估變態(tài)。不外，題目的癥結(jié)仍是在于快的過頭了，由于快所以健忘了一些固然粗笨但仍然行之有效的方式。

    這個(gè)時(shí)候，題目泛起了。按照之前的需求描述和原型講解研發(fā)工程師預(yù)估的時(shí)間在每個(gè)系統(tǒng)上都多出來了一倍多。產(chǎn)品職員在不斷的“完善”頁面邏輯和產(chǎn)品架構(gòu)，研發(fā)工程師在不斷的增加研發(fā)本錢。終極，當(dāng)研發(fā)周期過去大半的時(shí)候我們發(fā)現(xiàn)，靠！剛做完第一個(gè)階段…..于是，大家都急了，咋辦？！砍功能吧，把低優(yōu)先級(jí)的東西先干掉，先做“核心”的事情。一陣的手忙腳亂之后，仍是比預(yù)期的晚了幾周，上線了一個(gè)委曲過的去的版本。

    良多時(shí)候，事情就是這樣奇妙，不梳理不知道一梳理嚇一跳。原來當(dāng)時(shí)我們?cè)诳紤]展示部門的時(shí)候沒有考慮到不同的用戶流導(dǎo)向的頁面不一樣啊；原來一個(gè)簡樸的數(shù)據(jù)提交過程有如斯多的分叉口并導(dǎo)向不同的后端數(shù)據(jù)處理策略。產(chǎn)品職員以為，這些都是應(yīng)該重新歸納出來的，于是之前一個(gè)展示頁面被細(xì)分為N個(gè)不同的展示樣式；之前的一個(gè)提交流程被分拆成M個(gè)不一樣的處理策略。挨個(gè)模塊的這么梳理下去之后原來簡樸的一個(gè)原型被弄的好生完美，原來一個(gè)看似夸姣的頁面結(jié)構(gòu)被修剪的異常飽滿。而之前產(chǎn)品職員以為“比較簡樸，重點(diǎn)凸起”的系統(tǒng)被證實(shí)是一個(gè)很復(fù)雜的很重的系統(tǒng)。當(dāng)然，這個(gè)過程是后端工程師和產(chǎn)品設(shè)計(jì)師共同梳理完成。

    當(dāng)大體的排期做完了，需求也通過了。下面研發(fā)職員開始做后真?zhèn)€架構(gòu)和程序邏輯的架構(gòu)了，產(chǎn)品職員開始對(duì)之前的需求做梳理，對(duì)原型做細(xì)化，設(shè)計(jì)師也開始嘗試視覺風(fēng)格了。這次我們采用了并行的方式，我們要比之條件高多了吧。

    這一切看上去很夸姣，不是嗎？我們比以前快多了，我們也有凸起的重點(diǎn)了。但是事情真的是這樣嗎？

    在這個(gè)快字的指導(dǎo)下我們省去了對(duì)具體MRD的撰寫，采用了列出功能點(diǎn)的方式向網(wǎng)站建設(shè)研發(fā)團(tuán)隊(duì)講述整個(gè)產(chǎn)品的邏輯與核心需求點(diǎn)；由于要快速，所以我們采用初略原型的方式直接像工程師展示我們需要的產(chǎn)品架構(gòu)和頁面邏輯；由于要快所以產(chǎn)品職員在描述的時(shí)候很激動(dòng)慷慨的描述了我們要做的高優(yōu)先級(jí)系統(tǒng)，并且說這些系統(tǒng)是我們最至關(guān)重要的地方，我們高優(yōu)先級(jí)先把這些重點(diǎn)搞通；研發(fā)職員在聽完整個(gè)的需求描述與初略的原型之后迅速做出評(píng)估，給出研發(fā)排期，于是群情亢奮的就開始干了……

    在最早的時(shí)候產(chǎn)品設(shè)計(jì)大多采用瀑布模型方式做迭代，上一個(gè)流程完畢之后才進(jìn)入到下一個(gè)流程。這種模式有一個(gè)最大的好處就是下一個(gè)流程的預(yù)備相對(duì)充分，但是缺陷也顯而易見，那就是迭代本錢太大且顯得粗笨。跟著互聯(lián)網(wǎng)行業(yè)的發(fā)展，“快”成了這個(gè)行業(yè)最重要的一個(gè)口訣，于是類似“唯快不破”成為大受追捧的產(chǎn)品設(shè)計(jì)哲學(xué)。于此同時(shí)，良多項(xiàng)目的設(shè)計(jì)周期被縮短。