(项目管理)软件项目经理必读手册

软件项目经理必读手册

version 0.2

本文档属内部培训文档，仅供参考，如果发现和公司实际流程有不符之处，请指出并修订。

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 2/12 版本 0.2

变更记录

NO 1 2

变更日期 2006-1-4 2006-1-11

变更理由

评审后修改

首次发行 增加history 增加第六条 P3-2-6

P4增加 * release note 中的产品阶段和公司定义相同。

增加 跨部门的项目要了解获取资料的途径。 P5，4.2 改动较大 P8，4.7 MA 阶段有改动 P9，5.1 FTA补充2点

P10，更正 HW 测试什么时候需要做？

补充TCK测试

变更内容

版本 0.1 0.2

修改 王伟 王伟

批准 赖旭芳

2

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 3/12 版本 0.2

1 概述

本文希望能帮助同事们更好的配合公司产品开发，调用一切可以调用的资源解决问题，保质保量的完成软件开发工作。

目标人群：

刚刚从事软件项目管理工作的同事

已经有项目管理经验，但对流程和目标并不大熟悉的同事 对软件项目管理有兴趣的同事

2 软件项目经理具备的条件

1， 有软件项目开发经验

2， 熟练使用公司常用的项目管理软件：clear quest, clear case, project 等 3， 熟悉公司产品的开发流程

4， 熟悉公司软件质量要求，各阶段质量目标 5， 良好的沟通技巧和邮件处理习惯

6， 熟悉开发环境和系统框架，具有敏锐的洞察力，能够及时发现项目中的问题，有效调配人力。

以上是对软件项目经理提出的基本技能要求，如果你还有哪方面不足，要注意改进了！

3 基本要求

3.1 了解产品的特点

1， 开发时间短，功能多

一般新项目都是4个月到5个月左右，对于新平台的项目可能预研的时间会长一些，有的项目也可以长达一年，对于继承性的项目有的甚至只有一两个月就要完成。

2， 模块或芯片复用也是我们公司产品的主要特点。

通常我们会将一个多媒体芯片用于不同平台上，或在不同的硬件组合基础上实现不同产品，以实现成本优势。

所以作为软件项目经理，一定要求严格遵守开发时间，合理制定计划，在项目初期将风险评估到位，同时也要关注一下临家项目，说不定你遇到的问题人家早已解决过了。

3

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 4/12 版本 0.2 3.2 了解产品开发流程

（此流程参考公司产品开发流程，如有变动，以公司定义为准）

阶段 定义 时间 主要任务与目标 1）需求评审、确定 2）可行性研究完成 DP Design Planning 4W 3）ID确定 4）签合同 5）风险对策确定 6）Schedule确定 DR Design Review 8W 1）设计完成 2）设计评审通过 1）整机通过所有测试评价标准（软件测试、外观检查外）；2）EP Engineer Proto 4W 部品问题全部解决；3）BOM确定；4）所有设计问题、部品问1）所有测试、评价项题全部得到验证；5）之后无设全部要做； 计变更 1）用设计确定的部品、方案进SP Semi Production 3W 行试生产，最终确认设计完成的1）只做单项验证、确有效性； 2）Qualify完成 1）小批量生产、销售；理顺生PP Production Pilot 2W 产线； 2）量产准备； 3）SA通过 MP MA Mass Production Maintainance 合格率 认的测试项；2）部品合格率、直通率 2）评价部品合格率 On schedule 设计验证（设计问题全部解决）: 测试，评价

* 目前软件follow公司的产品阶段定义，在填写release note时，可以写这几个阶段。

4 项目经理实战

下面就从产品开发的各个阶段向大家介绍软件项目经理应该注意的地方和完成的任务。

4.1 DP 阶段

1， 参加PM 或 AM 组织的公司级项目启动会议，了解项目内容及大致计划。

2， PD上需要软件评估键盘布局，和各种功能键是否合理，因为这个影响ID设计。

3， 严格检查AM草拟的PD, 签字时一定要小心再仔细，因为这份东东是要写进合同的，任何疏忽

