图书
电子书
课程
VIP会员
书课包

软件项目角色指南

作者: 刘恒辉
译者:
编辑: 陈聪聪
分类: IT人文

图书目录:

详情

None

图书摘要

版权信息

书名：软件项目角色指南

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

软件项目是软件开发中的基础。一切软件的开发，一般都是以项目的形式开始。在软件项目中，项目经理是项目组了解软件开发过程中需要碰到的软件开发项目角色。本书就是以软件项目开发为基础，带领大家认识软件开发项目过程中所遇到的项目角色，以期能让大家对软件开发过程中的项目角色有一个清晰的了解，让项目经理、项目组在进行软件开发过程中，能够更好地为软件项目角色服务，更好地把软件项目做好。本书从最基本的软件工程师入手，通过项目甲方、乙方的关系，对软件项目过程中的各个项目角色进行了充分的描述，以期能给读者带来清晰的认识。

本书既可以作为大专院校相关专业的教材，也可以作为软件项目开发人员的技术参考手册，适合软件项目开发中使用的各个层次、水平的读者。无论你是初学者，还是软件项目高级开发人员，本书都将是你们的指南针。


本书作者授权人民邮电出版社独家出版。未经出版者的预先书面许可，不得以任何方式复制或抄袭本书之部分或全部内容。

版权所有，侵权必究。


对于软件项目角色，在我的博客上已经写了一些内容，但是没有此书那么详细。一直以来，从软件工程角度出发，我就想对项目团队中的各个角色，编写各自相关的指南文章，一来总结各个角色的职责和对该角色的要求，二来为创业做前期准备。这些角色相信大家在项目中会有涉及。由于与项目的大小有关，或者角色的划分，没有那么详细。在一些小项目中，往往是一人身兼多职，但是，他自己却没有想那么多，就是为了项目而在承担项目角色。这些项目角色，我部分经历过，是根据学习和经验记录下来的。

软件项目角色，在实际的软件开发项目过程中是会遇到的，但是没有我书中描述得那么全。这次将这些角色记录下来，就是为了将软件开发过程中遇到的各个角色在项目中所处的位置描述出来，以期能够让大家更好地了解各个角色所具备的知识和经验内容，以及各个角色在软件开发过程中所能够处理的内容。在我的博客上已经有部分内容被记录下来了，但是只是部分内容，没有书中描述得那么全那么详细。

当然，这些角色所具备的知识和内容，是我的经验总结。我把以前在学习过程中领悟的知识和经验再次沉淀下来，经过了几次内容迭代修改，这就是本书的由来吧。

希望能对大家的实际应用有所帮助。本书不敢滥竽充数，然则本人水平有限，欢迎大家批评指正，共同提高，争取做优质的指南针。

刘恒辉


到2010年为止，国内的信息化水平已经有了质的飞跃。IT项目的投资、建设无处不在，已经渗透到我们生活的方方面面。这归功于计算机硬件和软件的发展，信息化的影响力对于我们是深远、直接并且重要的。

有个重要的转变值得指出，经历了IT业的泡沫之后，我们的用户已经由懵懂转变成具有自主经验的用户了，由IT厂商说什么是什么的年代已经过去。IT项目的发展情况就是这样，从早期的门户网站，到今天个性化的个人博客站点，可见一斑。

从瀑布模型到迭代模型，从面向过程到面向服务，从传统项目管理到敏捷过程管理，软件工程的发展进步等，这些都是我们这一代项目干系人所经历的事情，也是我们不断探索、发现与实践的过程。在这个过程中，对于项目干系人角色的产生，也经历了由少到多的历史。各个角色的职责以及所处理的事情，都随着信息化项目的发展而在改变。在这条道路上，理论和实践是相结合的。理论指导实践，实践反过来影响和修订理论。这个与一些信息化项目，比如ERP需求的发展是一致的，都在随着信息化建设的发展而在不断地完善自己，不断地调整自己的角色，不断地绘制自己的舞台。

项目人员角色的完善，同样是软件工程趋于成熟的标志。软件工程界已经提出了一系列的理论、方法、语言和工具，解决了软件开发过程中的若干问题。但是，由于软件固有的复杂性、易变性和不可见性，软件开发周期长、代价高和质量低的问题依然存在。为了使软件项目能够按照预定的成本、进度、质量顺利完成，软件管理方法对成本、人员、进度、质量、风险、文档等进行分析管理和控制。进行软件项目管理有利于将开发人员的个人开发能力转化成企业 的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，其开发风险也越小。软件项目管理已经是公认的软件开发企业的核心竞争力之一。

为了提高项目建设、管理水平，笔者认为有必要对项目人员角色进行一个详细的描述，以帮助那些还处于懵懂阶段的初学者，以及那些需要提升项目建设过程经验的工程师。本系列的文章就是为了这个目的而编写的。由于笔者水平有限，文中出现的问题自然难免，欢迎大家批评指教。


这是笔者的第一本关于软件开发的图书。出书需要一种快乐的心情，基于这种心情，就能够创造出更多有经验的知识。

本书的目的，就是为了让更多的读者在软件开发过程中进一步了解软件开发过程中的相关角色，让大家在软件开发过程中能够对整个开发过程了解的基础上，对软件的各个角色也能够有一个更深刻的认识。

本书算是软件工程里的一部分内容，与软件工程中的内容并不冲突，算是软件工程中的互补内容吧。这次能够出本书，算是笔者在软件工程领域的一点经验和知识。

人在20岁以意志力著称，在30岁以智慧取胜，在40岁则靠的是理智的判断。

一个人只有时刻保持幸福快乐的感觉，才会更加热爱生命，热爱生活。只有快乐、愉快的心情，才是创造力和人生动力的源泉；只有不断自己创造快乐，与自己快乐相处的人，才能远离痛苦与烦恼。

基于上述的人生观，写书的时候我是乐观的，同样，我也希望本书的读者在阅读本书的时候也同样快乐、乐观。

本书适合于广大的软件开发人员，从初学者到高级软件开发工程师职务人员。

如果你想从零开始学习软件开发，或者你想回顾软件开发过程中所遇到的各个角色，或者你想提高你的软件开发过程水平，或者你想从更高层次上深入认识软件开发过程，本书都是你们的指南针。无论是新手还是老手，我相信本书的内容将能帮助你快速地认识软件开发过程并应用到实际工作中去。

本书的范围覆盖了软件开发过程中软件工程的尽可能多的方面，以期让更多的读者能够受益。

本书对软件开发角色的学习规划了相对完整的内容路线，该组织方式将有助于你以快速、高效的方式学习认识其语言的知识。这个路线图完全类似于从初级程序员，到中级程序员，再到软件设计师，直至软件开发过程中所遇到的所有角色的学习路线布置的，这将更有利于各个层次、水平的读者，通过不同的定位，选择性地阅读本书的相关内容，更好地服务于合适的读者。

