我所知道的富士康之二:出门
发布于 2024-10-02
1208
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
文章摘要侧重于作者对富士康安检流程的亲身经历和感受。作者描述了富士康出门时的安检过程,包括手持设备检查金属物品,对移动存储介质、相机等的审查,以及对大包包内容的检查。尽管原则上禁止带摄像头相机进出,但实际执行并不严格。
作者提到了对门卫进行安检方式的不满,如门卫伸手检查包内物品,而后经与内部员工沟通了解到这种做法是不恰当的。在一次被查到误带数码相机的经历中,作者体会到了解决问题的繁琐。
文中特别强调了携带电脑出门的复杂检查流程,要求IT人员检查编辑过的文件,确保没有敏感内容。作者还分享了因频繁检查而与检查人员建立起的友情,以及在不同地点偶遇熟悉工程师的趣事。整个检查过程可能需要20-30分钟,还需要主管签字才能放行,体现了富士康的严格安全管理。
最后,作者提到了一个不常用但较为便捷的出门方式——乘坐轿车离开,这样通常只需简单检查后备箱。作者通过与其他机构的比较,认为富士康的资安管理是相对严格的。文章以对入门和出门效率的感慨作结,认为虽然电子化使得进入效率较高,但出门效率稍显不足。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 634K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
读<软件工程的事实与谬误>所得
买这本书,纯属偶然,完全是为它的名字所吸引,随手翻了一下,看了其中描述的几个事实,觉的有收获,值23元,就买了.买了后,一直没有读,频于准备讲课,盯项目. 偶然地,某天顺手拿了这本薄书,读了几个事实,真是好书! 道出了现实! 昨天终于在火车上读完了一书,感触比较深的有下边的13条事实: 1 在软件工程的三要素(人,过程,技术)中,人最重要。 2 最好的程序员要比最差的程序员强28倍之多,而
项目管理的三架马车
决定项目成功的核心角色是什么?我认为是三个角色:项目经理、技术经理与需求经理。
项目经理:解决管理上如何做的问题,对项目的进度与质量负责。具体职责包括了:过程定义、估算、计划制定、计划跟踪与控制、风险管理、质量管理等。
技术经理:解决技术上如何做的问题,对项目的技术方案负责。具体职责包括了:技术可行性的评估、技术方案的确定、设计、设计验证、技术难题的解决、实现等。
需求经理:解决做什么的问题,对项目的需求与范围负责。具体职责包括了:需求获取、需求分析、
为什么同事不能成为好朋友
昨夜,一位朋友给我电话,他大叹:“为什么同事不能成为好朋友!” 他在一家小公司做事,但是人际关系却很复杂,他是一个直肠子,很善良,很容易相信别人,也很乐意帮助别人。结果却发现别人利用他,为了利益,为了权力,他成了冤大头。初来咋到,有什么心事,他还和其他的同事说说,结果那些心腹话成了别人的攻击他,给老板打小报告的把柄。他很苦闷,于是要找我喝酒,找一个不会危害他的人诉说诉说。 这个问题,我也经
图解敏捷性能合弄结构APH之:valuing合弄
图一:valuing合弄的目的与性能等级图二:valuing合弄的活动各种敏捷方法的原则参见博客:https://blog.csdn.net/dylanren/article/details/87184790。 图三:valuing合弄使用的敏捷仪式和技术说明:为便于图形化表达,每种敏捷仪式或技术没有映射到具体的活动,敏捷活动与敏捷仪式是多对多的映射关系。 ...
高成熟度的软件估算应该是什么样的?
1 估算基础 1)对估算对象(需求、任务等)的拆分颗粒度定义了上限与下限,以提升估算的准确度。 2)完备识别了估算对象,没有遗漏的需求或任务。 3)估算人员经过了估算方法的系统培训。 4)定义了组织级的估算方法。2 规模估算 1)从不估算规模或经验估算规模升级为客观度量规模,比如采用国际标准的功能点方法或自定义的规模度量方法,无论是哪种方法,规模与工作量之间应该是强相关的才是合理的。 2)如...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线