对于众多企业来说，制定需求，设计，测试，上线等计划相对“务虚”一些，而编码属于生产中最“务实”的阶段。

虽然绝大多数情况，越往上层的管理者，越对“务实”的东西越不“看重”，但作为基层的管理者不能有此想法，更不能付诸行动。

尤其，在一个新的团队中，管理者往往喜欢用自己熟悉的技术框架。业务上，工程师与管理者一般由于信息不对等，必定管理者其本人，在业务上更加熟悉，客观上照成估算会有一些偏差，对于管理经验更为充足的人来说问题不大，会有一些自己的“修正值”在计划里面得以出现，不过对于管理新手会出现一些问题。

以下举一案例：

公司刚组建技术团队不久，项目经理兼任技术经理，带着几个经验丰富的工程师开始干活了。由于团队刚刚组建，总有一些资源协调不到位，信息会有一些不通畅等等。总之，主观客观原因都有，照成实际实施项目周期比较短，在这种情况下也许大多数管理者会选择“加班”，是个手段，但不是法宝。

对于前期的“准备”工作，需求，设计，这些东西都很好过关的，执行上也一般不会出现延迟现象，但是到了编码阶段往往问题突然一下爆发了。

这种问题基本归纳为几个方面。

1，设计阶段是否真的完成了？

评审是否通过？时间若真的很紧张，至少需要数据库设计通过。没有较为健全的最底层的数据模型支撑，系统难以按照预定方向实施。

2，编码计划制定是否搭积木出来的？

比如难易层度是否按照一定的规则排下来的；较为类似的功能是否分配同一个人做，且第一个功能分配时间相对多点，其他类似功能分配时间相对少30%-50%；每个任务分解的是否得当，大多数任务都是0.5天/个，突然来个2天/个，是否妥当,；共通部分，数据来源，数据基础部分是否尽可能的计划排在前面？等等

3，计划的衔接点是否妥当？

比如某计划2天，却安排在周五与下周一，又或者中间来个国庆节什么的，这种计划客观上照成工程师无法按照您预想中那么多的时间去执行，原因大家都懂的。

4，计划的buffer是否妥当？

一般一份计划需要留有20%的buffer才是一份有价值的计划，没有buffer，是一份非常有风险的计划，谁也无法预料延迟，请假，生病，情绪低落，各种各样的问题导致生产率低下，特别是基层的管理者，手中的权力并没有想象中的那么大，很多时候还是需要上级领导帮忙与协调，做好各种风险对策。

5，沟通管理

编码阶段属于相对压力较大的阶段，沟通不能多，但不能不沟通，这样就需要提高沟通效率，有效沟通。比如汇报工作采取单线沟通，而不是开个又长又没有效率的会，需要几个人沟通再找相关人等沟通，汇报工作5分钟最多。

 

管理不仅仅是理论上的事情，更多需要考虑人的因数，在不同的环境中需要因材施教方为管理大师。

PS：平时较忙，有空完善下。