1. 项目管理的技巧：管理一般分为目标管理和手段管理，目标管理是利用组织内的文化优势来进行管理，而手段管理则是采用组织内的权利规范来进行管理；这里介绍的是手段管理
1) 经验的积累：从失败中、错误中学习，不仅仅是自己的失败和错误，也包括别人的失败和错误；分析其他人的失败和错误，需要获得比较充分的信息才能比较接近实际情况，才能分析彻底，而不至于一叶障目
a) 后期诊断分析（PPA，Post-Performance Analysis）：通常这种方法是在软件开发的后期，目的是为了找出问题发生的原因，并且讨论分析如何改进流程来防止这个问题再次发生
b) 前置问题列表（QP，Questionnaire Preparation）：先将所有的疑问和问题及时列出，为了找出这些问题的解决方法而制作的问卷进行调查，有些问题可以直接采用询问的方式；该方式很适合管理经验值不足的人员使用。至于如何准备这些问题列表，基本可以从管理事务的四大项目来着手：资源的调整、设置处理的优先级、监督事务、检讨审查
c) 管理事务的四大项目：
i. 资源调整：包括人力资源、软件资源、硬件资源、环境资源以及预算资源
ii. 设置处理事务的优先级：做错决定让人失望，但不作决定让人绝望；不要让手下跟着盲目努力
iii. 监督事务：进行监督无非是掌握流程进度，如果进度落后的话，就需要找出问题所在，并且可能再次进行资源上的调整；监督事务有两种方法，主动出击和自动反馈，大部分情况是两者并用
iv. 检讨审查：通过时候的检讨来分析问题，找出解决方法，是增加自我经验值得最好时机
2) 工作分割和单位化：一种方法是分化后逐一征服（Divide and Conquer）；不过这种一维的工作分割方式对于软件开发来说稍显不足，这时候就要采用WBS（）的工作风格方法来做规划。
a) 分割的模式：
i. Project（项目）：产品需求、产品设计、程序编写、软件测试，产品需求继续分为市场调查、市场分析、编写、审查等
ii. Product（产品）：自动扫描、线上更新、使用介绍、自动侦错
b) 分割的方法
i. 自顶向下的结构性方法：结构完整
ii. 自底向上的组合型方法：信息较多，需要整理
3) 分割工具
a) REDC：Review（审查）、Evaluation（评估）、Dsicussion（讨论）、Conclusion（总结）
i. Review：目的是对所要理清的议程项目做一个初步的审查，先锁定未来所要讨论的方向；Review的方式一般有3种，浏览性的审查（Walkthrough）、阅读性的审查（Reading）和设立审查机制（Inspection），这里所采用的是Reading和Workthrough这两种方式；建议将Review和会议分开处理，最好是会议前3-4天将所有要讨虏难得议题法E-mail给所有与会人员，
ii. Evaluation：先给出几种方案，然后对方案进行评估
iii. Discussion：讨论方案，给出结论；要注意讨论的方式和控制讨论现场的局面，不要偏离主题，不要讨论已经否定了的问题上
iv. Conclusion：最后一定要得出结论，不然就是一次无效会议，必须通过再一次的会议来讨论相同的问题
b) SWOT：策略分析法
i. Strengths（优势）：内部要项，常量；举例如下
1. 开发和测试人员的经验充足
2. 人员之间的工作默契良好
3. 人员士气并未受损
4. 修改部分只占整体的15%
5. 不需要额外配置测试环境
6. 所准备的软硬件不需变更
ii. Wesknesses（劣势）：内部要项，常量；举例如下
1. 人员并不熟悉新增的功能所需的开发技术及测试技术
2. 修改需要时间
3. 测试工具也需要修改
4. 相关文件也需要修改
5. 产品需要重新集成
6. 需要再次进行回归测试
7. 需要再次进行系统测试
iii. Opportunities（机会）：外部要项，变量；举例如下
1. 更改组件符合客户需求
2. 产品功能更加完整
3. 符合市场策略
4. 公司高层全力支持
iv. Threats（威胁）：外部要项，变量；举例如下
1. 经销商不满产品推出延误
2. 竞争对手先行抢先推出
3. 市场环境变动
4. 委外厂商无法配合
4) 建立检查单（Check List）：Product Release Check List
a) P1到P3的bug是否已经解决？
b) 是否准备好所有的程序列表（安装前和安装后）？
c) 所有程序的版本、时间、日期及其他属性是否正确？
d) 程序安装完后的初始化资料是否是最新的资料或设置？
e) 程序内部所有有关版本的信息是否已经更新？
f) 所建构的程序是否为Release版本而不是Debug版本？
g) 所有的测试资料是否已经从程序内部移除？
h) Help档案的内容是否已经更新？
i) 相关的文件是否已经准备完成？
j) Readme文件的内容是否已经更新？
k) GM（Golden Master）版本的程序是否经过防毒软件的扫毒测试？
l) 所制成的母片是否进行了安装测试及移除安装测试？
m) 是否在完全初始化的操作系统下进行过安装及移除安装测试？
2. QA人员的角色与责任：人员管理是项目管理中最难的一项
1) 组织结构介绍
a) 功能式组织结构：适用于规模较小的企业，管理层直接管理财务、信息、业务、管理、工程等职能部门，各职能部门各自管理
b) 矩阵式组织结构：适用于跨国企业、大型企业，可以应对横向沟通较多的问题；同一个人员接受多个部门或管理者的管理，比如测试人员或测试leader在项目组中要接受项目经理的管理，同时要接受测试manager的管理
c) 项目式组织管理：项目经理全权负责项目组内的人员、工作安排，甚至奖金发放；该种方式可能会导致资源利用不充分，各项目风格不统一等
d) 对软件公司而言，要采用何种组织结构出了要考虑管理人员的能力之外，还要考虑公司内部人员的数量、业务规模及资源分配等内容。除了慎重选择组织结构之外，让整体组织运作顺畅的要点取决于管理能力和规划能力
2) 软件开发人员的组织结构
a) 项目经理或产品经理：Project Manager或Product Manager
b) QA Lead：
c) Design Lead：
d) Requirement Lead：
e) … …
3) QA人员的组织结构
a) 以产品或项目划分：为产品或项目分配测试人员，由这部分测试人员完成所有测试；缺点是人员进入后的变动困难
b) 以专业项目划分：根据测试人员的专长来参与产品或项目的部分测试；缺点是容易遗漏测试内容，并且测试人员的责任心不强，没有归属感
c) 以产品划分的建议事项：以项目或产品方式划分时，要让测试人员轮替进入项目组，把产品知识能够分散到所有测试人员身上，避免人员流失引起的风险
d) 对于任何一种方式，都必须形成尽可能多的文档，文档要有实用性，见效人员流动带来的风险
4) QA人员的角色扮演
a) QA Engineer（QA测试人员）：好的QA测试人员必须由追根究底的精神，还需要有良好的沟通能力
i. 发现Bug
ii. 证明Bug
iii. QA人员的知识更宽，而开发人员的知识更深
b) QA Lead（QA组长或主任）：除了拥有QA Engineer的技能之外，还需要具备汇总与组织能力，对进度的掌控能力；处理事务的优先级上，也要有策略性的思考
i. 编写测试计划
ii. 统合软件测试用例
iii. 配置测试环境<
