Home | 简体中文 | 繁体中文 | 杂文 | Github | 知乎专栏 | Facebook | Linkedin | Youtube | 打赏(Donations) | About
知乎专栏

部分 II. 软件项目管理

目录

6. 范围管理
6.1. 宏观管理
6.2. 你清楚你的工作职责吗?
6.2.1. 制度管理
6.2.2. 权力下放
6.2.3. 专业的人做专业的事
6.2.4. 总结
6.3. 怎样防止踢皮球
6.3.1. 进入正题
6.3.2. 踢皮球几大害处
6.3.3. 场景一
6.3.4. 场景二
6.3.5. 踢皮球的风气是怎样形成的?
6.3.6. 怎样根治踢皮球
6.4. 内部外包与悬赏
6.4.1. 怎么样操作
6.4.2. 可能遇到的问题
6.4.3. 小结
6.5. 团队膨胀的原因分析
6.5.1. 人才管理
6.5.2. 再说说部门
6.5.3. 精细化管理带来的膨胀
7. 时间管理
7.1. 优先级管理
7.2. 时间管理的误区
7.2.1. 优化组织架构,精简机构
7.2.2. 命令决策一元化
7.2.3. 时间线
7.3. 时间管理的最高境界
7.4. 项目管理中工时计算的问题
7.4.1. 背景
7.4.2. 面临的问题
7.4.3. 工时去了哪里?
7.4.4. 怎样改善面临的问题
7.4.5. 怎样计算项目工时?
7.5. 项目延期
7.6. 当日事当日毕
7.6.1. 工作时间如何规划?
7.6.2. 遇到工作被打断的情况
7.7. 任务分配
8. 沟通管理(Communication Management)
8.1. 表达方式
8.1.1. 如何提问
8.1.2. 拒绝反问和质问
8.1.3. 蓝领与白领
8.1.4. 向下沟通
8.1.5. 宽以律己,严以待人
8.1.6. 任务分配
8.1.7. 任务确认
8.2. 会议管理
8.2.1. 什么要开会?
8.2.2. 会议的时间成本
8.2.3. 集思广益纯属扯淡
8.2.4. 会议冲突
8.2.5. 避免议而不决
8.2.6. 会议记录
8.2.7. 会议地点
8.2.8. 与会人员
8.2.9. 怎样管理会议的时间呢?
8.2.10. 晨会
8.3. 工作报告
8.3.1. 日报、周报、项目进度汇报
8.3.2. 为什么会出现频繁汇报?
8.3.3. 如何才能抛弃汇报制度?
8.3.4. 上级给下级写工作报告
8.4. 越级和跨部门沟通
8.5. 投诉处理
8.6. 负面信息处理
8.7. 通知管理
9. 变更管理(Change Management)
9.1. 什么是变更管理
9.2. 需求变更
9.2.1. 为什么会变更
9.3. 拥抱变更
10. 集成管理
10.1. 配置管理
10.2. 为什么持续集成难以普及
11. 质量管理
11.1. 无缺点管理
11.2. 自动化测试如何破局?
11.2.1. 认知问题
11.2.2. 生态的问题
11.2.3. 技术的问题
11.2.4. 能力问题
11.2.5. 氛围问题
11.2.6. 最后
11.3. 为什么自动化测试难以推广
11.3.1. 为什么自动化测试难以实施
11.3.2. 是什么阻碍了自动化测试?
11.3.3. 中国测试人员的人力成本
11.4. BUG率的误区
11.4.1. BUG 叠加
11.4.2. BUG 分类
11.5. 敏捷开发为什么会以失败告终?
11.5.1. 首先,思考为什么最近15年软件质量体系没有新概念出来?
11.5.2. 然后,我们再来盘点一下最近几年西方软件领域主导者都在做什么?
11.5.3. 失败原因
12. 风险管理
12.1. 项目管理绕不开问题
12.1.1. 开发,测试与运维的关系
12.1.2. 压力问题
12.1.3. 重速度轻安全
12.1.4. 技术实力
12.1.5. 测试问题
12.1.6. 运维问题
12.2. 程序猿说的「优化」是什么意思?
12.2.1. 经验和能力不足
12.2.2. 给前人擦屁股
12.2.3. 先盖楼,后打地基
12.2.4. 使用新技术和不熟悉的技术
12.2.5. 最后总结
12.3. 制度、流程和规范的误区
12.3.1. 为什么公司总是强调流程,而员工总是反感?
12.3.2. 为什么我们的流程总是做不好?
12.3.3. 搞不清流程的服务对象
12.3.4. 依赖增加人为审批来控制风险
12.3.5. 没有一劳永逸一成不变的流程
12.3.6. 故事一
12.3.7. 故事二
12.3.8. 故事三
12.3.9. 故事四
12.3.10. 故事五
12.3.11. 总结
12.3.12. 案例分析:怎样避免电梯伤人事件再发生
12.4. 因果图在运维工作中的应用
12.4.1. 故障树分析(Fault Tree Analysis,FTA)
12.4.2. 什么是因果图
12.4.3. 为什么使用因果图
12.4.4. 何时使用因果图
12.4.5. 何处使用因果图
12.4.6. 谁来负责制作因果图
12.4.7. 怎样使用因果图
12.5. 监控的艺术
12.5.1. 背景
12.5.2. 概述
12.5.3. 怎样监控
12.5.4. 总结
12.6. Incident Management(突发事件管理)
12.6.1. 突发事件处理流程
12.6.2. 事件处理方式
12.6.3. 监控与警告分级
12.6.4. 事故分级
12.6.5. 故障处理手册
12.7. 升级风险
12.7.1. 求稳心态不可取
12.7.2. 怎样才能保持持续升级
12.8. 需求评审和代码审查
12.8.1. 什么需求需要评审或审查?
12.8.2. 怎样做 Code review?
12.8.3. 怎样避免 Code review?
13. 成本管理
13.1. 警惕IT黑洞
13.1.1. 什么是IT黑洞
13.1.2. IT黑洞产生的原因分析
14. 人力资源管理
14.1. 怎样提高团队成员的利用率?
14.2. 技术面试
14.2.1. 面试流程
14.2.2. 如何判断技术应聘者的段位?
14.2.3. 初级-中级-高级工程师之间的差距是什么?
14.2.4. 面试考察的是什么?
14.2.5. 不同年龄段员工的诉求
14.3. 技术岗怎样做工作交接
14.3.1. 工作交接过程
14.3.2. 确认入口
14.3.3. 网络设备
14.3.4. 服务器系统检查
14.3.5. 容器的检查
14.3.6. 云安全检查
14.3.7. 系统备份
14.3.8. 绘制网络和服务器/容器拓扑图
14.3.9. 部署运作机制
14.3.10. 接手代码
14.4. 岗位描述怎么写?
14.4.1. 产品经理
14.4.2. 高级运维
14.4.3. 服务器与硬件设备
14.4.4. 高级 Java 软件工程师
14.4.5. Flutter App 开发工程师
14.4.6. 测试工程师
14.5. 运维工程师面试题
14.5.1. Junior
14.5.2. 高级运维工程师
14.5.3. 安全
14.5.4. 监控体系
14.5.5. 云计算
14.5.6. 容器运维
14.5.7. 数据库
14.6. 软件工程师面试题
14.6.1. Junior Software Engineer
14.6.2. Senior Software Engineer
14.7. 架构师面试题
14.8. 数据库管理员
14.9. 测试工程师
15. 采购管理

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

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

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

1. 敏捷开发

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

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

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

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