造成的损失可不是一字千金就可以的哦！

4， 如果你是半道杀出来的软件项目经理，第一件事就是要仔细审核一下这份PD, 以免造成衔接不

4

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 5/12 版本 0.2 利。

5， 一定要确认PD的来源，是正式的市场部文书。跨部门的项目要了解获取资料的途径。

[案例1] 不同的客户，不同的分公司PD格式不大相同，有的AM给你确认的一份PD, 但和客户签订的却是另一份PD格式，最怕它们是不完全相同的内容。从道理上说，应该是PD确认后，方可开始项目开发，但由于开发时间短的特点也决定了我们可能在项目签署前就进行研发，对于AM来说，PD的签署可能要经过一段较长时间，有时和你再次确认PD的并不是同一个AM, 这也就难怪PD会有变化。当然随着公司流程的加强，这样的问题可能会被避免，但是SPM仍然需要小心确认PD的来源及内容。

6， 可行性分析报告是这个阶段重要的输出文档。

SPM要对PD草稿中软件部分的Feature List进行可行性分析，包括：确认哪些能做，哪些不能做，哪些做起来有风险；

SPM对AM已经同客户确认必须做，但做起来有风险有难度的Feature List，安排开发人员进行前期调研，尽量结束在DP阶段。 6, 此阶段需要入库文档 1）《PD》 – AM 2）《Schedule》—PM 3）《可行性分析报告》—SPM

4.2 DR 阶段

1， DR第一周开始，SPM确定项目组成员，任务、职责，召开软件项目启动会，为项目组成员介

绍项目并分配任务。

2， 此阶段首先输入 SDP，SW sub schedule，通常这些是需要在kick off meeting 上向大家公布的，

如果项目来不及，也请大家先制定出草稿，会议结束后再做细化，评审并提交。 3， 启动会议后，SCMP，SQAP，STP需要准备，并在本阶段完成。

4， 请筹划项目的资源需求，告知PM 各阶段需要的项目样机，充电器，一般对于开发用的数据线，

USB线，下载线，DEBUG 工具等需要提出，由软件部统一购买，如何填写购买申请单在日常事务中提出。

5， 和客户确认细化的功能需求, 完成《软件系统需求规格说明》，从软件角度对产品进行描述及说

明，并完成评审(有的项目需要客户参与)。

6， 通常项目正式启动后，ID部门的UI team 就开始和客户确认手机界面的显示风格了， 在发给

客户的备选方案之前，SPM应该确认软件是否能够实现。

7， SPM应该在此阶段完成menu tree 的评审，将主要内容发给ID 部门的UI team，开始主菜单的

设计。

8， 和ID部门确认的还有手机的按键丝印，如果带触摸屏，屏幕上的丝印及功能也是需要确认的。

按照新的流程，SPM在最初确认PD的时候最好就确认这一点。

[案例2] 曾经有多个项目因触摸屏丝印没有和软件部或客户确认，直接发给供应商开模，导致废料或生产延时；还有项目因为给软件部确认的丝印图和发给供应商的不一致出过问题，主要是 *，# ， 符号键等。当然如果软件设计有键值的特殊要求，一定要向项目经理提出，不要等到模都开回来了才事后诸葛。

9， 在SW sub schedule要求期限内，完成各模块UI spec 的评审，有的项目UI spec还需要和客户确

认。NEC的项目还有一些相关文档，各项目自定。通常会有MMI concept，Default value，Max value

5

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 6/12 版本 0.2 等。 10， 在SW sub schedule要求期限内，完成各模块的需求文档，设计文档和接口文档。通常这些

文档比较占用时间，SPM要小心制定，以免流于形式。各模块根据实际进度把握，有些文档可以到EP阶段完成，有些文档也可以参考其他项目，不用完成。

11， DR 阶段文档入库需求： 1）《软件项目启动通知》— SPM 2）SDP，SW sub schedule –- SPM 3）SCMP -- SCM 4）SQAP -- SQA 5）STP – Test leader 6）《软件系统需求规格说明》— SPM 7）《Menu tree》—SW UI team 8）UI spec – SW UI team

