树立管理威信和沟通交际基本原则

一:沉稳(少说话)

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)勇于承担责任所造成的损失,公司应该承担

建设企业统一开发平台设计思路,提供类平台化SaaS研发平台

一、背景背景

近年来,在政策和市场的双重拉动下,中国软件市场保持了持续快速的增长。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
2Wiki管理GitBook企业内部做好考虑,团队未必每个人都能接受markdown
3开发过程管理Jira
4开发工具管理百度网盘公司内部建议使用FTP或者内部文件系统
5邮件通知163邮箱建议使用企业内部邮箱

以下为文档管理基线示例

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

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

序号说明技术版本备注
1代码管理Git(gitee)2.17.1企业内部建议使用gitlab(更能满足需求)
5代码管理客户端SourceTree2.7.6
2自动部署工具Jenkins2.107.1不建议使用太新版本
3私服库Nexus2.14.1不建议使用3.x版本
3构建工具Maven3.6.0
4代码检测Sonar5.x不建议使用太新版本
5镜像管理Harbor1.5.2
6镜像容器Docker1.12.1
7容器管理Kubernetes1.10不建议使用太高版本,跟着社区走

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

文档持续集成效果如下:

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

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

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

序号作用服务器资源(系统/内存/硬盘)IP规划备注
1开发服务器_masterCentOS7.4_x64_4G_40G192.168.1.110
2开发服务器_slaveCentOS7.4_x64_2G_40G192.168.1.111
3开发服务器_slaveCentOS7.4_x64_1G_40G192.168.1.112

规划的使用工具如下:

序号说明工具IP是否集群文档完善进度备注
1基础环境JDK172.18.11.17单点已完善
8反向代理Nginx172.18.11.17单点已完善
11自动部署工具Jenkins172.18.11.17单点完善中
12私服库Nexus172.18.11.17单点已完善
17链接跟踪skywalking172.18.11.17单点
13代码检测Sonar172.18.11.17单点
2缓存工具Redis172.18.11.17单点已完善
4消息列表Kafka172.18.11.17单点已完善
10分布式注册中心zeekeeper172.18.11.17单点完善中
6分布式注册中心Eurake172.18.11.139单点
10分页式配置中心Apollo172.18.11.139单点
6数据库MySQL172.18.11.139单点已完善
1开发过程管理Jira192.168.1.120集群
3Redis监控工具Redmon192.168.1.119单点
5消息管理工具Kafka-Manager192.168.1.119单点
7数据库主从MyCAT192.168.1.111/112集群
7容器管理Kubernetes192.168.1.1110/111/112集群
9高可用KeepAlived192.168.1.110/111/112集群
14镜像管理Harbor192.168.1.110单点
15自动部署Ansible192.168.1.119单点
16自动部署管理Ansible Tower192.168.1.119单点
17链接跟踪pinpoint192.168.1.119单点
18日志监控elk192.168.1.119集群
19服务器监控Zabbix192.168.1.119单点

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

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

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

服务设计原则

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

服务设计规划

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

工程目录规划

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

序号目录名称目录规划端口规划权限备注
1公共服务alinesno-cloud-common研发
2组件服务alinesno-cloud-component研发
3平台服务alinesno-cloud-platform24000+研发
4基础服务alinesno-cloud-base25000+研发
5业务服务alinesno-cloud-business26000+开发
6门户服务alinesno-cloud-portal27000+研发
7网关服务alinesno-cloud-gate28000+开发
8应用服务alinesno-cloud-web34000+开发
9监控服务alinesno-cloud-monitor35000+研发
10示例服务alinesno-cloud-demo30000+研发置于guide基线

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

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

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

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

中台业务架构设计

中台业务建设目标如下

中台业务建设目标

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

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

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

然后大概的设计如下:

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

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

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

机房服务器管理系统

机房管理系统,针对云系统和服务部署的管理

平台统一门户管理

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

四、总结

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

column count of mysql.proc is wrong. expected 20,found 16. the table is probably corruptd.

1558 1547 column count of mysql.proc is wrong. expected 20,found 16. the table is probably corruptd.
在用navicat连接时发生了一个错误:
1558 column count of mysql.proc is wrong.Expected20,found 16.created with mysql 50091,now running 50528.please use mysql_upgrade to fix this error。

其实这个错误如果不是用客户端工具的话是发现不了的,因为我远程控制时操作是没有这个问题的。
查了下说是这个是由于升级后未使用mysql_upgrade升级数据结构或用不同版本进行备份迁移恢复造成的。
用Navicat for mysql会有此错误提示:

解决方法:
最后是通过”mysql_upgrade -uroot -p”

命令解决的。
直接用cmd命令执行这个,然后输入密码就好了。会自动升级mysql里的数据结构。
如:

