時，大家最好一起來面對，問清楚問題的狀況和可能的方案，并討論方案的合理性和優(yōu)劣，根據(jù)當(dāng)前情況(項目資源、技術(shù)難易)來選擇最優(yōu)方案。
總是覺得項目管理知識體系中的一點一滴，就這樣無聲的出現(xiàn)在我們的項目中。正是這種“潤物細無聲”，才讓我們的項目更成功。
突期而至的指責(zé)
某個周一的下午，我突然接到領(lǐng)導(dǎo)的電話，責(zé)問我為何沒有安排出包？我心里直納悶，上周五按項目安排已經(jīng)出包了呀。問經(jīng)理他不清楚，他說項目管理辦公室的經(jīng)理打電話責(zé)問他的。我心里很不舒服，領(lǐng)導(dǎo)呀領(lǐng)導(dǎo)，你搞清楚了再來責(zé)問我行不行呀？只有窩著一肚子火，跑到項目管理辦公室，去問清楚究竟是咋回事。原來呀，測試部門周末加班測試，用我們部門的包安裝了但出錯，幾個人折騰了兩天，把測試經(jīng)理也氣得夠嗆，后來只有把我們包降級了才勉強測試下去。
我一聽氣樂了，哎喲嚯，我按照項目的要求出包，責(zé)任到輪到我們頭上了，另外一個模塊為何沒有按時出包，主要責(zé)任也是他們的呀。再說了，測試出問題時也沒有任何人要我們支持呀，出了問題也不問清楚緣由就直接找到我們領(lǐng)導(dǎo)，有這樣做事的嘛。后來討論了半天，本著“治病救人”的心態(tài)，我承認了我們的不足，要在releasenote中寫清楚關(guān)聯(lián)模塊的版本名稱。
首先是出包時間點的檢查，沒有形成有效的機制，沒有一份完整的check list，沒有人來匯總所有相關(guān)模塊是否都已經(jīng)出包，項目經(jīng)理不光要提前提醒，還得實時檢查及時發(fā)現(xiàn)問題，而不是等到測試部門測試了兩天之后再來檢查哪處問題了。
其次，溝通很重要，也要講究方法。如果是測試一開始暴露問題時就及時溝通找研發(fā)查原因，也不至于白白浪費幾人天的測試工作；本來我們release時寫了依賴模塊，但測試部門的人員認為這兩模塊本來就有依賴關(guān)系，看不懂有什么奧秘。另外，經(jīng)理之間的相互“告狀”只是讓問題變得更復(fù)雜，更不利于團隊建設(shè)，項目經(jīng)理尤其要注意，主要是解決問題、推動項目的進展，其次是總結(jié)經(jīng)驗教訓(xùn)避免重復(fù)的錯誤代價。