数据分析师要去数据部门还是业务部门?

在企业中数据分析师岗位一般归属于两个部门,一个是数据部门,一个是业务部门,而在招聘的时候,统称都叫数据分析师,从岗位JD中很难看出这个岗位的归属部门,需要我们在面试中需要去沟通确认的。由于我比较“有幸”两种架构都待过,分享下自己的拙见。

数据组vs业务组之间的差异

数据组是由一些数据分析师组成的专门组织,而业务组是长在业务部门里的数据分析师。我自己根据我经历过的两种组织的差异性,做了个简单的对比。

数据组也有是随着业务的发展,需求的增长,由数据分析师独立壮大出来的组。专门的数据组最大的好处是有高级数据分析可以学习与指导,然后接触数据面比较广,缺点是离业务较远。

目前造成业务部门内自己招数据分析师而不是用数据组,业务的老板觉得手下用的更顺手,不用等待别人的需求排期,有时也是排外心理不愿意让别的部门插手自己部门的事情。业务部门最大的优点是接地气。缺点就是多数情况下,没有高级的数据分析师指导你,只能自己摸索着发展。

面试中需要确认的问题

关于数据分析师,很多时候可能是Excel或者SQL取数的人资源不够,来招个人做取数机,以及业务领导看很多部门都有数据分析师,没想清楚为什么要招这个分析师。所有这些需要大家在面试中进行确认。

首先跟面试官确认这个岗位汇报的对象是谁,业务老大还是数据的老大,然后就能判断出来组织架构。

——数据组,需要确认的问题是否大部分时间是在取数和对接报表需求,是自己取数还是也有IT(数仓)支持?有无更多接触业务的场景与机会。

——业务组,可以确认是否可以自己取数或者服务对象,决定自己获取数据是否受制于他人;老大中的分析具体是解决问题的场景是什么,确认老板是否只是头脑发热。

数据组与业务组

数据组和业务组各有利弊,那么如果有机会可以给你选择,你可能会困惑。曾经的我在数据组面临转岗机会时候,也犹豫了很久,最后决定试下新的机会。最终我的体验的结论是倾向于长在业务组里的数据分析师。

真正在业务部门,你才对这些数据更敏感,才能知道更多数字背后的故事。说白了,就是你和业务部门同事‘混’在一起。

在业务部门,业务结果为导向,建立更多的合作机会。

其实在业务部门,大部分是实际应用场景的分析,如果给出一个浅显的结论,是很容易被老板diss的。当然随着跟业务接触时间长了,你可以知道业务目前现阶段关注的重点以及目前遇到的问题,主动出击与业务人员合作,容易出成果。

注意点:避免成为新的取数机,自己闯出一片天

由于你是业务里的数据分析师,业务里的很多需求就会砸向你,我觉得首先得跟业务老板协商好自己的主要工作职责,首先是过滤掉单纯的取数需求,精力集中于能产生行动的分析上,靠自己努力成为业务的分析专家,打造竞争壁垒。

数据组同学怎么办

那么现在在数据组的同学,可能会说,我已经在数据组怎么办呢。

我觉得在数据组的缺点是远离业务,所以就是要跳出自己的舒适区,和自己老板协商,对接具体业务产线,参加业务的会议,知道业务关注什么,寻觅合作机会。

文源:数据氧气

直接来源地址:https://www.wukong.com/question/6899633546828185864/

数据分析不只是一个岗位,更是一种职场必备能力

从事数据分析十年以来,我越来越感知到数据分析的学习与成长从来都不是纸上谈兵,不是理论空谈,也不是拿工具说事,而是不断在实践中迭代理论、磨炼经验。

近十年来,我先后在零售、电商等行业工作,一直专注钻研数据分析,包括数据分析技术、业务赋能、数据分析平台建设,以及数据分析团队的组建与管理等。

在整个过程中,我主导搭建过企业数据底层架构,通过统一化业务系统数据资源,从数据提取、集成,到数据清洗、加工、可视化,实现了一站式分析,帮助公司解决了数据混乱、业务系统孤岛等“老大难”问题。我也曾主导搭建上层 BI 项目级应用,让企业实现了营销模式全覆盖和数据流通。

实践的过程,就是我个人历练成长的过程。这一路走来,我在数据分析领域积累了丰富的业务经验和踩坑经历,并越来越深刻地感知到数据分析的重要性。

数据分析能力在不断“破圈”

任何岗位都要体现自身价值,数据分析最重要的就是给企业和业务带来价值。不过事实上,从我接触的数据相关的同学来看,大部分却专职做着利用 SQL 取数、写数据报告等枯燥、机械、低价值感的工作,导致自己越做越没动力。深究其原因,很重要的一点是:只是被动完成需求。

我刚开始做数据分析的时候,也是完全被动地接受来自业务和 IT 部门的需求。比如帮业务人员取一些零售数据等,但是怎么从客户维度、销售维度、门店维度去分析差异数据,该怎么做客户画像、产品规划、投入预算等,却不是随便跑跑 SQL、做几张 Excel 报告就能够完成的。只有真正挖掘数据背后隐藏的价值,才能够帮助你脱离低价值感的机械数据岗位。

如果你在分析业务需求时具有了这样的思维,那么恭喜你,你成功找到了普通数据工作与数据分析的分水岭——主动寻找数据价值,这也是数据分析会大火的原因之一。

如今,各企业都在数据化进程加快的激流中,谋求突破用户增长瓶颈、开展精细化管理的方法,数字化转型的大潮让数据分析人才供不应求。

无论是专业的数据分析岗位,还是运营、产品、财务、人力、销售等岗位,都开始关注从业者的数据分析能力:运营需要通过数据分析来解决流量、用户增长问题,产品需要利用数据分析解决业务增长需求,财务更要通过数据分析支持业务分析与管理……数据分析技能“不断破圈”。

无论你处于什么岗位,具备数据分析思维、懂得利用数据挖掘价值,便可以更客观地审视公司业务并优化流程,创造更高的企业与个人价值,成为职场的佼佼者。特别是在互联网公司中,反观对数据分析还没有丝毫概念的人,往往很快就遭遇瓶颈,在职业发展的道路上停滞不前,甚至被边缘化!

怎样才能学好数据分析?

跃跃欲试者众,但学好、用好一门技术并不简单。

