原文链接: https://dsx2016.com/?p=683
微信公众号: 大师兄2016
一定要记住,提升效率的方法不是锻炼自己所谓的意志力和倡导执行力,以长时间鏖战任务为目标获得胜利,而是将一个庞大的复杂的或者仅仅看起来不可战胜的事物合理的拆解为一个个小事物,然后分而治之.
工作项目
程序员经常会遇到以下问题:
-
项目开发前评审,领导或负责人要求估算出开发时间
-
节前上线,按照指定时间完成任务,酌情添加人手和资源
无论哪一种形式,都不容易按计划完成任务.
造成这一现象的原因有很多外在因素:
-
估算少了,加班加点也干不完,一开始时间就限制了你的任务,越紧凑越混乱.
-
估算多了,不仅让项目经理不愉快,也一般也不会给你足够的时间.
扫描二维码关注公众号，回复： 9114412 查看本文章
-
不熟悉的任务,难以估算,开发到一半,发现实现不了和推倒返工都是一个大坑.
老板关心的是一个项目从开发到交付需要多长周期,以结果为导向,不关心过程.
你需要给出一个结果,但并不意味你的思维模型也是一样,我们应当从业务上估算.
将抽象的概念具现化,将笼统的目标分解化,将冗杂的任务流程化,最终估算出项目周期.
任务分解
任务分解,也叫目标分解.
就是把一个大的任务拆分成一个个具体的,清晰的小任务,各自独立,又互相关联.
通过解决这些小任务,最终完成被分解的大任务.
事实证明,大多数任务都可以被分解为更小的任务,将复杂的拆分为简单的.
大任务容易给人带来沉重的心理负担,还没有开始,就产生畏惧和颓废心理.
编写一个完整的应用程序很困难,但是写一段代码就简单的多,然而现实中要交付的就是完整的应用程序.
WBS
Work breakdown structure为工作结构分解.
我们将手头的项目按照一定的原则分解,如将项目分解为任务,再给任务分配时间,最终分发到各个负责人身上.
WBS可以完成的事物
-
将项目分解为已知任务,模块化,流程化
-
给任务设定具体时间和指定责任人
-
对项目的成本和进度实现跟踪记录
-
对每个子任务和最终目标进行确认
WBS是制定进度计划、资源整合、风险控制、成本预算和人力分配不可或缺的一部分。
如何分解
分解并不难,难的是当我们遇到大的任务时通常是立即怯战或开干,不会主动意识到先去拆分.
假如要写一本书,那么要做的不是每天嚷嚷着我要写一本书,而是先分析书的构成.
书籍可以理解为多少文字构成,描述了哪些内容和信息,可这些大而虚泛,没有多少实际指标参考.
书籍为书名,封面,目录,序言,章节等组成,要想写一本书,先得构思一个主题,其次想一个书名,再编排一个目录,然后开始写章节内容,最终完成封面和书籍制作,出书.
即使你自己没有意识到需要分解任务,也仍然会受限于行动的时间线发展,也就是想要完成A,必须先完成B,以此类推.
当你试图把大任务分解为小任务时,你得先明白它是由什么构成.
如开发一个应用程序,它的构成为用户模块,商品模块,支付模块,订单模块,消息模块等等等.
用户模块又由注册模块,登录模块,权限模块等组成,注册模块又可以分为手机号注册,邮箱注册,用户名注册等模块.
把一个大的单元拆分为相近的小单元,小单元继续分解为更小的单元,直到任务分解的足够小,足够简单,足够到我们一眼就能估算时间和开发难度等.
有什么用
1.估算时间会更加精准
估算一个完成的应用程序,可能是三周,也可能是三个月.
这样的时间摆动太大,不确定性越大,意味着项目的延期率和失败率越高.
但是通过估算一个个小模块,如登录模块用时多长,支付模块用时多长,最终可以获得一个更为精确的时间值.
这个估算时间仍然不会准,但是摆动周期可以从周变为天,前后三天的摆幅还是可以接受的.
2.任务难度分析更加明确
项目开发总会遇到不熟悉的业务场景,面对陌生的需求难免忐忑不安.
通过任务分解,可以拆分出熟悉的部分和陌生的部分,陌生的部分可以查找资料和通过学习来针对性的解决.
只要明确问题,总能找到解决办法,即便找不到,也至少明确问题出在哪里,可以考虑换一个方案等.
3.大局观,全局观,流程化
普通人只会拥有自己的视角,很少从管理者视角和对方视角看待问题,更别说从全局视角看待问题.
如果要做任务分解,必须要先从全局看待问题.了解任项目的构成,了解每一个任务之间的关联.
要掌握足够的信息,掌握足够的资源,了解每个责任人的能力和职责,懂得协作和取舍.
4.数据化,可视化,具现化
完成这个项目的时间成本,资源成本,人力成本都可以通过分解获得精确的分配和追踪.
有助于及时跟踪项目的进度,完成度和完成质量,便于及时改进和优化,有良好的反馈.