mysql_upgrade -u root -pjoy

mysql_upgrade -u root -pjoy –datadir=/var/lib/mysql/ –basedir=/usr/

从新手到部门Leader:2年管理经验的90后

关于管理这件事,千人千面,我尽量把我这几年在管理上遇到的困惑和思考按照以下四点罗列出来,多多指教。

注:文章约12000字,信息量较大,故列出文章大体框架,供参考整理思路。

wenzhangkuangjai

一、团队搭建5大步骤

早在《圣经》中就写过“凡自高的,必降为卑;自卑的,必升为高。”谁想要居首位,就必须甘居众人的末位,当大众的仆人。团队管理就是如此。

特别是现在的互联网团队基本是同龄人,最忌讳权力崇拜。坦诚和尊重,足以解决大多问题。

1、部门章程

不以规矩,不成方圆。或许在团队建立之初,大多是专业人士,能主动担责各尽其职,但随着发展壮大,新人涌现,靠自觉和人情管理就显得脆弱,这时就有必要和所有成员议定“部门章程”。

这东西相当于新人指导手册,告诉他这个部门日常是如何运作,哪儿有雷,哪儿可以撒欢。其中常见的章程条例有这些:

(1)部门架构

  1. 小组概要(图左上)
  2. 人员编制(图左下)
  3. 岗位职责(图右侧)
image001

在部门章程里,部门架构这块内容变得越来越尴尬,大多条例都因为各种各样的原因沦为“面子工程”。但对于管理者而言,一定要清楚每个岗位最重要的职责,想让一个人承担大部分工作成为“全才”,最后不过是庸才而已。

(2)立项流程

不同小组提出需求开展某项活动时,应由管理组议定项目负责人,专项负责人和管理组拥有共同决策权,部门其他成员具有审议权。具体流程如下:

  1. 启动:由部门某成员提出创意或点子,在小组内部过审,并知会管理组,授权或承认该项目的存在并制定项目负责人(默认为主管);
  2. 计划:由项目负责人确定小组分工并制定验收标准,在正常情况下,面对项目负责人提出的合理要求,部门全组必须全力支持,如有意见可以直接向项目负责人或管理组反应;
  3. 执行:确定项目的分工及完成标准后,安排各小组按步骤执行;
  4. 监控:在项目推进过程中评估项目的发展是否按照正常计划在推进,如果不是,则寻找问题点,将问题点反馈给项目负责人记录解决;
  5. 总结:完成项目后,对项目的实际完成情况进行评估,项目是否按时完成?是否在预算内完成?是否达到预计完成效果?形成文档留存。

(3)会议制度

  1. 部门例会:部门定期开展例会,频率为每周一次,时间固定在每周第一天(默认周一)的 14 : 30 ,时长控制在 20 分钟以内。所有成员必须提前到会议室准备,如有无故迟到行为,乐捐 5 元。周会内容就是让明星个人讲经验,后进个人谈改进。
  2. 普通会议:当部门成员确定发起部门会议时,一般情况下需要至少提前 30 分钟通知,并注明会议主题、时长、参与小组/成员。

(4)工作汇报

每天 9 : 10 开始分小组在会议区站立汇报当日重点工作,部门所有成员项目同步。下班前 17 : 30 填写 Excel 日报提交到 SVN ,方便主管汇总制作当日简报。

部门所有文档的提交参考时间为:

image002
image003

日报告(全员)

image004

日汇总(管理)因作者公司隐私,故模糊处理

image005

周简报(管理)因作者公司隐私,故模糊处理

image006

月报表(主管)

制定部门报表规范的初衷很简单,一是规范工作内容,存档记录,二是便于领导查阅汇报。但由于我的性格,吃亏太多了。

以上表格图是我当初给团队制定的部分报表模板,最早日汇总由全员填写提交管理查阅,日报告由管理查阅后综合提交方便领导查阅,周简报由管理汇总提交领导,月报表由主管填写留底。

但现在只留下了日汇报、日汇总、周简报三张表,其他全砍掉了。

为什么?因为我太苛求了!!我注重规范不仅要求正确填表,甚至是控制单元格长宽,为了在日汇总中方便统计同一项目的参与人数,要求全员统一工作名称,还列出了一长串日常规范项目名。

起初同事就颇有微词,我力排众议推行了近三个月,终于后知后觉这是个多么反人类的工作!

在推行过程中我发现,表格失去了它原有的作用,越来越多同事因为反感,每天只是当做完成任务,完成结果和完成时间全凭感觉而非实际情况;领导层也由于事务繁忙,基本没时间看这些规范的报表。

也就是说不管表格多么漂亮,终究是流于形式。我意识到我可能是“没有大公司的命,却犯了大公司的病。”

