一切问题，归根到底都是心的问题；万般答案，追根溯源都在人心之中。日航新生本质上是稻盛和夫“心灵赋能”所取得的成功！

因此，本文以稻盛和夫在日航重建新生过程中的“心灵赋能”为重点，阐述我们所理解的根和本。

1.内外因叠加，日航陷危局

日本航空发展简史，1951年成立，从一家小私有制企业起步，上个世纪80代到90年代随着日本经济的快速增长步入了快速发展期，成长为日本龙头和全球第三大航空公司，2002年新日航成立后数年便由盛走衰，2006起的五年中有四年亏损，金融危机后加速没落，2010年申请破产。到申请破产保护之日（2010年1月19日），日航负债高达165亿美元，净资产为负77亿美元，其股票总市值仅相当于137亿日元，只够买一架波音787飞机。惨淡之境可见一斑。

回溯日航的衰败，原因诸多。本文认为主要是以下四个方面：

（1）全球因素：全球金融危机、油价、突发性事故和疫情，对高度敏感的国际航空市场造成严重冲击。

（2）本国因素：日本持续低迷的经济环境导致本土航空市场需求严重不足。从上世纪90年代开始，日本经济趋于不景气，主要是由于80年代末的过度投资所造成的资产膨胀以及证券和房地产市场的“泡沫化”，最终在日元不断升值下，泡沫经济瓦解。

（3）竞争因素：日本高速铁路对其国内航空运输造成“挤出效应”。

（4）内部因素：体制僵化、经营不善、人心涣散直接导致日航走向破产。

虽然前三个因素直接导致日航客源锐减，但并非根本原因。同为日本航空龙头的全日空虽然同样面临巨大挑战，却始终以专业闻名，品质和服务不断提升，所以穿越历次全球危机和本国衰退而愈加强大，2007年还被Air Transport World评为年度航空公司。

所以，归根结底，日航的衰败还是由于体制和经营原因导致的人心涣散。破产前，日航的服务已经显得表面化、程序化，可以说是“虽然殷勤，但是无礼”。而且，管理层官僚化严重，缺乏足够的危机感，员工各自为战，缺乏商业竞争和经营意识，形不成合力。

2.越在艰难处，越是修心时

日航破产时，除了高企的负债，员工队伍也已经可以用“离心离德”来形容。就在这样内外交困的艰难背景下，时任日本首相的鸠山由纪夫亲自出山，登门邀请已经年近80岁高龄的稻盛和夫出任CEO。

2010年2月1日，稻盛正式就任日航会长时，说了这样一段话：“实现新的计划关键就在于一心一意、不屈不挠。因此，必须聚精会神，抱着高尚的思想和强烈的愿望，坚忍不拔干到底。”可见，稻盛从接手的那天起，就已经明确了日航破产的根本原因：日航人意识涣散，人心不统一。实际上，这段话也从根本上诠释了稻盛拯救日航的“心法”，后来被做成标语牌挂在日航各个办公场所，同时公司报纸上也在头版刊载。

为了彻底从内心深处唤起全体日航员工的热情，凝聚重建新生的力量，稻盛在接管后，奋不顾身，持续地做着以下八件大事：

（1）零薪担任董事长，并付出了不亚于任何人的努力。在许多的员工眼里，稻盛是他（她）们的爷爷或父亲一辈的人，一生与日航没有什么关系，为日航的重建冒极大个人名誉风险，还愿意不领一分钱，这对于全体员工都是很大的震撼和激励。

（2）宣布并践行赴任的三条“大义”。第一，为了保住留任的3.2万名日航员工的饭碗；第二，为了给低迷的日本经济的重振助上一臂之力；第三，为了保持航空业的竞争态势，让日本国民有选择航空公司的权利。

（3）揭示并反复宣贯日航的经营理念，或者叫企业目的，即“追求全体员工物质和精神两方面的幸福”。稻盛始终认为，“只要你爱员工，他们就会爱顾客。”

（4）领导编制《日航哲学手册》并全员推行。这是日航经营的指针，指明了日航今后应该以什么样的思维方式、什么样的哲学为基础来开展经营活动。

（5）组织每月一期干部学习会。每期用一个月的时间对各级主要领导人进行彻底的精神洗礼。讲领导人应有的资质，要求大家以“作为人，何谓正确”作为判断和行动的基准，要求干部成为受到部下信任和尊敬的人，并讲解“经营十二条”原理原则，彻底改革官僚体系。

（6）每个月开一次员工大会。早在出任日航董事长致辞时，稻盛就表示：“企业最重要的财产就是员工的心。如果每名员工都能发自内心地盼望重组、发自内心地配合，我坚信这个企业就能持续发展。”

（7）一线发动，率先垂范。接手日航后，年近八旬、身高一米八左右的稻盛和夫都是搭乘日航航班，都坐经济舱，表明与员工同甘共苦的决心。机舱里的乘务员在经济舱看到公司董事长，每每感动得热泪盈眶。

（8）利用盛和塾的巨大影响力帮助日航人重塑信心。稻盛一手创办的盛和塾成为日航重建最大的“外援团”。一方面，盛和塾当时已经汇聚6000余名塾生，分布在日本、美国、巴西、中国等世界的各个地方，很多塾生是骨干中小企业的明星经营者。另一方面，尽管日航的多数主管都并非盛和塾的塾生，但盛和塾的研讨会依然向他们开放，大家都很主动地去参加，常常拿一些公司经营状况的数据进行案例分析。这种彼此的交流也加深了他们的相互了解，也让塾生们更愿意乘坐日航的飞机。

