【引言】

小公司研發人員就那么十幾個，日積月累幾年下來在研的、維護的項目可能會有十幾個，雖然業務比較單一，但是架不住產品型號繁多，各種事務真實剪不斷、理還亂。按照產品來劃分項目吧，實際上幾乎所有人都需要參加所有的項目，強行讓員工專職負責一個項目更不現實。可是不推進項目化管理吧，整個研發的效率越來越低，大家天天忙得要死，什么996、007，12x12玩過，老板累、員工累，但是產品上線比生孩子還難。

【正文】

本文所指的小公司并不是剛剛創業的小型公司，創業型的小公司，組織結構比較簡單，所有的管理和服務的角色老板一個人都包圓了，由于專注，效率也很高。本文所指的小公司是指度過了創業期，進入成長期的公司，公司有一定的規模，甚至可能員工的數量已經達到百人的規模（研發人員一般不會太多，加上測試二三十個左右），職能分工以初見模型。隨著公司規模的擴大，管理層開始發現創業時自己和員工如臂指使班的默契和效率沒有了，混亂和低效率與日俱增。雖然能夠支撐當前的業務規模，但是想再上一個臺階非常困難。公司戰略規劃執行起來，總是有一種沼澤行軍的感覺。

企業進入了該認認真真談談管理的階段。并不是說以前沒有管理，之前的管理多數情況屬于經驗式管理，屬于見招拆招式的管理。這里所說的是科學管理，是經過精心設計的管理。既然是設計，就必須首先進行架構設計。

本文重點談一下小公司的項目管理，提供一些可供借鑒的框架/架構，將公司的項目管理從經驗式逐步遷移至科學的管理。搞產品設計的人都清楚產品框架也就是架構，對于產品的重要性。技術需要框架，管理同樣需要框架，甚至有學者提出來企業應該設置“企業架構設計師”這樣的職位，可是對于小公司恐怕只有老板親自出馬了。管理架構的好處是：1）降低信息處理的維度；2）統攝全局，實現有序分工；3）易于傳播，統一工作流程；4）符合漸進明細處理復雜事務的原則。

項目是組織中臨時的一項“工作”，項目本身也是一個組織（項目團隊），另外項目也是一個系統（包括其所處的環境系統），項目無法脫離它所在的環境而單獨存在。對于成長型的公司，我們需要先理順項目所處的大環境，才能設計出符合實際的項目管理框架。這些環境包括：業務分工架構、研發流程架構、技術管理架構、研發組織架構，最后我們給出一種項目管理架構——研發事務看板。

一、業務分工架構

公司的成長過程必然伴隨著分工的加劇，分工是為了提高應對工作的專業性和效率。但是對于客戶來講，它要的是作為整體的結果，所以分工之后必須進行整合才能為客戶提供有價值的產品。分工越多，整合越困難，管理在某種程度上就是在平衡分工和整合之間的關系。

成長型公司由于管理層架構設計（現在流行叫頂層設計）的意識不強，被動反應式分工現象普遍存在。通俗一點說就是干到哪，想到哪！這非常類似生活中無計劃的購物，需要什么了就買什么，時間久了，發現屋子里面堆滿了需要的和不需要的商品，有的用一次就沒用了。似乎每一個決策都是正確的，但是所有正確的單次決策，一定不會得到一個正確的全局性決策。這是系統的普遍規律決定，一個和諧完美的系統，一定是多個組成部分之間相互妥協之后的結果。

為了防止被動反應式分工的發生，需要在分析公司核心業務流程的基礎上設計公司的業務分工架構。當公司在發展中遇到新的工作（內部和外部）需要處理時，首先對照業務分工架構進行安排，并仔細衡量增加業務職能和人員的必要性。當然架構并不是一成不變的，必要時可以進行更新。但無論如何，它為組織的發展提供了框架和指南，最重要的是可以讓公司員工從總體上了解公司是如何處理業務分工的。這一點之所以重要，是因為公司在成長的過程中必然會招聘大量的員工，而這些員工頭腦中根深蒂固的是他們原來公司的工作方式，在沒有統一指導的情況下，每個人都會根據自己的經驗來決定工作該如何做，這加劇了管理的混亂和沖突。

圖1 業務分工架構

圖1是作者為一家100人左右的成長型科技公司設計的業務分工架構，簡稱MSVC架構。其中：M-Marketing System，市場體系；S-Service System，服務體系；V-Sales System銷售體系；C-Creative System，創新體系。

市場體系負責產品規劃、品牌形象、服務平臺建設、商業分析、產品行銷培訓等工作。

服務體系負責解決客戶售前、售中、售后問題，提供客戶運維技術培訓，支持市場現場活動，發起完善產品體驗的倡議，另外HR被定義為服務于公司內部其它部門的部門。

銷售體系用V表示，而不是用S代表，有兩個考慮：1）銷售是直接將產品變成利潤的職能，即實現了產品的價值，所以強調利潤價值導向，銷售不是為了把產品賣出去，而是為了實現價值；2）服務已經占用了一個S，用V便于區分。另外銷售還要擔負發現市場機會、跟蹤客戶、處理客戶關系、回款等工作。

