关于刚开始接触带队开发
时间：2023年3月5日
这篇文章不是工具型文章，单纯聊一聊我工作生活中的心得体会。经历是非常非常勇敢的行为和非常非常有意义的。很多书其实也是一个一个的经历和经历总结。经历总是迷人的。
前言
先简单介绍一下我自己。我是一名前端程序员，2022年毕业的，但是当时我并没有立即进入程序员的行列。我首先参与了考研考公大军。不过正如我大学时的一位任课老师所说，我并不像个考研的人。我想补充一下，我或许也不是一个考公的人。
哈哈哈，不好意思，我这么久了还记得您这句话。只是印象深刻，因为我当时听到这句话的时候好像我的内心并不排斥，还隐隐觉得是对的🤣。不过老师应该看不到，她是教我们供应链管理的老师，她应该关注不到这儿。
考研我没过初试，考公我没过面试。可以说那段时日我是凄凄惨惨戚戚，严重精神内耗。在生活和内心的重压之下，我准备先到省会找一份工作，先自己养活自己。
22年11月15日，我深刻的记得这天，这是我回到IT的第一天，这天起，我开始了前端开发。我其实入职的是一家小公司，不算大，研发部一开始也就20来号人，所以总有人员不足的时候。特别是我手上的项目，是公司自研项目，但是公司投入的人不多，就我一个前端开发，外加部门经理直接领导我。于是乎我是前端，但不只是前端。
时至今日，我经历了不止前端开发。还有 electron 的桌面端开发、网络安全漏洞复现、漏洞收集分析、视频制作。这些是我在23年夏天开始经常出去做售前的基础。后来我一方面做售前技术支持，一方面收集需求，在经理的指导下做系统优化。后面还做过对产品部分功能模块的原型设计。这也是后来我第一次懵懵懂懂的开始带人一起开发的第一个功能。当时有两个人和我一起开发，我负责前端部分需求实现和 nodejs 后端功能实现，并做总开发进度监督汇报。
这一年的时间中，不乏各位同事对我热情的帮助、经理对我的容忍和耐心指导、还有老板对我的肯定。
1、遥想当初，"package.json"我都会说错🤣，不过那都是过去式。
2、有关的经历我会慢慢通过文字或者视频的形式输出，欢迎持续关注。
又是一次带队协作开发
1 和"队友"打配合的体会
今天我已经不是第一次带队开发了。但是我还是觉得我要把这次真正当成初次。为什么这么说？
这次的开发从调研到设计到整合人马，以及后续我都参与，并且我主要负责。相对而言，这次是更为完整的带队经验。而上一次原型是我画的，针对需求的技术方案调研我也是做过，但是当时我并没有以我是带头人的角度去思考问题，就是简单的，领导要我做啥我做啥，他提出需求，告诉我可以考虑用哪些去做，我就想办法去实现就好了。而这次不一样。我没有完全参与调研，因为这个时候我手上还有很多任务要做，不能完全把时间堆在上面。所以更多的我是让我的"队友"（其实也就只有一个，从公司结构来说她是我的下属）去做主要调研工作，我告诉她我需要她调研什么，结果以什么格式呈现给我。完成后我就她给我的信息做开发计划。
小体会：
要安排下属做一件事情的时候，告诉她"主体是什么"、"我需要的是什么"、"呈现形式是什么"，这将能带来更好的收益。
因为下属也是实习生刚转正，她其实还有很多在汇报或者其他工作上考虑不完善的地方。那这个时候就需要有这样的模式，能够让她快速知道自己要做什么，怎么做。她就不会胡乱给你信息，增大你信息检索的压力。我也明白了，为什么说领导更多时候就是在乎结果。因为直接使用结果对领导是更高效的。
2 开发计划书
开发计划我之前从未写过。我也好久没有一个 word 文档是自己从头到尾一个字一个字码出来的。我也更深刻的感受到了之前大学时期参与 "互联网+" 创新创业比赛中写项目计划书给我带来的思路优势了。我的开发计划书也更有了一点逻辑性。
从市场环境出发，到产品涉及的目标客户的需求共性，来作为开发计划的大背景，也是梳理需求的重要依据。再到需求点分析，需求特征分析。通过需求分析找到实现需求的重要做法。有句话说的好，问题的答案往往要从问题本身去寻找。（不用查了，这是我编的🤪）然后依据需求点要实现什么样的功能。最后是做前端的页面划分、功能描述、后端的数据库设计等。
小体会：
软考除了能帮我们减税、落户加分，还可以帮助我们有系统意识以及设计思想。
23年下半年我参与过一次软考中级考试，备考的经历不长，只有一个月，但是针对"软件设计师"的学习真的让我更好的理解了工作中的一些事情还有项目、电脑上的一些思想。有些计算机的思想甚至能帮助我在生活中拥有更为清晰的思路。
3 动工！小组会议
开会前我可担心了。因为产品所面对的是能懂开发的开发者，产品相对而言更有一些开发的专业性。本身我就是开发者，很容易就会去用我熟悉的词汇去讲，然而这未必是 UI 或者 测试 他们能接受的信息。
有之前和其他部门同事的交流以及和客户交流的经验，我非常明白这点的重要性，所以我本来可以在上午直接开完的会议我硬生生拖到了下午来开。为什么？我做了我能想到的各种情形的回答备案，以及整个会议的把控大纲。和UI我要说明什么，和测试我要强调什么。
但是我还是考虑不周😂。
- 对UI，我没有做到更为简单易懂的沟通。我的开发计划书中有对各个页面的功能描述，但是那只是文字。根据文字大家能想想到的情形是不一定相同的。后来我用纸笔给她边说边画，毫无疑问这是低效的，但在当时这是没办法的办法。会议结束前，UI 也告知我，如果没有原型或者草图的情况下，可以考虑给一些竞品的页面和她说，然后说自己需求，这样会更容易理解我想做什么事情。
- 我考虑了UI、测试，但是我没有考虑开发。因为我和我的"队友"是负责前后端开发的主要人员，我给她的定位就是前端开发，我习惯了，所以我没有想过会议上要和她说明她要做什么。以至于她会议结束的时候立马问我她要做什么。
当场我也立即意识到了自己疏忽了😂。考虑的还是不够周全。希望我今后不会再发生这样的事情。
小体会：组织者真是个不好当的角色，他应该尽可能考虑周全，不管是在事务说明上要让所有成员都明白、还要在工作安排上有明确完整的分工，即使对方知道了也应该在会议上明确说明。
幸好我们都是一群年轻人，互相都很好理解。
4 向上汇报------我是怎么避免被压工时
通过小组会议，我不仅要对各个成员的工作做安排，同时也要对任务的工期要有把控。而这个工期的情况，也是需要向上汇报的，这是告诉他什么时候来验收。
这个时候也有一些学问。相信有很多同学被压过工时。我也被压过。我还有过因为自己过少的考虑到工作情况的复杂性，没有给自己留够时间，周末还免费加班过一次。（当时年轻，也是不懂事，不好意思去提加班）。
而这次要开发的内容我之前也没有开发过，而且其中存在很多变数。这个时候是非常难和领导谈判的。因为在领导看来，这些任务就是非常简单的。就比如这个场景："这个需求，我分分钟就写完了，哪里还需要这么久？你这个时间我不接受，今天下班前一定要出来！"
大学的时候我也学过IT项目管理，我也知道要有工期预计，这也是对成本的估计。但是我这个时候真觉得是扯淡。因为没办法预估啊，太难了，我都不知道会有什么样奇奇怪怪的情况等着我。所以我这次学乖了，我要多估计一些时间，要给领导说清楚我需要这么多时间的原因（就是表明可能存在一些未知的困难，或者手头上的事情还有很多，强压我赶不过来等等）。
我也开始觉得我需要学一学怎么"讨价还价"了。
小体会：
要量力而行，稳妥行事，切忌冲动吹牛夸海口，学会"讨价还价"。
目前能总结出的就是这么多，我犯的错误希望大家可以引以为戒。另外，我也想更多的学习有关领导力的知识还有技巧，欢迎交流。
去经历，不去后悔。保持热爱，奔赴山海！
持续更新中 ... ...