共计 1478 个字符，预计需要花费 4 分钟才能阅读完成。
如何做打算
如何做打算，通常不是技术团队本人的问题，而是整个公司的问题。常见状况是，一家业务驱动的公司，技术团队是没有什么话语权的，大的需要打算由销售、经营或者管理层确定，技术团队只负责执行，有时候两头还隔着一层产品经理。这种状况下想制订紧密周到的打算就是奢谈，可能连正当都做不到。
我据说过最夸大的公司，明天定需要，今天就要求上线，并且上线当前如果呈现 bug，按数量罚款，数额从数百到数千不等，如果 bug 给公司造成了损失，就按等额的损失金额抵偿。。。不用说，这家公司的程序员到职率高得惊人，大略每 3 个月会从新换一批。
侥幸的是，作为合伙人，我还是失去了守业搭档的充沛反对和信赖，打算制订过程，基本上能够做到良性互动：业务和经营部门提需要，技术部门评估工作量，最终管理层会议决策优先级和工夫点。在过程中，大家当然免不了争吵、答辩和讨价还价，但争执的内容是感性的，能够相互理解。
有人可能会想，让技术部门本人评估工作量，难道不会成心多报么？说实话，在大公司里，这种状况还真不少，原本 3 天能实现的，说 3 周，1 个月也不是新鲜事儿。因为每个部门有本人的利益么，跟公司的整体利益并不统一，信息沟通也不那么顺畅，节约随处可见，同时又熟视无睹。而小公司一个最大的劣势就是外部损耗低，效率高，这个劣势是建设在信赖根底上的：业务团队必须信赖技术团队的诚恳和能力，就像技术团队也要置信业务团队的开辟和判断一样。实际上，我在评估工作量的时候，会真挚的想为公司节俭每一个人天：因为小公司经不起失败，任何节约都可能导致覆灭。
如何合成工作
具体的打算应该怎么做？一句话总结就是工作细分：把总体工作合成为可独立公布、可专人负责的小模块。留神 每个模块肯定只有 1 个负责人，这样才责权清晰（当然在有 Teamleader 的状况下，合成的职责又能够下放给 Team 了）。
之后每个模块负责人还要本人评估工作工夫，这是个技术活儿，很多人程序员不想做，或者做不好，但肯定要敢于撒手，也要提出要求——做不好工夫评估，就不是合格的程序员。
老手常常犯两个谬误：其一是一头雾水，不知从何做起。这就须要管理者来领导：如果是前端模块，通常能够按页面合成，而后每个页面里再察看复杂度：有没有交互？有没有须要计算的逻辑？有没有须要摸索的新技术点？；如果是后端模块，那么就能够按接口合成，每个接口独立察看复杂度：须要用到多少独立服务？有多少关联业务实体？波及什么算法？以及有没有要摸索的技术点？其中新技术点对评估准确性有最大的影响。
另外一种过分乐观，工夫预留有余。这时管理者要把好关：千万别感觉预估工夫短就很开心，打算短不是真的短：到时候完不成，或者代码千疮百孔，哭都来不及。首先依据教训判断估时是否显著有余，如果是，那么跟他一起过细分项。老手常常把写完代码的时长，就当成实现性能的时长了，殊不知前面的调试批改可能还要多花一倍工夫（如果有单元测试的习惯当然好，那么写测试的工夫也要算上）。
最初补充一点：同一个性能，不同的人须要的开发工夫就是不一样（人不是可调换的资源）。管理层通常心愿所有的资源都是标准化的，实现工作的工夫是明确固定的，甚至是能够对照手册查出来的——这对于软件开发，是不可能实现的工作。写代码和其余工作最大的不同在于：没有任何工作是反复上一次的！如果能够，那么它就应该被封装起来（这个当前说到代码品质的时候再开展聊）。所以它是真正创造性的工作，无奈标准化，也无奈彻底的量化，然而一个特定的团队，是能够有绝对稳固的产出效率的。作为技术管理者，要突破规范量化的执念，同时也要在公司业务需要和团队生产力之间起到桥梁的作用。
