1. 程式人生 > >敏捷設計,讓設計更高效

敏捷設計,讓設計更高效

眾所周知,微信是2011年1月21日進行釋出推出的,但是微信並不是第一個做社交軟體的,在微信前三個月就已經有米聊推出,更早的還有強大的中國移動在2007年推出的飛信。

但是,為什麼其他更早推向市場的產品為什麼後來在與微信的競爭中落於下風?

面對如此多的競爭對手,微信是這樣通過一系列的迭代以及功能的改進。

  • 利用QQ的導流優勢,迅速推出附近的人、漂流瓶等功能吸引使用者,
  • 在2012年8月23日推出微信公眾平臺,一大把的微信營銷案例又一次把微信放在在浪潮之上,
  • 在2014年1月27推出微信紅包,2015年除夕當日微信紅包收發總量達10.1億次,在創造了強大交易量的同時,微信紅包也為財付通的推廣打出一手好牌等等…

微信通過一系列的產品迭代,從而坐上社交軟體龍頭的位置,它並不是最開始面向市場的,但是它笑了最後。

我們不僅僅能由此得出微信的產品功能設計很棒,同時,我們也該明白:微信的迭代效率絕對是非常快的,在響應市場的把控上,是少有產品能比的。

前段時間針對下拉拍短視訊的功能,在經過使用者反饋之後,就在微信更新中進行了去除,足以可見響應之快。

同樣地,不僅是微信,對於其他的網際網路產品,產品的迭代效率都是十分重要的。

產品的迭代效率高可以讓產品更早推出釋出,搶佔先機佔領市場,同時容易快速試錯,通過使用者的反饋資料快速進行產品的迭代,這樣利於我們在市場上更穩地站好腳跟。

那麼,我們如何最大提高產品迭代效率?

在這裡,我先不談產品最初的開發釋出,以產品迭代為例子,詳細講述如何提高產品迭代效率——敏捷開發流程,這是一種流程,更是一種好的工作方式。

產品工作流程

如圖所示,這是詳細的流程表格,下面逐點進行分析。

背景

  • 產品型別:以上是以一個網站或APP簡單的迭代舉例
  • 開發週期:表格中設定的是兩週時間,實際操作中我們應該根據產品具體的迭代難度進行時間的調整,一切視情況而定。
  • 工作人員:參與迭代的工作人員涉及到產品、UE、UI、開發、測試,基本上網際網路公司都會涉及到這些崗位,小型的創業公司可能沒有UE,那麼一般是由產品經理完成,所以作為產品經理,原型圖以及互動體驗是必須要懂的,有時候測試人員不夠,同樣地,產品也要進行參與,所以,產品是苦逼的,大家要善待每一個產品經理。

工作流分析

我用灰色進行了標記,這是我們在產品設計過程中都會用到的流程,我將主要流程提取出來,便於檢視,如下圖。

工作流程

在產品迭代的過程中,根據每個人所負責具體的工作內容,進行合理的分配時間。

  1. 前期(前1/4時間):由產品經理進行驅動,進行公司產品戰略的參與,從而進行需求的採集與確定,根據競品分析以及使用者調研,進行產品原型的製作以及產品需求文件的撰寫,在這個過程中,需要與專案經理進行評審,瞭解產品的開發難度以及可行性,從而對產品需求以及原型圖進行合適地調整。
  2. 中期(1/4時間):由UE完善產品原型的互動細節,有關頁面的跳轉等使用者體驗做到極致,然後由UI設計師進行介面的設計美化,及時與產品經理進行溝通,設計出與產品經理所想要的效果出來,結合自身的設計理念和技術,將介面設計得人性化、扁平化。
  3. 後期(1/2時間):由開發人員進行產品具體的功能設計開發,根據專案進度安排時間,做好工作安排,認真檢視設計圖以及原型圖、產品需求不懂,不清楚的地方及時與產品經理進行溝通,以免辛苦做出的功能與產品的意思不符,造成浪費時間精力的後果,產品進行開發完成後,由測試人員根據測試用例進行測試,將出現的問題進行反饋,及時修復產品的bug,確保產品在規定的時間進行上線。

