一文搞懂什么是开发

前言

  关于开发，可能绝大部分人都听过或说过“开发效率”这个词，在大多数情况下大家都期望开发效率要高，质量要好。可能有些人已经做到了，有些人还在努力。对于没有做到的人来说，应该怎么去做？应该做些什么才能提高“开发效率”？是一个有点难度的问题。

  要回答这些问题就需要先了解清楚“开发”到底是什么？是指程序员？是指编码？是指产品设计？其实不然，想要对“开发”做一个明确的定义很难，网络上也有很多各种类型的答案，每个人对“开发”的理解也不尽相同，所以出现多个版本也可以理解。

  本文并不是要尝试对“开发”做一个明确的定义，也不是要提出一套完备的、通用的解决方案帮助大家解决“开发效率”的问题。本文仅从个人经验出发，总结一下个人对开发及其相关部分的理解。当然，不保证内容正确性，还请根据个人实际情况出发自行判别。

开发

  从个人的从业经验来看，我认为：开发实际上是对现实社会业务逻辑进行抽象、梳理，然后使用特定的编程语言对业务逻辑进行描述，以达到计算机能够识别并正确执行的过程。

开发是一个过程，开发的基础是业务逻辑，开发的结果是计算机可识别并执行的代码。那么程序员在这中间做了什么呢？实际上程序员的工作就是一个翻译工作，将已知的业务逻辑用特定的开发语言，按照特定的格式、结构描述出来，交给计算机去执行。

  用政治正确的方式来讲，“一个中心，两个基本点” 是开发的核心内容。一个中心是指以“业务逻辑”为中心，两个基本点是指“开发过程”与“团队管理”两点都要硬。一个中心两个基本点是一个相互联系、相互依存、不可分割的统一整体。

  简单来讲，“业务逻辑”描述了做什么，“开发过程”体现了做的过程，怎么去做，而“团队管理”负责了怎么才能做好这件事。

  在不清楚业务逻辑的情况下，如何开发？这个请谁来也没法做，会魔法的没几个吧？所以，“业务逻辑”是中心，是开发的基础，必然需要明确“做什么”之后才能谈得上“怎么做”和“怎么才能做好”的问题。

  “怎么做”实际上指的就是开发过程，是敏捷开发还是传统开发模式？采用什么样的架构？开发流程是什么？这些问题都是在“开发过程”中要解决的问题。

  “团队管理”当然不会是只负责谁去做的问题，实际上涉及管理的就没一个是简单的，人员的素养、状态能极大的影响开发过程。如何让团队保持高效，同时不断提示质量都是需要不断去探索研究的问题。

  话不多说，下面就 “一个中心，两个基本点” 展开来聊聊。

