项目管理流程

PMP在项目管理中应用的初体验

匿名 (未验证) 提交于 2019-12-02 23:32:01
写这篇文章的初衷是总结一下学习PMP之后在项目管理中所产生的影响,也希望我的经历能给同行者提供一些参考。 首先介绍一下项目背景,两个项目开发团队,三大业务领域,每个业务领域的开发人员相互独立,且同一个项目因为隶属不同的业务在人员管理模式也不尽相同(TM和FP共存),项目干系人、版本发布方式、汇报的机制、过程控制的流程等因业务而异,对于我这个菜鸟级项目管理者来说,这无形是一次极大的挑战。 我遇到的困难: 1、 需求接纳混乱,由于业务不同,每个业务内部开发Leader独自承接需求。 2、 人员无法复用,各个业务开发人员开发语言不同,发布版本不同,无法复用。 出现的问题: 1、各个业务需求无法有效跟踪闭环 2、团队成员忙闲程度分布极端化,士气低落。 我的措施: 1、 需求整合:统一需求出入口,统一需求管理工具,形成可视化看板。 2、 人员整合:人员形成资源池化运作,组建跨业务SE团队,由SE团队动态根据月度需求灵活调用人力。 3、 能力整合:由SE团队进行全员业务培训,技能培训,训战结合。 达到的效果: 需求出入口统一,人力复用,团队整体效率提升。 通过对PMP的学习解决了我在项目管理中遇到的很多困难和问题,PMP整套的方法论使我受益匪浅,不管是从项目思维、工作方式都有了很大的转变,非常感谢51CTO,感谢王安老师。

Workflow-产品:泛微工作流引擎

拥有回忆 提交于 2019-12-02 23:10:49
ylbtech-Workflow-产品:泛微工作流引擎 1. 返回顶部 1、 工作流引擎平台技术架构 TECHNOLOGY FRAMEWORK 高度协同系统各应用模块 泛微工作流引擎平台是整个协同办公平台的血脉,它是连接并打通其它各个应用模块之间协同的关键所在。 通过工作流引擎平台,既可以帮助用户基于企业业务模式和管理模式,自行定义所需要的各种流程应用,快速构建企业自身的流程管控体系,同时也为建设企业整体协同平台夯实基础。 国际标准化流程引擎架构 泛微工作流引擎平台参照工作流管理联盟(WfMC)所提出的工作流模型和五大接口标准,基于SOA架构,融合了近20000家客户的流程实践案例应用经验,自主研发而成。 这种流程引擎架构可以让用户方便快捷的构建符合自己企业规则的各类流程支撑企业的规范化管理。 灵活配置与多系统集成 泛微工作流引擎平台具有灵活的表单自定义功能,可以快速自由配置各类工作流程,提高流程实施效率,降低开发成本。 凭借强大的流程建模、多系统集成能力,可集成企业其他异构系统,在满足企业业务流程自动化管理的同时,实时构建基于企业不同管控模式下的流程管控平台。 工作流引擎平台逻辑框架 LOGICAL FRAMEWORK 工作流引擎平台技术特点 TECHNOLOGICAL CHARACTERISTICS 采用JAVA技术 跨平台设计,安全性高,运行性能卓越 符合WfMC标准

IT项目管理分享7个开源项目管理工具

