项目微管理8 - 流程
Posted 一名技术宅的管理经
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了项目微管理8 - 流程相关的知识，希望对你有一定的参考价值。
流程可以说是非常惹人讨厌的东西了，四代见过太多的公司实行的繁冗的流程了。
为了办一件事，要走太多的步骤，效率低下不说，最终还会形成一种叫“官僚作风”的习气。这种如同癌症一样的顽疾不断毁灭着一个又一个的团队。那么没有流程不就行了！大多数创业团队如是说。
创业团队也需要流程吗？
从四代的经历看来，不是创业初期没有流程，没有流程大家怎么合作呢？
创业初期有的是流程，只不过没有书面化而已！仅仅是没有书面化而已！比如，什么时候规划，什么时候测试，什么时候发布，怎么解决问题，怎么响应反馈，哪一个不需要一套对应的流程？
只不过创业初期人比较少，当面交流就可以了，不需要一套书面化的流程。而书面化的流程应该在团队磨合到能正常产出的时刻起，就应该书面化作为正式的团队文档，这样由于有了个正式的开始，当创业团队逐渐壮大，人数越来越多的时候，就可以不断的充实和调整这个流程，让它随着团队的成长而成长。
这就是即使PC团队目前只有两个人，四代仍然坚持要创建团队工作流程的初衷。
版本发布流程
研发团队最主要的流程应该就是版本发布流程了，也就是常说的Release流程，她真正的描述了每个版本完成的基本工作，包括完成的内容，完成的时间，完成的标准，对紧急情况的处理等等。
在经过数次的修正和调整后，四代的团队目前试着实行的版本发布流程如下：
需求收集
流程的起点是收集本次版本需要完成的需求列表。收集需求可以说是软件工程中最难搞的一部分了，偏偏它们还是软件研发后面各个步骤的基础，俗话说的好“不满足客户需求的软件都是耍流氓！”。
不过对PC团队现状来说，这件事又不是什么困难的事，因为PC软件的研发停滞了一个阶段，客户对软件的需求早就堆成了小山。
四代需要做的就是将这些需求整理一下，结合软件的现状，给它们设定好优先级和顺序。不过为了应对一些紧急的需求，四代还是增加了一个环节：需求收集阶段。
在需求收集阶段，四代会面向全公司成员，包括研发人员，测试人员，设计人员，客服和市场，发布征集软件本次研发功能的建议，也就是从所有人那里收集一些客户紧急需要的功能。
这个阶段不是必走的步骤，当四代觉的这个版本的功能研发任务已经足够紧急的时候，就不会发布这个公告。不过四代还是觉得，正常情况下每个版本计划的第一件事就是发布这个公告，这样能保证研发不会偏离客户太远，这个太重要了！
当然了，这种做法也有个不好的地方，那就是需要各团队所有人配合，坦诚的发表自己的想法。
这个似乎有一些难度，因为沟通几乎是每个团队最难的事了，何况还是跨团队，人家理不理你还是个问题呢，那还谈得上配合。所以实际操作的时候，四代都是拜托各个团队的直属经理，让他们帮忙收集，效果还是会好一点点，不过大部分时候，也可以忽略不计。
上面这个环节主要是对外的需求收集，紧接着就是对内需求收集的环节。结合目标管理的理论，这一部分需求的收集包括三个部分：产品经理的需求，他代表公司，项目经理的需求，他代表团队，团队成员的需求，他们代表自己。
需求筛选
收集到需求后，接下来就是需求筛选了。
这个不用多说，四代自然是需要先按照优先级排好序，再根据规划的Release的时间的长短选择合适的需求。
经过多次的试验，四代觉得一个Release在10个周左右对PC团队比较合适。在这个时间中，真正用于编码的时间是4周，其中还包括1周专门用于修复比较严重的Bug。其余的6周包括测试，发布，紧急情况处理，小版本处理等。正常情况下，需求筛选就可以按照这个时间来。
编码开始
需求筛选好以后，就是团队成员自行领取任务了。
接着，四代会和团队成员一起把自己手上的需要设计的任务设计一下，并组织项目所有相关人员举行几次会议，把这些设计过一遍，需要的调整的就调整，达到大家对所有这些的需求的理解是一致的。
虽然事先大家不可能想清楚所有的细节，不过认真的思考总是会为大家带来一个好的开端。在开发的过程中，还会发现很多新的细节，不过没关系，设计从来不是死的，设计从来都需要一个良好的起点，然后在此基础上不断演化。
在编码的开始阶段，四代会和团队每个人把他们的任务细分到可以每1-2天都能提交的程度，这样可以很方便的控制任务的进度和时间分配。
在编码的过程中，四代唯一强调的就是代码规范，这是四代的底线。做不到的人，四代会试着了解做不到的原因，并提供适当的方法帮助其做到。在四代帮助下仍然做不到的人，四代也绝不姑息，四代应该会马上进行劝退，不过到目前为止还没有发生。
进入内测
编码完成以后，就是PC团队内测了。
这一部分测试全部是围绕新功能和修复的Bug展开，毕竟把一个漏洞百出的软件交给测试人员测试实在是丢人的一件事，所以四代会带领所有开发人员全身心投入到内测中。
由于开发人员对代码十分了解，一般经过一定时间内测和修复后，除了一些不易修复或者不是很严重的缺陷，大部分主要流程中的缺陷都会被修复。
当然了，这是理想情况，在后面实行的过程中，还是出现了在开发时间很紧的情况下，内测做不好的情况，这是四代需要思考和调整的，四代需要顶住来自各个方面的压力。
集成测试
再接下来就是开发人员和测试人员共同参与的集成测试了。
集成测试是最重量级的测试，目前都是手动执行的。
集成测试的第一阶段和开发内测的目标是一致的，就是保证新功能和修复的Bug工作正常，发现问题就评估，然后根据重要程度修复。
第一阶段测试结束后，第二阶段就是全面的测试了，说白了，就是软件所有功能的测试，非常辛苦而且枯燥，但是又不得不做。
这一阶段测试内容非常多，包括软件所有功能的测试，各种版本的测试，各个平台的测试，用户真实数据的测试，大数据量的测试。这些固定的测试内容很多也是后面自动化的目标。
第三阶段是探索型测试，说白了，就是无限制测试，也就是脱离测试文档和常见的套路，完全不按常理出牌，执行一些不合理的操作，测试软件的稳定性。
这个测试三板斧非常重要，它们结合起来基本做到了对软件全方位的覆盖，所以也是非常耗时的过程。经过几次的试验，这些测试的时间平均都在3周左右，和编码时间也差不了多少了。
四代相信，只要成本允许，测试多花点时间，收益总是正的。
发布标准
为了便于划分测试的优先级和重点，四代把软件的所有功能分成两类：核心功能和辅助功能。核心功能指的是最为核心的资源管理模块，辅助功能指的是登录，注册，人员管理等模块。
四代和团队决定是否发布软件的标准：就是在当前版本中，核心功能没有1级的Bug，辅助功能没有0级的Bug。
所谓0级Bug指的就是不修复软件就不能使用，或者用户强烈要求修复的Bug。而1级的Bug指的是不修复该Bug的话，软件用起来不方便，但是有方案可以替代的Bug。所以PC软甲发布的标准简单来说就是当前版本没有0级Bug，核心功能还不能有1级Bug。
无奈的审核和收录
测试以后发布就比较固定了，就是加密打包，然后拿到各大流氓的软件管理中心进行审核和收录。为啥叫“流氓”呢？大家都懂的，卸载又卸不干净，不认识的软件就报可疑，或者是直接杀掉。针对这件事，四代与鼬已经不记得与他们交涉过多少次，费了多少唾沫星了！
收录成功后就发布升级包，客户端软件检查到升级包就进行升级。
发布后的事
发布以后，如果有一些紧急的问题，然后就是2周左右研发小版本的时间。
小版本的测试比较简单，基本都是根据代码的修改范围，划定测试的功能范围，有重点的测试一下，然后再测试一下核心流程就可以发布了。
发布成功后，接着就是团队面对反馈和进行反思的时间了。
这个部分怎么强调都不过分。因为不接受反馈，不进行反思的团队就像一潭死水一样，永远无法成长为成熟的团队，所以四代无论多么忙，多么没时间，在发布后都会找时间完成反馈反思会议。
团队功能的细化
在后面的实践中，随着专业的产品团队和设计团队的成立，产品的研发细节也在不断的调整中，很多需求方面的事情不再由开发团队完整的负责，而是有了专门的团队去主导。这样有了专门的分工，产品更加专业了，但是总体上说，这一套流程基本还是没有太大的变化。
好吧，整个过程和大部分的敏捷过程都差不多，确实也没有什么太多的奥秘在里面。如果非要说奥秘的话，那就是参与度，四代不断尝试在各个环节中增加团队成员的参与度。
当然不仅仅是在研发流程中，四代还有一整套的方案来在各个方面提高大家的参与度，所以，即使是流程，也是和团队的其他方面息息相关的，并不是孤立的存在，比如说与产品质量，就是密不可分的。
说起质量，很多人都会立即表示无语，甚至激进的测试团队会当开发人员的面，大声骂娘。唉，测试的那帮妹子也不容易哈，四代想。
以上是关于项目微管理8 - 流程的主要内容，如果未能解决你的问题，请参考以下文章