软件项目管理

• 需求和背景

• 交代软件需求，想清楚开发软件的目的，形成一些想法

• 项目投标：

• （1）什么是项目投标

• 企业或单位，以公开招标的形式，由于各个公司进行竞争，并最终获取项目资格。

• （2）为什么要招投标

• 公共单位30万以上的项目，必须采取招标形式。一定程度保障公平公正公开，减小贪污腐败。

• （3）招投标的流程

• 1、甲方（出钱方）

• 2、乙方（接项目，赚钱）

• 3、招标公司（负责招标事务）

• 标底：挂网的需求书

• 质疑：乙方认为甲方的标底存在不不清晰或者不公正的点，可以申报质疑函

• 项目存在质疑点，排他性

• 项目存在非合理性 出示，挖掘使用证明

• 项目质疑项目规则

• 备注：投标公司少于3家，5家 自动作废

• 招标流程图

• 控标

以各个合法方式增加自己中标概率

• 资质控标

• 1、人员资质

• 2、公司资质，高新技术企业

• 产品控标

• 1、性能控标

• 2、功能控标

• 案例控标

• 要求公司做过类似项目

• DAY4

1. 项目生存期模型

1. 生存期->项目生命周期，从开始到结束的一整个过程。

2. 订单生命周期：交易时创建 -> 付款 -> 验单 -> 交易 -> 收货

2. 管理软件项目的生命周期

1. 事项梳理，项目的设计，任务分配，进度跟踪，质量把控

2. 管事不管人，把控项目，让项目按照自己的预期顺利完成

3. “七彩乱麻”，理成线，织成布

3. 项目管理的方法

1. 瀑布模型

1. 最基础最传统的一种软件项目管理模式，主要是软件从需求到交付一套正向流程

2. 理想型的软件开发流程，优点是：高效迅速，缺点是：中途更改要推翻，只有软件体量小，复杂度低，需求不变的情况，才会使用该模式（开发环境，测试环境，生产环境）

3. 逆流瀑布

1. 一旦出了问题，先往上一个流程进行追随，解决后，流向下一个流程。例如测试不通过，返回给开发修改，修改完继续测试

2. 优点：出问题有可以回滚修改，快速迭代

3. 适用场景：一般需求清晰不变（定制开发：帮别人做软件，且合同中明确软件的需求）

4. 比较看重需求和设计，需求和设计未明确，是不动工的。

5. 软件反响不好，就得回炉重做

2. V字模型

1. 前半部分都是瀑布模型，后半部分是测试流程及对于的反馈

2. 比较注重调试和研发

3. 好处：质量把控高，但是周期长，要求步骤之前一定要严格，一般在开发大系统，以及第三方对接系统用的较多。（支付宝：鹭路行 -> 交通公司）

1. 项目经理：需求对接

4. 敏捷开发

1. 以小团队为主，以瀑布模型为依据，高速迭代，开发，反馈修改以后迅速变更。

2. 强调以人为本，让每个人都高速运转。（大部分都使用这一模式，当前最好的的一种管理模型）

3. 条件要求：

1. 小组自管，对管理要求很高

2. 对技术水平要求很高

3. 要求报酬奖励高

• 敏捷开发

• 将某个项目，分解为若干个小模块（精确到天），以高迭代，高反馈，快速开发测试的牧师进行项目管理，等所有开发完成，进行一次对接组合。（设计，开发，测试并线走）

• 优点：

• 人员利用率高，没有人员空闲期。

• 高速迭代，可以及时发现问题（不用等到最后，才发现问题）

• 发现问题容易更改，不用推翻

• 条件：

• 项目整体设计清晰，思路清晰，目标明确。（七龙珠：边写边拍，没有整体，故事线设计，导致剧情崩塌）

• 人员自管，要求员工素质高，积极性要高。

• 要求团队技术能力高，写代码活跃度高，已更改

• 项目激励高

• 缺点：

• 出错率及更改率都相关较高

• 人员比较辛苦，工作饱和度比较高

• 人员替换成本比较高

• 要求条件多

• 团队角色管理

• 产品线和项目线的管理模式。

• 百度公司产品线：

• 百度搜索

• 百度地图

• 百度贴吧

• 新增一个产品线，百度VR，先从其他产品线抽调人员，如果产品有收益就追投，没有解散，项目队伍中，有的角色任务比较轻，一般是多线调用。（游戏开发的音效师）

• 100以上的开发，一般在他的领域是头部企业。

• 普通软件项目的团队角色

• PO product owner 产品经纪人

• PM product manger 产品管理者，项目经纪

• UI user interface 用户交互设计（视觉和界面）

• Devlop 软件开发 （人数最多，程序员）

• Test 软件测试

• 产品运维 产品上线，产品维护

• 项目助理 协调，整理进度

• 项目设计实施方案

