前文已述,价值在商业项目中的体现最终会回归到赚钱这个事情上。而如何衡量赚钱这个事,那就和金融财务方面的许多计算扯上关系了。项目经理需要掌握这些东西吗?可以不需要,但如果你有这方面的知识那就最好了。如果没有的话,请发挥你的情商,跟公司的财务打好关系吧。
在今年年初的时候,华为发出了一份任正非的公开信,该信的主旨说明华为要以构建可信的软件为目标,合理应用软件工程的理论,并从开发者、架构师不同身份的角度出发给出了具体的操作建议,讨论了重构、技术选型、技术人员的价值评估等重要问题。
因为游戏行业本身是一个强项目型的组织结构,所以后续的内容上不再明确强调这一点。全部默认都是强项目型的组织架构,即项目经理拥有最高的职权。
第一场 源于需求,成于价值 组织过程资产是项目管理中的一个非常重要的术语,是过去的项目积累下来的系统的经验教训、工作流程、工作模板和工作数据。做项目,必须利用组织过程资产,也必须为以后的项目积累新的组织过程资产 经验教训,不仅要总结,而且要系统地总结,要书面地总结。重要的经验教训,一定要系统地写下来 协调关系分成三个不同层面 依存关系:两个或更多需求是相互依存的。去掉任何一个,另一个就无法存在,或者即便仍然存在,也无法发挥应有的作用。例如,做项目的需求,与做运营的需求,就是相互依存的。只做项目不做运营,没有
除了以上列举的,字节跳动、有赞等也爆出裁员风波,2021年以来的互联网裁员,近期正愈演愈烈,除了看得到的业务模块精简、省年终奖等原因,我们也不妨做出推断,背后的另一重要原因也可能是,这些大厂步入了项目管理的传统思维——追求多快好省的顺序。
对于外行来说,「Jira」只是一个项目管理工具,在科技公司中几乎无处不在。它最初是为管理软件开发项目而构建的,后来自然而然地被应用到数据科学项目中。我想说,尽管 Jira 可能是一个很好的工具,但数据科学项目是特别的!
年末将至,大批攻城狮与程序猿早已蠢蠢欲动,开始了跳槽涨薪之旅,虽然受社会大形势影响,IT行业虽然无法和前几年的突飞猛进的势头相比,但是对DevOps的热度却只增不减,工程效能团队的普及率正在迅速增长,对DevOps工程师需求量也是呈指数式增加。转型做DevOps工程师、DevOps教练也是逐渐成为IT圈的时尚。那么如何在大量的DevOps工程师中脱颖而出,打破开发与运维之间的隔阂,成为团队内首屈一指的DevOps专家呢?
程序员要面临的挑战千千万,项目进度评估是有史以来就存在而且到现在也没有完美解决的重量级问题。 项目进度这个坎儿其实又可以拆分为两个: 1.工作量评估 2.项目执行与评估 前一阵圈子里流行一篇文章,题目是“做一个这样的APP要多久”,类似的版本还有“做一个这样的网站要多久”、“做一个这样的APP要多少钱”、“做一个这样的网站要多少钱”…… 多年的软件开发经验给我施了墨刑,在脸上刻了三个字:“程序员”,所以我走到哪里都会被识破身份。嘿嘿,都不用介绍了。这不,上周我去洗车时,就被一个兄弟认出来是搞软件的。然后
---------------------------------------------------------------------------------------- 题记
由于与开源社区深度合作,Tidelift会接触大量开源维护者。每年,其会发布一份《开源维护者现状调查》。
铺垫了那么久,不知道大家期待不期待。总算到了挣值计算这一课,这个名字很奇怪呀,什么叫做挣值?成本不就是我们的投资吗?这个挣值到底是要干嘛?带着这些疑问,我们就来看看挣值计算到底是在计算个啥。
在敏捷项目里面,更多的度量数据是故事点(Story Point),在每一个迭代周期开始之前,会让团队人员评估每个需求的故事点。这就相当于是传统项目里面的评估工时(一个需求完成需要多少时间)。
「持续创新」是对现在客户需求的交付;「产品自适应」是对未来客户需求的交付;「团队和流程自适应」是对产品或者商业变化的迅速反应;「减少交付周期」是为了快速交付可工作的产品;「可靠的结果」是为了支撑商业的增长和盈利能力。
作为敏捷项目管理的开篇文章,还是先来简单地说一说为什么先从敏捷开始,为什么是以 PMI-ACP 为参考。当然,这一系列的文章可能不可避免地会为 PMI-ACP 做一些广告,但是我想告诉大家的是,敏捷以及项目管理相关的内容要掌握好,实践比理论重要,也比考试证书要重要的多。
敏捷项目管理VS传统项目管理
Agile Project Management的创始人也是敏捷宣言的十七大佬之一,Jim Highsmith。
1、规划方式。传统项目管理更注重预先规划和控制,而敏捷项目管理更注重快速响应和调整。
流程圈包括 每周40小时工作制(40-Hour Week),系统愿景(System Metaphor),小型发布(Short Releases),简单设计(Simple Design)。
提到精益,大家首先想到的肯定是“精益生产”,其中最具代表的就是日本的丰田公司,其最终演变成为了一种新的管理方式。
上周,我站在一家市值 200 亿美元的公司的会议室里,推动了一个关于敏捷的研讨会。出席会议的小组由这家大公司的一个产品线中的每个职能部门的董事和部门经理组成。从 UX、工程和产品管理的岗位中挑选出来的十几位领导者组成了一支团队,他们代表着约 150 人的产品线。作为一个团队,他们踏上了“敏捷”的旅程。
大家对这张图一定不陌生,你可以认为这是敏捷流派划分。敏捷和看板Kanban都脱胎于精益Lean。
国内很多企业非常关注产品功能,而对稳定性关注甚少,常常产品功能很炫可是稳定性往往差强人意。今天我们来聊聊产品稳定性。
团队圈分为:代码规范(Code Standards),持续集成(Continuous Integration),集体代码所有制(Continuous Integration)
不管是什么样的流程,都值得不断地去优化。针对不同的项目,不通的阶段,都可以做调整。因为敏捷是适应变化的,而不是一成不变的。所以,在敏捷中,也有个口号,用中国的大白话来说就是“没有最好,最优更好”。
近年来很多鼓励企业数字化转型的政策陆续出台,在一定程度上帮助企业减轻数字化转型的成本压力。但是企业数字化转型依然面临着诸多的问题与挑战。主要还是因为大部分企业,特别是制造型企业,数字化进程还在探索阶段,资金、人才、技术等方面都没有对应的配备,导致数字化转型进展并不顺利。而织信团队一直都是在为企业建设数字化工厂提供行业经验和技术支持服务,希望能够从底层来为企业数字化提供更加合理的实现路径。
精益敏捷要求我们站在用户的角度来看待问题,这样的话也就是企业产品(服务)的价值只能由最终用户来确定,价值也只有满足特定用户需求才有存在的意义。
在1969年以前,不管是制造汽车还是制造轮船,全世界的项目管理都没有太多的章法和规则。直到1969年美国成立了PMI组织,推出了PM Bok一整套规则、PMP认证后,全世界的项目管理就有了章法、有了规则。(= =#这样就是大家现在苦逼考着的PMP。)
“ 软件的估算是世界难题。完成一个任务实际花费的时间总会超过计划花费的时间。但是作为客户、用户或业务,他们需要我们提供估算,以便确定一个项目的预算和交付时间。一方面我们面对一个项目,里面充满着巨大的不确定性,另一方面客户、用户或业务需要确定性,这对矛盾如何破解?如果这对矛盾无法破解,是否可以转移矛盾?”
前面文章有提到敏捷的一些基本概念和做法,Scrum是一个敏捷框架,满足Scrum的做法都被认为是敏捷的行为。而本篇文章希望从敏捷工具讲起,对不同组织文化的敏捷项目管理工具选型做一下对比分析。
在这周五我们举办了V咖分享会第十五期的分享,现在就由芒果为大家整理这次分享会的知识。本次整理内容包含我们的V咖李强老师的分享内容,部分提问及回复。想要提问或者观看完整问题解答的小伙伴,请积极参与到我们分享会中来,我们的分享会每两周就有一次哟~
因为网上关于敏捷宣言的文章实在太多了,有深入浅出的,有详尽的。所以我的这篇文章就挑重点来说。
说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。
上一大篇的敏捷框架怎么样,有没有意犹未尽的感觉?敏捷框架只是敏捷的一部分,而且是偏实践的部分。所有的教材都喜欢把这些敏捷框架写在前面也是因为这部分非常吸引人。但是,真正的敏捷还有许多理论等着我们来探索,不要着急,在学习完后面的内容之后,再回来看敏捷框架,或许你会理解得更加深入。
CODING 项目协同近期为支持传统项目管理推出了「经典项目管理」。至此,CODING 已全面支持敏捷项目管理以及传统项目管理。那么问题来了,「经典项目管理」和「敏捷项目管理」,我该怎么选呢?本文将从理念差异、常见的研发模型、适用场景、实践应用等角度来提供选型参考。
随着数字化转型在各行业的广泛应用,越来越多的企业开始寻找新的增长点。对于数字原生企业而言,加速数字化转型是由“数字化”迈向“数智化”,增收减支,构建核心竞争优势,实现可持续发展的必然过程。敏捷协作工具凭借其先天优势,帮助企业快速适应市场变化和需求,集中内外部资源,不断迭代优化,成为了数字企业提质增效的利器。
敏捷开发(Agile Development)是一种软件开发方法论,强调在不断变化的需求和环境下,通过迭代、协作和自适应的方式来开发软件。敏捷方法的目标是提供更快、更灵活、更高质量的软件交付,以满足客户需求并实现项目成功。
摘 要: 系统规划设计呈扁平化设计趋势,用户主导或参与方案设计越来越多,客户的需求变化越来越快。尤其是在大型复杂创新物流系统仿真中,需要随需应变、快速设计、快速迭代和呈现设计方案,积极地应对和满足客户需求变化。本文采用敏捷项目管理方法研究大型复杂创新物流系统仿真应用,实现与项目干系人的协同及沟通,能快速适应需求变化及仿真结果交付。
先来一波高能预警,对于项目管理来说,笔者拥有PMP、PMI-ACP以及信息系统项目管理师三本证书哦。这三个证书实际上就是目前国内项目管理方面的三个权威证书。
任何项目都要经历从开始到结束的时间过程,在传统项目管理中,项目会被划分为若干个阶 段,每个阶段相加的时间总和,成为项目生命周期。
做敏捷开发,如何敏捷?我们需要一系列成熟的工具帮助我们敏捷。敏捷开发工具的适合以及选用,对开发项目起着关键性的作用。此篇介绍我们在scrum敏捷开发中发掘的几款工具,方便更多新加入的开发者上手。
I. 项目管理概述 A. 项目管理定义和目标 B. 项目管理的重要性和价值 C. 项目管理生命周期
PMI经过多年调查发现许多项目需求不断地变更,成员小于10人的团队 ,套用以往“先做计划再做事”的思维,项目根本推不动。因此,PMI提倡采用敏捷(Agile)的方法管理充满变动的项目,并从2011年开始正式推出 PMI Agile Certified Practitioner(PMI-ACP)认证,使项目经理能够具备快速应变的能力
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RbSNI3en-1589334555768)(1.png)]
随着市场的瞬息万变和软件行业的迅猛发展,传统的瀑布式软件开发模型因其漫长的开发与反馈周期,在抢占市场先机和快速满足用户需求方面日渐失去竞争优势。与此同时,敏捷开发以其快速迭代,持续满足不断变化的用户需求而
项目管理是管理学的一个分支学科 ,对项目管理的定义是:运用各种相关技能、方法与工具,为满足或超越项目有关各方对项目的要求与期望,所开展的各种计划、组织、领导、控制等方面的活动。 作为一名互联网产品经理,有幸在工作中负责一部分项目管理的工作,在经历几个版本、N次迭代之后,逐渐形成了一个观点:项目管理博大精深(shui hen shen)。如果从集成管理、范围管理、时间管理、成本管理、质量管理等角度来讲,可能需要写一篇万字长文。所以,我想结合工作中的经历,从关键词说一说自己的感受。
大家好,本次我将为大家详细讲解敏捷的一个流派,叫做 Scrum 敏捷项目管理核心,它起源于 2001 年,当时有 17 位大牛共同讨论了他们的想法和各种软件开发方法,经过交流,他们最后达成了价值观和原则上的共识,共同发布了敏捷软件开发宣言。
PMI全称Project Management Institute,中文名叫《项目管理协会》。成立于1969年,是全球领先的项目管理行业的倡导者,它创造性地制定了行业标准,由PMI组织编写的《项目管理知识体系指南》(PMBoK)已经成为项目管理领域最权威教科书,被誉为项目管理“圣经”。
1、PMP ®项目管理认证 1999年,中国国际人才交流基金会(原国家外国专家局培训中心)将起源于美国的项目管理协会的《项目管理知识体系指南》(《PMBOK指南》)及项目管理专业人士(PMP®)认证引入中国。2000年,项目管理专业人士职业资格认证(PMP®)在中国大陆地区首次开考,当年报考人数仅有316人次。而到了2019年,年报考人数已达14.5万人次。 截至2019年9月,全国累计PMP®报考人数近60万人次,通过PMP®认证人数约42万人,有效持证人数约30万人,占全球PMP®持证总量的31.
领取专属 10元无门槛券
手把手带您无忧上云