微軟秘笈 Microsoft Secrets


原書英文版 Microsoft Secrets,由 Michael A. Cusumano & Richard W. Selby 撰寫,中文版為微軟秘笈。我把有興趣的重點摘要整理,協助吸收書本資訊。

當我閱讀到不理解的中文翻譯時,會在 Google Books 上搜尋相關章節,找到對應的英文原文,也順便加註在心得。

尋找聰明人

  1. 向 IBM 學習人事管理辦法,包含雇用、訓練、福利、及個人晉升
  2. 培養中階經理人
  3. 培養專業,透過調職增廣閱歷與經驗

HR 是成熟公司的專長,是許多成長中企業可以學習的對象。

創意人員及科技技巧的管理

工作職掌

  1. 程式經理
    與開發人員並肩作戰,撰寫但不創造規格;取捨規格;歸納所有人的意見撰寫願景說明書 (Vision statement);規劃產品共用架構與勾勒 UI;準備開發計畫並追蹤進度。
  2. 開發人員
    與許多人有重疊;建立產品願景;設計、建立、與測試特色;分配資源,確保準時上線。
  3. 測試人員
    從六個角度測試產品:使用者、國際、硬體、軟體、規格、穩定性。

或許可以考慮在專案中加入願景說明書,融合使用者、管理者、與開發者的共識。

Mentorship

微軟期待有經驗的 mentor 協助新人,優點是自主學習,沒有限制;缺點是常打斷 mentor 工作,當無人可問就必須嘗試錯誤,提高公司風險。

但不是有經驗的人都可以帶人,教授與溝通是需要學習的技巧(請參考 Mentorship 的 New-hire programs)。這看起來比較像是猴子爬到自己身上,mentor 不斷被打斷工作耽誤進度,最終選擇逃避,讓新人自生自滅。

Bullis describes the mentoring process in the forms of phase models. Initially, the “mentee proves himself or herself worthy of the mentor’s time and energy". Then cultivation occurs which includes the actual “coaching…a strong interpersonal bond between mentor and mentee develops". Next, under the phase of separation “the mentee experiences more autonomy". Ultimately, there is more of equality in the relationship, termed by Bullis as Redefinition.

定義產品及開發過程

產品開發方法論

  1. 綜觀整穩式開發程序 (Synch and Stabilize Development Approach)
    以列點方式說明,分為規劃、開發、與穩定三階段。
  2. 程式管理、開發、測試之整穩式週期
    以垂直時間軸方式說明。
  3. 產品管理、使用者教育之產品週期模式
    從組織角色的觀點,以表格方式說明。

這是很棒的三張圖,善用不同方式說明重點。其中我最關心規劃階段的產物:願景說明書 (Vision statement)、規格書 (Specification Document,請參考 Specification)、排程與成立特性團隊 (Feature Team,請參考 Feature-driven development,也就是 Cross Functional Team)。更完整且繼續演化的方法論可以參考 Microsoft Solutions Framework

A vision statement is a declaration of an organization’s objectives, ideally based on economic foresight, intended to guide its internal decision-making.[1] A vision statement is not limited to business organizations and may also be used by non-profit or governmental entities.

The word specification is defined as “to state explicitly or in detail" or “to be specific"

A feature team is a small, dynamically formed team that develops a small activity. By doing so, multiple minds are always applied to each design decision and also multiple design options are always evaluated before one is chosen.

彈性工作

針對軟體開發人員,利用高層次的願景說明書 (Vision Statement) 與大綱式的規格書 (Specification Document),打造嚴謹又有彈性的工作環境。

高層次文件

  1. 願景說明書 (Vision statement)
    由 Product Planner 與 Program Manager 撰寫,定義產品目標,避免包含詳細規格。因為功能通常在資源有限的情況下無法一步到位,願景書可以協助行銷與開發達成共識,決定當下增減的功能。
  2. 規格書 (Specification Document)
    由 Program Manager 撰寫,解釋產品功能特色,但不宜定死;完整到可以估算作業時間,不需要因為有了更詳細的規格再重新估算一次。因為需要反覆修改,會搭配版本管理,比較版本之間的差異性。

願景說明書 (Vision statement) 與 BRD (Business Requirement Document,請參考 Business requirements), IRD (Integration Requirement Document,請參考 Integration Document) 不同,前者涵蓋整個產品的多個階段,後兩者專注在當前,而且比規格書更為詳盡,包含完整的作業流程。

