精华内容
下载资源
问答
  • 做好技改项目档案
    2019-03-11 15:03:53

     

    [摘要]:

    2010年3月,我作为项目经理开始参与某大型综合性企业信息化系统项目的开发,主要负责项目的组织实施与管理工作。本文以该项目为例,结合作者实践,讨论了信息系统项目的整体管理问题,指出项目整体管理在信息系统项目实施中的重要地位和关键作用。在项目整体管理中,我根据项目的实际情况和特点,有针对性的强化某些方面的整体管理工作,并采取了以下措施:科学编制项目计划、强化实施项目计划和执行整体变更控制以防止项目范围的无效蔓延来进行有效的项目整体管理,保证了项目按时交付使用,顺利完成了该项目。

    [正文]:

    信息系统项目的整体管理是项目取得全面成功的一个至关重要的前提和基础。通过项目整体管理,可以确保项目所有的组成要素在适当的时间有机地结合在一起,以顺利、成功地完成项目。这在本人所主持的某卷烟厂物流控制及管理信息系统项目实施过程中得到了充分验证。

    该项目是一个综合性的系统工程项目。从技术实现角度讲,它所涉及到的主要技术领域包括卷烟生产工艺、制造业物流技术、工业自控技术和计算机管理信息技术等 等。从利益相关者角度讲,它又涉及到作为需方的烟厂、物流设备供应商、工业自控设备供应商,以及作为信息系统集成商的我公司。因此,这是一个复杂程度高、 涉及面较广、实施周期长的综合项目。

    面对这样一个项目,作为开发方公司的副总工程师,我受公司委托担任该项目经理,我首先想到的是应该将主要精力放在项目的整体管理上,科学地运用相关理论知 识及其指导方法,做好项目的全局性统领工作,协调完成项目所需的所有人员、计划和工作,带领整个项目团队实现项目的顺利成功。另外,我也考虑到,除了项目 本身内部的各组成要素之外,项目的相关利益者也不容忽视。一方面是作为公司承担的一个对外项目,我们实行项目经理负责制,具有一定意义上的独立性,但同时 也是公司整个组织日常持续运作中的一部分,离不开公司的整个组织环境,而且公司也已决定将该项目作为业务延伸拓展的一个新的窗口,将其提升到了一个相当重 要的位置。另一方面,该项目是需方烟厂整体搬迁重大技改项目的一个部分,其实施的进度、质量和成本等,受到来自其主管上级部门和烟厂新经营目标的严格要求 和控制。此外,还会涉及到物流设备供应商、工业自控设备供应商等中标单位。所以,项目的整体管理显得是那么的重要、不可或缺。否则,稍有顾及步骤之处,都 将会给项目的实施带来很大的麻烦和影响。

    下面分别从项目计划编制、项目计划实施,以及项目综合变更控制等方面对项目的整体管理过程加以简要论述。

    1、关于项目计划编制:

    凡事预则立、不预则废。信息系统项目尤其如此。只有站在统领全局、整体规划的高度,对项目进行科学、合理、全面、周详的计划,预先制定一个用来协调所有其 他计划、以指导项目实施和控制的文件,才能使项目得以顺利实施并最终取得成功。项目计划记录了计划的假设条件和方案选择,可以为各利益相关者之间的沟通提 供了一个参照,并确定了关键管理审查的内容、范围和时间,同时还为进度评测和项目控制提供了一个基线。

    在该项目中,我们对项目计划具体内容的确定,结合项目的各方面实际情况,主要参照IEEE1058.1中“软件项目管理计划”的基本内容,其中包括项目介 绍、项目组织、管理过程、技术过程和进度预算等五个部分。在坚持科学、合理、全面、周详的原则基础上,还视部分具体的计划条款,详略得当。但所有的计划内 容都必须是正确的、明确的、易理解的和可执行的,切忌未经确认、含糊不清、容易误解、难以执行的项目计划描述。这就要求我们必须在制定计划之前或在制定过 程中,与需方烟厂、公司上层、其他设备供应商、项目团队各技术和管理小组进行充分的沟通与协商,明确确定项目有关内容,如项目可交付成果、技术方法工具、 组织结构、各工作包、资源要求、预算分配、进度计划等。

    另外,因为项目管理的最终目标是满足或超越各利益相关者的需求和期望,在项目计划过程中考虑利益相关者分析也是非常重要的,但不宜将其作为项目整体计划的 一个部分,最好把它作为公司内部使用的一个项目计划附件。该项分析的内容可以包含各利益相关者的所属组织、所处角色、项目利益、影响程度及管理这些利益相 关者的合适建议等。对于项目经理来说,花点时间来关注和利用这些信息也是非常重要的。我在该项目管理过程中的感觉是,在项目的日常实施过程中,尤其是在项 目陷入某些困难的时候,这些分析结果常常会帮助我起到对症下药、药到病除的作用。

    当然,项目计划的制定和执行,也必须考虑和注意它的动态性和灵活性。尤其是对于综合性的项目而言更加重要。由于项目复杂程度高、涉及面较广、实施周期长, 所以其中的变更是在所难免的。在该项目实施过程中,由于烟厂项目局部需求的修改,或由于各方交流的失误等,曾经导致了部分项目内容的变更从而致使了项目计 划人员和进度的变化和调整等。而且这种计划动态修订的次数还不止一次。所以项目计划制定以后并非一劳永逸,它与项目实施过程相互渗透,有一个动态的、灵活 的修订过程

    2、关于项目计划实施:

    项目计划实施是指对项目计划中所规定的工作进行管理和实施的过程。项目产品主要都在项目实施阶段生产出来,所以项目的大部分时间和预算都花在这一阶段。在 该项目中,我们的软件编程、与需方烟厂有关技术人员的具体沟通、与有关设备供应商的具体交流、阶段性调试,直至全套系统软件和技术文件的完成等,都发生在 这一阶段。为了能够成功地完成项目产品,项目团队进行了大量反复的具体编程、学习、沟通、修改、软硬件安装和调试工作。

    如前所述,该项目涉及到的主要技术领域包括卷烟生产工艺、制造业物流技术、工业自控技术和计算机管理信息技术等,我们项目团队不仅要从事熟知的信息技术工 作,还要花大量时间和精力了解烟厂具体的细节性的需求,学习卷烟生产工艺、制造业物流理念和常识、物流设备的基本工作原理和管理知识、自控设备的基本工作 原理和管理知识等等,以及反复地和烟厂、相关设备供应商、公司上层等进行必要的交流沟通。作为项目经理,在此阶段主要的工作是要按照预先制定的项目计划, 利用项目团队组织机构和工作程序,领导项目团队开展各项工作,管理和协调各利益相关者的关系,成功地将项目计划投入实施。

    项目计划和项目实施是相互渗透、不可分割的活动。在该项目的实施中,我们对于项目计划编制和实施之间的协调改进工作主要采取谁实施谁计划的原则。虽然项目 经理负责整体项目计划,但编制该计划的大量基础信息均来源与各技术组和技术人员。事实证明,按照这一原则,项目计划的编制更加合理、可行,实施起来更加顺 利。

    3、关于综合变更控制

    综合变更控制是指在项目生命周期内对项目变更进行识别、评价和管理的工作,这也是项目经理及其项目团队的一项重要工作。如前所述,该项目的复杂程度高、涉 及面较广、实施周期长,所以其中的变更是在所难免的。当有变更要求提出的时候,作为项目经理,我都会召集项目团队相关人员,进行协商讨论和工作安排。主要 内容有:

    A、对变更因素加以影响:通过在范围、时间、成本和质量等关键项目尺度的权衡,对促使变更形成的因素进行分析和采取对策,确保变更对项目有利;

    B、确定变更是否发生:在最终确定变更发生前,项目经理必须了解项目几个关键方面的状态。尤其是一些重大变更,项目经理必须与公司高管层,以及其他利益相关者进行必要的交流与沟通。

    C、对变更加以管理:项目经理在项目管理过程中必须严格行事,尽量避免或减少变更的发生。但变更不可避免发生时,更重要的是对变更进行管理。

    按照项目整体管理的指导方法,我们在变更发生时,要求必须输入项目计划、变更申请和绩效报告等重要内容,输出更新后的项目计划、纠正行措施和经验性教训记录等。通过这些做法,使我们的项目变更控制与管理工作规范有序。

    该项目顺利成功地实施完毕已经有一年多了。回顾起来而言,应该得益于我们在项目进行的最初期阶段就引入了项目整体管理理念和方法,对项目进行了科学、规范 的整体管理。通过项目整体管理,使项目所有的组成要素在适当的时间充分地、有机地结合在一起,极大地提高了项目的实施效率。

    [老师评语]

    本文基本达到了考试的要求。摘要和正文都写得比较流畅,给人的感觉思路清晰,层次感强。项目所述情况基本与项目研发过程中的情况相同,给人以真实感和作者有丰富的项目实施经验的感觉。

    更多相关内容
  • 在互联网公司中,日常迭代和重点项目的同步进行几乎成了常态,你也会遇到一些特殊的项目,比如“一号工程(老板项目)”“技改项目(核心系统重写)”“倒排期的重大业务(1111 和 618 的大促、新业务新产品研发)”...

    对技术 Leader 来讲,团队的开发模式多以项目制或敏捷迭代为主,不论哪种方式,项目管理都是最主要的工作之一。在互联网公司中,日常迭代和重点项目的同步进行几乎成了常态,你也会遇到一些特殊的项目,比如“一号工程(老板项目)”“技改项目(核心系统重写)”“倒排期的重大业务(1111 和 618 的大促、新业务新产品研发)”。这些项目统称为“大项目”

    大项目因为时间投入大、人员规模大、系统更大,和日常迭代项目在“项目管理”和具体做法上存在很多不同,在成员的协同、事务的推进上也存在困难,而你要具备解决这些困难的能力,有两个原因

    • 公司基于战略规划等目的,一定会启动大项目,你必须具备处理这类项目的能力,并不断抽象与思考,形成自己的方法论。这是环境对你的要求
    • 观察后发现,一些公认出色的同学,往往是在大项目中脱颖而出的。优秀者一般都会重点参与或主导几次重要的项目来证明自己,进而在未来得到更大的发展空间

     

    认清异同,做到心中有数

    想解决一个问题,先要定义清楚问题,一般而言,要想认清大项目,我建议你以常规项目为参照物,通过对比二者特征总结差异点。一般项目迭代的常规流程如下

    常规项目迭代流程

    这个流程并不复杂,大多是自上而下敲定需求内容和优先级,做好时间预估后就进入开发流程,有时受开发周期的影响,会压缩一些环节上的时间(比如方案设计、开发自测等),将大部分时间花在业务逻辑的实现上。在这个常规流程中,技术团队的重心是把执行做到位,你要更关注过程管控,确保系统交付

    大项目与常规项目的核心差异点,我认为主要在于这个“大”字上,可以从三个方面去理解

    • 出发点不同,业务期望更大

    在大部分互联网公司中,产品研发模式侧重敏捷迭代:项目小步快跑,尽早试错、及时调整,通过逐步完善系统实现量变积累质变。大项目完全相反,不再小步快跑,而是“蓄力憋大招”,希望以此建立公司的竞争优势

    以双十一为例,阿里相关团队要提前 3~5 个月进入双十一专项(最核心的团队半年前就会 ALL IN )。这类项目投入巨大,自然有极高的业务目标,比如双十一和 618 主打 GMV,历史新高的 GMV 映射到产品技术上,就要有更多、更复杂的营销玩法,系统也要有更强的负载能力

    • 规模不同,复杂度更高

    日常迭代项目一般以周为单位,以小组为执行单元,需要跨部门协作的往往是单点的需求(比如某个接口需要大家一起联调)。又因为需求和交付产物拆分得足够小,关联性也不强,即使在迭代周期内遇到一些意外情况(比如开发人员突然短缺、需求紧急变更)也只会让一小部分业务受阻,不会影响全部的项目

    而大项目往往是重新建立一个产品或体系,以月为单位,涉及的人员跨多个部门甚至整个公司(协作者会变成几十甚至上百人)。需求拆分的粒度并不细,并且随着项目推进可能会持续识别到新的需求,这就让整个项目处于动态变化的过程中,增加了系统复杂度和项目难度

    项目规模变大后,会放大很多问题,比如你会发现跨部门沟通协同比系统 Bug 难处理,开会汇报项目进度比写代码更花时间。除此之外,项目往往会倒排期,开发资源永远不够,组织与组织间协同效率低下等问题在大项目中极其常见

    • 结果评判标准不同,影响更大

    在日常迭代项目中,我们往往只关心交付的时间、质量,无法在短期内判定业务上的效果。可对大项目来说,最初立项就是奔着业务效果去的,所以相对而言,它可以容忍项目过程中的一些不顺利,但看重业务目标的达成情况。如果没达成业务目标,会浪费之前投入的资源与时间,从而在竞争中处于劣势,所以很多公司是把自己“折腾”没的

    除了业务层面的宏观影响,项目的交付直接影响相关人的绩效 KPI,也间接影响年终奖、晋升

    总的来说,大项目对你的要求与常规项目有很大不同,除了把项目管理的基本功做到位,还要考虑如何达成业务结果,如何协同人与团队,如何解决各种突发问题。最关键的就是你要脱离系统交付的角色定位,站在团队实现业务结果的角度去考虑问题,认识到系统的交付并不等于项目的结果,要在业务的思考上迈出一大步

     

    把握关键点,谋定而后动

    大项目中系统的交付固然重要,但更关键的还要看项目目的是否达成关注效果更重于关注交付,这是大项目的核心特征

    以核心系统的重构(重写)项目为例,要想重写,就要投入大量时间,承担极高的系统风险,为什么要重写呢?答案可能是“系统是其他团队开发好交接到手里的,不好维护。”或者“最早的设计实现有问题,必须大改。”这时,你要明确重构到底是目的还是手段?是否一定要做重构?

    重构除了解决过去的问题,更要预防未来的问题,这样才能平衡好投入产出比。如果单纯考虑解决过去的问题,忽略系统未来的演进方向,过不了多久就会回到原状。不要为了重构而重构,要知道你要的结果是什么

    为了确保大项目成功,关键点应该是制定完备的计划,因为想清楚比做到位更重要。从经验来看,大项目的失败存在一个共性的问题:围绕业务结果的思考、计划不足,目标的定义不清晰或没有充分同步给所有相关人,项目成员知其然而不知其所以然。连目标都没有共识,何谈执行到位,项目成功?

    所以越是重大的项目,在计划、设计、准备上投入的精力就应该越多,谋定而后动。 建议你围绕业务、技术、团队等几个方面,把 WHY、WHAT、WHO、HOW 问明白,想清楚

    WHY(项目为什么做)。 很多 Leader 因为习惯做执行和交付,或者觉得即使有不一样的观点也无法改变什么,所以并不热衷去探究项目背后的 WHY。不清楚 WHY,当你要解决困难时,就会缺少核心的逻辑依据,并且你很难识别真正的需求,很难判断业务想要的功能和想解决的问题到底是不是同一件事儿

    WHAT(项目做成什么样)。 WHY 是在确定项目的动机和目标,WHAT 是确定项目的具体形态,简单来说就是要做怎样的产品和系统来实现目标。比如每年的双十一大促,会推出新的玩法和营销活动。如果参与这样的“ Super ”项目,你至少应该搞清楚以下两点

    WHO(哪些人来一起做项目)。 很多问题不仅仅是系统的问题,人也是其中的关键因素,而你需要确定项目的核心人员并罗列项目所有的关联方

    HOW(启动项目后如何做)。 明确了业务目标、结果期望和相关人之后,就进入项目的执行过程,在常规项目管理的基础上,你要注意这样两点

    • 合理拆分任务(模块)是项目成功的一半:大项目是把最终的效果打包放在一起去设计规划,在执行过程中一定会被分治。关键在于你要等所有人对最终架构达成共识后,再去按照团队、业务领域、具体场景任务等维度拆分任务和模块,以终为始,从最终要的结果来确定如何开始拆分(最终架构的形态应该以产品和系统的全局架构大图为参照)
    • 保持风险意识,敬畏墨菲定律:大项目在推进过程中极易发生突发情况和概率性事件,你要做好预案,比如项目排期上一定要预留足够的 Buffer,提前确定好紧急处理问题的机制等

    做好充分的准备之后,可以召开立项会,将 WHY、WHAT、WHO、HOW 的信息与思考同步给项目相关人员。通过 Kick Off 会议确定项目的基调、同步必要信息,为项目推进扫清障碍

     

    如何处理棘手问题

    大项目复杂度极高,容易产生很多棘手问题,而处理这些问题的核心原则是:以最终结果为导向,借助所有可能的帮助与资源,在不违背原则的前提下适当平衡与妥协,达成目标

    问题一:缺兵少将怎么办?

    项目中人不够已经成了一个常态,比如部门内一套核心系统要重写,而团队无法一边持续迭代、一边在规定时间内完成重写,如果所有人 ALL IN 重写,系统迭代要暂停 2~3 个月,业务上无法接受。如果拉长周期,将重写项目持续半年,不仅会增加意外风险,并且很长一段时间内重写项目无法创造价值,会变成团队的负担

    如果你遇到类似的情况,需要在内部腾挪的同时,以项目的价值与收益为本金,借助上级组织的力量从其他团队借人。如果你有过“借人”或“被借”的经历,大概会对其深恶痛绝,因为这种方法会产生很多新问题,比如其他团队的成员不熟悉业务和系统(进入状态的成本很高),或者你们之间没有汇报关系,在工作安排和任务执行上并不通畅

    所以,并不建议大项目时常通过借人来补充项目成员, 人员的经常借调本身体现的就是权责不匹配,会导致一系列问题。好的方式应该是在组织内,让项目组的跨组织结构成为常态与共识,设计灵活的绩效、考核、汇报体系,让每个人都可以按需灵活地加入项目组。另外项目组人时你要注意以下几点

    • 当项目开始时,从更大的范围内寻找合适的同学,而不是看你团队有哪些人
    • 将参与项目的成员在一定时间内的汇报关系和绩效考核汇总到项目组中,由项目负责人根据实际情况重新安排每个人的权责,并确定绩效的绑定关系与比例
    • 项目交付并不等于结束,所有人的绩效结果都应和项目目标的达成情况紧密且长期关联

    最后,有时不仅要解决“缺兵”的问题,还要认真考虑是否“少将”?要充分考虑当前的人员是否适合做项目的 Owner,以我的经验来看,项目 Owner 几乎决定了项目成败的 80%,如果 Owner 能力不足,你要给予帮助和支持,或者另找他人,乃至上级的帮助,不要在 Owner 的人选上妥协,毕竟项目成败才是关键

    问题二:推不动的到底是人还是事?

    你是否有类似的经历:一些功能或模块经常会出现大家都不做,要么抢着做的情况(比如双十一新增的活动玩法会让很多相关团队都做到自己负责的系统中),这会阻塞项目进展

    之前,负责公司的订单交易系统,熟悉这个领域的人肯定知道,订单系统是一个大杂烩,任何业务都想加一个字段到订单表上。最开始,我经常会为了是否让一个数据加入订单系统而和别人争论,因为担心不干净的设计会拖累系统的稳定性和可维护性,由这两种情况你会发现,事情推不动的背后跟人和组织有很大关系,处理不当会加剧不同关联方的冲突,你必须处理好类似的问题,提供给你 几 点建议

    • 搞明白冲突现象下的利益诉求: 不同关联方产生观点冲突的现象背后其实是利益冲突,你要搞清楚彼此的顾虑。比如我不愿想让某个系统字段落到订单中,主要是考虑到订单系统的可维护以及稳定性,如果你能解决我的顾虑,会容易说服我
    • 为项目结果适当妥协: 在很多情况下,我们无法做出完美的方案,可能就是要在系统内通过很糟糕的实现去实现需求。项目没有 100% 完美,抓住核心原则不放弃,可控部分适当妥协换取项目前进是很好的策略
    • 通过项目地位和决策机制推动项目: 大项目往往是公司重大战略下的产物,一般情况下,不会有人去反对公司的某项既定战略,而你可以通过大项目的重要性在体系内争取更多的资源和帮助。如果你面临一些冲突,要学会利用决策机制,通过更高级别成员的沟通决策拿到解决方案

    问题三:一定会有项目变更吗?

    对你来说,最难处理的就是突如其来的变化,变化意味着要调整之前的计划,又会出现新的困难与问题。常见的变化往往有两种

    • 项目演进过程中识别出之前未能识别或考虑缺失的点,导致方案需要调整
    • 出自老板的需求变更,很多情况下都是要新增内容

    项目变化和老板 CR 之所以难处理就在于它会打乱项目原本的计划节奏,本来一环扣一环的时间安排、人力安排、任务与模块安排都要重新编排、组合、解决冲突,单点的风险通过链路传递到整个项目链路上,产生了极强的联动效应

    建议是保持平常心,几乎所有的项目都会遇到类似的情况,出现负面情绪只会增加你解决问题的难度,你要做好两点

    • 由外至内解决,先从优先级调整、新增资源、调整排期入手,不行就考虑压缩时间、调整方案乃至加班。做好 ROI 和风险的权衡,不要为了解决 A 问题制造更难解决的 B 问题
    • 统一变更管理,所有的变更都应该统一管理、审核、评估、记录最后广播给项目全员,确保大家信息一致,对终点的认识没有误差

    如果你被老板频繁的变更所困扰,试着多做汇报,让他对项目的进展与正在解决的困难有更直观的感受,这样他对新变化带来的不确定性风险会有更强的同理心

     

    总结

    大项目是技术 Leader 的试炼场,不仅考验你的技术能力,还会从产品、业务、沟通、事务推进等多方面考验其综合能力。而经历过大项目毒打的人在处理别的问题时,会更加从容

    所以,如果你在实际的工作中,有机会参与或主导类似的项目大可放手一试,这样会极大提高你解决问题的能力。强调这样三个重点

    • 驾驭大项目是你的试金石和分水岭,对自己职业规划有一定要求的人一定不要放过打磨修炼的机会
    • 在大项目中,往往人的问题会比技术与系统的问题难解决,因为与人相关的问题未必完全理性和逻辑,那么此时你也不妨看看感性的沟通与交流是不是有更好的效果
    • 时刻牢记你将项目按时上线没有故障只是做到了60分,更关键的是业务效果,所以除了盯紧开发过程外,还要在最开始的业务与产品设计阶段就投身其中

    展开全文
  • 作为项目经理,前期你抓设计,做好计划的基础性,自己主要负责或者带领核心开发人员构建良好的基础框架并编写封装公共代码(你要叙述你参与了重点技术工作)。持续交付和微服务开发,基础很重要,这是“速度”的基础...

        本文阐述敏捷开发的相关要点,做到理解切忌照搬硬套,特别是如果针对面试,对于场景类的描述,一定要变通!

    敏捷开发的一些问题
    说一下你对敏捷开发的理解,为什么要使用敏捷开发?
    》瀑布模型的典型问题就是周期长,发布烦,变更难。
    》敏捷开发就是快速迭代,持续集成,拥抱变化。
        所谓“敏捷”,顾名思义,可以通俗的理解为“短平快”,抽象点的可以说是“一种需求进化”。
    采用快速迭代、循序渐进的方法进行软件开发,通过持续交付的方式不断的交付一个一个子系统,每个交付的子系统都经过测试,具备可集成可运行的特征(这也决定了大的项目在一开始就要被合理的规划和切分为多个子项目)。换个说法就是把一个大项目拆分为多个相互联系,但也可以独立运行的小项目,并分别完成。
        a) 因为敏捷开发的特征,将项目的大目标切分为N个小目标,使得每个目标都简单直观可达性更强。不管是客户、项目经理还是开发者本身,能快速的看到“成果”都是一种好事。化整为零的方式是一种更好的方式,就好像搭积木,将复杂事情简单化的,问题这个攻克,项目逐块交付。
        b) 对于客户而言,也有这样一个场景:我做过整体交付的项目,也带过持续交付的项目。同样跨度都是八九个月(你要能对应到你简历上的具体项目,别一问就穿了)。其中一个项目就是,我们分了4次迭代交付,前面几个月交付了一个版本。客户就推向市场下发给普通用户使用了,然后后面每隔一个月上了一块功能。这样对客户来说可以更快的抢占市场(我理解市场的时间价值成本是非常昂贵的)。不断的更新新的模块,从用户角度也能感知产品的升级带来的效果(这就是为什么我们有的APP产品要每隔1年左右做一个UI改版一样,明明业务没有什么改变,单也要换个皮,其目的就是为了用户,话说不在乎用户感受的项目经理和产品都是不合格)。
        c) 还有就是甲方一般都特别担心的质量问题:谁付钱谁忧虑这本就人之常情,敏捷开发逐步交付的成果“相对较小”,对于质量更容易量化,因为持续交付,问题可以提前发现提前解决。不合理的问题可以“提前转舵”,避免后续持续产生类似的问题。
        d) 因为敏捷开发的特性,使得团队互动性增强。因为互动性的增强,使得每个人都能相对收益。
        e) 劣势:上面说了敏捷注重人员的沟通,若项目人员流动大太,会给维护带来不少难度,特别项目存在新手比较多时,老员工比较累。需要项目中存在经验较强的人,要不在大项目中容易遇到瓶颈问题,对项目的把控者有更高的要求,或者在必要的时候公司有相对专业的人或团队给予指导和支持。
    总结: 敏捷开发是是一个非常有价值的方式,特别适用于持续演进的项目(比如互联网产品或长期执行下去的项目)。对于短小交付就彻底结束的项目则不太适合。对产品对成本对成员有价值的东西,没有理由不用。
        严格来说敏捷开发由迭代+增量组成。持续交付的敏捷才是更有价值的,也就是上面说的不止迭代了,还可以不断的增量上新(用户可感知)。
    由于敏捷开发可以不断试错,迎合市场的可以加强投入,反之可以淘汰。而不是等整个大而全的项目完整完成统一上线才发现就有些不合适了。

    上面是叙述,下面的内容来自互联网,供参考(要理解记忆和挑几点说就行了):

    一、敏捷开发技术的几个特点和优势:
    1.个体和交互胜过过程和工具
    2.可以工作的软件胜过面面俱到的文档
    3.客户合作胜过合同谈判
    4.响应变化胜过遵循计划
    二、敏捷开发技术的原则:
    1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    2.即使到了开发的后期,也欢迎改变需求。
    3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。
    4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    5.围绕被激励起来的个人来构建项目。
    6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
    7.工作的软件是首要的进度度量标准。
    8.敏捷过程提倡可持续的开发速度。
    9.不断地关注优秀的技能和好的设计会增强敏捷能力。
    10.简单使未完成的工作最大化。
    11.最好的构架、需求和设计出自于自组织的团队。
    12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
    三、敏捷开发技术的适用范围
    1.项目团队的人数不能太多
    2.项目经常发生变更
    3.高风险的项目实施
    4.开发人员可以参与决策
    四、其他条件
    1.团队要小,人数超过一定规模就要分拆
    2.团队成员之间要紧密协作,客户也要自始至终深度配合
    3.领导们得支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性
    4.写代码时要有一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。

    你哪个项目中使用了敏捷开发?如何实施敏捷开发?产生了哪些实际效果?
        上面敏捷开发的理解和方式,其实对面试官考察表达能力和理解能力的。现在这个问题更重要的是“如何做的”,能真正知道怎么做的,才是相对靠谱的,因为执行力很重要。
        关于敏捷开发方面如何管理,如何计划,如何把控更偏重于管理,根据自己经验,使用“举例场景”的方式叙述,下面说一下微服务和持续集成的一些要点。
    举例说明之前做的某项目或某项目和某项目是自己实践过的。
        当今主流方式微服务、CICD、容器化、自动化,你可以说你当时使用了微服务、CICD、容器(也不一定说全,你不是万能的,有的工作是有单独的团队做的,但是你要强调你在不同团队协作中的作用,这也是你胜任项目经理的职责)持续部署和自动化测试一般都有独立的运维和测试团队来完成,但是你作为项目经理,你也不能只会协调(开发、测试、运维三板斧的第一板斧是必须要擅长的)
        微服务按业务拆分,做到业务层面的高内聚低耦合。有利于扩展也是微服务的一大特性。作为项目经理,前期你抓设计,做好计划的基础性,自己主要负责或者带领核心开发人员构建良好的基础框架并编写封装公共代码(你要叙述你参与了重点技术工作)。持续交付和微服务开发,基础很重要,这是“速度”的基础(比如高铁的铁轨要求就很高)。必要基础平台和基础框架是堆积业务的根本(你可以说你最近几年做的项目和产品自己本身也积累了相关经验)。
        实施敏捷开发,前期要做好很好的设计功底,该拆的拆该细化的细化。你当时推动的时候,不能一蹴而就,要使用新的业务模块来演进(这也是引入任何新的东西的一种常用方式),也叫“试水”。将风险较低的业务走这种路线,打造一个完整的体系后,接下来就是其他业务逐步迁移的事了。如果老业务不需要迁移升级,未来的新需求按新的方式进行即可。
        实施过程中,需要公司领导和重要技术岗位成员的支持,比如你当时项目中因为推动的时候也有一些成员排斥、遇到了一些阻力(革命哪有不流血的,适应了就好)。跟相关人说明这样做的原因,甚至可以说这是公司领导层对未来趋势的要求(有时候把领导搬出来也是做事的一种方法,可以适当的采用,做人做事要灵活嘛)。然后从自己负责的范围内(毕竟自己对自己这块还是有话语权的)推进和落实,再横向推动到其他团队甚至整个公司(整个过程是需要很长时间的,不要张口就说你一个月就推完了(如果你直接上到一个没有包袱的新项目中那可能很快),正常来说整个公司都演进下来步入整个轨道,至少半年以上,1年左右很正常,因为公司本身业务是要持续前进的,不是停下业务的脚步只干技改)。
        产生的效果:很明显,老板经常能看到产品在变动,不断有功能上线也获得了用户的反馈(当时有的用户甚至说:呀,最近XXX客户端的程序猿是不是开启机器人模式了,老发版发功能,面试是一个综合的过程,不只是死气沉沉的回答问题,你既然是项目经理活跃气氛也是这个岗位的职责)。还有就是我们为快速迭代拆了微服务,当时就有某个模块因为开发代码写的不够好性能压力上来了,我们单独给这个服务加了个节点部署,开发都没参与,运维搞一下扩展个节点即可(然后开发这边优化处理后又升级的)。如果是中心化系统,要整个系统部署一套,影响面就不好说了。
        刚刚也提到了CICD,你当时进公司的时候公司是什么现状(比如大家都是手工做事,经常出一些小问题,回退版本什么的都麻烦,发布包管理不够好,经常扯皮等等)你的CI是基于Jenkins的(按你对行业的持续关注度一般来说Jenkins可以满足大部分公司使用,如果公司的基础平台和架构团队发展到一定程度,变会衍生开发自有平台):你们当时基于git管理代码,因为git更适用于CI,分支和版本很强大。开发者提交代码后,Jenkins可以感知代码变动,会自动对代码进行编译,如果编译失败发送邮件通知开发者。同时会自动触发sonarqube进行代码扫描,开发者可以到sonar平台查看代码的质量问题,对存在的隐患bug或不规范写法进行纠正(你可以说很多时候机器比人靠谱所以代码扫描很有必要,重要的业务逻辑需要人工参与代码review)。你写了Jenkinsfile文件,使用pipeline脚本(你说到这块对方一般就知道你真实使用了)做了配置,针对develop、release、master(gitflow的分支模型你要了解一下,人家可能会问你分支模型)分支会自动将编译后的包打成docker镜像并自动发布到docker仓库。你要求重要的业务必须要写junit用例(可以说下因为写junit用例会增加开发量,所以你根据项目和公司的质量情况做的要求是针对核心和重要业务必须写没有强制全部写因为需要代价啊也就是要花钱啊,代价和成本是项目经理要考虑的职责),这是CI的过程。
        CD的过程,也是基于Jenkins触发服务器脚本来实现自动发布(服务器脚本前期采用docker-compose简单化编排),后期公司让运维慢慢引入了K8S(你如果熟你可以详细说,如果这块不熟悉,你就说这块交给了专业的运维,这块更重运维)。K8S给Jenkins提供一些脚本和接口,CD这块便OK了(在前期直接Jenkins操作服务器脚本完成自动部署)。

    使用微服务进行敏捷开发要解决哪些问题?
        服务被颗粒化之后,就更适合容器化了,现在docker+springboot微服务组合比较常见。
    服务多了,就要管理,管理代价就会提示,加上容器化之后容器可能随时升级被整体删除替代。加上springboot的打包方式(jar)和docker镜像的方式,使得配置可变性变的困难,文件存储、日志、配置、调度,这些都要提取进行统一管理,服务的注册发现可以使用Spring的Eureka,服务调用使用Feign,你熟悉dubbo的话也可以说。如果使用容器,有专业的运维可以上K8S一套进行容器编排更好。
        比如日志使用ELK,可以在docker内启动filebeat被动收集日志,也可以在项目中直接将日志写入Logstash、kafka、ElasticSeach都有方案(高可用的架构会带来复杂度,所以要根据项目实际业务情况选型决定,任何脱离业务的技术架构都是耍流氓)。
    配置中心你使用过Spring Cloud Config 、Nacos、Disconf,现在使用Apollo(或其他,你熟悉哪个就说哪个,不过Apollo现在挺主流的),这2个东西你要简单了解下,更多的你要告诉对方你为什么用这个。或者为什么从A换成了B。
        调度中心,用xxljob就够用(如果你自研过也可以讲讲,根据自身情况介绍),也OK。
        公司有独立的文件系统,你知道的提一下就行,你也可以说你直接用的阿里云OSS(或其他你熟悉的NAS、fastdfs、ceph等等)。
        服务化之后,服务变多了。全链路跟踪也变的更为必要,这个你之前的方案是SpringCloudSleuth+Zipkin,你如果熟悉Jaeger也可以说。
        监控方面,SpringCloud的Hystrix Dashboard+ Turbine。
    其他方面的,根据自己情况发挥,这些应该说了不少了。只要你理解了并描述清楚,基本也差不多了。
        不是每个人都可以全盘非常熟悉所有,对于会用和没有深入研究的。你可以根据自己的岗位来折中的回复对方。比如你是项目经理,你重点在项目成员、进度和质量把控,但是你持续关注技术,也会参与重点开发,平时重点解决团队内大家都不熟悉的技术(让开发人员更专注业务开发)。如果某块有很熟悉的团队成员,可以更好的利用团队成员的能力,把人用好对项目经理来说也很重要。
    相关的问题可能性太多了,平时还是要多看资料,灵活的协调人和回答问题本身也是一种能力,所以面试上不仅仅只考验纯技术,其实是对一个人的综合判断。

    有一句话是这么说的:敏捷是瓷器活,你得有金刚钻。字里行间都表达了对人的能力的要求。

    展开全文
  • - 没有自信:不觉得自己能做好 - 业务不熟:我和组员同是新人,大家都不熟悉 - 人员不熟:不知道组员技术能力水平,擅长和偏好 解决 调整心态 问老板选我的原因,找到我的优势,怎么弥补劣势 快速学习 不懂就花...

    阶段1:是个苗子,任命

    我能行吗?要干不好怎么办?。。。
    首先要第一时间答应,然后跟老板谈一下:
    

    问题

    - 没有自信:不觉得自己能做好
    - 业务不熟:我和组员同是新人,大家都不熟悉
    - 人员不熟:不知道组员技术能力水平,擅长和偏好
    

    解决

    调整心态

    问老板选我的原因,找到我的优势,怎么弥补劣势
    

    快速学习

    不懂就花时间弄懂! 看代码是最有效的
    

    细节致胜

    需求分解,项目计划尽可能的细
    代码每处修改要了然于心
    上线每个步骤要规划到位
    

    人知提升

    1、在这个项目中你的角色是什么?
    2、你是否有这件事做成的独特价值?是什么价值?(发挥独特价值)
    3、 哪些方面还不足以做好这件事(规避和改进)
    

    阶段2:哟还行啊,难点

    系统熟了,收获也有了,还蛮有成就感的
    -》
    我曹这次的项目这么难,这么大

    问题

    天天事情做不完
    项目也开始频频出现问题
    设计不合理、延期
    提测质量不高、线上bug
    

    困境

    项目复杂:项目从电商到涉及整个云配甚至集团
    人员增多:单一项目组变成多个项目团队,参与人翻几倍
    风险增大:不可控因素更多
    

    解决

    设计下放

    完成总体设计即可
    以团队成员详细设计为主
    只做设计把关
    

    心得:

    不要过于插手过分要求,防止打消成员的积极性与能动性
    省出时间来关注更重要的事
    

    减少开发

    合理任务分配
    核心功能不参与开发
    尽量不替他人改bug
    

    心得:

    尽量不要把自己放到业务里,避免这里只有你自己知道
    不要成为某一业务的代言人,否则一有问题就找你,那时你就处理不完的问题。
    省出时间来关注更重要的事
    

    风险记录

    识别风险,应对策略,记录文档
    风险及时上报,不把压力留在自己身上
    

    心得:

    进度风险及时汇报,成为一个**可控可信**的人!
    

    人知提升

    这件事我怎么做的更轻松?

    1、项目再大点怎么办?团队成员更多了怎么办?
    2、哪些事还没做到位?
    3、我做了哪些不该做的事情?
    

    有点意思,干他

    经验丰富啦:

    做好总体设计
    做好技改要求规划
    项目计划信手拈来
    

    多提出质疑

    Prd评审
    详细设计评审
    测试用例评审
    

    团队:

    多让组员锻炼学习
    尽量自己找到解决方案
    提高团队整体水平
    

    有更多时间来:

    思考架构问题
    思考流程改进
    思考人员管理赋能
    

    人知提升

    跳出团队,整体提高

    这件事怎么让团队做的更好?

    从关注部分 到 关注整体
    从关注事 到 关注人
    从关注功能 到 关注价值
    从追求最优 到 关注平衡
    

    三个类型
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    如何往其他团队里插入需求?
    平时就和其他团队的leader ,主要人员搞好关系,喝喝酒,抽抽烟,聊聊人生。。
    如何让大家自愿加班?
    阶段时间明确,进度随时沟通,风险及时同步,加班可能性时长告警。千万不要最后一天突然告知加班!
    调动老板,画画饼,给点鼓励和福利之类的

    展开全文
  • 本文以笔者所主持的某卷烟厂物流控制及管理信息系统项目为实例,探讨了信息系统项目整体管理在项目实施过程中的重要性,并分别论述了项目计划编制、项目计划实施,以及项目综合变更控制等项目整体管理过程,在整个...
  • 支持企业实施的多个技改项目归并后集中申报,申报的多个技改项目均应入库纳统。 (二)支持标准 专项审计报告明确的建设有效期(不超过两年)内实际完成的生产性设备购置与改造投资额,按照8%的补贴比例予以安排,...
  • 近日,市委办公厅、市政府办公厅印发《关于打造国内一流枢纽机场等16个重大项目行动方案》的通知,立足福州市现有产业基础、资源禀赋、政策优势和发展趋势策划推出16个重大项目行动方案,旨在进一步激发福州产业发展...
  • 由于市场需求的不断变化以及对产品的要求越来越高,由于技术的进步以及工艺的不断发展等各种原因,工厂、企业...本人从事技术改造项目的管理工作多年,曾经管理过大小几十项技改项目,深切体会到在技改项目的管理中...
  • 上两篇整理了技术管理的概念和内容,下面结合运营商企业的状况来思考一下如何做好技术管理。 一、技术管理的组织 对企业来说,按照职能进行部门划分是最常见的,所以往往开始就只有一个技术部门,但是随着企业业务...
  • 吉林市热力集团有限公司供热工程(以下简称供热工程)主要由五方面构成:利用日元贷款建设工程(以下简称日贷工程),公司基建工程,公司大修技改及单户改造工程、常规检修工程,新入网工程,热计量工程。...
  • 中国经济的迅速发展,使每年的项目投资多达万亿元,几乎含盖了经济、文化、科教、国防等所有重要领域,诸如银行贷款项目,能源、交通、水利等基础设施项目,房地产项目,农业发展项目、工业企业技改项目、环保项目、...
  • 项目是 ASP+ACCESS+IIS 构建的管理系统,生命周期2006–2012,已由新的版本PHP+laravel+vue+MYSQL替换 功能包含:设备台账管理 设备更换管理 设备检修记录管理 新闻管理 #仪表设备主要有以下特点: (一)是设备分布...
  • 襄城县首山一矿智能化改造及产能提升项目鸟瞰图2月26日上午,许昌市2020年第一批集中开工重大项目暨首山一矿智能化改造及产能提升项目开工活动在襄城县举行。本次襄城县集中开工首山一矿智能化改造及产能提升项目、...
  • 企业授信审查主要指的是,审查人员根据授信调查人员的调查报告以及其他材料,同时结合项目的具体特点,通过综合分析授信的合规性、申请人或保证人行业情况、经营与财务状况、授信用途和还款来源、抵(质)押缓释措施...
  • 全新电网技术改造定额软件,凡购买超人电网技改软件可以-赠送价值570元定额书,活动期间名额有限,请速与我联系。联系人:魏先生 电话13392455660 QQ:1443963905 《电网技术改造工程预算定额》、...
  •  (详情请咨询深科信) 对经评审达到国家标准《智能制造能力成熟度模型》三级及以上的国家专精特新“小巨人”企业,实施的技改项目按项目设备、配套软件投入的25%给予补贴,其中,对从本区企业购置的生产设备,额外...
  • 为全市规上工业企业免费提供诊断服务,并按照企业智能化改造实际需求,有针对性的出具诊断报告,帮助企业共同组织项目实施,积极配合做好示范项目应用推广。市经信局每年组织相关专家对诊断平台专业服务能力、服
  • 面试经验交流-IT女力战项目管理

    千次阅读 2013-01-25 13:56:27
    毕业的第三个年头了,最近想尝试的看看自己的...答:个人介绍+工作经历+工作内容+项目经历 2、问:离职原因 答:组织架构调整 3、问:未来3-5年的规划(其实我个人很讨厌这个问题,方向可定里程碑不可定) 答:IT规
  • 由外单位完成的整体改造或技改项目;设备的重新选项和整体更换。(2)课题命名大有讲究 问题解决型课题应尽可能直接表达课题的特性值,一般课题命名方式为“达到的结果+要解决的对象+问题特性”,其中“达到的结果”...
  • 技改前故障不断,其主要的一个原因就是物理架构不合理,运维要占60%、70%的责任,当时却把责任归咎为应用架构,这是个错误的方向。物理架构的不合理,应用架构是很难合理的,因为物理架构是我们的基础设施,位于最...
  • 正是当时对他们行业有个错误的判断,才促使拼命的多元化投资,主业丧失了竞争的优势,甚至于错失了技改的机会,设备变得非常陈旧。 这时,发现土地值钱了,原来所有的蜂窝煤厂都是在城市的中心,有些房地产大亨...
  • 研发人员绩效考核案例

    千次阅读 2015-02-24 21:10:28
    比如对项目管理部的技术管理员的考核指标为项目管理水平、决策评审点执行率、技改技措管理水平、技术服务满意度。 第三部份 实施考核的效果跟踪 笔者对绩效实施的指标值进行了跟踪。半年后,90%的项目延期...
  • 信息系统项目的整体管理是项目取得全面成功的一个至关重要的前提和基础。通过项目整体管理,可以确保项目所有的组成要素在适当的时间有机地结合在一起,以顺利、成功地完成项目。这在本人所主持的某卷烟厂物流控制及...
  • (7)企业发展:后期对企业在企业金融服务上有倾斜,提升本企业在金融市场融资吸引力,获得此荣誉(能获得此荣誉的企业代表企业的成长性好专精特新中小企业申报范围)后期在企业技改项目,培育项目资助申请上有政策...
  • 企业发展:后期对企业在企业金融服务上有倾斜,提升本企业在金融市场融资吸引力,获得此荣誉(能获得此荣誉的企业代表企业的成长性好专精特新中小企业申报范围)后期在企业技改项目,培育项目资助申请上有政策倾斜。...
  • 信息系统项目的整体管理是项目取得全面成功的一个至关重要的前提和基础。通过项目整体管理,可以确保项目所有的组成要素在适当的时间有机地结合在一起,以顺利、成功地完成项目。这在本人所主持的某卷烟厂物流控制及...
  • 创业计划书-某电子报税系统项目建议书 创业计划书-某电子科技公司商业计划书 创业计划书-某冬枣项目商业计划书 创业计划书-某度假村策略思考及广告执行计划 创业计划书-某段堤防工程可行性研究报告 创业计划书-某...
  • 作为 Leader,分解工作、向下授权是日常管理中的重要组成部分,也是管理者需要不断...以结果为导向,安排一项重要的工作给团队成员,最基本的是将任务执行完成,最重要的是将工作顺利做好,最期待的是将工作做得出彩。

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 180
精华内容 72
热门标签
关键字:

做好技改项目档案