先直接放出我對(duì)軟件開(kāi)發(fā)的相關(guān)人員職責(zé)和流程：

圖一：軟件開(kāi)發(fā)的相關(guān)人員職責(zé)

以下是截屏的開(kāi)發(fā)流程泳道圖：

橫軸是相關(guān)開(kāi)發(fā)人員的工作模塊；縱軸是從上至下開(kāi)發(fā)時(shí)序周期。

圖二：軟件開(kāi)發(fā)的流程圖

從職責(zé)圖和流程圖對(duì)應(yīng)到我們實(shí)際處在軟件開(kāi)發(fā)過(guò)程中好像就是這樣，并無(wú)不妥的地方；但是拆分下去并結(jié)合你的崗位工作經(jīng)驗(yàn)就會(huì)發(fā)現(xiàn)某些環(huán)節(jié)難以形成流程標(biāo)準(zhǔn)，和很多需要注意的細(xì)節(jié)。接下去我們可以來(lái)聊聊其中的問(wèn)題。

---

開(kāi)發(fā)流程涉及到他人協(xié)作的模塊：

項(xiàng)目經(jīng)理：任務(wù)管理系統(tǒng)（Tower任務(wù)管理工具）；

產(chǎn)品經(jīng)理：產(chǎn)品原型和需求文檔（Axure原型）；

UI設(shè)計(jì)師：UI稿管理項(xiàng)目（藍(lán)湖）；

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

測(cè)試組：bug管理系統(tǒng)（禪道）。

以上的各崗位所管理的項(xiàng)目系統(tǒng)是涉及到與其他同事協(xié)作的工作內(nèi)容，有依賴時(shí)間順序、有依賴他人工作和需做出回應(yīng)的。

涉及到協(xié)作的工作內(nèi)容，我們應(yīng)該做好本職工作以免給他人添加額外的時(shí)間成本、工作量，導(dǎo)致嫌隙；不利于團(tuán)隊(duì)關(guān)系和氣氛。

---

在開(kāi)發(fā)流程中，在完成本職工作上，為什么我們應(yīng)該更加注重團(tuán)隊(duì)協(xié)作和工作上的合作、磨合？？？

軟件項(xiàng)目的開(kāi)發(fā)更注重各崗位的協(xié)作，才能更好更快的產(chǎn)出預(yù)期的項(xiàng)目；

軟件開(kāi)發(fā)需要較少的人員參與，但工作也是人做的，都會(huì)帶入情緒、情感，協(xié)作上我們應(yīng)該盡量通過(guò)標(biāo)準(zhǔn)化流程避免些不必要的摩擦；帶給員工良好的合作體驗(yàn)；

軟件開(kāi)發(fā)的人員畫像大部分是些內(nèi)向、不善溝通、不愿多溝通的；應(yīng)通過(guò)協(xié)作管理工具和流程標(biāo)準(zhǔn)來(lái)減少不必要的溝通；這樣就能更專注的coding和設(shè)計(jì)，不常被流程外的消息打斷、打擾，擾亂思緒。

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

開(kāi)發(fā)主管/項(xiàng)目經(jīng)理：

項(xiàng)目主管/項(xiàng)目經(jīng)理的輻射圈

崗位解讀：

在把控進(jìn)度和質(zhì)量上，要善于利用任務(wù)管理工具；如：Tower，任務(wù)狀態(tài)更改，相關(guān)人員都會(huì)接受到通知，減少程序員的溝通時(shí)間和避開(kāi)他們當(dāng)面溝通能力不足的情況，轉(zhuǎn)而通過(guò)文檔溝通

對(duì)內(nèi)把控項(xiàng)目進(jìn)度、質(zhì)量之外，他們的日常工作更應(yīng)該關(guān)注團(tuán)隊(duì)管理，了解成員情況，消除不和諧因素，充當(dāng)團(tuán)隊(duì)潤(rùn)滑劑。了解員工留在公司的原因，通勤時(shí)間短、公司穩(wěn)定、薪資待遇、同事團(tuán)隊(duì)和諧、團(tuán)隊(duì)氛圍好、職位有的發(fā)展、有利于當(dāng)前學(xué)習(xí)？以及近期將來(lái)的打算和職業(yè)規(guī)劃。這得要求管理者比較懂得一些為人處世的經(jīng)驗(yàn)。

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

大部分中小團(tuán)隊(duì)提拔管理者只看到技術(shù)能力這方面的考核，過(guò)于片面，未正確認(rèn)識(shí)管理者充當(dāng)?shù)慕巧凸ぷ鲀?nèi)容。

軟件開(kāi)發(fā)的技術(shù)更新速度較塊，程序員這個(gè)群體是需要時(shí)間學(xué)習(xí)的，管理者要適當(dāng)留出時(shí)間給他們學(xué)習(xí)，一直壓榨員工時(shí)間在業(yè)務(wù)上，只會(huì)撿了芝麻丟了西瓜。

