第十三篇 - 2023年总结及2024年期待

看了之前写的几篇总结，发现2022年总结并未写，2022年考了PMP，简单记一下吧。

2023年，整体而言按部就班，大体是开心的。

情感方面，最大的变化应该就是交了个男朋友并订婚了，3月初识，6月确立男女朋友，12月订婚，预计明年5月结婚，感情循序渐进，一切好像都水到渠成。

工作方面，由于业务的变化，感觉并未成长多少，之前想精进自动化，不过现在不搞自动化了，想精进管理，由于人员的流动，去做vue的开发了。有好多想法，不过没有实践的空间。

工作中发现了一些痛点：

1. 没有需求团队（即收集需求，分析需求，确立需求等）

2. 没有设计团队（即UI界面设计，架构设计，接口定义等）

3. 没有文档管理系统（无需求文档，无设计文档，无开发文档，无使用者手册等）

4. 没有测试团队（性能测试，压力测试等）

现在的结构就是，提出要做一个系统，系统需要哪几个模块（无具体需求文档产出，口述一些功能，比较宽泛），然后分配给开发人员，评估时间（开发时间），然后各自开始开发，整个开发完成后，各自开发人员花1-2天时间自测试修改好测试出来的错误并写好测试用例，然后各开发人员花2-3天交换测试用例测试对方开发模块，测出的问题，开发人员在花1-2天来修复issue，交叉测试2轮，issue解掉后对之前记录的issue进行验收，然后上线。

这种模式问题矛盾点很多：

1. 首先评估时间，不断的压缩，觉得不需要开发这么久，如果需求很明确，确实不需要，但是架不住不断的需要修改，就比如一个UI界面，之前说做这样的UI界面可以，后来又不断的有新的想法，一直在改改改，改多了就说当时开发时没设计好。

2. 提一些比较宽泛的需求，初始时功能完成后过目，没有提出异议，验收时提出异议，觉得另外一种才是想要的。之后提出问题后，先不着急开发，先去梳理需求，找其明确需求，会被说开发应该要自己想到用户需求，要站在用户的角度。

3. 整个开发完成后自测试1-2天，其中还包含修复测出的问题及写测试用例，若自测试问题比较容易解决，还好，不然赶时间写出的测试用例品质较低。

4. 交叉测试2-3天时间，是根据开发人员写的测试用例来，只包含基础功能测试，且覆盖面不够

5. 验收测试1天，只验收交叉测试的issue是不是解了，品质也堪忧。

6. 有些功能有些共同部分，可以提出来，代码的架构部分也只有一个粗略的架子，比如谁谁谁负责哪个模块，接口定义，命名规则什么都没有，没有一个整合的人，只有开发的人，但是会说开发的人也要负责架构。

团队模式是负责人一名，开发人员3名。负责人负责提意见和验收。2个开发人员各开发2个模块，一个开发人员开发1个模块（复杂一点）。需求，设计，开发，测试均是开发人员，其中负责人在此期间会去使用及提意见（其实就是提需求），经常镀金，搞得时间比较紧张。

其实，文档化管理起来，可以大大节省无畏的争执，做事情都有理有据，不会出现讨论过的东西，一个忘记，一个记得，也能减少镀金现象，但好像不是很愿意给时间去整理文档，觉得文档没必要，没有产出，连使用手册都没有。有心想整理，但忙着开发，没时间。

生活方面，学习了一些省钱小技巧，还稍微学着画了下妆，得益于交了个男朋友，哈哈哈。十一期间还去桂林玩了下，欣赏了一下桂林的山水，那里的遇龙河漂流风景真的不错，不过得注意防晒，还是穿长袖长裤吧。灯光秀的话还是武汉的好看，租个电动车骑行，也蛮惬意的，就是时间久了容易屁股疼。有个小插曲还蛮有意思的，去兴坪古镇寄存行李时，有个阿姨收了10元钱，然后把我们行李放在一个卖水果的摊贩那里，然后我们游玩回来（一下午），那个摊贩说她亏了，保管了一下午，才收了5元钱，我们说不是10元吗，她说只收了5元，所以中间那个阿姨赚了5元差价，哈哈哈。

2024年小目标：

1. 完成结婚大事

2. 去云南旅游

3. 读至少3本心理学的书籍

4. 考系统架构师