如何制定好项目计划

"我是一家小互联网公司的部门负责人，下属五六位，他们推进项目有些拖拉，我不好意思强迫要求时间（有些项目时间不那么苛刻），他们上班时就有划水现象。如何很自然的变得原则性更强。" #软工好问题 这其实也是个典型的软工问题，工作中常见。 从软工的角度来说，这不是简单的缩减Dead Line，而是应该有更合理的项目计划，每一个项目，都有一个合理的完成的时间，该3个月就是3个月，该30天就是30天，不是商场买衣服先拦腰砍一半。 作为项目负责人或者部门负责人，最重要的是，要制定合理的计划，让时间点尽可能接近实际需要的时间，不要太紧以至于总是996，也不要太松让员工天天摸鱼。 那么如何制定好项目计划呢？有三个关键点： *第一个：要将任务分解。也就是项目管理中常见的WBS(Work Breakdown Structure)，一个任务层层分解，分解的越细就可以让时间估算的越准 *第二个：要让具体执行的人参与计划的制定。定计划不是拍脑袋，如果不了解具体的技术细节，很容易高估或者低估实现的难度而制定出不合理的计划。所以最好的办法是让具体执行的人参与计划的制定，这样一方面更准确，另一方面ta会更有参与感。对比一下： “这个任务你能不能三天内完成？” “我尽量吧” vs “你觉得这个任务要几天完成？” “我估计需要3天就可以完成” 前者可能就觉得好像是被逼的，完不成也有借口：“这是你定的时间点，不科学”。 而一般程序员自己说的时间点，都会努力遵守的，你甚至都不用太催ta，ta会尽可能在自己说的时间点前完成。 但程序员估时间点，很容易过于乐观，或者有些人会给一个过于宽松的时间，这时候，就需要结合任务分解（WBS），将任务细分后，偏差就不会太大。沟通的时候，要注意多问问题，而不是简单质疑为什么要这么多时间。比如说： “是不是可以把任务细化一下？” “这个模块3天是不是不够？” “这个功能模块需要2周，如果我们简化一下，或者移除，是不是可以让进度快一点？” 通过这样让程序员参与估算，通过反复沟通，基本上可以得到一个合理的时间。 *第三点就是要有里程碑。如果是敏捷开发这种一个Sprint一个Sprint的迭代还好，每个Sprint就相当于一个小里程碑。没有里程碑的话，计划的执行就很容易前紧后松，开始无所事事，快到交付的时间了发现还差很多，只能凑合着完成。 设立好里程碑后，强制每个里程碑都要有交付，这样就可以保证最终计划的执行不会偏差太大，一直有交付。 里程碑，本质上是利用DeadLine来倒逼生产力，是一个简单有效的方法避免划水，提升效率。参考阅读：《项目一再跳票？试试这一招：用Deadline倒逼生产力》 https://cnblogs.com/dotey/p/13205902.html… 计划，不仅仅针对单个项目，其实对于整个部门来说，也要有长期的计划，有些是硬性的业务需求，还有一些是要作为填充剂的软性需求，像偿还技术债务、提取公共组件、尝试新技术栈等，在闲暇的时候正好把这些填充剂需求补上，保证大家一直有个稳定的节奏，不要太紧也不要太松。 上面说的这些，包括截图中的方法，都是一些基本的软件工程和项目管理手段。除了这些手段，其实更高明的办法是去激励员工，激发他们自驱自主的努力工作 。 激励员工方法之一，就是类似于鲶鱼效应，开掉消极怠工的员工，招一些积极的“鲶鱼”，带动整个团队。 激励员工的方法之二，就是让他们觉得自己做的事情是很有价值很有意义的，他们能感觉到成长。 比如我们最近在忙一个大项目，我们组也有要去做一些事情，我并没有把这个事情只交给某个资深程序员的去完成，而是分解成几个小任务，让大家都有机会参与。任务做完了，再鼓励他们去给大部门做Demo，去展示他们的成果。 即使我们没996，但是可以看到他们很努力的工作到比较晚，因为他们觉得做的事情很有意义，而且从中也获得了成长。