稻盛进入日航后，还争取了日本政府巨额资金援助和各交易银行债务减免，并围绕“销售最大化、费用最小化”采取了很多措施，包括实施阿米巴经营及会计核算体系，落实经营措施中的极严格要求和绝对执行力，等等。但是最根本的是如上述“八件大事”所形成的“无形之力”。

因此，可以说，日航新生是从人心的觉醒和统一开始的，稻盛激发了每名员工发自内心深处的最纯粹的元力量。他的就任本身就让员工从黑暗中看到了曙光，而他动机至善、私心了无的持续努力则是挽狂澜于即倒、救千钧于一发的关键所在。

3.齐心协力干，败局获新生

稻盛的工作过程不仅“一气呵成”，而且立竿见影。

领导人层面，据说稻盛组织每月课堂，刚开始有些人还不乐意听，但后来所有人的精神都振作起来，连眼神都变了。各级经营者的责任意识开始建立，一同上课的人之间产生了强烈的一体感。渐渐地，稻盛的经营哲学慢慢由高层管理者向中层管理者乃至员工渗透。

员工层面，开始反思并致力于改进服务。（1）空姐们的播音越来越充满感情，提供各类服务越来越热情、细腻。（2）员工们在乘务长致欢迎词时站在前面鞠躬行礼，提高了送餐送水的效率，观察并满足乘客的需求，以表达歉疚和感激。（3）为了把准点率做到全世界第一的水平，他们充分做好起飞前的各项准备工作，以分甚至秒作计算时间的单位。如果被迫推迟起飞，日航也会不惜增加燃油，加速飞行以期准时降落。（4）维修人员也进一步感受到生命的重要和珍贵，从认为“工作就是检查、维修飞机“到认为“我们运送的是珍贵的生命”，安全意识更强了。（日航1985年发生过全球最大空难）这些努力不仅改变了乘客的评价，也改变了日航员工的心境，他们开始为自己和日航的进步而获得成就感，并不断以此激励自己和团队。

所以，虽然绝大部分员工的工资减少，奖金甚至没有了，但是在短短的2年多时间里，公司风气彻底发生了改变，员工发自内心地与公司同心同德同努力。变化大大超过预期，甚至让稻盛本人都深受感动。这种“精神气”，正是稻盛“心灵赋能”所产生的动人力量。

而日航因此迅速恢复生机，并且形成了可持续发展的高收益的企业体质，经营结果出乎所有人的意料，不仅日航内部，就连全世界都不能不刮目相看。

4.纯粹的心灵，赋能的力量

这个时代，我们见证了太多辉煌一时的巨型企业轰然倒下，却鲜有见到一个如此病入膏肓的企业如此快速的重新崛起。

稻盛和所有企业家的不同之处在于，他同时还是一位思想家和哲学家。他比一般企业家更能深刻地洞察人的心灵，坚信清澈纯粹的心灵最能够看见事物的真相，看透事务的本质。所以他带领日航从上到下、从里到外纯粹心灵，提升心性，通过持续拼命的努力，缔造了新生的奇迹。

如果从日航一路往前回溯稻盛的企业经营史，可以发现，心纯见真，“心里有基准，踏实往前行”，一直是稻盛所坚守、推崇、实践着的。从根本上讲，无论是京瓷的经营理念、京瓷哲学78条，乃至阿米巴经营模式等等，都是稻盛纯粹心灵的产物。这个纯粹心灵的过程也就是“心灵赋能”的过程。

从“优秀员工”变成阿米巴领导人，并非容易过去的一关。必须调整以适应新的现实，重新塑造自己，就好像客观环境逼迫我们重新塑造阿米巴一样。

对于阿米巴领导人来说，当你感到沉重的压力或对新角色不堪重负时，请停下脚步问问自己：

我是否清楚发掘出了下属的优势和弱势，或者拿他们跟我自己做比较?

我是否在用长远的眼光预测阿米巴团队的能力、挑战和期望?

我的提问是否多过直接给出答案?

我是否设定了明确的截止日期和期望成果，而将具体操作交由团队掌控?

作为管理者，我是否对自己的成长具有耐心?

陈先生是一家互联网科技公司的研发工程师，是老板和同事眼中的明星员工。当他被指派去协调一个由三名员工组成的阿米巴组织时，他非常兴奋，因为自己终于有机会成为管理层的一员。但是他很快就感到挫败和沮丧。因为那些对他来说易如反掌的任务，他的阿米巴团队却无法按时完成。

转变角色仅仅几周后，他在审阅团队成员的工作成果时，开始考虑要不要把这三个人努力的结果扔出去，然后自己重新写一个。他知道，如果自己稍微加加班，就能抵得上这三个下属的成果。

当人们从专家一跃成为管理者时，往往会遇到这种情况。一个阿米巴管理者需要努力成为一个好的老师和指导者，帮助阿米巴组织成员提高和成长，最终提升整个团队的能力。

但是，这需要阿米巴管理者在思想上完成巨大的转变，而这点对许多刚刚获得晋升的人来说非常困难。因为，指导和协调其他人跟你自己单打独斗不一样，你很难抛弃旧的思维习惯。

在转变思维方式时，有几点是你需要记住的。其中一些建议似乎是老生常谈，但当你面对新的责任和压力时，这些基本要点往往会被你抛诸脑后。

1F维系组织氛围，向阿米巴领导者“赋能”