本书提供了作者的邮箱：lzhdim@163.com和博客：lzhdim.cnblogs.com。读者在阅读本书的过程中发现的问题，或者有什么好的意见和建议都可以发送邮件到该地址与作者进行交流。

我非常喜欢指南针。在感慨大自然的伟大秘密的同时，对于事物的探究就有了按照前人的经验学习研究的过程。有了指南针，在积极探索新事物的同时，人们就能够事半功倍，就能更好地理解和掌握新事物。指南针给我们指明了前进的方向，在需要的时候，可以轻松地使用，能够学到感兴趣的知识；需要在实际行动中进行指导的时候，能够使用本指南进行分析。


第1章　客户负责人

第2章　系统用户


客户负责人在项目组中的角色是非常重要的，因为项目的需求功能都是由客户负责人与项目经理共同进行描述的，他的存在让项目的需求功能书能够写得更加的详细，让产品经理能够根据需求功能书进行原型等设计。同时，客户负责人在项目开展过程中需要与项目经理进行详细沟通，让项目的开发内容根据需求进行，在项目开发过程中对产生的用户界面、功，以及在项目过程中的用户体验等内容进行确认。另外，客户负责人还需要负责项目后期的项目验收等阶段，与项目经理配合对项目的验收等内容进行处理。

客户负责人的工作职责比较简单，主要是和系统用户进行沟通以获取需求，然后与项目经理进行沟通编写需求功能书，以及后期的系统试运行及验收等工作，客户负责人的工作是围绕着这几方面进行的。

客户负责人因为要对系统项目负责，所以需要对需求等有一定的认识了解，这样才能在与系统用户沟通时及时理解需求，在与项目经理沟通时解释所需要的系统功能。同时，客户负责人理论上也应该是业务负责人，起码得是软件系统项目的需求描述人，是软件系统项目业务的圈内人，这样才能更清楚软件开发系统所需要具备的需求内容并及时将需求传达给项目建设方项目经理。

因为客户方负责人是软件系统需求方的业务代表，所以其日常工作相对比较单一。客户方负责人应该在系统用户及系统建设方两边进行沟通协调，让软件系统的开发能够及时按时完成。客户方负责人的日常工作大致如下：

因为客户负责人工作比较单一，所以除了在日常工作中所需要具备的那些知识之外，其与项目经理一样，都需要对这个行业定制开发的软件系统的需求等具备及获取更多的项目经验。

客户负责人需要在平时的工作过程中不断地积累项目经验，同时也需要总结自己工作中所遇到的问题及解决方法，及时地发现问题、分析问题、解决问题和总结问题。这样才能够在工作过程中更好地将自己的经验落实到实际的项目建设中来，更好地将自己的经验服务于所建设的软件项目。

客户负责人作为系统建设的需求方负责人，需要在实际工作过程中与项目组成员等进行沟通，及时解决系统建设过程中产生的需求问题，以及解决系统建设过程中的用户体验及功能确认等问题。

客户负责人因为实际工作需要，不断地在工作过程中提出新需求及改进老需求流程，所以客户负责人需要不断学习新的知识，将自己的经验放到系统建设上面来，更好地实现需求方所需要的业务功能。


系统用户这个角色在项目管理过程中也是重要的一员。在实际的项目管理过程中，项目经理除了与客户负责人进行沟通之外，还需要与系统实际的用户进行沟通，在客户负责人与系统用户间进行协调，为项目组争取利益，让系统实际开发出来的功能满足甚至更好地符合系统用户的工作内容以及业务需求，除此之外还有用户体验及界面上的功能确认等。

系统用户在实际的工作过程中，需要对自身工作的内容进行不断的总结，给客户负责人提出更多、更能提高效率的业务需求流程，这样才能够让自己及同事的工作轻松一些，使自己的工作平台更加完善、便捷。

系统用户在工作过程中需要不断地积累和总结工作业务经验，所以实际工作过程中要对自己的工作业务进行充分了解。首先需要先了解工作内容、工作业务流程、工作所需要的技能和工作所使用的工具软件等。

系统用户实际的日常工作其实也比较单一，就是在工作过程中重复操作自己所具备的技能、经验及实际工作中需要的业务经验流程等内容。系统用户的工作相对简单，在熟悉了自己岗位的工作流程等内容后，系统用户的工作内容就简单多了，很多都是重复性的工作。

系统用户的工作比较单一，所以实际的经验提升方法也比较单一。无外乎就是不断地去学习并在实际的工作过程中去操作自己所学到的知识内容，这样才能够更快、更好地对自己的工作内容进行学习和经验总结，更加熟练地进行自己的本职工作。

系统用户因为实际工作比较简单，所以在工作过程中与其他角色的沟通也不是那么频繁。一般来说，系统用户在工作过程中使用系统功能的时候，会自己总结新的业务操作功能，这样才能让客户负责人与系统建设方进行沟通，使系统更加完善，更好地服务于自己的工作。

系统用户在工作过程中基本上除了开始的时候学习工作业务操作流程外，还需要不断地补充新的业务流程内容，更好地在工作中进行学习及实践。所以，系统用户一般都是先对自己的工作内容的业务操作流程进行了解，先解决工作过程中的问题，然后再不断学习提高，并将自己在实际工作中遇到的问题提交给客户负责人，使系统更加完善，更好地提高自己的工作效率。


第3章　软件工程师

第4章　软件设计师

第5章　软件评测师

第6章　前端设计师

第7章　数据库工程师

第8章　软件配置工程师（SCM）

第9章　软件质量工程师（SQA）

第10章　需求分析师

第11章　SEO工程师

第12章　安全工程师

第13章　系统架构师

第14章　技术经理

第15章　项目经理

第16章　产品经理

第17章　文案人员（项目文档的处理）


把软件工程师放在这里进行介绍，绝对没有贬低的意思。所谓排名不分先后，就是这个道理。项目成员没有贵贱之分，因为他们是一个团队，只有拧成一团的团队，才能成功。其实，软件工程师是最伟大的项目成员，项目的成功离不开他，项目的质量，同样也是。虽然在项目实现的分层结构中，他处在最基础的层次中。

项目成员的工作各有千秋，每个人负责的项目任务都是不可替代的，其工作职责自然也不一样，但有些是相辅相成的。有些项目因为人手问题，部分项目角色不得不一人身兼多职，既做这个也做那个的，所以其工作职责就混杂在一起。虽然界限划分不是那么详细，但却是行之有效的方法，因为有时候项目团队中的某个角色，也会请教其他角色以解决项目中碰到的问题。

软件工程师的工作职责大致划分如下：

很多人认为软件工程师的职责就是编写代码，这个只是最基础的职责。软件工程师同时还参与其它的项目活动，并从中起到辅助的作用。