9）SRS/SDS/SIS （部分模块可以到下阶段入库）

7, 配合SQA 完成DR到EP阶段的Judgment。

8, 如果是继承性的项目，此时可能需要发布一版软件用于硬件跑P0板，要求：

1） 能烧进程序。

2） 能做射频和电池校准。 3） 主要串口通讯正常。

4） 手机屏幕可以不亮，声音可以不响。

4.3 EP 阶段

通常会有EP1/EP2/EP3等3个阶段， EP1 阶段主要是准备FTA版本，同时提交大量的PRT 实验； EP2阶段主要对上一阶段试验失败的问题重新验证。有的项目比较成熟，紧跟着就进入 PP阶段了，如果问题太多，由QA和SPM共同确认是否还需要EP3阶段， EP3/EP4阶段对软件来说意义不大，只是能争取一点时间而已。

1， P0板回来后，继续调试，准备发布P1版

根据硬件设计方案：软件与硬件的接口文档(GPIO(Key, Earphone), Flash, LCDC, Camera Control)（HW）；生产部门提供的: 生产及生产测试软件需求(CIT)，Driver组开发工程师在SDP要求时间内与硬件部门协商软硬件的接口及实现方案。 2， P1版本发布要求：

SPM 必须要求 Driver team 负责人员熟悉发布软件的每一个指标。 请参考：（待补充）

1） 完成所有CIT测试。

2） 完成所有和硬件有关的验证，保证P1版本硬件发布没有太大问题。 3） camera 至少要做到preview，capture。 3， 生产软件通常要按照PM的计划执行。

在此阶段，电流测试和TOP测试需要由Driver 负责人完成。

6

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 7/12 版本 0.2 4， P1版本手机回来后，可以发给各个模块负责人进行实战开发了，此时也要准备FTA版本了。 具体见后文。

5， 发布了FTA 版本后，软件可以逐步进入正轨，持续时间最长的就是分bug, 解bug 的阶段。 6， 此阶段可以进入系统测试。第一轮系统测试通常要3周到1个月时间。

7， 按道理下面文档都要在编码前完成，但时对我们目前现状，这样的要求高了点儿，不管怎么样，

我们要朝这个方向努力。无论如何，系统测试前，需要完成的主要文档有： SRS, SIS, SDS, UI spec，单元测试用例，集成测试用例。

8， 此阶段还有一些产品级的问题需要软件关心，如PRT 的实验中出现数据丢失，不开机，白屏，

花屏，待机电流大等。PM 会找你讨论相关问题，请按时参加会议。

以下通常是EP2 阶段

9， P2 样机回来后，很快会准备发布CTA版本。CTA版本要求完成所有功能，包括产品说明书。

具体见后文。 10， 此阶段和客户沟通会比较多，尤其是一些国内客户，因为他们拿到了样机，需求会像雨后

春笋般不断涌出。请注意，所有需求一定要经过市场部同意，并在Clear quest 中提交需求变更。小需求可以答应更改，但大的功能请一定要求AM填写需求变更申请。

11，

由于很多手机售后都反馈过，receiver，speaker，mic烧坏的情况，因此很多音频上的指标，送CTA之后需要格外关注。

1）内置铃声最大音量，需要到实验室测量，不仅要满足客户需求，同时也要硬件确认符合speaker 输出功率。

2）MP3，同上。由于和内置铃声在硬件上不是一条控制通路，所以需要单独确认。 3）耳机的最大音量：包括听mp3和内置铃声。

4）Reciever输出功率：硬件符合spec，同时QA认可，软件协助测试。 5）Mic 最大增益：确认软件的参数是否合适。

12， 此阶段和CTA阶段要求质量目标相同： Stage EP Level 1 0 Level 2 40 Level 3 150 Pre-test Fail Rate < 10% Values of release 200

4.4 SP阶段

1， 从EP阶段进入SP阶段，通常PM会召集大家开Judgment会议，QA决定是否可以进入SP阶