业务逻辑

  开发中涉及到的业务逻辑来源于现实社会已知的业务。
  比如说，各类管理类软件的开发必然来源于现实社会已经存在的管理流程、管理办法。
  比如说，自动驾驶，其业务逻辑就来源于人类的驾驶经验。
  比如说，电商平台，来源于从古至今都存在的交易行为。

  可能没有人去统计过，但是我相信绝大部分应用软件开发的内容都是来源于现实社会已存在的业务逻辑。

  这里有一个问题，如果说现实社会已经存在的业务逻辑，现在使用计算机来实现一套有什么意义吗？如果是完全照搬，那确实没有多少意义，只能是给大家增加负担。但是在现实生活中我们可以看到，很多成功的应用都是超越了原有业务逻辑的范畴，给大家带来方便，提供帮助，甚至直接获利。比如说，以前炒股要到交易大厅，现在手机上就能搞。比如说交易支付行为现在简直不要太简单。由此可见，对现实社会业务逻辑进行抽象、梳理的过程，实际上就是一个优化、升华的过程。让整个业务逻辑更流畅、更简洁、更完善、更合理是开发中的核心目标。

  有一点需要说明，需求和业务逻辑并不是可以直接画等号的。经常会看见“以客户为中心”的说法，这个说法没有任何问题，但是到了具体的理解上就有问题了。总有人说“客户就是这么要求的”这样的话，没问题，但这并不代表就得按客户的要求完全实现。没有自己的理解，没有逻辑的优化，没有流程的梳理，这样做只能是给自己挖坑。

  对于我来说，需求讲的是要什么，而业务逻辑讲的是做什么。“要什么”和“做什么”并不是等同的两件事，“要什么”更多的是表达想要的结果，可能很清晰，也可能很模糊。“做什么”在开发这里来说就需要清晰、明确、无歧义。如果是由人来做一件事，接受一些模糊的需求是可以的，但是对于计算机来说是行不通的。做过开发的相信都很清楚这个概念，你不可能直接告诉计算机“下午执行”这个命令，如何定义“下午”？“下午”是一个时段，是要这个时段都执行吗？还是在某一个时间执行？

  因此，就“业务逻辑”来讲，清晰、明确、无歧义是首先要解决的问题。相信因为业务逻辑不清晰导致工作反复的情况绝不少见，总是能听到例如：“我以为”，“我觉得”，“可能”，“差不多”之类的对话。实际上这种情况非常普遍，并不是每个人都能写一本毫无歧义的书，每个人都有自己对业务的理解这才是应有的正常现象。就好像不可能要求所有人都写一篇一字不差的读后感，所以一定要明确接受这一点，否则受伤的总会是自己。

  关于业务逻辑可以举个例子，比如说每天都有很多人会在同一件事上烦恼，没错，“今天吃什么？”这个简单的问题总是在困扰着我们。如果有一款软件可以告诉我今天吃什么，那是相当巴适的。这就是一个业务需求。当然，这还只是一个基础的业务需求，在这个基础之上我还可以提更多的要求。比如说，我想每天不重样，我想营养健康，我想便宜实惠等等。需求可以是一个概念，一个想法，也可以是很具体的要求。比如说我想限制一周只花80块在午餐上，或者我对海鲜过敏不能吃等等。这就是需求，讲的是想要什么。

  在接到这样的需求之后，下一步就是对业务逻辑进行抽象、梳理，也就是业务逻辑产生的过程。在这个例子中，基本的业务有两个方向，一个是用户自己做饭吃，一个是点外卖。这也就是业务逻辑中需要明确的内容，也就是前面所说的“做什么”，在这里就是划定业务的边界。

  假设用户是自己做饭吃，这个时候要考虑的就更多了，几个人吃？南方人还是北方人？喜欢家常菜还是精致餐？是预制菜还是菜市场选购？家里有没有烤箱？类似的场景很多，这些就是参与业务的各项参数条件，这也是业务逻辑需要描述的内容之一。

  加上算法推荐之后，基本的业务就已经有了，然后再从其他角度来打磨打磨。比如说用户黏度，按现有的业务来看，可能整个使用过程不超过10秒，这肯定不行，得加功能点。如果告诉用户附近哪家菜店在打折，这样会不会好点？再把预制菜加进去好像也不错。再加点菜谱，同一个菜式也允许有不同的做法吧。这些内容就是基础业务线扩展的结果，这也就是业务逻辑需要描述的内容之一。

  不同的业务场景对应不同的业务流程，根据业务需求抽象、梳理得到的就是业务逻辑。在这样的业务逻辑里包含了对业务边界的描述，对业务数据的描述，对业务数据之间关系的描述，它是一个整合体，是一个描述的整合体，它的职责在于将事情讲清楚，清楚到开发流程中所有环节的所有人员都能清楚明了到底要做什么，以及怎么去做。

  当然，真正的业务逻辑并不会像上文中描述的那样简单，对业务逻辑的描述通常会由多份文档共同组成，这里就不一一列举了。需要说明的是，并不是一定需要提供一套完整的业务逻辑描述之后才能进入实际开发环节，实际上更多的时候这是一个反复的过程。所以，在实际开发过程中应该依然是需要根据团队的实际情况决定。

