DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> WEB網站前端 >> 關於網頁技巧 >> 互聯網產品設計:運營期產品評審的原則和方法
互聯網產品設計:運營期產品評審的原則和方法
編輯:關於網頁技巧     

   評審制度是互聯網產品管理的重要手段,評審制度貫穿於產品管理的戰略規劃、產品設計、技術實現、產品運營、產品營銷等各個環節。可以說高效的評審制度是一個公司產品管理能力的重要度量標准。簡單列舉一下評審制度的一些價值所在:
  • 通過評審制度可以幫助利益相關方達成對產品建設目標的一致理解;
  • 通過評審制度可以對產品規劃方案、產品需求方案、技術方案、運營方案、營銷方案等的質量進行把關,提升產品品質;
  • 通過評審制度可以對產品規劃建設過程中的關鍵點、風險點等進行把關,降低項目實施的風險
  • 通過評審制度可以有效提升參評人員的能力;
  • 通過評審制度來對方案進行把關,保證系統產品架構、架構設計的精神始終如一地貫徹下去

     盡管產品評審如此重要,但似乎沒有哪家公司的評審制度是高效的,大家都在抱怨評審制度的萬千罪惡,評審會議或是演變成了過形式,或是演變成了各大陣營的PK大會。關於評審制度,在各種軟件工程的圖書及方法論都有所涉及,這裡的重點不是討論評審制度的通用准則(例如產品評審那點事 ),這裡主要討論一下一個平台型的產品在運營過程中怎樣通過評審制度來把關。

1、建設期項目 VS. 運營期項目

   對於諸如支付平台、開放平台這類采用了產品平台理念的互聯網產品(產品平台),其處於建設期的產品的項目管理與處於運營期的產品的項目管理所面對的挑戰不盡相同。

   之所以強調這些產品平台,主要在於對於很多互聯網產品而言,主要邏輯就是網站前端,因此這些網站的評審相對容易,只需要采用原型驅動的方式。但對於這些平台化產品,不單純只是一個簡單的網站頁面開發工作,這些系統最復雜的邏輯一般在於後端的業務規則、業務邏輯,而這些並不是一個原型就能夠說明清楚的。

  1)、建設期項目特征

  • 項目周期相對長,例如1個月以上
  • 項目資源相對於充裕,可以以單獨項目組形式運作
  • 項目管理可采用傳統項目管理方式或者敏捷項目管理方式
  • 項目前期准備工作相對充裕,例如產品文檔相對完整、完整的原型、完整的項目計劃、項目立項討論會/需求討論會等、市場調研/競爭對手產品分析等等
  • 項目相對獨立,受到其他項目的約束較小

  2)、運營期項目特征

  • 周期較短,大部分為2周以下
  • 資源有限,項目組成員可能還要並發維護其他產品

      由於隨著公司業務的擴張,熟悉產品及技術架構的人員始終稀缺,這些人一般都去負責一些重點新項目,必須在工作中幫助新人熟悉系統

  • 項目管理一般采用諸如Scrum、XP這樣的敏捷項目管理方式,甚至是裁減過的敏捷開發
  • 項目准備並不是很充裕,也不可能准備充足後再做
  • 項目需要在現有產品基礎上進行優化、重構,不能影響現有系統。對於運營型產品,產品架構、系統架構的就是在一點一滴的修改中失控、變形的,必須有機制來控制這些因素

   這裡重點討論運營期的產品評審、技術評審的方法。

2、運營期產品評審的原則

  • 不管再緊急的項目都必須做產品評審、技術評審
  • 評審必須保持敏捷性
  • 評審的形式不重要,評審!=開會,評審的形式可以正式評審、也可以為非正式評審。評審最核心的是需要有熟悉系統、有能力的人對方案進行把關
  • 評審的目的不是找到最優的方案,而是在現有資源約束下最合理的方案
  • 沒有完美的評審制度,關鍵在實踐中持續優化評審制度,建立適合自己公司情況的評審制度及跟進措施

3、運營期產品評審的方法

      對於運營期的產品評審而言,並沒有最佳的實踐方案可供參考,每一家公司都有自己現實的業務狀況,不同的業務模式有不同的評審方式。可以說對運營期的產品進行高效評審是門平衡的藝術,必須均衡管理規范性、敏捷性、業務現實的要求。只不過整體而言,運營期產品評審的方法核心都是相同的:基於團隊協作前提下的持續完善。

  • 運營期的評審制度需要運營期的產品研發流程支撐。應當制定針對運營期產品研發的簡化流程(相對於建設期的產品研發流程而言),以便從其他流程環節的收集暴露評審制度的問題,來保證產品評審制度的持續優化。例如通過質量測試、運營、銷售、營銷等環節的反饋,發現評審制度失效的項目,納入到案例庫,持續優化研發流程、評審制度
  • 建立必須進行評審的硬性標准,細化成可量化的checklist形式(簡單為第一准則)

       例如開發時間1周以上或少於1周但涉及重點業務模塊的都必須過評審。之所以要采用工期及影響1刀切的方法而非采用接口人來評估是否需要評審,主要是避免太多的人為因素導致評審制度流於形式。

       對少於1周且不涉及重點業務模式改動的,由負責人來自行判斷。

  • 評審必須有利益相關者參與,不能單純讓產品人員、技術人員自己評。例如:產品方案必須有技術人員、運營人員、財務人員等;技術方案必須有產品人員、架構師、業務專家等。參與評審的利益相關者有權將方案打回重做。當然這有涉及到另外一個更大話題:團隊協作問題,如果一個團隊無法建立信任關系,那再完美的制度都會變成PK會。
  • 評審人不需要做全面評審,只對需求關鍵點、關鍵業務規則、風險點的方案做評審,以保證評審的高效性。評審結果需要記錄相關的流程表單中。
  • 建立評審案例庫,定期(每月)過評審案例庫,持續優化評審制度。評審案例的總結對事而非對人,不要讓評審人有必須對結果全面負責的負擔。

   一個制度的執行不在於制度最初定義得多麼的完美,關鍵在於制度能否持續不斷地優化。持續優化/持續改進/持續完善 是各種管理方法眾所周知且行之有效的核心秘密之一,但也是最難貫徹執行的,尤其是相對於那些管理時尚流行語,提持續改進太沒新意、太沒高度了,於是乎我們都指望有“銀彈”來解決面臨的各種問題。

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