一、布置工作还需要学？
布置工作实际上是职场中一项重要的技能，其关乎任务的完成也关系到团队的协作、效率、团队成员的成长。所以笔者想在这里聊聊如何布置工作。
这里针对布置工作几个误区
误区1：布置工作是一项【管理技能】，那布置工作就是管理者的事
布置工作不仅适用于管理者，同时也适用团队中每个人。每个人在工作中都会有协调他人的工作内容以及任务的场景。例如被委派作为某条业务线（某个需求）的Owner、虚线管理、实线管理等。
尤其是当前的环境下，用人单位通常会默认你在一定年龄就要达到一定的位置否则就会被认为是潜力不足。
误区2：布置工作没有技巧，就是把事情讲清楚，把工作分配下去
首先我们要考虑好如何将事情讲清楚，其次将任务讲清楚也不一定就可以将事情做好。还需要有其他配套设施。
例如协调某位同学继续开发你之前负责跟进的需求时，大致要沟通好以下几个方面：
- 需求背景
- 整体的需求、UX稿
- 当前开发进度，开发状态
- 之前评估的时间是否准确？按照当前进度是否可以正常交付
- 项目中、模块中有哪些工具可以使用，可以有效提高开发效率，而不需要重新建设
- 其他角色的接口人都是谁，沟通技巧等等。
- 目前需求中已知的坑点，可能存在的卡点有哪些？
梳理下来我们会发现即使是讲清楚也不是一件非常容易的事。
误区3：布置工作最重要的点是【布置】这个动作
布置工作之后，我们还要做检查、验收确保事情做好了。
小结
所以针对以上误区，我们将布置工作可以划分为三个模块再集合工程师的编码工作聊一下。
- 分配工作
- 布置工作
- 检查工作
二、分配工作
分配工作不只是将一个任务拆解成A、B、C三个模块分配给甲、乙、丙三个人就好了，在分配工作时我们需要以下思考：
- 工作分析
- 人员分析
1、工作分析
重要 + 紧急模型，即很多同学都非常熟悉的四象限评估。
什么是紧急？
- 所需时间VS截止时间 可交付的时间与截止时间越接近，紧迫性越强
- 影响别人的事情 影响的人越多、越关键、紧迫性越强
根据事情的紧急性，决定什么时候做。
什么是重要的事情？【有主观性】
分析工作的重要性时，某些工作对于团队，对于你是否重要
- KPI，JD，OKR 方向的任务最重要
- 改进性工作重要性次一等
- 辅导等工作再次一等
- 内外部需求不涉及以上的还要再次一等
团队工作职责、目标、重点来确定重要。
工作管理的原则
根据事情的紧急性，决定什么时候做
- 紧急的事情：立即做
- 不紧急的事情：计划做
根据事情的重要性，决定花多少精力做
- 重要的事情：认真做
- 不重要的事情：省时做
紧急又重要的工作，不紧急但重要的工作：亲力亲为 紧急不重要的工作：授权干 不紧急不重要：不干
小结
基于以上，我们大致可以总结一下策略
- 重要的事情，自己做或者无法自己做的授权给同学按照计划去做，确定好每个季度、每个月交付的目标；
- 紧急的事情，可以授权给同学立刻去做，最短的时间内拿到结果
关于授权还要学会合理授权
- 自己做重要的事情可以在团队内征求建议
- 授权给他人做的时，要考虑同事的能力，能力较强的同事你信任其可以做好，那么可以自行决策同步结论，能力稍差的同学需要你来做决策，做偏执性的工作。
另外一些涉及到敏感信息的工作，可能又要独立来看了。
2、人员分析
上一个小结是从工作的维度分析要分配，这个小结从人员的维度来分析任何分配。
从人员的维度分析大致有以下几个方面：
- 能力度：擅长哪些工作或者面向未来的潜力
- 意愿度：想做哪方面工作，希望在哪方面成长
- 工作量：工作量如何
以上这几点比较好理解，分配时必然要考虑哪位同学更加擅长哪个方面。例如擅长UI动画的同学，要承担项目较为复杂的UI、动画的开发。擅长性能优化的同学就去负责攻坚项目中的性能问题。
基于能力分配的同时还要考虑面向未来发展，例如要将一部分的动画或者性能优化的工作考虑分配给其他同学，用于培养对这方面感兴趣的同学或者新人。
同时在工作量方面，不能觉得哪位同学能力比较强，工作做的不错那么所有的工作都分配给他，这就造成鞭打快牛了，长此以往快牛也会变成慢牛，最终离职。团队中不能出现能者多劳、拙者不劳坐享其成吃大锅饭的情景。
三、布置工作
布置工作推荐使用GAME原则即：
- GOAL
- ASSETS
- MOULD
- EDGE
1、GOAL 目标清晰
在布置工作的时候第一步要与对方说明白目标这件事，说清楚工作的具体要求。给到的工作目标一定要够具体、可衡量、可达到、高度相关、有时间限制。即SMART原则：
- Specific 具体的
- Measurable 可衡量的
- Attainable 能够达到的
- Relevant 相关的
- Time-bound 有时限的
比如当你从上级那接到了一个工作，需要结合部门产品今年新的战略导向，要求你们全新开发一个产品功能。你接到这个任务后，把任务做了初步的拆分，随后你就喊来组员分别布置后续的工作内容。
如果你是这么表达的："我们又来活了，上面要求我们开发一个新的产品功能。你负责规划这个功能的架构吧，两周后我们一起过一下你的初步方案。"
设想下如果此时你是这位组员，脑海里能出现解决这个工作的大致框架么？想必是不能的。
从SMART原则来看，这个目标有以下几个问题
- 不具体。没有明确工作的具体方向、应用场景以及要解决的用户痛点是什么。新功能是为了提升用户体验、增加产品竞争力，还是有其他特定的目标，组员都一无所知。
- 不可衡量。我们最后衡量这个工作是否完成、完成的好坏？标准是什么？没有给出衡量标准，这对你后续跟进任务，验收任务也会造成很大的麻烦。
- 没有体现相关性。布置出去的任务与最终要达成的工作目标之间的相关性是什么？架构设计对新功能上线的影响有哪些，需要注意哪些核心部分？
2、ASSETS 可用资源
提供可用的资源：如资源整合、盘点为其提供助力。例如有哪些开源的框架可以用，工程中已经存在哪些组件可以直接使用，如果出现问题可以找谁来求助、询问等。
说白了这个工作不是为了难为他，而是要做好这个工作。一定要避免一些所谓的考验心态，前期我就什么都不说，就看你做的怎么样。如果你遇到这样的主管，说明他也不想把这个事情做好，建议你抓紧跑。
3、MOULD 交付模版
确定好格式、相应的模式。如果交付物是一个PPT，那么PPT会有一个模版。如果是一篇文档那么文档的格式是什么也要说清楚。如果要去调研某个框架，那么就说清楚要调研哪方面？例如框架学习接入的难易程度、与现有的框架相比有哪些优劣势等等。说清楚要交付哪些，比让对方猜要高效的多。
这里千万不要认为某项工作都是既定流程，不需要额外说了。这在实际上可能是经验主义错误，即理解和执行出现了较大的偏差。所以在布置时一定要明确说好交付物。
4、EDGE 行为约束
确定权限边界，例如哪些信息是可以直接使用的，哪些是需要申请的。什么时间点需要汇报确认进度，有风险要及时同步等等。
四、检查工作
如果一个工作布置之后就不再管了，那么大概率这个工作会做不好。所以在布置工作之后，就要约定好何时交付？具体交付哪些？何时这份工作要达到一个什么样的状态等。
1、共同计划
首先确认对方是否理解了，可以先讲对这项工作的理解，然后让其制定一个完成目标的计划。
针对能力高的员工
- 可以自己评估困难和风险
- 讲述自己的规划
- 自己制定详细计划
- 你只需要检查他的计划、与他约定检查节点
针对能力低的员工 要引导他进行工作难度评估、复制他计划执行
- 询问他准备如何做？进行做法、要点以及风险的描述和补充。
- 详细检查计划以及员工的理解。如果可执行，就让员工去做，如果不可以就继续辅导
- 最后约定一个密度较高的检查节点
2、建立控制系统
控制什么
- 控制什么：控制点（什么地方需要控制）
- 检查什么：指标（这个地方需要控制什么？用什么指标监控）
- 什么标准：标准（这个指标应达到什么标准）
定期检查
- 约定检查时间：确定具体的时间节点和频率，必须做到按时检查
- 约定检查内容：动作和结果 数量与质量 不定期检查
- 不定期询问
- 平时观察（走动式管理）
假设在实际工作中我们需要做一款微信 App，那么面对这样一个非常复杂的工程，我们在开始开发之后必然要设计几个检查点，或者叫里程碑节点，规定好每个里程碑节点的交付物。
- 节点1完成App基础架构搭建（服务端输入协议）
- 节点2完成P0、P1级别UI开发
- 节点3完成与服务端联调P0、P1业务联调成功提测。
- 节点4完成P2业务开发
每个节点确定好交付物之后，就可以设立响应的检查标准了。例如节点1封装性、架构设计；节点2的UI还原度；节点3检查业务逻辑Bug等。这些都是定期的交付节点，不定期就依赖个人的习惯了。
纠偏与反馈
任何工作都有可能出现差错，很多时候是避免不了的。所以在整个工作链路上我们也会有纠偏的机制。了。
例如节点1交付之后发现架构设计不满足当前业务所需，使用的框架面对复杂的业务灵活性不足，此时趁着上层还没有开发过多的业务，及时纠正还来得及。
例如节点2交付的UI还原度不符合预期，设计师在检查之后会反馈出来，那么开发同学也要提升一波还原度
五、总结
以上我们均是以主管为主体，作为组员本身当知道以上原则之后，也能用于反推工作的进展，例如主管布置一个任务，但是语意不详，你就可以按照上面的信息依次去确认。
以上简单聊了一下如何布置工作，并结合工程师的方向举了几个例子，希望对读者能够有一些启发。