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