我是一名典型的转行者,最初学习数据分析完全是个人兴趣推动,但问题和困惑也随之出现。自学的过程中,我发现一些知识开始越学越乱,明明看了很多资料,却还是很难搞懂实际业务场景,处于盲人猜象的迷茫阶段。在后来面试招人、搭建团队的过程中,我也深切感受到这是很多入门数据分析的初学者必然会遇到的问题。

于是,我决定深入行业去体会实际场景。在掌握了一些简单的数据分析基础技能(如利用 Excel 进行数据分析)的情况下,我毅然转行进入了电商行业,做一名数据分析专员,从最简单的报表、取数等工作开始了我的数据分析从业生涯。

再后来,我在业务工作中又不断掌握了 Python、SPSS、Hadoop 和各种 BI 工具等技能,能够利用各种工具或者编程语言对数据分析进行清洗、加工和可视化处理等操作。这时我开始尝试分析业务,想要进阶高级数据分析师。

但此时,我发现自己对业务的了解只浮于表面,脑海中没有具体场景,很难突破瓶颈,于是一直无法摆脱“工具人”的定位。这一点,我想大部分数据分析师都有切实的感受:盯着满屏的数据,半天分析不出一点结论和建议,只能做着低价值感的工作。职业生涯的天花板触手可及,这不是我选择这条路的初衷!

后来,我专门拿出时间学习业务部门的知识,包括流程梳理、业务模型、指标体系建立等。再后来,又逐渐承接业务部门的数据项目分析需求。比如采集人力数据做销售人员绩效分析,为此我专门学习了 HRDA(人力资源数据分析)中关于绩效管理、TOP 模型等知识,最终依靠数据模型优化了公司销售人员的绩效算法,提升了业务流程。

就这样一步步经历挫折、误区与摸索之后,我也终于从一个一无所知的纯小白,成长为一名略有成就的数据分析师。在这个过程中,我愈发感知到数据分析对于全行业的重要性,因为任何一家企业都需要利用数据资源创造利益价值,而我们数据分析从业人员就是为了挖掘数据价值而存在的。

(略,见原文)

我建议你多去了解业务、熟悉业务、解剖业务,只有以长时间积累的业务经验作为赋能基础,数据分析工作才能长远地发展下去。

最后请记住一句话:学习任何一种知识,坚持到底可以打败 99% 的人!

直接来源地址:https://www.toutiao.com/i6893406066017567240/

论数据分析师的职业技能

笔者作为一个有幸在数据分析与建模领域摸索过的数据从业者,有一些总结与思考。成为优秀数据分析师的道路千万条,其中比较扎实的一条便是从最底层的数据开始做起,积累对数据的认识,了解整个数据生命周期的全貌以及数据生态链都有哪些环节。

当理解了数据是如何产生、存储、使用和销毁的,就会知道为什么公司的数据会有一定的存储周期,为什么有价值、高质量的数据会这么稀缺,为什么数据处理环节如此耗时却又至关重要等等。而这些,恰恰是一名优秀的数据分析师需要懂得的。

以下就抛砖引玉,简单分享一下我所理解的数据分析师成长之路和必备知识技能。先上一份数据分析师成长的路线图,看看在不同阶段的数据分析师都应做到什么。

那么从数据分析的菜鸟,一路升级到优秀的数据分析师,需要哪些知识和技能呢?

知业务
数据分析不是无源之水,具体的业务场景才是数据分析的初始目标和最终归宿。要做到从业务中来,到业务中去,就要求数据分析师熟悉行业知识、公司业务及流程。

比如做一个信贷相关的数据分析项目,如果对相关信贷产品的设计,贷款的申报、审批、发放、风控等业务流程,以及流程内诸如客户经理、审批人员、放款人员、贷后监督人员的职责分工和工作内容有一定的了解,便可以从庞杂的业务信息流中有的放矢地选取分析目标和有用数据,产出真正业务人员用得上、用得好的数据分析模型、策略和产品。

会分析
需要掌握数据分析基本原理与一些有效的数据分析方法,并能灵活运用到实践工作中,以便有效的开展数据分析。在知识库中提前储备一些如对比分析法、交叉分析法、综合评价分析法等基本的分析方法,以及回归分析法、聚类分析法、其他机器学习与人工智能算法等高级的分析方法,做到心中有数,随时可用。

而想要在数据分析之路上走得更远,成为专家乃至数据科学家,对各类方法的理解不仅要知其然,更要知其所以然。比如,构建评分卡常用到的逻辑回归模型,可以了解它的基本假设、损失函数、优化方法是什么,如何处理数据才能提高该类模型的稳定性和准确率,与其他可替代方法相比的优缺点等。

用工具
数据分析方法是理论基础,数据分析工具就是实现数据分析方法理论的抓手。面对越来越庞大的数据,仅仅依靠Excel等基础工具已无法满足需求,掌握更强大、专业的数据分析工具或编程语言(如BI、SQL、SAS、Python等)以及常用的数据分析库(如Python中的Pandas和Scikit_learn等),辅助完成数据分析工作,可以达到事半功倍的效果。

擅表达
虽然常常被忽略,但这可能是最为关键的一部分。一方面,多数分析成效不佳的问题都和前期同业务与开发人员沟通不足、理解不够有关。和相关业务人员、开发人员的沟通涉及业务术语与技术术语的翻译与转化,不同角色间思维方式和表达习惯的差异对数据分析师的沟通表达能力提出了很高的要求。

另一方面,撰写分析报告,将数据分析的结果和得出的观点借助文字、图表甚至影像简明而高效地传递给目标受众(经理、客户等),也是优秀数据分析师的必备能力。

懂管理
从一个数据分析项目的规划和启动,到中间的执行和监控,直至项目的报告和收尾,每一个环节都需要一定的管理协调能力。比如,在项目规划启动阶段,需要协调业务人员对需求进行分析,对现状进行评估,也需要组织分析人员对项目进行可行性分析,形成计划书,还需要协调开发人员进行数据完备性调研。在合适的时间、以恰当的方式将有限的资源调配到各项工作上,持续推进项目直至按时保质保量完成,无不考验着管理能力。

知业务、会分析、用工具、擅表达、懂管理,这些技能的磨练难以一蹴而就,最为直接的途径就是多参与项目,可以是手头正在参与的各种数据分析类工作,可以是Kaggle竞赛上的项目,甚至可以“无中生有”,就一些日常工作生活中的小事做一点探索,比如研究一下车牌拍卖数据来做一个竞拍策略,或利用Excel的宏模块做一些数据的自动化可视化展示。总之,get your hands dirty,行动起来,踏上成为一名优秀数据分析师的道路。

