先直接放出我對軟件開發的相關人員職責和流程：

圖一：軟件開發的相關人員職責

以下是截屏的開發流程泳道圖：

橫軸是相關開發人員的工作模塊；縱軸是從上至下開發時序周期。

圖二：軟件開發的流程圖

從職責圖和流程圖對應到我們實際處在軟件開發過程中好像就是這樣，并無不妥的地方；但是拆分下去并結合你的崗位工作經驗就會發現某些環節難以形成流程標準，和很多需要注意的細節。接下去我們可以來聊聊其中的問題。

---

開發流程涉及到他人協作的模塊：

項目經理：任務管理系統（Tower任務管理工具）；

產品經理：產品原型和需求文檔（Axure原型）；

UI設計師：UI稿管理項目（藍湖）；

服務端/前端：api接口等文檔（YApi）；

測試組：bug管理系統（禪道）。

以上的各崗位所管理的項目系統是涉及到與其他同事協作的工作內容，有依賴時間順序、有依賴他人工作和需做出回應的。

涉及到協作的工作內容，我們應該做好本職工作以免給他人添加額外的時間成本、工作量，導致嫌隙；不利于團隊關系和氣氛。

---

在開發流程中，在完成本職工作上，為什么我們應該更加注重團隊協作和工作上的合作、磨合？？？

軟件項目的開發更注重各崗位的協作，才能更好更快的產出預期的項目；

軟件開發需要較少的人員參與，但工作也是人做的，都會帶入情緒、情感，協作上我們應該盡量通過標準化流程避免些不必要的摩擦；帶給員工良好的合作體驗；

軟件開發的人員畫像大部分是些內向、不善溝通、不愿多溝通的；應通過協作管理工具和流程標準來減少不必要的溝通；這樣就能更專注的coding和設計，不常被流程外的消息打斷、打擾，擾亂思緒。

我們逐一分解各崗位的影響圈，以及在協作方面應該做好哪些：

開發主管/項目經理：

項目主管/項目經理的輻射圈

崗位解讀：

在把控進度和質量上，要善于利用任務管理工具；如：Tower，任務狀態更改，相關人員都會接受到通知，減少程序員的溝通時間和避開他們當面溝通能力不足的情況，轉而通過文檔溝通

對內把控項目進度、質量之外，他們的日常工作更應該關注團隊管理，了解成員情況，消除不和諧因素，充當團隊潤滑劑。了解員工留在公司的原因，通勤時間短、公司穩定、薪資待遇、同事團隊和諧、團隊氛圍好、職位有的發展、有利于當前學習？以及近期將來的打算和職業規劃。這得要求管理者比較懂得一些為人處世的經驗。

然而大部分中小團隊的技術負責人、管理者大多都是由開發技術好的程序員晉升上去，大部分程序員性格內向、不善溝通，缺乏為人處世和管理的經驗；性格里更是不愿意去觸碰這些與人打交道的事情。他們更喜歡沉浸在自己的coding世界中。他們喜歡有產出，但是管理崗這工作實際工作量很多，不易看出實際的產出。對于程序員轉崗的管理者來說，帶不來多大的成就感，反而還加重他們的負擔。在中間管理崗，對上得負責，忙于溝通，對下也得指導溝通；自己反而沒時間專注寫代碼。最后這樣的管理者會逃避管理方面的工作內容或逃離管理崗。

大部分中小團隊提拔管理者只看到技術能力這方面的考核，過于片面，未正確認識管理者充當的角色和工作內容。

軟件開發的技術更新速度較塊，程序員這個群體是需要時間學習的，管理者要適當留出時間給他們學習，一直壓榨員工時間在業務上，只會撿了芝麻丟了西瓜。

產品經理：

產品輻射圈

崗位解讀：

產品在整個開發流程中是處于關鍵的協作位置：原型和文檔的輸出、需求評審會等都確保其他崗位對于需求的理解保持一致，并且要求同短時期內的需求理解一致，因為互聯網需求變更周期較短。不管哪一方需求理解錯誤，將會導致翻倍的溝通時間以及返工的時間。產品在設計的時候跟寫程序一樣要多思考邊界情況，盡量減少非需求變更導致的原型和文檔變更。

產品在整個開發過程中都要求積極參與、溝通:

開發初期：設計產品，需求評審會確保多方理解產品需求正確

開發過程中：跟進開發產出結果確保需求正確、變更需求積主動極溝通多方到位確保對于變更的需求理解一致

開發結尾階段：驗收產品、更改設計不合理的地方，再積極溝通到位

為什么那么強調要：主動積極溝通呢？？？

因為：項目經理、開發、測試、UI的工作都有依賴于產品原型和需求文檔； 項目經理依賴需求控制開發周期和任務；開發開發得業務當然依賴需求；測試的測試用例依賴需求；UI設計也依賴需求。需求一變更，下面的流程就得重新走一遍。需求一動則全身動。要時刻確保大家對于需求的理解一致，就得要求產品經理主動積極溝通到位，而不是其他崗位反過來溝通產品經理。

