高质量的完成 需求 研发，做一个靠谱的 攻城狮

3w.jpg

大家看图说话，记好 what when how 的 3W 原则

下面讲讲实际的案例

先说重要的（有关生死存亡和自身名誉的）

1. 关注线上质量

这一点非常重要，但又是容易被忽略的一点。需求发布上线，是个重要的里程碑，但并不意味着需求的终点，还得时刻关注以下事项：
功能是否正常运行？

各项指标是否正常？比如产品上报数据、性能监控数据、错误监控数据等。
有哪些可以优化的点？优先级多高？
。。。

只管功能开发，一旦需求上线，立刻做甩手掌柜，同样是缺乏责任意识的表现。试想一下，如果你是团队的老大，你会放心把重要的需求交给一个“甩手掌柜”吗。

2. 严控开发、自测、提测质量 （这样一旦有问题，才有理论的资本）

严格要求自己，才能让人觉得靠谱, 不要以为讨好别人大家就会重视你，真正的靠谱、能扛起大旗大家才会重视你

作为一名合格的前端工程师，对自己的开发质量负责，这是最基本的要求。

要时常问自己：

开发：是否严格按照需求文档完成功能的开发。

联调：在与后台同学联调前，是否已经对照测试用例，对自己的模块进行了严格的自测。

提测：提测前，是否已自测、联调通过；测试正式介入前，产品是否提前部署到测试环境，并进行初步的测试环境验证测试。

严格把控开发、自测、提测质量，这不但是能力，更是一种负责任的态度。如果能做到这点，不单节省大家的时间，还可以让其他人觉得自己比较“靠谱”。

3. 工作时间评估不足肿么办

比如你作为前端开发一个功能 评估了3天的开发工作量。等到开发的第2天，发现之前工作量评估少了，至少需要4天才能完成。

这个时候，该怎么办呢？

相信不少同学都是这样处理的：咬咬牙，加加班，4天的活3天干，实在完不成了再说。

这样处理潜在的问题不小：
给自己增加了过重的负担。
没能让问题及早的暴露解决。
可能打乱项目的整体节奏。

更好的处理方式是：及时跟项目组成员同步风险，并落实确认相应解决方案。比如适当调整排期、砍掉部分优先级不高的功能等。

4. 怎样推动解决问题 显得自己逼格高一点

比如 小 A 同学 需要小 B 同学的接口，然后 开发或提测 过程中出现了不少bug，对于小A来说，该怎么办呢？这里分两种情况：

bug主要是小A的。
bug主要是小B的。

第一种情况很简单，自己的坑自己填，抓紧时间改bug，并做好事总结，降低后续需求的bug率。

第二种情况呢？如果小B比较配合，主动快速修复bug，那没什么好说的。但万一不是呢？

遇到这种情况，小A可能会想：“又不是我的bug，干嘛操那份闲心，需求如果delay的话，那也是小B的问题，跟我无关。”

可能不少同学的想法跟小A一样，这在笔者看来，略显消极，处理方式显得不够“职业化”。

为什么呢?

同在一个项目组，得要有团队意识、整体意识。需求延期，首先是所有需求相关人的责任，是要一起打板子的。然后，才会对具体的责任人进行问责。

那怎么办呢？ 嘻嘻，这个问题证明你已经进步了

回到前面的场景，小A更好的处理方式是：做好沟通工作，主动推进问题解决。

了解小B没有及时改bug的原因：有可能太忙、bug不好改、没有意识到那是自己的bug。

如可能，提供必要帮助：比如跟项目经理申请，这段时间小B集中精力改bug，暂不开发新需求

风险同步：如果小B真的不称职，尽快知会项目负责人，对小B进行批评教育，实在不行就换人。

其次聊聊怎么严格把关

1. 怎样接到比较合理的需求 (就是what 想表达的意思)

没有绝对明确合理的需求，因为大家都是人嘛，你要求 100%的 明确需求，那产品理所当然的要求你没有一点 bug , 啊，这个世界还怎么合作呀。

假设现在有个论坛的项目，产品经理小C提了个需求 “给论坛增加评论功能” 。作为 前端工程师 的小A接到需求后，该如何高质量的完成这个需求。

可能有同学要拍案而起了：Are you kidding me？不就加个评论功能吗，我还能不知道该做啥？

答案很残酷：是的。

根据过往经验，不少前端同学，包括一些前端老司机，做需求的时候，的确不知道自己究竟要做什么。导致这种情况发生的原因有哪些呢？

产品经理：提的需求不明确。
前端工程师：没做好需求确认。

• 情况1：产品需求不明确
  说到产品需求不明确，前端的兄弟们估计可以坐一起开个诉苦大会，因为实在太常见了。典型的有“拍脑门需求”、“一句话需求”、“贴个图求照抄需求”。

  回到之前的例子：给论坛增加个评论功能。

  别看连原型图都贴出来了，其实这就是个典型的“需求不明确”。比如：
  是否需要支持富文本输入？
  是否需要支持社会化分享？
  发表评论后，评论怎么展示？

• 情况2：未做好需求确认
  再次强调一下，无论何时，一定要做好需求确认。再有经验、再负责的产品经理，也几乎不可能提出“100%明确”的需求。

  同样，回到上面的需求。

  现在已经确认了，需要支持富文本输入、需要展示评论，这就够了吗？其实不够，还有很多需求细节需要进一步确认。比如：

评论最大支持输入多少个字？（非常重要，关乎后台存储方案的设计）
1个中文算1个字，多少个英文字母算1个字？（产品语言、技术语言 之间的沟通转换）
输入内容过长，如何进行错误提示？（交互细节）
输入内容过长，是否允许提交评论？如允许，是对评论内容进行截断后提交？（容错）
用户未输入内容的情况下，评论框内默认提示文案是什么？（交互细节）
。。。

可以、需要确认的内容太多，这里就不赘述。

看到这里，读者朋友们应该明白，为什么前面会说，几乎不存在“100%明确”的需求。

很多需求细节，同时也跟技术实现细节强相关，不能苛求产品经理都考虑到。这种情况下，作为开发者的我们应该主动找出问题，并与产品经理一起将细节敲定下来。

2. 怎样 把控时间 （看看 What 怎么说的）

一个同时有前端、后端参与的需求，精简后的需求生命周期，大概是这样的：
需求提出-->开发-->联调-->提交测试->需求发布

要得出一个靠谱的完成时间，至少需要明确以下内容：
前端、后台 各自的工作量。
前端、后台 投入研发的时间点。
前端、后台 联调的工作量、时间点。
需求提交测试的时间。
需求测试的工作量。

最终，需求的完成时间点可能如下：（跟预期的出入很大）

640.png

• 下面聊聊 怎样 确定时间

  首先 很重要的是 自己心里 一定要有 开发质量的底线

  在 产品提出的需求上预计开发时间，总有时间和需求冲突怎么办

不要委屈 自己，这样不会有好结果的。

• 时间固定 需求。

• 刚性需求加时间

• 告诉他们质量才是 第一大关

做不完就提出来大家一块商量怎么办（一定要保证心底的开发质量）。不要委屈求全，也不要咄咄逼人

.