產品開發管理之流程和體系（總篇）

前言

秋風瑟瑟，夏日的灼熱猶在，就瞬間迎來刺骨寒風。凜冬將至，今天對我們來說，像貼面的利刃一樣冰冷而真實。農民、建築工人、司機、程序員、私企高管、私企老板、資本巨富，都被裹挾進了這個焦灼的時代，沒有人能獨善其身。

焦灼無法解決任何問題，這一次的風雪也並不會比以往的更為凜冽，唯有勇於踏雪前行者，才能迎來春天。這對於踏實肯干的互聯網研發企業來說，未必不是一件幸事——只要度過寒冬，來年我們會走得更遠！

三架火箭

先有雞還是先有蛋？我們不去探討這個問題，但是如果你家母雞都沒喂大，就想買蛋賺錢，這是一個問題。

產品研發就如養雞，雞大才有蛋，雞好才是真的好，雞長得快風險和成本才會更小，因此產品開發和管理才是重中之重。

如何解決產品研發中的“控風險、縮周期、降成本”的痛點？每個人都會有每個人的反思和總結，而我們有了本篇的反思和總結。

根據我們多年的開發和管理經驗，在降低生產成本、提高生產效率和保障生產質量的角度上，我們提出了“三架火箭”的概念，即：

• 框架和組件
• 工具
• 流程和體系

值得注意的是，三大寶劍，哦三架火箭只是我們的心血總結，希望能給大家一些幫助以及和大家共同探討，但是在一個產品團隊中，管理者不能忽視的一點是——以人為本。

框架和組件

對於一個軟件公司或者互聯網公司來說，開發成本是一個公司不得不說的痛，因為其在前期幾乎是全部的成本，而一旦功敗垂成，則片甲不留——打水漂可能還能聽幾個響。而約定一個統一的框架和技術體系，對於一個開發團隊來說，這就是一個團隊的積累和財富！這就是讓你的團隊繼續鏖戰的基礎！

擁有一套統一的優秀的企業級開發框架意味着有如下好處：

• 意味着統一了主體的技術體系，可以最大限度的減少后續的開發、維護、擴展成本。
• 意味着擁有了一套成熟的解決方案。
• 意味着保障了代碼的穩定性、延續性和可持續開發，而不是代碼全家桶。很多初創團隊的產品的初始代碼來自於五湖四海（各自成員的前公司的代碼段或技術積累），當開發到一定程度，隨着人員的交替，維護和擴展幾乎不在可能。一份好的代碼是一個產品的根本，否則后續的產品開發都將無從下手。 這里分享一下世上最爛代碼的結果：史上最爛代碼。
• 極大的提高了產品的生產效率。
• 建立有效的開發、知識、體系積累。軟件開發是一種知識活動，因此知識的聚集和積累是至關重要的。框架能夠采用一種結構化的方式對某個特定的業務領域進行描述，也就是將這個領域相關的技術以代碼、文檔、模型等方式固化下來。
• 減少重復開發。簡單的說，大大提高了代碼的復用性。畢竟每次打仗都要臨陣磨槍，耽誤時間不說，質量和速度都沒法保障。
• 有利於提高團隊水平。框架往往有相應的規范、約定、設計模式、理念、技術點，通過框架的源代碼既可以輸出開發和技術理念，提高團隊成員的水平，又可以規范代碼，而且可以降低程序員之間溝通以及日后維護的成本。
• 提高軟件質量。
• 提高企業的競爭能力，包括降低成本、提高質量、改善客戶滿意程度、控制進度等方面。
• 有利於團隊多人協作和分工合作。架構師專注於設計框架、組件、領域模型等；軟件開發人員專注於業務邏輯，以及業務的更深程度的分析和挖掘；前端人員更專注前端交互（前后端分離）體驗。

當然，任何事物都需要多方面權衡，我們也要看到一些問題。比如前期需要付出培養成本，框架的理念以及先進性會限制團隊的理念和先進性等等，但是對於企業和創業團隊來說，持續的成本控制是第一位的。

這里奉送中小團隊一句箴言——你可以沒有自己的框架，但是一定要有統一的技術體系。

最后，附上我們團隊的框架和組件庫地址，均已開源。擁抱開源一直是我們團隊的核心理念之一。

團隊框架地址：https://gitee.com/xl_wenqiang/Magicodes.Admin.Core

團隊組件庫地址：https://github.com/xin-lai/

后續文章我們會繼續分享我們在框架和組件這塊的理念和經驗。

工欲善其事必先利其器

框架只是意味着不要從零開始編碼，而配套的工具則能更好的提高團隊溝通和協作能力、提高編碼速度以及減少低級代碼的編寫。工具分為辦公軟件、開發工具、管理軟件和開發輔助工具。

我們可以初步確定以下兩個原則：

• 統一的環境、工具和軟件
• 善用工具

在這塊，我們也有挺多我們的心得，這塊，我們后面再詳聊。

流程和體系

流程體系旨在於提高工作效率，明確流程接口和步驟，確定相關崗位或者相關事務的要求、原則、規則。

流程

工作流程是工作效率的源泉,流程決定效率，流程影響效益。好的產品流程能夠使團隊各項工作良性開展，從而保證團隊的高效運轉，相反地，差的流程則會問題頻出，出現角色間、人員間職責不清相互推諉等現象，從而造成資源的浪費和效率的低下。因此，設計、建立科學、嚴謹的產品流程並保持這些流程得到有效執行、控制和管理，對一個企業、一個部門或團隊至關重要。

