一、需求理解：
在评审阶段和需求确认阶段需要足够的理解需求，提出质疑反复改善。实现方法、存在的技术难度、不可预测的问题。
需求怎么去理解？三个w：why、who、where
为什么这样做？
谁需要这么做？
需要做在哪里？
其次就是逆向流程，逆向流程没有公共的标准，需要自己擅长总结和推敲。
能够告诉你的是，一个流程的反向对应的事态是什么。
登场成功，反向对应的就是登录失败（断网、密码错误、验证码错误、验证码刷新不了…），这些都是对需求理解很重的一个思考维度，不能只单纯的认为走通了就等于走通 了。
（1）实现方法什么？
实现方法是觉得你们大概需要花多少天时间来做，在你脑海里需要想象可以量化的工作过程，例如改一个页面，你可以想象你需要做些什么步骤：浏览代码、找到css样式、浏览设计稿、改动样式、微调...那我大概会花多长时间做？，2小时？3小时？8小时？还是1天2天？在你的心里需要呈现一个模型，它是你工作进展的一个“底气”。
（2）存在的技术难度？
关联到你是否已经十分清楚业务的流程，如果你足够清楚那么你肯定已经在思考这个玩意怎么实现，它是不是你的知识盲区。不是，那就依照你以往的经验去判断，来评估消耗的时间。是，那就再次量化，怎么量化？其实无非就是两种结果，实现了，和没实现。
实现了：我不知道花多长时间能做到，所以这一项需要验证，验证就需要时间来推移，就必须在介入开发前去收集实现方式、参考文献、验证方案。
没实现：没实现了应该怎么办，我没把握啊，能不能跟产品说砍掉这块功能？要去和团队沟通，谁做过，谁来解决，无论任何事情当你无法解决的时候就向上汇报，告诉产品，这个我们没把握，可能会导致延期。产品经理就一定会带着问题去解决，你们不需要做什么，等着产品经理的结果就行。
（3）不可预测的未知问题
什么才算不可预测？当你走进一个乌漆麻黑的房间，你看不见任何东西。这就是不可预测，简单来说，当你去改别人代码，你就知道你要进到一个乌漆麻黑的时间。你知道这里面肯定会有很多坑，但是你不知道到底坑在哪。那么你接手前就应该去花时间从新熟悉旧代码对接方法，他的写法。来把不可预测尽可能多多转变成可预测，把不可控尽可能转变成可控。
最后，你就会得出你最终的一个正常8小时/每天的开发时间（不含测试）。剩下的就是排列优先级，哪些先做哪些后做。
二、Review
给一个项目拆分任务阶段，每做完一个阶段，或一个任务，都要对自己进行Review（复盘）
是不是存在漏洞？
这项代码足够优化吗？
这个bug会不会其他人也会遇到？
等等…
写下来，记在笔记上，带上你的解决办法。
在你Review完上一个你完成的任务，下一个任务你要重新审视他的需求，以及你需要完成的时间，对其进行二次理解和评估。这样你就知道在你时间开发过程中，你为什么当初评估的时间和现在的你时间开干时的评估时间出现差异，是你哪一步错了？那么在你下一次评估的时候你对风险就有了认知，也能及时的向上汇报，告诉产品这个东西我可能要延期了。
每做一个模块或任务，盯着文件（需求、设计图、原型等）去思考几分钟。
三、项目进程过程中的颗粒度
你的团队或者你，是适应快节奏还是慢节奏？
有些人写代码1小时，喝水上厕所半小时。有的人，一次弄完，休息5分钟，玩玩手机，继续弄。每个人对节奏的把握都不一样，你需要对自己的团队性格、做事方式有比较好的理解，考虑他们的个性问题会对项目产生什么影响。需要做到这种精细化，因为我们不能只看结果 ，结果不会给我们带来好处，结果只有输出2种，要么好要么坏。所以我们必须针对团队成员个性来给他们下达任务和指标，要靠过程推进而不是结果推进。
网友评论