Business requirements must be delivered to provide value. Products, systems, software, and processes are the ways how to deliver, satisfy, or meet the business requirements wants. Consequently, the topic of business requirements often arises in the context of developing or procuring software or other system; but business requirements exist much more broadly. That is, ‘business’ can be at work or personal, for profit or non-profit.

The integration document defines the activities necessary to integrate the software units and software components into the software item. The integration document contains an overview of tile system, a brief description of the major tasks involved in the integration, the overall resources needed to support the integration effort. The plan is developed during the Development Phase and is updated during the Integration and Test Phase; the final version is provided in the Implementation Phase.

以使用者為中心

透過使用者訪談問卷報告與敏感度分析 (sensitivity analysis) 蒐集顧客活動資料,更加瞭解客戶,才能開發出對的產品。

其實這就是 2013 年開始受到重視的使用者經驗 (請參考 User experience) 的雛型,也使用 QBQ (Questions-behind-questions) 的探索技巧。

User experience (UX) refers to a person’s emotions and attitudes about using a particular product, system or service. It includes the practical, experiential, affective, meaningful and valuable aspects of human–computer interaction and product ownership. Additionally, it includes a person’s perceptions of system aspects such as utility, ease of use and efficiency.

時程推估

開發人員自己估計工作時間,再由 Program Manager 彙整,並加上緩衝區,最終得到一個整體專案開發時間表。

最重要在於開發者心理學:他們才會接受並且努力達成目標。

業務預測 (Sales Forecast) 相同,由下而上。但是在業務預測中,有利用銷售漏斗 (Sales Funnel)轉換率 (Conversion Rate)BANT銷售階段 (Sales Stage)贏率 (Win Rate)Expected ValueConfidence IntervalProbability 等量化技巧與統計學,產品開發就沒有對應的學理基礎,還在持續演化中。

每日程式目標程序的 11 個步驟

非常完整的詳述開發人員的每日例行工作,或許可以用來推估專案進度,如果有搭配自動化測試、持續整合(請參考Continuous Integration)、持續交付(請參考 Continuous delivery),可以與專案管理資料庫整合,自動更新進度。

In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software faster and more frequently.

成本的關鍵數字

關鍵數字:要做「不同的」,先證明有原來的 2 倍好;重寫程式行的「20% 稅」

這是微軟的關鍵數字,兩者差別在於前者是新功能獲得效益比率要為原先的 200%;後者是專案時間保留 20% 重寫程式碼改善效率與/或品質。就像活動出席人數是報名人數的 50% 的經驗數字,經驗越多越能掌握整體狀況。

建立有學習力的組織

四項原則

微軟的四個原則:

  1. 有系統地從過去和現在的專案、產品中學習。
  2. 用測度 (benchmark) 和數據資料為標準,鼓勵回饋和改進。
  3. 視顧客志願服務為產品的一部分,將結果列為改進的參考資料。
  4. 在所有產品群中,創造連結與合作。

原則很簡單,點火 (ignite) 很困難,就像我在「利用五項修練導入 CRM 的經驗分享」的挫折。建議要有專職人員來推動,就像現在在大型科技公司的 Evangelist 一樣,主動創造許多星星之火,待火之燎於原。

Reference

  1. Amazon: Microsoft Secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets and Manages People
  2. BANT
  3. Campaign 活動
  4. Conversion Rate 轉換率
  5. Google Books: Microsoft Secret
  6. Maryland State Government Department of Information Technology: Integration Document
  7. Sales Forecast 業務預測
  8. Sales Funnel 銷售漏斗
  9. Sales Stage 銷售階段
  10. Win Rate 贏率
  11. Wiki: Business requirements
  12. Wiki: Confidence interval
  13. Wiki: Continuous delivery
  14. Wiki: Continuous integration
  15. Wiki: Expected value
  16. Wiki: Feature-driven development
  17. Wiki: Mentorship
  18. Wiki: Microsoft Solutions Framework
  19. Wiki: Probability
  20. Wiki: Specification (technical standard)
  21. Wiki: User experience
  22. Wiki: Vision statement
  23. 金石堂網路書店:微軟秘笈:七大理想工作模式導讀
  24. 利用五項修練導入 CRM 的經驗分享
廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s