砍掉大多“形式报表”后,同事们面上写着的都是“早该这样了啊!!”只保留了日报的原因是因为日报是所有汇报的基础,而简报的形式是“项目进度 + 本/下周重点事项 + 个人汇总”,用 word ,不论格式,只要把问题说清楚就行。

“重形不重意”,是所有管理者需要避开的陷阱。每天面对大量繁杂的报表时,一定要想方设法去简化,不要为了报表做报表,只会浪费时间。

文字传达的信息永远不比口头快,多和部门成员交流,了解情况,文字和表述结合,才是正道。

最后,不少企业已经开始使用更高效的解决方案,比如 Teambition 、 Tower 、钉钉等,但是公司内部一定要有创新者和领导的极力推动,毕竟多数人还很“传统”。

(5)文档规范

  • 文档存放:管理者分配好文件夹,制定不同类型文件的存放位置,告知团队成员
  • 文件命名:姓名 + 标题 + 日期,例如“涂俊杰-如何管理团队 2016-11-15.doc”

(6)培训计划

为提高部门人员专业素养并持续提高团队业务能力,运营部组织每两周开展一次内部培训会,时间一般安排在每周五下午,时长控制在1小时以内。

image007

会议流程:

  • 培训会议召开通知:确定时间、地点、参与人员、会议主题
  • 参考资料的准备:幻灯片、板书、文印资料等
  • 会议环节:分段讲述、随时提问
  • 会后资料共享:会议后整理所有会议资料,将资料上传到云盘

(7)乐捐事宜

本着“乐捐不是目的,改进才是”的理念,部门推出乐捐制度,希望所有同事在工作中能遵守部门规章制度。所有乐捐金额将存入部门基金池,用于部门活动的开展。

乐捐条件参考:

  • 上班迟到:除不可抗力,每月迟到一次乐捐 5 元
  • 会议迟到:无故迟到一次乐捐 5 元
  • 工作汇报超时:每日/周/月/季工作汇报未按照要求时间提交,一次乐捐 5 元

注:主管层以上乐捐金额*2

(8)部门活动

部门每月会举办 1 次部门活动,公司提供活动经费XX元/每人。

活动举办流程:

  • 部门选举娱乐委员:选举方式视情况分为推荐、自荐和抽签,暂定为每月更换一次。
  • 游玩项目议定:由娱乐委员收集全员意见,并作出整理,娱乐委员具有最终决定权。
  • 游玩费用:在公司活动中,费用由管理组垫付,回到公司后由文娱委员负责整理发票并申请报销,活动结束后多余金额存入部门基金池,缺少金额继续由所有同事均摊收取。

以上,大概就是一个部门章程中经常会涉及到的条例。

肯定会有人说这些条条框框真是麻烦,做人不能简单点?其实在实际推行过程中,会简单很多,比如大家聊天时提到有家餐馆味道不错,这个月想去搓一顿,那就定好时间,没有什么委员选举,说走就走。

规则的存在不是为了约束主动的人,而是少部分不够主动的人。

最后要给到管理者的经验是,管理者一定要分清楚原则问题和行政问题(原则问题诸如项目责任人的确立、管理者的授权等;行政问题诸如一次迟到或着装休闲等),不要在行政问题上死抠,视公司环境和成员主动性调整规范,规矩是死的,人是活的。

2、奖惩机制

在“部门章程”中的“乐捐事宜”就属于奖惩机制的一种。而奖惩的关键在于当你罚了同事 10 块钱,今后要找理由奖励他 30 块。

在奖励和惩罚两种方法中,我始终推崇奖励,惩罚只是作为辅助。千万不能让同事在潜意识里产生负反馈。

比如我曾经会叫几位最近业务成绩不太好的同事去会议室聊天,聊天过程中指出他的问题并适当引导。但是你不能只因为同事“业绩不好”就让他去会议室“聊天”。

久而久之,所有同事都会默认为“被叫去会议室=业绩不好”,这样的后果就是所有人都害怕我叫他,害怕去会议室。

当我意识到这个问题,首先换了一个轻松的聊天地点,比如休息区(会议室自带严肃属性),然后不只因为业务下滑才聊天,也在同事业务超额完成的时候单独鼓励,并申请一些实质性的奖励发放。

说了“惩罚”,再聊奖励。新来的管理,想要尽快和同事打成一片,除了专业能力突出之外,就是多请客,多在容易带来好感的事情上曝光,带来好感的事情最常见的的就是请客吃饭(下午茶)。但是你以为突然在群里说“今天下午我请客下午茶”就是好方法么?

心理学有个经典条件反射,刚才在“惩罚”里提到“被叫去会议室=业绩不好”就算一种,对于惩罚我们需要避免条件反射,做到无规可循,但是对于奖励我们反而要利用条件反射,让其他人一有好事就想到你,占领好感高地。

