DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> WEB網站前端 >> 關於網頁技巧 >> 產品研發流程:細節黑洞時間
產品研發流程:細節黑洞時間
編輯:關於網頁技巧     

是的,就是這樣,因為要快,所以我們在趕進度,我們忘記了產品邏輯,凌亂了產品架構,忽視了頁面流。這部分時間在排期的時候被忽略了,而這就是個大大的細節時間黑洞,這個黑洞影響著我們每一個產品

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

在這個快字的指導下我們省去了對詳細MRD的撰寫,采用了列出功能點的方式向研發團隊講述整個產品的邏輯與核心需求點;因為要快速,所以我們采用初略原型的方式直接像工程師展示我們需要的產品架構和頁面邏輯;因為要快所以產品人員在描述的時候很激昂的描述了我們要做的高優先級系統,並且說這些系統是我們最至關重要的地方,我們高優先級先把這些重點搞通;研發人員在聽完整個的需求描述與初略的原型之後迅速做出評估,給出研發排期,於是群情亢奮的就開始干了……

這一切看上去很美好,不是嗎?我們比以前快多了,我們也有突出的重點了。但是事情真的是這樣嗎?

當大體的排期做完了,需求也通過了。下面研發人員開始做後端的架構和程序邏輯的架構了,產品人員開始對之前的需求做梳理,對原型做細化,設計師也開始嘗試視覺風格了。這次我們采用了並行的方式,我們要比之前進步多了吧。

很多時候,事情就是這樣奇妙,不梳理不知道一梳理嚇一跳。原來當時我們在考慮展示部分的時候沒有考慮到不同的用戶流導向的頁面不一樣啊;原來一個簡單的數據提交過程有如此多的分叉口並導向不同的後端數據處理策略。產品人員認為,這些都是應該重新歸納出來的,於是之前一個展示頁面被細分為N個不同的展示樣式;之前的一個提交流程被分拆成M個不一樣的處理策略。挨個模塊的這麼梳理下去之後原來簡單的一個原型被弄的好生完美,原來一個看似美好的頁面結構被修剪的異常豐滿。而之前產品人員認為“比較簡單,重點突出”的系統被證明是一個很復雜的很重的系統。當然,這個過程是後端工程師和產品設計師共同梳理完成。

這個時候,問題出現了。按照之前的需求描述和原型講解研發工程師預估的時間在每個系統上都多出來了一倍多。產品人員在不斷的“完善”頁面邏輯和產品架構,研發工程師在不斷的增加研發成本。最終,當研發周期過去大半的時候我們發現,靠!剛做完第一個階段…..於是,大家都急了,咋辦?!砍功能吧,把低優先級的東西先干掉,先做“核心”的事情。一陣的手忙腳亂之後,還是比預期的晚了幾周,上線了一個勉強過的去的版本。

那麼,在這個案例中整個產品研發過程的問題出在哪?自我反思,我認為是產品人員造成“細節黑洞時間”過長,導致工程師對研發過於樂觀,項目開發周期評估失常。不過,問題的症結還是在於快的過頭了,因為快所以忘記了一些雖然笨重但仍舊行之有效的方式。

在需求的初期,產品人員並沒有能夠很好的將業務邏輯轉換成產品邏輯。整個業務的核心鏈條是什麼?用戶被什麼動力所驅動,這些動力在產品上由什麼來體現?圍繞這個核心鏈條哪些是我們必須要做的產品模塊?

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

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

是的,就是這樣,因為要快,所以我們在趕進度,我們忘記了產品邏輯,凌亂了產品架構,忽視了頁面流。這部分時間在排期的時候被忽略了,而這就是個大大的細節時間黑洞,這個黑洞影響著我們每一個產品。如果在研發過程中,我們發現之前的邏輯是錯誤的,那麼問題將更加嚴重……

當然,這個案例中提到的情況還是相對可控的,因為產品人員有相對獨立的控制權。如果再有權力高層摻合進來,不斷的增加功能,不斷的釋放需求,那麼,整個產品研發過程將更加糟糕了。最近微博上流行一張圖,那才是真正的糾結(點這裡圍觀)

最後,提到“唯快不破”,忍不住多唠叨一句。不要被“互聯網產品唯快不破”帶到溝裡了,這句話原本沒錯,但是要注意2個前提:第一槍一定要打響,不然以後你就算再勃起的高也沒人看了;在快的同時需要考慮自己是否有能力應對“快問題”並及時完美解決掉,是否有足夠精力應付快之後被拉長的戰線,不然就是快刀子也容易剌到手!

特別說明:細節黑洞時間這個詞來源於一條微博,作者畫了一張很大很糾結的一個產品研發流程。看完頗多感受,結合自己的感受寫出了以上文字。

XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved