部门制度

Posted on Aug 31, 2014

##一般会议执行制度

确定会议日程。确定会议中到底要讨论什么是保证会议效率的关键,没有会议日程就不要开会。

大会化小。短而主题独立的会议胜于长而多主题的会议。

指定会议记录员。既可以给错过了会议的人看,也可以随时提醒大家会议的结果。可以单独使用一个投影仪来现场显示记录内容。

办公室会议。上司可以订出一个时间段,在这个时间段内在办公室里顺序会见不同的项目负责人,每人最多十五分钟,既能掌握全局,又不浪费大家的时间。

守时。把守时作为一种压力,而不是无所谓,可以让会议不跑题,不把时间花在不该花的地方。

如非必要,就不要准备会议材料。会议材料的准备,即浪费,也会对参加会议的人造成一种依赖心理。

准备会议-》参加会议-》主持会议-》管理会议

会议结果:解决问题、达成协议、做出决策、重大提案及未决问题

发布情况:备忘录、文件、决议及其他形式(口头、书面、电子文档等)

保密要求:绝密、机密、公开

会议最好是局限在平行关系的成员,或是团队内部上

尽量避免举行“例行性召开”会议,按照一般惯性,前一天大家才开始准备沟通效果不佳

会前一定要事先通知,包含议题、预期会议要达成的目标、准备的文件、主席和参与人员、时间地点

主席控制时间确保议事顺利进行,不是裁判或训话

会议后将记录给与会人员签字,并经主席确认,再发给相关人员。有时限进度要跟进

在容易看见的位置上放一个表或钟,以便掌握时间。

会后速决,决后速行

节省成本,加快决策速度,更有创意

只开有实际效果的会议

准时开始,《1小时

重点在实际行动

开会前的6项准备:

  • 先決定會議希望達成的結果
  • 想想會議是否有必要召開
  • 邀請適當的人出席
  • 準備背景資料
  • 設定會議綱領及時間表
  • 預先設想可能的衝突

開會後3項追蹤:行動項目/決議/開放議題

參考一:會議規則:

  • 仔細傾聽他人發言
  • 主動思考問題在哪裡
  • 為他人打氣並提案
  • 貢獻如何『打勝仗』的 智慧
  • 互相諮詢討論
  • 根據事實
  • 先做做看

改革會議三大重點

  • 緊張感:沒有緊張感就不是會議
  • 溝通:拿出一決勝負的態度唇槍舌戰的討論
  • 決定未來發展的『創造性』

領導作風

掌握會議重要決策的關鍵時刻

藉思考法、基礎技術、工具等活化組織,提升思考性會議 3思考:從零出發思考法、綱要思考法、選擇思考法 3基礎:參與態度、結構化、本質化 3工具:邏輯樹、矩陣排列、過程分析 磨練報告技巧,強化會議活力 3技巧:存在感、劇本撰寫技巧、傳播技巧

從『空間』和『工具』思考未來的會議

  1. 有一个明确的议程
  2. 指定专门的note-taker
  3. 钻小会(Carve out micro-meeting)
  4. Hold office hours.
  5. 要数据,不要政治
  6. Stick to the clock

##按时召开会议(周、月、年)

每周最后一个工作日(一般是周五)下午16:30-17:00召开部门周会,Agenda一般是:

   总结上周工作情况
   听取和讨论建议
   讨论并解决目前碰到的问题
   分配本周任务

周例会前每个人必须提交本周的工作情况。

一般采用上传工作情况PDF文件到SVN上相关目录内。在会前由部门经理来检查并提取每人的工作情况报告。

每个月第一个工作日下午16:30-17:00召开部门月会,Agenda一般是:

 通告本月部门工作完成情况
 回顾每个人指定的本月个人目标是否完成
 表彰优秀个人和小组
 听取建议
 回顾和解决问题
 每个人制定下个月的个人目标
 下月部门计划

每季度第一个工作日下午16:30-17:00召开部门年会,Agenda一般是:

 通告半年部门工作完成情况
 回顾每个人指定的半年个人目标是否完成
 表彰优秀个人和小组
 听取建议
 回顾和解决问题
 每个人制定下半年的个人目标
 下半年部门计划

##内部培训制度