3. 版本管理的方式：版本号+版本备注

• 版本号：A.B.C

A：大变更（大调整，升级）

B：记录上线号和（对外公布版本记录）

C：内部版本维护（开发测试版本）

• 假设你开发一个软件：v1.0.0，交给测试，测试失败，v1.0.1，在次提交测试。假设在v1.0.8，测试通过，可以上线，下次开发就要从v1.1.X开始

4. 不是版本越高，软件越好，不同版本的软件事不同时期不同条件的产物。（怀旧服）

5. 如果上线出现问题，关闭维护，或版本回滚

• 需求和背景

1.1项目背景

1. 当前具备的条件

1. 设备条件

2. 网络条件

3. 人文条件

4. 系统条件

5. 政务软件：用一下文件要求要求和中央号召

6. 特定条件要说明：老年人义诊App，说明老年人智能手机普及率，以及操作情况

7. 假设需要对接系统，说明系统条件，比如做一个人才库：已具备和学籍系统，人社部的证书系统，官方比赛系统做对接的条件

2. 软件所面向的用户的基础情况（只写相关的情况）

1. 一般软件系统是针对某个用户群体，描述一下群体相关的和软件需求相关的特点（大学生外卖）

2. 软件是某个单位或某家公司定制的，描述一下公司相关的基础情况。

3. 简单的描述一下，用户的基础问题

4. 用户前期调研所反馈的结果

1. 农村养老App，对应调研的用户需求反馈

2. 收集用户数据，及统计结果

1.2项目需求

1. 需求分类

1. 按需求的等级：

1. 一般是马斯洛需求层次定义：

1. 生物需求

2. 情感需求

3. 自我实现需求

2. 按需求的必要性分类：

1. 刚需

1. 非要不可，没有不行

2. 非刚需

1. 要也可以，有则更好，没有也行

3. 伪需求

1. 看似有需求，实则没必要

3. 需求一定要特定角色而言（买房子：需要落户上学刚需，单身打工仔：非刚需）

2. 各需求的优劣点

1. 刚需

1. 一定有价值

2. 一定有用户

3. 刚需市场比较饱和，竞争激烈，溢价低

4. 政府监管严格，政府可能有定价

2. 非刚需

1. 有销售风险

2. 溢价相对会高

3. 利润空间更大（钻石，奢侈品）

4. 带来一定的用户提升

3. 伪需求

1. 一般是没有必要的

2. 忽悠客户骗钱的

4. 案例：VR产品

1. 非刚需，有可能是伪需求，3D呈现，新的视觉展现方式，普通的屏幕视觉可以替代他的效果

5. 需求获取

1. 需求获取->产品经理的职责

2. 用户是病人，产品经理是医生，病人只会告诉医生，哪里不舒服，具体病因要由医生自己诊断

1. 三流的产品经理：记录用户的问题，只能看到问题的表象

2. 一流的产品经理：能够挖掘用户更深层次的需求，给出对应的解决方法

3. 最好的产品经理：引导用户的需求，创造一个新需求（PC，智能手机）

3. 需求获取的途径

1. 客户面对面交流

1. 询问客户是否有哪方面的问题？

2. 在使用某某东西是否遇到了一些困难？

3. 对于某个产品是否愿意去使用？

2. 用户数据调研

1. 调查问卷收集

2. 粉丝群的问题反馈

3. App数据收集（滴滴：恶意收集用户信息）

4. 市场数据调研反馈

3. 用户竞品对比

1. 查看市场有类似需求的产品（竞品模仿）

4. 公司决策层讨论

1. 公司高层进行商讨

2. 一般决策者超前的战略眼光

6. 大众型软件：市场调研，市场分析

1. 细分用户软件：针对这个用户群体进行调研，组织部分用户交流（职业）

2. 定制软件：和甲方进行面对面沟通核对，并最终放在合同内。

7. 分析思路：将自己代入到不同的角色，体验角色的工作（使用）过程，设身处地地思考问题

1. 用户

1. 找不到客服的联系方式，或者拨打电话繁忙

2. 问题沟通不通畅，客服人员不清楚自己的描述的问题

3. 客服承诺解决问题，但后续无反馈

4. 客服进度不清晰，服务的对接不清楚

2. 客服

1. 客户反馈问题情绪不稳定，问题描述不清楚

2. 给予的解决方法客户不理解，不赞成，无对应的解决方式

3. 对接厂家人员比较繁琐，沟通不顺畅

4. 催促进度的电话多于询问的电话，导致没有过多地时间处理问题

5. 客户的问题下一跳整理和记录，用手写整理比较繁琐

3. 厂家

1. 客服反馈的问题和用户表达不一致

2. 客服反馈的问题重复，多次反馈一些本可以自行处理问题

3. 维修或者换新的问题，会遇到对接出错

