|
这个周末和嵌入式同事待在一起赶一个项目，和他们沟通的过程中发现我给出的计划内容太粗略了，以致有些事情到最后才想起来需要相互协助完成；还有任务的进度，最初的一版是要求12月底，但已经延期半个月左右时间了，我也没有相应的调整。 想起在项目刚开始阶段，我就在想着如何制定实施细节。现在想想这是犯了一个典型错误，在实施之前应该计划出完成一件工作的全部细节。因为这个产品开发由许多不同的人来完成不同的部分，在初始阶段应该决定由谁来做、什么时候做完、每一步花费多少、需要什么东西等。计划的意义，就是要回答一切有关谁、什么、何时、如何等的问题。 某种意义上，计划是一件非常困难的工作，原因之一就是它涉及估计。一个步骤要花多长时间？面临交付的日期压力，有的员工评估任务需要两周时间无法获得领导的同意，而压缩时间会造成人员加班导致疲劳，或者有的员工会自动降低工作质量，这些因素往往很难平衡。 那么，到底如何制订任务实施计划，才能更好地保证进度呢？以下是我再次的思考，并会在下次工作中按计划实施和检验。 不制订片面计划 团队的计划，不能仅仅由我去制订，然后交给下属执行。这显然是个错误，因为没人能够想到项目的方方面面。我要做的是，认识到项目计划的首要原则就是让具体执行的人制订自己的计划。 而我的工作主要是全盘考虑，和负责人沟通计划如何实施以及资源需求，特别是各个接口环节，不要有遗漏。没有完整的计划和定义，后续的控制是不可能实现的。 太少或太多细节的计划都不可取 项目失败的一个主要原因是把模糊预测当做了目标。要想取得满意的估计，你就必须明确要做的主要工作，甚至还要包括那些次要的工作，这些细节是不可或缺的。 一般来说，某一项计划如果超过2周，那就意味着需要细分，保持计划在1~2周最好。另外，所有的任务都必须有一个用来表示任务完成的标志。 与上相反，也不要沉湎于制定微观计划。一条基本的原则是，你计划的细节应当在你可控范围之内。对设计与软件项目来说，这意味着时间应以天来计算，比天还精确的事你根本无法控制。 如果你的计划照顾到太多的细节，你的所有时间可能都要用在修改进度表上，那完全是在浪费时间。 计划要考虑风险和备选方案 墨菲定理说，任何可能变坏的事都会变坏。用概率的语言来说，就是事情变糟的可能性总是比变好的可能性大。 如果在短时间内用一种没有把握的技术开发新产品，就存在失败的可能，这就需要在全力开展项目之前进行可行性研究。 如果风险的预估太高，那我们就需要提前考虑一种备选方案，不管是备选设备还是备选技术方案，能保证基础的目标实现。 一定要制定工作分解结构 项目失败的一个主要原因是，直到项目要完结时才发现忘记了某些工作。而一个工作分解表就能解决这个问题，所以这个环节也是不可或缺的。 工作分解结构也叫做WBS，是确定“必须做什么”，它能把整个项目连接在一起。首先是列举出所有的任务，然后进行任务分解，找到次级任务甚至次次级任务。每个任务需要某种验收标准，大家达成一致即可。下面两张图是从维基百科上找到的WBS分解示例，很有启示作用。 有一个说法是，“我们总是采用同样的方法，但却期待不一样的结果”。做产品开发、项目管理也是如此，我们不能采用被证明已经是错误的做法，却想着项目一切顺利。 此外，作为一名产品负责人，要明白自身的主要任务，是领导者和协调者。我的分析能力不是最强，我的计划和组织能力不是最好，这些都不会造成项目搁浅，因为只要团队成员做得足够好，一样不会有问题。但是，我的思维模式一定要进步，思考全面是必须的，否则，相同的错误一定会再次发生。 |
|
|