从“优秀员工”变成阿米巴领导人，并非容易过去的一关。必须调整以适应新的现实，重新塑造自己，就好像客观环境逼迫我们重新塑造阿米巴一样。

创造、维系团队工作的氛围，是领导人的首要责任。阿米巴领导人要持续不断地塑造我们的组织网络，信息共享和赋能是让我们作战行动取得成功的法宝。并且在高层领导者的推动下，才能保持我们所需要的行动节奏、信息透明度和各阿米巴之间的良好协作。

2F作战简报是一种高效的领导工具

阿米巴组织独立经营，也需要根据市场变化迅速决策、快速行动，阿米巴团队在作战简报会议上自由交谈，来展现这种新的领导方式。

作战简报应当是关键信息汇报和积极互动的结合。彼此间需要坦诚，阿米巴成员被要求给出简短的最新情况汇报。

阿米巴成员做简报时，领导者一般都会全神贯注地倾听。对一个阿米巴组织里的年轻成员而言，即便他的简报十分糟糕，领导者也要进行适当的鼓励。接下来其他人会给出建议，看看他如何能够改进。如果领导人做得得体，则这位阿米巴成员在作战情报简报会议结束后会更有信心，对于我们的事业也更具责任心、更加投入。

3F领导人首要责任，是对组织整体负责

为了让麾下的组织变得具有调整适应能力，我们必须建立、引导并且维系一种敏捷而持久的文化。阿米巴领导人的主要责任在于维系一种全局观、大局观的方法，不管宏观管理的做法多么具有诱惑性，都要这么做。

或许对于一个卖服装的组织来说，它的领导者发现自己喜欢与服装有关的一切——设计、生产、营销，但其实，这还不是这个阿米巴组织领导人最应该发挥作用的方面。领导人的首要责任，是对阿米巴组织整体负责。

一个领导人所说的话固然重要，但他的行为对于能否形成小团队构成的大团队而言更为重要。领导者还必须允许团队成员来监控他。除了指导以外，领导者也必须展现出个人透明度。这是一个新的概念。

随着这个世界变得越来越错综复杂，领导人的重要性只会增加。表达个人意愿、精神鼓励和热情嘉奖，这一切都需要领导人来做到。说服各支阿米巴团队彼此结成网络总是困难的，但这种文化可以被孕育出来，如果得到维系，就能茁壮成长。要想让一个生态系统良好地运转，领导者就要展现出愿意承担巨大责任的态度。

4F企业要尽早开始培养员工的领导力

有些高效的员工会比较以自我为中心。但是，领导者和管理者必须把组织看得比自己还重要。

但为什么有一些高效员工可以成为很成功的管理者，而其他人却不能。虽然最优秀的管理者都是高效员工，但是最高效的员工未必有能力管理别人。

数据显示，在每四个因为高效而晋升为管理者的人当中，就有一个人的管理效率比预期差。很多高效员工经过长时间的积累，掌握了特定的专业技能，在这个情况下，组织一定会希望这个员工可以在晋升后短时间内尽快学到所需的领导技能。可惜的是，这样的事不一定会发生。

所有管理者都必须意识到，要想成为高效的管理者，除了要具备那些让人变得高效的技能之外，还需要一些其他的技能。

有些组织更善于识别出哪些人会成为成功的管理者。这些组织往往会尽早把这些高潜力员工的管理技能培养起来，在他们还没晋升之前就训练他们。

为什么要尽早开始训练呢?毕竟，大多数最终成为低效主管的人并不是不擅长上面列出的技能，而且推荐他们获得晋升的人也相信，这些技能可以在他们晋升为管理者后进一步培养起来。问题是，培养这些技能是需要时间和努力的，偏偏组织一般都希望立刻见效。通常情况下，新主管会被他们的新职责压得喘不过气，于是往往就会依赖那些使他们成为高效员工的技能，而不是管理他人所需要的技能。帮助高潜力员工培养这些技能的时机，不是在他们升职之后，而是在他们升职之前。

许多组织会等到一个人晋升为主管之后才培养他们的领导力，所以上面的道理应该让这些组织警醒。他们没有任何理由等待;毕竟，当员工的领导力获得提升的时候，他们就会成为更高效的员工。组织为培养员工的领导力所投资的时间和金钱，不仅能帮到已经升职的人，还能帮到没有升职的人。

归根结底就是：企业要尽早开始培养员工的领导力。这样，当企业让最高效的员工升职的时候，就能更加肯定，他们会成为阿米巴组织中最优秀的管理者。

一：沉稳（少说话）

1）不要随便显露你的情绪。

2）不要逢人就诉说你的困难和遭遇。

3）征询别人的意见前，自己先思考但不要先讲。

4）不要一有机会就唠叨你的不满。

5）重要决定尽量有别人商量，最好隔天再发布。

6）讲话不要有任何的慌张，走路也是。

二：细心（多思考）

1）对身边发生的事情，常思考它们的因果关系。

2）做不到位的执行问题，发掘它们的根本症结。

3）习以为常的做事方法，要有改进优化的建议。

4）做事情都要养成有条不紊和井然有序的习惯。

5）经常去找几个别人看不出来的毛病或弊端。

6）自己要随时随地对有所不足的地方补位。

三：胆识（敢担当）

1）不要常用缺乏自信的语句

2）不要常常反悔，轻易推翻已经决定的事。

3）在众人争执不休时，不要没有主见。

4）整体氛围低落时，你要乐观、阳光。

5）做任何事情都要用心，因为有人在看着你。