开发过程

  开发的过程各家都有自己的一套，各不相同又有一些共同点。总体来说，设计、后端、前端、测试、交付环节总是存在的，顶多只是表现形式不同而已。比如说，一人身担多职，甚至一人全包等等。实际上，开发过程就是明确“怎么做”这部分内容。

  那么，开发的过程应该是什么样的呢？当然是按开发流程来做，各家的开发流程大同小异就不再累述了，就说说敏捷开发模式吧，如果仅仅是为了敏捷而敏捷，其实意义不大，有时反而会成为一种负担。慢慢地就变成了形式主义，这可能就是老话说的“上有政策，下有对策”吧。对于我来说，学习其中的精髓，理解其背后的逻辑，然后应用到自己所处的场景中，这才是正确的姿势。所以，个人认为在开发过程中有几个点是需要着重聊聊的，分别是：消息传递的扁平化，高效的沟通方式，合理的结构以及统一的标准。

消息传递的扁平化

  在开发过程中个人比较倾向于多岗位共同介入。也就是说，在业务逻辑阶段，设计、后端、前端、测试岗位的人员就可以共同介入并开展相关工作。比如说，设计可以根据业务逻辑思考产品的页面结构与逻辑（实际上很多人没有分清业务逻辑和页面逻辑的区别），后端（或架构）则可以开始思考整体结构、数据流程、存储等等相关的处理逻辑，前端可以预想可能涉及到的UI效果做一些技术储备，而测试则是需要全盘了解整个业务逻辑的所有内容，以设计相应的测试方案。

  实际上这是一种消息扁平化的传递方式，好处在于没有过多的中间传递过程，避免了消息在传递过程中的失真现象。同时，这样的方式也更容易让整个团队达成一致，可以很好的解决后续工作不断反复的问题。

  日常工作中总是能听到：“我以为你知道”，“我以为是这样”，这样的场景在开发过程中出现的频率很高。这实际上是沟通不畅导致的，而沟通实际上就是消息传递的过程。每一段信息如果需要经过N个环节的传递，那么在这个传递过程中极有可能出现信息失真现象。如果消息传递的方式是口头沟通，那么信息失真导致工作反复基本上可以说是必然现象。

  记得前不久才看了一个漫画，大概说的是“为什么两个人的团队反而更高效呢？”，其实核心就是在这里，因为消息传递环节几乎没有，每个人都很清楚自己要做什么，剩下的就是体力活了。然而，随着团队越做越大，岗位越分越细，看着人越来越多，反而效率是越来越低，最终的结果不言而喻。

高效的沟通方式

  曾经遇到过这样的一个场景，负责业务梳理的员工通过与客户的沟通以及自己对业务的理解，做了一套业务逻辑。而产品设计也通过与客户的沟通以及自己的理解做了一套产品设计出来。然后就没有然后了，两边的信息完全不对等，看着挺像其实完全不是一个东西。问题很明显，同一个业务出现了两套业务逻辑，而且还各不相同，甚至完全不匹配，究其本质，消息传递环节出现了严重问题，这种情况下返工重做是必然的，开发效率低下那是必须的。

  看了上面的例子，可能有人会说：一个人负责多个环节的工作不就可以解决这样的问题吗？答案是否定的，先不说一个人的局限性，在团队里的个人英雄主义应该是尽力避免的。原因很简单，如果所有有价值的东西都掌握在一个人手里，那么这个人离开之后怎么办？这是灾难级的损失，没有捷径可以走，只能一点一点补回来，前期的高效必定需要更多时间的低效来补偿。

  上述的例子讲的是消息传递不畅的问题，而消息传递的方法同样对开发效率有着直接的影响。消息传递的方法这里是指沟通的方式，日常工作中的沟通不外乎口头沟通和书面沟通两种方式。沟通的重要性不言而喻，无论是什么样的工作都需要良好的沟通渠道和沟通办法。在开发过程中，个人认为口头沟通之后一定要有书面沟通，把口头沟通的内容提炼为书面内容，再次与沟通对象进行确认。请注意，这并不是书面留证规避责任的意思，以明确、清晰、无歧义的书面语言对沟通内容进行描述，可以显著提高沟通质量，促使沟通各方达成一致。需要说明的是，并不是说定下的内容就不能变更了，实际上这样做反而为后续的变更留下坚实的基础，能够清晰的表达出变更的内容，这样更加有利于工作计划、任务的调整。

  无论是餐桌上的闲聊还是正儿八经的会议，沟通的目的就是描述自己的理解与想法，最终目标是大家达成一致。无论采用哪种方式，达成一致是最重要的一点，就个人经验来讲，绝大多数造成工作反复的情况都与沟通有关。所以，沟通是开发过程中重点的重点。