软件编码的基本，是从理解需求开始的。首先，必须从理解需求入手，分析需求，转化成模块设计，建立模块模型，然后从模型出发，转换为模块代码。这期间，软件工程师就需要参与系统的概要设计和详细设计。这是对需求理解的基础上才能进行的建模工作。随后，项目执行阶段开始了，这时候即开始系统模块的编码工作，同时辅助以编写单元测试代码，为后期的测试工作做准备。接着，就是模块单元测试和整体测试了，这方面需要配合测试人员进行。最后，还需要参与用户手册文档的编写，因为软件工程师对自己所涉及的那部分需求是最了解的。

当然，这是个“理解需求-设计-编码-测试”的循环，这里借用一下迭代模型的术语。

这个循环也体现了软件工程师日常的工作内容。从这里看，貌似比较枯燥。特别是在严格的编程规范的压力下，软件工程师的编码工作看似无趣，完全是代码民工的概念，其实不然。一个系统要具有规范化的管理，规范化的开发等，就必须从小做起，所以这个代码编写的活是一个很重要的工作。其中你可以发掘编程语言的特点、优化、乐趣等内容，特别是在你用新学习的知识高效地搞定一个模块的时候。个中滋味只有软件工程师才能理解。

软件工程师（我们习惯叫程序员，但叫软件工程师更书面化和理论化）所具备的知识，不一定具有很高的深度，但是要有一定的广度。语言之间是相通的，各语言之间的语法学起来应该不难，难的是深入地做一个优质的系统或组件。我们提倡多学几门语言，特别是具有相对意义的语言，比如.Net和Java就是相对的语言，好比windows和Mac等。

之所以要学习这些相对的语言，一个是因为他们的互通性，另一个原因是它们是相互借鉴的语言，比如.Net实际上很多内容就是抄袭了Java的思想，比如跨平台、中间语言、反射等。这样对比地进行学习，比单独学一门语言要快些，同时可以借鉴相对语言的思想，把好的思想继承下来使用，也是一个乐趣所在。

下面我们总结下软件工程师所应具备的理论和实际知识：

上面对软件工程师应具备的知识进行了泛述，其实在实际中，软件工程师给大家的印象往往就是什么都做，某件事没人做就由他来做，到处打杂的样子。所以很多时候软件工程师也蛮自豪，自己啥都会做。这个跟我们所讨论的软件工程师具备的知识没有直接关系，也不冲突，我们只是总结各角色的内容而已。

我们工作时所对应的工作不外乎两种：工作和学习。日常工作，就是每日基本都在做的工作。

基于每天进步一点的思想，对于软件工程师，我们总结的日常工作如下：

看到这里，我们把日常工作分为工作和学习两种。但是，估计有很多人就会抱怨了：平时工作忙得要命，哪有时间学习。这里我想说的是，学习是自己的事，要善于挤和钻，趁着中场休息的时间，看些自己感兴趣的知识内容。一来可以缓解下工作的紧张程度，二来可以学习到或者关注到自己喜欢的内容，这个是一举两得的事情。

而且，项目经理有责任为员工提供学习和整理内容的时间，这个也是我做项目管理时所需要安排的内容。

对于项目团队来说，成员经验提升的方法，一部分来自自学，另一部分可以由项目团队内部的项目经理组织的团队学习和讨论的会议进行。

但是，个人认为，自学是很大的一部分。通过自学，你学到的才是真正理解了的概念，才是真正充实了自己的知识，才是真正符合自己兴趣的内容。

不过，仅仅通过自学是不够的，这样只能培养出团队的英雄，而不是一个相对平衡的团队。所以，这时候项目团队内部的交流就派上用场了。通过交流，可以将团队成员间的差距缩小，进而将团队的核心竞争力提高。

对于自学，可以通过阅读相关书籍，或者网络上的资料来进行。这部分学习的时间，可以在项目实现之余，或者自己找时间去学习，因为工作时间相对来说是限制了学习的时间。对于交流，除了项目团队内部的交流会议之外，项目经理还可以使用XP极限编程的方式来直接使某几个人的编程风格和水平的差距进行缩小。当然了，也可以通过博客、提问等方式与网络上的友人进行交流，这样既增长了自己的见识，也使自己的朋友圈子扩大，同时也会找到志同道合的友人，且能够在实际工作中帮助自己的友人。

程序员与团队其他角色的沟通还是比较多的。

1) 一部分是开发经理，由他来进行工作的划分；一部分是软件设计师，由他来指导和编写代码；一部分是需求分析师，由他来确定软件功能实现是否符合用户的需求；一部分是测试人员，由他们反馈回来软件功能的测试结果，确定是否要更改代码以修订BUG。

2) 在沟通过程中，沟通是需要技巧的。因为程序员是代码的直接编写者，代码的质量、效率、是否符合需求都由他们来实现。所以，在系统功能与用户需求的实现差异上就得看程序员是否真正理解了需求。剩下的，就是与团队其他成员的协作部分了。

总的来说，程序员在团队中与其他成员的沟通还是比较多的。但是，一般程序员做好自己的本职工作就可以了，这已经包含了沟通的技巧。

软件工程师要阅读的书籍应该是一些基本的、浅显易懂的书籍，但是面一定要广，覆盖面一定要全一些，这样在以后的工作中如果需要到的话，再回头找回来也很快。下面罗列一些基本的书籍。

1) 语法（入门编程系列）

对于程序员来说，语法是编程语言的根本，必须做到精通。当然，语言基本都是相通的，这个只要将面向对象等编程思想容纳到代码里，估计就没问题了。

2) 数据结构

数据结构是一门必修的课程，因为数据结构代表了数据存储的方式以及效率问题。每门语言都有自己的数据结构方面的数据，建议做到熟悉程度，在实际工作中能够与大家的程度差别不大即可。

3) 高级编程系列（参考书）

高级编程系列，做到熟悉即可，当做参考书来进行阅读。因为程序员本身不需要很深入的层面以及很高的架构知识。

4) 线程

现在多线程的程序还是比较多的，尤其是Intel正在积极推广多线程程序的应用。而且，对于一个业务网站来说多线程就是一个典型的例子。这部分可以在实际工作中进行实践。对于程序员来说，做到熟悉还是挺重要的。

5) 网络

网络编程对于大部分的公司业务来说还是比较多的，特别是游戏编程方面，需要用到这部分的知识。对于一般的公司，估计实践的机会比较少。

6) 框架

程序员必须对现在正在使用的框架结构做到熟悉，才能更好地发挥出架构的优越性。不过貌似框架部分的书籍还比较少。这个就得看架构师的水平了。

7) 设计模式

程序员对常用的设计模式的书籍应该进行阅读，以了解架构师在现有的软件系统中所使用到的设计模式；或者应该召开会议，以讲解系统中使用到的设计模式。程序员对于设计模式只需要做到阅读即可。

8) 软件工程

软件工程对于程序员来说是必修的课程。但是深入程度就得看个人的修行程度了。软件工程还是得看，以理解项目经理在实际过程中所应用到的内容，提高项目团队的综合水平。

软件工程师要铭记的话不多，基本都是和编程相关的内容。但是这些内容都是和实际工作相关的内容。下面仅对个人的一些经验进行总结的话。


