最近半年參與了公司一個HRIS系統的流程開發，中間經歷坎坷，公司先后選了兩個系統來做BPM（Business Process Management）。先是Salesforce公司的Lightning Platform，然后中途換上專業做流程的Pega。這篇文章并不是要說這兩者的好壞，因為即使換上了業界先進（或者號稱行業老大）的Pega，也并沒有讓這個項目按時成功上線。
最后，國慶節大家加了6天班做最后的殊死一搏，還是只能接受項目延期或者重新再來的命運。記得國慶中有一天，大佬發火要看需求文檔，竟然沒有人能拿得出來！
這并不算嚴重的，嚴重的問題是竟然項目經理不認為自己是項目經理，需求分析不知道自己要分析哪塊需求。最后，供應商的開發不知道怎么開發，只能別人說一點開發一點，或者按自己理解的先做。
我以為這種亂糟糟的事情就這樣結束了，沒想到我接手的另一個項目仍然是這樣的問題。有了前車之鑒后，大佬們規定需要每個項目有正式的文檔，這其實又引發了另一場“戰爭”。
為什么大家都找不著北？
我們屬于公司的IT部門，IT部門有業務交付團隊和開發團隊，具體的命名方式不便透露。公司還是一個PMO（Project Management Office）的來管理項目和項目經理，大佬要求的需求文檔和其他的文檔有這個部門來制定。
然后他們屁顛屁顛的制定了一套文檔和流程，落地時業務分析和開發無法達成一致，并引發了更多的爭吵和混亂。因為存在于部門和公司的根本問題并沒有解決：大家不知道自己是誰！業務分析和業務方的代表也搞不清楚自己的責任范圍，開發拿到的需求文檔根本就沒多大用處，要做什么還得重新再找業務分析討論，完全的一個倒逼機制，開發做到某個的功能了就倒逼業務去理清這個功能的業務規則和具體的問題。
你要問我，項目經理呢？產品經理呢？
我會告訴你：“沒有！”
PMO會告訴你：“A就是產品經理！”
A會告訴你：“我怎么會是產品經理？！”
開發會說：“需求文檔業務需求描敘不清楚，沒有具體的業務規則?！?/p>
B會說：“要你們開發來干什么的？”
業務方代表（需求提出方）：“我只能管我這塊的需求，級別比我高的人的需求你們要去跟進?！?/p>
目前來說，除了使用某種編程語言碼代碼的那個人角色和責任很清楚之外，其他人包括我在內很多時候都搞不清自己是誰。沒有明確這些角色、權力和責任之前，PMO就已經制定了需要簽署需求文檔再開發的規矩，需求文檔不清晰，開發不能干活！哪天清晰，哪天重新評估重新開發。
于是IT內部的開發和業務分析只能爆發“戰爭”。
沖突的根源在哪里？
業務交付團隊希望能盡快的交付產品給用戶，畢竟他們直接面臨一線業務的壓力，時間對他們來說很關鍵；開發團隊希望保證質量和控制開發的風險，其實并沒有本質上的沖突。
我一直認為搞不清自己是誰是最本質的問題。如果一個參與項目的角色明確知道自己是項目經理，那么他會知道自己要管理項目的進度和對各種資源進行協調，產品經理會知道對需求負責并明確哪些需求是必須要做的，需求分析才能明確具體的業務規則。但往往一些小的項目，很難有齊全的人員和組織配置，可能會存在一人分式多角，甚至很多項目只有需求提出人和一兩個碼代碼的程序員。
搞不清楚自己是誰，可能需要大家慢慢磨合和明確下來，這個頑癥并非一朝一夕可以醫好的。我從技術的角度，在思考另一個問題：能用技術解決開發和交付的沖突嗎？
開發和交付團隊的沖突有兩個方面我想是可以嘗試技術突破的：
- 需求提交、分析、開發，到交付用戶使用的周期過長，即使簽署了相應的文檔，也無法保障開發出來的產品是業務需要的；
- 業務、分析和開發討論的有效性不高：多方的角度和認知不一樣，大家往往不在一個頻道上。
可能你會想到敏捷開發！沒錯，這也是一個可以嘗試的方案，不過我在嘗試另一個方案。
欲知后事如何，且聽下回分解（抱歉，我的嘗試還沒有成功，之后有效果了會總結奉上）。
