1000copy

@daysv 你的境界有点高。

@Vitumoc 听起来很有趣。很想知道怎么来的经验。。。

@cybort 你们公司没有测试和产品吗？

赞。

---
1 、原来的代码暂时不动，通过简单修改包路径防止互相交叉，新写的代码完全按新逻辑开发，要充分考虑兼容老代码逻辑，保证按时完成；
2 、陆续按模块迁移老逻辑的代码到新模块中，这个过程的进度完全根据自己可支配时间决定，然后陆续删除老逻辑；
3 、工作汇报、周报中尽量避免用 “代码逻辑优化、重构”这种模糊字眼，要不然就算你做了再多别人也会认为你在摸鱼。
4 、评估排期时，实际所需时间和评估时间，要尽量控制在 2:3 以内，这样你剩余的时间可以充分进行想要去做的优化工作；
5 、设计数据库字段、表结构、接口协议时要充分思考，因为这些地方设计的不好，上线后再改可就麻烦了。

@xueling 真是实践者的建议，有实践有理论。这样的好内容不多，v2 很多时候都是虚无主义的天下。

@charlie21 不错，分得挺细致的。把团队，软件复杂性，项目三角形分开来看。一般而言，事情能分得下去，也得整合的上来才行。

他们三个事情分开后，整合的就是他们的关联，前两者是内部的，是属于方法和操作层面的；而项目三角形则有很强的外部性，三角形的任何一个变化都会影响到开发团队之外。内部的存在是为了外部的服务。

@yjxjn 你经历了什么？交出你的故事。

@jones2000 如果问题出在开源代码上，当然可以这样做。

@darkengine

不能。

但是我猜你还有问题，就是既然不能，那么搞一个新团队的意义何在？

这就是项目三角形的功能范围的变更了。如果功能范围不包括难啃的，那么能做的还是可以交付的。

把碗里的吃掉，也顶饱啊。不能因为锅里没有，碗里的也不吃。

接下来，那要看你是什么角色了，如果是开发经理，这个做不出来就和你无关了，板子打不到你的屁股上。对你而言，这就是利好。

如果是技术经理，就要想办法找外援了。

如果是老板，就需要知道这个钱可能不该你拿，当然一般老板不会这么想，于是就 PUA 开始。