文源:数据治理周周谈

直接来源地址:https://www.wukong.com/question/6903334291250495752/

大数据从业10年,从一个BI项目的失败,看到数据治理的重要性

很多企业在做BI项目时,一开始的目标都是想通过梳理管理逻辑,帮助企业搭建可视化管理模型与深化管理的精细度,及时发现企业经营管理中的问题。

但在项目实施和验收时,BI却变成了报表开发项目,而报表的需求往往和个人习惯有关,一旦人员发生变动,尤其是新入职的高层,会把前公司的内容搬过来,这就需要重新开发一大堆报表。

如果不从源头进行控制,被动服务模式下的IT不可能满足所有人的报表需求。接下来我们要讲的这个案例就真实反应了这个过程,同时也为大家解析问题产生的原因并找到解决问题的方法,建议所有有计划或已经实施BI项目的企业,认真阅读本文。


一、2011年底至2012年初,笔者在某女装公司组织实施BI系统,项目第一期就花了100多万,长达6个月的周期,经历了业务需求调研、数据清理、指标体系梳理、数据模型构建等等一系列中规中矩的项目实施过程。

从业务个性化需求报表到以经营指标为导向的数据模型、数据驾驶舱等等,在项目组看来,除移动化展现,几乎覆盖了当前所有业务需求。在多次宣导并召开上线动员大会后,BI终于正式运行了。

然而现实却给了项目组一个响亮的耳光,在BI系统上线后,3个月内不仅使用次数屈指可数,就连最初要求的月度经营分析和绩效考核必须从BI中取值这两点都没有实现,依然需要业务部门从各个系统中导出数据再自行计算统计。

第一期项目很快就被宣判失败,这让整个项目组深受打击,实施方法论是没有问题的,也针对上述状态的可能性做了很多短期过渡的报表,还有最大自由定义的万能报表,但最后用户们依然不满意。这究竟是什么原因呢?

二、项目组进行反思,并用一周时间去做了用户调研,进行深入地讨论总结。

1、大部分用户反馈BI系统操作缺乏便利性,使用起来特别麻烦。因为每个用户只需查看自己日常工作的数据即可,这第一期BI系统实施把所有业务特性进行了归纳,按照其基础职能设置指标组合与自主选择的时间跨度栏位。

用户因此产生一个印象就是需要的报表全部堆砌在一起,你需求什么自己去找,而且部分派生指标取值需要重新计算后产生,报表展现的效率低下,BI操作起来就很痛苦。

其实每一项体系既要有决策层的视角,也要有管理层的视角,虽然按照操作层的指标体系与时间自定义几乎涵盖一切,但这样并没有针对每一个岗位进行相应的配置,要想得到用户认可,首要要素需要满足各层级用户在某一时间周期内的数据所见即所得

2、指标体系的管理逻辑梳理不清晰,需要用户凭经验去寻找数据背后的逻辑。BI的价值是提升管理的精准度,通过数据构筑一个企业管理模型。

BI系统实施的最大能力就体现在如何梳理管理逻辑,帮助企业可视化展现管理模型与管理的精细度。

3、主数据定义的一致性问题,用户经常反馈业务系统与BI数据报表中相同维度的数据会出现的一些差异,导致大家对BI数据的信任度严重下降。

综合上述调研的问题,项目组征得公司信息决策委员会的同意,于2012年8月启动了第二期的BI系统实施,项目组经过商讨决定改变实施思路,先暂停技术性工作,首要任务是进行公司的数据治理。

三、那么数据治理要怎么开展呢?

第一个就是主数据的治理,也就是说企业经营管理过程会用到哪些主数据?这些主数据是如何产生、如何进行分发、会标记哪些维度形成派生主数据?随后在BI中单独搭建一个主数据中心库,抽取业务系统的主数据按照分类原则存放,并开发主数据一致性校验程序与主数据分发日志表。

第二个是指标的梳理,建立指标体系,定义每个分析过程中的使用的业务指标,建立评价标准,以及计算方法,将业务管理逻辑进行更加直观的呈现,销售环节出现了数据波动就可以直观的呈现出来,通过指标的呈现,可以追踪哪部分业务发生的问题。

第三个就是规范数据产生的入口,以及数据取值的出口的标准。明确所有数据的录入产生的作业标准,建立各个系统到BI的接口规范,企业经营活动中产生的几乎所有数据都要进数据仓库,并由BI系统统一进行数据抽取与数据加工;

另外针对所有业务部、职能部提交的月度经营分析、月度绩效考核、年度关键考核指标、日常管理分析的全部数据需求进行综合评估分析,搭建相应的数据模型,要求任何所有应用数据都从BI系统取值,有了入口与出口的规范才能保证数据的一致性与唯一性。

四、完成上述三个动作后由项目组协同企管部门编撰公司数据管理制度,进行全公司范围的发文,数据管理制度定义了主数据产生、指标体系的结构与算法、数据录入与输出的标准等,是一项公司完整数据管理规范。

发文同时还明确了公司数据治理小组的组织架构与职能,治理数据小组有4种角色:

第一个是数据操作员,是业务部门的操作人员,主要发起主数据的调整、BI系统的维护、指标体系的修改申请等等;
第二个是数据审核主管,往往是部门领导。每个数据是由不同部门负责的,首先由数据操作员提出第一级的申请,其次是数据负责的部门进行审核。
第三个角色是数据的分析员,他对数据审核主管的审核进行分析,看修订的要求是否合理?是否影响其他主数据、指标和数据模型。
第四个角色是BI系统的管理员,经过审批审核后修订要求必须由系统管理员操作才能进行调整。即使这样每隔一个时段还是会有很多业务指标需要调整,比如新的业务出现或是新业务发生变化,甚至要调整公司组织架构,这个流程申请就是项目管理形式进行。
公司OA中也配置相应的三个流程,一是主数据的修订流程、二是管理指标和KPI指标调整的流程、三是报表优化的流程。通过数据治理实施过程,IT团队的数据中心部门基本实现公司数据的统筹工作,整体上也形成了PDCA的循环。

五、数据治理进行了一个月时间后,项目组又重新针对BI系统进行了优化,关键点有以下几个:

梳理业务分析体系:先从纯业务角度总结和梳理,分析各个业务中的流程和思路、常用角度、导向、评价标准,以及业务背后的原因。此体系的建立,是业务分析的总览,也是业务流程环节的真实需求,为后续的指标体系、系统实现打下基础,同时在业务分析体系建立的过程中,收集分析业务、数据的痛点和需求。

