淺析軟體開發項目的前期溝通工作

項目真正發起者

了解誰是真正發起者，有助於我們初步判斷項目的目的。有可能的情況下，儘可能與項目的直接發起者溝通，了解項目的高層次目的或根本目的。
了解項目的根本目的，有助於我們判斷項目難度和成本，而不被表面的工作量所迷惑，做出遠超客戶預算的報價錯失項目。
什麼是根本目的，什麼又是表面工作量，我以一個用於生產企業的生產管理軟體為例，簡單粗暴的歸納：

  • 表面工作量
    生產製程、流程的電子化，生產過程管理事無巨細的電子化，車間零零總總的設備對接。力求完美與準確。減輕車間生產者與管理者的工作量。

  • 根本目的
    企業一把手希望深化對生產部門的管理。

如果以表面工作量來估價，甚至恨不得馬上把最先進的技術與理念銷售給客戶，成本與價格必然高昂，錯失項目，項目的發起者根本沒考慮這麼多。在這種情況下，你所有的科普都不會有太好的效果，會給客戶造成一個「你就是想賺我錢」的認識。銷售先進的技術產品需要過程，不可以一蹴而就。

如果我們把所有的工作都只圍繞根本目的去做，就會發現，沒那麼難。那些瑣碎的細節都是可以不做的，所謂減輕基層員工的工作量也不重要。我們只要通過技術手段採集好訂單資訊、產量資訊，品質資訊，大老闆就點頭了，才有可能獲得信任繼續合作。這樣我們就可以在初期大幅度降低報價促成項目落地，項目的實施過程也會有的放矢，避免成本超支。

只有知道了項目的真正發起者，根本目的，才能正確的評估與報價。

項目干係人

若要實施項目，可能會涉及哪些部門。在項目管理學科上有一種技術叫做「干係人分析」，我們把項目干係人分為四種類別：

  • 權力大、關注度高
    重點管理、爭取支援。

  • 權力大、關注度低
    令其滿意、爭取支援。

  • 權力小、關注度高
    隨時告知、獲取支援。

  • 權力小、關注度低
    保持關注，防止關注度變化。

常規來講項目干係人分析在項目啟動之後由項目經理負責。但是我認為在售前階段，就必須開展一定的前期識別工作，這對項目成本的評估和報價有非常重要的影響。權力大關注度高的干係人多，勢必造成項目成本攀升甚至飆升。

所以在售前階段，就要做好初步的干係人分析，整理好乾系人清單，一方面與客戶不斷溝通，完善修正這個清單，另一方面與技術開發實施團隊保持溝通，正確傳達。在整理干係人清單的時候，要與各個干係人直接溝通，正確的理解他們的期望和關注的原因，關注的點在哪裡。特別是要分析好不同干係人的期望之間可能會存在的衝突。在項目開發實施階段，要解決這些衝突的成本也是高昂的。

管理軟體本質上是管理手段的化身，任何企業管理沒有矛盾和衝突是不可能的，售前階段評估的越準確，項目成本預算就越準確，給客戶報價時，也能有理有據，取得信任。

項目範圍

說白了就是要乾的活。理論上來說這是售前階段必須要明確的，要列為合約附件的。這裡最容易產生的問題是項目範圍寬泛，抽象，而解釋權掌握在甲方手中。雖然任何項目要求售前團隊完全明確項目範圍，是不可能的，但依然應該儘可能的，盡最大努力的去做好範圍識別。

舉例來說，客戶要求項目能夠把現有的管理流程，在系統中實現。那麼就要問清楚：

  • 有哪些流程？
    不是寬泛的「財務審批」，而是具體的就財務審批來說，又到底有哪些流程。我們未必能在售前階段徹底搞明白流程的細節，但至少要有一個清單，知道有這麼一回事的存在。

  • 涉及哪些部門？
    有許多流程是跨部門的，這就容易導致部門之前有一些矛盾衝突存在，也許在長年的工作中，大家達成了某些默契或是潛規則，來處理工作中的一些問題。一旦上了管理系統化，如何調和這些管理流程上矛盾或不合理的地方？這可能需要開發實施團隊付出大量的精力和成本。說起來這是甲方自己的問題，需要自己去解決制定好管理流程，但作為乙方我們去陪跑，也是需要付出成本的，這是不可忽略的項目成本。如果搞到最後甲方說無解，那我項目就不驗收了？不給錢了？

這樣的例子還會有很多，各個模組都會存在這類問題。所以項目的範圍說明，不僅僅也不能只是一個「功能清單」，它必須是一個「項目範圍說明書」。這項工作不僅僅是對我們自己負責，也是對甲方負責。

拿我們最近做的在線客服系統來說，我們在第一時間，就做好了詳細的範圍說明書

//blog.shengxunwei.com/Home/Post/9b667212-565c-43a8-8379-bd0b832a3720

我們先理解一個概念：什麼是產品範圍，什麼是項目範圍。

  • 產品範圍
    我們的交付物，比如交付 MES 軟體、OA 軟體。前文講的「項目範圍說明書」，關注的是這一部分的內容。

  • 項目範圍
    為了完成所要交付的產品，所要做的所有工作，這裡我不討論技術層面的工作，只討論客戶能夠理解的項目層面的工作。
    ** 需求調研：與所有相關部門、干係人討論交流、開會討論、寫文檔、畫流程圖、再循環繼續開會討論、修改文檔。
    ** 原型設計：根據需求文檔，設計原型介面，與所有相關部門和干係人溝通確認、調整修改、討論聽取意見，循環反覆。
    ** 修改反工：客戶的想法變了也好，領導的個人喜好也好，需求調研沒有做到位也好，干係人理解錯誤也好，對錯不重要，重要的是這也是我們項目工作可以預見的一部分成本。
    ** 部署實施：涉及到人員的差旅、軟體的安裝調試、試用期間人員的在場支援。
    ** 後續支援：使用期間的技術諮詢、技術支援等等。這不等同於運維服務，運維服務可能是有合約有費用的，後續支援則是一個寬泛的概念，電話或是微信上諮詢一些使用問題，三不五時來一波，都會消耗我們的人力，遇到項目緊張的時候，就會影響我們下一個項目的工作。

這其中需求調研和原型設計的成本巨大，在複雜項目中，佔比超過開發實施都是可能的。有些大型項目會把這部分工作單獨做為諮詢項目立項，可見其複雜度。

原文：
//blog.shengxunwei.com/Home/Post/db0b910a-ee5f-4e70-b70a-f73b5a2dd6b6

VirMach 便宜 VPS

QNews

QNews