Project Resource Management

2021/09/28 (增加連結)

簡介

資訊系統專案中最重要的是人力資源，除了人力資源之外，設備、工具也是重要的資源。

在專案管理中人力資源的管理有些很重要的議題，例如，在人月神話中提到的，投入越多人不必然獲得越多成果。所以，提升人力的生產力是很重要的議題。

• 09-01 專案資源管理-PMBOK®6th (6:19)

• 09-02 建立資源管理計畫-PMBOK®6th (6:15)

• 09-03 預估時程活動資源-PMBOK®6th (5:55)

• 09-04 獲取專案資源-PMBOK®6th (10:03)

  • RACI矩陣:

    • Responsible:負責執行者 ** 一定要有

    • Accountable:負責任者 (可以批准是否接受工作結果的人) ** 一定要有

    • Consult:可提供建議的人

    • Inform:該被告知的人

• 09-05 發展專案團隊-PMBOK®6th (10:52)

• 09-06 管理專案團隊-PMBOK®6th (6:59)

  • 衝突管理策略

    • 撤退/迴避 (Withdraw/avoid)

    • 緩和/接納 (Smooth/accommodate)

    • 妥協/和解 (Compromise/reconcile)

    • 強迫/指示 (Force/direct)

    • 合作/問題解決 (Collaborate/problem solve)

• 09-07 監控專案資源-PMBOK®6th (6:20)

討論

• 資源規劃

  • 如何規劃所需要的硬體設備?

  • 在系統開發前如何規劃所需要的資源? 會遇到什麼問題?

• 人力資源的管理

  • 很多軟體公司會採用PG pool，這樣的人力安排方式會有甚麼問題?

  • 要注意跨專案關鍵人力搶奪的問題 (參考: 時程管理的關鍵鏈 )

  • 關於人月神話，除了投入越多人不必然獲得越多成果，還有其他問題嗎?

  • 開發者生產力飛輪

    • 開發工具的採用可以創造生產力，生產力可以帶來效益讓公司成長並雇用更多的開發人員

    • 更多的開發人員投入開發工具的開發，會產生更多的開發工具

    • 採用開源的軟體框架是不是有同樣的效果?

參考資料

• The Developer Productivity Manifesto — The Flywheel

  • Every company is becoming a software factory

  • Why we should care about developer productivity

  • Are ideas getting harder to find?

  • The developer productivity flywheel

    • New developer productivity tools make software developers more productive.

    • Higher developer productivity drives companies to hire more software engineers.

    • More developers working at higher productivity levels ship more software, a subset of which is itself developer productivity tooling.

    • Loop

• The Developer Productivity Manifesto — More (Developers) Isn’t Always More

  • The Mythical Man-Month

    • Ramp up time

    • Communication and coordination complexity

    • Indivisibility of work

  • Diseconomies of scale

  • We will never have enough software developers

  • More developers, lower productivity

  • Busy work doesn’t work

  • Hidden figures

• The Developer Productivity Manifesto Part 3 — Leaving Software on the Table

  • 42% (17.3 hours / 41.1 hours) of developer time is lost to drudgery

    • 13.5 hours per week on technical debt

    • 3.8 hours per week on fixing “bad code”

  • The average productivity rate: 68.4%

• Why it’s difficult to build teams in high growth organisations

• Tom DeMarco, Timothy Lister (2014), Peopleware: Productive Projects and Teams, 3rd Edition

• 黃佩君 (2014) PG Pool團隊結構之研究 輔仁大學資訊管理研究所碩士論文

  • Architecture Ownership Patterns For Team Topologies. Part 1: A Business Architecture Model

  • Architecture Ownership Patterns for Team Topologies. Part 2: Single Team Patterns

  • Architecture Ownership Patterns for Team Topologies. Part 3: Multi-Team Patterns

  • Your Team Structures Ain’t Working. Let’s Apply Team Topologies

    • Team Types

      • Stream-aligned teams

      • Platform teams

      • Complicated-subsystem teams

      • Enabling teams

    • Interaction Modes

      • Collaboration

      • X-as-a-service

      • Facilitating