重新整理分析需求:根据收集的需求,业务分析的流程和思路,以及系统中的报表进行匹配和提炼,形成新的分析需求。

针对公司零售业务的变化特性,以月度为单位记录业务调整导致的指标比重系数发生调整和变化的历史数据,比如新店变成次新店、次新店升级为老店的时间维度差异。

将指标体系的业务管理逻辑进行更加直观的呈现,销售环节出现了数据波动就可以直观的呈现出来,清楚的知道到底是哪部分业务发生的问题。

更加细致精准划分管理层级的数据展现,针对业务操作层的用户也可在日常应用、周度汇报、月度绩效、年度关键指标上进行数据的直观呈现,所见即所得,虽然开发工作量增加,但是用户体验直线上升。

六、公司的管理理念也发生了深刻的变化,从上至下不再用定性的语言表达,形成了用数据说话习惯。当管理维度与经营业务发生变化的时候,也形成了通过数据治理体系来进行相应修订调整的习惯。

IT团队的数据中心部门设置5个岗位,数据中心经理负责管理工作,数据分析师负责数据模型的设计以及指标的分析,有两个BI系统开发师负责数据仓库维护与数据模型开发,一个H5开发工程师负责移动端开发。

七、从整个BI项目的实施价值上来讲,有这样几点内容可以分享:

从公司经营决策者角度来讲,通过驾驶舱可以快速看到企业的业务全局,及时掌握公司的经营状况,通过数据钻取透视看到整体业务的变化过程。经营层面出现的任何问题,都能透过数据预警反馈到业务管理逻辑上,也非常容易找到关联的业务动作,也就是哪些业务出现了问题。

管理者透过驾驶舱与关键考核指标组合报表可以快速阅读自己的KPI指标以及关注和的经营指标的变化,因为每个管理岗位应该关注的什么内容在体系上梳理很清晰了。

数据仓库,通过建立数据仓库,进行企业的数据治理,将企业的数据打通,形成可以分析和复用的数据资产。

整个操作层用户的工作效率提高了很多,大家都在一个频道,用同一种数据来源做汇报,再也不需要像过去需要临时加工一些乱七八糟的报表了。

BI系统第2期的实施大大丰富了IT团队的知识结构,尤其是数据中心团队的归纳总结、分析问题以及对公司主营业务的认知和理解能力有很大进步。

也让业务部门清楚地认识到IT对企业管理的价值,更加配合今后信息系统的实施与部署,IT部门的影响力得到了直观体现。

直接来源地址:https://www.toutiao.com/i6894172975424078340/

人民检察院单位简称规范建议

一、单位简称首位,为该省、直辖市地区简称,与92式民用车牌省、直辖市简称一致。

二、单位简称第二位,为地级市、县(县级市)、直辖市的市辖区地区简称,本级简称冲突由省级院负责调整,报高检批准;直辖市的分院,统一采用“京一分检”格式;各省的铁路分院,统一采用“云昆铁分检”格式。

三、单位简称第三位,为地级市的市辖区院地区简称,本级简称冲突由设区的市级院负责调整,层报上级检察机关批准。

全国检察机关统一业务应用系统关联案件提案同一及互斥规则配置表

被提案件 新案件 规则
提前介入案件 审查逮捕案件(适用于捕前介入) 同一规则
立案监督案件 审查逮捕案件(适用于监督后报捕) 同一规则
审查逮捕案件 提请批准延长侦查羁押期限案件 同一规则
审查逮捕案件 提请批准重新计算侦查羁押期限案件 同一规则
审查逮捕案件 侦查活动监督案件 同一规则
审查逮捕案件 一审公诉案件 同一规则
提前介入案件/立案监督案件(未报捕) 一审公诉案件(诉前介入,直诉) 同一规则
一审公诉案件 证据合法性调查 同一规则
一审公诉案件 发回重审案件 同一规则
一审公诉案件 法院决定再审 同一规则
审查逮捕案件 立案监督案件(适用于办案中发现) 同一规则
审查逮捕案件 (不)批准逮捕申诉案件审查 互斥规则
审查逮捕案件 不逮捕复议案件 互斥规则
立案监督案件 立案监督复议 互斥规则
侦查活动监督案件 侦查活动监督复查 互斥规则
一审公诉案件 不起诉复议 互斥规则
二审抗诉案件 撤回抗诉复议 互斥规则
不逮捕复议案件 不逮捕复核案件 跨院不涉及
不起诉复议 不起诉复核 跨院不涉及
一审公诉案件 撤销(不)起诉 跨院不涉及
一审公诉案件 二审抗诉案件 跨院不涉及
一审公诉案件 二审上诉案件 跨院不涉及
立案监督复议 立案监督复核 跨院不涉及
提请批准延长侦查羁押期限案件 批准延长侦查羁押期限案件 跨院不涉及
提请批准重新计算侦查羁押期限案件 批准重新计算侦查羁押期限案件 跨院不涉及
立案监督案件 商请督促立案监督 跨院不涉及
一审公诉案件 审判监督抗诉案件 跨院不涉及
侦查活动监督复查 侦查活动监督复查结果的审查 跨院不涉及

统一业务应用系统自动轮案功能优化建议

为适应司法责任制改革,全国检察机关统一业务应用系统升级了自动分案模块,实现了“随机分案为主、指定分案为辅”的案件承办确定机制。全国检察机关内设机构改革后,为适应捕诉一体等新的需求,自动轮案功能还有很多值得改进的地方,需要持续优化升级。

一、轮案规则

(一)组间平衡

当前,统一业务应用系统无法实现一名检察官在多个轮案组之间的办案数量均衡,轮案组设置越多,轮案均衡性越差。举个例子,内设机构改革后,基层院基本没有独立的未检部门,一般办理未检案件的检察官在一部,由于未检案件数量相对较少,员额相对紧张,所以,专门办理未检案件的检察官可能还会办理普通案件。按照现有规则,该检察官会加入普通轮案组和未检轮案组进行轮案,普通轮案组的轮案比例可能会略低一些。问题是:未检案件与普通案件的比例不是固定的,没有办法设定一个科学的普通轮案组的轮案比例。所以,组间平衡就非常重要了。本例中,将普通轮案组和未检轮案组设置为“组间平衡”,当检察官在未检轮案组分配一个案件后,普通轮案组自动轮空,停止一轮分案,确保其有足够时间审查案件,也保证办案的均衡性(否则,办理未检案件的检察官相对办理普通案件的检察官就多办理1件案件)。