6）事情不顺的时候，重新寻找突破口，   就结束也要干净利落。

四：大度（多善意）

1）不要刻意把有可能是伙伴的人变成对手。

2）对别人的小过失、小错误不要斤斤计较。

3）金钱上要大方，学习三施（财法无畏）

4）不要有权力的傲慢和知识的偏见。

5）任何成果和成就都应和别人分享。

6）必须有人牺牲或奉献的时候，自己走在前面。

五：诚信（远小人）

1）做不到的事情不要说，说了就努力做到。

2）虚的口号或标语不要常挂嘴上。

3）针对“不诚信”问题，拿出改善的方法。

4）停止一切“不道德”的手段。

5）耍弄小聪明，要不得！

6）产品或服务的诚信代价，那就是品牌成本。

六：担当（勇承担）

1）检讨过失的时候，从自身或自己人开始反省。

2）事项结束后，先审查过错，再列述功劳。

3）认错从上级开始，表功从下级启动

4）着手计划，将权责界定清楚，分配得当。

5）对“怕事”的人或组织要挑明了说。

6）勇于承担责任所造成的损失，公司应该承担

一、背景背景

近年来，在政策和市场的双重拉动下，中国软件市场保持了持续快速的增长。2002年，中国软件市场实现了21.1%的增长率，销售额达到345 亿元。2003年，中国软件市场销售额达到400亿元左右，软件市场进一步升温。在几百亿元的市场规模下，掩盖了这样一个事实：软件项目成功率非常低。根据统计，超过80%的项目不能在最初估计的预算和进度内成功交付。这对用户和厂商都产生了严重的影响，对于软件产业的健康成长也非常不利。用户对厂商的效率和能力产生怀疑，对使用软件的效果产生怀疑。

厂商在项目过程中难以维持健康的现金流和获得足够的利润，无力提升产品研发水平和效率。业界一直在试图解决这种恶性循环，解决方法一是靠软件工程，厂商采用更科学、更规范的流程组织项目开发，如软件生产过程中的CMM（软件成熟度模型）规范；二是靠软件技术。而就软件技术而言，平台化技术是软件产品发展的重要趋势，平台化的软件具有独立性、开放性、可管理性和可扩展性等特点。

平台化软件分为技术支撑型平台和应用实现型平台。技术支撑型平台的用户为软件开发人员，提供商负责平台的维护和升级，用户负责基于平台的上层实现。这类平台包括软件中间件、开发工具、应用服务器等。应用实现型平台的用户为终端用户，提供商不但负责平台的维护和升级，还要负责实现基于平台的上层应用。

 例如：一个网站使用应用服务器WebLogic为技术支撑型平台，服务器的提供商（BEA）不会负责具体网站内容的建设。而应用实现型平台（如集尔普的Our-ERP系统）不但负责平台的维护和升级，更重要的是负责上层应用的实现，如企业管理软件中的财务管理，进销存，校园管理中的总务管理，教务管理等。本文章主要描述应用开发型平台的目标，定义，技术架构，实现和应用前景。

二、为什么要建设这样的统一研发平台

企业各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。

应用间数据复制严重，数据不一致性严重
基础组件薄弱，日志，监控系统不完善
功能模块定义混乱，包含大量接口，接口定义重复
大容量访问下无法提供可靠性服务

待解决问题

核心系统全面服务化：系统分解为核心服务和基础服务。
基础组件：服务化框架，分库分区，缓存组件。
加强监控，日志系统。
步化并行，限流，分流，降级，压力测试，异地灾备。

建设的平台价值

这个基础平台以先进的技术作为依撑，采用服务架构实现一个共享可复用的统一框架，是具有扩展性、兼容性、前瞻性的底层平台，满足快速开发、避免重复开发的需求，开创产品创新的新模式和新途径，更好的为产品开发和部署、运维提供服务。

平台共享数据为各个子系统共同调用的数据，减少各子系统间数据的调用，减少系统间的耦合性，达到“强内聚，低耦合”的效果；
可实现数据一次输入，多个子系统使用，消除信息孤岛，减少数据库服务器工作量，提高整体使用性能；
提供统一的开发框架，提高开发效率，避免重复开发，节约成本；
便于部署，实施和运维；
形成一个产品，用于后期产品的开发和管理。
服务模块化设计，便于根据需求组合使用。
服务统一注册、发现、治理。
便于集群部署和负载均衡，提供强大的并发支持和高可用。

约束条件

系统稳定、高效，可支持内外各种不同使用场景下的并发操作。
良好扩展性：在增加新的功能时旧有模块不做改动或稍作改动即可完成集成，部署更新不影响其他业务。
提供数据接口：便于其他产品或第三方厂商系统进行集成。
模块化：各个功能部分按模块开发，模块彼此解耦。
配置化：可根据客户实际需求，配置不同参数。支持6大平台的开发和运行，支持Windows和Linux系统。
采用B/S架构，与外部业务系统之间使用RestfulAPI进行交互和开发。
需要支持高性能、高并发、高可用和高稳定的需求。

三、云开发平台与传统的研发企业平台有什么区别

平台化开发是一套综合的工具和一组实践证明的共享的最佳平台，它形成了完整、久经考验、开放和模块化的解决方案，旨在随需应变世界中开发软件和基于软件的服务。这一平台使开发小组能够跨合作伙伴、供应商 和客户自动化和集成软件开发的核心 业务流程 ，为企业提供获得竞争优势需要的灵活性和速度，从而能够 创新 和迅速响应市场变化。