4. 客服经常崔楚或询问维修进度

1.3、用户场景、用户故事

1. 假设自己是某个角色，对应XX情况，XX场景，发生（遇到）XX问题，并且使用了XX软件工作，解决该问题。

2. 需求等级

1. must（必须的）

2. should（应该的）

3. could（可以的）

4. want（扩展的、额外的）

3. 用户使用设备出现故障，想要联系客服解决，找不到客服联系方式，拨打总电话占线，用微信扫描冰箱上的二维码，进入小程序

4. 用户在售后小程序反馈问题，智能客服给出类似解决方法，客户回复参考方法解决对应的问题

5. 用户参考方法未解决，在小程序中，描述，拍照，并上报问题给人工客服解决

6. 客服回复了用户问题，并给出客户寄件地址，让客户进行寄送维修

7. 用户点击客服查询。查看到该设备，当前维修进度，以及对应的维修方式

8. 用户点击查看进度，已维修完成，根据小程序中的快递单号，查询到设备寄送的物流

1. 客服

1. 客服打开售后管理平台，查看今天能有N条用户反馈的问题，点击某个问题进行查看，并进行客户反馈

2. 客户反馈的问题，属于自身问题，风月无涯提供问题解决的方法

3. 客户反馈问题属于产品问题，客服将问题转送给厂家对接

4. 月末问题总结，从平台中下载问题统计表，编写问题统计报告

2. 厂家

1. 厂家受到了客服反馈的问题，对应给出解决的方法，并总结到问题库内

2. 厂家收到了客户的损坏设备，扫描标记为正在维修，编写问题反馈以及维修方式

3. 设备维修失败，根据用户地址寄送一台新设备，更换处理结果为换新，填写寄送的单号

4. 维修设备成功，根据用户地址，寄还设备，更换处理结果为维修完成，填写寄送单号

• 概要设计

• 软件设计的概要大纲，一般看完概要设计，清楚开发的思路

1. 角色及权限说明

分类	角色	共有权限	独有权限	补充及备注
研发部	软件开发工程师	接收任务 提交任务 申请加时 提交日志、周报	提交代码 BUG提交
	LB设计工程师		提交设计图
	软件测试工程师		上报BUG
	系统运维工程师		软件上线
经理部	项目经理	编辑和修改任务 指派任务 审批加时 日志查看，打分	创建项目组 人员分组
	产品经理		提交和更新文稿 审核设计图
	测试经理		提交测试用例 下载测试报告

角色	权限	补充及备注
用户	登录注册（小程序） 在线联系客服 填写、提交报修 查看保修进度 问题反馈投诉
客服	登录系统（售后管理系统） 回复客户消息 回复厂家消息 更新保修状态 查看用户保修	状态更新： 已受理 已解决 已指派
厂家	登录系统（维修管理系统） 回复客服消息 更新保修状态 填写快递单号 查看用户报修	状态更新： 报修中 已维修 已发货
管理员	注册客服账号 注册厂家账号 管理账号（客服和厂家账号）	管理模式 停用 启用 删除 更改密码

2. 角色关系用例

3. 软件架构

1. 模块架构图

2. 网络架构图

3. 软件层次图

4. 核心业务流程图

5. 核心结构时序图

---

• 详细设计

• 具体写某部分代码时候的参考和标准，类似一个字典，用来对照的

---

• 实施方案

• 软件的开发规划，一般反应的是任务和时间节点

• 自我管理规划

• 主要整理自己今天工作计划，理顺理清自己今天要做的事情

• 做一个便签，把今天的事情列起来，合理规划今天的时间点

• 下班前做好工作整理，做完打钩，没做完的标注延期没做完的原因，上报工作。

• 团队的任务规划管理

• 开展公司晨会，汇报当前的任务进度

• 项目进度的整理，Excel表格整理

• 汇总个人的进度，整理整个项目的项目进度

• 项目进度管理中国的问题

• 责任人因各种因素，导致未能在规定的时间内完成任务

• 有新的紧急任务插入，导致当前进度的中断

• 因需求变更，导致整体任务规划发生变更

• 多任务并线执行，会容易混乱，也有时间分配的不合理

• 甘特图的几个要素

• 任务

• 今天需要干什么？排列任务的时候需要注意任务的性质，任务是否有冲突

• 任务是否强关联（当前任务是否依赖前一个任务做完）

• 责任人

• 当前任务的负责人，原则上一个任务只有一个人负责，甘特图不写参与人

• 如果任务有多个负责人则需要细化任务

• 时间点

• 开始时间、结束时间、自动计算总耗时

• 一般来说时间是由责任人自己定，由项目经理进行调整，按照自己的能力多加1-2天

• 特殊情况由直系领导直接定时间

• 完成度

• 一般采用的百分比制，每天更新进度，项目经理，根据每天完成度，绘制整体进度