php 简历star法则模板,用STAR法则梳理产品经理日常工作及问题

STAR法则,即为Situation Task Action Result的缩写，具体含义是:

Situation: 事情是在什么情况下发生;

Task: 你是如何明确你的任务的;

Action: 针对这样的情况分析，你采用了什么行动方式;

Result: 结果怎样，在这样的情况下你学习到了什么.

简而言之，STAR法则，就是一种讲述自己故事的方式，或者说，是一个清晰、条理的作文模板。不管是什么，合理熟练运用此法则，可以轻松的对面试官描述事物的逻辑方式，表现出自己分析阐述问题的清晰性、条理性和逻辑性。

举个最近一年在做的短视频项目的例子

s情景：

平台流量日益枯竭，对短视频而言，直播对场地时效要求严格，不利于传播，并且15秒短视频精彩程度比直播强得多，对于提高用户粘性有很大的帮助。希望以后台为依托，以主播为中心建立一套完善的业务体系，提高用户粘性。

T任务：

以后台业务线为依靠，帮助业务人员设计实用的后台。

A行动：

前期对用户进行短视频使用情况调研和竞品主要功能分析，以及保持每天2次和BOSS的迭代速度，确认后台设计进度和项目开发跟进。

R结果：

短视频DAU28W,使用时长提高10%。对业务理解更透彻，培训业务人员使用，有完整的项目经验

Q1问题：

当时遇到问题，BOSS说要做一个短视频，但是对短视频的业务方向不太清楚，不知道如何确定业务方向，我和另一个产品就开始去寻找竞品，发现它们的痛点，发现找大部分视频主聊天都没反应，所以我们在做后台的时候加上了接待模块，主要针对没人评论，私聊没回复的问题。

Q2问题：

过度设计，跟老板沟通前期，一开始就对每个大功能模块上添加了很多自认为有用的小功能，导致了重点不明显，当时幸亏BOSS提醒，才将重点确定在能发能导能聊上面.

Q3问题：

项目跟进过程中，常常会出现一些BUG或需求没写清楚的地方，开发跑过来问，口头交代后还是会出现问题，最后导致项目延期。之后尽量不要口头交代，完善需求文档，自建自查表。

Q4问题：

没办法让主播自主发动态，功能上线后，发现主播发动态的质量和意愿不强烈，没有好的质量内容，于是我们在后台导播页做了一系列活动模板，通过主播参加活动来获得物质奖励和认证标识，同时构建推送体系，精细化推送提升日活。