团队建设是软件项目能否高质量、高效率研发和交付的基础，没有好的团队建设，项目有可能进展缓慢，质量低下，进而造成交付日期延误和用户体验差等后果。所以一个好的团建建设对公司和个人而言都是一项必须要重视的内容，对提升公司的业务、个人的能力和团队的战斗力提升都有至关重要的作用。
对于公司而言，我们的团队建设至关重要，要想把项目打造成公司的一面旗帜、一个标杆、一把利刃，我们要努力搞好团队建设，好的团队文化可以成倍的提升团队的战斗力、创造力和生产力。
首先我们可以设定一个最基本的约束或者边界，在约束或边界内，个人以及团队可以自由发挥，挖掘潜能和发挥个人创造力，如果超过边界那就表示不认同公司的文化或者规则了，这时候领导就要对该员工进行谈话以纠正。
参考前人经验，我们可以主要设定以下3个约束：
1、 最终的评价标准取决于对产品线的贡献
贡献是第一要素，绩效是建立在对项目真正的贡献之上的，带来了什么是最关键的，我们的贡献是提高对业务的直接输出，或者提高研发生产力，或者帮助他人解决难题或提升能力，或者提升团队建设等。
2、 以正确的方式做事
不接受低质量的代码，写有灵魂的代码，好品味是一个合格软件工程师的标配。
3、 要有技术目标
这点要求我们的研发人员要有对技术和代码的追求。如果一个人只是把工作当成一个任务，只是将代码堆积起来完成功能，然后就吊儿郎当不管不顾，这样的人很危险，对团队来说也很危险，他不仅自己不上进，进而带来一个坏的风气影响了别人：我吊儿郎当照样很好，这样就会拉低别人的积极性，造成恶性循环。如果一个人对技术这件事本身缺乏热情，这样的人只会关注绩效和工资，而不关注如何更有效率的做事。
这三点可以说在任何一个积极进取的IT公司的文化和发展的基石，没有这三点公司未必发展不好，但是未必能利刃出鞘，打出一手好牌。
在这三点之上每个研发团队可以定义自己的规则以适应自己团队发展的需要。
好的团队建设我总结了以下几点：
1、 建立代码审查制度
所有的代码都可以被code review。代码审查能够发现低质量的代码，这对我们团队的每个人都是一个促进，促进我们写高质量的代码，而高质量的代码又能提升研发效率和应对需求变化的灵活性，又能促进我们自己本身技术的提升。时间长了之后就在团队内部形成这样一个文化：以写低质量的代码为耻，同时大家又能自发的发现项目中低质量的代码，促进代码质量不断的提升。有的员工看到一处别人写的一处代码正好能用上，他就随手拷过来，以后凡是能用到这段代码的地方都拷过来，也不管这些代码是干什么用的，或者为什么这些代码要这样写，反正能实现既定的功能，导致项目中导出充斥着这样很恶心的代码，有时候还会导致代码性能低下，这样的情况应该坚决杜绝。
2、 建立合理分工制度
当需求来临时，leader要分配任务，这时候组员不可以对leader说NO；如果leader觉得哪块功能不好需要重构或者改善，将任务分配给组员时，组员不可以说NO。总之，组员要服从leader的分配。话又说回来，leader有时候也有分配不合理的时候，实在超出组员的能力范围或者组员实在有难言之隐，这时候组员不要直接拒绝，可以心平气和的和leader商量，如果和leader商量无果，再找更高的领导协商解决。如果组员发现leader故意刁难的话，可以直接找上级领导反馈。如果leader发现组员写低质量的代码，leader有权要其改善代码，如果组员有异议可以找上级领导反馈。组员如果有好的建议或者好的技术实现，可以和leader商量对代码进行改善，如leader不同意，组员觉得点子很好，弃之可惜，可以找上级领导反馈。总结起来：leader和组员都要有主人翁意识，要有责任感，将自己负责模块当成一个产品，以提高产品质量为荣，主动积极的参与进来，而不是实现功能后就一推了之。还要明确自己的责任和义务，做到分工明确。
3、 建立分享的氛围
IT行业技术日新月异，变化之快让人咋舌。每个人的精力有限，不可能每种技术都学的很深很广。团队的每个人都有自己擅长的或者别人不知道的知识，这时候可以拿出来分享。有的人不愿意分享，怕分享了之后别人学会了自己的技术超越自己。其实这是一种错误的认识。分享也是一种提升，在分享的过程中你可以给别人讲解，在你教别人的过程中你自己又会有新的领悟和更深刻的体会，技术会进一步巩固和提升，这对自己和他人来说一个双赢的结果。在分享和学习的过程中，别人会变的更优秀，而你自己也会变的更优秀，和优秀的人在一起工作只会更加优秀，这是一个正能量不断叠加的过程，值得大力推崇。我们可以建立一个分享文件归档中心，每个人的好的建议和分享的内容可以放在归档中心，团队的任何一个人可以随时翻阅，温故而知新。如果有的人分享的东西确实很好，对团队的每个人都很实用，可以安排一定的时间（一节课）让其给我们培训，这样的提升是很大的。
4、 建立学习的氛围
技术的日新月异对IT从业者来说是一种考验也是一种挑战，考验的是我们的耐力，挑战的是我们的学习能力。如果一个软件工程师在从不学习的情况还能屹立终身不倒，那只能说“从目前为止还没出现过”。我们应该在团队中建立一种工程师文化，不要把自己当成码农，永远只在码代码，而是把自己当成一个工程师，一个对技术和知识有追求的工程师。人人都应该不断的学习，把自己从初级工程师变成中级工程师再变成高级工程师到最后变成架构师或者专家，俗话说：一个不想当专家的程序猿不是一个好的架构师。
这是一种文化：仰望星空，人人都向着那座叫“架构师”的巅峰披星戴月，日月兼程。
5、 建立鼓励的氛围
如果员工提出一个好的建议，改善了代码质量或产品质量，提升了项目的技术水平，我们要对其进行鼓励和褒奖。领导的鼓励是必不可少的，如果一个员工付出的很多，领导视而不见或者永远不说出来，也会对员工造成一些困扰，好像自己付出的努力没有得到肯定，时间一长可能会挫败他的积极性。适当的鼓励可以提升员工工作的热情，让他参与感更强，情绪更积极，更能推动团队文化的建设。此外，一方面你要表示自己看到了员工做的贡献、在意他的贡献，另一方面你又要避免激励过度而导致事情变质，把自发的行为变成了为激励去做一件事情。
6、 建立沟通的氛围
沟通能力在架构师技术栈上排第二，由此可见沟通能力是多么的重要。那么对于一个团队而言，沟通自不必多说，康威定律即可说明一切：设计系统的组织，其产生的设计和架构等同于组织间的沟通结构，连架构设计都要和沟通结构匹配，所以加强沟通建设必不可少。其实沟通是贯穿于以上所说的几点的。沟通涉及的方面很多，包括项目各个阶段各个不同设计人员的沟通，而在研发团队内部，主要就是研发人员之间的沟通了，我们不应该打压大家发言的积极性，而应该鼓励大家发表意见的激情，对技术、研发、管理、领导、安排甚至娱乐都可以提意见和建议，好的可以采纳。这样大家就有一种存在感，对公司对项目的积极性也会提升。
7、 建立民主的氛围
规则的制定不应该由领导一手包办，而是要团队员工共同参与，民主讨论制定出来，这样符合共同利益。还有，给与每个员工自由发挥的空间。如果一个任务他能自己搞定的话，那就让他自己去发挥，如果有任何问题的话，在代码审查阶段可以发现，但是这是建立在你对这个人能力充分信任的基础上，如果这个人给你一贯的印象就是写烂代码，那么绝对不可以让他自由发挥的，这只会导致代码越来越烂。在平时，如果研发工作确实完成，而且也没有BUG修复任务，这时候个人不要白白浪费时间，要学习，学习底层、语言、软件开发或者项目管理知识都可以，只要能提升个人能力和对团队有益的都可以，学完之后可以分享和教别人。
8、 价值观的建设
愿景，包含了我们对未来的期待，让人激情澎湃，但又富含挑战。团队的愿景建立在公司的愿景之上，公司的愿景建立在领导的决策之上。有了一个良好的愿景，我们全体团队人员就可以为了一个共同的目标而努力奋斗，向着同一个目标进发，团队成员都拧成一股绳，像一支飞翔的箭，向着远方飞去，直插靶心，一个没有共同目标的团队就像一盘散沙没有凝聚力。其实好的愿景给与团队成员一个希望、一个信心的源泉、奋斗的动力以及一个安定的依靠，有了力量的源泉，员工才会认同企业，认同团队，才有了长久干下去的希望，才会付出努力把事情做好。举例来说，当年马云为什么能拉来23个人和他一起创业，不离不弃，主要就是马云给他们描述了一个宏伟的蓝图，一个充满希望的愿景，而马云绝不像搞传销那样满嘴忽悠，马云自己也是被这种蓝图和能量驱动，所以大家都满怀希望的跟他干，事实证明他是对的。还有一点，就是要让大家认识到，认真做好事情是公司对每个员工最基本的要求，不认真做事是不鼓励甚至要受批评的。