產(chǎn)品經(jīng)理：

產(chǎn)品輻射圈

崗位解讀：

產(chǎn)品在整個(gè)開(kāi)發(fā)流程中是處于關(guān)鍵的協(xié)作位置：原型和文檔的輸出、需求評(píng)審會(huì)等都確保其他崗位對(duì)于需求的理解保持一致，并且要求同短時(shí)期內(nèi)的需求理解一致，因?yàn)榛ヂ?lián)網(wǎng)需求變更周期較短。不管哪一方需求理解錯(cuò)誤，將會(huì)導(dǎo)致翻倍的溝通時(shí)間以及返工的時(shí)間。產(chǎn)品在設(shè)計(jì)的時(shí)候跟寫程序一樣要多思考邊界情況，盡量減少非需求變更導(dǎo)致的原型和文檔變更。

產(chǎn)品在整個(gè)開(kāi)發(fā)過(guò)程中都要求積極參與、溝通:

開(kāi)發(fā)初期：設(shè)計(jì)產(chǎn)品，需求評(píng)審會(huì)確保多方理解產(chǎn)品需求正確

開(kāi)發(fā)過(guò)程中：跟進(jìn)開(kāi)發(fā)產(chǎn)出結(jié)果確保需求正確、變更需求積主動(dòng)極溝通多方到位確保對(duì)于變更的需求理解一致

開(kāi)發(fā)結(jié)尾階段：驗(yàn)收產(chǎn)品、更改設(shè)計(jì)不合理的地方，再積極溝通到位

為什么那么強(qiáng)調(diào)要：主動(dòng)積極溝通呢？？？

因?yàn)?#xff1a;項(xiàng)目經(jīng)理、開(kāi)發(fā)、測(cè)試、UI的工作都有依賴于產(chǎn)品原型和需求文檔； 項(xiàng)目經(jīng)理依賴需求控制開(kāi)發(fā)周期和任務(wù)；開(kāi)發(fā)開(kāi)發(fā)得業(yè)務(wù)當(dāng)然依賴需求；測(cè)試的測(cè)試用例依賴需求；UI設(shè)計(jì)也依賴需求。需求一變更，下面的流程就得重新走一遍。需求一動(dòng)則全身動(dòng)。要時(shí)刻確保大家對(duì)于需求的理解一致，就得要求產(chǎn)品經(jīng)理主動(dòng)積極溝通到位，而不是其他崗位反過(guò)來(lái)溝通產(chǎn)品經(jīng)理。

需求通知-關(guān)系圖

舉個(gè)錯(cuò)誤的例子：

某互聯(lián)網(wǎng)公司技術(shù)部的某產(chǎn)品如何設(shè)計(jì)原型和如何主導(dǎo)溝通需求工作的？？？

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

之前偶爾開(kāi)過(guò)需求評(píng)審會(huì)或者不開(kāi)了，怎么開(kāi)的呢？

需求確定后，通知下午X點(diǎn)后會(huì)議集合，然后放映原型，說(shuō)這次我們要做這個(gè)，大概交互是這樣。。。

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

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

然后講的過(guò)程中賊快，這個(gè)需求就是這樣，這個(gè)頁(yè)面就過(guò)了，下一個(gè)頁(yè)面。。。。

就這樣？？？到底是怎么樣？？？我們就這樣多臉懵逼離開(kāi)會(huì)議室

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

基于此，管理者就開(kāi)始派發(fā)任務(wù)，各方自己去理解原型，不理解的地方再各自私聊產(chǎn)品，理解原型和溝通的時(shí)間算在開(kāi)發(fā)時(shí)間上。這樣就會(huì)產(chǎn)生多個(gè)版本的需求理解。

開(kāi)發(fā)期間，都是多方在主動(dòng)找產(chǎn)品溝通的，然后產(chǎn)品原型修改后并沒(méi)有通知到所有人，就只有提出問(wèn)題的人知道某個(gè)需求修改，多個(gè)人提出問(wèn)題，最后就會(huì)導(dǎo)致多方多個(gè)需求理解不一致，需求理解沒(méi)實(shí)時(shí)保持一致。

收尾的時(shí)候，前后端業(yè)務(wù)需求不一致，開(kāi)發(fā)和測(cè)試bug沖突，測(cè)試和產(chǎn)品，開(kāi)發(fā)和產(chǎn)品，ui和前端沖突，測(cè)試按自己理解提出的bug，服務(wù)端不屌不理任務(wù)是前端的問(wèn)題（各方都以為自己理解是正確）拋給前端，前端認(rèn)為是設(shè)計(jì)問(wèn)題，關(guān)閉bug。測(cè)試再去跟產(chǎn)品溝通，再次打開(kāi)bug并在bug上備注“產(chǎn)品這樣說(shuō)的”，然而前端不買賬直接轉(zhuǎn)給產(chǎn)品，產(chǎn)品再備注bug要求前端和服務(wù)端改。

