1. 项目需求迭代记录模板
需求迭代资源
对接人清单
| 产品 | 前端 | 后端 | 测试 | UI | 项目经理 |
|---|---|---|---|---|---|
| 产品对接人 | 前端对接人 | 后端对接人 | 测试对接人 | UI对接人 | 项目经理对接人 |
备注:如果对接人有多个,要注明哪个功能与谁对接。
时间节点
| 开发时间 | 联调时间 | 提测时间 | 上线时间 |
|---|---|---|---|
| 开发时间 | 联调时间 | 提测时间 | 上线时间 |
依赖说明
4.再比如说,跨应用跳转,依赖对方的接口提供跳转参数
3.再比如说类似管理者小结之类的图表类的界面,后端不造数据,页面什么也不展示,影响功能调试。
2.再比如说客户认证--客户详情,依赖企微登陆,不登录获取不到用户数据。
1.比如说必须在管理后台或企微后台配置相关的权限,才能看到页面。
本次功能迭代改动点
| 提交记录链接 |
|---|
| 序号-贴出本次需求迭代的git/svn代码提交记录链接 |
高频使用的代码片段
-
代码片段1
-
代码片段2
开发中遇到的问题
问题2:
-
问题描述:
-
解决方法:
问题1:
-
问题描述:
-
解决方法:
测试阶段(严重缺陷)+ 生产问题记录
缺陷2:
-
问题描述:
-
解决方法:
缺陷1:
-
问题描述:
-
解决方法:
经验总结
3.如掌握了compute传递参数的写法(书写方法,写在下方)
2.再比如掌握了ts如何约束动态参数(怎么做,写在下方)
1.页面出现空间兼容问题的处理方法(写在下方)
2. 关于员工培养的一份调研报告
2018年,《哈佛商业评论》刊登过一篇文章,研究的是如何提高培养下属的效率。这篇文章标题是ManagersCan’t be Great Coaches All byThemselves(直译为《管理者只靠自己无法成为伟大的教练》)。文章中,作者把管理者培养下属的风格分成了四种:
- 老师型(Teacher Managers)
这类管理者培养下属时像老师一样,他们有丰富的经验和知识,在培养下属的时候也是基于他们自己的知识和经验进行指导和反馈,帮助下属成长。
- 保姆型(Always-on Managers)
这类管理者培养下属时像保姆一样,把下属的成长当作最重要的事情,不断地给予各种支持,可能是人力资源经理最喜欢的管理者。
- 连接型(Connector Managers)
这类管理者培养下属时,花的时间最少——如果是自己专业领域的问题,就会给下属有针对性的反馈,否则,他就会帮下属联系公司内部或外部更擅长的专家,让他们自己解决。
- 啦啦队队长型(CheerleaderManagers)
这类管理者培养下属时,认为下属的成长是要自己负责并努力的,他的角色就是在旁边加油、鼓劲,但不会给太多具体的支持。
你猜,哪种类型的管理者的下属成长得最快?
答案是:连接型。这类管理者下属的进步效率是其他管理类型的三倍!
此外,这篇文章还有两个神奇的发现:
- 管理者培养员工的时间长度(9%~36%)和员工的成长速度没有太多具体的支持。
你猜,哪种类型的管理者的下属成长得最快?
答案是:连接型。这类管理者下属的进步效率是其他管理类型的三倍!
此外,这篇文章还有两个神奇的发现:
-
管理者培养员工的时间长度(9%~36%)和员工的成长速度没有太大关系。也就是说,如果方法正确,你花很少时间,也能让员工进步很快。
-
认为自己最努力、最负责、投入最多精力的保姆型管理者,反而是四个类型中,唯一对员工的成长弊大于利的类型——还不如在旁边只给员工打气、啥活儿都不干的管理者。也就是说,花了最多时间和精力帮助员工成长的管理者,结果“好心没好报”,不仅自己很累,下属还没什么进步。
这篇文章研究的结论初看让人吃惊——看似最努力培养员工的管理者居然是最低效的。仔细一想,其实也很好理解:知道什么就教什么的管理者,他就是员工成长的天花板,而能够整合最优秀专家的管理者,就能捅破自己的天花板,让员工有更多的机会和更开阔的视野。