段。因此SP Judgment前一个星期，SPM需要对clear quest中所有bug进行一次review，尤其是Not bug的问题。

2， 此时，SQA也会检查各种文档是否已经归档，如没有归档，需立即补充。根据流程，SQA应该

提前一天发出软件评审结果。

3， 1，2级bug是这个阶段处理的重点，因为硬件和结构此时都较为稳定，所以这时要安排人力开

始专项测试。

4， SP版本软件发布要求： Stage Level 1 Level 2 Level 3 Pre-test Fail Rate Values of release 7

文件类型 指南文件 文件编号 软件项目经理必读手册 20 80 < 8% 页数 8/12 版本 0.2 SP 0 150 4.5 PP阶段

1， PP阶段也是非常重要的阶段，Judgment会议同SP阶段一样，SPM要给与充分的重视，一般在

2周前召开。

2， PP版本软件发布要求： Stage PP Level 1 0 Level 2 5 Level 3 30 Pre-test Fail Rate < 5% Values of release 100

4.6 MP阶段

1， 软件大规模试产，对于新平台，可能会出现一些生产上的问题，SPM此时还不能放松，必须时

刻关注跑线是否顺利。

2， 第一个MP版本发布后，如果客户没有特殊要求，不要发布新的版本。 3， 此时不可以有1，2级bug，谨慎处理。 4， MP版本软件发布要求： Stage MP Level 1 0 Level 2 0 Level 3 10 Pre-test Fail Rate < 3% Values of release 50

4.7 MA阶段

1， 及时解决客户反馈的售后问题，在1到2个月内，用户反馈的问题要高度重视，尤其是严重问

题，必须及时解决，避免将来生产量大了，造成售后返修率高。但是为保证量产版本稳定，小问题可以和客户协商不做更改。 2， 注意量产后版本发布不可过于频繁。

3， 配合售后参加各种会议，和客户沟通的任何内容都要告知售后的同事，包括发布版本。 4， 通常MP版本发布两周后准备项目总结文档，并召开项目总结会议。 5， MA版本软件发布要求： Stage MA Level 1 0 Level 2 0 Level 3 10 Pre-test Fail Rate < 3% Values of release 50

5 手机重点测试介绍

5.1 FTA测试

FTA 简介：

Full Type Approval，在Morlab实验室测试。FTA测试一般处于EP1阶段，一般P1版本手机跑回来就要准备了。 对软件的要求：

正常开关机

正常搜索、注册网络，开机找网注册时需关闭呼叫转移（有些项目为过FTA通常把进入Idle

8

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 9/12 版本 0.2 之前检查呼叫转移的过程去掉，主要是不要影响找网时间） 正常接听、挂断、拨出通话

正常设置呼叫转移，设置成功或者被拒绝

无条件、无应答、占线、无法接通时的呼叫能正常转移 正常设置呼叫等待为开或者关

通话过程中能正确显示呼入的电话，能正常接听并能保持或者挂断前一路通话 呼叫保持正常，并且能正常切换 能正常建立多方通话，并能选择挂断 能正常收发短信

通话过程中的各种操作正常，包括收发短信

短信溢出提示正常，送FTA的软件版本手机中保存短信条数应为2条（此条测试主要满足短信自动转存的测试） 可以正确选择信息存储位置 可以正常接收小区广播(如果支持) FTA 软件质量目标： Stage EP Level 1 0 Level 2 40 Level 3 150 Pre-test Fail Rate < 10% Values of release 200

FTA版本的要求比较特殊，对于继承性的项目，可能延用以前的测试用例，但对于新平台的项目一定要事先做好需求，最好用编译开关进行控制，保证随时都可以生成FTA版本。因为一旦测试中间发现有的问题无法通过，就可能需要重新发布版本，注意FTA测试人员会提醒你，版本号一定要一致。

不同平台，测试点可能会有差异，需对具体项目而定。 5.2 CTA测试

CTA 简介：