相比软件工程师这个角色，软件设计师可以说是高了一个级别。按照以前的说法，软件设计师就是高级程序员的角色，只不过后来软考里给它改了个好听的名字（软考里软件工程师就是程序员，软件设计师就是高级程序员）。

软件设计师的工作，其实就是比软件工程师高了一个层次。在软件开发领域里，它所做的工作，只是比软件工程师更高级一些而已。在软件开发工作中，软件设计师将负责复杂的、核心的代码编码工作。软件设计师的工作职责与软件工程师差不多，但是与架构师又差一个级别，与技术经理也是差一个级别。

软件设计师的工作职责大致如下：

这里，我把软件设计师的工作职责与软件工程师对比了一下，大家能看出差别不大。区别仅仅在于编码模块的重点和难点方面。但是，软件设计师不仅仅要做编码工作，更要与文档打交道。这里可看出软件工程师和软件设计师都需要与设计文档打交道，因为他们是系统的直接编码员，需要把设计实现。

对于一些项目，有些软件设计师先进行设计，然后再进行编码，但是有些软件设计师先进行编码，然后再做设计。这里估计有些公司会根据项目的大小，复杂程度来进行定义。小项目可以先编码，再进行设计文档的编写。但是对于大项目，特别是团队合作紧密的项目，就需要先做设计再进行编码了。这样做的好处是有据可寻。但是，如果项目有变更，那么先更改设计再编码的话，就需要付出很大的努力了。

软件设计师应该具有比软件工程师更深入的知识面，而不仅仅是代码编写上的广度。在实际的工作中，软件设计师基本上要负责复杂代码段的编写，所以还是要比软件工程师具备更加丰富的知识。除了基本的语法，软件设计师还要熟悉设计模式等相对高级些的代码框架。

下面我们总结下软件工程师所应具备的理论和实际知识：

上面是对软件设计师具备的知识的一个大纲总结，这里说得相对比较广泛，而且基本上是理论上的知识，更多的需要在实际工作中去进行实践。

软件设计师的日常工作与软件工程师差不多。不过软件设计师要面对的是相对更难一点的项目设计与编码工作，其他的这里分类不明确就了。

基于每天进步一点的思想，对于软件设计师，我们总结的日常工作如下：

这里软件设计师的日常工作与软件工程师的工作没有区分那么仔细。日常过程中所涉及的工作内容我这里也不区分那么多了，毕竟下面有程序员，上面有技术经理和架构师。这里除了编写代码外，还有文档编写工作，这个只是参与，建议由专门的文档人员来编写吧。还有就是新技术的学习与交流了，这个通过开会来进行比较合适。

学习有很多种途径，比如看书、看资讯、看资料、看PPT，或者参加培训等。学习能够获取知识，从学习中获取的叫做知识，但是从学习中领悟到的另一层意思那就叫做智慧了。

软件设计师应该多读多看资料，以补充工作获取的经验之外的知识以及领悟智慧，或者参加工作和网络学院之外的培训等。个人认为项目组内应该多举行一些培训活动以让项目组成员提高自身的素质和经验。这里推荐大家看看《程序员》杂志或者去51cto等网站以及博客园等论坛。

个人觉得软件设计师除了多看书积累经验外，也需要写些博客之类来沉淀经验，便于以后进行积累等。对于项目组内的培训，建议由项目经理发起，由技术经理进行培训即可。所以技术经理的担子还是有些多了。至于资料，去CSDN网站的下载频道去搜搜看，会有所收获。我也将一些书籍发在上面了，有空大家可以去看看。

程序软件设计师与团队其他角色的沟通还是比较多的。

一部分是开发经理，由他来进行工作的划分；一部分是软件工程师，指导他和编写相关代码；一部分是需求分析师，由他来确定软件功能实现是否符合用户的需求；一部分是测试人员，由他们反馈回来软件功能的测试的结果，确定是否要更改代码以修订BUG。

在沟通过程中，沟通是需要技巧的。软件设计师是代码的直接编写者，代码的质量、效率、是否符合需求都由他们来实现。所以，系统功能与用户需求的实现就得看软件设计师是否真正理解了需求。剩下的，就是与团队其他成员的协作部分了。

软件设计师与团队之间的沟通还是挺多的了，除了编写代码之外，还需要与需求打交道，以确定是否符合需求。具体软件设计师在团队中的作用在前面已经介绍过了。

因为软件设计师与软件工程师之间差别不太大，这里借用了软件工程师的内容。

对于程序员来说，语法是编程语言的根本，必须做到精通。当然，语言基本都是相通的，这个只要将面向对象等编程思想容纳到代码里，估计就没问题了。

数据结构是一门必修的课程，因为数据结构代表了数据存储的方式以及效率问题。每门语言都有自己的数据结构方面的数据，建议做到熟悉程度，这样在实际工作中能够与大家的程度差别不大即可。

高级编程系列，可以做到熟悉即可，当作参考书来进行阅读。因为程序员本身不需要很深入的层面以及很高的架构知识。

现在多线程的程序还是比较多的，尤其是Intel正在积极推广多线程程序的应用。而且，对于一个业务网站来说线程就是一个典型的例子。这部分可以在实际工作中进行实践。对于程序员来说。做到熟悉还是挺重要的。

网络编程对于大部分的公司业务来说还是比较多的。特别是游戏编程方面，需要用到这部分的知识。对于一般的公司，估计实践的机会比较少。

程序员必须对现在正在使用的框架结构做到熟悉，才能更好的发挥出架构的优越性。不过貌似框架部分的书籍还比较少。这个就得看架构师的水平了。

程序员对常用的设计模式的书籍应该进行阅读，以了解架构师在现有的软件系统中所使用到的设计模式。或者应该召开会议，以讲解系统中使用到的设计模式。程序员对于设计模式只需要做到阅读即可。

软件工程对于程序员来说是必修的课程。但是深入程度就得看个人的修行程度了。软件工程还是得看，以理解项目经理在实际过程中所应用到的内容，提高项目团队的综合水平。

因为软件设计师与软件工程师之间差别不太大，这里借用了软件工程师的内容。


软件评测师在软件开发项目中起到很重要的作用。微软的软件开发，就是一个开发人员对应两个软件测试人员的，可见软件评测师的重要性。当然，这个是大公司的做法，在小公司里，往往需要软件工程师和软件设计师自己去参与一些基本的测试，或者到了后期参与系统集成测试。但是，软件评测师的作用不仅仅体现在做测试上，他还能浏览代码，进行白盒测试，同样能对开发人员的工作进行影响。所以，有时候，好的软件评测师的前身往往是软件工程师或者软件设计师。

软件评测师的工作也不那么简单，他需要很大的耐心。软件评测师往往都是进行一些重复性的任务，所以，软件评测师的工作就显得比较繁琐了。然而，软件评测师的工作职责就是为了让软件顺利地运行，再小的问题也要找出来，让软件工程师和软件设计师去解决。