平台化开发提供给企业将应用程序和业务流程演进到电子商务随需应变环境需要的所有工具。其核心是称为的面向大小型项目的灵活的流程架构。

传统的研发配置在本地开发配置，出现很多弊端，如：

环境不统一，编码版本和规范不统一；
非功能性需求产生技术问题占用一定时间,而且每个项目环境都不一样，开发过程耗时;
项目技术学习成本高，技术不统一，产生问题排查时间较多，影响工期;
没有统一的管理平台，产物得不到沉淀

云开发平台的优势在哪里

完成企业管理和规划的统一性，编辑规范的统一;
具备灵活方便的二次开发能力;
做到硬件独立和软件环境独立;
实现上层应用的技术无关性;
工作流、报表图表工具等也应与应用开发工具组合在一起，提供一个支持管理应用开发的平台;

平台化开发的优势

最大化效率：

开发平台可以帮助IT和工程小组用较少的资源来最大化输出、减少混乱和提升提供高质量的软件和与软件相关的系统的可预测性。

平台化开发通过符合行业标准的开放平台来加速价值的转化，它定义、集成和自动化软件开发的业务和流程。它还提供完整的建立、集成、现代化和部署软件的端到端平台，通过减少混乱和增加可预测性来提高效率。

增加业务灵活性：

开发平台由灵活的流程和一组定制用于任何项目或小组规模的产品组成。通过自动化和集成软件开发的核心业务流程，开发平台可以帮助您突出重点、灵活和迅速响应。

企业可以利用对大多数开发(模式、语言、操作系统和中间件)的支持，允许在企业内大范围重复使用流程、技能、生命周期工具和资产，以响应瞬息万变的业务环境。开发平台可以提供行业中最好的分布式地理位置的开发功能，支持现场开发、场外和境外开发、全球资源规划和远程数据工具。

缩短投资回报时间：

软件开发平台允许您实施四个强制性的随需应变软件开发流程：迭代开发、关注架构、管理变更和资产、持续的确保质量。实施这些强制性流程有助于加速IT和工程投资的价值实现 。

四、平台的市场和应用前景

设计良好的平台化软件应可以普遍应用于企业管理系统、校园管理系统、电子政务、医院管理系统等各行各业。企业管理软件中的销售与分销管理、生产管理、库存与采购管理、客户关系管理、办公自动化、人力资源管理等系统可以完全集成为一个系统，所有的企业资源（人、财、物）全部共享，全面降低企业的运营成本。

校园管理系统中的总务与后勤管理、教务管理、办公自动化、注册与离校系统可以集成为一个系统，实现学校的集中式管理，严格控制支出和消耗。医院管理系统的收费与挂号、财务管理、住院管理、医生站护士站等可以集成为一个系统，实现快捷、方便的医院管理。

2002年初，Gartner公司（ERP/MRPII理论的首创者）在对未来软件架构发展报告中认为平台化软件是管理软件的发展趋势。目前，由于平台化软件不可替代的优越性，SAP、Oracle等国外管理软件公司的产品都已经转向平台化，许多国产管理软件开发商都在宣称要将战略重点转向平台化软件，甚至宣称自己现在的产品就是平台化产品。

进入2004年以后，第一代ERP悄然消退的趋势更加明显。笔者认为，真正的平台化产品不应该在原有的固化的软件基础上的改造，因为原有的系统使用硬写代码的方式实现，无法与新型的平台化软件的运行支撑系统和应用开发工具结合，实现客户个性化需求的免编程定制。新型的平台化产品必须具备两个基本要素，实现应用的完全可定制，而不是原有系统外围的所谓“二次开发”。

由于平台化软件有着诸多优点，许多软件公司准备研发类似产品，十分关心产品研发需要注意的问题。根据统计，平台产品的研发壁垒有三个方面：一是投入资金大，一般一期的产品研发至少要3000万元，而完成成熟产品需要投入近亿元；二是研发周期长，需要2-3年的时间；三是核心技术壁垒高，需要软件技术人员、管理专家的集体参与。

随着中国软件产业的发展，国产管理软件在平台化软件技术和产品上已经有了很大的突破，许多过程的平台化软件产品已经能够与国外软件公司的产品保持同步，这必将给国内众多企业用户带来更大的效益。

五、平台的收益点和盈利点在哪里，怎么样可以提升收益

六、平台怎么做好进一步的运维和管理工作

从零开始搭建的意思，就是从需求分析，系统规划，设计分析和落地实践几个步骤，从无到有的过程。考虑左右，为了个人学习和提升，选型基于流行的springboot+springcloud，从零开始搭建一套自己用于学习的研发平台。

整体平台的流程，从管理、开发、测试、运维、生产几条线，实现整体平台的落地和管理，下面是整体研发平台架构。

整个研发平台架构设计

整个研发平台产物：https://gitee.com/landonniao

整体研发平台使用的基线规划如下

平台所有基线及所有项目目录结构，整体从零开始进行平台基线搭建及规划，多个基线的规划，考虑更合适多个岗位角色的管理

序号	基线说明	基线地址	维护人员	状态	备注
1	平台整体文档目录	alinesno-cloud-document		集成中
2	平台环境搭建文档记录文档基线	alinesno-cloud-evn		集成中
3	平台前端规划及页面基础页面设计基线	alinesno-cloud-pages		集成中
4	平台所有服务列表代码基线	alinesno-cloud-service		集成中
5	平台前端应用和手机应用代码基线	alinesno-cloud-application
6	平台自动化测试基线	alinesno-cloud-test
7	平台运维脚本过程产物基线	alinesno-cloud-operation
8	平台搭建过程中常见问题基线	alinesno-cloud-question
9	开发人员使用平台指引	alinesno-cloud-guide			略

