艰难的抉择

今年三月份，我带领开发的绩效团队终不免要到交付去，虽然是一个妥协的结果--团队中除了我之外所有的成员都过去了。过去的半年里，银行绩效系统倾注了我所有的心血，此时虽有不舍之情，但却为无奈的选择，当然同时我希望并相信一块去的团队能够很好地从我手中接替过去，愿绩效“项目”一路走好！
我总结了一下，绩效团队会有今天的结果，我自己会有这样的选择，有以下原因：
1、绩效产品是跨部门合作的产品，进入开发之前没有理顺部门之间的功与累的关系，虽然订单是交付做的，但需求分析和功能实现都是研发部做的，那么到实施的时候该由谁来主导，项目的分红研发部能够占到多少？这些根本利益一开始没有落实，到后来就很难落实。
2、团队中时有不和谐的声音，这使我看不到团队建设的希望，也是我萌生退意的根本原因。绩效三线作战，在上海的同事不了解项目现场的燃眉之急，现场的同事抱怨中心的同事不配合，所以，这种状况，越到后来，合作的摩擦就会越大，而团队自上而下，没有人会圆滑的处理这种状况。
3、绩效的代码决定权不在Code TeamLeader，而且几易人选漂浮不定，这是原因之一。
4、到后来，包括到上游的需求，也不甚严谨，这使我觉得绩效的质量以后难以保证。
5、个人感情有时候会决定一个人的选择。

 

教训：
1、加强团队建设，必须建立良好的合作氛围，Leader要在成员当中有一定的威信，这样才能指挥动、协调好工作。
2、工作安排要合理，一定要松弛有度、知人善任，有表扬也要有批评，但不主张用罚钱的方式。
3、准备工作要充足，配置管理、代码规范、数据库设计都要尽早完善。
4、Leader不能过多的参与编码，而要更多地参与到需求的理解和管理当中，CodeReview要贯穿编码的始终。
5、管理要自上而下，执行要自下而上，工作上不可能完全平等，项目经理要维护TeamLeader的权威。
6、多加强思想交流、技术交流。