項目越來越充實，開發隊伍也逐漸壯大，雖然進度還勉強能跟上，但在團隊內和團隊間的協作上還是存在著一些既定或者潛在的問題，這些問題也影響到了項目的質量和進度，而當談起這些問題的時候，往往又會出現互相扯皮的現象。即使在一個規模很大，管理很規范的公司，這樣的問題也比較常見。一位在500強跨國公司的朋友就曾經向我抱怨他們公司內部協調是多么的困難，而國內這些類似作坊的企業，問題的嚴重性更是不言而喻。如何解決這些問題，是每個項目管理人員應該想而且應該做的事情。
   在項目的開發和測試過程中，不和諧的因素主要有開發團隊內部，開發團隊和測試團隊，開發團隊和銷售團隊之間，這些不和諧我想從以下幾個方面可以解決或得以緩解。
   首先從我們自身的角度來尋找問題根源，我發現開發人員都有一個大的通病，不喜歡和人溝通，在某些公司，比如外包公司，軟件的需求文檔比較完善和固定，這時候開發人員只需要按照文檔進行開發，是沒有問題的，但在一些自己研發產品自己經營的公司中，產品的需求往往是瞬息萬變的。開發文檔也不會太及時，我們一些開發人員就喜歡將模模糊糊的需求實現就可以了，不會主動和產品部門和測試部門進行有效溝通，往往是我們費了九牛二虎之力做出來一個功能，拿給產品部門看的時候，人家卻拼命搖頭說這不是他們想要的，人生最大的痛苦莫過于此吧。我們很生氣，因為我們付出了勞動，卻得不到認同，產品也同樣生氣，他們的產品又不能按時完成了。如何解決這個問題，究我們自身的原因，我想我們開發人員過于被動了，出現不理解或者模糊的需求，大多數情況不是去詢問產品設計人員，而是根據我們自己的喜好來閉門造車，最后造成人力物力的雙重損失，如果產品設計人員和研發人員地域上距離較遠，不便于交流，溝通的話，這樣還情有可原，但坐在一個辦公室，為什么就不能事先交流一下呢。是不敢，不屑還是從來沒想過交流的重要性呢？反正我目前的工作方式為出現我不理解的地方，我肯定要找相關產品設計人員進行有效溝通，我從不擔心他會煩，怕煩他應該早早的把設計文檔寫清楚才對。經過溝通做出來的產品更容易被人認同，這點我目前也是深有體會的。
   而事出有因，莫怪一方，產品和測試部門同樣也有著不可推卸的責任，首先有些產品設計人員寫出來的文檔模棱兩可，不是很規范，需求在逐漸變化的過程中，產品部門卻不能及時的將需求文檔更新并交開發人員。這樣也造成了開發人員費力做出來的東西和需求脫節。造成產品部門與開發部門的分歧。解決這個問題產品部門應該盡量將文檔作的更加規范一些。也應該督促和跟蹤開發過程，當發現開發人員所開發產品和需求不一致的時候，有權利也有義務及時提醒。大家的目的都是一個，都是好好的工作，為公司創造更大的價值。而不能一味互相扯皮，互相詰責。
    與測試團隊的協調更為重要，有的時候，一些開發人員不能理解測試人員的工作，認為測試人員過于吹毛求疵，雞蛋里面挑骨頭，殊不知，一個成功的軟件，測試團隊和開發團隊都起著不可或缺的作用，開發人員往往不知廬山真面目，只因身在此山中，有些bug開發人員根本不可能找出來，開發人員都以一種正向思維考慮問題，有些問題就是開發人員的盲點，加上某些開發人員不太注重細節，人物功能實現了就可以了，界面上的工夫不值得去下。這種觀點肯定是錯誤的，大家從微軟的產品中就可以看出來，微軟總能夠將已經存在并且前景已經被證明不錯的產品經過加工從而普及開來，比如office,windows,aja,ie,我們開發人員要從思想上認識到“細節決定一切”，一個商業軟件，不僅要有足夠的功能，而且也要有人性化的界面。所以當測試人員提出一些有關UI，比如顏色，字體等問題的時候，我們一定要耐心的解決，而不是持敵對心理。
     一句話說的好：設計和編程都是人的活動，忘記這一點，將會失去一切！我們在工作的過程中，多些溝通，多些理解，少些抱怨，爭取早日登上軟件開發的和諧號