一、个人为什么要搭建一个统一研发平台

1、为了有方向感，不迷茫，不浪费时间，有可行的学习计划

上大学的时候，就开始学习计算机，从基础的Java到Java web，再到框架，再到在学校接一些小项目，如企业网站，兼职网，报名网站等，这几步路大概走了2年左右，而在学完两年之后，人还是很迷茫，方向感还不是特别强，而在找方向和突破迷茫上面，走过了很多弯路，终于找到点方向。后来才发现，很多这个专业的同学，可能毕业几年之后，依然还找不到方向和定位，东学一点西学一点，很浪费时间，可能醒悟的时候，已经过了3~5年，很难再转回头。

2、为了在工作和学习过得中不断积累和提高学习效率

学习和工作的几年里，几乎每个项目，资料，文档，规范都是有共性的，而由于各个项目的不统一，在接收新项目的，几乎都从零开始，一些非功能性需求的建设已经占去了实际项目的很多时间，投入需求建设的时间其实没多少，最简单的，代码的CURD都是一样，自己在做的时候，针对每个项目都有改进，比如这个项目统一了CURD，那个项目梳理出了公共代码，但是项目是分开的，最终新的项目，也是从零开始或者复制，再加上人工，手工，人肉运维，不断的繁琐而简单的工作的学习中无法脱身，影响进入下一步学习。这类似于温水煮青蛙，没有感觉，可能慢慢拖死自己，特别是做项目的前两年，除了数据的添加删除，还是这些。重复开发，无法共用这些都消耗了很长的时间。比如一直想学大数据，但是由于没有好的平台依托，目前还是无法投入学习。

3、为了可以总结和反思，可以不断的打磨出一个平台，一个产品或者一个精品

这几年的工作和学习中，有很多都是在学习，在努力，也很上进，资料有不计其数，但是却在用的时候，没有深入或者精通某一个模块，最常见的，连自己精通的模块都无法界定，不自信，没有自己的深入心得，比较浮在表面上。自己近乎有两年的状态如此，一直在努力，但是却一直没有达到预期的，别人认可的效果，接触的面好像很多，但是却没有哪一样是完全吃透的。最终发现的原因是没有做好总结和复习，反思，一个知识点以为看过了就懂，但是没有结合实际进行提炼与打磨，没有吃透，就往下一个模块，最终导致好像不断的在捡东西，但最终这些东西都不是自己的。所以需要打磨自己的东西，能谈出自己心得，这就是自己的产品，就是自己的精品，或者自己就一个精品。

4、为了扩大自己的视野和学习心态，开放心态

学习中最怕和就是无沟通与交流，没有他人的指点和自己的固步自封，坐井观天等心态，在学得一些技术之后，开始自以为自，然后偏向于安逸。明显，这种心态自己曾经有过，而且持续很长一段时间。这间接造成不管是沟通、技术方面都慢慢出现问题。自己一直相信，心态有多开放，有多宽容，帮助的人越多，自己也才更好的成长，不管是技术还是管理，包括生活等。

 二、个人需要搭建怎么样的研发平台来学习

1、可以随时随地的学习，只要有网络和电脑，就可以学习

闲碎的时间常常存在，比如学校上机，看手机，还有一些无聊的聚会，甚至上厕所，这些都要能可以用来学习，网络现在无处不在，有个手机就可以上网，所以这些时间要能充分利用起来。

2、可以好的工具和学习环境

学习过程，工具的成熟度和熟练程度很多时间影响到自己的学习效率。比如vim的配置使用，熟练之后，不管在编辑和代码方面，速度都比一般的操作快得多。还有jenkins，在这个工具上不断的学习和积累，不管是配置和权限，发布，运维，分布式都能很大的帮助，同时节省很多时间。

3、可以不断的学习目标，最好从基础程序员到总监

学习有一个从零开始，到不断往上的过程，并且有目标，知道每个目标阶段需要什么样的技术，能力，成长时间等，做到心知肚明，不浪费多余时间 。可以不断的有学习积累，在积累上由量变到质变

5、可以不断的跟外界沟通交流，避免闭门造车，固步自封

需要不断的与外部学习，获取到外部的建议，看到自己的不足，同时也看到自己的优点。在自己不断学习的过程中，同时不断的成果，并让别人看到，给自己提建议，在自己把自己的思路成果对外贡献的同时，别人也一样帮自己提升。

 三、研发平台怎么搭建，搭建到什么样的程度

搭建的思路都是先有一稿，然后再后期慢慢在这一稿上面做好优化，同时参考当前社会主流技术，便于学习。

1、制定整体学习规划和学习路线，技术路线和成长规划

平台构建过程中，产生大量的技术产物和管理产物，而在大量的项目过程中，同时也会产生大量的问题导致过程中细节的不完善，人为的不完善及限制，导致平台无法正常管理和运维，开发平台的管理规划即针对整体平台的运维管理进行的建议，以达到管理统一有序，过程明确，产物明确，目标明确等

从需求->准备->组织->开发<->内部测试<->用户测试<->自动测试->生产(试运行)->生产->运维整个流程完善，每个流程中又包括多个工作，如需求管理，同时每个工具必然有一定的产物，如需求管理的产物是需求管理基线和需求文档。