总结：
其实说了这么多，一个团队的建设是建立在正能量不断叠加的基础上，不管对于技术、学习、写代码、研发、管理和沟通等各个方面，不要让坏味道一直持续下去（坏味道：是指一个事情或者事物一直处于消极、怠慢、堕落以致最终损毁的状态），如果在任何一个环节发现坏味道，我们要去努力改善甚至去除坏味道，建立在民主和开放的基础上，每个人都有责任和义务这么做。在良性循环上，正能量不断叠加，我相信团队的效率会越来越高，技术会越来越好，交付能力越来越好。
关于绩效考核
软件开发工作很难量化，比如用代码行数来评估的话，就会造成员工故意写很长的代码，比如用BUG数量，这也不准确，有时候BUG数量受项目紧急程度、需求调研程度、沟通程度、对业务的理解程度等影响，比如评估代码难易程度，有的时候开始的时候代码很简单，但是随着需求迭代加深，代码的编写越来越难，而且这种开发周期绵绵不断，很难用时间或者技术能力去评估，这些都不足以体现一个人的编码能力。真正的编码能力其实leader最清楚。
即使量化办法可以量化每个人的工作量，但是个人一些无形的能力也是至关重要的。比如，有的人有擅长方面和一些其他方面的技术储备，虽然在目前的开发中没有充分发挥出来，但是对项目后面的发展有很大帮助，或者在未来的开发中能发挥作用；一个人为了完成工作加班加点的工作和为了让项目少一点BUG和风险，对项目的关注细致入微，这也是一种无形的资产，能减少很多不必要的麻烦，和一些做事吊儿郎当和马虎总出错的员工而言就是一种很大的能力差距了。还有的人为了项目尽快进展，主动沟通和协商解决，和一些事不关己高高挂起的员工而言就是一种能力的差距了。以上列举的种种，都是量化考核所不能体现出来的。我的观点是综合评估（对每个人的硬实力和软实力综合评价）和量化考核结合。为什么要出综合评估，每个研发人员都有对应的硬实力（技术水平）和软实力（主动能力、沟通能力、办事效率等），硬实力对个人贡献大，软实力对团队贡献大。如果一味的重视硬实力而不重视软实力，将形成一种失衡的文化，给员工造成一种假象：我只要技术牛逼就可以了，其他可以无所谓，这对团队来说是非常不利的。所以呢，我们综合评估一个人要从多方面进行考核，这样更公平，优秀的人才会更优秀。
我们可以从以下三个方面进行评估：
1、 综合评估
我们可以每半年或者三个月进行一次绩效评估工作，这样的评估工作可以持续几天。
评估的时候所有的leader和领导都参加，自己的leader对自己人进行打分和评估，然后大家讨论，看是否公平，讨论之后出一个综合评估结果。评估的标准，我们可以出一个评估的打分细则，按照细则进行打分。
评估可以从以下几个方面进行：
1、工作态度
2、软件质量 (bug的等级和个数，回归次数，重要模块系数)
3、工作难易度 (功能性，可靠性，易使用性，高效性，可维护性和可移植性，功能点数，复杂度)
4、工作效率/能力 (完成百分比，工作经验)
5、主动性
6、沟通能力
7、程序规范程度（文档和注释清晰度以及规范程度）
2、 量化评估
如果有量化考核标准的话，可以纳入考核体系
3、最终评估
将综合评估和量化考核结合，出一个最终评估，该评估就是该员工年度评审结果。