產品流程需要標准化！ 一個產品團隊都有不同的工作、不同的崗位，並且需要相應的人員來完成。然而，不同的產品流程就會有不同的效率，進而言之，就會對整個產品產生不同的影響。因此，我們需要將產品流程標准化，就是要分析某一工作的性質和類型，在其基礎上對相應的工作設立對應的崗位或角色，並且安排具體的工作者來承擔。即“一個蘿卜一個坑”，無論何時在某個節點或步驟上出現了工作的失誤都能迅速且准確地找到責任人，這樣可以有效地防止相關工作的不同崗位間、角色間的互相扯皮、踢皮球的現象。

注意：上面雖然提及“一個蘿卜一個坑”，但是並不代表一個人不能多個坑。一個坑代表的是職責的明確，而不是一個崗位。另外，筆者也非常推崇產品開發團隊成員盡可能是全棧工程師。

產品流程方面，一般推薦完成以下流程：

• 產品開發流程
• 產品反饋流程
• 產品上線流程

體系

對於一個軟件公司來說，產品管理開發體系極為重要。這也是一個公司的軟實力的體現。

技術體系

這里借用秦統一文字和貨幣的部分意義，來說明統一技術體系的意義：

• 有利於團隊的溝通，維護團隊的統一和促進團隊文化的發展。
• 鞏固了團隊技術管理的統治，維護了產品技術體系的統一。
• 降低開發人員離職風險。這里特別說明一下，編程不比其他職業，不同的編程語言、框架體系、設計風格、編碼風格決定着不同的上手門檻和成本。門檻達不到，那就是不行。上手成本高，那就必須付出相應的代價。既無法取巧，亦無法越過。

老秦可以走了，我們繼續。重要的話說三遍，你可以沒有自己的框架，但是一定要有統一的技術體系。

除了技術體系之外，我們還應該完善設計體系、測試體系、運維體系和運營體系。

規范

古人雲，“先學規矩后學藝”，在產品開發領域亦是如此。從設計到開發，測試甚至運維運營，都應該有對應的規范。畢竟，有章可循，有據可依，有正確的產品流程規范，我們的工作才不至於產生混亂，團隊的工作才能更有成效。

正確的規范有哪些好處呢？筆者認為主要有以下幾點：

• 提高團隊的工作/開發效率，便於團隊更協調、有效運作；
• 端正成員工作態度，體現團隊精神；
• 對人員進行有效管理；
• 有效降低溝通、管理成本；
• 提高成員修養和能力；
• 積累團隊經驗，促使團隊健康發展；

因此規范的建立不能隨手照搬照抄，需要根據企業以及團隊現狀，不斷地思索、總結、積累，然后建立適合自己的行之有效的規范。同時還要注意兩點：

• 規范重在執行，如果只是自欺欺人，那么規范將無絲毫意義。
• 規范從來不是一成不變的，企業或團隊在發展的過程中，一定要不斷更新和完善自己的規范。

關於規范這塊，我們可以根據產品開發運營的生命周期進行細化，落實到點子上，比如團隊規范、API設計規范、前端規范、源代碼管理要求和規范等等。這些在后續的文章中，我們再來共同完善。

理念

先進的理念是團隊產品開發管理的指導思想，是團隊成功的關鍵，亦能促使團隊成長和奮進。在產品開發管理之中，筆者接下來或逐步和大家分享以下理念：

• 精益創業
• 同理心
• 自我刷新
• 全棧工程師
• 開源
• 敏捷開發
• 渠道集成
• 單一職責
• IaaS、PaaS、SaaS
• DDD（領域驅動（Domain-Driven Design））
• TDD（測試驅動開發（Test Driven Development））
• CI（持續集成(Continuous Integration)）
• CD（持續交付(Continuous Delivery)）
• 微服務(Microservices Architecture)
• RESTful（Representational State Transfer）
• 前端工程化
• All in code（作者提出）

這里先優先側重簡單地說下敏捷開發，因為在整個產品的生命周期之中，開發一直是基礎中的基礎，而開發模式和管理模式對互聯網產品影響深遠。

敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。目標是提高開發效率和響應能力。

敏捷從來不是一件容易的事情，俗話說，“天下武功，唯快不破”，但是這快並不好實現。敏捷開發在很多情況下是一種願景，在國內落地比較難，但是因難而不往，就會一直錯失快速開發和快速迭代的能力，產品競爭力也會不夠（產品競爭力應該包含產品迭代速度），而且還會因為不能適應快魚法則而被淘汰。

敏捷開發的實施不能一蹴而就，比較講究天時地利人和。對於一個初創團隊，如果理念以及技術水平相近，團隊溝通協調能力不錯，這時候實行敏捷開發就會事半功倍。但是敏捷開發是不能生搬硬套的，否則就會水土不服，每一個團隊應該視自身情況打造自身的敏捷流程，而不是硬生生的套用Scrum流程。當然最重要的是，要將團隊的溝通能力、協作能力、包括技術水平提升起來，這才是實行敏捷的前提。

會議體系

會議一直會貫穿產品開發管理的整個過程，筆者倡導以下會議：

• 站立會議
• 規划會議
• 反思會議
• 評審會議

接下來，筆者將會和大家一起分享這些會議的細節，比如目的、要求、內容。

寫在最后

本篇僅是拋磚引玉，我們接下來會將我們這些年的經驗、總結和反思一點一滴的分享出來，期待和大家共同進步，多多交流！