有将近两个多月没有更新博客，也没写过一篇博文。因为最近太忙了，除了工作强度高之外，每天的工作状态和节奏也不对。
11月中旬公司进行了大的组织架构调整，我所在的业务中心被重组，原来的大领导变成总监，总监变部门领导，部门领导变普通员工，因为上层政治斗争的缘故，我们整个部门都沦为人力资源中心。 那段时间大家都人心惶惶，坚持了4个月的数据中台项目也被即刻叫停，所有没在有合同额项目上的员工全部要出差，在有合同额项目上的人被严重压缩。最终12月的第二周，我们java五人小团队4个人被安排到北京出差，作为人力资源去支援总部业务线的其他项目。新的环境，新的项目，新的团队，新的挑战。
从最初抱着一定要做好工作，到现在觉得无法再待下去，短短2个多月的经历，刷新了我对团队管理的认知。我不知道是因为我们的抗压能力太差，还是北京那边团队管理太差，或者说是因为我们做事方式不对，还是因为北京团队那边做事太无章法。总之，我现在站在圈子里面，或许会存在看不清真像，有失偏颇的认知。但我还是想静下心来想一想，问题到底在哪里？所以有了这篇非技术的博文记录。 我想记录下现在经历，写下我对项目管理、团队管理的看法，以及我认为怎样的团队才是有战斗力的团队，怎样的团队氛围才是健康的团队氛围。
这里先列一下北京那边团队的工作节奏和方式：
工作模式：无条件无理由强制早十晚十加周六。
【对于加班，我是不排斥的，我始终认为IT行业的加班有时候是不可避免的，有些时候就是留给开发的时间太短，就要求你加班，有的时候是你不加班尽快做出来，就失去了机会，这些都是不可避免的。但是对于因为管理问题造成开发进度缓慢而要求所有人不可不加班或者有事没事就加班的制度，我是一点都无法认可的】
团队组成：北京的团队有大概10几个人，有两个专职前端，剩下的都是后端服务开发。一个开发负责人，一个项目产品负责人。
使用的技术：前端使用vue。后端使用基于dubbo的微服务架构。包括有客服中心、客户中心、在线中心、热线中心、工单中心、机器人中心、知识中心、平台中心、权限中心、会话中心、鉴权中心等几十个微服务。 前端也是针对每一块都有一个独立的vue工程。
【这块在部署和发版的时候使用jenkins，但是在工程的管理上，我认为是有点乱，任何一个小的功能都是让去做一个独立的工程，微服务的架构是提倡把相对独立的功能放到一个独立的微服务中，但是不是无节制无思考的进行服务的划分和工程的创建。按照目前的方式，后期的运维将会是非常大的问题，不做负载的情况下也有差不多将近30个应用要跑。有些应用可能就一张表，服务可能就三四个接口。】
我们之前一直用基于SpringCloud的微服务架构，对于dubbo没有太多了解。在刚进入项目组的时候，产品负责人开了一个会，给我们大概讲了一下项目是干什么的，目前这个产品做成什么样子了，后续预计想要什么功能。 之后，直接安排我们四个人做租户管理和工单管理。然后就没有然后了。
我当时第一感觉就是团队的管理肯定是混乱的，没有任何的开发规范说明，没有任何的开发环境说明，也没有任何的培训，直接让开始工作，而且每天每半个小时问一次进度。 大家都是一头雾水。我后来直接找开发负责人，问他开发相关的环境，工程在哪里，有什么开发规范要求，数据模型是统一设计，还是每个人自己设计等等。 得到的答复是他也不太清楚，让我问某个开发人员。 第一周磕磕绊绊的通过问东问西，把整个开发环境摸熟悉，可以把项目跑起来。这个过程虽然很糟心，很讨厌，但是也无所谓，通过问别人、自己查总是能解决。但是后面的事情，就让我觉得非常不可思议。 首先是架构的设计，产品是采用saas模式进行开发的，把各个相对独立的子功能都设计成一个独立的微服务，团队内部可能每个人会负责一个微服务。每个微服务有自己的数据库。这就意味着，数据库不是统一的。在开发的时候，基本上谁负责那一块，自己就去做表结构的设计，也不管是否和其他有什么关联。 这其实是有很大的问题的，比如说：虽然表分库了，但是还是有关联的，热线中心在处理话单、客户信息的时候，一定是会和客服中心有关联，但是热线中心的相关表字段，可能完全和客服中心不同。例如：客户中心设计客户id是uuid。但是热线中心客户id使用的是bigint。这就乱套了。 除了这些在整体设计上的问题之外，还有诸如分布式事务、网关异常等等各种问题，我们提出来之后，开发负责人说他不懂，让不用管这些，我当时就震惊了。因为涉及到多个微服务，所以不可避免的存在服务之间的调用，在进行服务间调用联调的时候，往往是最耗时的时候。因为我们最初做的租户管理相对独立，所以前期主要是看他们在联调对接，我发现这其中问题非常大，开发的时候，每个人都很快的说我的服务开发好了，没问题了，但是联调的时候，总是有各种问题，这个变量对不上，那个入参对不上，这个出参不是想要的。 因为某一块功能联调不成功，其他所有人都要等着，不能走，在统一测的，往往都是一两个人在反复的发版和联调，其他人干等，等到晚上12点左右，实在不行了，就下班回去第二天继续。 我对于这种工作方式实在是非常不能认同，出现这种问题的最主要原因还在于团队管理和规范的问题，服务的设计和对接，应该有相对严格和标准的文档，他们提到有文档，但是文档都是流于形式，往往先写文档，但是在后续开发过程中的调整没有对文档进行更新，最终联调的时候，联调双方对接相差十万八千里。
对于开发的细节问题，我们可以按照自己之前的规范尽量避免，但是最让人无法忍耐的还在于需求以及功能设计。 团队名义上是有一个专业的产品负责人，其实他也是整个团队的负责人，在进行任务下发的时候，他往往就是简单的一两句话，剩下的就没有了，你继续去追问，他的很多想法感觉都是没有进行深入的思考。我对这种方式非常的不认可，如果因为身兼多职，没有时间做原型设计，那功能的设计至少要说清楚，能有一个合理的闭环，而不是随口的一句话，然后在开发出来之后，又说这不是我当初想要的，让重新返工。 如果功能需求都是模糊的，那在开发的时候，开发方案一定是会被返工，明明可以通过前期稍微花些时间把需求理清楚，功能说清楚再开发，非要开发直接模糊的先开发然后再不断返工调整。 他们称这种工作模式为敏捷开发，快速迭代。但是我对此不认可，敏捷开发、快速迭代不是这样玩的，我们以前做咨询大厅、做在线接入产品化的时候，也都是快速开发，不断的版本迭代，但是那是建立在版本不断完善不断补充的节奏，而不是不断推翻不断返工的模式。
即便是敏捷开发，对于一些小的迭代，也是尽量要把范围内的需求梳理清楚，在大方向正确的前提下，设计的要尽量通用，为后续的开发做准备。敏捷开发相比瀑布流的开发不是更简单，其实是更难，对团队的要求更高，因为敏捷开发要求在每一步的设计更细更具有前瞻性的思考。
功能上出了问题之后，没有人知道是什么问题，都觉得和自己没关系，是不是别人的服务造成的，这就造成在问题排查上增加困难，测试在测试的过程中，遇到bug不知道应该找谁，有新功能添加的时候，往往就是一句话，剩下的设计一概没有了，全靠自己发挥和猜想，这些管理上的问题至今都是这样。
我认为不管是开发一个系统还是做系统的某一个功能，应该谨遵的步骤如下：
（1）在有限的范围内尽可能明确需求
（2）在已知明确的需求前提下，设计产品原型图
（3）根据产品原型图，设计数据模型
（4）根据数据模型结合产品原型图，进行接口设计
（5）接口文档的撰写
（6）开发、联调测试
在安排每个人的工作的时候，至少要保证每个人能清楚的知道自己要做什么，涉及哪些页面，对应哪些数据模型，要写几个接口，接口的出入参是什么。
后台接口开发方在同前端进行联调对接的时候，完全以接口文档约束为准，一定要摒弃口头商量，在接口出入参发生变更的时候，一定要第一时间修改和完善接口文档，并通知相关对接的人。
我们之前的做事方式基本上是严格按照上面的方式来的，有需求或者项目的时候，我会进行需求的梳理和转化，将抽象需求转换设计成相关的产品原型，并同客户进行沟通确认。然后设计表模型，安排开发。团队内部的每个人在接到任务的时候，是非常的清楚自己要做什么，涉及那些表，界面是什么样，交互是什么样的。而不是像现在开发人员接到的任务就是原始的需求，就是一两句话，全靠开发人员自己去设计。其实也不是说开发不能设计，但问题是涉及到多个微服务，涉及关联的东西，没有一个全局统一的设计，没有一个统一个管理，那产品是要出问题的，不光是产品质量问题，更重要还在于功能对接、细节交互上。
我认为这里面有一个至关重要的点，那就是需要有一个人，他对系统所有功能、设计、技术细节都能把握到位，在进行表结构设计或者功能设计的时候，能够进行关联考虑，确保设计的功能是有意义有关联的。承担这个角色的人可能完全不用写代码，但是基本会清楚每个接口的大致逻辑。在出现问题的时候，可以迅速定位到问题在哪块，在出现功能设计分歧的时候，可以拍板给出明确的调整建议。 我认为这才是一个产品负责人或者项目负责人所应具备的最重要的能力。
这里要区分下互联网公司的产品经理，我始终认为，脱离技术基础的产品经理是有缺陷的，这也是为什么总是会有各种新闻说研发和产品互相折磨。据我了解的有些大厂的产品经理可能不关心技术细节，所有的功能设计、产品设计都从用户角度出发进行设计，所以功能设计发生变化的时候，可能对于产品来说，就是一个小调整，但是对于开发来说，可能是非常大的调整，这就造成一些不必要的麻烦。 这样的产品经理，我认为中小企业或者小团队是很难效仿的。
更多的时候，我认为站在用户的角度，以普通人使用的视角去思考问题，用最简单的交互实现客户的诉求，然后给出哪怕简单手划的原型图。这是在开发之前必不可少的一步，可以把表结构的设计和具体的接口设计、逻辑设计给到开发人员，但是产品或者需求负责人至少要把需求能表达阐述清楚。
另外，在团队的管理方面，我更偏向相信我的队友都是积极主动的，以前负责的项目，基本上在进行任务划分之后，大家都会积极主动的去做事情，分配任务的时候，因为需求以及功能我能设计的足够细，所以每个人基本上能比较准确的估算出开发时间，在deadline之前，大家都能按时完成任务，不用每天几次的问进度。 因为我自己心里非常清楚每个人应该做成什么样子，是什么进度，我也相信大家。但是在北京这边，负责人不深入了解功能和需求，无法沉下去，在上层压力之下，他每天都会逼问进度，这种不断强压的工作方式，让我们也非常的不舒服。说到这里，我也觉得北京那边具体开发的同事，还是很厉害的，至少他们更有韧性，因为很多时候，出的问题不在于他们，而在于管理以及工作安排不善造成的，但是锅都是他们背，即便如此，他们还是会忍受着去工作。我对于他们不讲究做事方式的行为不认可，但是对于他们的工作态度和韧性表示尊敬。
断断续续说了这么多，也先这样记录吧，也许每个人的位置不同，所承受的压力和所负责的事情不同，所以看待问题和解决问题的思路也不同，我不知道自己对还是不对，我也不能妄加评论说他们一定不对，但是项目进度和每个人高压的工作节奏不会骗人，这中间一种有哪里出了问题。 我按照自己的方式接下了我们所有人的任务并分解再开发，我把我团队里的成员尽量“保护”住我也不知道是好还是坏，这些就交给时间来验证吧。