这么说吧，我的团队里软件，逻辑，算法都有
基本会有这几种情况需要leader协助解决问题：
1.需求和方案是leader做的，成员实施，因为我写的方案会非常详细，基本可以认为是代码的中文版，细节都有，遇到问题大多是没有严格按方案来干，找到差异点纠正就好
2.需求和方案是成员自己搞的，leader不熟悉，这种情况其实去插手具体代码没有意义，没准还成为了捣乱。这种情况做方案的那个成员一定是最懂的，leader主要是通过跟成员一起分析原理和底层逻辑，协助找到他的思维不严谨的地方，找到疏漏，问题自然就解决了，去直接参与代码是没啥用的
3.问题发生在不同成员或者不同专业的边界处，这种一般是接口没定义好或者相互没配合好，并且成员一般只限定在自己的思维和视角内，看不到全局，迟迟不能解决，这种时候leader是负责拉通，规范接口处的定义和行为，把各部分需要修改的内容归属到具体的责任人。
4.以上都不太需要参与代码，有一种特例需要参与代码，主要是FPGA逻辑设计人员如果经验不丰富，他的代码写的不规范或者掩藏了问题，他自己都说不清楚，这种确实得帮忙看。软件设计人员因为debug手段太丰富了，一般只要你给他理顺了，代码的问题他自己就搞定了
【 在 xeagle 的大作中提到: 】
: 但如果项目delay了几周呢，问题特别多，你也不亲自解决一两个问题？只给简单建议大部分情况没有多少帮助啊，因为是代码细节特别多的那种
: 发自「今日水木 on iOS」
--
FROM 219.145.32.*