春节回来之后，调整到一个新的团队工作。
团队，是已有的；所用的技术栈，不熟悉；所做的业务领域，也涉猎甚少。挑战比较大。
管理层对团队的产出不满。我的首要任务，是提升团队的效能。
目前团队的软件研发管理没有套路，比较随性，出现的很多问题都是软件研发中常见的。
在这种情况下，我选择先把自己当成一个教练，梳理过去的经验教训，根据团队当前的情况，进行选择和裁剪，在个别项目中陪着团队用起来，形成适合这个业务、这个团队的干法。在这个过程中，必然会带来一些改变：习惯，规范，人，人和人之间的关系。公司有惯性，团队有惯性，要进行改变，不能下猛药，要慢慢调理，从小处入手，从接受意愿强的部分开始做起来，产生效果，再逐步推广。
同时，一边当教练，一边当学生，学习新的技术栈，学习新的业务领域，让自己尽早能下场成为队员。
在这个情况下，要求自己把软件研发的套路，提炼出来，成文，以便于团队内的沟通。
领域：应用系统的软件研发
主要内容，可以用下面这些关键词来概述：
-
业务分析：对象关系图，状态图，活动图，用例图，外加报表需求。
-
分析和设计过程：静态模型 => 动态模型；建模结果 => 存储结构、内存数据结构；前后端对接的restful API列表。
-
项目scope：用例图 => 功能特性（叠加非功能特性）=> 任务拆分 =>工作量评估（前端、后端、测试）。
-
项目过程：项目启动，项目计划，检查点，敏捷，复盘。
一、业务分析
做应用系统，是为了解决业务问题。
要解决业务问题，首先得理解业务，理解一个业务有哪些参与者(Actor），他们分别有哪些诉求、哪些问题。
所以，首先要从业务的理解和分析入手，进行业务建模。
这几年业界提得比较多的DDD，也是业务建模的一种方法。识别业务对象，划分子域，设计聚合关系，也是其重要组成部分。
我习惯从三张图入手：
-
对象关系图
-
状态图
-
活动图
这里的对象关系图，接近于UML中的类图，目的是识别业务对象，以及它们之间的关系。状态图和活动图也基本上是UML中的定义。
对我来说，这三张图承担了Ubiquitous Language的作用，作为业务方、产品、开发、测试等项目成员之间用来沟通业务和方案的通用语言。
识别业务对象，是最基础也是最核心的。
对象关系图，可以帮助我们识别和梳理业务对象及其关系。一般需要多张图，才能把一个系统的业务对象及其关系都描述出来。对象之间的关系比较复杂时，还需要从不同的维度，分别用不同的图来描述对象之间的关系。
关系的描述，简单粗暴地，区分1对1、1对多、多对多就可以了。去年我发现飞书上画UML图的工具不错，可以用聚合、组成、扩展这些标准化的关系，效果更好。
样例1：1:n 关系
样例2：用 聚合、扩展等标准化的描述
系统的使用者，一般也会在对象关系图中进行分析。
对象关系图，属于静态模型。
动态模型，则用状态图和活动图来描述，两者可相互印证。时序图，用的比较少，一般只在调用关系比较复杂的情况下，或者跟第三方有比较多的调用关系时才画，一般在设计或编码阶段使用。
状态图：首先要识别对象是否存在状态。如果有状态，有哪些状态；是否存在多个维度的状态；对象之间的状态，是否存在关联性；
活动图，一般按泳道图的方式来画。如果业务比较简单，也可以简化。
业务建模一般就用这三类图。
在撰写这三类图的过程中，自然会形成名词表，以及各种枚举值等主数据。
除了业务建模，还需要梳理系统的需求边界，设计系统功能，所以还需要用例图，从业务目的出发，分解出功能点、特性。
每个功能点中，除了业务逻辑，可重点说明对关联对象的限制、影响。
报表需求，也是在这个阶段需要收集的重要信息。从报表中可以反推和验证业务对象及其关系。报表的统计需求，能帮我们发现一些维度、主数据，发现一些容易被忽略的东西。另外，报表对数据存储结构设计的影响也比较大，需要尽早收集。有的产品负责人会忽视这一点，认为报表需求可以在系统跑起来之后再做。在过往的工作中，多次遇到在做报表的时候，发现数据缺失，或者数据的颗粒度不满足需求，导致产生很大工作量。为了满足报表需求，调整数据结构，增加数据冗余这类工作更是常见。
在慧点科技的时候，到客户那里调研需求，除了到各业务部门访谈，索要组织架构、索要各种表单和报表，就是标准动作。拿着这些东西，结合访谈内容，结合每个业务流程进行梳理。二十年过去了，这招依然管用。
业务分析，是平时我最关注的，也是在实际工作中花时间最多的。
二、概要设计
设计文档，一般只做到概要设计。除非有特别复杂的业务逻辑，单独画流程图，做详细设计。
文档，缺少越好。
自己不看的文档，不要写；可写可不写的，不要写。
文档管理最难的在于更新维护，保持其up-to-date。写得越多，维护工作量越大。没时间维护，文档的有效性就变差，慢慢得就没人看，没人看就更不会有动力去维护，恶性循环。
概要设计，我主要关注两部分：
-
数据库存储结构
-
API清单，目前一般是Restful API清单，用于前后端对接，或者服务之间调用。Restful API清单，只需要写到 method 和 url 就可以，不用详细描述参数和返回值。
除了这两类之外，还会就某些专题要求提供设计文档，例如部署拓扑的设计、特定模块的代码结构设计。
对于设计，我的观点：
-
设计要解决的是结构性的问题。数据结构、代码结构、接口定义，都涉及结构，所以都要关注。不影响结构的细节，在设计阶段知其大概就可以。
-
设计要回答为什么。为什么选择这个方案，为什么不选择另一个方案。我经常发现“为什么不”是一个好问题。在设计过程中，要找到影响设计的关键点，每个关键点，至少提供两个选项，并说明为什么选择A而非B，这样才能把设计决策说清楚。
文档的具体形式，不一而定。
可以用思维导图，可以用Excel表格，可以用ppt，也可以手写手绘拍照存档。数据结构的描述，可以单独写文档，也可以直接引用代码。
三、项目管理
工作中经常要面对一个问题：这个事情什么时候能做好？
很多时候，挺难给出一个简单的答案。
把过程拆解开来看。
首先是确认目标
业务方经常只是给出一个笼统的描绘，需要先搞清楚其真正的诉求，搞清楚目标。
目标的描述，要从业务角度来进行。结合场景，描述要在系统中让用户能完成哪些事情，并把这些事情排出优先级。实际操作起来会复杂一些，不只是比较实现A和实现B哪个更重要，很多时候的比较是类似A这件事的体验从60分升到80分，跟B这件事从系统不支持到能支持（60分）的优先级。需要进行拆解，拆成比较小的条目，以便于比较，即WBS（Work Breakdown Structure）。
画用例图把用户诉求细化为具体的功能点、特性点，有助于找到用户的关注点，有助于安排优先级。除了功能特性，非功能特性，业务规模、性能、可用性、安全性，这些也需要了解，加到工作任务里面。
需要注意的是，拆解之后，我们不能忘记真正的目标，是为了实现业务目的，不要让自己迷失在繁多的功能点里面，忘记了本谋。
其次是工作量评估
从在巴克莱开始使用Scrum之后，我觉得Story Point这个方法挺好。根据业务对象的属性多少和复杂度等因素，综合评估，根据基准任务来进行规模的评估。例如，把一个不超过10个属性的简单对象的CRUD功能，设为基准，对应2个SP，其他任务就根据和它的对比来估算。一个任务的工作量估算值只能从1，2，3，5，8，13，21，∞中进行选择。
前端、后端、测试，各自评估自己的。
评估的工作量，包括设计、编码、自测、集成测试和问题修复，包括过程中所需的沟通、文档编写，从接受任务开始，到完成交付目标为止，需要完成的所有工作。团队里每个人都要对每项任务提供评估。
如果不同的人，提供的估算值相差很大，例如 3 vs 8，就需要沟通，这种情况，常见的原因有两个：1. 对任务的目标和边界理解不一致；2. 实现方案有重大分歧。
尽早发现问题，尽早沟通解决。
第三，才是排期
如果积累了数据，每个人每周能完成多少个Story Point，排期就比较容易。
项目的时间和人员经常是固定的，这时就需要根据每个任务的客户价值和工作量，综合评估优先级，选择项目范围。
现实中比较麻烦的是一个人同时在多个项目中。有不少人，特别是不具备软件研发背景的，希望工程师并行工作。一个人同时处理多个项目，分时并发，看起来很高效。但一个人在多个任务之间来回切换，思路切换，环境切换，都会产生消耗，而且很容易影响质量。
另外，任务之间的先后依赖关系，多人协作时的进度协调，关键路径和优先级的调整，这些都是日常要做的。小团队小任务，口头沟通就够了。中等规模的，甘特图这个古老的工具就挺管用。
这些都是常规动作。
在项目管理上，我看到的比较多的问题是两个。
一个是沟通不足，信息不对称。信息不对称的点很多，比较大的问题是一线员工只看得到眼前的具体任务，不了解背景和目标，对后续的工作安排没有预期。需要通过项目启动会、晨会、周会、部门月会等方式，一方面自上而下传递信息，另一方面也让一线员工有机会发出声音。这里有很多具体的工作要做，才能形成合力。
另一个是不复盘，不闭环。个人、团队，缺少复盘，没有从方式方法上进行改进，低水平重复。
我的套路，大体也就这些。
没有妙招，只是本手。具体的工具、方法，也非独创，都是业界十年前、二十年前、乃至更早就在广泛使用的，对很多人来说，基本功而已。
我的套路只是把这些基本功做到位，做扎实。
在现实中，无论个人、团队，只要把基本功做到位，就可以达到前20%，在市场上具备竞争力。
最后一点，无论流程、工具、方法有多好，承载研发体系的，是人。带团队，最重要的一条，是把人当人看，而不是工具或资源。关心队员的成长，关注他的喜怒哀乐，才能够真正建立信任，形成战斗力。
黄鹤
2023-03-18