java离职交接文档_金融小公司java开发岗位日常

33b3279d6159707f52b30e46a1006d5b.png

从今天开始搜罗在各种公司、各种团队中,程序猿的日常工作、生活和感受。毕竟团队氛围是主导工作开心与否的关键。好不容易战胜面试官、斗倒HR,别再被团队氛围打倒,弄成上午入职、下午离职就不好了。也算是为找工作打个预防针吧。


一、公司团队背景介绍

团队从招聘第一个HR到停业务散伙用时1年多一点,目前公司可能还在。

先吹一波:互联网金融公司,多家大型企业联合投资百亿,坐落于北京西三环丽泽商圈。目的是打造京津冀金融企业,为了冀的发展做企业投资。有金融基金营业执照,倒闭前还给所有买过基金的客户发消息,主动退还了所有用户的投资款。没卷钱跑路,真是良心啊。

写字楼怪相:那几栋楼里边搞金融的公司有很多家,啥放贷款、做基金的,经常有各公司业务员带大爷大妈们聊业务。当然没过几个月,就出现公司跑路,大爷大妈集体讨债的情况。

团队规模:50人左右,包括5个小团队。产品(约5、6个)、技术(约30)、运营(约6、7个)、人力(3个)、总经理直属团队(3、4个)。

技术团队(程序猿团):由于写程序猿日常,所以着重介绍一下技术团。后端开发10人(Java为主),前端(h5、ios、android共10人),测试(5人)。技术总监和架构师是牛人,带队井井有条。测试大姐也是牛人,被总监视为工作以来见到的最强测试。不过猿小明一直游走于小公司,也没亲眼见过啥牛人,在眼里他们就已经很犀利了。

c1aed1e1b3d29a57feb8eb2e2c328240.png

二、java开发工作日常

这里可能是非典型的小团队工作模式,感觉很多团队根本无法做到像这个团队如此井井有条。这也是猿小明待着最舒服的一个地方,即使最后被裁掉了,也挺感谢这里的团队所带来的体验。

这里采用的一种叫做scrum的开发模式,每2周一个开发周期,严格遵循,与绩效挂钩。谁出问题拖延开发进度谁负责任。当然每个周期做什么和人物分配都是由架构师和技术总监严格评估的。

下面就开始记录2周的生活,一次又一次,直到散伙。

1、前戏正式进入迭代开发前,有很多准备工作,这个吾等初级java开发是接触不到的。后来想想前边一定得有这些准备,要不然不可能开发如此顺利。

  • 产品组设计迭代。
  • 团队leader、产品leader、技术leader、架构师讨论产品设计可行性。

2、整体开发过程

1到2天接收产品需求、程序设计。0.5到1天出接口文档给前端。4到5天程序开发,修改接口不合理地方。1到2天联调,提交测试。2天修改测试提出bug。第二周周五晚或者第三周周一上线。

3、详细开发流程(采用trello看板控制进度)

第一周

周一上午:架构师召集相关模块开发和测试人员听产品讲产品设计,纠正部分设计不合理地方(90%流程已经确定),产品讲完后回去修改。java端负责人分配任务,前端负责人分配任务,测试负责人分配任务。产品trello看板创建需求任务。

周一下午:相关开发人员进行产品反讲,业务逻辑复杂的话是java开发主讲,页面转换复杂的话是前端主讲。产品确定理解无误,开发人员回去进行程序设计。开发负责人在trello看板创建开发任务,分配到开发人员。

周二上午:java负责人或者主开发人完成数据库设计,后端开发讨论修改。

周二下午:测试人员给出测试用例,给产品和所有相关程序开发人员讲解,有异议进行修改。经过同意,开发按照用例标准进行开发。与用例不一致的话视为bug,bug数影响绩效。

周三上午:java端给出接口文档,发布文档链接给前端开发。开发人员从trello看板领取任务,将任务分解成接口级别,添加到trello看板。并将trello看板任务拖动到开发中。