软件评测师的工作职责如下：

软件评测师的工作职责，就是让软件评测师具备相关的行业领域知识，更好地为软件开发过程中出现的BUG等问题进行查找发现，更好地为软件工程师和软件设计师开发出来的软件服务。

软件评测师需要具备的知识不是很多，但是为了行业领域知识，多学些其他的知识也是应该的。在这里简要描述一下软件评测师需要具备的一些行业领域知识。

软件评测师日常的工作比较繁琐，基本都是一些重复性的工作，虽然现在有自动化的测试软件，但是一些测试内容仍然需要软件评测师自己手动去进行测试。特别是一些大型的系统，自动化的测试也需要手动的配合才能进行。

软件评测师经验提升的方法也不多，因为工作的单一性、重复性和繁琐性，软件评测师的经验提升，往往需要自己进行学习，例如从网站上获取测试方法和自动化测试方法等。

目前国内对软件测试这个领域的关注度不是很高，导致国内软件测试领域的一些测试方法比较过时，往往只是对一些软件测试基本方法和自动化测试做一些介绍就基本完成了，所以软件测试在国内领域还需要不断地提高。

测试本身分为硬件测试和软件测试，我们这里只讲软件测试的内容。笔者曾经搜索过国内的测试杂志，具体大家可以去搜索一下，但是这些杂志水平良莠不齐，有些也将双月刊降为月刊，可见国内的软件测试水平还有待提高。

软件评测师在项目组中与其他角色的沟通也不是很多，一是要把测试出来的BUG交给软件工程师和软件设计师去处理；二是要对项目经理负责，把测试报告提交上去。

1） 与软件工程师和软件设计师的沟通。软件评测师在项目中，要把测试出来的BUG提交给软件工程师去进行修改，同时还要查看软件工程师的部分代码，看看单元测试是否有问题。

2） 与项目经理的沟通。软件评测师需要把测试报告提交给项目经理进行审阅，这样项目经理就能知道谁的BUG最多，谁需要加强编码方面的技能。同时项目经理也能大概知道谁的测试水平比较上档次。

因为软件测试在国内的水平良莠不齐，所以软件评测师需要阅读的书籍也不是很多。


前端设计师，是这几年才兴起的一个概念，也是一个较新的职位，其实其前身就是美工。传统的美工只是负责一些图片的编辑工作。然而，在日益变化的现在，传统的工作已经无法完成日趋复杂的需求。于是，前端设计师这个职位就诞生了。

前端设计师的工作职责不多，不外乎就是设计界面、排版、编辑成可点击的界面、编辑图片。当前，又多了移动端的一些界面设计的工作，前端设计师的工作又更进了一步。

前端设计师首先要具备良好的美工经验，其次才是界面前端的一些脚本设计工作。

前端设计师的日常工作比较简单，无需很复杂的工作。

目前国内对界面前端设计的内容很多，比如PS、JS等，能够学习这些的网站也很多，所以对于经验的提升不是难点。对于经验提升的方法，不外乎看书、逛网站等形式。前端设计师自身的经验提升，目前只有靠自己多学习，多在工作中实践，才能够获取更多的经验。所以，能够在项目中进行实践，是一件很愉快的事情。

前端设计师由于有时候需要参与软件系统的原型设计，所以要与项目经理进行沟通；又由于有时候需要设计JS脚本，所以要与软件工程师或者软件设计师沟通，获取一定的经验。

与项目经理的沟通。前端设计师需要设计一定的原型，所以要与项目经理进行沟通。一方面是要与项目经理的需求进行切合，另一方面又需要符合用户的操作习惯，所以就要与项目经理进行深入的沟通，对软件系统原型进行修改。

与软件工程师的沟通。界面设计师在设计JS脚本的时候，有些内容需要与软件工程师进行沟通，看看是否符合需求、是否符合用户习惯，所以需要与软件工程师沟通交流经验。

由于国内的美工杂志等缺乏，导致界面设计师能阅读的书籍很少，从网络上进行获取学习的机会更大一些，毕竟现在是网络时代，从网络获取知识已经是经常的事。不过，值得庆祝的是，现在有很多的前端工程师将自己的作品发表到互联网上。下面给出几个比较好的前端设计网站。


数据库工程师是整个项目软件开发最底层的操作员。因为现在的系统很多都是以数据库作为中转和存储的，所以数据库工程师的作用就显得很重要了。很多的软件系统都需要先设计好底层的数据库表，然后再在数据表和数据字典的基础上进行开发，这其中就包括ASP.NET、JAVA、PHP、Android和IOS等软件开发语言，这样，数据库工程师的职责和重要性就显现出来了。

因为数据库工程师是项目开发基础阶段的成员之一，所以其工作职责就显得重要，就如同面向对象中的依赖关系，项目管理中的前置（完成-开始）任务一样。

因为数据库工程师处于基础的项目层面，所以其具备的知识相对要求比较广泛，就是说，不能局限于对某个数据库的理解，应该对所有的数据库，包括NO-SQL类型的数据库也有所了解，做到面广但是某个方面精通。

数据库工程师的工作相对比较简单，所谓熟能生巧，其在日常工作中需要配合项目组对系统的底层数据库开发进行设计，还需要对运维的数据库进行维护（DBA的工作），并对数据库相关的内容进行调优。

数据库工程师的工作内容不多，但是因为都是底层的内容，所以其工作内容对项目来说是非常重要的。其经验提升需要学习的内容不多，但是需要跟上数据库系统更新的节奏，对数据库系统（比如MS-SQL Server、Oracle、MySQL）的更新需要及时地调整工作内容，与时俱进，及时跟上新技术的学习步伐。

因为数据库的工作性质相对底层，所以数据库工程师在项目组中与其他成员打交道就相对比较多一些。首先数据库工程师需要跟项目经理沟通需求，对需求中的数据库表进行设计；在项目开发过程中，对需求变更或者数据表调优等进行处理；在项目后期，主要针对表间关系的调整及数据处理SQL语句进行调优等。所以，数据库工程师主要与软件工程师沟通。

数据库工程师除了必读软考中的中级数据库工程师教程之外，还需要对市面上的所有数据库的教程（推荐从入门到精通系列）进行阅读，了解所有数据库的设计、调优、运维等方面的知识。


软件配置这个概念在很久以前就产生了，但是在项目组里进行划分还只是大公司才做的事情。软件配置工程师这个职位主要是被分配在质量管理部门，针对项目的软件质量进行分析管理，配合SCM软件工具进行处理。

软件配置工程师的工作内容不多，主要的内容就是对项目中的代码、文档等进行系统配置，达到一个优化的程度。

软件配置工程师因为工作内容不多，所以其工作所具备的知识点就不那么多了，一般成员培训一下就能够胜任软件配置工程师。

软件配置工程师日常的工作不复杂，就是对项目中的文档、源码等可配置的内容进行配置化、规范化的维护管理。