China Type Approval，一般由客户提交到信息产业部的实验室(TMC,TTL或者WLLC,Mtnet,SRRC四个实验室)，无委即SRRC,是信息产业部的一个实验室, 主要测试电性能和EMC方面，Mtnet主要测试网络兼容性。认证过程中出现问题可以更改,但是软件版本号必须一致。 测试周期为一个月。

手机上市之前必须拿到CTA认证，否则不容许写IMEI，没有IMEI就不能卖。很多客户希望PP版本的手机就可以上市销售，因此一般提交CTA至少在PP前一个月。

CTA对软件要求：

所有用户手册中涉及到的功能都要测试，界面要求与说明书一致。 网络兼容性达到要求 GPRS/WAP 功能正常

通常CTA 软件要通过一轮系统测试，因此所有功能的集成版本必须要在提交系统测试2周到1个月前完成。但由于各个平台的特性不同，具体需要和PM/Test leader 商量系统测试提交日期。 有些平台还需要在给CTA的软件写入不同的音频参数，以便测试时可以有漂亮的音频曲线。因此硬件要在送CTA之前一周拿到样机，软件必须事先准备好，并且不能再做修改。

9

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 10/12 版本 0.2 CTA 软件可以有部分功能没有完成，在测试过程中升级，但一定要事先告知客户或AM, PM, CTA 认证人员等。

CTA 软件质量目标： Stage EP Level 1 0 Level 2 40 Level 3 150 Pre-test Fail Rate < 10% Values of release 200

5.3 IOT测试

一般给中国移动做定制手机（CMCC）都要过此测试。有些大客户，如NEC，可能不做定制也要测试。CMCC测试一般准备10台手机，在北京的移动测试中心做为期2天的验证，主要测试基本功能和GPRS/WAP/JAVA等方面。测试中心有完整的测试表格，我们以前的项目都有。然后移动会将此手机发放全国主要城市做大约2周的交互测试，没有单独的测试表单，内容包括WAP/MMS/JAVA和用户体验。

具体的测试标准要移动发布的标准，目前最高是2.1版。

5.4 TCK 测试：

TCK测试是Java 需求的。如果你的项目有java应用，应该都需要此项认证。 只有过此测试才能拿到SUN的Logo，上市销售。

通常这个测试由java解决方案提供商来测，然后他们会把测试结果给SUN公司，获得logo。测试一般给2台，大约需要2-4周时间。如果加急，可多提供样机。 SPM制定计划时注意，logo一定要在上市前得到。

5.5 微软LOGO TEST

[不同平台，还有一些重要的测试项，大家可以边看边补充]

6 版本发布注意事项

1， 内部版本发布通常一周一次。

2， 外部版本发布以客户要求为主，如果没有要求，CTA之前偶尔发布测试版，CTA之后可以2-3

周发布一次。MA阶段，通常开始两个月，一个月一个版本，而后两个月准备一版，半年后，根据客户需求和问题的重要性自行安排。

3， 系统测试提交前，需要填写系统测试申请单，并提前一天发出。

4， 系统测试的版本需要有pre-test 报告，因此版本发布要留出pre-test 时间。

5， HW 测试什么时候需要做？ 一般外发的给客户或生产的版本都要做。内部版本由SPM自己控

制， 最好2-3个版本一次。

6， 给生产的版本一定要做 TOP 测试。MA阶段，如果客户只做用户升级可以不测。 7， 和硬件相关问题争取在版本发布前找硬件确认。

10

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 11/12 版本 0.2 8， 给客户的版本，一定要注明此版本解决的客户提出的问题，如果客户所提的关键问题没有解决，

可以和客户商量推迟发布，但一定要告知客户或AM. 9， 给客户的release note 一定要清楚，不可有理解不清的地方，避免客户事后询问。造成不利影响。 10， 版本发布尽量提前解决问题，避免特采。 11， 从MP版本起，每个版本都要找很多领导签字，此时要注意预留时间，避免到时找不到人。

7 说明书的问题

不管你有多么繁忙的任务，也一定要给说明书的审核留出时间，因为你是最了解这个项目的人。尤其是和手机硬件有关的内容一定要谨慎，如某个按键的功能，新增功能等。