(二)批量分案

当前系统是针对每件案件从轮案组中随机抽取一个办案团队(检察官办案组或者独任检察官)来承办的分案方式,不能一次批量分案。以业务量较大的检察院的一审公诉案件为例,可能在3天内陆续收到6~9个案件,每轮随机分配1个案件,所以案件可能不在同一天分配过来,由于告知、换押必须在3日内,致使检察官需要频繁往返看守所。特别是案多人少矛盾突出的部分检察院,为提高办案效率,提出了批量分案的需求。建议系统修改为既支持每件案件随机分配,也支持一批案件随机分配。案件管理部门或者业务部门某天统一登记受理多件案件后,可以每次2件或3件的方式一次性的批量分配案件,方便检察官合理安排时间赴看守所批量处理告知、换押等事宜。

二、轮案条件

(一)刑事案件专业类型

刑事案件专业类型是内设机构改革后的一个重要概念,会用于案件分配、案件查询、动态案卡项等具体场景。以未检“业务”为例,由于1.0架构不支持动态案卡项,迫不得已将未检作为“业务”处理。实际上,内设机构改革后,应当不存在未检“业务”,而是未检刑事案件专业类型(普通、重大、职务、经济、罪犯又犯罪、未检)。系统的案件流程应当通过事项、动态案卡项等具体设计,适应检察机关多种改革叠加对业务敏捷性的需求。系统通过同一个流程,同时适应普通刑事案件、重大刑事案件、职务犯罪案件、经济犯罪案件的需求,同时适应未成年人犯罪案件和罪犯又犯罪案件的需求,满足个性的办案需求和信息采集需求。否则,随着专业化建设的深入,刑事检察业务会面临分崩离析的危险(比如:职务犯罪检察部门完全有理由提出新建“职务犯罪检察业务”)。

言归正传,在轮案规则配置的“属性设置区”中,系统应当支持通过“刑事案件专业类型”来进行分流、分配,至少能够方便部门设置和高检院一致的检察院能够快速设置分流分配规则。

(二)案卡项条件

当前,统一业务应用系统只是提取案件受理向导中的数据信息来组合设置自动分案条件,无法满足实际条件时就用案件特性标签来解决,虽然这一定程度上可以实现随机分案,但也造成了一方面案件特性标签繁多,前台受案人员不好判断,另一方面随机分案智能化程度较低的问题。比如十厅设置了不服检察机关处理决定重大疑难案件轮案组,重大疑难的标识是“人大代表交办的不服检察机关处理决定的案件……”,是否人大代表这个数据项可以在分案前的案卡填录信息中获取到,但是系统只能提取案件受理向导中的数据信息,造成只能依靠受案人员人工判断来添加案件特性标签。

建议将系统分案条件提取数据信息的时间延后至案件分流前,这样既可以提取案件受理向导又可以提取案卡数据信息,分案条件支持按照案件类别进行扩展,各地提交需求后经高检院审核后统一发布,组合成灵活多样、满足实际的分案条件,减少人工干预,达到分案智能化。

三、同一规则

《人民检察院刑事诉讼规则》第八条为同一规则提供了法律依据:

第八条 对同一刑事案件的审查逮捕、审查起诉、出庭支持公诉和立案监督、侦查监督、审判监督等工作,由同一检察官或者检察官办案组负责,但是审查逮捕、审查起诉由不同人民检察院管辖,或者依照法律、有关规定应当另行指派检察官或者检察官办案组办理的除外。

(一)跨院问题

同一规则就是解决某件案件确定由办理过前面某案的同名检察官来承办的问题。当前系统适用同一规则的前提是两类案件存在提案关系。以市级院办理二延为例:市院的提请延长侦查羁押期限案件,是通过提取下级院的提请延长侦查羁押期限案件(而不是提取本院的批准延长侦查羁押期限案件)建立。所以,即便本院新建了批准延长侦查羁押期限案件→提请延长侦查羁押期限案件的同一规则,当前系统是不能生效的——因为没有直接的提案关系。所以,问题的关键在于,同一规则需要突破本院限制,站在全局角度以统一受案号来考虑同一规则。

(二)同一规则优先和专业化优先的问题

同一检察院内,当“捕诉一体”原则和“专业化分工”原则发生冲突时,以什么原则优先?目前高检院尚无明确意见。但目前系统只支持专业化分工优先。如果高检院明确“捕诉一体”原则优先或者将决定权交由地方自行确定,系统将无法适应。举例:犯罪嫌疑人以故意伤害罪报捕,根据专业分工,案件自动分流至普通犯罪检察部门办理,该案移送起诉时,罪名变更为故意杀人罪。如果是“捕诉一体”原则优先,那么该案应当根据同一规则分配至一部原审查逮捕案件承办检察官而不是根据专业化分工进入重大犯罪检察部门随机轮案。类似问题还有“诈骗罪”(普通)-“合同诈骗罪”(经济)等典型情况。

四、优化不在位管理功能

实践中检察官因案件复杂程度、工作量等原因需要少办几件案件,往往也通过不在位登记来变相实现暂停轮案。建议系统将此功能细分为:中止轮案和暂停轮次两种。

(一)中止轮案申请(不在位申请)

中止轮案以起止时间登记。中止轮案申请主要针对检察官本人不在位情形,一旦申请检察官不在位,其参与的所有轮案组均不应当继续分案,故中止轮案申请(不在位申请)界面不用过于复杂,仅需选择其不在位起始日期、结束日期、中止轮案(不在位)原因等。系统应当支持上传不在位依据(请假条、文件等)。

(二)暂停轮次申请

暂停轮次以某轮案组或全部轮案组轮次登记。因工作分配、案件强度不一致等原因,导致检察官在法律时限内完成案件办理有一定难度的,检察官可申请在某些或所有轮案组申请暂停轮案一轮或多轮。

以上仅是实践中的典型问题,需求素材来源于基层。需要进一步加强需求调研、需求统筹工作,方能保持统一业务应用系统长久持续的生命力,成为检察官喜欢的不可或缺的系统。

 

直接来源地址:https://mp.weixin.qq.com/s/iRQgl9j7-dK_ILsuXJti8Q

关于侦查/审判阶段羁押必要性审查案件流程的规范使用和需求建议