序号	模块	功能	产物	备注
1	需求	需求管理	管理基线
2	需求	组织分工	需求人员管理表
3	需求	需求变更
4	需求	需求确认	需求文档
5	需求	需求分配
6	准备	工具准备	工具管理文档
7	准备	组织结构	人员资源清单
8	准备	环境准备	开发基线/文档管理基线
9	准备	资源准备
10	准备	基线准备
11	组织	人员资源	人员资源准备
12	组织	开发管理
13	组织	沟通管理
14	组织	角色分工	角色分工及联系沟通表
15	组织	版本管理
16	开发	开发培训
17	开发	开发管理
18	开发	单元测试
19	开发	开发流程
20	开发	部署管理
21	开发	问题处理
22	测试(内部)	内部测试
23	测试(内部)	组织机构
24	测试(内部)	问题反馈
25	测试(内部)	Bug管理
26	测试(内部)	接口测试
27	测试(内部)	功能测试
28	测试(内部)	集成测试
29	测试(用户)	业务测试
30	测试(用户)	问题反馈
31	测试(用户)	Bug管理
32	测试(用户)	问题反馈
33	测试(用户)	测试报告
34	测试(用户)	版本管理
35	测试(自动)	测试配置
36	测试(自动)	压力测试
37	测试(自动)	安全扫描
38	测试(自动)	功能测试	测试报告
39	测试(自动)	安全测试	安全报告
40	测试(自动)	压力测试	压力报告
41	生产(试运行)	切换计划
42	生产(试运行)	工单管理
43	生产(试运行)	账号管理
44	生产(试运行)	安全管理
45	生产(正式)	运维监控
46	生产(正式)	工单管理
47	生产(正式)	日志管理

为达到以上的要求，也为了过程有记录和沉淀，考虑一些必要性的管理工具，暂时考虑以下几个工具：

序号	说明	技术	版本	备注
1	文档管理	GitBook		企业内部做好考虑，团队未必每个人都能接受markdown
2	Wiki管理	GitBook		企业内部做好考虑，团队未必每个人都能接受markdown
3	开发过程管理	Jira
4	开发工具管理	百度网盘		公司内部建议使用FTP或者内部文件系统
5	邮件通知	163邮箱		建议使用企业内部邮箱

以下为文档管理基线示例

2、制定持续集成环境，为学习提供基础的准备和提升效率

持续集成他一套比较成熟的自动化研发解决方案，使用也有几年时间，不同的人有不同的设计，有些可能只是发布工程，这里针对于需求、开发、测试、文档、运维几个维度，进行了整合，同时也制定和管理方案，以达到基础规范 – 组织结构 – 基础架构 – 业务开发 – 持续集成– 自动化部署 – 自动化测试 – 生产运维监控 – 在线升级 几个方向自动化，这里不得不提一下Jenkins+git，确实是整个自动化的核心。目前考虑了一下这些工具，针对于开发的：

序号	说明	技术	版本	备注
1	代码管理	Git(gitee)	2.17.1	企业内部建议使用gitlab(更能满足需求)
5	代码管理客户端	SourceTree	2.7.6
2	自动部署工具	Jenkins	2.107.1	不建议使用太新版本
3	私服库	Nexus	2.14.1	不建议使用3.x版本
3	构建工具	Maven	3.6.0
4	代码检测	Sonar	5.x	不建议使用太新版本
5	镜像管理	Harbor	1.5.2
6	镜像容器	Docker	1.12.1
7	容器管理	Kubernetes	1.10	不建议使用太高版本,跟着社区走

自动化持续集成的效果如下：

文档持续集成效果如下:

3、下载和整理软件工具，整理软件工具版本

基础环境完善及配置，为整个开发平台做基础，以环境搭建为主,为本地开发环境。

使用的阿里云服务器规划如下：

序号	作用	服务器资源(系统/内存/硬盘)	IP规划	备注
1	开发服务器_master	CentOS7.4_x64_4G_40G	192.168.1.110
2	开发服务器_slave	CentOS7.4_x64_2G_40G	192.168.1.111
3	开发服务器_slave	CentOS7.4_x64_1G_40G	192.168.1.112

规划的使用工具如下：

序号	说明	工具	IP	是否集群	文档完善进度	备注
1	基础环境	JDK	172.18.11.17	单点	已完善
8	反向代理	Nginx	172.18.11.17	单点	已完善
11	自动部署工具	Jenkins	172.18.11.17	单点	完善中
12	私服库	Nexus	172.18.11.17	单点	已完善
17	链接跟踪	skywalking	172.18.11.17	单点
13	代码检测	Sonar	172.18.11.17	单点
2	缓存工具	Redis	172.18.11.17	单点	已完善
4	消息列表	Kafka	172.18.11.17	单点	已完善
10	分布式注册中心	zeekeeper	172.18.11.17	单点	完善中
6	分布式注册中心	Eurake	172.18.11.139	单点
10	分页式配置中心	Apollo	172.18.11.139	单点
6	数据库	MySQL	172.18.11.139	单点	已完善
1	开发过程管理	Jira	192.168.1.120	集群
3	Redis监控工具	Redmon	192.168.1.119	单点
5	消息管理工具	Kafka-Manager	192.168.1.119	单点
7	数据库主从	MyCAT	192.168.1.111/112	集群
7	容器管理	Kubernetes	192.168.1.1110/111/112	集群
9	高可用	KeepAlived	192.168.1.110/111/112	集群
14	镜像管理	Harbor	192.168.1.110	单点
15	自动部署	Ansible	192.168.1.119	单点
16	自动部署管理	Ansible Tower	192.168.1.119	单点
17	链接跟踪	pinpoint	192.168.1.119	单点
18	日志监控	elk	192.168.1.119	集群
19	服务器监控	Zabbix	192.168.1.119	单点