合理的结构

  这里说的结构分为服务结构与代码结构两个方面，结构就是骨架，好的结构可以省去很多麻烦，从而提高工作效率。

  先说代码结构，在单体项目流行的日子里，重复的代码，杂乱的结构，迷宫般的调用过程，费时费力的代码冲突，频繁的停机发布等等都是刻骨铭心的痛。如果让我接手一个单体项目，我一般都倾向于重新写一套自己的项目，实在是没有条件去学习理解原项目的结构与过程。在多年的工作经验中，什么样的代码都见过，有脱了裤子放屁的，有一个方法写了上千行的，大多数情况下都是对“面向对象”的理解不够深刻，就好像写了一篇详细的每日生活日记一样，内容巨多，但味同嚼蜡，整个就是一个“面向过程”编程。关于这一点，个人认为“缺乏合理的抽象”是问题所在。当然，本人的代码水平也不高，只能建议多去看看开源项目的源代码会很有帮助。

  服务结构的话，现在有很多的公司和团队都采用了微服务架构的方式来构建应用。简单来讲就是一个单体项目变更为一组单体项目，每一个分离出来的项目负责相对独立的内容。当然，实际上不可能这么简单，并且并不是所有的项目都适合微服务架构，一定是根据实际需求来判断是否采用微服务架构，以及如何构架微服务。因为微服务并不是万能的，在避开单体项目弊端的同时也会产生一些新的问题，有时甚至可能是导致项目失败的重要原因。关于微服务就不在这里细数优缺点了，有时间的话下篇文章专门讲讲对微服务架构的理解。

统一的标准

  需要注意的是，无论是单体项目还是微服务架构，代码采用统一的标准是一项重要指标，因为其可能直接影响开发效率。代码标准包含很多方面，接口规范、代码规范、注释等等。比如说，为前端开发准备的数据接口没有标准，不同的后端提供的接口使用了不同的数据结构将直接影响前端开发效率。比如说，没有采用见名知意的命名法，直接增加阅读/学习成本。比如说，没有正确的注释对于代码来说是一个灾难。

  这里我想拿注释来展开一下，关于注释可能有很多的争议，对于老码农来说，漂亮的代码本身就是最好的注释，确实，我是认同这句话的。但是，注释是给谁看的？如果能够保证永远都是自己在维护代码，那么写不写注释确实没啥区别，最多就是可以帮助自己回忆一下。但是在团队开发里就不一样了，每个人对漂亮的定义是不一样的，无论是新手还是老手来接手代码，都会存在一个阅读理解的过程，没有任何注释只能增加大家的时间成本，无论代码有多漂亮。

  注释怎么写也是有讲究的，曾经在网上看到有人说：“A = B + 10；这种代码还需要写注释？”。大家觉得说得很对，这么简单一行代码，清清楚楚的，还需要写什么注释？不是多此一举吗？在我看来，这恰恰说明了很多人完全没有搞明白注释应该怎么写？应该写什么？就拿这个例子来说，我的第一反应是，为什么要加10？为什么不是加20？注释并不是使用自然语言对代码进行翻译，并不是说用中文去描述这一行代码，例如：“变量A等于变量B加10”。注释是描述业务逻辑，描述的应该是为什么这里要加10。当然，这只是一行代码，如果有上下文可能是可以解释为什么要加10的。多年的编码经验让我养成了一个习惯，就是在写代码之前先写注释，注释写清楚了之后再来写代码，这样做往往能够达到事半功倍的效果，特别是业务逻辑复杂的部分，效果更佳。实际上在写注释的过程中就对业务逻辑进行了一次梳理，这种情况下写代码就不要太轻松了，就跟填空题一样。