那么这个下午茶该怎么请呢?回答是,在团队完成了某个小目标的时候,或者在团队测试出一条可行性方法的时候。成员目标达成,会自带成就感,这时候如果你能锦上添花,在大家心情好的时候请个下午茶,好感度 double 。(土豪随意)

3、KPI ? KPI !

KPI(Key Performance Indicator:关键绩效指标),大部分同事对 KPI 厌恶至极。追溯根源不难发现这个矛盾在设立 KPI 之初就已经埋下。

领导层希望最大限度的激发员工积极性推动目标,所以设定高 KPI ,但是高 KPI 带来的刺激程度并不是所有人都能接受,特别是当 KPI 挂钩工资,一旦员工受罚,必然怨声载道。

这次,我们不聊 KPI 到底要不要,好不好,我们来聊设定一个合格的 KPI 有哪些方法?

(1)定值 KPI

有些领导人深陷“年度目标”无法自拔,关键是领导如果执意要非常清晰业务指标,例如“一年后微信粉丝XXX”,“微信头条均阅读量XXX”之类。那么结果就是在分解月指标时只能按照月份均分,得出一条稳步上升的曲线。

这就意味着 KPI 值的容错率非常低,因为市场不可预测,可能第一季度平稳上升,第二季度突然来个幺蛾子大幅下降呢?如果挂钩工资奖惩,是不是意味着员工在第二季度只能喝稀饭呢?

所以,短期的定值 KPI ,或许可以适当刺激,长期的定值 KPI ,就是藐视市场。

image008

定值 KPI – 理想曲线

(2)浮动 KPI

什么是浮动 KPI ?就是环比统计,本月成绩与上月对比,把时间粒度切分,风险分散,指标多为百分比制。

例如“获客单价较上月降低 5% ”,“咨询量较上月提高 10% ”之类。这样做的结果是,把超额完成和未完成分布均衡,这个月出了幺蛾子, KPI 值突然下降,被罚,那下个月最少会回升正常值,对比之下上个月罚的钱这个月就能赚回来,出了黑天鹅,也是同理。

浮动 KPI 最大的特点就是跟随市场的变动而变动,在员工的赏罚之间快速制衡。当然,浮动 KPI 也不是没有缺陷,因为是以上月值为基数,容易“小富则安”,大方向感缺失。

所以目前比较普遍的解决办法是使用“浮动 + 基准值”的 KPI 形式,如“获客单价较上月降低 5% ,达成得 10 分,低至 50 元 / 人,额外得 5 分”之类。

image009

浮动KPI – 现实曲线

管理者如何制定 KPI 是一门艺术。

不仅要设定奖罚力度(奖励金额>惩罚金额),还需要在同事和领导之间找到平衡;不仅要视企业发展阶段使用不同的 KPI 方法,还要深入了解业务找到关键指标和基准值;不仅要思考客观分数和主观分数的配比,还要琢磨表格的展现形式…可能千辛万苦制定出的 KPI ,还没经过测试就被喷成狗。

小事情,大智慧。

image010

因作者隐私,故做模糊处理

4、招聘 / 离职

任何一个团队,都无法避免老成员流失和新成员的进入。团队成员是我们每天都会接触面对的人,所以招任何一个人,不论职位都要谨慎;辞退任何一位同事,都要三思后行。

(1)招聘

团队正值用人之际,向人事提出需求申请,在此之前,管理者必须非常清楚需要招揽一个什么样的人,要找执行人才还是战略人才?需要他哪方面能力突出?希望这个人入职后给团队带来哪些改变?

经过几次面试之后,对应聘者的言谈举止应该有了大致的了解,应聘者的面试作品也能反映出部分业务能力。但是真正的考验一定是入职之后。

一般来说,在面试者入职的前三天是第一道坎(熟悉部门规范),一周是第二道坎(熟悉业务流程),一月是第三道坎(是否能优秀完成任务),结束面试期之前一定要有明确结果(是否有优化工作的意识),决定去留。

说个关于我的反面例子。

我所在部门需要扩招,有两名面试者同时通过人事一面,但是两个人都有些缺点, A 对业务的熟悉度较差, B 态度有些高傲。在两人入职的第三天,我决定放弃 B ,留用 A 。

理由是一个人的业务能力可以逐渐提高,但是态度品性却难以改变。所以哪怕最后 B 写出来的业务方案明显比 A 专业。

在 A 入职后,我安排了大量执行性工作,忽略了新员工在试用期的多维度测试环节,这些执行性的工作掩盖了 A 对一些开放问题的思路和能力局限。两个月后, A 通过试用期,等到业务量增多,我不得不交付一些开放工作(没有具体的步骤,需要自己试水总结)给 A 。

