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

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

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

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

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

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

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

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

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

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

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

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

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

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