创业技术团队如何做计划

如何做计划

如何做计划，通常不是技术团队自己的问题，而是整个公司的问题。常见情况是，一家业务驱动的公司，技术团队是没有什么话语权的，大的需求计划由销售、运营或者管理层确定，技术团队只负责执行，有时候中间还隔着一层产品经理。这种情况下想制定严密周到的计划就是奢谈，可能连合理都做不到。

我听说过最夸张的公司，今天定需求，明天就要求上线，并且上线以后如果出现bug，按数量罚款，数额从数百到数千不等，如果bug给公司造成了损失，就按等额的损失金额赔偿。。。不用说，这家公司的程序员离职率高得惊人，大概每3个月会重新换一批。

幸运的是，作为合伙人，我还是得到了创业伙伴的充分支持和信任，计划制定过程，基本上可以做到良性互动：业务和运营部门提需求，技术部门评估工作量，最终管理层会议决策优先级和时间点。在过程中，大家当然免不了争吵、辩论和讨价还价，但争论的内容是理性的，可以相互理解。

有人可能会想，让技术部门自己评估工作量，难道不会故意多报么？说实话，在大公司里，这种情况还真不少，本来3天能完成的，说3周，1个月也不是新鲜事儿。因为每个部门有自己的利益么，跟公司的整体利益并不一致，信息沟通也不那么顺畅，浪费随处可见，同时又视而不见。而小公司一个最大的优势就是内部损耗低，效率高，这个优势是建立在信任基础上的：业务团队必须信任技术团队的诚实和能力，就像技术团队也要相信业务团队的开拓和判断一样。实际上，我在评估工作量的时候，会真诚的想为公司节省每一个人天：因为小公司经不起失败，任何浪费都可能导致毁灭。

如何分解任务

具体的计划应该怎么做？一句话总结就是任务细分：把总体任务分解为可独立发布、可专人负责的小模块。注意每个模块一定只有1个负责人，这样才责权清晰（当然在有Teamleader的情况下，分解的职责又可以下放给Team了）。

之后每个模块负责人还要自己评估工作时间，这是个技术活儿，很多人程序员不想做，或者做不好，但一定要敢于放手，也要提出要求——做不好时间评估，就不是合格的程序员。

新手经常犯两个错误：其一是一头雾水，不知从何做起。这就需要管理者来指导：如果是前端模块，通常可以按页面分解，然后每个页面里再观察复杂度：有没有交互？有没有需要计算的逻辑？有没有需要探索的新技术点？；如果是后端模块，那么就可以按接口分解，每个接口独立观察复杂度：需要用到多少独立服务？有多少关联业务实体？涉及什么算法？以及有没有要探索的技术点？其中新技术点对评估准确性有最大的影响。

另外一种过分乐观，时间预留不足。这时管理者要把好关：千万别觉得预估时间短就很开心，计划短不是真的短：到时候完不成，或者代码千疮百孔，哭都来不及。首先根据经验判断估时是否明显不足，如果是，那么跟他一起过细分项。新手经常把写完代码的时长，就当成完成功能的时长了，殊不知后面的调试修改可能还要多花一倍时间（如果有单元测试的习惯当然好，那么写测试的时间也要算上）。

最后补充一点：同一个功能，不同的人需要的开发时间就是不一样（人不是可互换的资源）。管理层通常希望所有的资源都是标准化的，完成任务的时间是明确固定的，甚至是可以对照手册查出来的——这对于软件开发，是不可能完成的任务。写代码和其他工作最大的不同在于：没有任何工作是重复上一次的！如果可以，那么它就应该被封装起来（这个以后说到代码质量的时候再展开聊）。所以它是真正创造性的工作，无法标准化，也无法彻底的量化，但是一个特定的团队，是可以有相对稳定的产出效率的。作为技术管理者，要打破标准量化的执念，同时也要在公司业务需求和团队生产力之间起到桥梁的作用。