• RAGE. A simple way for product managers to answer the question “Why does everything take so long?”

  • Rapid Acceleration towards Goals Equation (RAGE)

    • Tp (The total number of people) x Cp (the capability of individuals) x OPS (the overall productivity of the system) divided by D (distractions) and C (complexity :Both operational and technical)

• 10 Mistakes To Avoid as a Software Development Manager

  • The Project Is Not the Top Priority — People Are

  • Processes Should Not Be for Stats, but for Ease of Development

  • Don’t Make Developers Compete — Build Camaraderie

  • Don’t Be Stingy With Praise; Celebrate Small Wins

  • Avoid Working Overtime. Or Emailing At Night

  • “Developers’ Happiness” Is Not Just Nice To Have

  • Our Position Is Just a Position. Be Grateful for Any Treatment

  • Stay Technical. Be Relevant to the Developers

  • Don’t Forget To Invest in Yourself. It Does Good for You and The Company

  • Never Rule Out That Sometimes We Are The Problem

• Conway’s Law : Conway’s Law suggested that the software architecture eventually copies the communication structure.

• Remove Cross-Team Dependencies

PMBOK

• 專案資源管理 / Project Resource Management

  • Resource Management Overview

  • 專案人力資源管理 (第五版)

  • 專案資源規劃 (Plan Resource Management)

    • Outputs: Resource Management Plan、Team charter、Project document updates

    • Resource Management Plan

    • 規劃人力資源管理 (第五版)

  • 預估活動資源 (Estimate Activity Resources)

    • Outputs: Resource requirements、Basis of estimates、Resource breakdown structure、Project document updates

    • 估算活動資源

    • Resource Leveling: 會因為資源(如:人員)的限制，活動的先後順序或時程會必須調整 ，這個動作相當複雜，可以利用工具 (如:Gantter)來幫忙

      • What is Resource Levelling? Project Management in Under 5 (6:43)

  • 獲得資源 (Acquire Resources)

    • Outputs: Physical resource assignment、Project team assignment、Resource calendars、Change requests、Project management plan updates、Project document updates、Enterprise environmental factors updates、Organizational process asset updates

    • 獲得專案團隊 (第五版)

    • Other Influences on Project Management

      • Enterprise Environmental Factors

      • Organizational Process Assets

  • 建立團隊 (Develop Team)

    • Outputs: Team performance assessment、Change requests、Project management plan updates、Project document updates、Enterprise environmental factors updates、Organizational process asset updates

    • 專案人力資源管理

    • 發展專案團隊

    • Team Building

  • 管理團隊 (Manage Team)

    • Outputs: Change requests、Project management plan updates、Project document updates、Enterprise environmental factors updates、Organizational process asset updates

    • Powers of Project Manager

    • 管理專案團隊

    • Peopleware

      • Peopleware談到辦公室空間對工作效率的影響，這篇文章也有同樣的觀點: Why open office design makes you less productive

    • Top 12 Things That Destroy Developer Productivity

• • • • Interruptions & Meetings

      • Micro-management

      • Vagueness

      • Seagull Management

      • Credit Greediness

      • Environment — Noises, Motion, Workspace Design…

      • Scope Creepiness

      • Product Definition Process

      • Lack of Consideration to Technical Debt

      • Tool Multiplicity & Hardware

      • “How” Documentation

      • Impossibly Tight Deadlines

• • • Building Amazing Development Teams

      • Training

      • Motivation

      • Responsibilities

      • People

      • Implementing Change

      • Team Management

    • What Ashby’s law tells us about balance in product teams

      • The law of Requisite Variety and the Viable System Model

        • Insufficient variety

        • Excessive variety

  • 控制資源 (Control Resources)

    • Outputs: Work performance information、Change requests、Project management plan updates、Project document updates

    • Control Resources