創新體系負責將市場機會轉化成產品、服務能力和解決方案，并保證其質量，其中外協生產部分也是劃歸創新體系。

創新體系負責通過項目的方式創造價值，銷售實現價值和發現價值機會，服務保證價值的順利轉移，市場對創新、銷售和服務進行統籌規劃和指導。這個架構并不是憑空想象出來的，而是在分析總結公司當前業務運行情況，抽象提煉出來的。另外這個架構又不是現實的復制，而是升華。這些工作有些是現在正在做的，有些是管理層希望做的，通過這個架構進行了整合，明確了公司業務運轉的模式，為今后的業務分工提供了統一指導。

二、研發流程架構

公司的業務分工架構統一了全公司的分工配合問題，接下來我們談一談如何統一產品研發管理步驟，也就是MSVC中的“C”，因為“C”是本文要討論的重點。要建設研發體系，首先需要做的就是梳理最大的研發流程，大部分情況下我們稱其為“產品/項目 生命周期”，如圖2所示。

圖2 研發流程架構

產品/項目生命周期明確了完成產品或項目需要經歷的主要階段，以及他們的先后順序。它的功效在于統一了研發人員的行動步驟，為工作分工和協作打下了基礎。一般意義上產品管理和項目管理側重點是不同的。產品管理側重產品的定義，即“產品應該是什么樣子（需求）和為什么做這個產品（市場）”，另外還要保證產品從定義到退出市場整個生命周期內的市場適用性（即能賣的出去且盈利）。而項目管理側重于如何將一個特定的產品創造出來，即“如何干”，產品做出來項目就結束了，而產品管理未必會結束。產品生命周期中可能會經歷多個項目生命周期來完成包括創造、維護、升級等工作。

對于規范成熟的公司來講，產品管理和項目管理是兩條并行的管理線，他們在特定的時間點重合與分離。

對于成長型公司來說產品管理線和項目管理線實際上是由同一部分人完成的，也就在事實上融合成為一個整體。圖2實際上就是將產品管理和項目管理融合成為一個統一的“研發流程”。

如果單純從項目的角度來看待產品管理也是可以自洽的，即把產品管理看作是項目集，把單個項目看作是項目集的組成部分，這樣就可以用統一視角來看待研發工作，減少概念的混亂。

基于小公司的產品類型的單一性（品種少型號多），根據圖2的架構，我們把整個研發部的項目看作一個項目集，可以簡單理解為一個大項目，這樣就避免了因為強行劃分項目導致人員管理分工的困難。在實際操作中，小公司中的項目論證和論證啟動階段的工作相對比較簡單，通常是少數管理層來完成，這部分不是管理活動的重點作用對象。研發管理的重點是規劃、實施、交付、收尾，以及生產和維護。

當然圖2所示的流程順序在實際工作中并不一定是按照嚴格的順序方式來執行，針對不同的產品、不同的環境可能出現，交疊、往復、循環等各種模式。如果某種模式可以很好地解決實際問題，那種模式就可以稱作是“生命周期模型”。例如常見的生命周期模型有：瀑布式、迭代式、增量式和敏捷適應式等。

三、技術管理架構

我們用把整個研發部在研和在維護的項目看作項目集的方式解決了統一管理的問題，接下來還要解決的是從技術上怎么協調諸多產品型號、不同產品層次、多種產品組合的問題。不解決這個問題，管理就失去了作用的對象，因為管理要管的工作就是技術工作，要協調的工作也是這些技術工作。

基于貨架的產品交付框架可以很好的解決多產品、多型號、多層次交付的問題，如圖3 所示。

圖3 技術管理架構

凡是擺在貨架上的產品（可能是中間產品）都是經過驗證的，也就是說在自己所屬領域是可以交付給客戶（可能是內部客戶）的產品。未經驗證，無法保證質量的產品不允許放在貨架上。當客戶需要某種產品時只需要在貨架上尋找適合自己的產品，而不需要直接跟產品提供者打交道。

產品貨架上的產品根據其適用的范圍，需要進行縱向和橫向的分類，例如圖3中自下而上將公司的產品分為：軟件平臺和硬件平臺，整機，解決方案三個層次。縱向上越往下通用性越強，越往上定制程度越強。橫向還可以根據型號、版本、客戶進行更加具體的分類。

解決方案層級，基本上沒有研發創造活動，它主要是根據客戶（通常是需要綜合服務的客戶）的需求，從自己貨架上挑選產品，形成一個滿足特定客戶需求的綜合解決方案，并進行部署和調試。解決方案層面根據底層產品提供的特性解決接口兼容問題，如果需要調整底層的特性，則由整機層和平臺層負責。

四、研發組織架構

成長型公司在人力組織上面臨的最大的現實就是“人少活多”。如果按照一般意義上的產品或項目來組織人員工作，將會使團隊分割成一個個碎片，加之人手本就不足，個個都身兼數職，更不適宜劃分項目組。

