软件项目经理必读手册

软件工程经理必读手册

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

变更记录

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测试

变更内容

版本

修改 王伟 王伟

批准 赖旭芳

1 概述

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

目标人群：

刚刚从事软件工程管理工作的同事

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

2 软件工程经理具备的条件

1， 有软件工程开发经验

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

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

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

以上是对软件工程经理提出的根本技能要求，如果你还有哪方面缺乏，要注意改良了！

3 根本要求

3.1 了解产品的特点

1， 开发时间短，功能多

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

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, 以免造成衔接不

利。

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 等。 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 负责人完成。

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 SP Level 1 0 Level 2 20 Level 3 80 Pre-test Fail Rate < 8% Values of release 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之前检查呼叫转移的过程去掉，主要是不要影响找网时间〕 正常接听、挂断、拨出通话

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

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

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

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

短信溢出提示正常，送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之前一周拿到样机，软件必须事先准备好，并且不能再做修改。 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， 和硬件相关问题争取在版本发布前找硬件确认。

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 日常事务

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