但是 A 面对这些问题的处理方式很迷茫,在没有具体指导的情况下难以开展,必须要我手把手教,我一边工作,一边培训。

A 最大的问题就是缺乏思考的主动性,习惯被动接受执行性的工作。这样的性格或许不太适合开拓团队,特别是在名额有限的情况下。

上面这些问题都是我的反思,但是我发现我最大的错误在于我定错了招人的标准,我错误的把标准放在 A 和 B 之间,潜意识认为一定要从这两人中选出一个,反而忘记了招聘岗位的准绳。这件事情一直提醒我,招人必须谨慎,否则受累的还是自己。

(2)离职

天下无不散宴席,总会有同事因为某些事情离职。管理者获知该同事提出离职申请后,就需要去了解员工离职原因。

一般来说不外乎有更好的去处,主动请辞;对团队或个人不满;被动离职;希望通过离职向领导申请加薪,威胁离职;业务能力不够,公司辞退。

先说主动请辞。如果是同事找到更好的去处,管理者可以和他聊聊对未来的打算,帮他分析一下新职位合不合适,提点一些新入职后要注意的地方。

同时,在营造一个友好的沟通氛围后,可以问一些他本人对于团队的建议。这时候,他可能会因为即将离职,说一些在职时不会透露的内容,一定要仔细留意。如果同事确定要离开,那么嘱咐他做好工作交接,祝他事业顺利就好。

其次被动离职。如果团队出现了“有你没我”这种极端情况,管理者必须反思,为什么会允许这种情况的存在?

先找到症结点,人 VS 人的问题,就衡量两人的价值情况,决定去留(到了这种程度,一般无法和解);人 VS 环境,小团队的环境问题可以努力改变,但是大环境只能婉言相劝并向领导反馈,实在无法留住,后续依然好聚好散。

再说威胁离职。先给结论,所有拿离职来威胁领导希望加薪的行为都是下下策。正常的申请加薪流程应该是:整理业绩→拿着业绩向领导提出加薪→得到答复→加则留不加再提出离职。

最后是公司辞退。如果因为员工长期业务不达标,能力不足,那么管理者应当至少提前一个月给该员工敲警钟,严肃的指出业务问题并给出可行建议,如果该员工仍然无法提升业绩,那么向人事申请辞退并提交业务成绩证明。

另外,还有一种极端情况,那就是公司无理由辞退。如果企业提前一个月告知,然后按照《劳动法》支付工资,当然没事。但是企业既不想支付补偿,又想要强制辞退。管理者先要意识到,东家非常“不厚道”。

这时候切记,管理者需要站在被辞退员工的角度出面和人事及领导谈判,商量补偿,并且为同事提供切实可行的自保方法(劳动法)。而不是代表人事出面辞退员工,这样你不仅会被喷死,还会在团队中威信全无。对于这样一家企业来说,今天他能无理由辞退其他同事,明天就能无理由辞退你。

5、团队氛围

所谓团队氛围,不仅是团队内部营造的,更建立在整个企业文化之上。如果整个企业是狼性文化,你想把团队打造成温和派,怕是行不通。企业文化的改变绝非一人之力,而最需要注意的团队氛围管理是以下几点:

(1)负面控制

团队难免遇到困难时期,在困难时期管理者除了要向团队灌输正能量,还要做好负面控制。有不满是难免的,但是绝对不能出现推卸责任或边缘化同事的情况。

负面控制有个前提,首先是管理者不能说丧气话!面对某个小组的失利,千万不能说像“领导更加重视XX组,所以我们这边难过是正常的”这种话,一旦管理者说出这种话,那么被轻视的小组就等于是打入冷宫,哪儿还来奋斗的激情?

另外,要给团队合理吐槽的机会。可以设置“吐槽会”,比如每周五上午有半个小时的吐槽时间,任何人都可以被吐槽,合理吐槽(提出问题并给出个人建议和解决方案)+1 分。

当同一个人因为同一件事被吐槽超过 3 次,那么被吐槽者需要完成某个特定的惩罚,如当着团队的面表演节目之类(最好别光罚钱,大庭广众的羞耻感可比钱来的刺激)。

一定要注意维护好吐槽会的平等。不论参与者职务高低,一旦触发惩罚,必须受罚。

(2)成就感管理

团队最大的成就感当然来自业务指标的突破。管理者必须清晰的向所有团队成员解释完成某个指标所带来的意义,让团队意识到具体的场景并兴奋起来。

例如,管理者说“今天我们的日均访客目标突破了 2000 ”就不比“今天我们的日均访客目标突破了 2000 ,比之前1500的成绩提高了 33.3% ,帮公司多赚了 5000 块”来得好。

