项目经理最重要的事情是使老板，客户和开发团队都happy.

但他们的目标是不一样的，
老板只想多赚钱，一直赚下去，
客户只想少付钱，系统又好。
开发团队想要轻松，又能学到新的东西。

所以项目经理就是一个协调者的角色，如何达成平衡很重要。

一些人经常把项目经理和系统分析员搞混。其实他们有很大区别。国内项目规模小，所以常常
项目经理就是系统分析员。

一个项目的开发结构和流程我看还是有必要说一下，一般大点的公司要做一个项目要有的角色都有

1客户 提出自己的需要，想做个什么样子的软件，哪里哪里都是什么样子的

2SA 系统分析师，用来根据客户的需要来做分析，设计项目结构

1和2形成需求文档，供开发人员使用

3后端人员  根据需求建表，也就是数据库，写数据库查询语句和response 用http来发 state （表示后端状态，是查询成功还是数据库崩了还是其他错误比如参数不够，查不到）data（存放数据，一般是json数组结构）

4架构师   这个用来根据需求来配置服务器 ，看硬件的大小，比如用到了缓存就要使用内存，数据量大小用来决定硬盘大小

5UI   ui主要是通过绘制图片来展示客户的需求，也会把尺寸样式给前端展示

6前端   前端主要是根据ui和需求来绘制页面，写request请求和发送数据，把数据上到网页。要对后端的数据做验证和结构更改，还有请求的逻辑也是要写的。

7测试  测试人员将项目跑起来，按照测试用例来模拟不同的场景，看代码的反应。通常就是冒烟测试，直接搬一块代码上去看看。有点傻大粗。当然还有其他的测试软件，用来辅助。这里打比方  业务逻辑是否有bug  ，并发情况下能撑多久，攻击下的安全性，运行是否缓慢这些。

项目开发及角色扮演
 
在开发一个项目的时候，前期的准备工作往往就有很多，还有一个团队的组建也是十分重要的，而一个好的团队在软件开发中有着不可忽视的重要性。
不管是开发何种项目，都需要典型用户和该项目所适应的应用场景。
对于开发人员来说，不能想当然的认为用户需要什么样的软件，这个软件应该具备什么样的功能，然后尽可能详尽的添加自己所能想到的所有方面的功能，且不论一些功能是不是用户真正需要的，所谓将自己软件的拓展性做的特别好，就认为可以覆盖所有用户，然而，一昧的追求拓展性，有可能就会带来很多的副作用。综上，在开发项目的时候不能一昧的追求某一个单方面的需求而忽略整体的利益。
典型用户往往是由一种角色的抽象，典型用户可以分为受欢迎典型用户和不受欢迎典型用户。典型用户可以包括以下内容：名字（越自然越好）、年龄（不同年龄和收入的人有不同的需求）、收入、代表的用户在市场上的比例和重要性（比例大小等同于重要性高，如付费的用户“会员”的比例比较少，但是影响大，所以更重要）、使用这个软件的典型场景、使用本软件/服务的环境（办公室、家里、公共汽车、地铁等）、生活/工作情况、知识层次和能力（教育程度，对电脑，互联网的熟悉程度）、用户的动机、目的和困难（困难=需要解决的问题）、用户的偏好。当定义了典型用户以后还不能进行写代码，因为典型用户只不过是我们的设想，是纸上谈兵，还需求同用户进行交流，理解用户，然后进一步细化典型用户。当与用户交流并制定了开发流程后就要将典型用户迁移到场景中了，找到一个合适的场景，然后分配任务，也就是将场景模块化。接下来就可以写规格说明书了，它一般分为功能说明书和技术说明书。功能说明书是从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界、功能的效率、国际化、本地化异常情况等，不涉及软件内部的实现细节。技术说明书有叫设计文档，它用于描述开发者如何去实现某一功能。功能驱动的设计步骤：第一步，构造总体模型，第二步，构造功能列表，第三步，制定开发计划，第四步，功能设计阶段，第五步，功能实现阶段。至此，产生一个完整的、验证过的功能。
对于团队，有很多的模型，较为出名的有MSF团队模型，在MSF团队模型中，任何技术项目都必须达到特定的关键质量目标，才能够被认为是成功的项目。任何一个角色无法实现其目标，都会危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同作出。说白了，一个项目要达到的目标很多，MSF团队模型让不同的角色去实现这些目标。同时MSF也支持CMMI（能力成熟度模型集成）开发模式。
对于项目，就拿“学生信息管理系统”来说。首先，该系统要具备的功能包括：学生能登录该系统并且可以处理一些常用的事件，可以和老师沟通提交老师所布置的专业；对于老师来说登录系统后，可以查看学生的提问、学生提交的作业，也可以回复学生的问题；对于其他人员，系统可以满足他们各自需要的功能；对于管理员，系统应该讲管理员的权限设置的可以处理学生和老师所遇到问题。该系统的数据库要实现实时更新，以免出现因信息更新不够及时可能出现的问题。
不管一个项目大小，开发流程都是一样的，而对于团队的要求却不同，对于大型项目，对于团队的要求相对来说就比较高，但是任何一个团队的组成成分都是相同的。
一个好的团队离不开一个好的PM，他往往是一个团队的核心人员，通常是发现问题并和客户进行交流，并指挥整个团队更好的开发项目，使得项目的各个进程之间更好的协调。其他人员各自做好自己的事情就可以了。
在开发学生信息管理时，PM首先要去学校了解学生和老师对于该系统的基本需求，最好和各个年级的学生进行面谈，将他们的需求汇总后交给开发人员，开发人员在拿到需求列表时，应该仔细分析需求，然后将它们分类细化。接下来就是开始开发了，在开发过程中，不断回顾并尽可能的做的更好。在开发进行一段时间后测试就可以进行了，这样做可以节约时间，同时能够尽可能早的发现错误，减少开支。开发就是在不断测试不断改进中进行的，慢慢的软件的早期模型就出来了，这时可以先交给用户一个模型，让他们感受一下使用是否合理舒服。如果没有什么问题的话就可以将现有的成果完善交付客户了。如果有问题的话就进行更改，直到客户满意为止。该项目采用边开发边测试的开发流程，该流程最大的好处就是不会出现特别大的Bug，减少返工率。
至此该项目的开发就可以告一段落了。

