產品部、項目組、實施組的關系

本文以筆者所在的公司架構和筆者所了解的業(yè)內的公司架構的情況和自身實際經歷的案例淺談一下軟件開發(fā)中的產品部、項目組和實施部這三者之間的關系，希望對各位在實際運作和管理中能有所幫助，并在實踐中盡可能地避免犯同樣的錯。文章是從作者本身的角度和經歷總結的一些問題，并不一定正確，借此拋磚引玉以期和廣大同行共勉共同進步。國內成長起來的軟件公司都想著做產品，因為銷售軟件產品就象批發(fā)水果一樣快速地給公司帶來大量的現(xiàn)金利潤，雖然國內軟件產商包括金蝶、用友在內都不能說完全實現(xiàn)了產品化的軟件產品，但軟件產品的前景卻被極度看好，而國內的眾多軟件開發(fā)商都是以項目的運作為生存和發(fā)展的基石和跳板，項目的成敗直接決定了公司的運營利潤，項目組的成員對項目的成敗有著最直接的關系，一般分為開發(fā)部和項目實施組并配一個測試文檔編寫小組。有些有實力的公司還專門成立有研發(fā)部門。產品部一般由技術總監(jiān)、項目總監(jiān)直接領導并配有固定的比較有經驗的開發(fā)人員以實現(xiàn)產品化的軟件為開發(fā)目標；項目組一般是在產品部提供的軟件產品再組織項目組成員根據(jù)客戶的需求進行定制的開發(fā)；實施組則根據(jù)項目組提供的程序現(xiàn)場更新并和客戶討論需求并制作查詢報表等系列的實施工作。筆者對產品的觀點是：產品部開發(fā)出來的產品不會是通用的十全十美的產品，它只是一個階段性的相對較完善的可以適應比之前更多更廣面的一個階段性的軟件。因為我們總是在不斷地進步，而且實際的情況總是不斷地變化發(fā)展前進的，作為開發(fā)人員有時會提出更有前瞻性的目標，軟件只是一個實現(xiàn)的工具而已，筆者于2003年6月份就提出了量化的人力資源軟件設計的概念和設計思想，即便到了現(xiàn)在，筆者手中公司團隊的程序代碼所實現(xiàn)的功能還是不能讓筆者滿意。因為微軟從Window32到Window2000，還加打SP6。產品部配備了公司相對較強的開發(fā)實力，相對而言也潛在著一種風險，那就是開發(fā)人員的開發(fā)能力、經驗和行業(yè)經驗都比較多，作為開發(fā)人員在國內目前的管理體制下會不自覺得走向盡善盡美和唯技術論，甚至不自覺而且無意識地到了吹毛求疵的程度，使得每一段程序都非常完美，每一個功能在設計理念、功能、技術、算法各方面都達到了極致，但前端實現(xiàn)的功能卻只是比以前多了一些，如果開發(fā)團隊出現(xiàn)了這樣的情況，而預期的時間來臨時，卻發(fā)現(xiàn)無法提供當初預期中想要的產品，雖然離產品只差一步，但就是差了這么一步，而無法提供于項目組轉入項目，實施部的人員只好轉入產品部幫忙做測試。當然這是最差的情況了，因為筆者是看過這樣的團隊，因此希望大家在實際的產品研發(fā)過程當中，要盡可能避免閉門造車百花齊放的局面，因為筆者更經?？吹降陌倩R放的結果是負責人被更換，而應當讓目標明確，并不斷地修正目標，保證每一個時間點都能有階段性的成果出來，并保證提供的產品是可用的。當產品提交出來后，一般的公司都會讓產品部開發(fā)人員再進入項目組，因為公司窮啦：）。筆者的觀點是：提交的產品只是做項目的基礎，產品只是提供了一些基本的當然也有一些是功能相當強的。在實際的項目運作中會有著相當多的需求變更，那就需要項目經理現(xiàn)場把握和引導客戶，使得程序做盡可能少的修改，并盡快地結束項目，并通過項目的歷練使產品更完善。項目組的人員不要期望產品部提交的軟件就象是萬能機器一樣什么都可以實現(xiàn)，更多的是只是提供了一個基礎，更多的東西要在項目中完善，甚至有些模塊的程序只能用其中的四分之一或更少，筆者之前就看到產品部提供的產品進項目后，結果整個模塊重新開發(fā)的局面，這當然和項目經理和客戶有著非常大的關系；但筆者也經歷過產品部提供的三個大模塊，和客戶談時全部通過的局面。項目小組的項目經理和開發(fā)人員筆者認為還有著一項任務就是在項目推進過程中將產品完善，并使項目為產品服務，筆者就經常是在做項目的過程中開發(fā)的一些模塊的程序最后被產品部全部吸收作為產品中的一部分并再下發(fā)到新項目程序中。這樣將使得產品和項目更快地完善，而不是產品部和項目組脫節(jié)，項目的程序最后不可控，和產品沒有什么太大的關系。因為項目做完后，后期維護也是非常重要的，一旦當初的開發(fā)人員換了職位，則只有再招一批新人熟悉項目的程序進行維護，而不是一般的開發(fā)人員就可以維護大多數(shù)的項目程序。當實施組拿到項目小組根據(jù)客戶需求定制修改的程序并經過測試時，就可到客戶現(xiàn)場更新了，因此實施小組的工作是在項目開發(fā)組完成后的動作的延續(xù)，而項目實施過程中的問題也是千奇百怪的，明明開發(fā)組那經過無數(shù)次測試都沒有發(fā)現(xiàn)的問題而到了客戶現(xiàn)場就是冒出了這樣那樣的問題，有些甚至是想都想不到的問題，就比如筆者現(xiàn)在在做的廣東省聯(lián)通項目，組織結構圖客戶現(xiàn)場出現(xiàn)的情況是第一次能瀏覽到而關閉后再進去插件就被屏蔽了，最后大家都沒有辦法就建議客戶重裝IE。項目實施過程中會遇到非常多的問題，既是對程序的挑戰(zhàn)也是對程序的完善，如果實施組的工作只是更新程序并制作報表查詢統(tǒng)計的話，則實施組的人員就成長不起來。實施人員在項目實施過程中還需學會對需求的控制，要學會如何引導客戶向已開發(fā)完成的軟件靠，而不是客戶說什么就當個二傳一樣將客戶的需求全部傳于開發(fā)人員，這樣只會導致整個項目失控，因為二傳傳一次最多只能吸收八成，甚至需求都變樣了。因此實施人員在實施過程中學會引導客戶的基礎是首先要對自己的軟件產品非常熟悉，因為如果你都不知道你的軟件是怎么運作的，那你只好當個二傳了，因為筆者認為每個人都可以成長起來的，筆者在出任多個項目經理的過程中，培養(yǎng)了兩個實施人員而現(xiàn)在他們也都出任過項目經理這角色。在項目推進過程中，除了團隊的團結，還需注意的一些細節(jié)問題，如團隊說話的口徑一致，現(xiàn)場需求應有一個人總體負責，也就是所有的需求口徑都需經過這個人。另外有些話更要注意說法，筆者在現(xiàn)場時就遇到這么一個場面，在項目轉入驗收時客戶發(fā)現(xiàn)了一個和他們業(yè)務不合的需求，當時實施人員就說是程序的錯，說開發(fā)人員的錯之類的，我則立馬截止，說這是我們根據(jù)我們做過的大多數(shù)的項目中總結的這樣做更符合客戶的要求和習慣，而且程序中還有專門的注釋說明是特意這樣寫的。雖然我心里比我們的實施人員更清楚這是程序的錯，程序中更不可能有這樣的注釋，但這樣的說法筆者認為會更好一些，特別是在項目轉入驗收期時，雖然這程序的修改量不到十分鐘，大家都應當還記得余世維成功經理人中的一個關于修電梯的故事吧！產品的成功和成熟有兩個標志，一是項目的成功，二是產品的熱賣。產品不修改程序并象批發(fā)水果一樣熱賣的場面在國內好象很少看到，所以筆者認為產品部、項目組和實施組的關系是緊密相關的，因此在開發(fā)或研發(fā)新產品時筆者認為讓第一線的實施、開發(fā)人員以及項