| 设立背景 | 公司要做电力电子产品，得有人搞研发和调试。 | ||
|---|---|---|---|
| 核心职能 | 做电力电子产品的开发，写控制算法，调dsp控制器，搞软件架构。 | ||
| 工作内容 | 建模系统，写控制算法，开发dsp程序，设计储能变流器软件，编码调试样品。 | ||
| 协作关系 | 跟硬件工程师一起调板子，向项目经理汇报进度，配合测试同事做功能验证，有时要和结构同事对安装接口。 | ||
要求:本科/研究生，电力电子与电力传动，电气工程专业;控制理论与控制工程专业;电子信息类专业。
职责：
1、负责电力电子产品的开发工作;
2、产品的系统建模，控制算法，dsp 数字控制器研发、软件架构以及样品调试;
3、进行储能变流器、大功率双向dc-ac逆变器/dc-dc变换器软件设计和编码实现
| 设立背景 | 集团要搞b2b网站，得有人懂架构和二次开发。 | ||
|---|---|---|---|
| 核心职能 | 管好b2b网站的底子，改功能、加模块、搭系统。 | ||
| 工作内容 | 搭网站架子，改电商页面，做可视化操作系统，写代码调接口。 | ||
| 协作关系 | 跟总部信息化部门天天对接，听他们安排，也帮事业部落地系统，偶尔配合其他部门提的需求。 | ||
it总监(b2b网站建设) 负责集团电商平台架构(b2b网站架构要精通)，及电商平台二次开发;
负责事业部可视化操作系统开发;
与总部信息化对接工作
其它信息化相关工作。
负责集团电商平台架构(b2b网站架构要精通)，及电商平台二次开发;
| 设立背景 | 公司做大型软件系统，需要有人搭整体架子，不然开发容易乱套。 | ||
|---|---|---|---|
| 核心职能 | 定技术方向，画系统蓝图，带团队干活，解决卡脖子问题。 | ||
| 工作内容 | 写架构文档，教同事用工具，改设计图，盯开发进度，调服务器和数据库。 | ||
| 协作关系 | 跟产品经理聊需求，向技术总监汇报，帮开发工程师解bug，和测试一起验结果，跟运维对接部署细节。 | ||
系统架构设计师职位要求
1.本科学历，计算机或通信相关专业
2.最少3年以上相关工作经验
3.精通struts hibernate spring等主流开源框架，熟悉j2ee体系结构
4.对面向对象、mvc有深刻的理解，熟练使用常用软件建模工具进行系统分析和设计
5.熟悉运用oracle，sql server等数据库开发
6.熟悉weblogic/tomcat/jboss等主流应用服务器及oracle数据库开发技术
7.掌握常用需求/架构设计工具使用
8.优秀的沟通和谈判技巧。能有效的激励工作团队
1.理解系统的业务需求，制定系统的整体框架(包括:技术框架和业务框架)
2.对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。
| 设立背景 | 公司做游戏和web产品，要保证上线前不出大问题，得有人专门盯测试这事。 | ||
|---|---|---|---|
| 核心职能 | 测网页功能对不对，写用例找漏洞，盯bug修没修好，写报告说哪有问题。 | ||
| 工作内容 | 看需求文档、写测试用例、执行测试、提bug、跟bug、写小结、分析bug原因。 | ||
| 协作关系 | 和产品经理聊需求，和开发一起改bug，向测试组长汇报，偶尔和ui确认显示效果。 | ||
工作职责：
1、根据产品需求文档执行功能测试、系统测试;
2、根据产品需求，分析和设计覆盖率高的功能测试用例和业务流测试用例，并对设计提出改进建议;
3、熟悉软件测试的流程，熟悉测试用例的编写，能独立完成测试用例设计;
4、编写并提交测试小结报告， 对缺陷原因进行统计分析;
5、处理日常bug，跟踪bug，辅助配合研发人员修复bug;
6 、具备软件工程的基本知识，掌握各种测试理论和测试技术并不断去拓展新方法。
任职资格：
1、至少熟悉一种bug管理系统(禅道/bugzilla/jira/redmine...);
2、了解各种软件测试理论，熟悉b/s架构的测试基本方法;
3、有移动应用及web相关产品的测试经验;
4、仔细严谨的工作态度，有较强的学习能力、责任心强、良好的沟通和团队协作能力;
5、具有优秀的文字及良好的文档编写能力。
| 制定目的 | 审核完一堆不符合报告，不能直接下结论，得把所有结果合起来看看整体情况，不然没法准确评价ohs管理到底咋样。 | ||
|---|---|---|---|
| 适用范围 | 管审核组和受审核部门，管不符合项统计、趋势对比、薄弱点判断、结论形成。 | ||
| 职责分工 | 审核组长牵头汇总分析，全体审核员一起讨论，组长定结论，管理者代表配合沟通，监督靠内部会议记录和末次会议确认。 | ||
| 禁止行为 | 不能跳过汇总直接下结论，不能回避上次没改的问题，不能在末次会议前不跟管理者代表对齐意见，不能擅自修改不符合项性质。 | ||
| 检查与监督 | 末会前开全体审核员会汇总数据，对照要素和历史做分析，组长写结论，会上宣读并签字，2-4周内收纠正措施反馈，没交就记入下次审核重点。 | ||
ohs管理体系审核结果的汇总分析
审核组有了若干份不符合报告，还不能在末次会议上对审核发表结论性意见，还应对审核的结果作一次汇总分析。汇总分析可以在末次会议前召开一次全体审核组成员会议上进行，以便对受审部门的ohs管理工作做一次总体评价。
汇总分析可以考虑以下几个方面:
(1)从发现的不符合项分析:如不符合项的总数，其中严重不符合，轻微不符合各有多少项。如果审核是按部门进行的，则列出其不符合项涉及哪些要素，其中哪个要素最多或最严重。