最近半年參與了公司乙個hris系統的流程開發，中間經歷坎坷，公司先後選了兩個系統來做bpm（business process management）。先是salesforce公司的lightning platform，然後中途換上專業做流程的pega。這篇文章並不是要說這兩者的好壞，因為即使換上了業界先進（或者號稱行業老大）的pega，也並沒有讓這個專案按時成功上線。
最後，國慶節大家加了6天班做最後的殊死一搏，還是只能接受專案延期或者重新再來的命運。記得國慶中有一天，大佬發火要看需求文件，竟然沒有人能拿得出來！
這並不算嚴重的，嚴重的問題是竟然專案經理不認為自己是專案經理，需求分析不知道自己要分析哪塊需求。最後，**商的開發不知道怎麼開發，只能別人說一點開發一點，或者按自己理解的先做。
我以為這種亂糟糟的事情就這樣結束了，沒想到我接手的另乙個專案仍然是這樣的問題。有了前車之鑑後，大佬們規定需要每個專案有正式的文件，這其實又引發了另一場「戰爭」。
為什麼大家都找不著北？
我們屬於公司的it部門，it部門有業務交付團隊和開發團隊，具體的命名方式不便透露。公司還是乙個pmo（project management office）的來管理專案和專案經理，大佬要求的需求文件和其他的文件有這個部門來制定。
然後他們屁顛屁顛的制定了一套文件和流程，落地時業務分析和開發無法達成一致，並引發了更多的爭吵和混亂。因為存在於部門和公司的根本問題並沒有解決：大家不知道自己是誰！業務分析和業務方的代表也搞不清楚自己的責任範圍，開發拿到的需求文件根本就沒多大用處，要做什麼還得重新再找業務分析討論，完全的乙個倒逼機制，開發做到某個的功能了就倒逼業務去理清這個功能的業務規則和具體的問題。
你要問我，專案經理呢？產品經理呢？
我會告訴你：「沒有！」
pmo會告訴你：「a就是產品經理！」
a會告訴你：「我怎麼會是產品經理？！」
開發會說：「需求文件業務需求描敘不清楚，沒有具體的業務規則。」
b會說：「要你們開發來幹什麼的？」
業務方代表（需求提出方）：「我只能管我這塊的需求，級別比我高的人的需求你們要去跟進。」
目前來說，除了使用某種程式語言碼**的那個人角色和責任很清楚之外，其他人包括我在內很多時候都搞不清自己是誰。沒有明確這些角色、權力和責任之前，pmo就已經制定了需要簽署需求文件再開發的規矩，需求文件不清晰，開發不能幹活！哪天清晰，哪天重新評估重新開發。
於是it內部的開發和業務分析只能爆發「戰爭」。
衝突的根源在**？
業務交付團隊希望能盡快的交付產品給使用者，畢竟他們直接面臨一線業務的壓力，時間對他們來說很關鍵；開發團隊希望保證質量和控制開發的風險，其實並沒有本質上的衝突。
我一直認為搞不清自己是誰是最本質的問題。如果乙個參與專案的角色明確知道自己是專案經理，那麼他會知道自己要管理專案的進度和對各種資源進行協調，產品經理會知道對需求負責並明確哪些需求是必須要做的，需求分析才能明確具體的業務規則。但往往一些小的專案，很難有齊全的人員和組織配置，可能會存在一人分式多角，甚至很多專案只有需求提出人和一兩個碼**的程式設計師。
開發和交付團隊的衝突有兩個方面我想是可以嘗試技術突破的：
需求提交、分析、開發，到交付使用者使用的週期過長，即使簽署了相應的文件，也無法保障開發出來的產品是業務需要的；
可能你會想到敏捷開發！沒錯，這也是乙個可以嘗試的方案，不過我在嘗試另乙個方案。
欲知後事如何，且聽下回分解（抱歉，我的嘗試還沒有成功，之後有效果了會總結奉上）。
在軟體開發中，對使用者 所屬部門間業務邏輯的理解
使用者會有有效時間段，部門也會有有效時間段，兩者單獨使用時互不干擾。當使用者有所屬部門時，所屬部門也應有有效時間段，所屬部門的有效時間段既應該在使用者的有效時間段內，也應該在部門的有效時間段內。有些情況，使用者會屬於多個部門，我做的專案中，使用者所屬部門便存在本務和兼務之分。要求是在使用者有效期間內...
業務運維部門的崗位價值與DCOS
崗位價值有 通過配置檔案修改乙個後台引數需要登入許可權，檔案修改許可權，甚至程序起停許可權。這些運營環境的許可權需要盡可能的收歸到很少的人的手裡以控制風險。業務運維初期以人工介面的方式提供服務，後期以web應用的方式提供自助服務。如果後台開發人員做得比較完善可以直接提供web應用提供自助服務。但是很...
會計的思考（46） 當作業務部門的財務部門
關鍵字 會計體系 財務 業務 業務部門一般指與公司客戶直接打交道，直接為公司創造效益的部門，如銷售部 市場部等，而財務部則劃歸後端職能部門，為業務部門提供服務與支援，這也沒錯。可是，某些業務有時大放厥詞，說財務部是他們養活的，這就讓人聽了極為不爽。其實，財務部門為什麼不能作為業務部門呢？財務部門把自...