统一业务应用系统1.0版执检业务下的“羁押必要性审查案件”,是检察机关对办案机关办理案件的犯罪嫌疑人羁押必要性进行审查的案件流程。内设机构改革后,原执检部门办理的羁押必要性审查工作由刑检部门办理,此次1.5版升级后,在刑检业务下新增了“侦查/审判阶段羁押必要性审查案件”。关于该流程的使用,提出以下理解和建议:

一、【诉讼监督职能】“侦查/审判阶段羁押必要性审查案件”承载的羁押必要性审查工作,是狭义的羁押必要性审查。羁押必要性审查的主体是人民检察院,时间为犯罪嫌疑人、被告人被逮捕后,人民检察院履行职责方式是向办案机关(公安机关、人民法院)提出释放或者变更强制措施的建议。(袁其国,《人民检察院办理羁押必要性审查案件规定(试行)解读》,人民检察,2016年第5期)如果案件刑事诉讼环节仍在检察机关,不应当新建“侦查/审判阶段羁押必要性审查案件”,自己给自己建议没有意义。目前统一业务应用系统1.5版刑检业务下的“侦查/审判阶段羁押必要性审查案件”,只适用于刑事诉讼规则第五百七十五第一款,对“依法对侦查和审判阶段的羁押必要性进行审查”(办案机关非检察机关)。

  第五百七十五条 负责捕诉的部门依法对侦查和审判阶段的羁押必要性进行审查。经审查认为不需要继续羁押的,应当建议公安机关或者人民法院释放犯罪嫌疑人、被告人或者变更强制措施。

审查起诉阶段,负责捕诉的部门经审查认为不需要继续羁押的,应当直接释放犯罪嫌疑人或者变更强制措施。

负责刑事执行检察的部门收到有关材料或者发现不需要继续羁押的,应当及时将有关材料和意见移送负责捕诉的部门。

二、【诉讼职能】案件尚处于审查起诉阶段的(办案机关为检察机关),即便收到了所谓的“羁押必要性”审查申请,也不应当创建“侦查/审判阶段羁押必要性审查案件”,严格来讲,应该通过辩护与代理业务中的申请变更(解除)强制措施方式的一种情形进入系统。由此,衍生出之前提出的需求,辩护与代理案件化或流程化的需求。应当适用新刑事诉讼规则第一百五十一条相关事项时限:

  第一百五十一条 犯罪嫌疑人及其法定代理人、近亲属或者辩护人向人民检察院提出变更强制措施申请的,人民检察院应当在收到申请后三日以内作出决定。

经审查,同意变更强制措施的,应当在作出决定的同时通知公安机关执行;不同意变更强制措施的,应当书面告知申请人,并说明不同意的理由。

犯罪嫌疑人及其法定代理人、近亲属或者辩护人提出变更强制措施申请的,应当说明理由,有证据和其他材料的,应当附上相关材料。

对承办检察官而言,依申请或者依职权对犯罪嫌疑人的强制措施进行审查,正确拟制相关文书(以高检院最新规范为准),并及时、准确填录“案件办理及审结情况”→“决定强制措施情况(强制措施审查情况)”、“羁押必要性审查”两张案卡。

三、目标考核相关问题。由于羁押必要性审查工作办理部门和工作模式发生很大变化,所以各地检察机关制定本项工作目标时(比如“羁押必要性审查建议被采纳予以释放或者变更强制措施人数达到批准逮捕人数的比例”)应当考虑具体工作情况,不能简单沿用之前的考核指标。另外,由于“羁押必要性审查情况基础表”没有配套升级,建议各地检察机关明确考核方式,不简单依赖统计案卡,可以考虑实际发出的《对犯罪嫌疑人、被告人变更强制措施(予以释放)建议书》的数量和质量(应当同步验证送达回证回传情况和办案机关采纳情况)。

以上是对统一业务应用系统1.5版规范使用的理解。

以下是关于广义羁押必要性审查案件的受理问题的需求建议(目前尚未实现在统一业务应用系统中)。

四、需求建议

刑事诉讼规则第五百七十五第三款“负责刑事执行检察的部门收到有关材料或者发现不需要继续羁押的,应当及时将有关材料和意见移送负责捕诉的部门。”由于派驻羁押场所检察院和办案单位或办案单位对应检察院不完全一致,系统应当给检察机关执检部门提供无差别的广义羁押必要性审查案件的受理途径,系统根据该犯罪嫌疑人关联案件的办案单位自动流转:

(一)【诉讼监督职能】如果当前案件办案机关非检察机关,则自动流转至办案机关对应的检察院,根据专业化分工进行自动分流至负责捕诉的部门,部门内勤接收并创建羁押必要性审查案件。

(二)【诉讼职能】如果当前案件办案机关为检察机关,则自动流转至对应的检察院案件管理部门,纳入“辩护与代理”流程。

关于受理,实践中还比较复杂,不考虑办案机关属性问题,除了执检部门会收到相关申请外,控申部门、案管部门均可能收到,是在系统中统一考虑,还是在线下移交,均需要具体业务规范和系统实现。

 

直接来源地址:https://mp.weixin.qq.com/s/oLEXDlZQDdfY21OHza2m-Q

统一业务应用系统基础之关系单位管理

一、问题引出

市级案管部门的同学可能会遇到这样一种现象:在进行流程监控时,发现下级院某案件没有填录“侦(调)查机关”和“侦(调)查机关类别”,打电话通知下级院案管部门,下级院大呼冤枉,他们自己看是正常的,绝对有填录,然后给市院的同学来个“有图有真相”。

二、问题分析

事实上,这是统一业务应用系统设计的一个“痛点”。统一业务应用系统的前身是深圳市院研发的,当时也没想着拓展全国,就把关系单位纳入了“本院代码管理”,这是什么意思呢?这代表着每个检察院都要去收集和配置公安、国安、海关、监委、检察院、法院、监狱甚至部分行政机关的关系单位名称、关系单位代码等。实践中,每个检察院的配置标准不一、代码不一、完整程度不一,上级院用户在查询下级院案件时,此处的关系单位代码“翻译”为关系单位名称时使用的“码表”是上级院用户单位的。当下级院和上级院配置不一致时,下级院的关系单位代码在上级院的“码表”中找不到对应项,就显示为空,甚至,如果上下级院的相同代码配置了不同的单位,就会出现下级院填录的是“某某公安局”,上级院显示“某某监狱”的情况。