把关键指标通过统计出的数据描述为真金白银,不仅能让团队成就感爆棚,也能让团队成员知道自己的工作价值。

还有一项常常被忽略的成就感来源,那就是生活成就感。

管理者可以把自己或其他人的优秀习惯进行提炼,比如我曾经在团队组织过 15 天读完一本书行动,向公司提出购书申请,每人读完书本后写一篇读书笔记,相互传阅并口头讲述给他人。生活和工作,其实不一定要完全分开。

(3)管理者的绝对权力

虽说任何团队都是公司的财产,但是我认为团队管理者在充当团队保护伞的同时,要始终掌握团队内的“绝对权力”。

比如可能会出现的“越权行为”,当有其他团队管理者甚至领导人直接越过我向我下辖的某位同事下达命令时,我会在大群马上接过话题,重新按照我的想法进行任务分配,并委婉表示下次有需要支持的地方请@我就好。

再就是“分权行为”,管理者在内部培养接班人时不要犯懒,避免贸然让接班人迅速对外以求减轻工作。

关于“分权”这件事,其实就是要掌握一个度,这个“度”,对我来说就是管理者必须主导所有外部联系,控制接班人直接和其他部门领导沟通,如果认为时机到了,那么第一次也必须是在你的协助下沟通,并向其他部门同事表示今后部分工作会委派他来跟进,规范授权。

二、Leader需要培养的9种能力

关于优秀的管理者需要有哪些个人能力,我觉得可以分为专业能力、培养接班人能力、系统思考能力、优先级能力、沟通能力、认识自己能力、时间管理能力、个人素养,八个方面。

1、专业能力

管理者本职岗位的专业能力是所有能力之首,在团队中不要妄图以人情、素养服人,这些永远是加分项,不是必须项。

项目之初,管理者须亲自参与到项目中来,明确项目每一个节点及步骤。鞭策团队,带团队走一次完整的流程,项目完成后辅以数据证明,让每个环节的同事知道自己的付出得到了什么回报,哪些流程可以优化改进。

一般来说在管理者亲自主导完成 1 – 2 个项目之后,就可以开始由主导角色转变为辅助角色,从前更多的是监控项目进度,现在更多为整个团队提供弹药和资源。(切忌下属做事做得好,管理认为自己能做的比他更好这种竞争心理)

管理者的“贡献力”由直接业绩转换为团队业绩,开始更加关注团队成长,这是个人能力转化为团队领导力的特征。同时引出第二个能力,培养接班人。

2、培养接班人

不知道现在团队管理者还有没有“教会徒弟饿死师傅”这种思想,我的人生准则就是提倡分享。没有先贤的分享就没有后辈的进步,想要整个团队大步提升,就把你的优秀经验共享出来,分享过程中优秀的思考者会冒头,这些优秀的善于思考的同事就是你将来的左右手。

当下属能完成你做的绝大部分工作,甚至整个团队缺了你也不会翻车的时候,我认为管理者在培养团队这方面是合格的。

事实上,我通过这段时间的输出分享,收获巨大。在分享的过程中,我必须琢磨透每一个关联知识点,打通知识树的上下层。

这样来说,你教给别人的只是一杯水,但是自己先灌了一桶水。在教授的同时,自己也能加深记忆,遇到不清晰的问题还可以帮助你反思,这么好的机会,你要选择浪费敝帚自珍?

不要害怕暴露实力,你的杀手锏总有一天会被时代抛弃。始终记住“学不如教”!

3、系统思考能力

刚才提到分享,在分享过程中,爱思考的同事可能会问一些上下文联系的问题。

比如你正在向同事讲解“ 404 ”的问题,说到“出现死链要设置返回 404 状态码”,同事好奇再问,那还有哪些常见的状态码,常听别人的 301 、 302 又是什么意思呢?

如果你对“ HTTP 状态码”这个知识点没有深入了解,那肯定是懵逼的,你更不会知道顶级域名使用 301 (永久跳转)和 302 (暂时转向)到主域带来的影响。

现在是碎片化时代,太多短篇文章会分散我们的注意力,没事刷刷微博、微信,几分钟几十分钟的碎片时间就这样被消耗。

所以我规定自己每周读一本书,关注书籍中的系统思考以及作者成书的逻辑。包括我所有的文章输出,全都是按照我的逻辑框架在走,虽然很长,但是我要告诉读者,我学到这一步所有的逻辑线在哪里。

关注自身系统思考的能力,不仅有利于项目的复盘总结,也有利于个人的迅速成长。

4、优先级能力

分清楚待办事项的优先级,一定是管理者必备的能力。很多文章里有写,我就不多重复。