導(dǎo)致了多少的工作量和溝通時(shí)間，我都把自己說(shuō)繞了。這時(shí)候我40米的大刀已握的緊緊。

這讓整個(gè)團(tuán)隊(duì)產(chǎn)生了多少的間隙，還談什么團(tuán)隊(duì)氛圍。

讓我們來(lái)康康bug如何流轉(zhuǎn)的：

某部分bug流轉(zhuǎn)圖

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

所以綜上所述，產(chǎn)品經(jīng)理實(shí)時(shí)維護(hù)好原型、需求文檔并主動(dòng)積極溝通多么的重要。

UI設(shè)計(jì)師：

UI的輻射圈

崗位解讀：

如圖所示，UI崗看似被所需溝通的崗并不多，整個(gè)開(kāi)發(fā)過(guò)程參與度也比較低，輸出完UI稿算是完成工作了；依賴產(chǎn)品原型，給予前端UI實(shí)現(xiàn)幫助，實(shí)時(shí)維護(hù)UI稿項(xiàng)目管理，有變動(dòng)做到及時(shí)通知前端，收尾時(shí)變動(dòng)得再提醒測(cè)試。

UI崗有點(diǎn)要注意的是，設(shè)計(jì)不能太天馬行空給開(kāi)發(fā)帶來(lái)很多實(shí)現(xiàn)上的困難，同一套系統(tǒng)UI標(biāo)準(zhǔn)一定要規(guī)范化，設(shè)計(jì)盡量組件化。

前端/客戶端：

前端/客戶端的輻射圈

崗位解讀：

前端主要是以頁(yè)面、app、小程序等可視化程度高的為產(chǎn)出，這個(gè)崗位的工作內(nèi)容偏依賴于其他崗位，如：產(chǎn)品原型、需求文檔；UI稿；服務(wù)端的API文檔等。所以在開(kāi)發(fā)協(xié)作上也是需要經(jīng)常溝通的。

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

所以要借助各方所管理的協(xié)作文檔和工具，進(jìn)行文本溝通。如tower任務(wù)回復(fù)、依賴線上UI稿（藍(lán)湖）產(chǎn)出UI界面、依賴API文檔聯(lián)調(diào)接口、bug管理系統(tǒng)等。

其他與多方合作該注意的細(xì)節(jié)都在上圖。

服務(wù)端：

服務(wù)端輻射圈

服務(wù)端解讀：

服務(wù)端的工作內(nèi)容相對(duì)其他開(kāi)發(fā)會(huì)多些，具體的見(jiàn)最上圖的魚骨圖。

日常工作中更多的是于前端撕逼，針對(duì)某個(gè)功能點(diǎn)自己實(shí)現(xiàn)復(fù)雜麻煩，前后端都想讓對(duì)方來(lái)實(shí)現(xiàn)，這時(shí)候斗舞就開(kāi)始了，就看誰(shuí)的理由更加充分更能說(shuō)服對(duì)方了，說(shuō)不過(guò)的一方只能忍氣吞聲了，所以說(shuō)前后端的關(guān)系通常也沒(méi)那么好。

服務(wù)端跟前端協(xié)作該做好的一點(diǎn)就是，盡早設(shè)計(jì)好API接口文檔，這樣前端在寫好UI界面就能今早進(jìn)入接口聯(lián)調(diào)階段。服務(wù)端也能安心寫接口實(shí)現(xiàn)功能等。不用空出時(shí)間和前端battle。

前后端在開(kāi)發(fā)前盡量協(xié)商好api文檔的交互數(shù)據(jù)結(jié)構(gòu)，不然開(kāi)發(fā)后都不好改，讓誰(shuí)改都容易產(chǎn)生點(diǎn)摩擦。

---

總結(jié)：

互聯(lián)網(wǎng)開(kāi)發(fā)團(tuán)隊(duì)通常都是偏中小團(tuán)隊(duì)，或者按項(xiàng)目分組；團(tuán)隊(duì)人員相對(duì)少，加重了團(tuán)隊(duì)協(xié)作的重要性，活是人干的，要注重團(tuán)隊(duì)間的相處溝通和氛圍，團(tuán)隊(duì)管理者應(yīng)及時(shí)縫合團(tuán)隊(duì)裂縫，加固團(tuán)隊(duì)團(tuán)結(jié)。開(kāi)發(fā)團(tuán)隊(duì)的人員畫像的特征也比較明顯，要結(jié)合這群人的特征，按癥下藥來(lái)協(xié)調(diào)管理整個(gè)工作流程。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。