固定每周四晚上下班后进行内部培训。如果当晚的培训时间超过1.5小时,那么都吃完晚饭后培训;否则从17:30开始培训。

每次培训前周三下班前必须把培训讲义PPT及必要的文档上传到FTP上相关目录中,并发邮件通知与会其他人员。

提前2周确定培训内容和讲师。

##FTP使用制度

FTP Server:192.168.1.133 UserId:中文姓名拼音,例如:刘冲>liucong PW:88888888

采用FTP方式(不加密模式)

在FTP服务器上建立目录下必须有一个readme文件,内容是目录中的文件的用处

在FTP服务器上每个人都可以有一个自己的目录,并且只有本人有全部权限,除了管理员以外没有人有权限去访问。目录以邮件地址“@”前面的值来命名。每个人的目录大小预先设为100M,以后根据需要经部门负责人批准再酌情增加容量

除了最高管理员对所有文件或者个人对自己目录有所有权限,除此之外没有人有删除权限

按照部门建立目录,给这个部门负责人和指定的部门管理员赋予除删除外所有权限,如果有其他人需要权限,经由部门负责人批准后添加

按照项目建立目录,给这个项目负责人和指定的项目管理员赋予除删除外所有权限,如果有其他人需要权限,经由部门负责人批准后添加。

建立共享目录,分为软件、文档和其他三个子目录。所有人都有上传和下载的权限,但是除了管理员以外没有用户有删除权限。

##文档命名规范

|工作产品名称|特征符|缩写含义|

项目计划 PP Project Plan

过程和产品质量保证计划 PPQAP Process And Product Quality Assurance Plan

配置管理计划 SCMP Software Configuration Management Plan

工作产品表 WP Work Product

工作细分表 WBS Work Breakdown Structure

任务描述单 TDF Task Description Form

进度安排表 PS Project Schedule

项目跟踪监控表 PT Project Tracking and oversight

项目进展度量表 PM Project Measurement

产品审批表 PAF Product Approval Form

项目问题状态日志 PSL Problem Status Log

风险分析表 RA Risk Analysis

风险应对措施日志 RMAL Risk Mitigation Action Log

项目变更申请 PCR Project Change Request

个人每周状态报告(个人周报) WSR Weekly Status Report

小组每周状态报告(小组周报) TWR Team Weekly Report

项目每周状态报告(项目周报) PWR Project Weekly Report

工作会议纪录 WMM Work Meeting Minutes

配置项状态统计 CSA Configuration Status Accounting

变更和问题状态日志 CPL Change & Problem Log

配置变更请求单 CCR Configuration Change Request

软件问题报告 SPR Software Problem Report

配置审计报告 CMA Configuration Management Audit

版本说明书 VDD Version Description Document

QA审计报告 QAAR Quality Assurance Audit report

QA检查单 CKL Checklists

验收测试计划 ATP Software Acceptance Test Plan

评审报告 RWR Review Report

项目验收报告 PAR Project Acceptance Report

项目开发总结报告 PDS Project Development Summary

可跟踪矩阵 RTM Requirement Traceability Matrix

|工作产品名称|特征符|缩写含义|

软件需求分析 SRS Software Requirement Specification

概要设计说明 HLD High Level Design

详细设计说明 DDS Detailed Design Specification

源代码 SCL Source Code List

系统测试计划 STP System Test Plan

集成测试计划 ITP Integration Test Plan

单元测试计划 UTP Unit Test Plan

系统测试用例 STC System Test Case

集成测试用例 ITC Integration Test Case

单元测试用例 UTC Unit Test Case

单元测试报告 UTR Unit Test Report

集成测试报告 ITR Integration Test Report

系统测试报告 STR System Test Report

发布测试结论 RTR Release-Test Report

产品发布说明 RN Product Release Specification

用户手册 UMF User Manual Final

操作手册 OPM Operating Manual

安装维护手册 SIM System Installation Manual

用户培训手册 UTM User Training Manual

文件名规范:项目代号-文档类型-版本号.xxx

均用小写字母,各部分用减号“-”来分隔

项目代号:YYSXXX,YY表示年份后两位;S表示是该年的第几个项目,从1到9,如果超过9那么以A到Z来扩展;XXX是项目缩写。如果是非特定项目,那么设为“000GNR”