这是统一业务应用系统经典的“老问题”。实践中,为了避免这种情况,市级院案管部门会履行统一业务应用系统管理职责,辖区内新增关系单位的管理由市级院案管部门负责,统一调研、统一标准、统一配置。统一管理自然是一种办法,但还是应该从根本上进行解决。

三、问题拓展

(一)侦(调)机关内设、派出机构配置问题

在大数据和人工智能的今天,很多检察院特别是基层检察院,亟须细化关系单位,比如:虽然是成都市公安局东部新区分局移送的案件,希望能够细化到派出所,比如是“养马派出所”的,还是“草池派出所”的,如果完成此类采集,就可以将整个东部新区的发案情况,细化到乡镇一级,进行更加精准的数据分析研判。

但是,统一业务应用系统1.0中,侦(调)查机关案卡项绝对不能擅自添加派出所,因为很多文书是直接调用该案卡项,如果受案时选择派出所,文书内就会出现不适格的单位名称。

(二)受理向导侦(调)机关填录问题

实践中,有些单位创建立案监督案件时,如果立案监督案件类型选择的是“监督行政执法机关移送案件”,会在受理向导中的侦(调)机关中错误的选择对应的行政执法机关!注意:侦(调)机关就是刑事案件的侦查机关(如公安、国安)、调查机关(监察委),普通行政执法机关的调查不属于此处的“调查”。比如立案监督案件(两法衔接),是在两法衔接案卡的行政执法机关类别、行政执法机关名称处填录!

(所以对于受理向导的升级建议,一是受理向导的侦(调)机关读取关系单位配置时,只显示侦查机关、监察机关;二是具体到立案监督案件这种流程向导,一旦选择立案监督类型是“监督行政执法机关移送案件”,在受理向导处即新增行政执法机关类别、行政执法机关名称的采集项。)

四、需求建议

建议统一业务应用系统实现统一的关系单位管理!

统一业务应用系统内的关系单位不再纳入“本院代码管理”,由高检院统一规范、分级管理。系统包括侦查机关、监察机关、审判机关等,以及执检业务相关的监狱、看守所等,辩护与代理业务相关的律师事务所等,都使用统一关系单位进行管理。

系统内关系单位编码使用全国组织机构统一社会信用代码,关系单位名称为正式全称,关系单位类别、类型高检院统一制定。关系单位的内设机构、派出机构,由对应的检察院负责收集、核对、管理,对全国适用。

为提高工作效率,系统内调用关系单位的案卡项时,默认显示本院本级对应的机关,支持逐级扩选、支持快速查询。

系统增加侦(调)机关内设、派出机构的案卡项(不作为必填项),有需求的单位可以在受案时细化,便于后期数据分析研判时使用。

直接来源地址:https://mp.weixin.qq.com/s/vr1g2_6LWNOHUvmK4beEFw

关于案卡和系统,来听听案管部门的声音(CU检)

CU检说法

昨天,推送了一篇题为《关于案卡和系统,可以开一场三天三夜的吐槽大会》的文章。

文章推出后,引起了很大的反响。截至目前,后台已经涌入了835条留言。

但由于微信公众号只允许放出100条留言,所以还有很多评论无法放出,也请大家理解。

昨天文章里的很多内容,都来自于微信群内的聊天,有些问题没有经过核实和验证。

今天在跟案管部门的同事们经过深入的交流之后,发现有些是片面的、错误的。

虽然CU检说法是一个自媒体,但也要遵循客观、公正的传播要求,要尽可能地尽到核实求证的义务。

所以,首先要向案卡和系统的设计者,以及案管部门的同志诚挚地道歉。

在看了昨天那篇文章之后,尤其是看了评论区的留言之后,案管的小伙伴们表示很受伤,也很委屈。

他们也希望能有机会就文章中提到的一些槽点,以及对案卡、数据统计、以及统一业务应用系统谈谈自己的看法、意见。

正所谓:“兼听则明、偏信则暗。”因此,今天就将案管同志的意见在这里发表出来,让大家也能听到关于同一件事不同的声音:

 

一、关于昨天文章中提到的问题

A

1.不是所有空案卡都需要填上是否,只有很少一部分作了必填控制的是否项案卡需要填录,否则可以空着,这种情况等同于“否”。

2.从最近几次补填案卡的情况来看,对于已经办结的案子,除非在补填范围内,且必须填录为是的,否则是不需要补填的。

3.手工统计的数据大部分都是系统内未填录过的内容,大统一内填录的内容大部分都能通过不同的查询或者分析模块统计到,当然统计不到可能是因为你不太会使用系统。

4.每个项目的设计都经过高检研发人员多次的讨论,都有相应的填录标准,如果觉得标准不清或者不对的,完全可以层报高检进行修正。

5.对于看不到自己以前办理的案件,那完全是系统后台权限配置没有到位,不是大统一设置内设机构改革故障问题。

6.一案多人有诉有不诉或者撤回的,每个人的文书都是单独拟制审批的,个人案卡也是单独的,办案至今没有听说有没法审批和案卡没法填录的情况。

B

总体而言,信息填录负担重是客观的。文中相对客观的说法有:是否项较多,填录负担重,特别是案件有关情况案件中的专门调查项目。

1.文中认为应当把所有是否项都默认为“否”以减轻负担。但客观地讲,只要系统自动默认成“否”,很怀疑有多少承办人会去自觉、主动修改为“是”,并且这是在实际工作中证明了的。

而之所以设计默认为空,并在某种条件下必填,就是为了解决承办人不愿意填录的问题,以及压实填录责任。

至于文中列举出的“是否人大代表”、“是否政协委员”本身就是默认为“否”的。而且系统中没有文中列举的“是否民营企业家”项目。

2.文中认为一案如有N人,是否项的填录工作量就得是N人乘以57个是否项。

我们估且不论其中不少是否项只设计在案件表单中,一个案件中只填录案件表单即可,不存在都要乘57的夸大问题,并且即使部分是否项设计在嫌疑人案卡中,本也是实现以人为单位进行调查,一案多人每个人的情况不一致,当然需要分别填录。

3.非公经济、扫黑除恶、三大攻坚战、涉民营企业、涉疫情等,多属于检察机关落实国家政策要求的专门调查内容,经济在发展,国内、国际形势在变化,

检察工作重心随时在调整、适应,数据需求、数据调查当然要同步跟进,不仅案件信息、数据的采集要跟进,承办人本身的办案难道不需要适应政策性的要求吗?