當然最好的方式是擴大研發隊伍，加強專業化程度，但是這需要綜合衡量成本和風險。除了成本的增加，在沒有形成科學規范的項目管理體系之前，驟然增加大量的研發人員，會導致管理上的混亂。

穩妥的做法是基于現有人力，梳理研發流程，規范研發管理，先提高效率，培養隊伍，為未來的擴大建立基礎。總體戰略是“先精兵強將，再兵多將廣“。

圖4 研發組織架構

圖4中所設計的研發組織架構，是基于組織目前的分工設計的，其中虛線框是未來希望增加的部門，總體來說還是一種職能式的組織結構。

現實情況是，研發人員的總數不到30人，加上硬件的研發工作相對獨立，需要協調的人員主要是軟件和測試，人數不超過20人。

主要設計思路是，將整個研發部的所有在研項目和在維護項目當作一個項目集來看待，研發部要能夠持續的交付價值（產品和服務）給客戶，所有研發人員應當象生產線工人一樣圍繞產品交付價值流（隱形的生產線）工作，所有的研發工作，包括產品需求、缺陷、基礎平臺建設、客戶反饋、風險應對全部當作研發事務（待辦事項）來處理，整個研發部由一位研發副總統轄，目的是打造一部“事務“加工機，按照商定好的優先級處理規則”加工“所有的研發事務。

五、研發事務看板架構

價值流的具體實現方式，采用看板方法，這是一種脫胎于精益管理的敏捷實踐方法，結合公司的情況，不是以產品和團隊為單位設置看板，而是整個研發部設置一個總的研發事務看板，如圖5所示。

圖5 研發事務看板

研發事務看板的基本思想如下：

1）整個研發部設置一個總得“研發事務看板”，所有需要研發處理的“事務”都必須納入看板才會被處理。

2）研發事務的主要來源有：研發需求、測試部發現的缺陷，客戶提出的要求和反饋的問題、風險應對活動、技術試驗活動、環境搭建活動、以及來自高層的緊急任務。

3）研發事務看板由研發部負責維護，還可以設置團隊或小組級別的看板。事務看板層面管理事務（backlog又稱待辦事項），而團隊小組級別管理任務（task）,任務是對事務的進一步分解，由事務負責人根據需要自行分解。

4）要建立統一的事務清單（可依托JIRA建立數據庫），一項事務需要描述一些必要的信息，例如：標題，內容描述、優先級、工作規模、事務類型、所屬項目或產品、來源、狀態信息、必要備注信息等內容。凡是要研發部完成的工作都需要先進入研發事務清單，并且設定優先級之后方可進入研發事務看板。

5）研發部負責人根據優先級定期（例如每周）選擇需要在本周期內完成的研發事務，納入看板進行處理。事務需要在公司層面進行管理和存檔，任務則有團隊小組負責無需存檔。

6）研發事務看板初期最好采用高接觸低技術的方式管理，例如在研發區專門開辟一面墻當作看板，待養成工作習慣之后再采用電子化的方式管理。

以上是研發事務看板的不同于一般看板方法的要點，當然看板的基本原則和方法還是需要遵守的，例如團隊還需要就以下幾個方面達成一致意見，并形成運行規范：

1）迭代周期長度；

2）計劃會議的規則、評審會議的規則以及回顧會議的規則；

3）設定優先級的規則；

4）允許的WIP的數量是多少，工作流轉的規則；

5）度量的方法、溝通的方法、事務分類的方法、工作估算的方法；

6）數據庫字段、編寫不同類型事務的模板、看板泳道的設定，緊急事務的處理規則；

7）信息系統和手工看板的結合方法等等。

在對研發事務看板核心要件討論清楚之后，就可以與現有流程并行運行一段時間。這是因為看板需要成熟的時間，另外團隊也需要培訓和學習。待時機成熟之后，整個研發團隊就可以切換到看板模式運轉。

研發事務看板并非只是權宜之計，它具有擴展性，未來隨著產品線和人員的增加，可以根據產品線進行擴展，也可以根據部門擴展。各產品線的看板還可匯總信息到公司層級的看板，當然公司層級看板的內容是一個個的項目，不是具體的項目事務。

【小結】

一個企業是一個系統、一個項目也是一個系統，對于項目而言，企業就是它的超系統。一個系統有三個主要部分：組分、結構和組分的相互作用。一個系統之所以成為一個系統，不是因為組分的不同，而是因為結構的不同。組分通過結構相互作用，最終使得系統表現出與眾不同的特性。對于管理來講，結構是統攝全局的總的抓手，結構順則管理順，結構亂則管理亂，梳理清楚管理的結構才能排兵布陣，組織戰斗，實現戰略。

參考文獻

[1] PMI. The Standard for Program Management 4th. 美國項目管理協會，2017

[2] (美)理查德L達夫特，組織理論與設計（第12版）. 清華大學出版社，2017

[3] 周輝，產品研發管理，電子工業出版社，2014

[4] (美)David J. Anderson，看板方法，科技企業漸進變革成功之道，華中科技大學出版社，2017