各位已经躺平了嘛？如果还没躺平那就再起来学点新技能？
职场，不能永远只做一个螺丝钉不是，学点进阶技能，争取早日当老板。
下面我们讲一下如何做任务分析，做一颗有思想的螺丝钉。
规范 的有条理的任务分析和切分会减少开发时间和BUG
开始学习任务分析之前，我们先来聊一下工作方式，好的工作方式，是功能技能的基础。
什么类型的工作方式
当有一个任务被分配到你手上，需要你来完成的时候，你通常是什么样的工作方式呢？
- 直接开始开发，先写为敬
- 想想实现思路，然后开发
- 思考应用场景，从用户的角度分析使用情况，了解所有使用场景之后再开始开发
针对上面列举的三类情况，我的个人建议是：
要避免使用为第一种方式。 原因其实也很好理解，完全不经过思考直接开始工作，可能都没有完全理解需求，大大的增加返工和出现问题的可能。而且，这种方式非常不利于个人成长。
学会转变第二种方式，只思考实现方式是典型的从解决问题的角度直接切入问题。但是，这种方式的弊端就是看问题的角度不够全面，容易遗漏用户场景。
学会使用第三种方式，从用户的角度来思考为什么会有这个需求，用户存在的使用场景是哪些，梳理出来所有的使用场景。之后再开发。
在一个任务开发之前都思考什么
我理解对于大多数程序员来讲，可能在开发一个功能之前不太会思考太多关于这个需求的非功能性的问题。但是现在我想要表达的是，如果你想提升自己的职场竞争力就需要花时间在这些非功能的问题上。
为什么会有这个需求
大多数情况下我们做为一个任务的执行者，并不会思考为什么会有这个任务。
但是我希望大家从下个任务开始要问一句为什么会有这个需求。
要从业务的角度来切入问题。
- 用户的使用场景是什么样的？
- 用户为什么会有这个需求？
- 这个需求是不是用户的真实需求？
在彻底搞清楚需求背景和用户场景的情况下再进行下一步，看上去占用了开发的时间，但是实践中你会发现会提升开发效率和减少返工以及问题。
从使用场景到测试用例
在理解了业务背景和用户使用场景之后，我们理清楚的是什么？
是用户如何为什么要用这个功能和如何使用这个功能。
这时候我们最自然能得到的东西就是用户操作软件的使用逻辑，各种使用逻辑合起来也就是测试用例。
从测试用例到开发方案
当获取到全部的测试用例之后，也就意味着我们明白了所有的功能点和边界条件。
基于梳理出来的功能点和边界条件再制定开发方案和开发计划。
这时候再来实施开发，虽然从开发时间点上来看是晚了，但是会大大缩短开发本身占用的时间。
如何切分任务
使用"Process"来定义测试用例
其实上面的文章内容已经简单的介绍了如何切分任务。简单来讲就是从用户场景出发，按照用户使用流程进行功能分割，然后结合架构，业务总结出完整的功能。
举个例子：
User Story: 作为一名用户，我想要浏览商品列表。
所以，从这个User Story出发，我们能够写出AC。分别是：
- AC1：在页面展示商品，每页显示15个。
- AC2：如果没有商品，显示当前无可用商品。
通过上面的AC， 我们分析出用户使用场景。
AC1：在页面展示商品，每页显示15个。
- Case1:如果商品多余15个，展示15个商品，并且可以翻页到下一页。
- Case2:如果商品少于15个，在当前页面展示全部商品。
AC2：如果没有商品，显示当前无可用商品。
- Case1:展示"未发现可用商品"
所以，我们从用户的"我要看产品列表"，得到了三种情况"多于15个需要翻页"，"少于15个直接显示"，"没有就展示没有"。
这样，我们就能够在开发开始之前清楚需要开发的所有功能点。避免出现有一些需求是开发过程中才意识到。
当然，我举的例子非常简单，我们在实际的工作中遇到的需求往往复杂很多。但是我想要表达的是这种任务的分析方式。
先了解你的用户，再分析使用场景，再产出开发计划。
Mien, 7年前端开发经验，1年管理经验，目前就职于SLB，任职Team Lead。
涉猎范围： Angular, Vue, React, 小程序, Three.js, Cesium.js, Babylon.js, electron, Taruri, nodeJS, Rust以及一些乱七八糟的技术 欢迎留言提问和指正。