工具的保存是放在百度云上面：

4、规划平台非功能性需求组件，包括基础组件等

功能重用，组件重用，目前最好的技术承载就是微服务了，这也是这几年才出现，这样规划研发平台构架，对我而言，微服务架构自然成为不二的选择（后面的中台业务也是在微服务上进行进程创建）

服务设计原则

服务单库设计,以减少迁移，服务之前影响等；
基础服务只为调用设计，位于服务的底层或者中间层，基础服务禁止调用业务服务；
业务服务调用基础服务，或者其它服务，业务服务为服务的顶层，用于定制化业务；
同一级服务之间可以互相调用，只能自下往下调用，平级调用，禁止自下往上调用，以避免服务混乱及维护混乱。
每种服务目录按999个服务规划

服务设计规划

类型	目录名称	说明	备注
教程	示例服务	做示例工程，包含有所有服务调用示例
前端应用	门户服务	与中台服务同级，用于统一门户服务
前端应用	应用服务	前端应用或者手机应用
网关应用	网关服务	对外网关服务,与平台组件同级，但仅做为网关部分
中台服务	中台服务	服务于前端应用，处理业务，可以服务之间互相调用，或者调用基础服务
基础服务	基础服务	公用基础组件，只能被调用或者调用公共或者组件包,不能主动调用其它服务
基础服务	公共服务	基础公共包,所有工程的基础，包括配置，页面，核心包等
基础服务	组件服务	基础组件包，用于第三方等，组件包不能单独运行，只能被依赖
运维环境	监控服务	监控平台，用于运维平台，目前仅规划,有可能与平台服务合并一起
运维环境	平台服务	包括注册中心，配置中心等

工程目录规划

关于命名方向，一直不知道用什么名字比较合适，所以使用自己网站的域名。

序号	目录名称	目录规划	端口规划	权限	备注
1	公共服务	alinesno-cloud-common		研发
2	组件服务	alinesno-cloud-component		研发
3	平台服务	alinesno-cloud-platform	24000+	研发
4	基础服务	alinesno-cloud-base	25000+	研发
5	业务服务	alinesno-cloud-business	26000+	开发
6	门户服务	alinesno-cloud-portal	27000+	研发
7	网关服务	alinesno-cloud-gate	28000+	开发
8	应用服务	alinesno-cloud-web	34000+	开发
9	监控服务	alinesno-cloud-monitor	35000+	研发
10	示例服务	alinesno-cloud-demo	30000+	研发	置于guide基线

5、提取出业务中台规划，并完善组件，打磨中台业务产品

上面也提到，业务中台也是在微服务上面构建，设计原则加上了几个点，分别如下：

按“重中台”+”轻应用”设计，业务应用逻辑思路放在前端应用，推荐是尽量减少或不拆分前端服务;
重中台的建设，在于前端应用共性部分的抽取和后期的沉淀，形成中台业务服务;
中台服务调用基础服务，或者其它同级服务，中台服务为服务的中层，用于业务共性(共享)抽取；

整体中台的业务架构如下：

中台业务建设目标如下

6、统一和通用的权限配置系统和界面设计

这个就是通用的，只需要在配置平台添加好菜单，分配好账号权限，本地开发只需要账户就可以进行本地开发，配置平台包括的一些功能规划如下：

应用管理：用于配置系统应用，添加和删除管理。
用户管理：用户是系统操作者，该功能主要完成系统用户配置。
部门管理：配置系统组织机构（公司、部门、小组），树结构展现支持数据权限。
岗位管理：配置系统用户所属担任职务。
菜单管理：配置系统菜单，操作权限，按钮权限标识等。
角色管理：角色菜单权限分配、设置角色按机构进行数据范围权限划分。
字典管理：对系统中经常使用的一些较为固定的数据进行维护。
参数管理：对系统动态配置常用参数。
通知公告：系统通知公告信息发布维护。
操作日志：系统正常操作日志记录和查询；系统异常信息日志记录和查询。
登录日志：系统登录日志记录查询包含登录异常。
在线用户：当前系统中活跃用户状态监控。
定时任务：在线（添加、修改、删除)任务调度包含执行结果日志。
代码生成：前后端代码的生成（java、html、xml、sql)支持CRUD下载 。

然后大概的设计如下：

开发人员的开发流程如下：

7、完善软件组件辅助，包括测试、运维、环境管理

以上组件的搭建过程，如果一个人管理，会产生很多问题，同时延伸出其它方向的建设，其中包括最基础的服务器管理和服务预警方向，安全策略管理，平台整体入口和常用文档，功能，平台组件的质量保证，即运维、机房环境，测试这几块。在建设统一研发平台的同时，也自然包括建设这些内容，大概做了一些建设工作，以下为一些设计的示例。

机房服务器管理系统

平台统一门户管理

• 

其它的建议，如包括人才培养，大数据，人工智能，项目管理，都是在研发平台中慢慢积累和培养的产物，而最终的结果是为了整理出一套完整的企业统一研发平台。

四、总结

以上为目前搭建整体个人整体研发平台的思路和设计，一个优秀的研发人员的工作并非只是编制代码，更多的是自己能做什么，完成什么，有什么价值，能帮别人做什么。