艾偉也談專案管理,成功軟體專案管理的奧秘

2021-09-08 23:05:59 字數 3132 閱讀 8716

如何入門並設定軟體成功的目標

實踐技能建議

要點說明

1.設定優先順序 1)

為團隊成員提供服務

2)滿足組織客戶的需求

3)從事自己相關的專案

2.分析自我能力差距

人員管理(人際關係、解決衝突、推銷想法)

聆聽技巧

鍛鍊演講表達能力

3. 學會定義質量

與開發團隊、客戶確定一致的產品質量定義與準則

4. 鼓勵團隊所取得的進步

指定鼓勵計畫(精神鼓勵與物質獎勵)

5. 從歷史中學習

6. 設定團隊改進目標

設定長期與短期的改進目標

如需求變更、軟體質量。通過制定具體的改進指標進行具體量化。

通過活動掛圖、故事牆等方式來向整個團隊找出和展示需要改進的項和成果。

7.慢慢的起步

實踐練習:

找出自己在專案管理、人員管理和團隊領導力中的短板,並想辦法進行提高;找到一些經驗豐富的專案經理們作為你學習的楷模,並嘗試運用它們的優點;從你過去的一些上司、領導處總結哪些行為和特點是你無法忍受的,然後再你自己的管理工作中去規避這些做法。

當產品已經足夠好的情況下,可以確認是否已經完成。

「足夠好」:是指產品已經具備一些可接受的綜合屬性,如功能、質量、時效性、客戶價值、競爭力以及支撐的基礎設施已經準備就緒。

客戶對質量的看法主要取決於可靠性(持續執行無故障)和效能(操作的響應時間)

內部對質量的看法主要設計如下方面:軟體在未來的可修改性、可維護性、文件的可理解性等

如何定義產品發布準則?

發布準則必須要與成功準則相對應,沒有放四海而皆準的發布準則,要確保專案取得最終的成功,反映產品能夠上線發布的指標都必須要有一定的可信度和可測度。

如果指定了不符合專案業務目標的寬鬆的發布準則,可能會造成一種一定會可能會取得成功的假象。

一些寬鬆的發布準則:廣泛的客戶群體**率,「很高的客戶滿意度」

某些模稜兩可的措辭:可接受的、足夠的、恰當的、廣泛的、精確地、高的、改進的、低的、合理的、健壯的、準確無誤的和有效率的。這些措辭要盡量避免使用。

發布準則必須要滿足

specific【明確的(不是空泛的)】

measurable【可度量的(不是定性的或主觀的)】

attainable【可實現的(不是一對不可能實現的目標)】

relevant【相關的(與客戶要求和業務目標相關聯)】

trackable【可跟蹤的(在整個專案過程中可以進行監控)】

制定準則時:

認真考慮不同專案干係人對團體的想法和意見,避免衝突和分歧

考慮使用者提出的驗收標準

於關鍵使用者代表進行充分溝通

出現衝突時,全體團隊成員必須要工作在共同的目標集合上,並做出適當的折中判斷。

可能的發布準則項:

1)缺陷

質量是一系列複雜和多維度的產品特點的集合。發布乙個不成熟且存在很多缺陷的產品會導致很高的執行成本、使用者的失望、很差的產品評價、過高的維護成本、產品退貨甚至法律糾紛。作為質量的指標之一,可以對開發和測試中發現的缺陷的數量和型別進行跟蹤。

在乙個四級的缺陷跟蹤系統中,不存在未解決的最嚴重的1級或2級缺陷。在過去的x週內,未解決的缺陷數量持續下降,同時估算的遺留缺陷數量是可以接受的(可以採用缺陷模型來進行**)

在編譯器中、原始碼分析與執行時分析中所報告的所有錯誤和警告都得到了修正。

前一發布版本出現的問題都已經得到了修正,在修復過程中也沒有引入額外的缺陷。

2)測試

大多數軟體團隊都非常依賴不同型別的測試來發現缺陷,可以通過檢視估算的未發現缺陷數量是否處在可接受範圍內,或者在預設的測試時間內並沒有發現新的缺陷時是否決定停止測試,一些主要的發布準則如下:

**編譯、構建和冒煙測試是否在所有平台上通過;

綜合測試和系統測試100%通過

特定的功能通過了所有的系統和使用者驗收測試(如正常流程和相關的異常處理流程在普遍的用例中測試通過)

測試計畫中涵蓋的所有記錄在案的功能需求的測試用例都得到了執行

達到了預先設定的**或需求(如功能需求、測試用例流程或者產品屬性)

完成了覆蓋100%功能點和80%的回歸測試

不存在嚴重等級1和等級2的缺陷;

已知的遺留缺陷密度少於每千行**0.5個缺陷;

每1000小時的測試工作發現新缺陷的數量少於40個 

發現缺陷的平均間隔時間少於100小時

完成了壓力測試、配置測試、安裝測試、本地化測試、可用性測試和傻瓜使用者測試。

3)質量屬性

在所有的平台上的定量效能目標得到滿足

可靠性目標得到滿足

相關公司的安全策略和需求得到了滿足

特定的條件已經符合,可以使得產品通過必要的評審或者審計

4) 功能

在即將發布的產品版本上,所有的承諾的高優先順序需求已經實現並能正常工作

滿足特定客戶的驗收的標準

滿足所有非健全人士的可訪問性需求

如果需要軟體在不同語言環境下執行,所有本地化與全球化測試都能通過

滿足特定法規、合約、標準規範和監管目標

所有的功能需求都可以通過測試用例進行追蹤

5) 配置管理

產品可以在所有目標平台上重複構建

物理配置審計確認現有的所有元件都是正確的版本 

產品在所有的目標平台上都能成功安裝

發布的介質和映象檔案經過了反病毒和惡意軟體掃瞄

6)支援

這裡主要指確保產品順利安裝和實施的其他關鍵要素。

發布說明已經準備完畢,包含新版本中的已修復的缺陷資訊、增加的功能和刪除的功能

受影響的專案干係人均了解軟體發布和支援流程

已知的未修復缺陷全部記錄在專案的缺陷跟蹤系統中

支援部門已經做好了接受和回應客戶問題報告的準備

執行軟體的執行環境所需的各種基礎裝置已經到位

軟體的生產和下發已經做好了接收產品的準備。

艾偉也談專案管理,架構組織管理

架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中,需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱,描...

艾偉也談專案管理,微型專案實踐感悟

微型專案是指絕大部分工作由乙個人員負責的專案,這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員,包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小,業務邏輯也比較...

艾偉也談專案管理,如何管理「人」

我們常說工作中應該 對事不對人 但事都是人做的,不同的人做相同的事效果可能相去甚遠,再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛,識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術,topk就是由 tiger owl peacock 與 ko...