软件配置工程师也需要不断地学习计算机软件类相关的知识内容，虽然其工作内容不多也不复杂，但是仍然需要不断地对自己的经验进行总结和积累。在工作过程中，软件配置工程师需要对配置管理这部分内容进行学习，同时在实际的工作过程中去操作实践，这样才能更快更好地学习到软件配置的内容并将所学应用到实际的项目过程中。

软件配置工程师与项目组成员的沟通不多，主要是与软件工程师打交道，因为其需要对项目的源码等进行配置，同时也需要与项目经理和文案人员进行沟通，对项目产生的文档进行配置管理。

软件配置工程师需要对配置管理这部分的书籍进行系统化的学习，这样才能够让项目配置管理更加规范化。同时，还需要阅读版本控制方面的书籍，对软件配置管理的工作进行更加全面的维护管理。


软件质量工程师也是分配在项目质量控制部里的编制，对项目的软件编码质量等进行管理，与软件配置工程师相比，软件质量工程师主要偏向于对项目的质量控制部分进行管理。虽然在项目管理过程里没有详细划分这个岗位，但是在项目管理中仍然需要软件质量工程师对整个项目的质量进行控制管理。

软件质量工程师属于质量控制部的一员，其工作内容不多，主要是对项目中的源码、文档等内容的质量控制。质量控制部的原则就是对项目的所有内容进行质量控制，特别是CMMI软件成熟度模型中的级别，需要通过CMMI等级的公司需求对项目内容进行质量控制，还有就是ISO9001等质量控制级别。

软件质量工程师因为需要对项目中的所有内容进行质量控制，所以必须熟悉质量控制相关的内容。一般来说，公司也会请专家来给质量控制部人员进行培训，这样经过培训后的质量控制部人员就能够及时了解工作中的质量控制内容。软件质量工程师需要对CMMI软件成熟度模型和ISO9001:2000等规范做深入了解，更好地在工作中对公司级别的内容进行质量控制。

软件质量工程师平时的工作内容不多，就是根据自己的经验，对公司级别的内容进行质量控制，然后整理工作的内容，让控制部的人员分享并累积自己的经验。在实际的工作过程中，就是根据质量控制原则，比如CMMI模型，对源码和文档等进行质量控制，ISO9001用于证实组织具有提供满足顾客要求和适用法规要求的产品的能力，目的在于增进顾客满意度。

软件质量工程师需要在工作中不断地学习新的质量控制标准，并应用到实际的工作过程中，把CMMI和ISO9001等质量控制标准在公司级别的基础上进行更好的维护管理。除了软件质量工程师要对这些质量标准进行学习之外，公司也应该以培训等方式对质量控制部门的人员的素质进行提升管理。

软件质量工程师在项目组中的地位是中等级别的，需要与项目经理、软件工程师和文案人员等角色进行沟通，主要是因为这些角色需要的工作内容都涉及质量控制的领域范畴。项目经理需要对项目文档、质量控制等内容进行把控；软件工程师则是对代码上的内容质量进行把控，比如代码质量，代码的规范性等；文案人员是对项目文档方面的内容质量进行把控。

软件质量工程师需要阅读的书籍其实不多，更多的是对质量控制标准，比如CMMI和ISO9001等体系的学习。


需求分析师作为项目管理过程中的一个重要角色被项目经理所认知。需求分析师的任务是配合项目经理的实际工作进行的，在项目需求管理中对需求做分析整理，形成需求功能书或者解决方案书，让项目组成员能够更准确地理解需求，更好地进行项目的下一步设计。

需求分析师要做的工作不多，主要是在项目前期的需求阶段，工作内容相对比较简单，与需求方进行沟通并记录下调研内容，同时将调研内容记录成文档让项目组人员阅读，与项目经理沟通，协助项目经理对需求内容进行确认。

需求分析师需要对项目需求进行不断的更新补充，在项目管理过程中对需求进行确认，配合项目经理对需求整理记录。在工作过程中需要对项目涉及到的业务进行分析、确认和整理补充。需求分析师对于项目的需求进行分析，并且把需求内容进行详细记录。

需求分析师的工作相对比较简单，主要就是在需求阶段进行分析整理，配合项目经理对需求进行确认，对项目后期试运行期间的需求进行控制，防止相关的需求变更。

需求分析师的工作不复杂，就是对项目的需求进行编写、分析并对后期的需求变更进行控制。此外，需求分析师需要具备更多的项目业务知识，配合项目经理进行需求控制和变更管理。

需求分析师在项目中是一个贯穿项目需求过程的角色。除了配合项目经理与客户负责人沟通需求、调研需求以外，其他的时间需求分析师主要对需求进行整理分析，对需求中的内容提出合理的要求。与项目组的其他成员对需求进行分析理解，使项目组成员顺利完成项目的所有工作内容。

需求分析师因为工作内容相对比较简单，所以需要了解的项目内容就比较少了，更多的是对项目的业务进行把控，对需求及时进行分析并整理需求功能书。


SEO工程师是一个新兴的职位，在实际的项目管理过程中，SEO工程师的地位相对靠后，只有在项目试运行以及运营期间才能体现出其作用。在项目完成之后，SEO工程师的工作仍然在进行，也就是说，SEO工程师的工作处于项目实现之后，在项目实际验收之后仍然需要对项目进行SEO处理。

SEO工程师在工作上主要是对网站项目的产品进行优化管理，工作内容不复杂，做过之后自然就懂。

SEO工程师必须对SEO搜索引擎优化的内容具备一定的知识，对多个搜索网站进行搜索引擎优化的内容进行调整。

SEO工程师在工作中需要不断地对网站项目进行优化处理，同时对新的SEO优化内容进行不断的学习，根据新的搜索网站的SEO内容进行调整。

SEO工程师需要在工作中对新的SEO搜索规则进行学习，对新旧网站项目进行SEO搜索引擎优化。

SEO工程师主要对网站的架构及代码结构进行SEO搜索引擎优化的设置，所以其需要与项目中的系统架构师和软件工程师等进行沟通，提出并对网站的内容进行SEO搜索引擎优化的设置。

SEO工程师平时应该阅读SEO优化的相关书籍，并在实际的项目过程中进行应用。


项目安全工程师也是一个相对比较偏的职位。安全工程师主要针对网页端或者系统级的安全问题进行处理，找出项目系统中所有可能产生出的安全问题，其中包括以前产生的比如SQL注入等安全问题，这需要安全工程师在项目的设计架构和项目编码过程中就进行处理，让安全问题解决在项目的起始以及开发过程中，更快更好地为项目质量等工作进行负责。

安全工程师这个职位也是这些年才提出的，其主要是对项目中系统的安全问题进行分析并解决掉这些安全隐患。

安全工程师需要对系统的各个层次的内容进行详细了解，获知常见的安全漏洞，对其他系统的安全问题都有一定的经验，能够对系统安全做详细的分析并解决掉其中的问题。

