今天学习了宝玉老师的《软件工程之美》中的“14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决”,以下是我的总结:
这节课说的管理问题主要是软件项目中困扰项目经理和开发人员的一些问题,比如任务进度量化的问题,项目进展不够直观,项目经理需要耗费很大的精力去做任务管理等。
项目管理工具软件发展史
阶段一:没有工具的年代
去管理项目确实是非常耗费精力,比如阿波罗项目,需要专业人士花大量时间和精力去制定计划和调整计划。
阶段二:项目计划工具
在瀑布模型为主软件项目,才出现了相对容易制定计划的项目计划工具,比如微软的MS Project,但存在不方便跟踪任务进度,进度不直观的缺点。
阶段三:基于Ticket的任务跟踪系统
传统项目计划工具不能解决具体的任务跟踪状态,后面才有了基于Ticket的任务跟踪系统,从用来跟踪bug逐步衍出跟踪需求和开发任务等功能。但缺点是不能直观看到哪些任务的状态。
阶段四:基于看板的可视化任务管理
可以很直观的看到不同的任务处于什么状态,项目经理和项目成员都可以很直观看到进展。
今天学习了宝玉老师的《软件工程之美》中的“15 | 风险管理:不能盲目乐观,凡事都应该有B计划”,以下是我的总结:
风险管理的重要性不容忽视,如果软件项目没有做风险管理,造成的后果轻则项目不能按时完成,重则造成无法挽回的经济损失,拼多多被“薅羊毛”事件就是风险管理不到位的典型案例。
应对风险的几个层次:
-
被动应对:风险已经发生,造成了问题才被动应对;
-
有备无患:事先制定好风险发生后的补救方案,但没有任何防范措施;
-
防患于未然:对可能发生的风险作出防范,并把风险防范作为项目任务的一部分。
做好风险管理需要做好以下几点:
- 培养风险意识
不能盲目乐观,思考最坏的情形,提前做好Plan B。
- 管理风险
管理风险有四步:
2.1 风险识别
软件项目的风险有以下几类:
-
项目风险:项目预算、进度、用户和需求等方面问题;
-
人员风险:人员离职、人手不足等问题;
-
技术风险:采用技术所可能带来的风险;
-
商业风险:与市场、产品策略等有关商业风险。
可以按照上面的分类整理出自己的风险检查表。
2.2 风险量化
风险发生的概率和发生后后果的严重程度,概率大和后果严重的应该以优先级去重点考虑。
2.3 应对计划
一张图解释如何应对风险,我们可以根据实际情况来选择应对策略,减少可能的损失。
2.4 风险监控
要做好监控,有以下三点:
-
第一要能对监控内容良好
-
第二要设置阈值
-
第三要有后续的报警和处理机制
这就就比如我们会监控线上版本的Crash率,设定告警的阈值,比如2%,超过这个阈值我们就告警,相关开发人员要及时处理线上的Crash,通过热更新解决Bug来将Crash率维持阈值以下。
这个主题其实开发人员感受可能不会很深,我们日常更多是基于需求去评估单个需求完成可能存在的风险,比如技术选型和人力成本这些方面去考量,但对项目整体来看,要把需求都变得可控,所以风险管理就很重要,如果前期评估出了风险,可以通过砍需求或者延长时间来降低风险。但对于开发人员如果能全局去培养自己的风险意识,这样能很大程度帮助团队一起规避不必要的风险,防患于未然。
今天学习了宝玉老师的《软件工程之美》中的“16 | 怎样才能写好项目文档?”,以下是我的总结:
我个人是比较偏向写文档的,很多程序员不愿意写文档,无非就以下几个原因:
-
不知道怎么写
-
太忙没时间写或者懒得写
-
觉得文档无用,价值不高
从这篇文章学习的内容,更加坚定了我对写文档的重要性的态度:
-
文档能够帮助自己理清思路
-
方便未来的维护和交接,最明显的是新人可能更快的融入团队,减少口口相传
-
团队更好的协作沟通
如何写好文档?
-
从模仿开始,参考别人是怎么写的
-
从简单开始,不要求一下子写大而全的文档
-
从粗到细,迭代更新
-
一图胜千言,能用图说明清楚的就不用文字,常用的有线框图、流程图、时序图、各种格式的截图等。
这一节我感受比较深,因为最近我也在帮助团队整理项目文档,因为我作为新人加入项目基本知道我缺什么东西,需要了解什么东西,如果之前有文档估计我可以更快融入团队和发挥自己的价值。
今天学习了宝玉老师的《软件工程之美》中的“17 | 需求分析到底要分析什么?怎么分析?”,以下是我的总结:
这节课的信息量很大,需求分析说实话工程师参与的并不多,更多是产品经理将需求分析过后的翻译成我们能够理解的需求单。需求的重要性不用多说,只有真正理解用户的需求,我们才能做出触及用户内心诉求的产品。宝玉老师这节课提到了很多让我很受益的知识和观点,比如做需求分析的一些步骤:
- 收集需求
-
头脑风暴
-
用户调研
-
竞品分析
-
快速原型
- 分析需求
-
表层需求:用户对解决问题的期望
-
深层需求:用户的深层动机,诉求产生的原因
-
底层需求:人性本能的需求
- 需求评估
-
可行性:技术能否实现
-
成本:人工成本、时间成本
-
商业风险和收益:有没有商业的风险,收益是否合理
-
紧急性与重要性:是不是用户迫切的需求
-
评估其优先级:紧急重要四象限
-
需求设计
-
验证需求
在日常工作中,其实产品最终效果不明显很大程度就是没有做好需求分析,没有深入理解真实的用户需求,一种好的基于数据验证需求实践——AB Test,通过数据驱动来分析需求。
今天学习了宝玉老师的《软件工程之美》中的“18 | 原型设计:如何用最小的代价完成产品特性?”,以下是我的总结:
原型设计经历了三个阶段:
-
低保真原型设计
-
中等保真原型设计
-
高保真原型设计
目前原型设计已经从一种快速开发模式演进成了设计工具,产品经理可以低成本、高效率的做出软件原型,便于更好的确认产品需求。
**如何做好原型设计?**分为以下四个部分:
-
分析:原型设计的目标是什么,搞清楚用户的需求
-
设计:从信息架构和使用流程两个维度去考量
-
实施:在设计的基础上通过原型工具进行界面搭建
-
验证:产品经理反复验证流程,调整存在走不通或者使用不方便的地方进行调整。
选择合适的原型设计工具的几个考虑维度
-
面向的平台:Web、桌面、手机;
-
保真度:
-
中等保真度还是高保真度;
-
功能:是否满足你的要求;
-
成本:价钱是否可以接受。
最后送福利了,现在关注我可以获取包含源码解析,自定义View,动画实现,架构分享等。
内容难度适中,篇幅精炼,每天只需花上十几分钟阅读即可。
大家可以跟我一起探讨,有flutter—底层开发—性能优化—移动架构—资深UI工程师 —NDK相关专业人员和视频教学资料,还有更多面试题等你来拿
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!
- 成本:价钱是否可以接受。
最后送福利了,现在关注我可以获取包含源码解析,自定义View,动画实现,架构分享等。
内容难度适中,篇幅精炼,每天只需花上十几分钟阅读即可。
大家可以跟我一起探讨,有flutter—底层开发—性能优化—移动架构—资深UI工程师 —NDK相关专业人员和视频教学资料,还有更多面试题等你来拿
[外链图片转存中…(img-uxeSgFLx-1714971644167)]
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!