文档类型:文档类型缩写,长度从2-5

版本号:处于“草稿”状态的文档的版本号格式为:0.YZ,YZ的数字范围为01~99。随着草稿的不断完善,“YZ”的取值递增;

处于“正式发布”状态的文档的版本号格式为:X.Y,X为主版本号,取值范围为1~9,Y为次版本号,取值范围为1~9。文档第一次“正式发布”时,版本号为1.0。如果文档的版本升级幅度比较小,只增大Y值,X值保持不变,只有文档版本升级比较大时,才增大X值。

文档处于“正在修改”状态时,其版本号格式为:X.YZ。文档正在修改时,只增大Z值,X.Y值保持不变。当文档修改完毕,状态重新成为“正式发布”时,将Z值设置为0,增加X.Y值。

##SVN使用制度

SVN Server:192.168.1.245

SVN 地址:svn://192.168.1.245

UserId:中文姓名拼音,例如:刘冲>liucong

PW:123456

每个部门新建一个目录,之下分为管理制度、工作日志和例会三个子目录。【管理制度】放管理制度文档;【工作日志】为每个人建立一个文件夹,并且赋予该用户除删除外所有权限,其他人除了部门经理外都没有访问权限;【例会】分为周、月和半年三个子目录,部门下所有人都有下载的权限,只有部门经理有上传的权限。

每个项目新建一个目录,之下按照软件工程来建立子目录,比如:POC、合同、参考资料、策划设计、管理制度、会议和源代码等。其中项目经理和部门经理有权限访问所有目录,【管理制度】【会议】和【参考资料】所有人都能访问,除此之外只有策划设计人员有权限访问【策划设计】,开发人员有权访问【源代码】。

##文档管理制度

目的:规范文档流转规程,例如在邮件附件中文档、上传到FTP等共享目录的文档、上传到版本控制系统中的文档。

以下特指: MS Office:doc(Word),xls(Excel),ppt(PowerPoint) Libre Office:odt(Writer),ods(Calc),odp(Impress) Acobat:pdf

如果不需要修改或者不允许修改的文档,必须以pdf格式保存 否则,以MS Office(97/2000/XP)的方式来保存

##内部IT管理制度

###邮件管理制度

每个员工分配一个公司邮箱,并且申请一个Gmail帐号。 接收邮件用Gmail,并且代收公司邮箱。 发送邮件使用公司邮箱

###IM管理制度 IM使用飞鸽传书http://ipmsg.org 如果和公司外进行网络沟通,按照实际需求申请,部门经理批准后开通相应IM权限。

#任务分派制度 完成时间如果都沟通确认了,那么必须确定完成时候提交的结果。比如:文档、会议或者代码。

在任务执行过程必须要多进行Review。根据任务的大小难易召开Review会议,可以找其他部门的人一起来。

会议提前在Google日历中确定,并给相关人员发出会议申请。

##其他制度 1.加班的小时数可以一比一来做调休。

2.如果加班时间已经超过了公共交通的限制或者得到部门经理的允许,可以采用出租车方式回家。并且要求拼车或者坐一段公共交通(比如地铁)。

3.和其他部门如果是部门间的沟通,一律使用部门邮箱,采用邮件方式,附件附上《部门联系单》,然后规定2个工作日内必须答复。

4.规定每1到2周在周三晚上举行部门内部培训,内容是员工提出来的,可以由员工来讲也可以找外部力量帮助。培训内容全部用摄像机或者MP3录下,以作为以后的培训教程。

5.争取固定一段时间进行部门内部team working,形式多样,可以是吃饭、唱歌、桌游、体育运动或者踏青野餐等。费用要争取公司付一点。

6.每周一上午8:30进行周例会总结上周计划本周

7.每个员工申请gmail邮箱,并且用gmail来收取俄公司邮箱的信件。工作任务和会议通知全部都用邮件方式进行传达。收到邮件的员工必须在邮件内容中规定的时间内完成任务或者参加会议,同时第一时间回复邮件。

8.每个人每周一周会前必须提交上周周报,内容包括:上周工作完成情况,本周的计划,还有问题和建议