安全工程师在平时的工作过程中需要对系统的安全问题进行分析，并对系统的安全隐患进行记录分析解决，同时，也需要对国际上的系统安全问题进行收集整理，在实际的工作过程中进行应用。

安全工程师需要在日常的工作过程中对新的安全问题和工具有一定的认识，并且在实际工作中应用。比如在虚拟机中进行新的系统安装，并在里面进行安全问题分析与模拟解决。

安全工程师在项目中主要是与软件工程师和系统架构师进行沟通，因为在实际的工作中，系统的编码问题都是由这些项目成员处理的。所以，安全工程师需要与这些项目组成员进行沟通，从系统底层到高层次对项目组成员的实际代码架构等进行分析解决。

安全工程师在实际中需要阅读相关的系统安全书籍，还有一些黑客攻防之类的书籍也需要精通。

安全工程师的工作不复杂，平时的工作中对系统安全问题必须精通：


系统架构师这个职位的重要性是不言而喻的，在项目设计开发过程中处于高层的位置。系统架构师需要在项目的需求相对稳定之后就进行系统架构设计，并在项目开发过程中对编码的开发架构和编码技术等问题进行解决。系统架构师在实际的项目系统设计过程中就极其重要，在项目系统开发过程中可能需要不断地调整架构上的细节，比如接口方面的内容，所以，系统架构师的作用也是贯穿于整个项目系统从设计到开发完成的这样一个过程。

系统架构师的日常工作更加的单一，但是又有其重要的一面。系统架构师在系统需求阶段就必须介入系统开发问题，同时根据需求到设计的这么一个理念去对系统的整体架构进行设计。

因为系统架构师是对系统进行架构设计的，所以其需要在系统级别的问题上必须精通。对操作系统的底层和开发代码的底层进行理解，并在实际的工作过程中进行实践应用，让系统架构能够在其他项目中进行复用。

系统架构师的工作比较单一，基本上在项目需求到设计阶段就基本完成了，后期在系统架构上的调整不大。系统架构师日常需要对系统底层进行理解，并且对系统的业务方面也需要熟悉，在设计阶段根据需求对系统的架构进行设计，所以，在对系统架构设计完毕之后，系统架构师就相对比较清闲了。

系统架构师在实际的工作过程中也需要及时补充经验知识，特别是现在，新技术的诞生需要新的架构设计理念，比如大数据、云计算等。系统架构师这个职位也有一定的年限了，软件水平考试中也有考试内容，但是系统架构师的经验是在实际的工作过程中总结出来的，更多的是自我提高，市场上的系统架构设计暂时还没有相关的培训。

系统架构师的设计理念就与项目组的其他角色有沟通需要。其在需求到设计阶段就必须介入到系统架构设计，与技术经理共同把系统架构做好，并在实际的应用中进行及时调整。所以，系统架构师主要与技术经理、软件工程师进行沟通比较多。

系统架构师因为相关的培训比较少，所以基本上都是自我学习比较多。


技术经理这个职位在软件项目组中的作用也是很大的，技术经理需要配合系统架构师对软件系统的架构进行规划实现，同时需要对项目开发过程中产生的一些技术上的问题进行解决处理。技术经理在职位上需要配合项目经理对项目需求等进行分析处理，同时需要对项目的设计文档负责，对项目设计内容进行管理，让系统产生的所有编码技术问题得以解决。

技术经理在实际的工作过程中是一个重要的角色，其作用贯穿项目的整个过程。在需求到设计、设计到开发阶段都具有重要的意义。

因为技术经理在项目开发阶段的重要性，所以对其所需要的知识和经验要求比较高。除了软件工程相关的知识、设计模式、从入门到精通系列的学习内容，技术经理还需要对整个架构下面的技术问题进行解决处理，配合软件工程师对整个项目的编码进行沟通处理。

技术经理在实际工作过程中也需要进行学习，同时配合项目组成员进行系统开发阶段的技术和攻关问题，更好地在项目过程中发挥自己的作用。

因为技术经理基本上是有招聘但是没培训等内容的，所以，技术经理需要自己学习提高。技术经理需要在工作空闲之余进行不断的学习及经验提高，同时需要对系统业务等内容进行理解，以便更好地对项目成员进行技术上的培训，在实际工作系统开发阶段对技术问题进行解决。

技术经理属于技术岗位，在需求到设计阶段配合系统架构师对系统进行架构设计，在设计到开发阶段对项目组软件工程师进行技术培训，让开发人员在项目的开发过程中更加顺利地进行开发。

技术经理更多的是进行自我提升，所以需要阅读相关的系统设计开发书籍。

1）框架

程序员必须对现在正在使用的框架结构做到熟悉，才能更好的发挥出架构的优越性。不过貌似框架部分的书籍还是比较少。这个就得看架构师的水平了。

2）设计模式

程序员应该阅读常用的设计模式的书籍，以了解架构师在现有的软件系统中所使用到的设计模式。或者应该召开会议，以讲解系统中使用到的设计模式。程序员对于设计模式做到阅读即可。

3）软件工程

软件工程对于程序员来说是必修的课程。但是深入程度就得看个人的修行程度了。软件工程还是得看，以理解项目经理在实际过程中所应用到的内容，提高项目团队的综合水平。


软件产品经理这个职位也是这些年产生的一个重要的岗位，产品经理从项目的需求开始，到系统的原型设计，后期的系统运营等方面都有所涉及，在产品项目管理过程中是与项目经理相互配合的一个职位。软件产品经理对外包和公司内部项目的产品开发等过程都负责管理。

产品经理的工作内容不多，主要是需求、设计和运营三方面，所以就需要从这三方面入手去进行工作的划分。

产品经理因为在工作中涉及需求、设计和运营三部分，所以需要对这三部分的内容进行学习并达到精通的程度。需求方面需要配合项目经理与客户负责人进行沟通处理，所以需求分析记录经验也需要具备一定知识；设计方面是根据需求方面的内容进行制定的，所以原型设计方面是一个充满创意的设计内容，需要产品经理具备一定的设计能力；运营方面产品经理需要与市场部进行协调处理，更多的是对市场内容进行调研和管理。

产品经理日常需要做的事情还是比较多的，需要配合市场部对产品的设计开发进行调研并对实际内容进行管理操作。所以，产品经理实际是对原型设计方面进行管理设计，还有就是对运营方面进行学习并应用到实际工作中。

产品经理因为实际的培训课程不多，所以也是一个需要自我学习提升的角色。在需求上要与项目经理和需求分析师进行沟通，提高自己的需求分析经验；在设计上要与前端工程师进行沟通，提高自己的设计能力；在运营上要与市场部推广人员等进行沟通，提高自己的市场运营能力。

产品经理在项目中是一个设计的角色。在需求上要与项目经理、需求分析师和客户负责进行沟通；在设计上要前端工程师进行沟通；在运营上要与市场部人员进行沟通。因为沟通的目的就是为了将项目做好，所以产品经理在项目中的工作相对没有那么繁忙，只是工作内容需要创意方面的知识。