同樣地,我們通過圖中的流程,這也很容易解釋為什麼一旦產品出現問題,產品就成為當之無愧的背鍋俠,事實上,這怨不得其他人,好比造房子,產品的工作類似打地基,地基不好,房子會塌,房子塌了怪誰,地基打得不好,當然是產品。

在工作中產品經理特別需要注意的三個要點:

  1. 前期的產品戰略以及需求,產品經理都是參與其中的。特別是大的產品方向突出的功能點,你都必須全域性進行了解。對公司的戰略方向是否匹配,之後在產品的開發以及以後產品的迭代是否難度太大;這些問題一定要想清楚,想清楚,想清楚。重要的事情說三遍,不懂的就問,不斷地進行評審深入下去。因為一旦進入開發階段,突然變更需求,那麼這段時間的精力以及時間就浪費了,這對於公司的損傷是巨大的。
  2. 工作過程中,需要勤寫文件。一個人的記憶不可能會記住所有的東西,所以你必須記錄下來,這樣能更好地開展工作,在寫需求文件的時候,我們需要要對每個用詞定義緊摳,少用差不多、不確定等用詞來模糊定義,千萬不要以為需求文件開發不看,只看設計圖,起碼測試是需要根據你的需求文件寫測試用例的,所以需要慎重對待。
  3. 經常會有評審。在評審的過程中,與專案經理進行評審後,記得做記錄。哪些功能做,哪些功能不錯;什麼時間開始,什麼時間結束;這些都做好記錄。如果專案延期遭到老闆責罵,那麼你可以向你的上級表示你已經盡力。之前已經有記錄是與專案經理談好了工作進度安排的,當然責任不在你身上。

職位工作流程

在我們產品迭代的過程中,經常會遇到這樣的情況,因為只涉及到一個具體的工作流程,比如開發只負責開發,那麼在前期的需求採集確定以及UI設計等階段,他會無事可做,而如果真的是這樣的話,那就是上級沒水平工作安排不佳的問題。

產品

產品經理:

在產品迭代的過程中,產品經理是全程互動、全程參與的,產品經理主要是負責前期的需求採集分析、製作原型互動等工作,在之後的設計以及開發過程中,需要時刻地溝通跟進,確保需求傳達準確,根據原型圖進行功能開發,對細節的把控,以完成最終產品的迭代。

UE

UE:

貌似UE只負責一個產品原型互動細節,製作一個低保真原型圖就萬事大吉,事實上他也要涉及到一些必要的工作,在前期的需求採集,可以作為一個小白使用者參與到產品的構思,在完善產品互動細節後,對在互動設計上經常用到的方法制作一個正規化文件。(正規化文件:解決通用問題的通用方法,參照他人解決問題的方式,結合自身工作過程中解決問題的方式,進行統一的要求)

UI

UI:

同樣可以作為一個小白使用者參與到需求採集分析,便於產品經理集思廣益更全面洞悉使用者心理,在產品經理和UE製作原型互動的時候,可以為設計提前做準備,尋找此類產品的設計圖參考,對於介面風格以及具體的圖示進行素材的尋找,這都便於在之後的設計中提高設計的效率。

開發

開發:

在產品的需求採集階段,開發不進行參與的情況下,可以對上一個開發完成的產品進行總結,對一部分技術難點進行深入,對部分可簡化的程式碼給出程式碼規範,及時進行總結,在設計圖的製作過程中,檢視需求文件,對於需要做的功能點進行事先的深入研究,便於提高後期開發效率。

測試

測試:

及時檢視產品需求文件,根據產品需求文件中的內容進行測試用例的撰寫,做到細緻,如此一來便省去了之後測試過程中的一部分時間,對於測試過程中經常出現的問題,在文件中進行總結反饋給開發人員,減少出錯率。

總結

在產品迭代的過程中,合理地按照工作流程來執行工作,提高產品迭代的的效率,針對於個人的瀑布流工作方式,幫助個人在工作中及時進行總結,進行能力的提高,這些都再好不過。

何況,網際網路迭代的效率提高,產品的質量並沒有因此下降,對於市場的快速試錯,根據資料的反饋進行及時的戰略調整,讓產品在市場立於不敗之地。

對於工作流程,有問題大家可以和我多多交流。