题目想了很久，但是自己却没有勇气来写出来，怕自己还没有想好。如果后面还有补充，就另起篇章吧。
缘起要写这个，是因为今年夏天做的一个需求，我作为TE的角色参与，有需求来源，有方案细节，有DEV开发分析，有QA测试验收；我们项目组总是这样分配角色的，还没有参与其他项目，所以以我现在目前的认识，这样的一个搭配是可以满足需求开发交付的。这个需求从评审到最后交付，持续有近小半年的时间，时间跨度确实不短了。
从人员配备上看。需求和方案来源同一人，该同事我认为是同行里面水平比较高的，而且自开始到需求交付，需求和方案考虑的都很完备，虽然过程中有修改，但是大的方向没有变化，可以指导开发和测试。固定开发人员三人，其中一人资深经验，经常作为项目中解决疑难杂症的，开发经验自然没的说，另外一个人虽系新员工，但是上手极快，也不涉及开发质量差的导向，还有一名前端开发人员，也很有经验。QA，这一块是我想吐槽的部分，虽然年龄已经不小，经验有，但是没有总结；我始终认为该QA和我是要为这个需求的交付质量差负责的。整个人员配备，QA和我是整个环中能力较差的一环，应用木桶理论，事情做不好是有原因的。QA测试，对问题跟踪不到位，验收过程中也仅仅邮件告知下问题，更加随便的是有的问题仅仅口头告知下开发人员，导致很多实际验收过程中发现的问题也泄露到了后端测试；在还没有理解需求的前提下就进行测试并写自动化，导致写自动化过程中很多问题都是边学习边请教边尝试，这个方面也导致了时间跨度很大；没有主动提过是否要添加测试用例以及检查项，会让人认为QA也仅仅是为了完成测试，而没有为质量负责的味道；测试过程中不按照用例来，想怎么测试就怎么测试，没有依据。我的问题，前期跟踪需求是没有理解需求是什么，这当然是很大的问题，也是跟踪需求中最关键的一个问题；对需求的流程没有理解就把测试策略评审了，导致测试用例并没有如期的高质量，那后面的测试就更不要说了；对需求的交付阶段没有明确，这个需求还是比较大的，肯定要分阶段交付，但是在需求做的过程中，并没有和需求作者以及开发勾兑好，导致需求范围不明确；对人员的认识不足，比如针对QA这样的情况，应该在功能做出来后与之一起看下是否可以满足要求，虽然中间也有看过功能的实现，但是并没有上心；测试用例的检查项没有明确，到底应该检查到什么程度才算通过，检查什么，还是说界面返回成功就可以了。
从与外部交互来看。与用户联调过程还是比较顺利的，按照计划行事，唯一不足的是用户端也没有稳定的版本与我们做的需求联调，导致后期要验证我们的功能时还要等待用户。这一层面上，对需求做了这么长时间但是还没有做好，并不需要负责。
从需求交付上看。目前还没有统计过这个需求交付后的bug数量和波及，但是从目前用户使用和同行反馈来看，基本的流程没有问题，问题来源多是（1）界面交互；（2）需求；（3）流程细节。界面交互当时也没有定具体的验收规则，但是基本的界面规则也不明确，导致很多界面的尝试问题，比如缩写应该怎么显示，界面组件之间的联动，中英文对照；流程细节上，后面还出现了很多问题，比如服务端数据库没有入库，交互过程中出错等等；需求中间有过改动，都属于优化类的，但是都没有经过测试就发给用户了。
想了这么多，最主要最复杂的原因还在于人身上，尤其是能力达不到要求时应该怎么约束并指导工作就尤为重要。花了这么长时间做事情，还是没有做好，原因总结来看有如下几点：（1）问题跟踪没有闭环；（2）流程理解不透彻，没有想明白就去做了；（3）任务进度跟踪不及时；（4）做事没有依据，通过准则是什么。