产品经理也是一个需要自我提升的角色，虽然现在网络上有一定的学习课程，但是仍然需要产品经理不断地进行自主学习。


项目经理在项目组中的作用是非常重要的，在实际的项目过程中，项目经理管理整个项目过程，从系统需求到设计编码、测试和试运行以及后期的验收等，贯穿项目的方方面面，从启动、计划、执行、监控和收尾五大过程组对整个项目的内容进行项目管理，争取让项目能够顺利地进行，更好地服务于项目以及项目组成员，让项目组能够更快更好地完成项目。

项目经理在项目中的重要地位是不言而喻的，项目经理主要在项目过程中是贯穿始终，对整个项目的把控。

项目经理应该具备项目相关的知识，技术、业务和管理都需要精通。在实际的工作过程中，项目经理应该更多地对项目需求进行把控，防止后期的需求变更。

项目经理在项目中处于核心位置，技术上需要配合技术经理进行开发控制，业务上需要与客户负责人进行沟通，管理上需要对整个项目组人员进行管理。日常工作中，项目经理需要对项目计划进度进行把控，对项目的WBS分解结构完成的计划进行监督，从启动、计划、执行、监控和收尾五大过程组对项目进行整体的把控。

项目经理的实际经验需要不断地在工作中进行学习补充，更多的是对项目业务上的补充。相关的项目管理经验，能够通过项目培训的方式积累，比如PMP的考试内容，都需要详细地进行学习，尽量以系统化、标准化的方式进行经验的沟通提升。

项目经理是整个项目的核心，所以其需要与项目组所有成员进行沟通。技术上与架构师、技术经理和软件工程师进行沟通，对项目的开发进度进行把控；业务上需要与客户负责人沟通，对项目的需求进行把控；在管理上需要与项目组成员进行沟通，对项目的绩效等进行管理。

项目经理除了通过培训方式获取经验外，就是通过自主学习得到提升。


作为项目组中的文案人员，需要有一定的文字功底，并对项目管理过程中产生的各种文档进行管理。这里有点配置管理工程师的味道，但是文案人员只是对项目过程中的文档，比如需求功能书、用户手册、会议纪要等内容进行管理，主要还是配合项目经理把项目的相关文档进行整理并进行维护管理，争取让项目更加人性化、规范化。

文案人员在实际工作过程中只需要对项目的文档进行编写维护即可，所以需要具备一定的文档编辑能力，比如对WORD、EXCEL和PPT等工具都需要做到熟练运用。

文案人员需要在项目中与项目经理、技术经理进行沟通，对项目需求功能书、软件设计说明书、项目后期的用户操作说明书等文档进行编写。所以，文案人员需要对项目的需求方面具有一定的理解能力；对软件设计、系统操作也需要一定的知识。

文案人员在实际的工作中需要一定的文档编辑能力，对需求文档、设计文档、用户手册等文档进行编写以及排版，同时提交给项目经理进行备案审核。其工作内容不多，但是也是具有一定的重要性，因为文档写出来是需要给人看的。

文案人员需要具备的经验要求不多，主要是文档的编写及排版能力。所以，需要在实际工作过程中提高自己的文档处理能力。

文案人员主要与项目经理、需求分析师进行沟通，处理项目需求文档内容；与技术经理沟通设计文档编写内容；与项目经理沟通用户手册编写内容。

因为没有相关的岗位培训，所以文案人员需要通过自主学习提升对WORD等文档的编写能力。


第18章　 监理负责人


监理工程师在项目管理过程中起到监督的作用。监理工程师配合项目经理对项目的流程、时间和质量等方面进行管理。此外监理工程师还能够与软件系统外包公司配合进行管理。

监理工程师在实际的工作过程中主要是对项目的整体内容进行监督理解，所以监理工程师的工作职责比较单一，但是其工作量和工作内容对于整个项目来说是非常重要的。因为监理工程师需要从项目的需求开始，直至项目验收，都做类似流程这样的工作。

因为项目监理只是在项目的整个过程中起到监督的作用，类似于项目经理对项目管理的把控一样，所以项目监理工程师需要对项目相关的内容进行了解甚至是成为专家级别的人员。

监理工程师的工作也比较简单，任务量不大，但是重要性就很高。因为其需要对整个项目的流程进行监理，让项目朝着正确的方向进行。监理工程师的日常工作就是在甲方与乙方之间进行沟通管理。

监理工程师因为工作的原因，需要在甲方系统需求方和乙方项目建设方之间进行沟通协调，对整个项目的进度和质量进行把控，把项目建设过程中的问题进行解决，让项目能够更好更快更安全的进行实际的开发建设。

监理工程师在实际的工作中主要是与甲方系统需求方客户负责人以及乙方建设方项目经理进行沟通交流，这就是日常工作中需要经常沟通的角色。对甲方系统需求方而言，就是对系统的需求功能和用户体验等方面的沟通，对需求进行把控，防止在项目后期的需求变更问题；对乙方项目建设方而言，就是对项目的质量、进度和风险进行把控，防止项目有大的风险出现。

监理工程师需要阅读的书籍目前就是国家软件水平考试中级中的项目监理工程师教程，以及项目建造师相关等考试的教材。


对于软件项目角色，还有很多可以叙述的故事。本书内容有限，只能从大的方面对软件项目角色进行学习研究。写本书这件事情终于完成了，不过，由于本书是在非持续性的过程中编写出来的，自然有很多需要完善的地方。而且，从软件设计师的角度出发，本书对部分内容缺乏严谨的认识。

其实在写本书的过程中，我有好几次想过放弃，因为首先，觉得时间不是很充裕；而且支持我的人不是很多，只有自己支持写下来；最后，本书内容虽然基本覆盖软件项目角色的全部范围，但细节部分仍需要详细论述拓展。

但我相信，付出总会有收获。我在学习别人知识的同时，别人也需要学习我的经验，所以，继续做我该做的事吧。

因此，我要感谢在本书编写过程中给予帮助的所有人，是你们的耐心和鼓励给了我继续写作的信心；是你们的帮助使我能够深入学习和完善本书的软件项目角色知识，将更多的经验记录下来以进行传播。

本书不敢滥竽充数，然则作者本人水平有限，欢迎大家指正，将批评和建议反馈给我，共同提高。



相关图书

元宇宙中的硬科技
元宇宙中的硬科技
AIGC提示词美学定义
AIGC提示词美学定义
专利写作：从创意到变现
专利写作：从创意到变现
架构思维：从程序员到CTO
架构思维：从程序员到CTO
产品经理方法论——构建完整的产品知识体系（第2版）
产品经理方法论——构建完整的产品知识体系（第2版）
开发者关系实践指南
开发者关系实践指南

相关文章

相关课程

异步社区-致力于优质IT知识的出版和分享

京ICP备05035396号-6

京公网安备11010602100305号

增值电信业务经营许可证（京B2-20201559）Powered by 人民邮电出版社▪出版云