精华内容
下载资源
问答
  • 交付管理——怎样构建项目团队
    千次阅读
    2020-08-27 18:18:24

    对于TO B类软件公司,尤其是偏项目型的公司来说,把项目签下来只是万里长征走完了第一步,能否把项目交付好才是关键,我见过太多的软件公司不是死于没有项目,而是死在了项目交付不了。

    怎样做才能把项目交付好,确保公司的可持续经营,是每一个创业者在创业初期就要想清楚的问题。在这里,我想先从组织架构讲起,跟大家聊一聊怎样构建项目团队。

    对一个公司的经营来说,如何把管理效能最大化,是每一个管理者都要考虑的问题,而项目团队作为组织架构的最小单元,其配置是否合理,是影响公司整体管理效能的关键因素。

    对于纯做产品的公司,其组织架构是职能型的,没有交付部门;对于纯做项目的公司,其组织架构是项目型的,一个项目就是一个部门。而TO B类软件公司一般都是既有产品又有项目,其组织架构是矩阵型的,职能部门养兵,业务部门用兵,有了项目才会成立项目团队去交付,因此项目团队是个临时性的组织。

    一、项目团队应该如何配置?

    项目团队的配置关键要看产品的成熟度。

    对于标准化产品的实施,比如财务系统,通常只需要一个实施顾问就可以了。所以金蝶、用友的实施顾问,一个人就可以同时负责几个项目。

    对于既有标准化产品又有个性化开发的项目,实施起来会相对复杂,需要成立项目团队,其基本配置大概如下:
    项目经理: 负责项目整体把控,包括团队的日常管理,客户沟通,需求梳理,原型设计等工作。如果项目小,出于节省成本的考虑,还要兼职数据整理,系统测试等工作。
    开发工程师: 包括前后端的开发,如果有移动应用还需要移动端的开发。负责系统设计、开发等工作。在开发人员中需要有一个技术组长,负责对需求实现的工作量进行评估,制订开发计划,分配开发任务,遇到技术难题时能够带头解决。

    对于完全定制化开发的大型项目,还需要增加以下角色:
    需求分析师: 负责协助项目经理整理客户需求,编写需求规格说明书;
    UI设计师: 负责协助项目经理画界面原型。一个好的UI工程师,不仅可以实现界面的友好性,同时也会兼顾到操作的易用性,即UE的工作;
    系统架构师: 负责协助开发组长设计系统架构,搭建数据模型。
    数据库管理工程师:即DBA,负责数据库的安装、部署、配置等工作;
    测试工程师: 负责系统的测试工作,包括单元测试、集成测试,原型测试,测试用例的编写,测试计划的制订,测试报告的输出,BUG的跟进等。
    在这些角色中,除测试工程师外,不需要全程参与项目,在使用时需把握好使用效率,在满足前置条件的基础上提前做好规划。

    项目管理也存在木桶理论,决定管理效能的永远是最短的那块板,所以项目团队的配置要尽可能均衡。

    二、怎样选择项目经理?

    一个好的项目经理是项目成功交付的关键因素。

    赛意信息科技有限公司董事长张成康先生在跟我分享赛意的成功经验时特别强调了项目经理的重要性,他说到在没有找到合适的项目经理前,即便有项目他也不会接。我对这句话的印象极为深刻!时至今日赛意早已成为了上市公司。

    对于项目经理的人选,历来有两种观点,一种认为应该由业务顾问担任,因为业务顾问可以更好的理解客户需求;一种认为应该由开发顾问担任,因为开发顾问可以更好的实现需求。我认为由哪个角色担任项目经理关键是看产品的成熟度,如果产品成熟度高,开发工作量小,业务顾问会比较合适,反之,则开发顾问会比较合适。

    另外,项目经理首先需要的是管理能力,其次才是专业技能,因此在其他条件相差不大时,谁的领导力强谁就更适合担任。

    当然,如果一个人既有与客户对接的能力,又有一定的技术功底是最好的,但这样的人很难找,或者即便能找到,成本也很高。

    三、资源不足时怎样确保项目团队的正常运转?

    在实际的项目实施中,项目团队会经常出现人员不到位,资源不足的情况,怎么办呢?

    两种方法,一是内部消化,二是向客户借力。

    内部消化,可以通过内部补位的方式把工作分配下去。一般来说,项目经理应该是个万金油,除了写代码外,任何岗位都是可以胜任的。而需求或开发人员也能够担任测试工程师的角色,开发人员可以交叉测试,根据测试用例相互测试对方开发的模块。

    向客户借力,实施项目团队的成立不是单方面的,客户的人也要参与其中。有经验的项目经理一开始就会把客户的人拉进来,一起整理数据,一起参与测试,有些客户有独立的IT部门,具备一定的开发能力,则把这些开发人员全部调动起来,以熟悉系统,帮助客户培养人才的名义给他们分派工作,以此来弥补自身资源的不足。而且这样做还有一个好处是可以让客户深度参与,客户参与度越高项目成功的机率也就越大,因为大家都希望自己的工作能够得到别人的认可,不会去轻易否定项目团队的工作成果,这就是人性!

    以上是我在项目团队组建方面的经验总结,接下来我会继续分享有关项目交付方面的方法和技巧,有兴趣的朋友可以和我一起交流,感谢大家的关注!

    更多相关内容
  • 交付型项目经理

    2021-08-07 08:41:25
    交付型项目经理是因为公司的组织机构而产生的,也是因为工作的重心不同而产生的。 如果你在后台部门做项目经理,那么你就是研发项目经理; 如果你在中台部门做项目经理,那么你就是交付型项目经理; ...

    交付型项目经理是因为公司的组织机构而产生的,也是因为工作的重心不同而产生的。

    • 如果你在后台部门做项目经理,那么你就是研发项目经理;

    • 如果你在中台部门做项目经理,那么你就是交付型项目经理;

    • 如果你在前台部门,那么你就是售前项目经理

      交付项目经理的工作内容定义:

      当销售拿到一个项目的时候,就会去寻找一个可以帮他完成合同的人,这个人就是交付型项目经理。

      交付型项目经理接到这个任务后需要仔细研读合同内容,然后列出完成合同内容需要哪些产品部门,以及哪类级别的人员才能在规定的时间内完成,或者按照什么频率提供给客户需要的数据、报告等。

      所以说,交付型项目经理需要负责项目的交付,有非常明确的目标,范围,和时效性当项目完成后,就与项目经理无关了。

      项目经理是一个有责无权的岗位,看似权利很大,负责整个项目,实际上项目经理下面没有属于自己团队也没有实质性的权利,所以为了项目能顺利交付,交付型项目经理需要去争取调动任何可调动的资源,然后组织大家协同工作,确保项目能交付。(所以项目经理在前期需要和每个同事都处理好关系,方便后面办事。)

      当然,在整个过程中,项目经理还需要做整体的把控,除了要判断标准产品是否符合合同内容之外,还需要严格把控项目的成本。(因为多一点成本,就意味着项目的奖金会比变少。)

      交付型项目经理的岗位职责,可以总结如下:

    • 拉通前端销售和后端交付实施环节,保障合同与交付质量,可在项目需要时介入投标环节进行合同质量提升工作。

    • 合理有效的运用项目管理知识、工具和技能,制定项目管理计划;协调、管理和控制内部及周边资源,保障项目高效交付,提升客户满意度。

    • 参与客户大数据顶层规划设计,包括需求调研、需求分析,能够编制客户方大数据解决方案,撰写相应的实施方案文档以满足客户需求。

    • 熟练使用PPT撰写分析报告、向客户演示研究成果,完成项目汇报。

    • 负责公司项目交付人员的团队建设,各项目的人员调配和资源协调安排。

    展开全文
  • 大型互联网项目的持续交付模式.pptx
  • 项目交付体系

    千次阅读 2020-08-05 13:56:46
    伴随公司的逐步发展尤其是产品软件公司,企业的产品逐步趋于精品及完善,但如何能够提高项目交付速率,将项目交付批量化、产品交付成熟化、产量化,实现此过程的前置条件有哪些,距离当前的目标还需要做哪些事情,...

    项目是为了提供独特产品或服务而暂时承担的任务,项目的特征是临时性和唯一性。伴随公司的逐步发展尤其是产品型软件公司,企业的产品逐步趋于精品及完善,但如何能够提高项目交付速率,将项目交付批量化、产品交付成熟化、产量化,实现此过程的前置条件有哪些,距离当前的目标还需要做哪些事情,本文将从道(目标、战略、远景)、法(制度、规范、保障机制)、术(方式、方法以及熟练度)、器(环境、工具、产品)、人(意识、心态、欲望、人性)五个层面分别阐述说明。

    明以道

    道是根本,是规则、自然法则,上乘。建立项目交付体系,提升项目交付率,实现项目交付批量化的顶层构建依赖于“道”。“道”类于产品架构设计属于顶层规划设置,在“道”里提下“势”、顺势而为,在国际、国家、行业整体大趋势下决定公司的发展方式与方向,顺大势而行软件行业经由无纸化办公至信息化整合乃至现在更为广泛的产业互联网、5G、云物移大智等。道与势结合,在道的规划结合势的辅助更可将事情事半功倍,取得更好的成果。

    1.行业聚焦

    人的精力是有限的同样公司的精力也是有限的,作为公司的运营及发展同样需要聚焦行业,作为公司的运营能够“广撒网多捕鱼”固然有一定成效,但是“专精”才是公司的立身之本。在公司有广泛涉猎的同时需要聚焦行业,深耕行业,了解行业的发展历程、趋势、特点,结合客户的业务特点丰富、完善平台的功能及交互模式。如:地产行业下主数据管理是围绕地产项目为全生命周期管控的,而过程中可能还会涉及基础数据与项目间的关联如房源、期、栋等;业财集成过程中会涉及到成本对接、四费回写(开发间接费、营销费、管理费、规费类)。

    2.项目筛选

    在公司当前阶段不是力求“广而杂”,而是需要“专而精”,主要聚焦于集成领域,意在为企业尤其是集团性企业搭建“一站式”整合平台,构建柔性IT架构,公司战略层面明确公司的专业的领域,当前公司主要精力在集成开发、开发集成两大类项目,致力于公司整理的运营方向及发展方向,公司主力的营业范畴,包含数据治理、统一身份认证、数据治理分析、统一门户集成、统一流程集成几个方向,主要行业在于制造业、建筑业、房地产等多以项目制度为管理方式的行业领域。在商机落地、项目承接选择阶段需要甄别项目是否符合公司发展且是否能够为公司带来价值。

    如公司目前主营对接方案ESB、IDM+ESB、MDM+ESB、ESB+MDM、MDM+ESB+DAP的主要承接侧重要点如下:

    1. ESB应用对接:主要解决客户有3~5套系统间的表单数据对接,服务开发提供的情况;
    2. IDM+ESB统一用户管理:实现客户信息化系统用户统一、认证统一、权限统一、审计统一的4A管控,实现用户账户密码统一无需在系统间返回切换登录,提供工作效率;
    3. MDM+ESB基础数据治理:实现客户主数据治理及规范,建立基础数据管理体系,保障数据的一致性、完整性、准确性,为客户应用集成及数据分析结果的准确性提供坚实的基础支撑;
    4. ESB+MDM应用集成对接:实现客户信息化系统集成,结合主数据时间系统数据映射的管理,为后续数据治理规范奠定基础;
    5. MDM+ESB+DAP数据治理分析:沉淀企业业务数据建立企业自身数据仓库,挖掘企业内部数据价值,将数据可视化、趋势化、价值化。

    3.方案匹配

    匹配公司主营领域及主要行业领域对应项目类型均需要匹配对应的落地方案给予支撑,方案不仅限定于售前沟通方案、项目落地解决方案及同行业案例分享等。

    1. 售前沟通方案:方案主要体现在几个层面如:项目领域的意义与价值,项目主要背景需求,解决客户问题及痛点分析,典型落地方式及优劣比较,同行业对应的案例类比分析。
    2. 落地解决方案:侧重体现结合客户的实际情况针对客户的痛点如何落地解决,通过什么方式解决哪些问题,预计带来什么效果,需要哪些投入及能够输出哪些产出。
    3. 同行业案例分享:主要体现当前案例的背景,痛点,解决方案及实施效果,侧面印证、体现同行业其他公司确实由此方案受益颇多。

    行尊法

    法是措施方法,是实现价值的方式及方法,项目交付过程中仅依赖于框架的体系理论同时对于项目人员思维意识,思维转变也是重中之重,由程序思维转变为用户思维,用户思维转化为产品思维,产品思维晋级为商业思维,只有这样才能很好的实现产品有自己用向友商用及面向用户的交付。同时加快交付、成体系的交付、实现项目做好、做快、做规范、做批量。

    1.体系支撑

    “没有规矩不成方圆”,公司层面关于整体管理体系需要不断的充实、完善,对于公司运营的全生命周期的管控均需要建立完善体系制度,如:商务体系,售前体系,人员体系,项目管理体系,实施体系,奖惩体系。

    1. 商务体系:明晰内部商务、外部商务之间的衔接关系,促进商务与客户间的对接,提升商机的落地促成的几率。
    2. 售前体系:明晰售前沟通、汇报、交流、跟进的各周期的工作内容及工作边界,配合商务促进商机的成单率。
    3. 人员体系:对于人员培养,意识、方法、工作方式、沟通、汇报、学习、管理等多方面全方位系统化培养模式;
    4. 项目管理:项目全生命周期管理,需求、设计、开发、测试、上线、交付、验收、运维,8位一体的全生命周期管理,各里程碑注意事项等;
    5. 实施体系:项目现场交付注意事项,沟通机制、汇报机制的明晰与管理,与客户不卑不亢,与友商化敌为友,与伙伴共进同退;
    6. 奖惩体系:明晰项目的奖惩管理,以奖励促进成员的积极性,更加助力于项目推动及交付。

    2.绩效考核

    公司员工潜能的开发需要鼓励与鞭策并存,在鼓励的同时与压力并存,在压力的临界点伴随鼓励共同推进,一方面有压力驱动员工向前推进,一方面有鼓励增加推进项目工作的动力。建立项目绩效考核体系,有奖励有惩罚双管齐下,同时不仅面向项目交付团队,对项目管理人员,销售人员均需要具有全面的考核体制,管理人员关心KPI才会关注项目实际推进情况,销售人员具备考核指标能有效保证项目相关动作的推进,交付团队明细目标才能够保证项目的交付。

    • 项目管理制度

    1. 阶段划分:不同阶段的侧重点、工作内容、交付输出物的明确与规范且需要输出样例文档;
    2. 需求明确:项目调研过程中明确客户需求,不要含糊而过,将自己的理解与客户确认,框定项目的需求范围。
    3. 设计细致:结合项目需求进行可落地的详尽设计,明确功能约束,技术要点,设计需要详细明确出相关功能的涉及到的基于预研、落地实现。 
    4. 计划精细:项目计划需要明确到人、详细到人天,同一项工作不能有多人同时负责,如果是多人负责则需要把工作进行再次拆分直至明确至个人,计划在实施过程中需要不断完善、精细,周计划明确至人、天,日计划细粒度至少0.5人\天。
    5. 人员分配:不同角色的职责划分,什么人什么时间应该做什么事情;
    6. 汇报管理:按风险、日、周、月、里程碑不同粒度对项目负责人、销售同步项目情况,保证消息的对称性;
    • 绩效考核制度
    1. 考核指标:规范考核指标,考核与绩效挂钩,不同完成度的奖励及惩罚机制,成体系落地执行;
    2. 节点考核:对项目各里程碑节点、收款节点、工作完结阶段需要明确标记出来,以各环节节点倒逼工作管理,输出工作审查情况;
    • 人员晋升制度:分角色、分岗位的晋升制度,不同岗位有明确的职业规划方向,员工可选择自身的规划及发展方向,明确对应T级的晋升制度;

    3.人员培训

    建立员工培训体系,除平台基础操作外需要模拟项目实际进行内部演练,保证新员工对项目整体过程及不同类型项目有整体的意识及交付的概念,明确什么是好的什么是不正确的。

    1. 公司认知:公司为平台产品的提供商及技术解决方案的提供商,对于普遍的承接项目研发公司存在着本质性的不同,对于公司员工需要明晰公司的立身之本,公司的盈利项及公司的发展方向。
    2. 项目认知:作为项目交付需要明晰项目验收是项目完成的基本盘,而项目衍生二次商机,项目运维服务盈利才是项目的本质目标,而实现目标的前提则是为项目提供友好的服务为客户解决实际问题。
    3. 意识方法:项目交付过程中需要具备团队意识、敏感度、责任心,遇见问题暴露问题,解决问题而不是等着事态爆发,一发不可收拾的状态。
    4. 职责明晰:项目交付过程明细各岗位职责,项目经理对项目整体进度负责,把控项风险;技术经理对项目过程中技术问题支持,保证项目技术落地;技术顾问保证自己负责项目工作的进度,同时熟悉项目整体流程及注意事项。
    5. 策略技巧:无论是哪一类型的项目最终都是需要与人打交道,在此过程中不要与客户发生矛盾,与客户关键人建立友好的沟通渠道,权衡其中关系,更好的推进项目。

    精于术

    术是体现,是具体手段。通过法具备方向的指导,结合术的手段落地,项目交付过程中在建立规范的同时需要能够对规范实现落地而不是“空中楼阁”遥不可及。在落地实践的过程中进一步完善、夯实整体的体系,将概念转变为认知,认知转变为下意识。

    1.项目管理

    项目管理主要是实现项目时间、成本、质量的管理,在有限的时间保证项目高质量的交付控制项目成本实现项目质量好、服务好、成本低、满意度高的最优交付。

    1. 需求管理:项目实施推进过程中,客户需求出现变更/增加是常态,从项目管控来说需求变更是不可避免,而对于项目交付而言需要尽量收口项目过程中的变化,引导用户收口或者下期推进,避免整体项目需求跑偏。
    2. 进度管理:项目推进过程中各里程碑节点的管控,以节点倒逼工作进度是否存在跑偏的情况,实时跟进项目进度,进行项目推演,及时暴露问题,避免问题的发生,而不是事后补偿。
    3. 团队管理:需要明确失败的团队没有成功的个人,需要明晰团队成员的动向,团结一心推进项目的工作,在项目中增加团队成员的配合度及默契,出现问题快速解决而不是互相推诿。
    4. 资源管理:领导也是资源,或者说领导是更为有效的资源,销售同样被视为资源的一种,项目最终是以结果论成败,项目管理人员需要以项目风险为优先级,协调各类资源保障项目的平稳推进。

    2.规范落地

    建立项目管理规范后续要进行规范落地,而不是仅有规范而不切合实际,更多时候人更倾向于自己信服的事实。可能规范总结的经验教训但员工自身没有体会其中奥妙没有转化为自己的下意识。而由知识转变为技能,技能转变为下意识的过程因人而异,各有不同。需要在项目实战过程中不断淬炼,增加个人的认知及能力模型的丰富,如:

    规范说明

    枚举说明

    售前管控

    售前人员熟悉方案,沟通前内部演练模拟客户沟通情况,将方案演绎、产品演示划分分别进行,输出各产品的演示关键点、演示方案

    项目管控

    建立文档标准、里程碑标准、考核标准、汇报标准、沟通标准、结算标准

    实施体系

    项目实施过程中建立项目管控体系,项目日汇报、周总结,计划滚动更新;暴露问题解决问题,项目进展极端推演,控制项目需求范围,把控项目各工作进度节点

    测试体系

    内部产品、公司项目均需要遵循测试体系进行详尽测试,按照不同角色、人员从使用、操作、维护角度进行测试,从安全、性能、功能层面进行自动化脚本测试,生成测试报告,交付对应的负责人员

    运维体系

    项目交付后进行内部交接,遵循项目运维体系,明确项目内容、背景等信息,对项目中遗留问题解决,产品层面问题反馈至研发部门进行解决,客户反馈问题及时响应,提升客户的信任度

    3.模拟演练

    建立规范的同时是纸面的通知,而真实的“触感”需要来源于一线的直观认知。而在员工并不具备实际项目参与的能力是时,可通过公司内部项目实现实际项目过程的模拟演练。感受项目整体流程,项目各里程碑是什么情况,与理论的认知有什么不同。

    1. 项目生命周期:6个周期节点从项目售前、合同签订、项目立项、蓝图确认、项目上线、项目验收,各阶段的关注事宜及输出产物。
    2. 项目沟通技巧:与客户、与伙伴、与领导、与商务面向不同群体的沟通方式及技巧,如何推动才能让同事更好的助力项目的推进,不同层面的工作人员的关注点,言简意赅保证工作推进。
    3. 项目封闭标准:项目在实施阶段的目的是验收,将项目封闭实现项目闭环,项目封闭后标志当前项目节点闭环,进入运维工作及二期推动工作。
    4. 项目意义价值:项目不同层面对项目的意义价值有自己的理解,项目追踪需要作为项目案例资源,项目结束后需要明晰项目的价值及意义,客户的价值及公司的价值以及团队的价值。
    5. POC搭建演练:以公司自有业务为需求原型,模拟不同方案下项目的实施方式,一方面作为技术人员的培训,提升员工对项目的熟悉度,另一方面也可演练验证产品的完备性,提升产品的质量。

    利其器

    器是用具提高效率将复查的问题简单化,经过公司对主营的行业领域及主营的范畴细后,项目甄别当前能不能做,而器有效的提升如何将项目做好,如何提高项目交付率,如何将项目交付批量化的工具。通过产品+管理结合,提升盈利;从产品层面考量,面向用户级别产品,打造“无脑式”产品线;项目交付层面:统一、标准、体系、积累、夯实;

    1.成熟产品

    公司本身为产品型公司,想要项目批量化交付则需要产品不仅能为公司员工使用同时需要能够面向伙伴、面向用户都具备较好的交互操作能力。对于平台的安全、稳定、扩展、交互均需要具有极佳的用户体验,且除平台技术能力本身的保障外,对于依赖于产品的方案,使用手册、维护手册、项目典型方案、应用场景及对应场景的落地方案标准文档均需要不断的完善和充实。

    产品名称

    应用场景

    ESB企业服务总线

    做企业服务总线ESB来实现异构系统的对接;

    在数据整合/数据中心项目中,作为综合数据交换平台负责业务数据上传、汇聚,基础数据(主数据)的下发、分发;

    综合集成项目实现跨系统业务流程重组;平台协作及支撑

    MDM主数据管理平台

    主数据管理的用户是各业务系统、数据集成系统、应用集成系统、业务流程再造系统、BI智能决策分析系统。通过主数据管理,改变企业数据利用的现状,从而更好地为企业全方位的信息整合做好铺垫。

    BPM流程集成平台

    流程集成平台一般用于跨异构系统的流程集成,或者实现业务流程间相互调用;也可以做工作流系统来用,为特定业务系统做为工作流引擎提供用户与流程信息交互的接口,实现诸如完成、挂起、加签、回退、签收等改变引擎流转的操作

    IDM身份管理平台

    搭建统一用户中心实现用户统一、认证统一、权限统一、审计统一的四位一体的统一管控,建立统一管理体系

    DAP数据分析平台

    挖掘企业数据价值,将企业沉淀数据可视化、资产化,建立企业自身的数据管理体系及数据存储模型

    Portal门户集成平台

    搭建单一的信息门户、知识门户、数据门户、应用门户、移动门户、开发社区及综合办公门户,通常及到AEAI ESB应用集成平台来协作,用于提供数据服务或者进行相关的数据加工汇总;

    2.管理系统

    项目管理同样需要信息化进行支撑,建立项目管理制度的同时匹配对应的项目管理系统,支持项目管理标准的落地,结合系统有效的对项目风险进行评估及展现,避免人为性掩盖事实。结合系统的统计情况真实、有效、实际的展示项目当前的进展状态,风险评估状态,项目里程碑节点,项目收款节点,项目当前进展状态及后续推进计划。

    • 如典型项目管理系统功能:
    1. 项目信息管理:项目管理可以看到项目信息和项目计划,用于创建项目的基本信息,比如项目的成员,周期成本合同周期等等,项目计划为每个人分配的任务,具体每天都要干哪些功能,进行一个统一的管理;
    2. 项目过程管理:对于项目周计划、日计划的滚动管理,项目计划填写完毕后并且总监对计划也进行确认,确认后项目经理就可以进行项目周报的填写,项目开发人员完善项目日报;

    3.办公环境

    工欲善其事必先利其器,生活的周边环境也是一种器的体现,大到欢愉的公司氛围,办公环境,网络带宽,小到使用的电脑、手机甚至是居住环境均会影响个人的思绪和心情进而影响办公的效率及积极性。这些环境因素往往是对办公情绪影响最大的但却是最容易解决的,如:居住环境在外出出差实施项目租赁房屋时选择比较符合心意的房子,一方面提升居住的舒适感,另一方面舒适的环境也是缓解工作的疲劳和压力的有效途径。

    常见的办公环境因素如下:

    环境说明

    匹配优选

    公司氛围

    • 公司氛围一定程度决定公司发展,选择公司氛围融洽,专心做事、敢打敢拼、全攻全守、

    生活环境

    • 居住环境:项目租赁房屋可优选居住舒适度较好的房屋,提升居住舒适度,缓解异地负面情绪
    • 网络环境:优先选择可控带宽的运营商,提升办公速率

    办公工具

    • 电脑:在经济允许的情况下选择性价比高的办公电脑,便携、速度是重要考核指标

    交通环境

    • 可控范围内选择便捷的交通环境,如公司选择在是地铁周边,交通便捷的地方,方便员工的出行

    皆由人

    “尺有所短寸有所长”无论是对公司还是对于个人而言均是广泛涉猎的同时需要有自身立足的根本需要具备深度的挖掘,呈T字型发展趋势。对于公司而言在具备广泛产品系列的同时需要有自己的深耕行业及“明星”产品,一方面在这一领域各类瓶颈了如指掌,另一方面通过产品切身实际的解决用户问题。对于个人而言,人的精力是有限的需要做好个人的“精力”管理,有自己的专业领域在专业领域内不断深入,提升自身的竞争力。

    1.自我约束

    历览前贤国与家,成由勤俭败由奢,懒惰的所有人的天性,而自我约束才是能够提升自我,超越非凡的本质。不以恶小而为之不以善小而不为虽是表述是非之道,从自我约束的角度来看也是同样的道理不要因为事情繁琐就拖延,不要因为工作简单就推进。自我约束管理,越忙越要整理计划,梳理工作项目;越慢越要倒逼原因找出本质而不是得过且过,不求有功但求无过的蜗牛心态。

    1. 时间管理:利用闲散时间总结规划当天的工作项及对应工作的完成情况,哪些工作需要协调哪些资源,预计需要多少时间;
    2. 心态建立:责任心、主动性、积极性需要化被动为主动,积极迎接变化,面对问题解决问题,不断积累形成正向循环;
    3. 习惯培养:主动汇报、积极涉猎,带着好奇心工作,对工作涉猎的知识点及周边知识点进行学习,由点到线,由线到面搭建知识体系。

    2.洞察人性

    无论是售前、实施、运维最终都是与人在打交道,在不同阶段与不同的人员沟通交互,每个人都有着自身的性格标签,需要结合个人性格特点有分别的进行交流。

    1. 与客户:与客户不同层面的人沟通时需要注意,有人风风火火,有人沉稳冷静,有人内敛涵养,面对不同性格的人需要建立良好的沟通渠道,保证工作推进的顺利;
    2. 与伙伴:与伙伴交流的过程中注意不同人承担的角色,销售辅助推进配合,交付并肩推进,管理明晰工作;
    3. 与领导:与领导需要言简意赅,明晰工作进度,问题点及潜在的风险点,不要盲目乐观,报喜不报忧导致问题爆发;
    4. 与团队:与团队成员建立并肩作战的情谊,失败的团队没有成功的个人,明晰整体团队的目标齐头并进。

    3.一往无前

    置之死地而后生,只有摒弃后路方可一往无前,每个人都有无限的潜力等待被激发,在成年人的世界没有永远的敌人只有永远的利益,不同的人可以为共同的目标一起努力,而在团队管理的过程中需要激发团队成员的欲望,激励成员的斗志,保持清醒的战意。向目标齐头并进为实现一往无前。

    对于员工而言更多的不是惧怕吃苦受累,而是没有目标和方向。作为管理者需要帮助员工明确公司未来发展方向及个人发展规划,为员工制定目标,将员工目标、公司目标相互融合,使得个人收益与员工收益互相联系。激发员工由被动接收转变为主动进取,且匹配对应的考核奖励制度。实现员工有盼头、得甜头、足劲头进而形成正面良性的体系。

    ​​​​​​​4.厚积薄发

    仅仅依靠任务的关系去维系项目推进是不足以作为项目推进支撑的,项目实施的本质还是要落地项目中客户的需求,消除客户使用的痛点,提升客户的使用满意度。本质上还是需要以实力取得客户的信任,提高客户对公司、平台、团队的信任感,而对于个人而言需要不断累积自身的实力,没有量的积累很难实现质的飞跃。在此过程中个人需要不断提升自我认知,提升个人能力,将硬实力与软实力结合,保证项目交付。

    道法术器人思想虽然源自历史长河,但内涵精髓却经久不衰,其理论方法被不断延续用于现代企业的管理,道:是方向、理念、价值观;法:是组织架构、经营模式、管理体系、规章制度;术:是策略、技能;器:是工具(硬件、软件等),人:是基本元素、成败关键。五者结合,以道义来承载智术,“术”要符合“法”,“法”要基于“道”,道法术,通过最好的技术和工具,人是“道、发、术、器”的承载着,五者兼备做出最好的策略。

    展开全文
  • 归根结底,还是因为既有的Saas化产品如何应付传统企业项目交付的问题。本文从项目型产品和Saas化产品的关系,架构等方面尝试给出答案。 1. 前言 如果说为单个企业实施定制化项目是IT服务商的婴孩时期,通过产品积累...

    目前,在业务推进方面,产品和项目之争越来越多。归根结底,还是因为既有的Saas化产品如何应付传统企业项目交付的问题。本文从项目型产品和Saas化产品的关系,架构等方面尝试给出答案。

    1. 前言

    如果说为单个企业实施定制化项目是IT服务商的婴孩时期,通过产品积累以较低成本为多个企业实施定制化项目就是IT服务商的少年时期,通过产品SAAS化为所有企业提供满足个性化的服务就是IT服务商的青年时期,最终,通过产品的平台化为所有企业提供一体化的服务就是IT服务商的壮年时期。成长的过程是不可避免的,因为身边很多年少时期的客户,而花费很多精力去迎合他们,降低了自己的成长速度,并不是一个好的方法。
    较好的办法就是通过开动脑筋,保持现有成长速度不变的情况下,满足年少客户的需求。
    个人认为,SAAS化产品路线和项目化实施并不矛盾,是一个不断演进的过程,是同一事物的不同成长阶段。任何的SAAS化产品都是从项目型产品进化而来的。

    2. 项目型和SaaS化产品

    2.1 Saas化产品长什么样?

    指标SAAS化产品项目型产品
    云部署×
    多租户×
    可配置
    可扩展
    数据隔离×
    高可用
    热部署×
    独立升级×
    数据可控×
    自助注册×
    可监控×
    浅色风格
    新手导航
    客户互动×

    从各项指标对比来看,项目型产品和Saas化产品确实不同。并且,从商业模式上也是不同的。但是否意味着为了项目需求和Saas需求,要走两条不同路线呢?个人认为,从商业模式上确实要走两条路,但在技术实现上是相同的。

    2.2 技术实现的演进关系

    Saas软件并不是天生存在的,是一步步演进形成的。公认的,按照成熟度等级可分为:

    • level 1:定制开发

    最初级的Saas应用成熟度在应用架构上,跟传统的项目型软件应用架构几乎没有差别。在这种模式下,软件服务提供商为每个客户定制一套软件,并为其部署。每个客户使用一个独立的数据库实例和应用服务器实例。数据库中的数据结构和应用的代码可能都根据客户需求做过定制化修改。

    有些 SaaS 软件公司专门为单一企业提供软件服务,也就是一对一的软件交付模式,客户可以要求将软件安装到自己公司内部,也可托管到服务商那里。定制能力是衡量企业管理软件好坏的最重要指标之一, 这也是为什么有些软件开发商在 SaaS 早期坚持采用单重租赁的软件设计方案。

    • level 2: 可配置

    第二级成熟度模型相对于最初级的成熟度模型,增加了可配置性。希望通过不同的配置来满足不同客户的需求,而不需要为每个客户进行特定定制,以降低定制开发成本。这是目前成熟的传统软件可以达到的程度。

    但是,在第二季成熟度模型中,软件的部属架构并没有发生太大的变化,依然是为每个客户独立部属一个运行实例。只是每个运行实例运行的是同一份代码,通过配置的不同来满足不同客户的个性化需求。
    多重租赁架构下的自定制或自定义功能是 SaaS 软件的另一核心技术, 领先厂商的产品已经将自定制做到出神入化的地步。客户可以根据自己公司的业务流程, 自定义字段、 菜单、 报表、 公式、 权限、 视图、 工作流和审批流等, 做到 S a a S软件的量身定制,而且不需要编程
    知识。

    • level 3:高性能多租户架构

    多租户单实例的应用架构才是通常真正意义上的Saas应用架构。多租户单实例的应用架构可以有效的降低Saas应用的硬件及运行维护成本,最大化的发挥Saas应用的规模效应。不过,与传统的企业应用不同,Saas应用更具备互联网应用的许多特征。与传统单实例的企业应用相比,其数据量和并发量都会有明显的增加。因此,对于基于传统应用改造的多租户应用,还面临着大量的性能方面的挑战。

    • level 4: 可伸缩性的多租户架构

    在实现了多租户单实例的应用架构后,随着租户数量的逐渐增加,集中式部属会成为性能瓶颈。需要通过一定策略实现水平扩展。随着租户数量的进一步增大,该架构可以保证仅通过再多部属几个实例来满足更多租户的使用。

    因此,从项目型产品到Saas化产品是同一产品的不同成熟度等级。显而易见的是,如果实现了高成熟度的产品,则会兼容低成熟度的产品。即,实现了Saas化产品,完全可以满足项目实施对产品的要求。

    2.3 关于轻量化的理解

    **目前,有些工业化Saas软件给人的感觉就是轻量化——功能不多,只能满足基本的业务需求。那么,轻量化是否就是Saas软件的特征呢?没有那个Saas软件将轻量化作为它的特征。轻量化不是最终目的,满足需求才是最终目的。轻量化可以当作产品由小到大过程中的一个阶段或者是满足特定客户群体的一个产品版本。只要可配置性做好了,我们的产品完全可以做到按需变化,想轻量就轻量,想复杂就复杂。

    如果非要说,Saas软件必须是轻量化的,也可以这样理解:依托软件平台,软件本身可以实现轻量化,即部分功能通过平台实现,减少软件本身的开发和维护工作量。这就要求Saas软件是基于平台的软件。平台可以是工业互联网Paas平台等。

    2.4 如何兼顾项目实施和Saas化产品?

    1. 采用组件化技术,将系统划分成细粒度的模块,将不同模块甚至不同功能拆分成组件;
    2. 配置性,通过数据可配置、功能可配置、流程可配置及页面可配置,实现灵活配置;
    3. 统一管理,抽取公共业务组件,统一维护。如果组件无法同时满足,则拆分为更细粒度的组件。

    2.5 小结

    综上所述,采用Saas化架构,是历史前进的趋势。技术上讲,项目型产品是Saas化产品的最低成熟度等级,实现了高等级成熟度,则可以兼容低等级成熟度。商业模式上,项目型实施和Saas化推广是不同的商业模式。Saas化产品不等于轻量化。轻量化只是在产品无法满足各类用户个性化需求的情况下,一种折中的实现方式,是最终Saas化产品的一个阶段。可以采用不同的方式,同时兼顾目前项目实施的需求和未来Saas化需求。

    3. SaaS产品实现和微服务架构

    Saas化软件模式大约在2003年就出现了。而微服务架构大约在2014年出现。所以说,实现Saas化产品并不一定使用微服务架构。早期的salesForce,八百客,早期的阿里巴巴等的Saas化产品,肯定不是基于微服务的架构。但随着软件设计方法的不断发展,微服务架构也迎合了时代发展的要求。

    3.1 软件架构演进历史

    软件架构一般划分为应用架构和基础架构。其中应用架构是指构建业务系统本身需要关注的设计内容,而基础架构是指部署业务系统时需要考虑的设计内容。

    基础架构演进路线为:

    graph TD
      A[大型机] -->B[小型机]
      B[小型机] -->C[PC Server]
      C[PC Server] -->D[云计算]
    

    应用架构的演进路线为:

    graph TD
    A[面向过程] -->B[对象组件]
    B[对象组件] -->C[多层架构]
    C[多层架构] -->D[微服务架构]
    
    

    面对的业务场景为:

    graph TD
    A[科学计算] -->B[信息服务]
    B[信息服务] -->C[企业应用]
    C[企业应用] -->D[互联网+]
    
    

    3.2 为什么选择微服务架构?

    微服务的本质:一种更优的分工合作机制,加速分工,促进合作,帮我们成就更大的梦想!

    从产品来说,各类自研应用采用微服务架构是是为了能够借助平台的力量,借助云计算的力量,成为有生命力的产品。这就要求我们的架构也最好使用分布式架构,以充分利用云计算提供的各层能力。传统分层架构,如MVVM,SSH框架等,是单体架构,不具备搭建分布式系统的能力,如果要将单体架构改造成分布式架构,还需要借助其他框架,如EJB等,才能实现。将来和工业互联网平台的融合,也只能是集成式的浅融合。

    从工业互联网平台来说,工业互联网平台白皮书推荐的技术架构也是分布式微服务架构,也就是说是业内事实上的标准。这样,我们的平台可以将各类应用通用的权限、用户、消息等做成公共组件,统一维护,降低产品维护成本。另外,借助云计算能力,我们的平台可以集成大数据分析平台,智能决策平台,为各类应用提供高价值功能,使应用成为开放的,不断升级的产品。如果走不同的架构,那么需要两个团队来维护,还会有团队协同问题,难于管理。

    从团队和研发管理来说,不会像以往的传统软件研发那样,需要依靠那些既懂业务,又懂开发的人员负责从业务到开发一条龙。这大大降低了对人员的要求,每个人只需要是单个领域的专家,促进了人员的分工合作,具备了把产品做大的可能性。

    当然,微服务存在缺点,就是管理和维护复杂。当我们的产品规模达到一定程度后,微服务管理和维护会比较复杂,需要专业团队运维。

    4. 项目实施的顾虑——微服务架构和前后端分离

    项目实施的目标是为了盈利。不管是Saas化产品和项目型产品,都是为了满足客户的需求,业务上没有顾虑。而提到微服务架构,大家诟病的就是一个功能的开发需要前端工程师和后端工程师两人来完成,比起传统项目一个人开发来说,看似成本高了一倍。如何解决这个问题?

    第一种,接受微服务架构带来的好处,而不采用前后端分离的开发方式。目前,我查到的资料来看,微服务架构一般是前后端分离的,而我们采用的Springboot框架,也是前后端分离的。第一条路可能行不通。

    第二种,放弃微服务架构,采用传统的单体分层架构。那就成了做传统软件了,无法有效的利用现有的云计算、人工智能和平台的能力。为了节省几个人工费,让我们的产品倒退一大步,得不偿失。

    第三种,从根源入手,解决人力成本高的问题。我想到的,可以通过招聘或培养懂前后端的人做项目实施。这种有可能可以。通过软件本身的可配置性和可扩展性实现,这个可能是根本解决办法。如果产品配置性和扩展性做好了,是不是就意味着实施周期的降低,快速的交付。这样,就可以降低项目实施的费用了。

    参考

    1. 为什么要前后端分离?优缺点?
    2. 微服务到底改变了什么?
    3. 微服务,为什么可以加速分工,促进合作?
    4. 微服务系列
    5. 架构这么多,该选哪一个?
    6. 哪些业务适合微服务?
    7. 微服务为什么从前后端分离开始?
    8. 什么是微服务架构,详解?
    9. 微服务的优势和不足。
    10. 详细讲解SaaS项目解决方案
    11. SAAS产品设计原则及产品架构特点
    12. SAAS软件架构浅谈和设计
    13. Saas系统架构思考,多租户架构设计分析。
    14. Saas服务与传统ERP软件的区别?
    15. Saas是什么?和传统软件的区别?
    16. saas模式和传统软件模式区别?
    17. 互联网时代的软件革命-Saas架构设计-叶伟
    18. 微服务设计-sam newman
    19. Saas架构新特性-八百客,李智
    展开全文
  • 项目管理过程仅仅围绕产出的交付物(交付价值)服务,项目交付聚焦干满足需求、范围和质量期望,产生预期的可交付物,以推动想要的项目成果,如何在多重约束条件下管理好交付项目管理的重中之重。
  • 项目实施各阶段交付物清单

    千次阅读 2020-08-24 13:59:27
    交付物名称 启动 投标文件评审表 投标付款评审表 合同评审表 合同变更评审表 ★ ...
  • 大型软件的团队有效协作对项目成功起到越来越关键的作用,“敏捷之旅广州站——精进之旅”的活动,请来了业界敏捷项目管理的专家做了几场公益性的讲座,涉及敏捷开发应用和互联网项目管理的一些实用的方法,本文结合...
  • 前期的系列文章主要是从相对较细的层面去说明项目该如何实施,本篇就揭秘如何将项目交付效率至少提升30%,这个是“套路之王-招投标软件项目管理”系列文章的核心所在,方法论的本质在于提升项目的整体交付效率。...
  • 主数据项目交付最佳实践

    千次阅读 多人点赞 2019-04-24 10:14:01
    任何规模的企业都会存在各种各样的数据问题,主数据管理早在十几年前...而近两年主数据管理项目数量逐渐增加,一方面是随着大数据分析的风潮,数据的利用被高度重视起来,主数据管理作为大数据分析建设的首要前提,...
  • Sprint评审会—— 检视交付的产品增量。 按需调整产品待办事项列表。 通过Demo演示进行。 不需要汇报进度。 目的是获取反馈促进合作。 Sprint回顾会—— 识别改进项。 5种价值观 承诺 勇气 专注 开放 尊重 Scrum...
  • 关键词:交付和成果、全局观、持续、进化、变革。 目录 1、培养以交付和成果为导向的能力 2、保持“全局”观 3、持续改进、知识转移和变革管理 1、培养以交付和成果为导向的能力 这些 PMO 可培养项目管理...
  • 项目管理交付物Check List

    千次阅读 2019-07-15 20:08:10
    PMO的工作包括提供项目管理过程模板,并确定里程碑节点交付物Check List。传统瀑布式项目重文档,一个大型项目的SVN库,能有100G资料。因此文档资料不在多,而在于是否做了适应性的裁剪,取不同类型、级别项目必需...
  • 23.企业敏捷实战论坛-郭晗-让项目交付更“敏捷”——项目从成果交付转向效益交付 24.企业敏捷实战论坛-徐毅-华为云DevCloud的DevOps项目管理实践 25.企业敏捷实战论坛-胡杰-互联网+To-B+独角兽的项目管理成长路径 26...
  • 项目型制造也称按订单设计(ETO: Engineering to order),是制造业内复杂而独特的一种生产类型。由于每件(批)产品均需要根据具体客户合同的指定要求进行定制设计与制造工作,并在规定的期限内交付产品,对应的...
  • 1、项目交付流程 1.1 定义 项目交付流程规定了对项目实施的管理和作业控制要求,保证了工程项目实施按照规定的程序进行 1.2 重要性 1.2.1提高客户满意度 1.2.2 提高工程效率,节约成本 1.2.3 降低项目风险 ...
  • 项目组织结构的3种类型:职能项目型和矩阵
  • 交付团队管理 开始于:为什么需要构建软件? (Begin With: Why Do You Need To Build Software?) There are a many reasons why an organization needs to build and deliver software. Some examples might be: ...
  • 很多时候项目团队的资源是有限的,项目成员的素质、能力是不足的。...对于大型软件项目交付周期通常都会在半年以上,其中最辛苦的阶段是在上线前后的一两个月,上线前要完成功能开发、BUG修改,以及期初数
  • 对于交付团队来说,项目干好干坏都一样,老板很着急,但团队却没有足够的动力,照常上下班,如果逼紧了就离职。老板没办法就只能寄希望于项目经理,把整个项目的成败都维系在项目经理一个人身上。如果运气好,项目...
  • 以“规范敏捷交付”之名提出了一组最佳实践,帮助较大型软件开发团队取得与较小型团队在过去10年使用敏捷技术所取得的相同成就。这不是说现有的常用敏捷方法是杂乱无章的;事实上,大部分敏捷方法都需要比传统或临时...
  • 职能项目型、矩阵(强/平衡/弱) 第六版 1、职能组织结构 职能组织结构是目前最普遍的项目组织形式。它是一个标准的金字塔组织形式,见图 职能组织结构是一种常规的线型组织结构。采用这种...
  • 交付管理——怎样与客户打交道

    千次阅读 2020-08-30 08:17:25
    项目实施过程中,与客户打交道是需要技巧的,很多项目的失败不是因为项目团队的能力不行,而是项目经理在处理一些问题时犯了错误。 项目经理都容易犯哪些错误呢?我给大家列举一下: 一、 把问题推给售前顾问。 我...
  • 大型前端项目降低复杂度新思路

    万次阅读 2022-03-11 00:56:45
    当其他前端开发人员,参与到项目中时,面临这种复杂的项目也是头大,需要花费很大的成本梳理清楚业务与代码的关联。导致合作或者交接项目时,困难。 我们需要通过发现的这些问题,来寻找合适的解决方案。 1. 解决...
  • 面向交付的IT软件管理流程

    千次阅读 2021-12-02 14:01:49
    软件开发过程万物皆“可交付物”。“可交付”的标准衡量了公司的管理水平。
  • 大型复杂项目集管理之一

    千次阅读 2019-06-26 21:40:32
    项目集(Program),更广泛的被称为项目群,从字面意思看,包含多个项目,其管理复杂度也较普通单项目要大的多。目前市场上对项目集经理的需求越来越大,这是社会发展的必然,代表着各行各行从粗放式发展向集约式...
  • 伴随着私有云和混合云的蓬勃发展,各类应用和服务的私有化交付需求也持续增长。如何快速、高效地实现私有化交付,成为云厂商和SaaS厂商的一大难题。
  • 推动软件交付的24个关键能力

    千次阅读 2020-09-21 07:59:42
    这篇文章摘自Nicole Forsgren博士,Jez Humble和Gene Kim 的Accelereate摘录 。持续交付能力1.对所有生产工件使用版本控制版本控制是将所有生产工件...
  • 这里所指的研发特指可重复产生价值的产品/解决方案的研发,不包含面向客户交付项目型开发。 而产品/解决方案的研发,又可以分为两种情况,一种是完全没有业务基础的探索研发,一种是基于现有业务的增值研发。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 64,247
精华内容 25,698
关键字:

交付型项目