精华内容
下载资源
问答
  • 技术平台与业务平台的区别

    千次阅读 2011-04-02 15:34:00
     技术平台毕竟是“技术”平台,无论怎么完善和拓展也只是一个“技术”平台,应用软件的所有的业务逻辑都是技术平台无能为力的,也不是技术平台的职责所在。那么能不能有能够快速开发业务逻辑的软件工具呢,于是业务...

    技术平台有效降低了软件公司的开发成本,技术平台的优劣,直接体现了一个软件公司的核心竞争力的优劣。 没有自己技术平台或技术平台不够先进的软件公司就像没有核心竞争力的公司那样,最终被淘汰出局,因为客户永远追求物美价廉的产品。

      什么是业务平台?

      技术平台毕竟是技术平台,无论怎么完善和拓展也只是一个技术平台,应用软件的所有的业务逻辑都是技术平台无能为力的,也不是技术平台的职责所在。那么能不能有能够快速开发业务逻辑的软件工具呢,于是业务平台就应运而生了。业务平台是指快速生成业务逻辑组件,并组织、调度业务逻辑组件应用的软件工具和众多行业经验积累的、成熟的业务组件库。

      业务平台的优点:

      业务平台封装行业知识积累和行业解决方案,能够最大限度的实现知识的复用,业务平台可以自我完善、不断的丰富和发展,随着业务平台的多次客户化应用,平台有机会构筑出一些行业软件产品(或准产品)。

    展开全文
  • To B 就是 To business,面向企业或者特定用户群体的面商类产品;  To C 就是 To customer,产品面向消费者。... 技术业务 作为开发人员,如何面对“CRUD,天天写业务代码”这个事情,可以思考下面的几个问题: ...

     To B 就是 To business,面向企业或者特定用户群体的面商类产品;
     To C 就是 To customer,产品面向消费者。

    B端产品经理与C端产品经理- http://blog.csdn.net/qq_37697037/article/details/75235151

    > 技术和业务
    作为开发人员,如何面对“CRUD,天天写业务代码”这个事情,可以思考下面的几个问题:
     1.什么是技术和业务
     2.业务和技术的关系
     3.业务与为解决业务而衍生的业务
     4.对待业务的态度因你在团队的角色不同而不同
     5.如何从所谓的业务代码中学习深入

    技术与技术之间,有如下的两种关系:
     1.在解决同一个业务问题的前提下,更高效,更低成本的技术,会淘汰低效,高成本的技术。这是人类利益诉求所决定的。
     2.一般刚开始解决根本问题的技术(钻木取火)的效率是比较低的,只是把不可能变成了可能(从这一点上来说,技术才是业务的 促成者)。然后就会有提高效率的需求出现,要求改进这个技术。这个技术的低效率部分就会被其他人(或者技术发明人自己)加以改进,这部分就会形成新的技术。

      逐渐的不再满足于纯技术领域的探索,而是思考更多的问题:如何将技术转化为生产力;什么技术在什么样的场合能够发挥最大的价值;技术团队应该怎样构建;在一家公司里面,我怎样才能将自己的技术能力最大化的发挥出来?

    >  理解pm只是那个设计原型的家伙,那太小看PM了,需求更新:
     1、收集需求。多和业务待在一起,做一些业务需要做的事情,然后会发现...“那么问题来了”,这时候的问题就是业务需求了。
     2、分析需求。需求出来了,接下来就是如何解决。解决方案先从业务流程上分析,然后再依据业务流程给出产品建议和优化方案。
     3、设计需求。其实做好了第一第二点,设计出来的原型基本就满足了业务的需求。业务逻辑清楚了,其他的慢慢优化都行。* 最难的地方就是收集和分析需求,不是几天就能做好的。深入业务,深入业务,深入业务,重要的话说三遍。

    > 产品文档
      1、PRD是产品需求文档。
    产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。
      2、MRD是市场需求文档。
    文档在产品项目过程中属于“过程性”文档。
      3、BRD是商业需求文档。
    BRD是产品生命周期中最早的文档。

    > To B业务
    -- 关于B端产品的用户体验,你要知道这些- https://blog.csdn.net/g2V13ah/article/details/80972359
     B端产品(To Business)是企业在工作中使用的或出于商业需求而使用的系统、工具或平台,比较典型的如百度云各产品、百度统计、监控平台及企业内部的ERP系统等。B端产品的目标人群多为专业用户,需要具备一定专业知识才能使用。B端产品虽比较注重功能和效率,但用户体验较差的产品也会使用户丧失使用的热情,导致工作效率下降。

    To B运营那些事儿(一)到底什么是TO B呢?- https://baijiahao.baidu.com/s?id=1575858933266730&wfr=spider&for=pc
    To B业务数据分析系列二:To B 业务 VS To C 业务- http://www.sohu.com/a/165115595_187948
       B端产品经理与C端产品经理。

      To B更多讲求的是对企业价值的传递,而To C更多的是向终端消费者提供服务或者价值,这是最大的不同。所以两类产品的目标人群是完全不同的。这决定了我们的产品To B和To C应该怎么做的方法的不同。
      To B的产品,它不像To C的产品;可能我提供了某个工具或应用到终端用户身上,它就可以产生价值,产生消费。而To B的产品的整个决策链、价值传递非常的长。同时To B的产品不仅仅卖的是某款产品或者某个工具,它需要背后强大的服务支持,有可能产品只是整个服务环节中的一部分。
      作为To B的产品经理,不能仅仅是把时间和精力全部聚焦在产品本身的打磨上,还要有更宽的视野去纳入更多的因素。所以To B的产品不仅仅是在做产品,其实也是在做一款服务,这个是最大的一个基点。
      To B,人力成本上涨、生产效率下降、营销推广线上化、同业竞争白热化等诸多问题。
      用户想要什么?即,教育用户需要什么,对于To B的企业,常用“父爱经济”引导用户需求,与之对应的是“母爱经济”,大多用于To C的企业。我们通过专业会议、直播、白皮书、直播、知乎、微博、公众号等方式与用户进行沟通(教育)。
      To B企业要关注覆盖率、转化率、渗透率三个指标,要以最低成本、最快方式去覆盖,并密切关注转化率,关注业务环节中的每一步转化数据。

      TO C与TO B业务最大的区别就是前者决策是个体行为,后者决策是公司行为,而公司决策行为是非常复杂的,包含非常多的利益相关方。
      TO B服务(企业级应用服务)有以下两种形式,第一种是传统的企业级服务。用友、金蝶,都是属于传统的企业级服务。另一种是在这一两年,企业级的SaaS服务非常火;
      对于企业而言,数据分析的作用主要体现在三大领域:(1)是对业务的改进优化;(2)是帮助业务发现机会;(3)是创造新的商业价值。 数据分析最重要的是基于对业务的理解

    > To C 产品
      To C 产品是发现用户需求,定义用户价值,并准确的推动项目组达成这一目标;而 To B 产品是根据公司战略或工作需要,构建生态体系,或者推动将流程系统化,提高效率。

        To C 产品是你去挖掘用户需求,是创造,从无到有;To B 产品是公司战略或相关方给你提出要求,产品经理将这类「线下已有的需求」系统化,达到提高现有流程的效率的目的。
      To C 产品的用户直接是用户个人,所以更关注人性或者说用户体验,强调的是刚需,痛点,高频,体验,而 To B 产品存在的前提就是为了满足「组织完成业务信息化」的需要,所以 To B 的产品非常关注组织和业务,核心是功能服务、效率以及系统
     构建完整生态,或者提升效率,就是 To B 产品经理的价值所在。

      对于ToC用户产品,客户和用户是重合的,满足客户至上就等于用户第一,用户量上去后,付费客户的比例就有可能上升,之后流量也有变现的能力。
      对于ToB的业务产品,要考虑业务场景,比如微信公众平台,就是一个复杂的业务场景:企业或自媒体等入驻微信公众平台,进行内容和服务的发布,个人用户是微信公众平台的使用方,使用公众号发布的内容或服务。

     C类产品的流程一般是,发现用户需求,定义用户价值,并准确的推动整个项目组去达到这个目标,而且产品需哦那个0到1的周期很短,甚至一周时间就有可以完成一款产品的研发并推出市场。但是B类产品则不然,B类产品是根据公司战略发展或者工作需要,构建整个生态体系,或者说是为了推动流程的系统化,提高效率而为。

     to C 产品是站在用户的当下需求去设计的,而to B 的产品路径是针对用户长远性的需求去设计的。
     To C 产品针对普通用户,受感性思维影响大,而To B 产品大部分针对企业用户,决策者的理性思维以及产品使用流程要复杂许多,to B的产品路径比to C 要规范和专业的多。

      B端与C端产品相比,B端产品更多的是讲究产品对一个企业的价值传递,而C端产品更多的是向终端的消费者去提供一个服务或一个价值。对于B端产品经理而言,产品的打磨只是冰山一角,更重要的是做服务。
      面向企业端的产品:从最早的百度搜索推广,到后来的凤巢系统,以及围绕整个商业体系的这些产品背后的运营体系搭建,面向销售的、面向客服的,以及面对终端消费者(也就是企业用户)怎么把他们对产品的诉求反馈给我们,都做了大量的工作。后来我加入“去哪儿网”,也围绕终端消费者,包括供应链以及第三方支付,都是面向这种企业级的产品。

     To C的产品更多是让用户体验好,让用户用的爽,To B的产品其实是在解决企业的内部流转企业的内部效率的问题。

    -- 产品:
    设计中间产出物(流程图、线框图).
    1.业务目标:产品的商业目标是什么,UV/PV/留存要达到多少,满意度要达到多少,等;
    2.用户目标:面向的用户,用户的痛点,用户使用的动机,用户深层的欲望和需求,用户使用产品的场景,等;
    3.时间节点:什么时候完成初稿,什么时候内部评审,什么时候项目方评审,什么时候交付,什么时候跟进,等。

    展开全文
  • 应用架构、业务架构、技术架构和业务流程图详解

    万次阅读 多人点赞 2018-10-09 18:48:32
    应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次: 企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业战略发展方向...

    应用架构

    应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次:

    企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业战略发展方向和业务模式,向下规划和指导企业各个IT系统的定位和功能。在企业架构中,应用架构是最重要和工作量最大的部分,他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。

    单个系统的应用架构:在开发或设计单一IT系统时,设计系统的主要模块和功能点,系统技术实现是从前端展示到业务处理逻辑,到后台数据是如何架构的。这方面的工作一般属于项目组,而不是企业架构的范畴,不过各个系统的架构设计需要遵循企业总体应用架构原则。

    应用架构主要以架构图的方式描述系统的组成和框架,一般从系统功能和系统技术层次两个架构视角进行设计:

    1. 系统功能视角的应用架构图

    ​​​​​

    2. 系统技术层次视角的应用架构图 

    业务架构

    ----摘自《自主变革的基石 制造企业管理技术及SOA实践》

        主要考虑部署,例如你不同的应用如何分别部署,如何支持灵活扩展、大并发量、安全性等,需要画出物理网络部署图。按照应用进行划分的话,还需要考虑是否支持分布式SOA

        每一个典型业务,都可以把它想象为一台运行中的机器,而其中的每个业务组件便是构成这台机器的功能模块。之所以要利用组件来进行业务架构的搭建,正是因为组件具有上述特性,这些特性能确保搭建的典型业务架构图,既完整有效、又无功能冗余,而且有利于今后展开系统架构的组件分析和设计。这样的架构能告诉我们:是由哪些内容相对独立的业务模块构成了这项典型业务。如对其中的每一个业务组件之间的作业关联关系、相互沟通的方式进行研究,就能掌握整个业务架构的协同作业水平;如果对每一个业务组件都采用前述外特性定义的方法加以描述,就能掌握这些组件当前能完成哪些独立的业务内容以及能达成哪些业务目标。本节重点介绍利用业务架构图分析典型业务的分析方法,分析的对象就是业务架构在功能构成方面的完整性和合理性。

       首先,需要表达出当前的典型业务是由哪些业务组件构成的。基本可以断言,大家在开始按上述三个层次描述某个典型业务的构成时,一定会对应该如何定义管理层和决策层的业务组件感到困惑,这是非常自然的反应。因为,至今以来,大家总是在研究执行层的作业方式,不会去、也不敢去研究管理层和决策层的作业能力。但在不远的将来,我们的企业注定要进入业务协同和系统整合的时代,所以,大家现在应该开始学习如何定义和建立管理层和决策层业务组件的具体方法了。

    典型的整车生产企业产品开发业务的业务架构示意图

     

       如典型的整车生产企业产品开发业务的业务架构示意图所示:当我们对于某项典型业务的业务组件的构成进行初步的归纳后,能够得到该项业务的一个整体的框架结构,我们可以称之为“业务架构图”,以及在这个框架内,企业中三个层级的员工在该项业务上分别从事着哪些作业内容。分析执行层的业务作业方式和作业规律,你觉得很正常,但如果让你去分析作为你上司的管理层、甚至决策层的作业方式和作业规律时,你也许会感到有所不安。这种心理反应,实际上正好反映出目前很多企业中的一种能力倒置现象的产生原因。很多人都了解这样的事实,那就是,企业中的很多升职后的中高层领导,在就位后的很长时间内,不能进入应有的管理角色中,这绝对不只是个人能力的差异问题,而主要是因为我们的中高层领导总是习惯地认为:研究执行层的作业方式和规律才是他们的主要职责,而没有注意到自己的作业内容和作业方式在整个作业链条中的重要作用,其结果,自然是管理层和决策层领导们的业绩,只好取决于执行层作业人员的努力程度,这种习惯也导致我们的中高层领导们不会去研究影响自己判断能力和决策能力的技术瓶颈是什么。而很多新出现的现代管理模式,实际上就是为了解决中高层领导们的作业能力问题,或是为了解决三个业务层级之间的信息沟通能力的问题,这也就是为什么业务架构分析人员还必须分析战略层和管理层作业形态的原因。下面将分别说明上述三个不同层次作业组件的特点:

    (1)战略层业务组件

       战略层业务组件自然是用于定义和规范战略层决策人员的业务行为的。那么,哪些人员可以归类于战略决策层之中呢?一般说来,在典型的制造企业中,部长以上的领导应被理解为企业战略决策人员,因为,他们通常已脱离具体的、单一的业务管理,他们通常会被要求在某个综合业务的专业领域提出战略性规划,并按规划进行部署和指挥。但在很多企业中,还设置有经营管理课或战略策划部等机构,其中的一些专门从事为决策层领导进行战略数据分析和提出具体方案的高级管理人员,也应该被认为是战略层业务组件中的业务人员。

     战略层业务组件通常应按如下的作业基准进行设计:

    - 对于特定的典型业务,是否具备有效的战略规划编制和调控能力。

    这里提到的调控能力,是指当企业经营发生重大的内部或外部环境变化时,企业内部是否具备能对既定规划及经营目标做出及时分析和调整的响应机制和具体的作业标准。

    - 制定、发布以及变更经营战略规划的流程和作业规则是否明确。

    这只是一个规范作业流程的问题,在很多企业内部,通常具有手工审批,进行传递的流程,有时存在指令重复、重要度不明、不易追溯等管理问题。

    - 是否能及时、准确地获取相关战略指标的动态统计数据(用于决策)。

    这是直接影响战略层决策能力的重要条件。这里提到的及时和准确,往往可以作为衡量一个企业管理技术水平的标尺。

    - 战略指标数据是否能明确指向具体部门或具体业务组件(用于能力评价)。

    这同样是一项检验企业管理技术水准的重要课题,在此后的第七和第八章中,将对此课题展开详细的讨论。

    - 是否具有根据设置的危机监控标准,及时触发决策机制的系统反应能力(确保决策的及时性)。

    这是一个技术含量最高的课题,任何企业都很难达到这样的水准,只有在管理方法和技术手段方面同时达到很高水准的企业,才能有效展开这一类课题的研究活动。但这一课题显然是所有企业都需要瞄准的目标。

       当然,上述的作业基准未必一定完整和精准,只是按照对一般指挥机构职能的理解来考虑的。例如,企业每年需要设置生产成本控制的战略目标,如经营层的业务人员(实际上是一些领导们)能按图2的成本控制图谱获取所有部门和所有组件的目标达成数据的话,自然就能及时做出相应的评价、指导和决策调整。关于如何实时采集和展现业务状态数据、以及如何设计战略决策信息舱的详细情况,请参见第八章《商业智能和可视化管理》的内容。

    单车成本构成示意图

    (2)管理层业务组件

    由于管理层处于决策层和执行层之间,从信息沟通的角度来说,具有上情下达、下情上报的职责,一般情况下,上情下达比较容易实现,但下情上达则相对困难,存在诸多的管理和技术问题。管理层业务组件应以提升管理层控制业务过程的能力、以及提高管理层和执行层及战略层之间的信息沟通能力为主线进行设计。管理层作业的重点应按如下思路设置:

    - 对于某个典型业务的企业战略,是否具有明确的计划编制、监督实施等作业标准。

    如部门接受了达成企业某个战略,或实现某个企业年度指标的任务时,应该按照既定的作业标准,进行自身业务能力的分析、指标的分解、作业分工以及过程控制方法的确定等作业,以确保该项战略目标或年度绩效指标能按计划展开,并确保其实施过程能得到有效的监控。

    - 相关的典型业务的过程状态是否能有效掌控。

    这一条可以认为是管理层的主要业务方向之一,如一个中层管理人员对如何监控业务过程缺乏最起码的研究,那就基本可以断言,他肯定是一个缺乏最起码业务过程控制能力的管理人员。

    - 对于某些典型业务或某些关键的作业节点,能否实时、有效地评价员工的执行力。

    管理人员之所以需要掌握员工或团队的执行力,不仅仅有利于达成业务目标的正确预测,更重要的是将有利于管理人员发现团队中意愿不足和能力不足的员工,以便及时加以指导。另外,如能实现员工执行力的数据统计,还将有利于事后的正确评价。

    - 对于部门重点业务以及管理改进目标,能否掌握员工知识贡献度的不同。

    能设置符合这一方向的业务组件,其先决条件是必须已经实现了基本有效的知识管理,否则,这样的要求就偏高了一点。作为一个以创新为主的业务部门的管理人员,必须研究如何做才能达成这样的目的,关于这一点,将在第八章中进行详细的介绍。

    - 对于所承担的企业战略指标部分,是否具有实时采集、分析和上报的机制。

    如果管理层职员基本具备这样的意识,就基本上能够得到他们上司的认可,至少能够保持住当前的官帽。如果能够建立这样的机制,具备这样的能力,那就完全不用担心自己的升迁问题了,因为,能够实现及时、准确地“下情上报”的管理人员,已经充分具备了能随时取悦上司的资本。

       总之,从信息沟通的功能来说,设置中层管理业务组件的目的,一是能够掌握企业战略动态,及时编制、和实施部门业务计划;二是要能够实时掌握执行层业务的作业状态(进度、执行力、作业量、知识贡献等)、并能够及时处理、分析执行层的业务统计数据,以便及时对员工进行指导、督促和评价,以及顺利履行按规定向上通报的职责。根据以上思路设置管理层业务组件,从表面来看,似乎主要关注的是中层管理者们处理信息的能力,但大家必须清醒地认识到这样一个事实,那就是:没有充分有效的反映执行层作业状态的信息,管理层就不可能进行有效的控制、指导和评价,作为管理者的能力,也就不可能得到充分地展现。

    (3)执行层业务组件

        执行层业务组件的设计重点,当然首先要关注组件的设置是否有利于实现所属典型业务的目标,其次是希望它能以最少的资源投入来确保业务目标的实现。如果企业单一系统的建设卓有成效,则基本可以认为该企业的执行层业务组件应该是处于一种良好的状态。但在当前加强目标管理、绩效管理的企业,所有执行层组件应该还要考虑是否需要设置向管理层提供信息服务的功能。归纳起来,应考虑以下要素:

    - 是否能确保实现典型业务的业务目标。

    要回答上述问题,必须对典型业务有完整的认识,所以,必须尽量把有利于实现业务目标的业务活动、操作方法以及技术手段都纳入研讨的范围。也许,在考虑如何才能实现典型业务的业务目标时,暂时可以不要过多地去推敲效率的好坏。

    - 实现业务目标的效率如何。

    如果企业对于作业效率有很高的要求,则在设计业务组件时,或许要更多地考虑组件的合并、组件业务流程的连通方式的改进、执行力的监控等有利于提高作业效率的问题。

    - 业务过程失控的危险是否已完全消除。

    企业中的有些业务,如必须需要通过设置控制基准值,并通过逻辑条件或数学运算规则来发现业务过程失控、指标达成失败等现象时、则需要考虑追加自动监控组件,如果没有自动监控的条件,也应明确人工监控的具体方法。

    - 业务状态数据是否可实时采集、统计和发布。

    对于必须控制进程的业务,则通常需要考虑追加进度监控组件,至少应明确关键节点的进度监控方法。

    - 业务组件之间的协同是否顺畅。

     这一条要求是指业务组件之间的流程连通方式、信息共享方式是否符合业务目标的要求,如果不能达到要求,则要追加某种提升协同能力的辅助组件。

        总之,执行层业务组件是实现典型业务目标的骨干部分,而管理层业务组件的合理设置可确保执行层业务过程得到实时的控制,而战略层业务组件则应起到目标调整、资源调整的决策作用。

    在进行上述三个层面的业务组件设置时,如果已经掌握了相对先进的、行业内的最佳实践模式,并对该典型业务进行过组件构成合理性的分析,或者根据日常的业务不良投诉记录,已经掌握了某些组件的问题,那么,在分析和描述该项典型业务时,可明确地表达出该典型业务在构成上的缺失或冗余项,以及当前这些业务组件的业务能力的总体状态。在分析中,最容易发现的是业务组件的缺失项,即一些目前我们还没有开展的业务,而这些业务的开展恰恰有利于企业最新战略的实现。但发现所谓冗余项,则通常是一个不容易完成的任务,因为,大多数员工不会斗胆挑战现有业务存在的合理性,因为大家已经习惯于把时间打发在这些日常业务上了。但作为业务分析人员,建议大家必须时常保持高度的怀疑态度,因为任何业务组件的存在都要消耗资源,为此,任何业务组件都存在压缩、分解乃至取消的可能,如果能通过业务的重组或优化,凸现出某些业务的冗余功能,并最终取消之。这才是分析人员应该加以重点研讨的方向,才是大家更值得骄傲的地方。真所谓“居人之所恶,故几于道”,我们业务分析人员,没有必要对自己始终保持对现实的批判态度而心怀歉疚,反倒应该随时提醒自己,要始终保持对现有业务合理性的怀疑态度,在这方面,做“恶人”比做“好人”,更能体现业务分析人员的职业价值。对于上述的分析结果,自然应在业务架构图中表达出来,具体的表达方式可参见图2-4。在图中,采用的是用色彩区分来表达组件业务能力状态的方法,虽然这种表达方法比较直观,但肯定不是唯一的表达方法,在此建议大家不必拘泥于形式,只要能容易理解即可。

    和最佳实践模式对标或完成调查和分析后的业务热点分析图

        不过,有一点,希望大家注意,上述的架构图是一张企业级的典型业务架构概略图,所以,对于每一个典型业务,都包含了所有相关部门的业务组件。但实际上,我们的很多具体分析,往往只须针对一个部门的业务展开即可。在这种情况下,也可以按照上述的方法编制部门级业务架构图,只是这种架构图在大多数情况下,不需要考虑战略层的组件设计,所以,只采用两层的架构图也是没有问题的。另外,根据需要,对于部门级的业务,还可以编制一种横向按时间顺序展开的架构图,但这种架构图不利于展开全局性的分析,所以,通常不采用,这里就不作详细说明了。

       根据以上两个图例,读者是否不再介意使用‘业务架构’这样的表达方法了呢?为此可以认为,即使是相对抽象的业务也是可以用相对直观的架构形式来表达的。这样的表达方式不仅仅只是为了直观地进行业务的归纳,更重要的是为了直观地表达出现有业务架构的缺陷。图3中,红色的组件表示缺失、冗余或存在严重缺陷的组件,此类组件我们通常称之为“热点组件”(这样的架构图也可称之为热点组件示意图)。红色组件通常是表示尚未实施改进对策的热点组件。粉红色的组件则表示该组件虽有问题,但目前正在对策中。黄色的组件表示存在当前可以默许的缺陷,但随着企业的发展也许需要加以关注的组件,通常其评价的平均得分低于3分。绿色则表明该模块当前运行正常,暂时不需要特别关注的业务。当面对如此直观明了的业务架构图。没有理由不对缺失的和有缺陷的模块部分进行进一步的问题定位分析、并制定改进方案。但怎样才能知道A组件是缺失,应该考虑增设,或B组件有缺陷,需要改进呢?这便是后面的章节中将要重点介绍的核心内容。

    下面这张就是画的比较细的业务架构图

    ​​​​​

    技术架构

    从技术层面描述,主要是分层模型,例如持久层、数据层、逻辑层、应用层、表现层等,然后每层使用什么技术框架,例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等,分别说明,要求这些技术能够将整个系统的主要实现概括。

    技术框架(technological Framework)是整个或部分技术系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一种定义认为,技术框架是可被技术开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

    实例图:

    业务流程

    业务流程,是为达到特定的价值目标而由不同的人分别共同完成的一系列活动。活动之间不仅有严格的先后顺序限定,而且活动的内容、方式、责任等也都必须有明确的安排和界定,以使不同活动在不同岗位角色之间进行转手交接成为可能。活动与活动之间在时间和空间上的转移可以有较大的跨度。而狭义的业务流程,则认为它仅仅是与客户价值的满足相联系的一系列活动。

    流程图

    竖式业务流程图就是要业务流从上到下,看起来一目了然。

    竖式业务流程图可以划制成矩阵式流程图,就可以同时说明业务、工作的流程,还可以在流程中明确各自的分工和职责,关键的控制点等。业务流程要重点注意可靠性、资源利用率、反应性、灵活性、较低的管理成本五方面问题。

    综述

    良好的业务流程设计是保证企业灵活运行的关键。清晰的定义业务流程之间的接口,可以降低业务之间的耦合度,使得对局部业务流程的改变不会对全局的流程产生灾难性的后果。

    对整个企业的业务流程进行建模是一个相当复杂而有挑战性的工作,但是并不代表没有方法可循。一般来说,建模需要处理好以下几个方面:

    建立流程

    主要的业务流程是由直接存在于企业的价值链条上的一系列活动及其之间的关系构成的。一般来说包含了采购、生产、销售等活动。 辅助的业务流程是由为主要业务流程提供服务的一系列活动及其之间的关系构成的。一般来说包含了管理、后勤保障、财务等等活动。

    层次关系

    业务流程之间的层次关系反应业务建模由总体到部分、由宏观到微观的逻辑关系。这样一个层次关系也符合人类的思维习惯,有利于企业业务模型的建立。一般来说,我们可以先建立主要业务流程的总体运行过程,然后对其中的每项活动进行细化,建立相对独立的子业务流程以及为其服务的辅助业务流程

    业务流程之间的层次关系一定程度上也反映了企业部门之间的层次关系。为使得所建立的业务流程能够更顺畅的运行,业务流程的改进与企业组织结构的优化是一个相互制约、相互促进的过程。

    合作关系

    企业不同的业务流程之间以及构成总体的业务流程的各个子流程之间往往存在着形式多样的合作关系。一个业务流程可以为其它的一个或多个并行的业务流程服务,也可能以其它的业务流程的执行为前提。可能某个业务流程是必须经过的,也可能在特定条件下是不必经过的。在组织结构上,同级的多个部门往往会构成业务流程上的合作关系。

    进QQ群(779809018)免费领取学习资源,欢迎大家,加入我的微信公众号:代码帮 ,免费分享资源。

    本公众号将秉持活到老学到老学习无休止的交流分享开源精神,汇聚于互联网和个人学习工作的精华干货知识,一切来于互联网,反馈回互联网。
    目前研究领域:大数据、机器学习、深度学习、人工智能、数据挖掘、数据分析。 语言涉及:Java、Scala、Python、Shell、Linux等 。同时还涉及平常所使用的手机、电脑和互联网上的使用技巧、问题和实用软件。 只要你一直关注和呆在群里,每天必须有收获,讨论和答疑QQ群:大数据和人工智能总群(779809018)微信公众号(代码帮)每天分享最新IT、大数据和人工智能新技术。

    展开全文
  • 很多开发者为天天写业务代码无暇提升技术而焦虑、苦恼,比如: 又如: 又如: 再如: 那么,作为开发者,到底该怎么面对“写业务代码”这件事呢? 今天我们就从以下几个方面聊聊这个话题: 什么是...

    很多开发者为天天写业务代码无暇提升技术而焦虑、苦恼,比如:

    又如:

    又如:

    再如:

    那么,作为开发者,到底该怎么面对“写业务代码”这件事呢?

    今天我们就从以下几个方面聊聊这个话题:

    1. 什么是业务
    2. 业务和技术的关系
    3. 业务和因解决业务而衍生的业务
    4. 对业务的态度因你在团队中的角色而不同
    5. 如何从写业务代码中跳出来,做你所谓的有技术含量的工作

    我们先来看看,什么是业务。

    1. 什么是业务

    简单讲,“业务”就是需要处理的各种事务,但通常偏向指客户实际作业涉及的事务,“业务”最终的目的是完成工作所做的所有事务。

    比如取款就是一种业务,ATM 机内运转的软件,要解决的业务就是取款。

    比如挂号、预约、查检查报告,都是业务,趣医网的 App 就可以用来解决这些业务。

    比如买火车票也是业务,12306 这个网站就是为解决买车票的业务服务的。

    2. 业务和技术的关系

    软件是用来解决现实世界中的业务给人们的工作带来便利的。

    比如到火车站买票,要坐车、提前、排队,又麻烦又消耗时间又浪费精力,而 12306 网站和 App ,通过把买火车票这种现实业务虚拟化,为人们省去了奔波、排队、耗时的麻烦。

    比如大家都想到好医院看病,人人都想挂专家号,很多人为了挂到某个医生的号,通宵排队,非常辛苦,而现在的各种网上挂号网站、微信公众号、 App ,通过软件技术手段,把专家大夫这种资源虚拟化,让大家随时随地能挂号,还不用到医院、不用通宵憋尿排队、不用担心被医托和黄牛忽悠,给患者带来了极大便利。

    软件是现实业务虚拟化的载体,技术最终是为了解决业务问题的。从这个角度讲,所有的开发者,其工作最终都是指向某个特定业务问题的。没有业务,技术的存在就没有意义。技术不能解决实际问题,不能给人们带来便利,就没有价值。

    但从另一方面来讲,技术是现实业务虚拟化的必要条件,没有技术,现实中的业务就无法被虚拟化。而且,同一种技术又可以实现多种业务的虚拟化。所以,很多初阶的开发者才会有种“错觉”:技术牛 X ,因为没有技术就无法实现业务,业务很 Low ,技术牛 X 了,随随便便就能搞定。

    实际上,这些感觉虽然在一定阶段有其道理,但并不是真理哦。

    关于业务和技术的关系,这里下个结论:

    1. 技术是为了解决业务问题的,只有在实现业务、给人们带来便利的前提下,技术的存在才有意义,所以,多数时候,是业务决定技术、业务统领技术。
    2. 没有技术,业务就无法被虚拟化,生产效率就很难有效提升
    3. 业务和技术具有相互促进、相互依存的关系。

    我们回到开发者身上来看,写业务代码多一些,还是所谓的技术代码多一些,没有高下之分,只有个人取向和组织分工的不同。

    3. 业务和因解决业务而衍生的业务

    很多开发者会用割裂的眼光来看待业务和技术,比如把增删改查(CRUD)看作是无意义的业务代码,把实现 libuv 或 Redis 这样的框架看作是有技术含量的事情。

    比如京东上《程序员的成长课》这本书的详情页,是这样的:

    它对应的架构是这样的:

    很多开发者会觉得,写那些用来展示《程序员的成长课》的图书封面、优惠券、促销等相关信息的代码是没什么技术含量的,因为那些是业务代码。

    他们会觉得,写商品详情页架构中的 Redis、JMQ 或 JIMDB 是有技术含量的,是真正的技术代码。

    但实际上,所谓的业务代码和技术代码,它们的区别,仅仅是和业务的距离远近不同而已:业务代码离业务更近,技术代码离业务稍远。它们最终都是指向业务实现的。

    而且,你换一种视角来看业务,就会发现,其实每一层代码,都服务于它的上一层代码,上一层代码,就是它的业务

    比如详情页架构的第2层“对外提供API”中的商品介绍个 API ,它的服务对象,就是前端页面,要解决的业务,就是“响应前端页面的查询,提供商品介绍”

    而第2层底部的前端数据集群(JIMDB),它的服务对象,就是商品介绍,要解决的业务,就是“存储商品或代理商品介绍信息”。

    简单说,每一层技术实现,都服务于上一层,都以上一层的需求为业务。从这个角度讲,现实中的业务在被虚拟化的过程中,会在技术实现层面引发分层,产生中间性、对用户不可见的新业务。

    从这个广义业务的视角来看,每一层代码,都是业务代码!

    但是为什么很多开发者又觉得所做的技术实现越接近现实业务越没技术含量呢?

    这是因为,你越接近用户业务:

    1. 细节越多,繁琐度越高,越不容易做好,越容易因为一点小瑕疵而被否定,让人觉得自己的劳动没价值
    2. 现实性越强,变化几率越高,越容易来回修改代码,越让人觉得自己的掌控感低下
    3. 实现的代码可迁移性越差,劳动成果被复用的概率越低

    而当你远离用户业务时:

    1. 你用到的技术,多数都是被高度抽象过的、用来解决从用户业务衍生出的技术性业务的,它们比具体的用户业务稳定,它们的适用面更广,也更容易被迁移到其它的业务领域
    2. 你的劳动成果因为具有抽象属性,被复用的概率会更高,你会更愿意打磨它,会更有成就感
    3. 你受到压力,经过距离用户近的几层同事的传递,得到了衰减,没那么大
    4. 你打交道的对象,多数时候是内部同事、是技术人群,更容易达成一致

    4. 对业务的态度因你在团队中的角色而不同

    你对业务的态度,会因你在团队中承担的角色不同而不同。这是由开发团队的组织结构和职责分工导致的。

    下面是我绘制的“团队结构、能力与职责”图:

    在一个开发团队中,架构师这个角色,会负责业务拆分和软件架构的工作,并且领导团队来实现满足业务的软件。

    注1 :有的研发团队里有业务架构师和软件架构师两种角色,业务拆分由业务架构师或业务分析师完成。

    注2 :软件架构师和业务架构师这两个角色也可能由没有架构师头衔的研发经理兼任。

    架构师一定是要以业务为导向的,要搞懂业务的。所以,在架构师这个阶段,在团队管理者这个阶段,业务的重要性,往往是高于技术的,在他们的眼中,业务统领技术,技术是用来实现业务的。

    当团队完成业务架构和软件架构之后,就会选择不同的开发者来负责不同功能模块的实现。

    负责不同功能模块实现的开发者,必须能够理解业务,并且要熟悉某个技术栈,能够进行模块设计和任务拆分,我称这样的开发者为“熟练开发者”。

    熟练开发者会承接由架构师分派的子业务,负责模块设计和拆分,把拆分后的小任务,交给普通程序员来完成。

    当你是一个熟练开发者时,业务和技术几乎同等重要,因为:

    • 你不理解业务,就很难将子业务模块映射到软件实现上,也很难做进一步的业务拆分。
    • 你不具备完整的技术栈和相应的知识体系,就很难找到合适的技术来实现业务,也很难做软件模块的拆分。

    熟练开发者完成了子业务和软件模块的拆分,会形成一系列的叶子型任务,并把它们分派给具备特定专项技术能力的普通程序员。

    普通程序员要做的事情比较简单,就是接受别人分派的任务,实现特定的业务细节。

    注意当你是一个普通程序员的时候,团队要求你具备一定的专项技术能力,能够完成任务即可,你的角色,就拿把螺丝刀拧螺丝,拧好螺丝就 Ok 。

    这个时候,你内心是痛苦的,对不停地写业务代码是拒绝的,因为你要再找工作时,别的组织看重你的专项技术能力甚于业务能力(他们有人做业务拆分,你过去了能拧螺丝即可),而你在现有组织中,却因为深陷业务代码的编写而无法持续淬炼你的技能能力。

    所以普通程序员最纠结写业务代码这件事!

    那么,该如何才能解脱呢?

    5. 如何从写业务代码中跳出来

    孔子说过一段话:“弟子入则孝,出则悌,谨而信,泛爱众而亲仁,行有余力,则以学文。”

    翻译成现代文,是这个意思:“年轻人,在家就要孝顺父母,出门在外就要尊敬兄长,行为谨慎,言语有信,博爱众人,亲近仁者。这样都做到之后还有余力的话,就可以去学习从政,做更大的事业。”

    这段话呢,给普通程序员指明了方向:轻松搞定你的业务代码,还有余力,就可以做更重要的事情

    也就是说,当下你能力不够,组织上不可能给你更复杂的模块让你负责(再说团队里已经有更厉害的人在做那些事了),你得先轻松且漂亮地搞定手上的任务再说。

    很多普通程序员天天抱怨老写业务代码没长进,可手上的任务却总是敷衍了事,完成得凑凑合合,那是很难摆重复简单业务任务的泥沼的。

    那怎样才能做到轻松、漂亮地搞定任务呢? 4 点:

    1. 在深度和广度两个方面提升技术能力(如果当下任务繁重,就利用业余时间练习)
    2. 把自己的做的事情放在全局理解,提升业务理解能力
    3. 培养好的工作习惯,比如计划、回顾等
    4. 做好汇报和展示,让领导知道你的能力

    当你慢慢做了上面 4 点之后,每次拿到任务,都能轻松又漂亮地搞定,超出领导的预期,还有未发挥完的火力,那团队就一定会给你复杂一点的任务,如果你还能轻松、漂亮地搞定并且还有余力,那团队就会给你复杂度再高一些的任务……

    往复循环,你就可以跳出最简单的业务代码编写,做越来越重要的事情,人也变得越来越重要。

    6. 小结

    前面我们分 5 个部分阐述了业务和技术的关系,总结一下,关键的其实有 3 点:

    1. 技术是手段,业务是目的;软件开发工作是以业务为导向的,但是没有技术又无法实现业务。
    2. 业务和技术的关系,随着开发者角色的变化而变化。
      • 刚入行时作为普通程序员,技术是基础,有技术才能实现业务,公司在招人时也以技术水平为门槛,从这点出发,一定要在短期内迅速提升技术。
      • 工作了 3 、 5 年,成了熟练开发者,可以独自负责一个业务模块时,需要更好地理解业务,这样才能更好的从技术上实现,此时业务和技术并重。
      • 从熟练开发者往前发展,有两条路,技术专家和架构师,如果你选择架构师的路线,则应该调整思维,以业务为导向,把业务放在更重要的位置,因为架构是从业务拆分出来的,如果你选择技术专家路线,则需要在深耕技术的同时保持对业务的敏感。
    3. 普通程序员要想从业务代码的泥沼中跳出,要从技术水平、做事的方法、习惯和自我展示几方面入手,努力做到搞定任务有余力,进入正向循环,慢慢获得做重要事情的机会,让自己变得重要。

    点击购买我的新书:《程序员的成长课》

    展开全文
  • 《强化学习在阿里的技术演进与业务创新》电子书免费下载:https://102.alibaba.com/downloadFile.do?file=1517812754285/reinforcement_learning.pdf  温馨提醒:1、本书约20M,需要一定下载时间,请耐心等待哦。...
  • 十种技术思维:给业务新人的分享

    万次阅读 多人点赞 2020-05-01 12:04:29
    这两周比较惊讶的发现,团队里的小伙伴们...技术的表面上看是职能线,但技术的本质不是完成需求,而是在一起创造价值。有个二八原则,说的是80%需求都没啥用,其实这个数字实际可能更大。因此业务上要从起点考虑。 ...
  • 我就根据自己的经验,谈一谈业务、销售与技术的关系。 在我看来,业务、销售、技术重要性依次降低,但每一环节都是必不可少的,缺一不可。对初创公司来说,业务是最重要的,其次才是销售,最后是技术。所谓业务...
  • 支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后,支付渠道之前。 它根据支付能力将不同的支付渠道封装成统一的接口,通过支付网关来对外提供服务。所以,从微服务的角度,支付...
  • 企业要善待业务技术人员

    千次阅读 2007-06-06 00:36:00
    【CSDN5月28日独家访谈】看题目,你首先会问什么叫业务技术人员?其实在最近发布的几篇访谈文章中,我已经反复提到了这个名词。顾名思义,既懂业务又懂技术的人就叫业务技术人员。详细点说,我们把企业信息化领域...
  • 不同的业务分解下来有不同的系统,所以业务层没有办法提炼一些公共的系统或者组件,但抛开业务的差异,各个互联网业务发展最终面临的问题都是类似的:就是复杂度越来越高,也就是说,业务层面对的主要技术挑战是...
  • 互联网技术发展之路(2)- 业务如何驱动技术发展在《互联网技术发展之路(1) - 技术发展的驱动力》一文中,我们详细阐述了对于服务类的业务来说,业务发展是技术发展的驱动力。那接下来我们就看看业务究竟是如何...
  • 一、系统架构 1. 中科软 中科软的系统应用架构分为五个层次,分别是用户...主要特点是业务应用的分布化,以及基于应用集成平台的系统整合和流程整合。 2.易保(eBao) 易保寿险系统采用模块化设计。模块的分...
  • 漫谈程序员(十九)天天写业务代码,如何成为技术大牛?  不管是开发、测试、运维,每个技术人员心理多多少少都有一个成为技术大牛的梦,毕竟“梦想总是要有的,万一实现了呢”!正是对技术梦的追求,促使我们不断地...
  • 只是由于专业的分工,懂业务的人不是很了解技术,而搞专业的IT人员,又不是很了解业务。于是两帮人就有可能产生了重此轻彼的想法。关于业务技术,其关系从它们的概念诞生开始,就注定是紧密相连的。业务的发展离不...
  • 业务重要?还是技术重要?

    万次阅读 2020-09-04 06:50:00
    技术 or 业务 首先,其实除了很少岗位不需要懂业务外,大部分公司的技术岗位都需要懂业务的,随着大数据平台的逐步成熟,有了平台开发这样一个岗位,他们主需要关注平台的功能,不需要关注具体的业务逻辑,随意...
  • 架构可细分为业务架构、应用架构、技术架构, 业务架构是战略,应用架构是战术,技术架构是装备。 应用架构承上启下: 1、一方面承接业务架构的落地, 2、一方面影响技术选型  应用架构类型:单体式...
  • 何修峰,就职于滴滴业务中台,任高级技术专家一职,致力于微服务治理、提高系统工程效率、构建底层基础组件或服务,在大型分布式系统构建、微服务治理、复杂系统重构方面有丰富的经验,现负责滴滴支付中台基础工作,...
  • 作为技术人员,喜欢去以技术驱动型的公司,这也是以后的发展方向,那么我们如何来区别是自己所在的公司时技术驱动还是业务驱动呢? 1、看公司眼光的长短 一般来说,业务型公司关注当下,技术型公司关注未来。 ...
  • 百度新兴业务技术体系正在通过技术创新商业领域的结合,建立起能融合技术、产品、服务和行业的新商业生态。顾维维面临的最主要目标是塑造百度在全球技术领域和企业级生态的品牌形象,并赋能业务拓展边际的效率。...
  • 业务人员和一些有创业经验的技术人员会鄙夷的说:技术只是工具,是手段而已,是为业务服务的,公司的一切都是围绕业务运转的! 乍一听第二种观点更加接近真相,实际情况真是这样吗?   在前几年大众创业万众...
  • B2C团队的业务线参考及技术选型

    千次阅读 2012-08-18 21:49:17
    技术是为业务服务的! 做电商做的是销售,不是技术。但是做大的时候必须技术来撑腰,这里我们就来分析下B2C电商的技术到底是什么样的。 B2C的架构图如下: 通过上边的描述,大家如果要做B2C可以清晰的...
  • 随着运营商全业务经营越来越近,中国的运营商都有或者都将有两张以上的网络来提供同质业务。...电信专家希望找到一种技术,来将各种接入技术的网络资源融合在一起,提供统一的业务。例如,将移动网络、小灵通和固定网络

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,156,209
精华内容 462,483
关键字:

技术与业务