需求通知-關系圖

舉個錯誤的例子：

某互聯網公司技術部的某產品如何設計原型和如何主導溝通需求工作的？？？

需求文檔不用寫，原型畫的最粗糙、簡單的那種，某些交互都不說明的；他以為你們都看的懂原型和他畫的原型上的交互的。

之前偶爾開過需求評審會或者不開了，怎么開的呢？

需求確定后，通知下午X點后會議集合，然后放映原型，說這次我們要做這個，大概交互是這樣。。。

你們有什么不懂的地方或者建議都可以提出來。。。。

然后我們是第一次在會議室見到原型，我們能理解要做什么呢？？？我們什么都不懂好不，多臉懵逼逼逼逼逼逼逼逼。。。

然后講的過程中賊快，這個需求就是這樣，這個頁面就過了，下一個頁面。。。。

就這樣？？？到底是怎么樣？？？我們就這樣多臉懵逼離開會議室

這樣開需求有何意義呢，首先得提早1-2天通知我們要開需求會，先把需求原型熟悉過幾遍，對于不理解或不合理的地方記錄下來，會議上討論。

基于此，管理者就開始派發任務，各方自己去理解原型，不理解的地方再各自私聊產品，理解原型和溝通的時間算在開發時間上。這樣就會產生多個版本的需求理解。

開發期間，都是多方在主動找產品溝通的，然后產品原型修改后并沒有通知到所有人，就只有提出問題的人知道某個需求修改，多個人提出問題，最后就會導致多方多個需求理解不一致，需求理解沒實時保持一致。

收尾的時候，前后端業務需求不一致，開發和測試bug沖突，測試和產品，開發和產品，ui和前端沖突，測試按自己理解提出的bug，服務端不屌不理任務是前端的問題（各方都以為自己理解是正確）拋給前端，前端認為是設計問題，關閉bug。測試再去跟產品溝通，再次打開bug并在bug上備注“產品這樣說的”，然而前端不買賬直接轉給產品，產品再備注bug要求前端和服務端改。

導致了多少的工作量和溝通時間，我都把自己說繞了。這時候我40米的大刀已握的緊緊。

這讓整個團隊產生了多少的間隙，還談什么團隊氛圍。

讓我們來康康bug如何流轉的：

某部分bug流轉圖

這只是bug流轉圖的某個分支，最后多方互相傷害一波，火藥味濃濃啊。

所以綜上所述，產品經理實時維護好原型、需求文檔并主動積極溝通多么的重要。

UI設計師：

UI的輻射圈

崗位解讀：

如圖所示，UI崗看似被所需溝通的崗并不多，整個開發過程參與度也比較低，輸出完UI稿算是完成工作了；依賴產品原型，給予前端UI實現幫助，實時維護UI稿項目管理，有變動做到及時通知前端，收尾時變動得再提醒測試。

UI崗有點要注意的是，設計不能太天馬行空給開發帶來很多實現上的困難，同一套系統UI標準一定要規范化，設計盡量組件化。

前端/客戶端：

前端/客戶端的輻射圈

崗位解讀：

前端主要是以頁面、app、小程序等可視化程度高的為產出，這個崗位的工作內容偏依賴于其他崗位，如：產品原型、需求文檔；UI稿；服務端的API文檔等。所以在開發協作上也是需要經常溝通的。

作為開發這類人的性格都偏向不愛當面溝通，溝通能力也一般，然后前端又比較多溝通，怎么辦呢？？？

所以要借助各方所管理的協作文檔和工具，進行文本溝通。如tower任務回復、依賴線上UI稿（藍湖）產出UI界面、依賴API文檔聯調接口、bug管理系統等。

其他與多方合作該注意的細節都在上圖。

服務端：

服務端輻射圈

服務端解讀：

服務端的工作內容相對其他開發會多些，具體的見最上圖的魚骨圖。

日常工作中更多的是于前端撕逼，針對某個功能點自己實現復雜麻煩，前后端都想讓對方來實現，這時候斗舞就開始了，就看誰的理由更加充分更能說服對方了，說不過的一方只能忍氣吞聲了，所以說前后端的關系通常也沒那么好。

服務端跟前端協作該做好的一點就是，盡早設計好API接口文檔，這樣前端在寫好UI界面就能今早進入接口聯調階段。服務端也能安心寫接口實現功能等。不用空出時間和前端battle。

前后端在開發前盡量協商好api文檔的交互數據結構，不然開發后都不好改，讓誰改都容易產生點摩擦。

---

總結：

互聯網開發團隊通常都是偏中小團隊，或者按項目分組；團隊人員相對少，加重了團隊協作的重要性，活是人干的，要注重團隊間的相處溝通和氛圍，團隊管理者應及時縫合團隊裂縫，加固團隊團結。開發團隊的人員畫像的特征也比較明顯，要結合這群人的特征，按癥下藥來協調管理整個工作流程。

總結

以上是生活随笔為你收集整理的api 二次 开发 禅道_浅谈-软件开发流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。