匿名 (未验证) 提交于 2019-12-02 23:04:42
在一项调查中,有 71% 的组织表示他们在开发过程中会用到敏捷方法。 此外,用敏捷方法管理项目比传统方法管理项目成功率高 28%。在这次工具推荐中,我们从一些比较受欢迎的开源项目管理工具中摘取了支持敏捷的几项。 无论您的组织已经在使用敏捷,还是正计划使用,相信这 7 个开源的项目管理工具都能给你带来帮助。 1、MyCollab MyCollab 是一个高性能、稳定而且安全的商业平台,用于 CRM 客户关系管理、项目和文档管理。是一个企业的协作平台,基于 Java 开发。该系统提供开源的社区版本。 2、Odoo Odoo 的前身是 OpenERP,是一个开源的企业 ERP 系统。Odoo 不仅仅是项目管理软件, 它还是一个完整的集成商业应用套件,包括会计,人力资源,网站和电子商务,库存,制造,销售管理(CRM)等。 3、OpenProject OpenProject 是一个开源的、基于 Web 的项目管理应用程序。OpenProject 为项目团队提供了整个项目生命周期的支持,通过插件,OpenProject 支持: 协同项目计划 进度报告 任务管理 时间和成本报告 Scrum 等 4、OrangeScrum 5、]project-open[ ]project-open[ 采用 TCL 开发的基于 Web 的项目管理系统,它能帮助你的业务涵盖领域,如客户关系管理,销售,项目规划

【干货合集】项目管理、需求快速迭代如何实现?17篇文章搞懂敏捷开发!

落花浮王杯 提交于 2019-12-02 19:37:29
为了让大家get到研发效能有关的敏捷开发和架构的相关知识,现将云栖社区2017年度与之相关的前沿技术理念及实践技术成果资料整理出来,供大家学习。 【敏捷开发】 敏捷个人和敏捷开发 敏捷开发实践总结(一):敏捷开发的核心思想。 谈谈软件项目管理——敏捷开发 从瀑布模型、极限编程到敏捷开发 敏捷开发思想及Scrum实践 敏捷开发-快速迭代 敏捷开发,你真的做对了吗?阿里文娱广告团队敏捷实践总结 老曹眼中的敏捷开发【中生代北京闭门会实录】 当深度学习遇上敏捷开发,会发生怎样的“化学反应”? 还以为敏捷开发是个概念?有人已经将它变为现实了! 敏捷开发 敏捷开发的根本矛盾是什么?从业十余年的工程师在思考 不以敏捷开发为基础的DevOps都是耍流流流流流流流氓 敏捷开发 PK 瀑布模型 敏捷开发解决方案 敏捷开发之Scrum扫盲篇 为什么敏捷开发在亚洲实行不了 上述是小编整理的最新关于“敏捷开发”的相关云栖社区博客,分享出来,便于大家对该架构有一定了解以及加深对其的认识。通过上述介绍,相信大家对敏捷开发有了初步的了解,也愈发懂得了其重要性,想迫不及待的了解更多相关知识吗?机会就在眼前,5月29日9点,第二届研发效能嘉年华线上直播活动即将开始。阿里巴巴资深技术专家,十年敏捷教练,一线的实践专家,分享交流经验,奉献满满的干货。无论是项目管理,还是持续交付、测试发布、敏捷研发

提高软件项目管理中沟通管理水平的方法研究

泄露秘密 提交于 2019-12-01 18:59:21
  沟通与协调是进行各方面管理的纽带,是在人、思想和信息之间建立的联系。沟通管理是项目管理的九大知识体系之一,在项目整体管理中有着极其重要的意义和作用。沟通研究专家勒德洛(Ludlow,R.)曾经说过:“高级管理人员往往花费80%的时间以不同的形式进行沟通,普通管理者约花50%的时间用于传播信息。”提高沟通管理是提高项目管理的关键。因此研究软件项目管理中沟通管理,提高沟通水平,是十分必要的,也有着重要的现实意义。   一、软件项目管理中沟通管理存在的问题   (一)项目前期准备不足   在识别阶段,项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以至于无法得到完整需求或最终经权威用户代表确认的需求。加上项目干系人的要求包含明确的和隐含的,不同的干系人其愿望和追求的目标往往相差甚远,因此对项目干系人的愿望进行平衡可能是相当困难的事情。而且客户参与程度不高,客户方面的相关责任人不明确或对范围和要求责任心不强,提出的要求具有随意性,项目前期对需求的确认不够积极。博士论文,项目管理。有些时候项目交付时的系统与原来设计的系统有很大差异,这与项目团队对用户需求的挖掘不足有关,也就是说在项目前期没有与客户进行有效的沟通。   (二)重大决策过于仓促。   在时间的压力下,很容易做出仓促的决定。即管理学上的芝麻绿豆原理:就是对于重要的事情两三天就下决定了

基本流程

*爱你&永不变心* 提交于 2019-12-01 08:02:57
基本流程 需求分析阶段: 阅读需求、理解需求,分析需求点,参与需求评审会议。 测试计划阶段: 主要任务就是编写测试计划,参考软件需求规格说明书,项目总体计划, 内容包括测试范围,进度安排,人力物力分配,整体测试策略的制定,风险评估与规避措施, 参与测试计划的评审工作。 测试设计阶段: 编写测试用例,参考需求分析、概要设计、详细设计,不明确的与开发、产品经理沟通。 用例完成后进行评审 测试执行阶段: 搭建环境准备数据,执行冒烟测试(预测试)然后进入正式测试(系统测试、回归测试、交叉测试、自由测试),遇到问题提交bug到缺陷管理平台,并对bug进行跟踪,直到被测试软件达到测试需求要求,没重大bug,测试结束。 评估阶段: 出测试报告,对整个测试的过程和版本质量做一个详细的评估。 来源: https://www.cnblogs.com/zhanghan123/p/11671728.html

优秀技术Leader应具备的六项能力

倖福魔咒の 提交于 2019-12-01 07:56:12
技术Leader是互联网公司中,战斗在一线的技术领导者,技术Leader们能力的强弱,决定着公司整个技术团队的战斗力,结合我之前管理上百人技术团队的经验,谈谈我心目中优秀技术Leader五个方面的能力要求。 一、技术能力 系统设计和开发能力。技术Leader要熟悉业务领域内的系统架构和相关技术,能根据业务特性,合理进行分层设计,实现最高效率、低运维成本等等。 对于重要而复杂的系统,要求做好过载保护措施,以及资源的动态分配和优先级管理等。 技术运营。主动分析系统各项指标以及变化,通过监控数据和统计手段对系统性能情况、性能变动规律及原因、各项重要业务项数据变动情况,并做出对未来的资源规划等。 二、业务能力 业务知识。能够提出改善业务流程的合理化建议,并被客户接纳,不仅熟悉与自己领域相关的流程、专业知识,而且对公司主体业务领域业务知识也了解。 产品规划。对Team内的产品方向有总体把握能力,推动产品经理、业务做产品近期、远期的规划。 三、项目管理能力 敏捷开发。能够在团队内部主导和推动敏捷开发。 项目管理。能够独立负责中型项目的实施和运作,清楚了解项目的关键因素,在现实情况和有限条件下做好任务分解和进度安排。 针对计划合理地调配和充分利用现有资源,解决项目中大部分问题;在活动过程中充分预见可能的问题,并提前确定相应的防范应变措施;有风险管理意识,懂得如何识别和管理风险。 四、团队管理能力

对需求分析

别说谁变了你拦得住时间么 提交于 2019-12-01 01:26:57
转 https://www.cnblogs.com/syw20170419/p/8640609.html 案例 《挖掘管理价值:企业软件项目管理实战》一2.3 需求分析过程 1、什么是测试需求分析 需求分析:需求规格说明书的编写作者,在编写需求时进行的业务分析,依据于业务,来进行需求的编写 测试需求分析:1、分析需求的可行性 2、分析测试点:将需求分析拆分成一个个的功能点 拿到需求----测试需求分析-----编写测试计划/编写测试用例-----执行测试-----编写测试报告 2、测试需求分析点 1、功能需求: 占据系统80%左右的内容,软件主体。显性的需求分析点 2、业务需求: 隐性需求,直接看到的软件并没有将全部的业务显示出来,通过什么步骤进入到什么页面,什么页面显示什么样的内容,分析业务        的重要性:实际的业务中每一个业务系统解决了什么问题,达到了什么目的,业务的表现在功能上,依托功能来表现业务。 3、性能需求:有明确性能的需求(显性需求),如淘宝0点8分到5点7分有500用户使用,没有性能需求(隐性需求) 4、环境需求:系统运行环境的需求分析 5、安全性需求:用户登录(权限)、密码加密、非敏感行业,隐性需求 6、界面需求:用户交互、UI 7、可靠性需求:运行过程中出错的风险,软件的数据准确性、流程完整性 3、测试需求分析技巧 1、熟悉需求,明确测试范围

工作两年

我是研究僧i 提交于 2019-11-30 18:57:58
工作两年了,我一直希望让自己每年对测试的理解更深入一层。工作一年的时候我写了《 谈软件测试 --- 一年工作总结 》 ,谈轮了自己对各种测试的理解,这一年来,虽然对那些理概念的有所加强,自我感觉没有什么质的变化。前些天听我们公司的一位测试经理讲《敏捷测试》豁然开朗。他在学造飞机,而我一直在学造飞机里的一个发动机。我从来没想过,一个完整飞机的架构应该是怎样的。   如果想让测试在公司的项目中发挥出它最大的价值,并不是招两个测试技术高手,或引入几个测试技术,而是测试技术对项目流程的渗透,以及测试流程的改进与完善。虽然,当然测试行业前景乐观,许多中小企业也都在引入测试,但一百个公司就有一百种测试,每个公司对测试的看法不同,公司对测试的定位也不完全一样。本人前后经历两个公司,以自己的拙见浅谈一下对测试流程的看法。 这几天整理思路,回顾了前两份测试工作的流程与架构。 简陋的测试流程   先说笔者入职的第一个家公司,笔者是第一个入职的专职测试人员,相信一两个测试的公司还是不少的,入职后各种项目都在进行当中,上面给我的定位是并没完全融入到项目中去。而通过指派任务的方式。 下面是简陋的流程图: 需求分析与架构设计 :   我们做的是某一移动公司内部使用的项目,需求分析与架构全部由项目经理完成,之后由项目经理给具体某个开发人员分配任务,具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高

敏捷软件需求管理

帅比萌擦擦* 提交于 2019-11-29 19:04:32
title: 敏捷软件需求管理 date: 2017-10-23 10:29:39 tags: 需求管理 严格的来讲,这个标题的说法并不是很严肃,这篇文章的目的不是建立一个敏捷软件需求管理的流程,而是去探索一种需求管理的实践,解决现在工作中遇到的困惑和困难。为了将问题解释的更清楚,我需要先从流程定义说起。 流程定义  上面这个图是一个典型的IPD(集成产品开发)流程图,从大的视角来看,这就是一个典型的瀑布模型,需要有前一个阶段的成果作为后一阶段的输入,后一阶段的工作才能开展,这样当然没有错,不过有时候会显得低效和无法满足项目的需求。 同样,我也拿出我们研发层的各阶段的定义,进而进一步探讨。  从图和表中点后可以看到,需求分析集中在项目的前期的阶段,理所当然,需求就要作为后续工作的输入,因此需求很重要,这都知道,所以在图中也设置了需求的技术评审,但需求的技术评审并不能保证全部的质量。 总结来说,需求很重要,但需求又大多数集中于前端部分,不好管控,怎么保证需求高质量的分析,发现和实现都是比较困难的事情。 需求层次 产品开发规程中,对需求层次的定义是: op=>operation: 用户需求 op1=>operation: 产品需求 op2=>operation: 软件(子系统)需求 op(right)->op1(right)->op2 用户需求是顶层需求,直接反应用户的需要