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

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

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

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

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

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

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

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

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

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

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

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

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

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