[Team]开发中的控场

近期在参与一个大型模块的开发中，自己也承接了不少任务，以及大量的提交代码&讨论代码；
实际在做的feature中，代码量大约是30%，70%的时间和代码都是在重构整理（有自己直接整理，有的是交代同事直接整理）；
做的时候，更多的是发乎直觉，面对一系列问题，显然应该这么去处理事情，这里进一步去总结下；

黑盒部分的优先级和局限

所谓黑盒，就是把每个人作为一个“抽象化”的标准个体，3个人做还是5个人做这种；
假设这几个人的战斗力输出的，比如按照鹅厂的3个t9战斗力怎么样。。。
进而建立目标，做人力分配，以及核查实现的结果。

这里的建立目标部分在产品层面，一部分是在技术团队（比如对未来开发的技术布局），这块工作一定是最关键的，需要优先做好。
也就是平衡团队的能力和目标的工作；
这块就是整体战略，确实非常重要，但是很多时候这块在假设团队能力固定的情况下，那么目标也是比较直接，未必那么难。
如果仅仅停留于此，个人觉得还是比较浅层；

一个团队可以有很强的成长性，而且在开发的过程中，也有非常大的弹性，同样这几个人，做得好与不好，带队得当与否都意味着不同的能力。
这个就是黑盒看待团队能力的局限，也就是团队能力是可变的，也就是“搭班子，定战略，带团队”中的带团队部分，是一个提升能力的过程。

所以黑盒定战略，平衡能力与目标，这个优先级最高，但是也有局限；
我们要白盒的看待开发的过程，动态的看待团队能力成长与培养；

白盒：开发过程中的控场

在开发过程中，几个人形成一个小team进行开发，这里就形成一个小的系统，team的战斗力就不只是简单的几个人的叠加；
其上下浮动的范围非常的大。
在team leader层面，在面对具体milestone的时候，重在开发过程中寻找整体最优，控场；

在team级别这里几件事情要做到位：

关键点	覆盖面	反例
技术方案清晰	在文档上能描述清楚，更新及时	没有文档，技术方案已经开始混乱
开发实现效率高	整体结构健康清晰，框架和底层函数强大	架构落后，代码混乱，底层函数支持不足，智商280的也没法发挥了
代码在整体上结构健康	持续的进行重构整体，保持整体的健康简洁	代码冗长，内部出现bug的概率高，开发效率非常慢
代码在设计和底层模块强大	提供好用的底层函数模块，并且对此有足够的应用	扩展和实现都非常的快

具体同事来说，往往是实现其中一个个的小模块，那么整体最优的责任就落在了lead的头上：
在短期内，至少要保持：

• 技术方案清晰，落地到文档
• 代码在整体上结构健康

而这点：

• 代码在设计和底层模块强大

则是偏长期的建设；

sum：

• 黑盒进行开发是远远不够
• 团队能力在同样的人身上，有巨大的浮动范围
• 整体最优中的控场上的事情，落地于牵头人的身上，这个就要覆盖到方案，整体代码结构和整洁度