今天，因為開發團隊的體制調整，筆者在基礎結構及技術調查方向上又增加了開發小組的管理工作，負責Web頁面（包括業務邏輯和數據訪問）的制造以及單體。因為原來主要負責技術調查工作，所以角色轉換的同時需要先明確團隊現有的軟件開發過程是否有問題，從而進行改善。
項目存在問題：
本次開發團隊的體制調整實際上是因為內部矛盾的激化，一位直線經理和業務經理（客戶代表角色、最終成果物審核）因為成果物審核問題產生了爭議，最終導致直線經理退出項目組。團隊因多年從事對日軟件外包工作，熟悉從詳細設計開始的下游設計及開發工作，本項目是第一次直接面對日本客戶，存在許多風險和問題。
1.直接面向客戶產生的問題
對日軟件外包，我們面對的是日本做上游設計的軟件開發公司，以概要設計及詳細設計為起點，所以分歧主要是設計與實現方法不一致進而需要修改設計的小問題。在大方向已經確立的前提下，成功的估算和守住交付期限即可得到良好的客戶滿意度。
對于直接面向客戶，我們因為沒有需求分析和概要設計先例，可以說基本上是零經驗。而客戶公司的IT改進部門對系統藍圖的印象模糊，且其要求的系統功能過于寬泛，導致開發團隊無法以客戶需求為基礎進行需求分析。而客戶公司存在的問題為，需求來源于不同的部門，且要求實現的層次和程度各有不同，在統一意見和對各部門需求的調查整理工作上看，客戶公司的IT改進部門是失敗的。這也是他們不愿意甚至不可能積極提供需求和確認需求的原因。在客戶IT改進部門的沒有提供適當的系統需求的前提下就要求我們的軟件開發團隊進行作業，則是把負擔加在了開發團隊的肩上。
2.客戶代表（業務經理）的問題
為了解決客戶需求沒有或不明確的問題，則設立項目主要負責人——項目組的業務經理作為業務代表，主要負責與客戶的溝通工作和提供日本客戶無法提供的功能的需求。所以很多“虛擬”的和“假定”的需求就被提出出來，但因為這部分需求來源于客戶代表（業務經理），所以口口相傳沒有進行事前記錄和整理，這就是引發此次內部矛盾的主因。
3.工程審核問題
因為客戶代表提出的需求沒有記錄，在設計人員進行概要設計和詳細設計后，所進行的內部審核也沒有客戶代表參加，所以設計人員對于需求的出發點就有可能與客戶代表（甚至是客戶）背道而馳。所以在設計的工程審核階段，大部分設計被叫停甚至是返工，嚴重導致了時間的浪費、成本的增加并遭到設計人員因返工而產生的不滿情緒。
4.項目團隊成員問題
因為長時間從事對日軟件外包，就如同被動享受填鴨式教育，使得項目團隊每天按任務計劃（WBS）做事，不能積極地為軟件開發過程作出時間安排和調整。比如，一個子模塊的開發時間安排的比較長，而測試時間比較短，作業人員不會自己協調時間，而是“打擦邊球”。開發時間長了就在完成開發作業后“休息”，等著測試開始時間的到來，這也為項目的順利進行帶來隱患。
開發人員產生了對上游設計的依賴性。沒有良好的上游設計就無法進行作業，這也是工程審核時無法通過的原因。沒有積極地試圖改進、優化開發過程，而是抱殘守缺，缺乏積極向上的態度。
4.（中間）成果物問題
嚴格地遵守時間進行作業，嚴格地提交要求的成果物，但是缺少在軟件開發過程中制作作為過渡使用的中間成果物的意識。以至上一步作業無法為下一步作業做鋪墊，相比之下是浪費了更多的時間。在數據準備方面缺乏前瞻性，不能測試先行，不提整備數據而是使用測試數據進行單體測試，導致發生系統測試時正確數據上馬后出現問題的風險。
不知道大家的項目中是否也會出現這樣的問題，如果有請寫在評論中，如果有好的解決方法也請寫在評論中。下一篇文章我會提出我對此項目組工作的改進建議，同時也會整理大家的問題和建議。希望我們能在良好的項目文化和項目管理下工作，讓我們的心情更愉悅，讓我們更快地成長，讓我們的項目能夠順利交付。由此希望大家多提意見，給我更多的力量，謝謝。
文章來源于領測軟件測試網 http://www.k11sc111.com/