一般情况下,都是按照“时间——紧急程度”四象限划分。通常,领导任务 > 团队任务 > 个人任务,如图示:

image011

图片来自网络

5、沟通能力

如果我设定了某个其他团队提交的支援需求优先级为“紧急但不重要”,但在其他团队看来,或许这件事是“紧急且重要”。如何解决?这就体现出管理者的沟通/谈判能力。

沟通的过程中,先说清楚你的想法,为什么会这么安排,为什么有这样的决定。双方进行信息共享,然后判定是否需要修改优先级。

如果确实是管理者的疏忽,那么调整后修改优先级即可。如果只是对方的“伪需求”那么也适当安抚,表示已经受到重视,完成手头重要的工作后会马上跟进,向对方表态,你已经重视了该问题。一般来说,对方其实要的也就是你的“重视”而已。

在沟通中,难免会出现摩擦。管理者的沟通能力最好同时包括“情绪管理能力”,任何时候都不要在公共场合口出恶言,情绪失控。

始终牢记双方沟通的目的,不要中途被情绪绑架,偏离了初衷。例如我曾经在和其他部门沟通“网站客服系统更换”问题时,提出把XX为XX软件,结果客服部的同事以“学习成本”为由,表示反对。我说明新系统上手快,界面更美观。

但最后因为情绪激动,导致双方的话题偏移,爆发了一些旧问题,比如“客服每天接到的咨询量下降”之类完全和初衷无关的东西,由商量变成了纯吐槽,沟通失败。

良好的沟通方法是所有人都需要好好学习的地方,怎么说话,怎么维持气氛,都已经有很好的借鉴。有心学习,推荐大家看《关键对话》这本书。

6、认识自己的能力

文章开头提到,我发现管理其实是一个“重拾自我”的过程,更多的是管理自己,而不是他人。他人的秉性很难改变,也不要奢求改变,我能做的就是改变自己,通过改变自己的过程去影响他人。

怎样才叫认识自己呢?有几个很简单的测试问题,这些测试问题大多面试时就会提到,但这时候它们不再是面试技巧,更多的是为了看清自己。

  • 我的优缺点有哪些?
  • 我做事的原则有哪些?
  • 我有哪方面的兴趣爱好?
  • 其他同事眼中的我是怎样的?

能尽量详细地回答出这几个问题,代表你对自己有基本的认知度,认识自己,才能更好的改变自己。人活在世,最大的对手,永远不是别人。

7、时间管理能力

管理者时间宝贵,务必力求尽早跳出执行层,以更高的战略眼光去看问题。这就是为什么这么多大牛乐于分享自己的知识还能保证自己立于不败之地的精髓所在。

看待问题的“大局观”就是一个人的不可替代性。而培养这种“大局观”的前提,必须是能够合理安排工作,腾出完整的时间块,供自己学习思考。

关于时间管理,展开来说也是个大话题,有兴趣的朋友可以看一看我之前的文章《数据人生丨如何进行高效的目标管理?》,里详细记录了我的时间/目标的管理方法。

实践中对我的影响巨大,让我更深刻的从时间角度认识自己,发现平时不被注意的问题,在潜意识里种下的时间节奏的种子。

8、个人素质

传说中的个人魅力大多体现在一些细节上,管理者对待这些细节的处理方式就是个人的行为名片,常见的需要注意的个人素质行为有:

  • 会议时电话静音
  • 进办公室前敲门
  • 有同事在开会时注视,以表尊重
  • 用过饮水机后关门
  • 离开工位时熄/锁屏
  • 下班离开时把椅子推进桌下
  • 多说请,并看着同事说辛苦/谢谢
  • 保证桌面整洁
  • 不在公司吃有味道的食物
  • 知人不评人

最后,需要强调一点,个人的素质行为不应该成为工作中的主导,也就是说领导者不该试图在业绩不好的时候拿素质说话,也不要标榜哪些行为很好,这些只是加分项。

9、隐性经验

在职场中,始终牢记“没有人应该帮助你”这个观点,会让你减少很多没用的抱怨。聊到这里,再说两条职场隐性经验(潜规则)。

  • 注重穿着打扮,越职业越让人觉得你的能力强
  • 工作区说话/曝光次数越多,职务越高

三、5个管理痛点的分享

这部分纯属私货,只是写下我的想法和思考,不接受喷子,友好交流。

1、管理者应该是温和派还是严厉派?

管理之初,这个问题一直困扰着我。我不喜欢批评,更不喜欢厉声呵斥,妥妥的温和派。为此我一直担心同事不服。

那段时间,一直是“每一种性格都能成功”这样一句类似鸡汤的话在支撑着我。一年多后,我和同事闲聊时,听闻他说我为人太严肃。我才突然恍惚,所谓温和派严厉派只是你的一部分标签而已。

