关于项目和实施过程中部分角色行为的心得体会

一个项目的完成是一票人磨合的结果，这一票人包括懂业务的客户方（客户经理等），项目manager，需求人员，架构师，开发工程师等等。包括客户方在内的整个Team彼此应可能少的谈地位、领导，应该用一个平常心去体会Team是以合作为主的行为体。

在项目中我们强调工作不能强依赖个人，而应该依赖角色。做到这一点，要有严格的项目管理控制，要能控制每个环节（需求、设计、开发、测试等）的结果，要保证每个环节形成的文档等结果是经的住推敲和研读的。做好这一点除了有很好的管理机制外，还要做到将责任放到心上，要铭记工作不是交出去就算完事了。刚刚接触工作的朋友也许不能很好的判断工作做到什么程度算是好，给出一个参考答案，当你要提交一件job时，如果你的心没有忐忑、没有这样可以么、更没有直接明确的疑虑存在时大概就做好了。

项目需求方是最了解他们的需求了，但需要依靠乙方的需求人员才会更好的将复杂的业务梳理成满足开发要求的需求文档。如果客户方懂点开发知识兴许能帮上很大的忙，比如他可以较为清晰的梳理业务需求，但是懂技术的客户对项目并非会绝对的促进，尤其是在开发上，他很可能不止是站在客户方角度，而是在很大程度上会进入到架构设计上甚至是code中。这样的举动会极大的阻碍。一方面由于他不只是对功能和性能提出要求，而且还会干涉架构、所用框架等，另一方面由于他对技术所持模凌两可的态度，导致他会很大程度上诱导架构更改，也导致在业务与实现的中间转化环节有更大的发挥空间（也不能排除整人的可能性哦）。

Manager是一个多方桥梁，负责和客户方沟通，负责包括需求人员在内的整个团队，负责和自己的老大沟通，负责为项目找资源（包括技术和人才）。Manager要严格控制自己的言行，话要到位事要做好。

需求是一个项目真正开始的源头，需求文档定义的好坏直接关系着项目的成败，而业务方面的事情不去研读，不去进入到业务中是不能真实理解文档的描述是否全面的。而往往在开发设计过程能够体会到什么样的需求文档是优秀的需求文档。对于需求人员，应该以将事情讲清楚为原则，注意业务术语，注意体会客户方所需要的与设计人员和开发人员所需要的不同。

架构师负责的是整个项目架构等的设计，要及时将相关设计文档化，一方面方便开发人员，一方面确保让工作仅依赖角色。架构师要很好的划分功能点，以及实现它的工作量，并选择适合的人去完成，同时要根据此人的能力制定好完成的计划，需要事先了解开发者，例如对所使用的框架熟悉是否熟悉，以此判断完成这项任务时是否包括学习时间。（之后。要审核，对自己的分配，对接受者的能力评估等等）

开发者只需要保证一点，认真把你理解到的需求转化为优质的code，而是否做到这一点，你的心是清楚的，去认真听听你的心声。

在整个团队中是要以做完做好为标准来上线，不能按照上线的计划来紧赶项目进度，甚至是偷工减料。所以Manager就要注意，不要跟客户方一碰面就敲定上线时间，在这之前要认真听取Team成员的意见，尤其是架构师的计划与想法。因为只有他才最为真切的了解每块需求所需要的工作量。

如果你是Team的新人就请观察和学习他人都在做什么和怎么做。

无论是Team中成员还是与项目相关或不相关人员，都要把责任放到自己最重要的位置上，在管理中不反对使用各种规章约束等，但不要让你自己成为它们的奴隶，那样是不快乐的，更为重要的是，事情往往是不会在不快乐中做好的，要让内心的责任来指导事情（如编码、如测试、如项目上线进度）该做到什么地步，同时用你所掌握和可以触及的知识来衡量你的行为，事后更要以此来评估你的决定和行为，促使自己成长。