上下文
四月中旬突然接到任务，要求在一个月之内从零到一完成一个公司内部使用的低代码平台，也就是五月底上线。对于一个熟悉公司流程的人来说都是一个非常艰难的事情，从零到一要走非常多的流程，包括资源申请，资源配置，基础代码搭建，生产环境资源申请，各种服务器之前开墙。更何况我入职半年来没有经历过。万幸的是这次过程中有热心同事指导，项目即将上线，这里将这段时间的经历总结回归一下。
问题以及思考
项目周期短
我相信所有做开发的同学都遇到过这个问题，所谓的时间紧，任务重。面对这个问题无外乎以下几个解决办法
砍需求
- 砍需求听起来不大靠谱。其实是有技巧的，需要你作为技术负责人要有业务的敏感度，了解做的项目背景，业务价值，准确找到一些非痛点的需求。这时候再去找产品聊，其实是有很大希望能聊下来的。比如我这次的项目，核心需求就是APP端能访问PC端配置的模板。那其实PC端除开模板配置外，在保证pc端是一个完整的系统的前提下（主要功能能走通），一些细枝末节的功能其实就没那么重要。
- 当然很多时候需求也是没法砍，比如一个toB的项目，还是给领导使用的。这时候就只有考虑增加人手或者加班
增加人手
- 个人对这种方案不是很喜欢，我非常赞同《微服务架构》这本书里面谈到微服务缺点时候说的一句话，“微服务拆分会导致各个成员/团队间只关注自己服务内的东西，尽管他们是一个系统”。同样的道理，如果增加的成员是外部团队，又恰好他只是抱着来打两天工的心态，这样做出来的东西很容易出问题。而且这对于许多团队也是不大现实的事情，毕竟kpi相关不大。
加班
在面临时间紧，任务重的时候，99%最终都会走向加班。这似乎是不可避免的情况。
任务分配相关问题
面临以下几个问题
- 团队人员水平参差，如何保证交付质量
- 方案设计阶段尽可能的简单以及更加具体，细节。
- 简单:对于业务系统，技术就是为业务服务的。能满足业务的技术足以，说简单点，能单体就不要分布式，微服务（在我看来，做好微服务真的门槛挺高的）。尽量找一些团队成员都熟悉的技术。
- 细节: 因为其他同事只了解他做的那部分业务，如果设计不够细节，可能最终会有差异。比如:对于热点数据，都知道用redis。那缓存哪些数据，数据结构是怎么样的，存取场景在哪儿。这些都需要在做方案设计的时候详细罗列出来。对于一些复杂的流程，需要画出流程图或者时序图，来保证交付质量。
- 人员安排阶段
- 需要了解团队成员水平能力，以及功能难易度来进行分配。
- 方案设计阶段尽可能的简单以及更加具体，细节。
- 如何在保证速度的同时，保证代码质量
- 这其实是一件比较头疼的一件事情，特别我还有一些代码洁癖，特别一些复杂功能，短时间内很难想到完美方案，就只有先采用一些妥协的方案，想着后面再改。（根据我多年开发经验，不可能改了。我也知道，所有屎山项目都是这样一次次妥协，日积月累。很简单的道理。如果完美是1的话，就算你每天做到了0.99，连续1年2年过后，也所剩无几了）。
- 我这边的做法，就是在搭建代码框架的时候，尽可能的将一些基础功能，例如异常处理，常见工具类，分层架构，基础配置。这些给搭建好。然后定一些符合团队情况的一些简单规定，比如idea中黄色代码处理一下，不要controller直接调用dao等。- 有条件的情况下尽量每天code review，如果条件不允许，抽空去翻翻代码。严格按照比如阿里的java开发手册执行是不现实的。习惯不是一两天养成的。在开发过程中动态增加一些代码质量规约。
- 需要动态的调整排期
- 做法开发的同学都知道，一些很小的疑难杂症（可能是很简单的问题），一卡就是半天，一天。就算是简单的CRUD，也会或多或少碰到卡壳的时候，但对于赶工期的项目，做任务排期的时候，并不会将这些时间算在里面。也就是说但凡碰到这种问题，就会导致任务的延期。这次项目就碰到这种情况，我这边的反思是对于稍微复杂一点的功能，开发同学先用伪代码把整个流程写下来，然后再翻译一遍，这样可以降低卡壳的几率。还有就是如果碰到卡壳的问题，半小时解决不了就抛出来。
- 与第三方系统的协作
- 特别是双方都需要进行功能开发，这时候，许多团队都会以“自己改动量最小”来方案的讨论与设计，尽管有时候方案不是那么合理。这时候就需要“尽量”的为自己团队争取，所谓“尽量”，就是在方案的合理性与时间中找一个相对平衡的点，如果吃亏太多，这时候能做的就是及时上报给领导。
- 被第三方阻塞:这次项目就碰到了许多次，开发过程中可以做一些mock以及服务降级，但到了联调阶段，需要拉通各方系统，这时候就只有倒计时，然后上报风险了。
- 任务分配不平均
- 由于团队成员能力有差异，所以这次我把复杂的功能都分给了一个同事。导致其他同事中途被阻塞。出现的场景就是忙的忙死，闲的闲死。反思了一下，应该稍微平均分配一下，就算能力稍差的同事做出来有Bug，也不会出现在赶工期的时候，闲置的状态。当然，问题的本质还是团队成员能力急需提高
冗长的各种申请
这个因公司而异，这次对我来说是个好事，熟悉了整个公司的开发流程。
最后的总结
需要提升的地方
整个过程感觉最大的两个需要提升的点。一是我个人能力还需提升，这次项目由于我在设计过程中的不够细致，以及任务分配不够妥善，导致在开发过程中，有的同事忙的忙死，有的同事被阻塞后无事可干 二是团队成员能力的提升。这样的话，就可以规避排期，代码质量等问题。
个人能力的提升
对于我来说，架构，设计能力以及团队管理能力还需提升。这是一个累计的过程，后续也会针对性的看一些书籍，记一些笔记
团队成员能力提升
收获
- 出现问题或者被阻塞时，及时上报，让领导去协调资源，特别是多方团队一起协作时，这点真的很重要。
- 当你作为一个团队的技术负责人时，影响团队比自驱重要太多，如何让团队中能力较差成员无论从代码质量，责任心达到慢慢向你靠近。是作为技术负责人最重要的事情。团队生产力提高，这样你就不用考虑，是保质还是保量这个蛋疼的问题了。
- 并不是所有开发人员都对技术感兴趣，许多人只是把这个当做一份简单的工作。只要他们能完成任务就行了。