下载文档原格式
生产现场管理规范1目的为了维护好车间生产环境，确保生产的产量、质量、安全均正常运作，特制本规范。
2使用范围本规范适用于工厂生产现场的管理。
3职责3.1一线人员：需严格执行本文件内容。
3.2线长：监督车间现场环境实施情况，负责对生产人员的日常工作进行管理。
3.3工艺员、车间管理人员：负责按文件要求对车间人员进行检查、监督。
4生产现场具体要求4.1生产车间要求4.1.1车间内应保持通道畅通；地面无积尘、地面防滑等杂物；4.1.2车间保持足够的空调通风环境和采光照明；4.1.3电线布置要符合安全规范，消防通道无堵塞，消防器材齐备；4.1.4产品制造过程中使用的工器具、原辅材料、半成品应遵循整齐、存取方便的原则，分类放置指定地点；4.1.5下班后各班组必须将杂物、垃圾清理出车间或置于指定位置，并整理、清扫地面；4.1.6每月生产人员须对车间进行彻底清理，如有必要可适当增加频次；4.1.7车间负责人须对新员工进行车间安全环境教育和班组安全环境教育培训；对员工进行经常性的安全环境意识、知识和技能教育；组织开展各项安全环境活动、检查、督促开展安全环境活动。
4.1.8车间内禁止出现任何管制刀具，若生产必须使用刀具，刀具露出的长度不得超过1cm。
4.2 人员管理4.2.1车间全体人员须遵守上下班作息时间，按时上下班。
4.2.2车间员工须服从由上级指派的工作安排,尽职尽责做好本职工作,不得疏忽或拒绝管理人员命令或工作安排。
4.2.3全体车间人员工作时间必须按公司要求统一着装，更换工作鞋或鞋套进入车间；员工正确着装，头发不外露，衣帽整洁，工鞋保持干净，做到勤洗勤换。
4.2.4生产人员上班前，须在生活区换穿工作服，戴工作帽；除生产车间人员外的其他人员进入车间，必须按规定佩戴好工作服。
在进入车间操作之前，所有员工必须把手洗干净，不得擦护肤品；不得佩戴戒指、手表等金属材质的首饰。
4.2.5车间人员禁止在工作期间不得做与工作无关的事,例如：吃东西,闲坐聊天,听歌,打瞌睡、玩手机等行为。
产品上线前的准备工作有哪些在前面经历了需求评审、进度跟踪、测试跟进之后，有的人会说终于熬到要上线了，可以松一口气了。
产品经理是要为产品的全生命周期负责的，上线只是刚开始，后面还有运营需要跟进，运营过程的用户反馈又可以持续的进行产品迭代，周而复始，良性循环迭代，才能把产品打造的越来越好。
不知道有没有小伙伴经历过那种只能在凌晨停机发布产品新版本的过程，有的话，很轻易的就能见到凌晨X点的XX地方，感触应该会很深。
特别是中间发布出问题的情况，需要紧急修复问题，再重新发布，过程会让人很紧张。
理论上上线发布应该是技术人员的事情，为什么产品经理也要陪着一起呢？一是产品经理需要对上线后的功能做线上验证，虽然有测试人员在把关，但还是很容易出问题的。
测试环境是好的，预发布环境也是好的，到了线上环境变的不好了，这种情况时有发生；二是产品经理责任心的问题，对你自己所设计的产品功能有多负责，一定程度上会决定你的行为。
有时候上线发布运营人员也会陪着一起，因为他们要关注功能上去之后会不会影响运营活动。
那一般产品上线前后产品经理都需要做什么呢？制定checklist，心里更有底在经历过测试环境、预发布环境的洗礼之后，产品经理应该会比较清楚哪些地方是容易出问题的。
所以说日常一定要跟进，否则你都不知道产品是怎么研发出来的。
把这些容易出问题的地方整理一下，再加上需求列表里面的核心几个功能，两者相加，可以整理出一份检查清单checklist。
这份清单主要用于上线前后的校验，可以和测试人员核对一下，然后在预发布环境做一次试点。
清单里项目不能太多，不能变成测试用例清单了，要抓住核心操作功能和容易出错的操作点。
可以基于用户实际操作的角度去罗列功能点，这样至少能保证上线后用户操作的过程没有问题，其他问题还可以事后补救，不影响用户使用。
上线发布结束后，测试人员会从他们的角度去验证功能，而产品经理就可以照着checklist去做验证，如果没有问题，心里悬着的石头也就能落地了，如果有问题，还可以当场协调技术人员修复。
1.0目的：降低生产线的换线工时损失，提高产能，并通过提升干部主管的管理技能，提升公司的市场竞争力。
2.0 范围：适用于天线事业部全部生产线。
3.0 权责与权限：现场班组长：快速换线具体实施责任者；现场主管：快速换线指导者；QC：协助生产上线后的质量监督和辅导；现场员工：掌握作业的标准，尽快适应；工艺工程师：现场指导，协助生产调整不合理工位；4.0 作业内容：4.1 清线前4.1.1PMC向生产提交生产计划，并确定物料状况；4.1.2由生产填领料单，仓库提前一天给生产备料（品质要对每款物料检验，且盖品质章）；4.1.3生产组长提前半天将物料对照BOM领出；4.1.4工程人员提前2小时制作成品首件，并交QC确认。
将正确的首件移交给现场组长；4.1.5工程人员准备工装，并检查确保可正常使用；4.2 清线作业4.2.1收回指导书，放入夹子，保存起来；4.2.2统一收回工装检具、气批等；4.2.3将剩余的物料统一回收，做上标识，统计数量，由品质检验后入库；4.2.4组长将制程中发现的不良物料进行统计，交给QC确认后，填写不良品单进行处理；4.2.5组长带领员工整理产线的5S。
4.3 清线确认生产部和品质部按照《清线checklist》进行核对，确保清线动作的完成。
4.4 开线前准备4.4.1组长先挂上SOP，然后安排员工到岗，仔细阅读《作业指导书》，熟悉操作；4.4.2按照对应指导书上的物料编码进行分发物料；4.4.3将物料盒和物料箱贴上编码，要与SOP完全一致；4.4.4组长按照SOP要求，按照对应工位分发工装、检具；4.4.5螺钉工位的气批、气批，必须有品质部校准标识；4.4.6在下工序要挂上工序的SIP，实现下工序检验上工序。
4.5 开线确认生产部和品质部按照《开线checklist》进行核对，确保开线条件全部满足。
4.6 开线生产4.6.1员工按照作业指导书要求作业；4.6.2工艺人员对员工进行逐个单工位讲解；4.6.3对于第一个产品流出开始，现场组长与QC对逐一工序进行检查确认，纠正员工操作与质量上的问题点；4.6.4现场组长必须每小时对生产线的产能进行跟进。
【超全】5年经验教训总结68条从立项到上线的checklist！编辑导语：一个新项目从立项到上线需要经历很长一个周期，期间也会遇到很多的问题，从需求提出到设计再到研究开发，需要清晰统一的目标和整个团队的协作；本文是作者总结的从立项到上线会遇到的问题清单，我们一起来看一下。
要把踩过的坑，转化为前进的奠基石。
无流程，不组织；对自己负责，对团队负责。
一、需求分析阶段需求类型，来自其他部门提出的需求：1. 反思点能不能一句话说清楚要解决什么问题？有没有其他更简单的解决方式？我理解这个需求背后真正的诉求了吗？我有对这个需求合理性的分析吗？我有对这个需求普适性的分析吗？2. 产品原有功能的优化迭代我全面了解原有的这个功能吗？原有功能的数据我分析了吗？存在哪些问题？我这次优化要解决什么问题？原有功能有哪些亮点和作用？我这次优化怎么保持和扩大？新的设计部分哪些可以复用原来的能力或者当前已经在开发的能力，避免重复开发？3. 从0到1的产品这个需求符合战略方向吗？我想清楚了为什么要做这个功能吗？这个功能的核心价值是什么？我需要做市场调研或者用户调研吗？怎么确认这是不是伪需求？我做了版本迭代规划吗？什么是这个产品的MVP？4. 参考/模仿其他业内产品或功能我深刻了解他们做的成功背后真正的原因了吗？我们用户群体和使用场景相似吗？我怎么弃其糟粕取其精华？5. 老板提的需求老板真正的目的是什么？老板有没有明确的时间要求？老板是自己的想法还是传达其他部门角色的想法？如果是后者需要了解清楚是谁的想法再具体去沟通二、需求设计阶段概念陷阱：我创造了新的概念吗？这个概念有必要创造吗？如果一定要创造我解释清楚了吗？准确描述：我准确描述问题了吗？如果把自己当做研发，从研发的角度看我们的需求文档，能完整理解需求吗？逻辑是否清晰：设计中的逻辑是不是严谨？业务流程逻辑有没有问题？功能描述逻辑有没有缺失？核心目的：设计结果有没有背离最初的初衷？是不是紧紧围绕我做这件事情核心目的？分享激励：我做了分享激励吗？分享是链接还是海报？我有时刻把获取新用户作为产品经理的使命之一吗？学科专业性（针对教育行业）：我有从学科专业性角度审视设计吗？我需要跟老师们沟通下给出建议吗？运营思维：我从运营角度反思设计了吗？这是一个静态的功能还是一个可运营的产品？关联角色的思考：有没有跟其他角色包括不限于运营、市场、创作部、客服、销售、服务、老师等角色沟通确认了，对他们的业务有没有影响甚至负面冲击？需求控制：我有没有把简单的事情复杂化了？哪些功能可能不应该放到1期？需求延展性：功能设计是不是有足够的延展性？下一次迭代是可以直接拓展功能还是要重构系统？忽略了入口：我是不是只处理了子页面的优化而忽略了入口？静默更新一些内容等着用户来发现吗？更新机制：以什么机制更新内容和数据？系统在一定周期自动更新？用户状态变更后再更新？运营手动更改配置更新？缓存机制：是否要提前缓存？需要缓存多少？自动缓存还是用户手动下载？版本兼容：我考虑了新版本功能在旧版本中不能使用的兼容处理吗？是两个版本采用不同的功能还是老版本提示用户升级的方式呢？数据兼容：我考虑了老数据兼容处理吗？老用户的年级、订购、会员等状态变更吗？用户体验：交互够不够不顺畅、提示文案是否太过技术化生硬难懂、icon能不能看懂、能不能记录用户的使用数据、保持上一次学习记录、用户等待时间是不是过长、空状态有没有文字提醒等保持上一次学习记录、用户等待时间是不是过长、空状态有没有文字提醒等。
转转交易全链路接口测试发展及扩展1.概述1.1.背景1.交易相关业务测试订单流很多、流程偏后测试与回归的重复工作量大，效率低；2.商品类型及订单状态多样，订单又包括红包、服务、活动等属性，全链路数据种类非常多，如被测需求发生在交易场景末端或者关联多种属性则数据构造需要操作很多步骤，效率很低。
3.业务敏感，需求上线需要反复的对基础业务进行回归。
1.2.目标1.测试前置。
在联调或前端提测前完成业务流程测试，让功能测试尽可能的只关于与前端交互。
2.抽离核心业务，作为环境检测、冒烟测试、上线前轻量级回归。
3.用例可视化，提供分享执行、定时执行功能。
4.提供数据构造，减少末端场景、复杂数据构造带来的效率损耗。
5.性能数据收集，多线程场景下并发量可参数化，为性能测试提供便利。
6.用例推荐，小需求自动提供用例，方便回归上线。
2.发展过程2.1.All In One1.接口测试最初应用阶段，没有成型的代码接口，为了快速响应需求，将所有代码集中在@Test方法中，包括服务初始化、测试数据构造、测试用例、测试结果校验。
2.2.公共方法抽离1.随着测试用例的累积，服务初始化、数据初始化相同的代码块重复出现，甚至校验方式出现大同小异的方法块。
一些请求参数封装，返回值的解析逻辑出现重复。
2.当重复的代码和类似的逻辑重复出现时整个测试项目便可以进行集成和重构抽象出初步的框架结构。
3.当抽离完成后用例编写更加高效用例对需求的覆盖程度提高，针对不同类型的项目或不同的被测主体出现几大类用例编写模式，如基于被测实体状态变化进行状态覆盖的状态类测试用例如订单流转与交易流程中商品的状态变化，基于业务流转进行分支覆盖的分支类测试用例如运营活动等等细分类别。
基于状态基于流程2.3.项目分离与数据构造随着代码量增长，项目开始变得臃肿，但项目从代码逻辑来看可以清晰分为两层，一层为提供基础功能的代码，如服务于基础的工具类、服务接口调用方法等，另一层为测试用例；再者接口测试已经发展一段时间，用于业务测试、回归测试的场景已经成熟，到了再往前走一步的阶段：比如在功能测试中QA往往直接通过写几行代码来辅助构造一些数据，项目合理的拆分似乎可以更便于将构造数据功能平台化。