对于项目负责人本身没有太多的经验，只是在2014年以项目负责人的角色完整的带着5个人做完一个一个项目。并且，在这个项目期间还开始了另外一个项目，总结的有些乱，想到哪说到哪，不过都是自己的真实体会。
1 项目开始阶段：
首先对项目的基本需求有一个大概的认识。但是，最终达到什么效果，这需要项目组成员共同讨论决定。在进行讨论的时候会产生很多想法，但是一开始的时候，大家也可能没有想法。最为项目负责人，需要对项目需求有个总体的把握，充分发动每个人的长处。毕竟不是个人都对项目开始的设计有兴趣，项目负责人需要充分听取大家的意见和建议，以及对每个人所擅长的领域的知识有一个全面的听取后，开始对项目进行大体的设计，这是可以选择一到两个人和自己一起思考，并且多把自己的想法与组内成员以及上司和比自己厉害的以及经验比较丰富的人请教和交流。另外，方案设计会出现多种方案的情况，一方面需要将方案与大家交流，一起讨论，另一方面需要将自己比较倾向的方案以及倾向的理由与大家交流。这样才对项目的进展有一个大的方向性的把握，项目开展的速度会快一些。
2 项目的前期实施阶段：
2.1 概要设计文档
经过多番的讨论，最终会定下项目的基本实施方案，这是需要尽快形成项目的概要设计文档。通过概要设计文档，将前期讨论的方案落实到文档中，并且将文档发给每个人，并且抄送给上司，确认大家一起讨论的方案，在实施的过程中，大家如果有异议就可以根据这个文档修改。另外，这样做的也是为了防止时间长，有些人忘记开始讨论的方案，后期根据自己的想法做，这样就会造成你做的和我们设计的方案不是一个，虽然你这样做也可以实现。
2.2 项目分工
经过概要设计文档，应该差不多将项目分块划分好了，这样就可以对各个模块根据个人的长处分工。分工一定要确定每个人的具体的工作内容，具体的各个模块的实施细节可以由各模块的负责人设计。但是各个模块的接口部分一定要统一制定。最后，很重要的一点，各个部分的负责人需要制定各自部分的任务进度安排表，并且写明各个任务的deadline。
3 项目中期实施阶段
3.1 进度跟进
人都是有惰性的，对于分工后的项目开展一定要及时跟进，确定好周期项目汇报时间，并且将大家汇报的工作汇总成进度简报，每次汇总完都要群发给各个组员，并且抄送给上司。每周确定时间进行统一的讨论，各个模块的人员汇报自己存在的问题，大家一起讨论解决，毕竟众人拾柴火焰高。
3.2 任务督促
对于自觉能力不是很好的组员，需要加紧跟进，必要时，需要将这种组员的任务进行再细化，并且规定deadline，这样就会起到很好的督促作用，不会影响项目的进度。


4 项目的后期实施阶段
4.1 完成确认
项目开展到后期，各部分的大致功能算是完成的差不多了，这是就需要针对开始的项目目标，对照任务，对各部分的完成情况进行总体的梳理，确保各个部分没有少做或错做，经过这样的梳理，才会心里有把握。
4.2 反复测试
经过上面的完成确认，就要进行项目的反复测试了，首先是各个部分的分开测试。各部分分开测试没有问题的情况下需要进行联合测试，反复经过联合测试，并且运用测试的科学方法，只有经过这样的测试，才可以确保项目的稳妥。
4.3 详细设计文档
最后需要完成项目的详细设计文档，在完成详细设计文档的时候会对项目的总体有更加深入的把握。同时，会在撰写详细设计文档的时候发现项目值得改进的部分，利于项目的再次提升，同时为以后的项目积累更加宝贵的经验。


以上就是我作为项目负责人的一些体会，可能很多说的不是很专业，还请大家批评指正，共同进行。