周三下午~第二周周一下午:java程序开发阶段。有问题或者忘了啥,问产品。有接口修改与前端讨论,修改文档。接口开发完成通知前端。将trello看板任务拖动到完成。


第二周

周一下午~周二下午:java开发与前端联调测试。所有接口跑通无问题,通知测试,并将trello看板任务拖动到待测试。

周三~周四:修改bug。

周四下午可能有coding review。由架构师或者自身开发带领进行代码审核。对本次迭代开发有难度的地方进行讲解,需要修改的会后进行修改。修改后需要测试重新测试。

周五:上线会议,所有本次迭代上线相关人员,列出上线所需内容。无遗漏,各自回去准备,将文档或者文件发送给运维。

周五晚或者第三周周一:上线。测试人员进行预上线系统测试,无问题后,切换到正式系统。测试进行正式系统部分功能测试,以确定无误。然后大家就下班了。


总结

上边哪些地方出现问题,都是由相关人员直接负责,直接扣绩效。产品需求在进入开发阶段修改的话,需要各leader进行确定,评估影响范围和延期时长,重新规划排期。如果是产品逻辑问题,由产品负责。

就这样每2周一次迭代,程序员们过着幸福和充实的日子。8月上线,12月基金销售额突破5000万,大家都沉浸在欢乐之中。突然有一天,团队最高leader离职了,他在这也就10个月。真的非常意外,大家都很不解。后来有个有意思的消息,“公司定的今年任务是20亿”,哈哈哈,团队只完成了5%的任务。

就这样莫名其妙的开始裁员,留下一些大佬做善后工作。裁员没几天,基金业务就暂停了,开始通知用户返还基金。据说最后一个程序员在那坚持了将近2年,才被裁掉,真是犀利。

哎,美好的时光总是短暂的,这里的coding review让自己学到了不少。是这2、3年java生涯一次真的提高吧。

如果觉得这篇文章值得细品,点个赞,这样下次就可以在你的首页动态里找到文章。

也可以关注@猿小明,及时获得各种公司、团队日常工作生活信息。

也可以关注公众号「迷茫猿小明」,实时获取学习资料、职场趣闻,一起讨论分享职场生活。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当准备离职时,编写一份全面的交接文档对于确保后续维护和开发工作的顺利进行非常重要。以下是一个Java后端离职交接文档的示例,你可以根据实际情况进行调整和补充: 1. 项目概述: - 概述项目的目标和背景。 - 列出项目的关键功能和模块。 2. 技术栈: - 列出项目使用的Java版本,框架和库。 - 提供相应的配置文件(如pom.xml等)。 3. 运行环境: - 列出项目所需的操作系统、数据库、中间件等。 - 提供安装和配置这些环境的相关文档或脚本。 4. 数据库设计: - 给出数据库结构的ER图或表结构定义。 - 列出表之间的关系、索引和约束等。 5. 代码结构: - 描述项目的代码结构,包括各个模块和包的职责。 - 列出重要的类和方法,并说明其功能和用法。 6. API文档: - 提供项目的API文档,包括请求和响应格式、参数说明等。 - 如果有API文档生成工具,也可以提供相关脚本或配置文件。 7. 工具和开发环境: - 列出项目中常用的开发工具,如IDE、版本控制系统等。 - 提供相关的配置文件和使用说明。 8. 部署和运维: - 提供项目的部署流程和脚本。 - 列出常见问题和解决方法,如日志查看、性能调优等。 9. 测试和质量保证: - 描述项目的测试策略和框架。 - 提供相关的测试用例和测试数据。 10. 问题记录和解决方案: - 列出项目开发和运维过程中遇到的常见问题和解决方法。 - 可以包括一些技术难点的解决方案。 11. 待办事项: - 列出项目未完成的功能或改进点,以及对应的计划或建议。 12. 联系方式: - 提供离职后的联系方式,以便于同事在需要时能够咨询你。 以上是一个简单的Java后端离职交接文档示例,根据你所在的团队和项目的实际情况,你可以根据需要进行适当的调整和补充。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值