產品開發流程|網際網路|敏捷

語言: CN / TW / HK

背景

現今我們很多工程師在實際工作中,可能工作許多年都還未能感受到自己所在組織產品或專案的開發流程到底是怎樣的,也不清楚自己在團隊中為何存在,應該如何表現才能在團隊中出類拔萃。

大部分原因就在於我們自己對於組織的結構和流程沒有太多關注,自己沒有明確的職業規劃,或是沒有意識到自己在團隊中應如何努力才能得到領導的賞識和肯定。說到底就是我們的認知和覺醒力還不夠,一個在於自己沒有被開發,另一個在於當前國內的環境,特別是中小型公司更多是勞動力輸出型,對於職業發展引導方面比較少。

本章將通過產品開發流程和研發過程中專案管理的基本內容帶大家一起了解下,算是拋磚引玉,希望能給職業發展遇到瓶頸的你一些幫助。

產品開發流程

產品開發整體流程

以上流程基本上是絕大多數公司產品開發的流程了,不同組織結構的公司可能各個環節所執行的粗細粒度不一樣而已,但大體方向應該不會有太大偏差。流程中“專案立項”-->...-->“部署運維”為專案管理過程

產品設計

產品設計,首選需求的來源,針對於自主研發的產品,需求可能來源與市場,或是目標使用者以及與組織對於這個產品的對外能力所關係到的涉眾物件;而對於一些定製專案,特別是外包專案,需求一般都來源與甲方(準確來說,來源與甲方以及甲方目標系統所涉及到的涉眾群體),甲方作為需求提供方,收集了所有涉眾需求。這個過程中有個非常關鍵的動作就是將使用者需求轉換為產品需求,我們也可以將這個過程稱為需求分析;需求分析:從使用者提出的需求出發,挖掘使用者內心真正的目標,並轉為為產品需求的過程。

我們在做需求分析過程中,需要考慮如何將使用者需求轉化為產品需求,在這個過程中我們更多需要去研究任性,瞭解使用者提出這個需求背後的真正目的是什麼。

在本章主要介紹,在組織中實際進行產品開發產品設計的過程。如下圖所示

如上圖所示,在產品設計過程中,輸入是MRD文件,也就是《市場需求文件》提前對使用者需求,商業價值以及技術難度等做了提前的推算和分析。最後確定立項才正式進入專案開發環節,專案過程中即對產品進行原型設計,原型測試以及高保真等方面的設計,其目的在於能夠更好的與使用者或是需求方描述滿足需求的產品方案。另一方面在於後期可以與研發團隊有一個比較好的銜接,一般會形成PRD文件。在PRD文件中主要描述產品的整體功能框架,詳細流程,以及各個功能模組的關聯關係等內容,形成文案的方式,交付給研發團隊,其目的是讓研發團隊指導產品想做什麼。

以上流程看是比較正常,其實經過筆者多年的團隊管理實踐來看,這種模式未必是一種比較優越的方式,因為在這個過程中,開發團隊接收到的是經過產品分析設計後的產品,很多時候,開發是比較難知道這個軟體產品最終使用的客戶到底是要解決什麼問題,為何推演出來的這個產品設計。從而一定程度上會導致研發工程師偏離真實需求,照單幹活的情況。

軟體開發

在學校特別是學習《軟體工程》專業的夥伴,一定是知道軟體開發模型的,比如瀑布模型、演化模型、增量模型、螺旋模型、快速原型模型、噴泉模型、V模型等。

與開發模型一樣,對應的開發方法也是很多,比如:迭代開發方法、快速應用開發方法、基於構建的開發方法、統一開發方法、敏捷開發方法、模型驅動開發方法、基於構建的開發方法等。

以上都是一些開發過程或方法。

專案管理

在專案管理圈,同行都有一句話,叫做凡事皆專案,無論是個人的事,還是公司的事都可以是專案。從早上起床要去上班這個事情,也可以當做一個專案來管理,為了不遲到,如何控制風險,如何做好計劃,需要管理哪些干係人等等。

專案管理是一個相對專業的學科,建議無論以後你是否從事專案管理工作,都有必要系統的學習和了解專案管理。這裡我搜集了一些關於專業專案管理方面的體系和方法,如下圖:

如上圖所示,縱向從個人到組織,橫向如何做到做什麼。

  • 個人:

個人不涉及到團隊,看上去是沒什麼管理可言,但是在這塊需要自己有較強的學習能力,自控能力,自律能力。在開發圈中很多剛出道不就的夥伴,最開始一個人單兵獨將,做事情都很快,自己想到什麼立馬就開動,直接開始寫程式碼,玩的不亦樂乎,但是到了一些大型團隊,就感覺做事情沒以前順溜了,其實這是一種比較正常的現狀,因為個人管理和團隊協作完全是兩回事。

個人協作,對應的方法有 PSP,單核工作法,包括在CMMI體系中1級認證就是針對個人的。

  • 團隊

