在当今极度变化的大环境中,产品团队正面临着一场巨大的变革。为了更好的适应大环境,研发团队都极力做自我调整。
达尔文曾说过“留下来的物种往往不是最强的,确实最先进化的”,从传统的“瀑布式”到“迭代式”,最终再到敏捷型研发团队。无数组织、团队都在进行思考、变革。
研发团队一定要通过无尽的加班,才能交付产品,不能一边享受生活一边交付产品吗?
产品一定要尽善尽美后再推向市场,是否可以通过小的版本快速推向市场?
答案是可以的,是时候来场变革了!
在本系列,我将和你一起探索敏捷项目管理的知识和实践。
最终客户价值在销售时交付,不是在计划时交付。
敏捷商业目标
持续创新
关起门来造轮子,已经无法适应当今复杂的商业和技术环境。开发产品和新服务都需要新意识。
特别是随着大数据、人工智能、工业互联、5G的发展,编程步入了一个高速发展的时期,从C语言到python,从低级语言到高级语言层出不穷,从成人编程教育到少儿编程的兴起,市场给了我们更大的机遇和挑战。
持续创新能力随着环境的变化显得尤为突出,当大家都在聊4G,5G已经悄然来临,快速占领行业浪尖–这就是持续创新的一种表现,带来的机遇和收益往往是巨大的。
创新思想并不会是模式化的、独裁的环境中产生,一定是在开发的组织、组织成员自我的约束下不断的适应当下的环境中产生。
产品适应性和缩短交付进度
产品研发周期越短、产品实施交付能力越快,仍然是项目经理和企业要优先考虑的企业目标。看起来似乎是矛盾的,产品研发周期短意味着缩小研发功能范围。
其实一点也不矛盾,我们有做过市场调查,70%的功能很少使用,频繁使用的功能模块只有20%,意味着我们付出大的代价,无法适应客户的需求,造成极大的浪费。
通过排除用处不大的功能,避免过度研发,减少总体工作量。精益研发的引进,简化开发流程、详尽的文档使其效率更高,将重点放在最有价值、增值的活动上,排除那些合规而无意的的活动上。最后,敏捷项目注重让每个成员都发挥其特长、增设防火墙杜绝无意义的打扰和压力从而提高研发效率。
人员和流动适应性
敏捷是一种思想、一种能力。其最终体现在团队成员的意愿上,组建一支适应能力强的团队–成员愿意自我改变、乐意突破极限而不是秉承固有的工作模式。
可靠的结果
质量是好产品的硬性条件之一,作为研发团队,交付质量可靠的产品,不仅可以鼓舞团队气氛,还可以扩大产品的附加价值。
敏捷定义
敏捷是一种思想、一种能力–敏捷最精简的定义
敏捷领导价值观
敏捷《相互依赖声明》中明确的阐述了我们的信仰,即核心价值观和永恒的目的。团队为何存在、要创建什么产品、为谁而而创造以及如何共同工作,这些组成了敏捷项目管理的原则。
一款优秀的产品背后一定有一个优秀的团队,一个优秀的团队一定是由优秀的人员组成,如何吸引留住优秀的人才,是当今企业普遍思考的问题。
最近网络上某某平台,运维人员因公司上级不人道的对待,一怒之下删库与公司同归于尽,事件导致该公司市值缩水几亿以上,对公司和人员、客户、社会造成极大的不良影响。–这就是传统型管理模式
相互依赖声明
通过持续为客户创造价值来提高投资回报;
通过不断地与客户交互、共享所有权限来交付可靠的结果;
预测不确定性,并设法通过迭代、预防、适应来应对不确定性;
个体价值是团队价值的源泉、创建个体卓越的环境,实现创造和创新;
通过激发成员的使命感和责任感来提高团队的绩效;
通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。
敏捷型领导的价值观念:仆人式领导是一种非常社会化的领导风格。虽然传统的领导力是关于“金字塔顶端”的人积累,囤积和锻炼(通常会堕落为滥用)权力,但仆人式领导是与团队分享权力,识别,优先考虑和满足他人和帮助人们尽可能地发展和表现。
仆人式的几个特性
** 总结:Scrum Master 采用仆人式领导需要将团队的需求放在首位。仆人式领导者主要关注团队的成长和福祉:首先为他人服务,对于希望在团队成员中发挥最大作用的现代管理者来说,仆人式领导是一个强大的工具。**
敏捷项目管理架构
构想、推测、探索、适应、结束
敏捷架构过程
**总结
敏捷管理是最新出现的吗?不是,在2000年左右已经出现了。敏捷项目管理通过–做法、价值观、原则、概念架构组合形成了敏捷项目管理,继承了项目管理的丰富遗产,取其精华去其糟粕;敏捷也吸收了丰富的管理、制造、软件研发理论和时间经验(精益产品开发、KanBan等等)融合了最适合激动性和速度的世界观和思想体系。
敏捷项目管理并不是适用于所有人和所有项目,不是万事通的最佳实践**。