成熟的过程是慢慢意识到,这个世界并不是非黑即白。你可以一面严肃、一面温柔,只是这些需要时间。

如果你和我当初有一样困惑,也请你和我一起干了“每一种性格都能成功”这碗鸡汤。因为成功最关键的因素,不在于你是什么派,而是你能不能把事情做好,做得漂亮。

2、管理层能不能和下属做好朋友?

如果没有中间答案的话,我更倾向于不能。管理者和同事之间只要处理好公事,把团队的业绩做好,那就是合格的。

当然,我也见过能和下属公事公办,私下里关系不错的领导。但是有个有趣的现象,那就是当管理和下属玩儿得很嗨的时候,下属内心是希望领导不在场的,所以私下里关系虽然好,但是朋友圈有些话题仍会屏蔽。

不同职位等级的人之间确实是有一条线存在,不论你认同不认同。

在工作中打理好团队,做好自己的事情就足够,有适当的“权力距离”,方便工作推行也挺好的,至于能不能做好朋友,不必强求。

3、遇见能力强但不服管的员工该怎么办?

首先证实是员工能力确实强,还是员工自以为是。如果是员工自以为是,果断辞退,不要有任何犹豫。虽然可以耐心指导纠正,但是耗不起。

如果确实是员工业务能力强,那么你就要适当的反省,管理者对于这些业务能力强的人最大的帮助就是声明边界,边界以内让他们放手去闯,不要设立一些常规的条条框框阻碍他们。真的是天才,你迟早会让路,虚心学习,别端架子。

还有一种极端情况,那就是员工的能力确实强,但同时又很自负,会当面质疑并顶撞你。我曾经面对过这样的问题。解决办法就是辞退,你这里装不下他。

“当面顶撞你”这种事次数多了必然有损你的威信和自信心,如果任由他继续在团队中行走,不仅不会帮你博得“宽容大度”的美名,还可能让你越来越烦躁,影响判断力。顶撞你事小,破坏团队气氛绝不容许。与其这样,不如辞退得个清净。

4、规则在一个团队中好还是不好?

创业前期的默契小团队,没规则可以让大家撸起袖子大干一场,可是团队要壮大必须有规则。就像上文提到日/周/月报表的例子。

当管理者试行观察下属和上级对规则的反应后,就要马上做出对比结论,千万别“折中”一半老规矩,一半新规矩,最后没什么卵用。

任何一个规则的制定,都不能凭着之前的经验照搬,不同的公司有不同的文化和氛围,发现规则水土不服时就要果断舍弃,寻找更高效的解决办法。

没人喜欢冗长业余的会议,也没人喜欢看着就头大的报表。管理者不该以“我原来用这一套管理得挺好”的借口来麻痹自己,规则因人而异。

5、如何应对不同团队“踢皮球”行为?

因为我本人处在运营岗,可能沟通部门及杂事较多,不少其他部门的人会以各种各样的要求提出“支援”。

管理者首先要明确部门的职责范围和界限,千万不能因为是小事就随便接别人的猴子。这种小事能接一次,永远会有第二次。

如果其他团队说不会,你就教到他们会;如果领导的意思也是这个活儿你先接,那么管理者必须要向领导传达这件事情只是暂时接手的严肃性,一旦其他部门可以接回,必须马上移交。事情要在开始就说清楚,不然就是“管闲事”。

最后,“踢皮球”在现实中可是个危险信号。凡是其他部门以不懂互联网、不懂 Excel 、不会操作后台等借口撂挑子,坚决当面指出。你是来做大事,不是来当助理的。

四、3本书、6篇文章、1点感悟

1、这3本书值得一看,思维导图已做

image012

《卓有成效的管理者》思维导图

image013

《关键对话》思维导图

image014

《精益创业》思维导图

2、自己的一点感慨

我始终忘不了两年前主管对我说“俊杰,周总结会你一起参加吧。”那是我第一次面对公司的管理层,虽然不必汇报,但仍然紧张得不知道手该往哪里放。这几年时间里,我在迅速成长,可成长道路上总会有困苦。

我为每一次唐突处理的人情世故都交了学费。

当我带的第一个下属被公司辞退,主管说,你要想清楚这个人她为什么会被辞退,这个人是被你带“死”的;

当我第一次面试应聘者,面上谈笑风生,桌子下双腿其实在发抖;

当我第一次面对同事质疑,她当面怒怼说“你不就是因为我不服你所以针对我吗?”

当我第一次辞退业务不达标的同事……往事历历在目,恍如昨日。

感谢这一路曾经提携我帮助我指导我的人,我站在巨人的肩膀上看世界,同时也希望能言传身教,把这份精神传递给所有人。