8 问题/需求管理

1， bug 分配要及时，一般是当天分配，但如果任务较重，最晚推迟1天分配。 2， 只有SPM才可以将bug 置为not bug。

3， 对于复现率低的bug 要及时申请专项测试。

4， 提交需求变更时，客户资料一定要填写完整，同时请将客户的关键mail 作为附件载入。

9 样机管理

1， 样机借用台数视具体项目而定，争取每人一台。 2， 所有借入样机需要专人管理，避免丢失。 3， 每一阶段结束时，都需将无用手机入库。 4， 所有从软件部借出手机都要留借条。

5， 通常EP2阶段会有一批PRT试验后的机器可以调给软件使用，但千万不要调给测试组，以免出

现死机重启等现象，不易解释。

10 沟通技巧

1， 有些客户经常提出无理需求，通常采取的办法是：“让我们考虑一下，然后给你答复。” 然后苦思冥想一些理由，据之为上。

2， 有些客户一下提出很多需求，不全部做不大好，那么可以答应只做部分内容。

3， 对于模棱两可或实现起来很难的需求，一定要和客户确认清楚，要么做，要么让他彻底打消念

头，不要等到量产的时候再让客户想起来，就更难改了。

4， 通常和客户的所有email 都要保留，Maintain 阶段结束后可以备份。 5， 给客户的email 标题要简单易懂。

6， 发送前一定注意检查收件人和抄送人，避免错发邮件。一般应该把需要对方注意或需要回复的

人员列在收件人中，只需知会的人列在抄送列表中。 7， 不可泄漏给不同客户不同项目的内容。 8， 对待客户要向朋友一样，经常保持联系。

9， 给客户汇报的问题要有选择性的保留。尤其是clear quest 中的bug 不可全盘给出。<> 10， 在回复或转发邮件时，应该注意是否需要修改邮件的标题。如果邮件经过多次回复或转发

11

文件类型 指南文件 文件编号 软件项目经理必读手册 页数 12/12 版本 0.2 之后，邮件内容往往与最初的标题有出入，此时需要更改邮件标题，以方便收件人查阅，避免重要信息没有及时传达。

11 日常事务

1， 当天的bug 当天分。 2， 当天的信件当天处理。

3， 每周一上午准备weekly report，注意抄送 SQA、SCM、PM和AM。同时更新项目的软件Schedule，

与周报同时提交。

4， 每周参加项目review 会。 5， 每周发布release 计划。

6， 将第三方的联系方式贴在显见的地方，方便查询。 7， 遇有无法解决的难题，及时向高层经理汇报。

8， 由于目前同时会有许多项目并行开发，开发人员会承担多个项目的工作任务，SPM需要加强与

Team leader、开发工程师和其他SPM的沟通，及时协调解决人力资源的冲突问题，以避免项目进度的滞后。沟通的途径可以是项目周会、项目周报等。 9， 和客户开会要记得发meeting minutes，记录越详细越好。 10， 如何申请PR(purchase requisition) 在软件开发过程中, 如果需要购买某些工具, SPM要填写PR交给采购部进行采购, 如某项目使用的下载工具或下载线不同于其它项目时, PR单可以在DCC网页上找到. 1） 填写PR, 关于供应商的信息需要找生产的同事了解, 最好能让他们填好在发给我们, 这样可以避免出错, SPM只需填写REQUESTOR, DEPT, EMAIL TELEPHONE等项. 注意TOTAL VALUE(RMB)这项千万不要填(这个是采购填的) 2） 填写完成后, 找相关领导签字. 3）复印PR一份(采购部要求如此)

4）到商务部(M7-5)取得所需购买物品的报价单复印件(一般都是找商务部侯映楠) 5）将两份PR和报价单复印件一并交给集团采购部(M8-2)

6）如果时间要求比较急的话, 可以请NPS帮忙PUSH供应商尽快提供

12 学会自我调节和自我激励

SPM通常会带多个项目，大家要学会自我调节工作带来的压力，不要累坏身体。

补充：

DCC 网址：http://192.168.23.1

12