团队管理

  无论有多好的理念，多好的架构，事总是要人来做的。所以，团队管理是整个开发过程中的另一个重要基本点。人数越少越好管理，这几乎是公认的事实。然而，公司业务的发展势必会不断地扩张团队，或早或晚都会遇到团队管理上的问题。在这里我想从团队组织结构、团队成员以及日常工作方面简单聊聊团队管理。

团队组织结构

  对于公司来说其组织结构必然是层级结构，团队的组织结构也是一样，不同的公司可能各不相同，但是总归是避不开层级结构的。

  通常情况下，金字塔结构是很普遍的现象，其特点在于下层节点总是汇集到上层的某个或某几个节点。那么这种情况下位于管理层级节点的员工就是整个结构的关键点。不但需要承上启下，还要左右逢源，任何一个关节不畅都将直接影响工作效率。领导的意图、公司的目标无法准确传达到下层，导致工作重心不明影响工作效率。拦截下层员工的工作成绩，导致员工离心离德影响工作效率。与同级同事沟通不畅，无法配合影响工作效率。这些场景相信大多数公司或多或少都经历过，处于这种位置的员工可能没有多少精力能够放在业务工作上，大部分时间都花在沟通上了，如果能力稍差点就更吃力了。如果再加上后宫戏，想要把工作做好就别想了。如果公司够大，那么金字塔的层级也会变多，这种情况下整个公司作为整体的运行效率相信不会太高。原因很简单，因为每一层的关键节点不可能全是完美无缺的人。

  扁平结构出现得较晚，并不是把金字塔尽可能的压扁就行了，实际上扁平结构依然是层级结构，只是层级会特意的进行控制，使其不会太多。与金字塔结构相比，扁平结构的特点在于层级少，上层节点对应的下层节点多。这种结构确实能解决金字塔结构的一些固有问题，但是也会产生一些新的问题。处于管理层级节点的员工会被要求具备更多、更强的能力，既要懂业务，也要懂管理，甚至可能还要懂架构、懂技术。完美的人肯定是存在的，但并不是每个公司都有的。所以，对于扁平结构中管理层级节点的员工，其能力、素养将直接决定整个结构是否能够正常工作，把不合适的人放在不合适的位置上就是个灾难。
无论是金字塔结构还是扁平结构，组织结构中的关键节点始终是关键，任职人员素养将直接影响到整体。可以说只要是层级结构就一定会涉及到这个问题，不同的只是程度轻重而已。那么如何解决这个问题呢？基本上可以说无解。可曾看到过上级领导自陈能力不足，请求换人？我想除了离职这种场景没有人会这样做，包括我自己也是。但凡项目有什么问题，大部分情况下都和管理层级的人员脱不开干系。把合适的人放在合适的位置上恰恰是最难做到的，毕竟家家有本难念的经，所以还是那句话，不求完美，但求合适，合适你的才是最好的。

