【团队管理制度2.0】历时5个多月，数十次实践和修改，终于定稿
Skywen天问信息团队管理制度2.0版本经过大约5个月时间完成定稿，这五个月时间经历了数十次的修改和完善。每一次改动和改版都在大家的共同尝试，测试，反馈中逐步的完善。团队管理2.0制度囊括了我们团队现阶段面对管理层面各个维度的问题，进行了一些加法，也进行了大量减法。团队管理的核心是去解决问题，而不是去制造更多的问题。接下来我们会在3.0的版本中进一步完善现阶段存在的问题，同时拓展和研究更加先进和优秀的管理理念以及团队协作方式。
文档说明
通过优化项目管理来提高团队执行力，增强团队凝聚力，并且从统计中考核成员，实施一定的绩效奖励。持续优化简报制度进行团队和个人的反思与总结，同时对1.0版本进行了优化处理，制定了年假制度、发票制度和文档规范，实施奖励与规范并行。
项目管理
项目排期和统计
产品基础方案
运营内容输出
简报制度
月报内容和数据优化
周报内容优化
年假制度
制度说明
制度方案
发票制度
个人发票返点制度
合同发票返点制度
文档规范
标题层级
文本间距
文本字体
更新记录
【20200330】更新了工作量统计、工作成长规划内容
【20200331】更新了工作量统计中开发技术部分内容
【20200709】更新了项目排期及版本迭代内容及整体框架变动
【20200814】整体内容持续更新
【20200824】最后的增删改查
项目管理
项目排期和统计
记录、统计和分析团队成员在项目上的各项工作任务内容所花费的时间，用以采集标准工时，考核团队成员的绩效。
排期方式优化
该版本根据V1.1执行协作的工作细节进行了再一次的优化。
产品经理对项目进行大版本小版本功能拆解，在开发进程中进行分配跟进。产品UI仍然考虑大版本进行项目处理，完成后项目进入下一阶段。
状态
负责人开始着手做的时候改为进行中（研发中），后续根据具体进展情况进行修改状态。
开始时间
默认负责人开始着手时间，开发的时间由产品经理填写。
截止时间
默认创建人填写预期时间，如果提前完成，负责人修改最终完成时间，或者在评论里记录。
如果正常延期，不用修改，统计到月度总结里；如果是特殊原因延期，在评论进行说明，艾特任务相关人员，修改截止时间。
统计
产品经理根据实际完成时间统计到语雀数据表格里。预计完成为估时，实际完成为工时统计，完成日期为最后确定时间。根据V1.0试用情况，删除上线运营，修改发布交付为交付维护。
Wotktile项目整合
原先的具体项目根据进度合并分到大类，对任务进行迁移处理。主要变动的项目是 SkywenInnovation 和SkywenProduct 两个分类。
产品基础方案
方案作者：丁琳
文档版本：2020.08.24
方案说明
1.0方案简单介绍了我们小团队是如何在大半年的时间内形成适合我们的工作模式，并且从0到1进行产品的研发直至交付。在此之前，项目往往会存在流程不具备基本灵活性、与客户或开发沟通存在“盲点”、项目经常性延期、客户测试时反馈问题较多等等问题，团队不断磨合的过程，慢慢总结并且在一个个项目中就不断调整、优化，以求摸索到最合适的团队方案。在接下来过渡到2.0期间，我们也会不断在产品本身的进步方向、测试用例上的规范、复盘工作内容的细致化等等方面持续探索。
项目策划
项目沟通
在和客户进行对接时，我们首先在沟通过程中理顺清楚要做产品的类型是什么、核心功能是什么、产品目标有哪些、怎么做、操作流程是什么样的、使用场景有哪些、目标用户又是谁、最后需要达到一个什么样的效果、什么时候完成等等。
项目方案
出项目方案给客户，方案以思维导图的形式向客户展示用户端和后台系统端的功能结构或页面结构，以图来展开说明每个模块下功能点，最后给出一个合理的工时预估和预算
原型确认
项目方案定下来之后，就要开始推进原型的确认。产品页面的信息和布局需要展示清晰且简单的用户操作步骤，可以支持并帮助用户更高效的完成目标，一个文案或一个图片都会分散用户的注意力，因此还需要考虑到各个模块之间的关联性。
产品UI
输出原型客户并确认之后，交给UI去出设计图，尽管在设计稿上做了简单交互，但是有时客户还是难以体会到实际使用起来的感受，特别是网站类的项目，在此方面需要细致的沟通，否则在研发结束后客户不满要做整体页面上的变动。
研发测试
由于我们还没有测试人员，因此在测试上一般由产品和UI进行测试。每个人的思维都有一定的局限性，导致在内部测试阶段很多问题无法及时发现，就交付给客户，留下了一些隐患问题，这样的用户体验很不好。
测试用例已经提上2.0的日程，大多用例都是由运营担任测试的角色进行编写，评审通过后去测试，一些主流程或主要功能点则产品去完成测试用例的编写并测试。接下来，将这个制度规范化并且在使用过程中不断进行优化。
交付维护
在内部测试通过后交付给用户进行使用测试，在这个过程当中及时记录客户的使用反馈，毕竟有些功能往往在使用过程中才能真切的让客户获得感受，并及时优化当前版本、修复问题、随时调整进行更新迭代。
由于内部测试流程的不完整、不规范性导致现阶段我们的客户测试阶段亟待完善，客户总是在交付后有一些新的问题，若是小版本交付又会涉及到后续版本开发周期的问题，因此，目前我们是bug类问题第一时间解决，客户提的一些新需求进行“初处理”，放到后面的版本去迭代，以免打乱整体进度。
复盘工作
项目以小步快跑的模式进行研发，同时项目的延期导致在此阶段我们做的复盘工作并不细致也不系统化，只做简单的沟通。因此，在下一步的探索规划中复盘工作也要更加全面、规范。
运营内容输出
制度说明
主要为解决团队内部的内容输出，以及输出后的品牌宣传和新媒体运营发表所编写的制度规划，同时对团队文章及内容的管理和输出进行进一步的规范。
文章内容原则
文章80%以上以团队原创为主。
文章字数以1000字和2500字为两个标准，1000字用于技术类或者资讯类，2500字用于制度或知识分享类。
文章内容囊括制度，创业，技术，设计，新媒体等领域。
文章内容由团队成员共同完成。
内容管理概述
基于PARA 四步内容管理法进行内容输出流程。
主要应用于在语雀博客 Skyweninfo 博客中的内容管理。
PARA整体流程概述
Projects
将每周确定要写的文章主题放置Projects，并且标注截止完成日期，作为一个硬性完成指标。
Areas
把日常感兴趣和认为可以发表的文章题材、话题都放到Areas文件夹中作为一个文章的海选池。
Resourses
将平常项目进行的素材、好的文章内容都记录下来放置Resources文件夹。可适当根据不同主题文章分类放置，在写作时可以在Resources找到合适的素材下笔。
Archives
定稿后，运营人进行检查确认无误后，排版编辑推送至各个相应的平台。其中产品案例是图片，所以涉及多平台传播时可能需要设计师配合运营人员切图。最后将定稿的文档存档于Archives文件夹。
文章编辑和改稿规范
文章基本结构
1.文章头图 - 创客贴设计
2.文章摘要 - 总结文章概述
3.文章正文 - 基于MD写法
4.产品案例 - 根据情况增加或取消
5.文章总结 - 总结文章主旨
6.文章底图 - 公司或团队介绍
产品案例结构
1.头图
2.目录
3.设计规范
4.模块内容
5.全部设计图排列
6.尾部（公司介绍+成员介绍+结束语）
改稿和定稿
审核人（李老师）提修改意见，作者在指定时间内修改完定稿。
发表审核
运营在发表前，检查语句是否通顺，有没有遗漏或错别字。发表后关闭任务，通知相关人员。
内容发表平台
技术类平台
1.CSDN - 团队技术分享
2.掘金 - 团队技术分享
设计类平台
站酷 - 产品案例发布
公司资讯发布类平台
1.微信公众号 - 每个月完成四次推送
2.语雀博客 - 主要编辑平台
3.知乎 - 偏内容分享
4.简书 - 偏制度和内容分享
5.官方网站 - 等待上线
其他资讯类平台
1.今日头条 - 资讯类
2.新浪微博
3.企鹅媒体平台
4.百度百家号
5.搜狐号
运营维护工作
运营人员对各平台文章的留言、评论的进行维护。结合文章对作者进行反馈，以便后期进行优化迭代。
简报制度
月报内容和数据优化
内容优化
1.对整理内容的目录结构进行了调整，调整后为：BOSS总结 – 团队总结 – 项目总结 –个人总结 – 工作统计 – 语雀统计 – 新闻专报 – 技术统计。
2.对个人总结内容进行调整，不再使用上月规划+当月总结+下月计划的模式，修改为：四周的周报内容 + 四周打分的分 + 个人月度总结和思考。
3.基于企业微信进行请假情况处理，取消原先的模块记录。
数据统计
1.语雀更新文档的次数统计不局限于当前知识库，拓展为skywen和skyweninfo两个知识库，合并统计。
2.取消对周报情况的统计。
3.暂停个人完成度、延期率统计工作，后续会更合理化和针对性统计。
4.语雀数据表增加技术类的数据整理统计。
周报内容优化
修改周报提交内容
修改前：
修改后：
1.本周工作过程中自己在哪些方面有成长，学到了什么，或者遇到了什么困难，自己如何解决和面对的，或者希望自己在哪些方面有更好的成长空间。（50字以上算合格完成周报）
2.给自己打分 （50-100分）
修改周报提交和截止时间
由原先的周五下午5点到周日下午6点，修改为周四下午5点到周五下午5点，逾期算未完成。时间节点的修改，来避免成员周末总是遗忘提交。
修改评论范围
不再对岗位之间互评做强制要求，可自由互评。
年假制度
制度说明
基于过去几年来不完善的年假管理制度，进行整理和重新规划。公司和团队是一个利益共同体，后续会根据实际方式进行一些微调，每个人必然会收到公司和团队增长的红利。
制度方案
获取方式
入职满1年起，拥有1天带薪年假。入职每多1年，可累计增加1天，比如入职满2年，则拥有1+1 = 2天年假。
有效时间
每年3月1日之前清零上一年的年假数额，开始新一年的年假自动计算。如员工在8月1日入职满2年。则当年3月1日-8月1日期间拥有1天年假，在8月1日之后可以再拥有1天年假。每年所有未使用的年假数额。公司会给予一定的金额补偿。
使用方式
可以用于病假，事假等。在项目集中交付日，或者想要搭配节假日使用，需要提前沟通，原则上不影响工作安排和客户要求情况下，均可以满足。
上限额度
暂时按照最多不超过10天/年方式统计，也就是入职11年的最高额度考虑。
发票制度
个人发票返点制度
基于企业微信进行申请和返点，返点按月进行发放。成员登录自己的账号，在发票指定报销范围内上传当年发票，发票必须真实有效，不得虚开、代开或者是失效及作废发票。上传成功后，分享给团队地区负责人，由其交给财务，确认合格后进行返点。
合同发票工作制度
工作涉及到的合同处理在worktile上汇总，在伙伴云进行统一记录，开票联系团队当地的财务。
合同部分
客户沟通确认，起草准备相应的合同，原则按一年算，注意金额、付款方式、时间、客户抬头、内容五个要点。双方盖章后，一定要收回公司那份留存，必须有盖章红章。
发票部分
和客户沟通发票类型（专票/普票），填写资料开具发票，拿到纸质或电子发票后，上传到伙伴云进行数据备份处理。其中纸质发票需要邮寄给客户，电子版发送即可。
文档规范
基于Markdown写法为基础，以及语雀编辑器为主要的内容编辑工作的文档写法规范。
标题层级
标题
二级标题，文章的标题，用 ## 表示。
四级标题，文章的副标题，用 #### 表示。
注意事项：上下级标题避免重复。
列表
无序列表，参考本文的使用。
有序列表，以 1. 2. 3. 显示。
文本间距
字间距
1.中英文字符之间，保留一个空格。英文作为开头或结尾，只保留单侧空格。
2.中文字符和数字之间，全局保持一致即可。选择有空格的情况，数字作为开头或结尾，只保留单侧空格。
段落间距
段落与段落、段落与图片之间，图片与图片之间留空一行。段首不缩进。
标题间距
二级标题之间留空两行。
四级标题之间留空一行。
文本字体
字重
在被加粗的语句、短语前后，如果加粗句子最后有标点符号，不要对它加粗，句子中间的标点符号正常加粗。
字号
不要对任何文字，做字号调整，更不要把非标题字号扩大用作标题。
颜色
不要对任何文字，做颜色调整。
拼写
主要针对英文的拼写。如 iPhone 而不是 iphone，Apple 而不是 apple，Java 而不是 java，Aliyun 而不是 aliyun，UED 而不是 ued，OSS 而不是 oss 等等，使用前，可以先网上查下正确使用。
版本迭代记录
记录团队管理从1.0版本进化到2.0版本不断优化的过程，每个小版本都会对具体模块进行优化，为求更贴近团队的管理与协作。
项目排期和统计
V2.0 项目整理优化
填写
产品经理提前一周安排下一周的工作规划，以一个季度为准统计项目的排期和进度情况，项目饱和度较高的排在前面，已结束的项目归入归档项目行列。每个季度末排查整理。
统计
产品经理根据排期和实际的情况把数据填写到项目步骤表里。
持续优化的月报制度
V1.3 内容结构回顾
本次优化相对工作量最大，内容最完整，根据试用的效果进行评估，继续优化。
V1.4 内容的增删
删减部分
1.4版本取消了团队下月规划、项目进度和下月规划、重大失误等内容。数据报表汇总直接统计到语雀，不需要单独作出图表展示。项目进度和下月规划直接在排期中提现，由于很多项目是线性的，故不再以月度为节点进行统计，以里程碑或版本迭代时间为基准，在复盘或季度/年度等报告时进行展示。
新增部分
针对周报进行统计，以字数、评论、实效三个维度进行总结。
1.一月四篇未完成的成员
2.周报中比较优质，字数较多的成员前三
3.周报中评论较多的成员前三
V1.5 内容修改优化
1.删去团队工作总结。此处的团队指的是岗位团队，比如产品创新团队、UI设计团队。
2.针对个人总结，增加上个月写的下月规划，和当月总结、下月规划放在一起，用于成员自我查看和思考。
姓名
当月规划
当月总结
下月规划
3.周报未完成不做必要显示，有则单独一行说明即可。本次修改取字数、评论的前二和最少两名。增加精华周报内容，从成员的周报中提取一些对问题的反思、思考建议等。
4.其中为提高开发数据统计的精度，增加git提交次数。
姓名代码量git提交次数
V2.0 数据统计优化
时间
1.由于时间只能筛选创建时间，所以尽量当月创建任务以提高精确度，但不可避免有任务暂停的情况。
2.通过设置任务的开始时间和截止时间来提高精准度。
人员
负责人和参与人单独统计数据成员完成度，影响的是两边的数据，为保证相对精准，一个任务下同一成员不能同时为负责人和参与人。
报表
1.对worktile表单的数据筛选，保留进行中、已完成、完成率、延期任务和延期率。未开始的任务不作为总结；延期总结只保留延期任务和延期率；由于每个成员的任务基数不同，所以不单一的以完成率为指标衡量。由于任务设定了截止时间，没有结束的话会影响到延期率和完成率，故每个人要及时更新自己的任务状态，并参照规范结束任务。
姓名进行中已完成完成率延期任务延期率
2.语雀保留近30日成员更新文档的次数。
V2.1 项目整合及统计优化
原先的项目根据进度合并分到大类，对任务进行迁移处理，暂停具体项目的各类指标统计。持续统计成员完成率和延期率以及各成员在语雀近30日更新文档次数。
周报制度
V2.0 周报工具更换
周报工具的从worktile更换到语雀。对语雀进行可行性分析。
1.可以定时发起和归档，通过接入公司的消息中台，可推送到群里通知成员及时快捷参与。
2.标签-可以自定义任务状态。列表内容分为无序列表和有序列表，在编辑内容时可以选择合适的形式。整体内容列表排版，层级错落有致，重点突出。
3.支持每个成员都可以进行表情和文字的评论。对于我们写月度总结也方便了许多。可以直接在这个面板回顾与总结，对比自己的变化。个人面板持有心情功能，相比单一的文字更多一分趣味。同一个成员可以多次发表。
4.汇总的时候可以直观看到参与的人数和提交时间，但需要将头像和成员联系起来，才能统计到提交成员。
版本展望
2.0 方案优化
任务分配
不断地配合团队协作的模式进行优化，意图更贴近项目执行流程。从需求的确认到项目的完结，每一阶段落实到具体成员，进行任务处理。同时对任务量的统计持续进行优化。
报销请假制度
进一步完善发票抵扣和报销申请，从人工审核过渡到自动化流程。不断对请假模块进行尝试统计和计算。通过修改使用方式和流程，符合现阶段我们团队的需要。
产品方案
优化项目测试用例制度化规范，进一步提高产品用户体验，同时积极开展项目复盘工作，汲取前一个项目的经验，以此来缩小下一个项目结果和预期产生的负差值。
运营维护
随着我们发布的文章数量的持续增加，在3.0阶段考虑运营维护和推广策划阶段。
工作成长规划
3.0预计推进成员的工作成长规划，为鼓励成员不断学习、进步，实现自我的人生价值和能力，同时也为公司创造更大的价值，各部门拟制定不同的发展计划。
执行与反馈
逐步完善依托 note 系统，3.0会全面加强消息通知，囊括所有相关平台，做到日常通知、关键通知、紧急通知，以及各类提醒等通知方案构建。Worktile、语雀和Gitea作为发出通知方，实现推送一些消息通知到企业微信、微信公众号和
2.0版本 BOSS总结
我们在2.0整个方案中，考虑和尝试了很多，在上面这些方案中有一些思考总结一下。
针对项目排期管理做了比较大的优化，在尝试过基于excel方式的排期记录和基于worktile的自动化项目管理方式上，做出了很多的改动和尝试，最终我们还是决定基于worktile进行实时管理项目排期的方式进行管理和跟进，这样可以收回很多项目排期和实际情况不符的工作损耗以及项目进度无法及时跟进的严重问题。
月报周报的工作简报制度从之前的worktile上进行编写以及常规的周报编写方式，以及月报的越来越多的数据统计工作到最后2.0定稿的大幅度精简了工作量，整个流程中应该说减少了大约50-60%的周报月报工作量，同时更加注重个人的工作反思，以及及时完成工作统计，减少一切不必要的工作量和无价值的数据。
我们在之前简单记录的请假管理方式上，考虑使用企业微信进行自动化请假管理，同时在报销和发票返点制度上线之后，同步迁移到企业微信上进行申请和审批，同时做到了使用企业微信+微信支付进行人工审核之后可以直接打款到员工微信账户中完成更加高效的钱款到账方式，大幅精简了运营的各类统计工作。
我们在内容管理制度上，近期完成的基于PARA内容管理方法目前使用效率很高，预计会在接下来的时间内可以大幅提高我们的内容输出量以及团队内的内容管理模式，解决了我们一直以来困扰的内容工作模式。
同时我们在这半年多的产品项目全流程，也就是朝着敏捷开发的方向上。总结出来的产品方案，目前完成了1.0版本的定稿，在定稿过程中，我们在几十个项目，经验，困境中总结经验，同时也为接下来的2.0版本的产品方案里列出了更多好的方向和需要解决的难点，比如测试用例的初步介入等等。
接下来的3.0 团队管理方案，我们会更加的选择和尝试优秀的管理模式，制度模式，覆盖到团队管理领域的每一个方面，尽可能的融合一切数据和操作，减少一切不必要的损耗和浪费，用尽可能少的资源和精力损耗，自动化智能化信息化的解决团队发展过程中遇到的每一个问题。
