从我们团队建立以来，到现在引入新的项目管理流程，前前后后经历了3次变化。
最开始的时候，采用的是传统的项目管理流程，在公司内部搭建使用 redmine 作为项目管理工具。但是很快，大家觉得并不那么的好用，可能是某些操作习惯还是不太符合中国人的思维，并且操作繁琐了一点，而且大家都觉得界面比较丑（团队里边还是年轻人居多，大家都对现在新潮的事物比较感兴趣）。
于是，在几经筛选之后，选择了 Worktile 作为新的项目管理工具。Worktile采用的是 “看板式管理 + 任务式驱动” 的方式进行研发流程管理，根据项目或者组定制不同的看板，让任务在看板之间进行流转。可视化的看板让每个人的任务状态直观明了，另外Worktile还有些特性也是很不错的，比如关注任务的人可以接收到任务相关的消息，消息也会推送到个人微信等。我们使用的是免费版的Worktile，一直使用了3年左右。
免费版的Worktile现在也要收费了，不然会有人数的限制。再就是现在访问Worktile的网站经常比较慢，当你要更新任务的时候，时不时卡几下，还是很令人捉急的。单纯的使用看板的方式去做项目管理，任务太松散了，缺乏了一些整体的概念。另外，居于信息保密的需要，使用第三方平台，会存在泄密的风险，先不说需求、任务这些，比如你就不敢上传一些重要的文档、附件等。
有什么办法可以保留现在看板简单方便好用的方式，并且解决掉上面的问题呢？
先是考察了禅道，它是国内开源做得比较好的项目管理系统，但是我试用了下，发现比较难用，并且遇到比较明显的Bug，就放弃了。
无意中看到jira以及它的Scrum敏捷开发实践，我想或许它可以解决我们现有的问题，于是就经过深入的调研与试用后，决定就使用jira + confluence作为我们的项目管理工具，其中confluence是一套很好的文档管理系统，它可以跟jira很好地集成。
敏捷开发，几年前我就了解过但并不深入，正好这次在实践中做一次尝试。优秀的思想必然有其价值所在，不断去尝试实践才会有所进步。Scrum敏捷开发网上的资料很多，也有很多专业的培训机构，这里就不多作阐述了。Scrum有一套完善的理论，但是每个团队的情况各有不同，并不能完全照搬理论到实际的情况中。
这一次我们也是在探索中，希望可以在Scrum的指导下，逐渐形成适用于我们的一套项目管理流程。
高效团队
一个项目做得好不好，跟团队有很大关系。从项目管理的角度来看，我认为一个高效的团队必须满足以下3点：
- 清晰的目标
- 明确的职责
- 规范的流程
清晰的目标
清晰的目标，也即让所有团队成员都清楚团队的目标是什么，项目的目标是什么，长期的目标是什么，短期的目标是什么。
大家清楚了目标，也就有了方向。比如说，公司未来的目标是打造一个开放平台，那好，作为一个技术人员就会去想，现在的系统能不能满足需求呢，如果要做哪个地方要改呢，需要提前做什么准备呢，架构需要怎么搞等等。作为设计人员就会去想，做成什么风格比较好呢，要准备哪些素材呢等等。
大的目标，如公司的方向、公司未来的规划等，到项目的目标、系统的目标、与第三方合作的目标，甚至到本次需求迭代的目标等等，如果让大家都了解通透，那么做起事情来会更加的有目的，同时也会让大家跟公司、团队、项目联系更加的紧密，而不是成为纯粹的只是接任务做任务的机器一样。
我以前所在的一些公司，基层员工，甚至中层员工，大部分都不了解也不理解公司的方向。比如说要开发一套系统，绝大部分人都是为了实现功能而实现功能，至于怎样做才能更好地达成主要的目标，却是没人会去思考得更多。
明确的职责
在一个团队中，最忌的就是团队成员职责不清，这样不仅会让事情做不好，而且可能还会出现模棱两可、相互推诿的情况。
首先，明确人的职责。在团队里边，各个职位的人员各司其职，产品经理、设计师、开发人员、测试人员等。在大型团队里边，还会有架构师、项目经理等，在小团队里边，并没有设立这么多的岗位。而对于团队管理者来说，又不能事事亲为，那这时候最好就指定谁有更多的一些职责去做一些事情，并且在团队里边跟大家都明确的，不然有些人就会想，你又不是领导，凭什么来管我的东西，产生这种抗拒的心理。比如谁技术好的，就负责架构，跟进团队的项目代码情况等，谁比较喜欢沟通的，可以让他去跟进项目进度与问题等。
另外，同样一个事情不要有2个负责人，这会让事情的推进不那么容易。当然了，对于成型的成熟的团队，职责划分比较明细，就没这种问题。
再就是，明确大家负责的项目，并且在项目里边的职责。一般项目会划分很多模块，不同的人负责开发不同的模块，那么模块相关的问题都要积极去响应，出现模糊不清的问题时，需要由谁来梳理跟进。在项目管理系统当中，每个人的职责也明确清楚。比如产品的职责是管理需求，制定版本计划、创建任务等，开发人员处理任务，修复Bug等。
简单地说，就是让每个人都知道自己该做什么，职责是什么，能做什么，不能做什么，要清晰明确。
规范的流程
一个高效的团队，需要有规范的项目开发流程、测试流程、代码管理流程、发布流程、服务器管理流程等，规范的流程，可以让事情执行得更有条理，并且可以避免问题。
大厂与小公司一个比较大的区别就在于流程，就像是正规军与野战军。正规军从前线打仗、到后方支援，都是有组织有规范的，而野战军则是经常脑袋一拍，我们要干嘛干嘛，所以要想做大，必须要有规范的流程。
规范的流程并不是一下子就能建立起来。在实际的工作中，会不断的出现问题，这时候就要考虑是否制定一些规范去避免掉一些问题。比如我们与ERP团队在对接的时候，由于是跨部门对接，经常会不明确哪块功能该谁开发，谁来跟谁对接需求，时间进度怎么安排等，出现问题大家就会扯皮一些责任问题。针对这些问题，两个部门之间制定了一套对接流程，每次都按流程走。如双方进入正式开发对接之前，先由双方技术负责人、产品经理与业务方召开需求讨论会，明确功能划分，再召开技术对接会，明确对接要点，然后各自估算开发时间并相互通告，如果需求变动应怎样确定，文档怎样对接等等，整个流程每个节点的结果通过邮件通知双方相关人员，对于一些小的需求，可由双方产品经理直接对接。
可能很多人会觉得，流程太多，会带来一些时间与效率的成本，还不如直接吼几下或者直接QQ微信完事。这就需要做一个权衡，并不是所有事都完全严格规范。但是我相信绝大多数的事情都需要有流程去规范。
对于项目管理来说，本身就是一个复杂的过程，必然需要一套规范的流程来让它顺畅地执行。在这次新的项目管理过程中，最重要的部分就是如何去制定一套合理的流程，这也是项目管理的核心所在。
方案实践
在日常的项目开发当中，会有以下一些情况：
- 项目比较多，且都是几个项目并行开发
- 业务线多，业务需求多，且变化快
- 系统模块多，且很复杂，经常一个版本的开发，需要涉及几个项目、几个系统对接开发
- 部分项目版本迭代开发频繁
- 除了版本功能开发以外，经常插入很多需要快速开发上线的功能
针对以上情况，以及以往项目过程中出现的问题，我们把项目管理分为几个过程：
- 需求管理
- 冲刺开发管理
- 非冲刺任务管理
- Bug管理
- 回顾总结
需求管理
我们绝大部分的需求都来自于业务方，这些需求需要经过产品经理的梳理跟进才可以进入项目的开发流程，因而需求就有自己的一套工作流程。
我们创建了需求管理看板来进行需求管理。它使用jira的普通看板模式，并且该看板仅由产品经理进行管理。里边包含了所有的需求，每个需求进展到哪一步，都能清晰地体现出来。
利用jira的功能，还可以很方便地对需求进行筛选。我们利用模块对项目进行业务线定义，在创建需求的时候，指定所属的模块，就通过jira的筛选器定义一些快速搜索的条件。
需求可以分为2类，一类是比较大的需求，比如专题系统开发，它可能需要的周期是2周以上，我们把它叫做史诗级需求或者大型需求，这类需求会进入冲刺开发流程。另外一类是零散的需求，比如会员注册完成后赠送优惠券，可能也就一两天就能搞定的需求，我们把这类叫小需求或者日常需求，这类需求会进入非冲刺开发流程。
以前我们比较缺乏的就是需求文档，主要还是由于产品经理不大愿意去写文档。这次使用了confluence来存放项目中所有的文档，它能很好地跟jira进行链接。可以把jira任务链接到一个confluence的需求文档，也可以直接在confluence的需求文档直接创建jira任务。我们现在都要求产品经理去写一些重要的需求文档，这样任何的任务都可以去查看对于的文档，并且日后回查也是非常有用。
冲刺开发管理
对于史诗级需求（大型需求），我们采用Scrum敏捷开发过程进行管理。产品经理创建好每次的Story，并排好优先级，在需求评审过后，由项目经理与大家一次创建Sprint，进行时间估算，并对Story进行子任务拆分，分配到对应的开发人员。
在jira中，我们新建了一个Scrum Board，所有的冲刺任务都在这里进行管理。在看板中，以Story作为泳道进行划分，在每个Story下面都能看到拆分出来的每个人的子任务，以及各个任务的进展情况。开发人员随时更新自己的任务状态，让大家都知道当前的开发进度。
这样，通过这里的冲刺开发管理，我们可以把需求、版本、开发任务、文档关联起来，形成一个整体，解决了以前开发任务松散零乱的状况。
非冲刺任务管理
对于零散的需求，不适宜去走冲刺过程，那么就按照非冲刺任务管理过程去执行。产品经理定好需求后，可以创建子任务，分配给对应的开发人员，或者直接创建一个任务。
所有的非冲刺类型的任务都会在一个单独的看板进行管理。它是一个普通的看板类型，开发人员拖动任务到不同的任务栏下，从而可以更新任务的状态。
对于这种任务来说，需要的是快速的更新流转，可以由任何人去创建任务，被分配到任务的人，需要及时地去更新任务就可以了。项目经理定期去跟踪各人的任务状态是否及其处理即可。
Bug管理
Bug的管理就比较简单了，主要由测试人员来提Bug，分配给对应的开发人员。开发人员处理Bug，并更新Bug到已修复待测试状态，测试人员对这种状态的Bug进行测试验证是否修复，如果已经修复，则更新Bug为修复完成。
Bug要关联到模块、版本，这样在每个发布版本的信息里边，就能看到每个版本Bug的分布情况以及处理情况。还可以根据模块以及经办人来筛选统计Bug的情况。
回顾总结
在每个月的月末，我们会举行一个月度总结会，其中项目经理会对本月的项目开发情况进行一个回顾总结，大家也可以提出问题，讨论解决方案。产品经理也会对下个月要开发的需求进行一个说明。
在这样一个总结过程中，不断地对我们的项目管理流程进行调整，从而使到整个流程更加的通畅。同时也让大家了解项目开发的情况以及未来的计划。
人的力量
为什么要在这里提到人呢？其实在之前我们的项目管理中，大部分都是靠团队成员自我驱动式去进行任务的管理，并没有一个专职的项目经理，但是实际上人是有惰性的，并且并非人人都具有项目管理相关的意识，而且每个人的任务比较多，经常会忘记去更新自己的任务状态。这样导致的问题是任务要么是堆积在任务栏没有进行更新，要么就是任务信息并没有在系统中流转。
要解决这种问题，还是少不了项目经理的介入或者施加一些强制的手段。项目经理每天会跟进任务的更新情况，并提醒相关人员。在Dashboard可以看到每个人的未完成任务数，以及项目的进度情况，如果任务数比较多，或者项目进度缓慢，那就要去跟进原因了。
这里说下jira的仪表板（Dashboard），这是一个很有用的功能，可以添加很多统计信息，如：
- 【分配给我的任务】： 每天各人在这里可以看到所有自己需要处理的任务
- 【7天内没有更新的还没有完成的任务】： 这里能看到所有在过去7天内没有更新过的任务，用以判断任务是否滞留了，或者忘记更新了
- 【修复完成待测试的Bug】：所有等待测试人员去测试的Bug
- 【未完成的Bug列表】： 发现的所有Bug
- 【按经办人统计所有未完成的问题】： 列出所有人要处理的任务数量
- 【所有创建的任务以及已解决的任务曲线图】： 可以看到创建的问题与处理的问题的对比曲线图
通过这样的一些统计信息，让整个项目任务的流转情况，每个人的任务情况都清晰地展示出来。
总结
在引入这套新的项目管理流程之前，我先去尝试了很久，最后才形成现在的一个流程。或许这还不是现在最好最适合我们的流程，只能是在日后的使用过程中不断地去改进完善。
项目管理，是一个很大的领域，我们接触的只是一些皮毛，相比大公司而言，我们也只是小打小闹。比如网易有自己专门的项目管理研究院，我也听过他们的一些课程，确实专业。希望以后有机会可以学习到更专业的一些理论与实践。