背景：最近发现团队成员的计划设定存在各种问题，之前提到过的 SMART 原则，普遍理解不太一致，因此周会上专门就此问题进行了简单的培训，在此分享出来：
一个故事
部队组织越野比赛，三个队伍都是精兵强将，比赛实际内容也一样，唯一的区别是目标设置不同。
谁最先达成目标？
所谓 SMART 原则，即：
具体的（Specific）
不具体：提高工作透明度
具体：确保每天的任务及时发布到 Tower 中，并且当天结束时该任务需要说明清晰的进展，并通知相关人；
不具体：提升自己的沟通能力
具体：阅读《高能效人士的七个习惯》，并且就其中的内容跟大家做一次 PPT 分享；
不具体：配合后端联调
具体：和 xxx 结对，完成新建询比价采购、匹配供应商两个故事点的联调；
不具体：进一步优化设计
具体：优化第一版中的问题，并组织第二版设计的全体评审，说明设计思路，收集第二版意见；
不具体：加大招聘力度
具体：重新修改 JD，提升招聘效果；扩展论坛和博客渠道，提升简历量；完善招聘协同机制，确保筛选的简历能够 2 小时内得到需求方确认；已经确认的简历，当天完成邀约；
不具体：提升开发质量
具体：坚持每天进行代码审查，每次审查发现的问题，当天记录和分析，确保第二天完成修改；
可以衡量的（Measurable）
不可衡量：提升团队透明度；
可衡量：每日进行透明度检测打分，对透明度低的同伴及时提醒，并通过晨会、周会强调，确保下周透明度提升 30%；
不可衡量：基本达成项目目标
可衡量：确保下周完成 BetaV1.0 迭代的开发和测试，并完成 bug 修改，确保无1、2 级 BUG，迭代正式对外发布；
不可衡量：基本完成产品验证
可衡量：建立应用级故事验证表格，确保产品正式开发前完成销售、专家、老板、客户的四重验证；
不可衡量：了解团队成员的问题
可衡量：下周完成团队成员 15 个人的访谈，并发布访谈纪要和总结，针对问题设计改进方案提交给 xx；
不可衡量：降低产品发布后的 bug 率
可衡量：下个迭代发布后，1 级 bug 从 2 降到0，2 级 bug 从 6 降到1，3 级 bug 不超过 3 个；
不可衡量：提升客户满意度
可衡量：客户的电话投诉率降低 20%，问卷调研满意度从 75% 提升到 90%，电话接通率需要达到 97%，论坛抱怨贴相应时间不超过 10 分钟；
可以达到的（Attainable）
不可达到：7 月底完成新版产品的上线
可达到：7 月底完成新版询比价采购以及配套基础模块的上线；
不可达到：季度内客户满意度达到 97%
可达到：季度内发布产品后，检测客户满意度，确保数据可监控，并且根据初始数据提出满意度提升方案；
不可达到：成为专业领域专家
可达到：每个月至少看一本专业书，写一篇专业博客，做一次专业分享；
不可达到：减肥成功
可达到：放弃烧烤，不再吃夜宵，每天做 10 个仰卧起坐；
不可达到：获得北京户口
可到达：获得北京工作居住证；
相关的（Relevant）
不相关：获得采购师证书
相关：产品成员 1 年内获取采购师证书
相关：对已经固化的 3 个核心应用的 17 个关键 featur 实现自动化测试
不相关：每天必须 8 点半上班
相关：每天必须完成当天的目标
明确的截止期限（Time-based）
不明确：每周按时提交周报
明确：每周五中午 12 点前完成周报
不明确：本周完成项目上线
明确：本周五中午 12 点前完成项目打包，下午 6 点部署上线并开始验收，达到验收标准后下班，否则加班；
不明确：晨会要及时签收
明确：晨会纪要，必须中午 12 点前签收
不明确：及时响应用户需求
明确：对用户的意见反馈，24 小时内给答复；对于投诉，10 分钟内给答复；
不明确：明天开会讨论
明确：明天上午 11 点开会讨论
无论是团队目标，还是个人目标，都应该符合 SMART 原则的要求，否则计划会流于形式，更不便于针对计划进行后续监控和管理。特别对于敏捷团队小步快跑的节奏而言，每个人每一天的计划都与团队迭代目标的达成密切相关，因此，即日起我们会对团队成员的日常计划和周计划进行 SMART 评估，帮助大家逐步建立良好习惯，提升团队战斗力。
相关文章