如上圖所示,團隊管理涉及到很多的專業方法和理論了,比如XP、Scrum、RUP、PMP等,一般建議是在3人以上20人以內的專案團隊,推薦最佳的10人內比較合適,否則管理難度就比較複雜了。

  • 組織

組織級別的專業認證,主要有,敏捷方面的SAFe、LeSS,華為的IPD、CMMI等;這些都是比較大型,比較重量級的管理體系,落地有利於企業實施事業部或事業群的管理體系支撐。當然也要看我們各自實施的具體方式和方法。

接下來重點介紹兩種目前比較主流的專案管理方法體系,目前業內比較主流的應該主要分傳統和敏捷專案管理兩類。傳統專案管理以PMP體系為代表,敏捷專案管理以Scrum(認證體系為SCM)為代表

PMI-PMP體系

PMP指的是專案管理專業人士資格認證。它是由美國專案管理協會(Project Management Institute(簡稱PMI))發起的,嚴格評估專案管理人員知識技能是否具有高品質的資格認證考試。

其目的是為了給專案管理人員提供統一的行業標準。目前,美國專案管理協會建立的認證考試有:PMP(專案管理師)和CAPM(專案管理助理師)已在全世界190多個國家和地區設立了認證考試機構。

\

根據PMBOK內容,其主要體系如下,五大過程組+10大知識領域,每個領域都有其對應點過程組

十大知識領域

敏捷專案管理

敏捷專案管理是近幾年比較熱的一個話題,無論是大公司還是都在實施敏捷,還有DevOps,這裡說到敏捷,我們不得不提到敏捷宣言。

從敏捷宣言內容來看,更多是推崇團隊協作,而不是傳統的文件工具,合同和刻板的計劃。對應敏捷的體系也演變出了不少的分支體系,其中Scrum是所有敏捷體系裡面算是一個比較基礎的框架了。LeSS、SAFe裡面的最小單元也是基於Scrum的方式,可能在管理上稍微有些不同而已。

以下是Scrum對應的框架圖

\

如上圖,市場或終端使用者將需求輸入給PO(Product Owner),PO根據產品的整體規劃,梳理出產品的Product Backlog,對每個Backlog會標註上對應的客戶價值分數,標識出哪些是對使用者價值最大的點。在以Scrum Master為帶領的專案團隊,大家組織

  • 計劃會議(Sprint Planning Meeting): 在這個會議上主要做三件事: 1. 挑選即將計入下一個Sprint計劃的使用者故事;2. 將選定的使用者故事進行故事點拆分,輸出Sprint Backlog;3. 每個人主動認領任務(可以直接認領任務,也可以認領某幾個故事點).
  • 站立會(Daily Scrum Meeting):在站立會上每個人主要描述三件事:1. 昨天完成了哪些事情;2 今天計劃做哪些事;3. 今天工作需要誰的協助。
  • 可執行的軟體(Potentially Shippable Product Increment); 每個Sprint結束都具備潛在可執行的軟體
  • 驗收(Review) 每個迭代,都可以讓客戶對已完成工作進行驗收,以便於及時發現問題確保輸出物的正確性
  • 反思會議(Retrospective),反思會議,主要是團隊召開反思會議,回顧在這輪Sprint中大家做的好的部分和做的不好的部分;對做的好的部分由Scrum Master統一放入到團隊優良傳統榜,對於做的不好選取幾個能執行的,討論出對應點優化方案,在下一個迭代中去持續改進。

在整個Sprint過程中有個時間盒的概念,也就是說在正式Sprint過程中是不允許變更的,變更需求都在每個Sprint開始部分。

我們一個專案跑下來,就是經歷無數Sprint不斷的迭代,每個迭代的結束緊接著寫一個迭代的開始。

\

傳統專案與敏捷專案的對比

這裡借鑑了網路上總結的,個人覺得比較到位,也就不用再單獨總結了。如下

從管理關注的重要領域上看,可以參考如下圖例

左邊為傳統專案,郵編為敏捷專案;傳統專案中,範圍,進度,成本就是一個鐵三角。任何一邊變更都會引起其他方面的變更,如果不然質量將無法得到有效保證。

敏捷專案實踐

在筆者所在的公司推行過如下的敏捷實踐,僅供參考。在實踐過程中還是比較順暢的。產品設計與產品開發交疊進行。有效保證了專案的有序推行。

總結

本章主要給大家介紹了產品開發的基本流程,以及專案管理的知識體系和比較主流的另種管理體系。同時也簡單對比了傳統專案與敏捷專案的差異點。最後結合筆者過往在團隊中的實踐,分享了敏捷實踐模型。希望通過本章的分享能幫助大家建立產品開發流程的體系結構,同時瞭解當今主流的專案管理體系以及差異。為後期個人的職業發展和團隊中定位更加清晰明確。