大家好。 我經常看到同樣的情況，尤其是在外包領域。 各個項目的團隊缺乏清晰的工作流程。
最重要的是，程序員不明白如何與客戶以及彼此之間進行溝通。 如何建立開發優質產品的持續流程。 如何計劃你的工作日和衝刺。
所有這一切最終會導致最後期限被打破、加班、不斷地攤牌誰應該受到責備以及客戶不滿意——一切進展到哪里以及如何進展。 很多時候，所有這些都會導致程序員甚至整個團隊的變化。 客戶流失、聲譽惡化等。
有一次，我剛剛接手了這樣一個項目，其中充滿了所有這些樂趣。
沒有人願意為這個項目（一個大型服務市場）負責，營業額很糟糕，客戶只是撕扯和扔掉。 首席執行官以某種方式找到我，說你有必要的經驗，所以你手裡有牌。 自己承擔這個項目。 如果你搞砸了，我們將關閉該項目並將所有人踢出。 事實證明，它會很酷，然後按照你認為合適的方式領導它並發展它。 結果，我成為了這個項目的組長，所有的事情都落在了我的肩上。
我做的第一件事就是從頭開始設計一個符合我當時願景的工作流程，並為團隊編寫工作描述。 實施它並不容易。 但一個月之內，一切都安定下來，開發人員和客戶都習慣了，一切都安靜而舒適地進行。 為了向團隊表明，這不僅僅是一場玻璃風暴，而是真正擺脫困境的出路，我承擔了最大的責任，消除了團隊中不愉快的慣例。
一年半的時間已經過去了，項目的進展沒有加班，沒有“激烈的競爭”，也沒有各種壓力。 老團隊裡有人不願意這樣工作就離開了，相反，有人真的鑽進去了，透明的規則出現了。 但結果是，團隊中的每個人都非常積極，並且完全了解這個龐大的項目，無論是前端還是後端。 包括代碼庫和所有業務邏輯。 甚至到了我們不僅僅是“划船者”，而是我們自己提出了許多業務流程和業務喜歡的新功能。
由於我們採取了這種方法，客戶決定從我們公司訂購另一個市場，這是個好消息。
由於這適用於我的項目，也許它也會對某人有所幫助。 所以，這個過程本身幫助我們保存了項目：
“我最喜歡的項目”項目的團隊合作過程
a) 在團隊流程內（開發人員之間）
- 所有任務均在 Jira 系統中創建
- 每項任務都應盡可能詳細地描述，並嚴格執行一個動作。
- 任何功能，如果足夠複雜，都會被分解為許多小任務
- 團隊將功能作為一項單一任務來工作。 首先，我們一起開發一個功能，進行測試，然後再進行下一個功能。
- 每個任務都標記為後端或前端
- 有多種類型的任務和錯誤。 您需要正確指定它們。
- 任務完成後，轉入代碼審查狀態（為其同事創建拉取請求）
- 完成任務的人立即記錄他完成該任務的時間
- 檢查代碼後，PR 獲得批准，之後，執行此任務的人獨立地將其合併到 master 分支，之後將其狀態更改為準備部署到開發服務器。
- 所有準備部署到開發服務器的任務均由團隊負責人（他的職責範圍）部署，如果事情緊急，有時也由團隊成員部署。 部署完成後，從準備部署到開發的所有任務都會轉移到狀態 - 準備在開發上測試
- 所有任務均由客戶測試
- 當客戶在開發人員上測試了任務後，他將其轉移到準備部署到生產的狀態。
- 為了部署到生產，我們有一個單獨的分支，我們在部署之前合併主分支
- 如果在測試過程中客戶發現錯誤，則他會將任務返回進行修訂，並設置其狀態返回進行修訂。 這就是我們將新任務與未經測試的任務分開的方式。
- 因此，所有任務從創建到完成：待辦事項→開發中→代碼審查→準備部署到開發→開發上的質量檢查→（返回開發）→準備部署到生產→生產上的質量檢查→完成
- 每個開發人員都獨立測試他的代碼，包括作為網站的用戶。 不允許將分支與主分支合併，除非確定代碼可以工作。
- 每項任務都有優先級。 優先級由客戶或團隊領導設定。
- 開發人員首先執行優先任務。
- 如果系統中發現不同的錯誤，或者一項任務由多名專家共同完成，開發人員可以相互分配任務。
- 客戶創建的所有任務都會發送給團隊領導，團隊領導會對這些任務進行評估，並要求客戶完成這些任務或將其分配給一名團隊成員。
- 所有準備部署到開發或生產的任務也會交給團隊負責人，由他獨立決定何時以及如何部署。 每次部署後，團隊領導（或團隊成員）必須將此情況通知客戶。 並且還將任務的狀態更改為準備在開發/生產上進行測試。
- 每天同一時間（我們在 12.00 點）我們在所有團隊成員之間舉行集會
- 集會上的每個人都報告，包括隊長，他昨天做了什麼，今天打算做什麼。 什麼不起作用以及為什麼不起作用。 因此，整個團隊都知道誰在做什麼以及項目處於哪個階段。 這使我們有機會預測並在必要時調整我們的估計和截止日期。
- 會上，組長還宣布了項目中的所有變更以及當前客戶未發現的Bug的級別。 所有的bug都會被整理出來並分配給每個團隊成員來解決。
- 在集會上，團隊領導為每個人分配任務，考慮到開發人員當前的工作量、他們的專業培訓水平，並考慮到特定任務與開發人員當前正在做的事情的接近程度。
- 在會議上，團隊負責人制定架構和業務邏輯的總體策略。 之後，整個團隊對此進行討論並決定是否進行調整或採用該策略。
- 每個開發人員在單一架構和業務邏輯中獨立編寫代碼並構建算法。 每個人都可以表達自己的實施願景，但沒有人強迫任何人這樣做而不是其他方式。 每一個決定都是合理的。 如果有更好的解決方案，但現在沒有時間，那麼就在fat中創建一個任務，以供將來重構某部分代碼。
- 當開發人員承擔一項任務時，他會將其轉移到開發狀態。 所有與客戶澄清任務有關的溝通都落在開發人員的肩上。 技術問題可以向團隊領導或同事提出。
- 如果開發人員不理解任務的本質，而客戶也無法明智地解釋它，那麼他就會繼續執行下一個任務。 然後團隊領導拿當前的一份並與客戶討論。
- 每天，開發人員應該在客戶的聊天中寫下他昨天做了什麼任務以及今天要做什麼任務
- 工作流程基於 Scrum。 一切都分為衝刺。 每個衝刺持續兩週。
- Sprint 由團隊負責人創建、填充和結束。
- 如果項目有嚴格的截止日期，那麼我們會嘗試粗略地估計所有任務。 我們從他們那裡收集了一個衝刺。 如果客戶嘗試向衝刺添加更多任務，那麼我們會設置優先級，並將一些其他任務轉移到下一個衝刺。
b) 與客戶合作的過程
- 每個開發人員都可以而且應該與客戶溝通
- 你不能允許客戶強加他們自己的遊戲規則。 有必要以禮貌和友好的方式向客戶表明我們是我們領域的專家，只有我們應該建立工作流程並讓客戶參與其中
- 理想情況下，在繼續實現任何功能之前，有必要為某個功能（工作流）創建整個邏輯過程的流程圖。 並發送給客戶確認。 這僅適用於復雜且不明顯的功能，例如支付系統、通知系統等。 這將使您能夠更準確地了解客戶到底需要什麼，保存該功能的文檔，並確保自己免受客戶將來可能說我們沒有按照他的要求做的情況。
- 所有圖表/流程圖/邏輯等。 我們保存在Confluence/Fat中，我們在評論中要求客戶確認未來實施的正確性。
- 我們盡量不給客戶增加技術細節的負擔。 如果我們需要了解客戶的需求，那麼我們會以流程圖的形式繪製原始算法，以便客戶可以自己理解並修復/修改所有內容。
- 如果客戶發現項目中存在錯誤，那麼我們會要求您在 Fat 中詳細描述它。 它是在什麼情況下發生的、何時發生的、客戶在測試過程中執行了哪些操作順序。 請附上屏幕截圖。
- 我們每天（最多每隔一天）嘗試部署到開發服務器。 然後客戶開始測試功能，項目也沒有閒著。 同時，這向客戶表明該項目正在全面開發，沒有人給他講童話故事。
- 經常發生客戶根本不完全了解他的需求的情況。 由於他為自己創建了一個新業務，流程尚未調試。 因此，一個非常常見的情況是，我們將整段代碼扔進垃圾箱並重塑應用程序邏輯。 由此可見，沒有必要用測試來覆蓋所有的事情。 通過測試僅覆蓋關鍵功能，然後進行保留是有意義的。
- 在某些情況下，團隊意識到我們無法在最後期限內完成。 然後我們對任務進行快速審核，並立即通知客戶。 作為擺脫這種情況的出路，我們建議按時推出重要且關鍵的功能，並將其餘的留給發布後。
- 如果客戶開始從他的頭腦中提出不同的任務，開始用手指幻想和解釋，那麼我們要求他向我們提供一個頁面佈局和邏輯流程，該邏輯應充分描述整個佈局及其元素的行為。
- 在我們承擔任何任務之前，我們必須確保此功能包含在我們的協議/合同條款中。 如果這是一個超出我們最初協議的新功能，那麼我們一定要估計這個功能（（大約交付時間 + 30%）x 2），並向客戶表明我們將花費很多時間來完成它，而且截止日期要按估計時間乘以二來調整。 讓我們加快任務速度 - 太好了，每個人都會從中受益。 如果沒有，那麼我們就有保險。
c) 我們在團隊中不接受的：
- 不一致、不連貫、健忘
- “早餐餵養”。 如果你無法完成任務，你不知道如何完成，那麼你需要立即通知組長，而不是等到最後。
- 布羅瓦達和誇耀來自一個尚未用行動證明自己的能力和專業精神的人。 如果被證明，那麼這是可能的，在正派的範圍內🙂
- 各種形式的欺詐。 如果任務未完成，那麼您不應將其狀態更改為已完成，也不應在客戶的聊天中寫入其已準備就緒。 電腦死機、系統崩潰、狗咬筆記本電腦——這一切都是不可接受的。 如果確實發生不可抗力，則應立即通知組長。
- 當專家始終離線並且工作時間很難聯繫到他時。
- 隊伍中不允許有毒害行為！ 如果有人不同意某件事，那麼大家就聚集在一起，討論並決定。
我有時會要求客戶消除所有誤解的一些問題/論文：
- 你們的質量標準是什麼？
- 如何判斷一個項目有沒有問題？
- 違反我們所有更改/改進系統的建議和建議，所有風險僅由您承擔
- 任何重大的項目變更（例如，各種額外流程）都可能導致出現錯誤（我們當然會修復這些錯誤）
- 不可能在幾分鐘之內了解項目中出現了什麼樣的問題，更不可能當場修復它
- 我們致力於特定的產品流程（Zira 中的任務 - 開發 - 測試 - 部署）。 這意味著我們無法回复聊天中的整個請求和投訴流程。
- 程序員只是程序員，不是專業的測試人員，無法保證項目測試的正確質量
- 最終測試和接受銷售任務的責任完全由您承擔
- 如果我們已經承擔了一項任務，那麼在完成當前任務之前我們不能立即切換到其他任務（否則這會導致更多錯誤並增加開發時間）
- 團隊人數較少（由於假期或生病），工作量較多，我們沒有時間回應您想要的一切
- 要求您在開發中沒有測試任務的情況下部署到生產環境只是您的風險，而不是開發人員的風險
- 當您設置模糊任務，沒有正確的流程，沒有設計佈局時，這需要我們付出更多的努力和實施時間，因為我們必須代替您做額外的工作量
- 任何有關錯誤的任務，如果沒有詳細描述其發生情況和螢幕截圖，都不會讓我們有機會了解出了什麼問題以及如何修復此錯誤
- 該項目需要不斷完善和改進，以提高性能和安全性。 因此，團隊花費了一些時間來進行這些改進。
- 由於我們有加班時間（緊急修復），我們必須在其他日子進行補償
通常，客戶立即就會明白軟件開發中的一切並不那麼簡單，僅靠願望顯然是不夠的。
一般來說，這就是全部。 在幕後，我留下了很多談判和所有流程的初步調試，但結果，一切順利。 我可以說這個過程對我們來說已經成為一種“銀彈”。 來到該項目的新人從第一天起就可以立即上手工作，因為所有流程都被描述，並且圖表形式的文檔和架構立即讓我們了解了我們在這裡所做的事情。
PS 我想澄清一下，我們這邊沒有項目經理。 它在客戶端。 根本不是技術人員。 歐洲項目。 所有溝通均僅使用英語。
祝您的項目中的每個人好運。 不要精疲力盡，並嘗試改進您的流程。
來源在我的 .
來源： www.habr.com