Home | 简体中文 | 繁体中文 | 杂文 | 打赏(Donations) | ITEYE 博客 | OSChina 博客 | Facebook | Linkedin | 知乎专栏 | Search | About

Chapter 3. 软件项目管理篇

Table of Contents

3.1. 敏捷开发
3.2. 范围管理
3.2.1. 宏观管理
3.2.2. 你清楚你的工作职责吗?
3.2.2.1. 制度管理
3.2.2.2. 权力下放
3.2.2.3. 专业的人做专业的事
3.2.2.4. 总结
3.2.3. 怎样防止踢皮球
3.2.3.1. 进入正题
3.2.3.2. 踢皮球几大害处
3.2.3.3. 场景一
3.2.3.4. 场景二
3.2.3.5. 踢皮球的风气是怎样形成的?
3.2.3.5.1. 责任不明确
3.2.3.5.2. 缺乏沟通
3.2.3.5.3. 背黑锅
3.2.3.5.4. 员工问题
3.2.3.6. 怎样根治踢皮球
3.2.3.6.1. 调整组织架构
3.2.3.6.2. 禁止追查问题源头
3.2.3.6.3. 不懂技术的管理
3.2.3.6.4. 统一目标,价值观。
3.2.3.6.5. 防止问题扩大
3.2.4. 企业内部外包与悬赏
3.2.5. 企业膨胀的原因分析
3.2.5.1. 人才管理
3.2.5.1.1. 先从员工个人谈起
3.2.5.1.2. 技能管理
3.2.5.2. 再说说部门
3.2.5.2.1. 部门膨胀
3.2.5.3. 精细化管理带来的膨胀
3.3. 时间管理
3.3.1. 时间管理的误区
3.3.1.1. 优化组织架构,精简机构
3.3.1.2. 命令决策一元化
3.3.2. 项目管理中工时计算的问题
3.3.2.1. 背景
3.3.2.2. 面临的问题
3.3.2.3. 工时去了哪里?
3.3.2.3.1. 洗手间,茶水间,吸烟
3.3.2.3.2. 看邮件,写邮件
3.3.2.3.3. 沟通
3.3.2.3.4. 查资料
3.3.2.3.5. 无关的会议
3.3.2.3.6. 不必要的拖延行为
3.3.2.3.7. 私人时间
3.3.2.4. 怎样改善面临的问题
3.3.2.5. 怎样计算项目工时?
3.4. 沟通管理(Communication Management)
3.4.1. 表达方式
3.4.1.1. 拒绝反问句
3.4.1.2. 任务分配
3.4.1.3. 任务确认
3.4.2. 越级和跨部门沟通
3.4.3. 会议管理
3.4.3.1. 会议的时间成本
3.4.3.2. 三个臭皮匠,还是臭皮匠
3.4.3.3. 下一个饭局
3.4.3.4. 会议必须有结论
3.4.3.5. 会议记录
3.4.3.6. 会议地点
3.4.3.7. 与会人员
3.4.3.8. 怎样管理会议的时间呢?
3.4.4. 工作报告
3.4.5. 负面信息处理
3.5. 集成管理
3.5.1. 配置管理
3.5.2. 为什么持续集成难以普及
3.6. 质量管理
3.6.1. 无缺点管理
3.6.2. 压力测试中存在的问题
3.6.2.1. (What) 什么是压力测试
3.6.2.1.1. 压力测试存在那些问题
3.6.2.2. (Why) 为什么做压力测试
3.6.2.3. (Where) 在哪里做压力测试
3.6.2.4. (When) 什么时间做压力测试
3.6.2.5. (Who) 压力测试过程参与人员
3.6.2.6. (How) 如何做压力测试
3.6.3. 打破软件自动化测试的格局
3.6.3.1. 自动化测试的误区
3.6.3.2. 分层与部署带来的问题
3.6.3.3. 压力测试存在的问题
3.6.3.3.1. 压力测试环境
3.6.3.3.2. 测试顺序
3.6.3.3.3. 瓶颈分析
3.6.3.3.4. 指导开发
3.6.3.4. 持续集成形同虚设
3.6.3.5. 测试的终极目标
3.7. 风险管理
3.7.1. 开发,测试与运维的关系
3.7.2. 技术规范的误区
3.8. 成本管理
3.8.1. 警惕IT黑洞
3.8.1.1. 什么是IT黑洞
3.8.1.2. IT黑洞产生的原因分析
3.8.1.2.1. 人的因素
3.8.1.2.2. 来自组织架构的问题
3.9. 人力资源管理
3.10. 采购管理

这里讲述项目管理的基本知识与方法,软件项目管理与传统行业项目管理最大的区别可能是知识型人才的管理。所谓管理大可分为两类,一类是着重考察项目过程本身,一类是主要考察项目的参与者,前者着重于时间管理,后者倾向于绩效考核。

学习管理你千万不能陷入到管理学领域,很多管理者陷入一个误区,试图寻找一种管理工具(非软件,这里指的是管理方法),通过工具解决项目管理问题。

管理软件开发团队,你只需要20%的管理学知识,更多的是对技术的掌握。

3.1. 敏捷开发

项目管理:项目管理从管理角度出发,通常根据软件工程方法实施,通常是告诉领导我们在做什么,但常常无法安照计划进行。 敏捷开发:从开发角度出发,告诉领导我们今天做完了什么!

我认为项目管理模式的软件开发团队,不理利于创新,会降低员工的积极性,员工没有参与感,将员工视为工时,一个部件,一个资源,任凭项目经理的调度,使用。员工的想法无法得到重视,仅仅是执行命令。 这种模式会浪费每个人20%的时间用来维护时间表。

我更喜欢敏捷开发团队,我更喜欢全栈开发人员,让开发人员参与的软件开发周期的每个环节中,人力资源利用率高,让开发工作成为有趣的事,从被动接收任务分配,到主动参与其中。

软件工程当下已经显得落后。尤其是快速变化的互联网行业。