新的環境、新的成員、新的客戶和新的文化,過去的2個月更多的時間忙于應戰,周末難得的梳理時間,來做些回顧和總結。
加入之初,項目啟動已經開始,對于陌生的一個產品和團隊,盡快熟悉掌握的方法莫過于通過文檔和產品環境的方式、通過日常的溝通熟悉人員。和成員一起,對產品全流程進行了驗證和記錄。市場類的項目,通過會受到直接客戶的一線壓力,尤其是新業務的項目,開始階段往往是客戶主導、公司研發,項目計劃的時間變更也相對頻繁,疲于迎戰的局面開始凸顯,但項目初始為了市場占有率,趕工和加快進度的項目方式是需要的。
產品驗證過程中,整理了“內部優化”和“外部客戶”兩份,集中精力解決“外部客戶”是當務之急。和測試成員一起,將存在的問題進行統一的跟蹤、管理,形成《問題跟蹤表》,以天為單位做早晚兩會的碰撞討論,針對問題進行會議澄清、明確開發、測試和關閉時間。安排一個測試接口人更新《問題跟蹤表》中的問題狀態和完成情況,會議期間,以測試接口人為驅動進行問題結論的確認和復盤。
一個月的沖刺過后,產品的問題基本受控,節奏也逐漸步入正軌,但更多的還是親歷親為的跟蹤和驗證,因為KPI也好、不放心也罷。五一假期選擇了加班,作為負責人,全程陪同加班似乎理所當然。回想,將任務計劃安排再細化,三天假期第一天開發成員將功能開發自測完畢并提交受控庫,第二天集體休息,第三天開發、測試成員進行開發測試的迭代,完成版本關閉,也許效果會更好。
產品演示臨近,需求還是源源不斷,一方面與客戶的溝通引導,去掉優先級低的需求,一方面加班趕工開發重點功能。人力不夠的情況下與領導及時溝通協調,增派人力。版本開發、測試完畢后,接下來需要做的就是測試數據清理、真實數據導入、全流程預演。演示當天,安排技術人員進行保障,演示環境主備準備。
最終,演示順利完成。大家的辛苦付出得到肯定。同時,也在思考項目化運作流程,不一定成熟,分享(持續更新):
1、需求討論階段(Demo演示),產品導入期:
功能開發和測試進度跟蹤一般較密,建議每1~2天開一次例會,緊急情況至少每天1次例會,將問題通過《跟蹤表》進行任務評審、分派和時間明確。其中:
1.驅動測試端來跟蹤故障單的解決進展。
2.測試完成后,讓開發打包做成臨時版本部署到前方demo環境。
3.開發的功能及時發布到受控庫。
4.測試做好故障的記錄。
5.做好版本控制。
6.根據成員對任務的完成效率和質量,進行考核。
2、需求收斂階段(試商用/商用),產品成長期:
1.整理《問題跟蹤表》,大的需求單獨編寫成《軟件需求》,與開發、測試評審、評估時間,反饋客戶演示/驗收/交付時間。
2.跟蹤開發進展,版本提交節點提醒開發組、版本發布節點提醒測試組。
3.版本管理員制作正式版本并發布到版本庫。
4.編寫《基線手冊》,組織開發組、測試組、工程組評審。
5.發布《基線手冊》給工程組,由工程組找版本管理員提取正式版本,跟蹤工程進展。
6.收集項目試商用期間的問題,規劃新版本。
7.了解和挖據未來潛在需求,規劃新版本。
8.根據成員對任務的完成效率和質量,進行考核。
9.如此迭代。
posted on 2013-06-16 13:57
cheng 閱讀(2594)
評論(2) 編輯 收藏 所屬分類:
通信&政企產品