团队成员

  虽然说ChatGPT现在相当火爆，但是目前还没有到可以替代程序员的时候，相信各家的产品都还是由程序员来实现代码开发的吧，想要完全自动化还得再等等。既然工作还是由人来做的，那么做开发的人自然就是整个开发过程中的核心了。工作这么多年，也算见过各式各样的前同事吧，总结了一下，我觉得有三大类的员工可以拿出来说一说。

  【会“偷懒”的】，这里说的“偷懒”是一种另类的褒义词，曾经听过一句话感觉很有道理，“聪明人总是第一时间让工作变得更简单”，当然，耍小聪明不在此列。放到开发这个环境中来看，能够结合工作的内容预想到以后可能出现的场景，从而采用兼容或扩展性更好的方案完成工作，这就是“偷懒”的真谛。这类人总是善于观察、善于挖掘、善于思考，随着工作经历的积累很容易可以实现层级跨越，属于团队必备且重要的角色。但是，兵贵精不在多，个个都是这样的人才，发生冲突的几率将大大增加。

  【会沟通的】，这类人通常自带高情商，无论是工作还是生活中与这类人打交道都会让人感到轻松、舒畅。放到开发这个环境中来看，同样是必不可少的角色。在工作中与团队成员良好的沟通不仅仅能让自身的工作更好开展，同时还能促进团队成员之间信息交流频率以及提升沟通质量，甚至可以提前预判避坑。就个人经历来讲，那种埋头苦干、加班加点，到头来路都走偏了的场景确实不少见，每次见到这种场景时，内心总是充满了无赖与沮丧。当然了，只会说不会做的也不行，就算是项目经理、产品经理这样的角色也一样，岗位任职还是有底线的，只说不做的那是领导、老板那个层级的，级别不到就老老实实做事吧。

  【不是不会只是不想】，这类人最明显的特征就是主观能动性缺失，经常出现的场景类似于,问：”为什么不这样做？”，答：“没人说要这样做”。一般情况下，现在的这份工作只是其职业生涯的跳板之一，打算的是混两年跳槽，薪资又能涨一大截。这种情况很难搞，说白了就是员工对公司、对项目没有认同感，对于他们来说只是一份工作而已，不是事业，那是领导、老板的事业，跟他没关系。当然，并不是说这类人错了，换个角度来看我觉得也是可以理解的，能不能改变这类人的看法就要看公司看领导给不给力了。一些公司里的老油条也可以归到这一类里，有事就做，没说？那就不要说我不做了。混子哪儿都有，怕就怕全都是混子，那就该头痛啦。

  无论团队是由哪些类型的人组成的，知人善用是根本，说起来容易做起来难，办公室政治又哪有这么简单呢？尽力而为吧。