4.如果新增的是否项设计为必填,升级后对于已经办结的案件(流程结束甚至已归档),承办人如果只是要查看一下原案件,系统是不会要求承办人补填“否”的!

当然,如果仍为在办案件或者回退流程结束节点并激活案件,则需要补录。这个现象,是系统设计技术因素,系统在技术上是否能实现新增项目不涉及已办结的既往案件,需要专门研究。

同时,每次新增的项目,都是经过部门研究后决定的,而且要对一段时期以来的案件进行调查,项目的改造一定是滞后于相关制度或政策性要求的。

升级项目后,势必需要就一段时期以来的案件进行补充调查,这是决策、管理的客观需要,不是为了和承办人过不去、找麻烦。

5.文中认为“填报了那么多信息,需要统计时还得靠手”。这恰恰说明信息调查、统计数据是滞后于决策、管理需求的,不可能把所有数据需求都事先预设成系统项目信息。

上级院的数据、信息需求是多元的,都是为了服务于管理和决策。承办人一边在叫喊着案卡信息填录负担很重,一边却对不需要填案卡只要求填报表叫苦不停,只能说明不愿填、不想填,认为填录不是办案,认为管理是案管的事,决策是领导的事,与承办人无关。

6.文中提出的单位犯罪年龄为0分案的问题确实存在,属于系统简单改造问题。

7.文中提出的民营经济、非公经济问题定义问题。民营经济至少在目前系统中没有此项目,非公经济属于政策性概念,高检院也下发了填录标准,承办人不去学习文件只吐槽。

8.精神病鉴定开始日期填写后,系统会暂停计算审查起诉期限,填写精神病鉴定结束日期后,系统恢复计算审查起诉期限。根本不存在吐槽所说情况。

9.至于卡顿问题、升级问题,客观存在,只能通过技术升级、加强管理来实现。

10.系统中的项目,确实存在只做加法,减法做的少或没有做的现象,剖分项目存在的逻辑性问题,属于历史项目、新增项目之间的统筹改造问题,需要通盘研究处理。

11.系统项目智能化填录问题,需要技术有突破,也需要实践中去完善,即使在2.0版本中,也不可能解决全部案卡信息的智能化填录问题。

 

二、关于评论区吐槽的问题

CU和评论区一水的吐槽可以归结为三类问题:

一类是对系统运行效率等硬件的吐槽;二类对系统操作设计不够优化的吐槽;三类对系统操作和项目含义的问题。

综合来看,绝大部分吐槽或问题是对系统操作流程不熟悉不了解引发的误解,部分问题实际是最基本最基础的系统操作或业务程序问题。

相信对系统稍有了解的人应该不会有这种误解。不太确定这些问题是哪地的检察官或检察官群所说,但这种吐槽反而占据大部篇幅,所以反面也说明当地对系统的基础培训可能还需要进一步加强而不是减弱。

希望CU可以全面搜集各类这种问题,并分门别类处理:

一是对于操作类和程序类问题统一编发系统常见问题100问或答疑之类的;

二是对于系统设计优化问题进一步上报,以期系统升级改造更加契合基层承办人需求。

最后一句:没有调查就没有发言权。

 

三、关于压力和辛苦的问题

1.承办人只要对自己的案卡负责,数据管理员要对全院的案卡负责,每个月底对照着185个核查点审核案卡是怎样一种体验,CU检要不要来统计群感受一下眼睛看瞎,电话打爆,嘴皮子说破,最后案卡还是错了,被通报,年底扣案管的分数,心碎……

2.每个检察官填的案件信息是一个个“细胞”,总公司汇总的信息是一个个“有机体”,“有机体”是否正常仰仗着“细胞”的健康,当总公司需要数据分析的时候,需要准确的“有机体”数据,这个准确的数据一方面依赖承办人辛苦的填录,另一方面也少不了数据管理员们眼睛都要瞎了一样的核查,大家都不容易,相互理解。

3.作为一名案管人员,承载了太多,不断加厚的眼镜片,案卡内容不断在增多,系统不断在升级,但检察官只用填自己的案件,还有助理帮忙,可案管人员要一个一个,一项一项看完所有案件案卡,同时还要承受大家的吐槽和不理解……

承办人看到的只是一个一个的必填项,但在这背后是庞大的数据库,是一个个让人又爱又恨的天使与恶魔化身。承办人不易,案管人员更不易,且行且珍惜。

好了,以上就是来自案管部门的同志的声音,受到版面的限制,就暂且放出这么多吧。

其实,案管部门也是案卡和统一业务应用系统的使用者,他们和一线的承办检察官一样,也承担着巨大的工作压力,也希望软件更好用、统计更便捷。

正如一些案管的同事所说:

不管是案管还是业务部门,最终的目标都是规范案卡填录和检察数据,只有齐心协力,才能进一步提高办案质效,也希望在2.0系统中能看到更智能更完善的案卡填录和数据使用模式。

历史的车轮滚滚而来势不可挡,信息化的发展带来的阵痛必须承受,我们要有足够思想准备,对社会进程中已经出现和可能出现的问题,困难要一个个克服,问题要一个个解决。

我们应以积极的心态来应对系统升级更新,要坚信道路是曲折的,前途是光明的,而不是一味抱怨、退缩,唯有联合起来团结一心,才能更快的克服当下的困难。

当然,对于业务部门检察官的吐槽和怨气,也希望案管的同志们能多一些理解。

一线承办检察官填报案卡的压力很大。关于这一点,是业务部门和案管部门同志的共识。

业务部门的同志之所以会意见那么大。是因为在案件法定办案期限没有增加,人员没有增加的情况下,他们要承担的工作量比以前增加了太多。

而当现有的软件无法在节约时间、提高效率上提供帮助,甚至会增加他们的工作量时,他们自然会有抵触的心理。

但正所谓:责之深,望之切。他们不是不愿意填报案卡,在做好案件的同时做好数据的填报工作。

他们只是希望能有更加智能、更加便捷、更加好用的工具。

业务部门的同志也要和案管部门的同志多交流,多反馈。其实他们很多时候也默默地为你们做了很多。

今天,读到了一篇题为《共建巴别塔,而不是被变乱了口音》的文章,更加深入地了解了统一案件业务应用系统研发背后的故事。

最后一句:吐槽不是目的,发现问题并促使问题得到解决才是意义和价值所在。

 

直接来源地址:https://mp.weixin.qq.com/s/B7lB3rD7fdYxDWvgRmV2lw