工作计划的制定有几个必要因素的存在——任务、资源、时间。我们总是针对一项或是几项必要的任务来制定计划的;任务的完成总是存在着时间的限制,只是有的比较宽松,有的比较紧凑;任务总是需要人来完成的,不同的人适合做不同的事情。
任务有大有小,我们拿到任务后,首先要对任务进行分解,就是将任务拆分成可以独立控制的细小单位。拆分时按照从大到小的范围,从上到下的顺序进行拆分,粒度拆分的大小可以灵活控制,但是一定要是在控制的范围之内,例如,总的任务时间要求是8天,任务拆分时仅拆分两个任务,分别为4天,这样的任务就不适合在执行中的控制,这种任务我建议拆分到一天的单位,每天核对,及时纠正计划的偏差。说起分解任务,我们时常遇见的问题是如何进行分解,到底要分解为几步?特别是刚刚做项目管理的同事,对系统的有些模块,或是有些业务不太熟悉,对任务、需求到底要如何实现都不太清楚,如何做计划安排,任务分解?我的建议,首先做方案制定的计划,待到方案制定完成后再做方案执行的计划。
如何来做解决方案的计划呢?这里只能提供一些自己的经验。一个方案的制定分为四个步骤:1、需求了解、分析;2、需求讨论;3、系统设计;4、设计评估。其中1、2与3、4可以采用迭代的方式,穿插进行,不要采用瀑布型的模式,一步步的做。作为现场实施人员,一定要记住,需求一步到位只是我们心目中一个美好的幻想罢了,现实你将看到的是不断变化的需求。所以,不要奢望等需求固定好以后在进行设计,在需求成型后就如初步设计,只是设计的不要太细。在进行需求了解时,一般有两个渠道,一个是用户,也是需求的主要渠道,另一个我们不太注意的是来自同业的需求。这一部分用户也会去收集,但是由于公司之间不同的独立性与竞争性,他们收集的时候往往没有我们方便,只有有兄弟项目组的地方,我们就可以收集其相关的需求,或是找QA,或是直接找相关项目组的项目经理。其实,这也是我们最大的价值,让用户体会到我们不可或缺的地方。需求收集并做了分析后,要及时与用户进行沟通、讨论,以检验我们对需求的把握是否准确,是否需要调整方向,同时可同步进行系统设计。这个过程,根据需求的难以程度,需要区分对待,例如,对于多币种需求,我们在收集需求就花费了近一个月,与用户反复讨论了4次,在最终定型。系统设计又花费了近半个月的时间,与用户沟通了两轮,才进入具体的实施阶段;对于发票打印的需求,从需求提出到最后设计方案的制定,也就花费了3天的时间。所以解决方案的制定可以根据项目组对需求的了解程度,兄弟项目组的建议来灵活安排。熟悉的需求时间时间安排的短一些,不熟悉的需求时间安排的长一些。但有两个注意点,一是一定要经过以上四个阶段;二是在需求还不太清楚的情况,不要轻易安排开发计划。
有了清晰的解决方案后,计划的安排就水到渠成了,找到合适的人,在根据任务的难易程度安排好时间即可。在这里唯一需要提醒的是:任何事情都有风险,一定要预留出一定的“风险期”,在操作层面,我往往会在安排两到三天的任务后,会安排一天的时间作为风险期,如果存在问题,还能进行缓冲。当然,风险期不是说一位同事正常的时间安排,使用风险期即意味着任务完成的失败,事后需要进行详细的总结与分析(如果安排了其他任务的情况除外)。另外一点,我们需要面对的问题是资源不足的问题,这是现实,也是在大陆做项目普遍会遇见的问题。这需要项目经理们创造性的来解决问题,将问题进行分解,分批上线,通过拉长处理时间来缓解资源不足的问题,或是将范围尽可能的缩小,控制到能够接受的范围。当然,如果能够说服客户、公司领导补充资源是最为合适的,但这在很多时候只是一种愿望罢了。
在这里很多项目经理容易犯的毛病是对计划安排的过于理想,事前将事情考虑的比较简单,导致计划根本没有办法完成,这样的计划还不如没有计划。制定后的计划如果不能及时完成,久而久之会让用户失去信任,认为你说的话都是打折扣的,二是会让计划失去严肃性,团队成员会觉得反正也完成不了,能做成什么样就什么样吧,慢慢的,也就失去战斗力。所以,做计划一定要慎重,尽量将各种情况都考虑的全面些,对执行人员、用户都是一种负责任的态度与做法。唯有这样,也才能得到用户、团队成员的认可。
有时候往往我们需要在解决方案还不清晰的情况下就要开始进行开发,这样的计划怎么安排?其实,这就在于我们对解决方案的理解,解决方案不可能时绝对的完善,只可能是相对的比较完善。因此,在任何时刻我们都有可能需要做计划安排。只是,我们在做任何事情都需要让项目干系人知道我们能够达到的状态,或是说我们能够将需求实现的怎样的程度,后期将如何来完善余下的内容。总之一点,要提前将我们能够做的,不能够做的,都如实的告诉用户,只有在大家都达成共识的情况下才能进行后续的工作安排。对于这种情况,重点是在后期如何处理遗留的问题。我们经常犯的错误是短时间支持了,后期就不再管了,随着新业务的出现,当前的功能没有办法在支持后续业务的开展,导致用户对系统功能存在较大的意见。所以,一个需求没有处理完所有的问题,就一定要作为一个未处理完成的任务继续处理,直到用户认为可以关闭为止。