日常工作

  团队管理的日常很琐碎，也不好定边界，涉及的面还广，想要讲清楚讲明白有点难度，这里大概聊聊四个需要注意或把握的方面。

  【抓大放小】 只要大的方向没有问题就不要太在意细节。细节控当然好，但是用错地方也是会造成伤害的。举个例子，员工为了赶进度工作到第二天凌晨，结果第二天上班很疲惫，睡着了，还打呼。这个例子比较典型，从不同的角度来看能得到完全不同的结果。比如说，老板看见了，上班时间睡觉，还有什么好说的呢？上到管理下到员工估计都不会有好果子吃。比如说，不了解情况的其他员工看见了，真牛啊，上班睡觉胆子不小啊。比如说，了解实际情况的员工看见了，佩服啊，累成这样了还要坚持上班，不服不行啊。

  像这种场景作为管理实际上可以做得相当漂亮，也可以做得相当糟糕。就好像口罩期间看的一个新闻一样，一女子载父亲去医院拿药，过五关斩六将，最后还是被拦下。对女子动了手，老人反击也动手了，还大喊录下来没有，最后的结果就是给全国人员看了一场反转小剧。这就是典型的选择了最错误的处理方式，本来可以成为一个正能量典型，结果把自己栽进去。

  就个人而已，如果工作干好了干完了，直接放假也行啊，没有必要因为一个全勤把员工栓在工位上，浪费大家的时间没多大意义。而且宽松的工作氛围也会让员工充满自豪，公司不加班还放假，整个行业都找不到几家能做到，说出去还能给公司打广告拉人气。所以，追求完美、抠细节是好事，应该鼓励，但是一定要用在正确的地方，否则很容易适得其反。

  【形式主义】 形式主义是必然存在的，尤其是在国内的大环境下，随处可见。团队里的形式主义也是长盛不衰，最著名的就是团建活动了，真正通过团建达到目的的少之又少，但是人们总是乐此不疲的不断尝试。形式主义的存在必然有其道理，关键在于如何去做，如何去把握。就个人而言，我认为“对领导对客户要讲形式，对员工要讲务实”。毕竟对领导而言是没有多少机会能够了解项目/团队真实情况的，那么对于领导来说定期的总结、汇报是很有必要的，这样领导才能根据情况的变化做出正确的决策。虽然很多时候汇报会变成一种形式，但确实还是有存在的必要。而对于员工来说，务实才是大家最需要的，整点水果下午茶，搞一顿火锅，没啥事可以提前下班等等，在不影响大方向的前提下这些务实的行为反而能让大家更加的专注、更加的快乐，何乐而不为呢？

  【处事公正】 绝对的公正是不存在的，无论怎么做总是会有人不满意。处事公正至少要做到摆在台面上的事不能太过分。举个例子，女性员工生孩子几个月都没有上班，那么在评定季度绩效时就应该把这个情况考虑进去，而不是说因为其长期以来表现很好，这次季度评定也要发绩效。这种就是没有原则的当好人了，并不是只有季度绩效这一种方式激励员工，员工表现得好，那么在年终、晋升等等方面进行激励一样是可以的。整个季度都没有上班那没有绩效不也正常吗？

  【增加认同感】 虽然说大家都是为了钱进公司的，但是从所有人的共性来说，大家都是需要别人的认同的。小时候需要父母、家庭的认同，上学了需要老师、同学的认同，工作了需要领导、同事的认同，甚至当上老板了，也是需要员工、客户的认同。所以说作为人这种群居性动物，被别人认同的感觉总是需要的。
  那么对于团队来说，如果高层领导或者老板能够给予员工认同感的话，效果绝对差不了。比如说，能知道员工的姓名，能在开大会的时候提一提员工做出的成绩等等，像这些措施都能够直接提升员工被认同的感觉。但是，有一点需要非常注意，在没有掌握真实、完整的信息之前，切勿轻易下结论。一旦出现张冠李戴的情况，抛开尴尬不说，员工能够感受到的只会是不公平。我个人就经历过这种事件，过年开个表彰大会，完了就一半人提出离职，相信所有人都不会想要看到这种结果。想要增加员工的认同感办法还有很多，直接加薪也是认同的一种方式嘛，而且会是大家都欢迎的方式。

  总的来说，团队管理的日常工作内容很多，涉及面也很广，能让项目进度有序推进、团队成员持续进步、产品质量稳中有升那就是好的管理。如何来做好团队管理？这是一个没有标准答案的问题，有人的地方就有江湖，而人就是一切变数的根源。无论是KPI还是OKR，无论是瀑布开发还是敏捷开发，都需要明确一点，不同的人在相同的场景下会有不同的反馈，不要指望搞一套制度/方法就能解决所有问题，即使是当下能够完美解决问题，同样是需要不断优化提升的。所以，团队管理是一个持续不断的过程，针对不断出现的新问题提出更多更好的解决办法，从而推动整体的提升与进步，这才是团队管理的正确姿势。

结语

  近几年我国的蓬勃发展制造业功不可没，而制造业之所以能发展迅猛得益于流水线生产，流水线对提高生产效率的意义相信大家都很清楚。那么，对于开发来说，能够源源不断的，保质保量的产出同样极其重要。话不多说，“一个中心，两个基本点”无论在什么样的公司里总能找到发挥的机会，但是理论必定只是理论，不经历风雨怎么见彩虹。学习、实践、总结，总是一套不错的方法，以上即为个人经验总结，共勉之。