### 專案真正發起者 瞭解誰是真正發起者，有助於我們初步判斷專案的目的。有可能的情況下，儘可能與專案的直接發起者溝通，瞭解專案的高層次目的或根本目的。 瞭解專案的根本目的，有助於我們判斷專案難度和成本，而不被表面的工作量所迷惑，做出遠超客戶預算的報價錯失專案。 什麼是根本目的，什麼又是表面工作量，我以一個用於生產企業的生產管理軟體為例，簡單粗暴的歸納： * 表面工作量 生產工藝、流程的電子化，生產過程管理事無鉅細的電子化，車間零零總總的裝置對接。力求完美與準確。減輕車間生產者與管理者的工作量。 * 根本目的 企業一把手希望深化對生產部門的管理。 如果以表面工作量來估價，甚至恨不得馬上把最先進的技術與理念銷售給客戶，成本與價格必然高昂，錯失專案，專案的發起者根本沒考慮這麼多。在這種情況下，你所有的科普都不會有太好的效果，會給客戶造成一個“你就是想賺我錢”的認識。銷售先進的技術產品需要過程，不可以一蹴而就。 如果我們把所有的工作都只圍繞根本目的去做，就會發現，沒那麼難。那些瑣碎的細節都是可以不做的，所謂減輕基層員工的工作量也不重要。我們只要通過技術手段採集好訂單資訊、產量資訊，質量資訊，大老闆就點頭了，才有可能獲得信任繼續合作。這樣我們就可以在初期大幅度降低報價促成專案落地，專案的實施過程也會有的放矢，避免成本超支。 只有知道了專案的真正發起者，根本目的，才能正確的評估與報價。 ### 專案干係人 若要實施專案，可能會涉及哪些部門。在專案管理學科上有一種技術叫做“干係人分析”，我們把專案干係人分為四種類別： * 權力大、關注度高 重點管理、爭取支援。 * 權力大、關注度低 令其滿意、爭取支援。 * 權力小、關注度高 隨時告知、獲取支援。 * 權力小、關注度低 保持關注，防止關注度變化。 常規來講專案干係人分析在專案啟動之後由專案經理負責。但是我認為在售前階段，就必須開展一定的前期識別工作，這對專案成本的評估和報價有非常重要的影響。權力大關注度高的干係人多，勢必造成專案成本攀升甚至飆升。 所以在售前階段，就要做好初步的干係人分析，整理好乾系人清單，一方面與客戶不斷溝通，完善修正這個清單，另一方面與技術開發實施團隊保持溝通，正確傳達。在整理干係人清單的時候，要與各個干係人直接溝通，正確的理解他們的期望和關注的原因，關注的點在哪裡。特別是要分析好不同干係人的期望之間可能會存在的衝突。在專案開發實施階段，要解決這些衝突的成本也是高昂的。 管理軟體本質上是管理手段的化身，任何企業管理沒有矛盾和衝突是不可能的，售前階段評估的越準確，專案成本預算就越準確，給客戶報價時，也能有理有據，取得信任。 ### 專案範圍 說白了就是要乾的活。理論上來說這是售前階段必須要明確的，要列為合同附件的。這裡最容易產生的問題是專案範圍寬泛，抽象，而解釋權掌握在甲方手中。雖然任何專案要求售前團隊完全明確專案範圍，是不可能的，但依然應該儘可能的，盡最大努力的去做好範圍識別。 舉例來說，客戶要求專案能夠把現有的管理流程，在系統中實現。那麼就要問清楚： * 有哪些流程？ 不是寬泛的“財務審批”，而是具體的就財務審批來說，又到底有哪些流程。我們未必能在售前階段徹底搞明白流程的細節，但至少要有一個清單，知道有這麼一回事的存在。 * 涉及哪些部門？ 有許多流程是跨部門的，這就容易導致部門之前有一些矛盾衝突存在，也許在長年的工作中，大家達成了某些默契或是潛規則，來處理工作中的一些問題。一旦上了管理系統化，如何調和這些管理流程上矛盾或不合理的地方？這可能需要開發實施團隊付出大量的精力和成本。說起來這是甲方自己的問題，需要自己去解決制定好管理流程，但作為乙方我們去陪跑，也是需要付出成本的，這是不可忽略的專案成本。如果搞到最後甲方說無解，那我專案就不驗收了？不給錢了？ 這樣的例子還會有很多，各個模組都會存在這類問題。所以專案的範圍說明，不僅僅也不能只是一個“功能清單”，它必須是一個“專案範圍說明書”。這項工作不僅僅是對我們自己負責，也是對甲方負責。 拿我們最近做的線上客服系統來說，我們在第一時間，就做好了詳細的範圍說明書 [https://blog.shengxunwei.com/Home/Post/9b667212-565c-43a8-8379-bd0b832a3720](https://blog.shengxunwei.com/Home/Post/9b667212-565c-43a8-8379-bd0b832a3720) 我們先理解一個概念：什麼是產品範圍，什麼是專案範圍。 * 產品範圍 我們的交付物，比如交付 MES 軟體、OA 軟體。前文講的“專案範圍說明書”，關注的是這一部分的內容。 * 專案範圍 為了完成所要交付的產品，所要做的所有工作，這裡我不討論技術層面的工作，只討論客戶能夠理解的專案層面的工作。 ** 需求調研：與所有相關部門、干係人討論交流、開會討論、寫文件、畫流程圖、再迴圈繼續開會討論、修改文件。 ** 原型設計：根據需求文件，設計原型介面，與所有相關部門和干係人溝通確認、調整修改、討論聽取意見，迴圈反覆。 ** 修改反工：客戶的想法變了也好，領導的個人喜好也好，需求調研沒有做到位也好，干係人理解錯誤也好，對錯不重要，重要的是這也是我們專案工作可以預見的一部分成本。 ** 部署實施：涉及到人員的差旅、軟體的安裝除錯、試用期間人員的在場支援。 ** 後續支援：使用期間的技術諮詢、技術支援等等。這不等同於運維服務，運維服務可能是有合同有費用的，後續支援則是一個寬泛的概念，電話或是微信上諮詢一些使用問題，三不五時來一波，都會消耗我們的人力，遇到專案緊張的時候，就會影響我們下一個專案的工作。 這其中需求調研和原型設計的成本巨大，在複雜專案中，佔比超過開發實施都是可能的。有些大型專案會把這部分工作單獨做為諮詢專案立項，可見其複雜度。 原文： [https://blog.shengxunwei.com/Home/Post/db0b910a-ee5f-4e70-b70a-f73b5a2dd6b6](https://blog.shengxunwei.com/Home/Post/db0b910a-ee5f-4e70-b70a-f73b5a2d