团队职责角色讲解
<p>[TOC]</p>
<h1>一、为什么写本篇文章</h1>
<ol>
<li><strong>招新的时候可以参考</strong>,毕竟刚高考的同学们刚进组,可能还不了解什么是“运营人员”、“UI设计人员”、“开发人员".写这篇文章就是为了让大家对团队的不同角色有个大概的印象,也方便大家挑选不同的组。</li>
<li>对于新加入组的成员可以看一下团队的协同合作,以及<strong>一个需求是怎么从想法到具体成品的实现过程</strong>。</li>
</ol>
<p>这篇文章的逻辑,先概述的讲一下不同角色的职责,然后再举一个具体的应用场景,来辅助大家理解</p>
<h1>二、角色职责概述</h1>
<p>下面由具体到抽象分职责来介绍,运营人员思考的事情比较具体,开发人员思考的事情最为抽象</p>
<h2>1.运营人员</h2>
<p>团队的灵感发动机</p>
<p><strong>写这个之前,运营人员需要知道,咱们并不是一个大的互联网公司,所以职责界限并不是很明确,也就是说,运营人员也可以设计一些UI</strong></p>
<p>主要是提供各种方案,以及各种不同的营销手段
下面写的只是举例哈,<strong>不是规则</strong>。有可能还会做一些其他事情,也不像是下面写的那么“严格”</p>
<ol>
<li>关注产品各项指标,根据分析报告,提出优化方案;</li>
<li>制定运营策略、活动方案和推广计划并负责实施;</li>
<li>运用有效的手段提升用户的关注度和活跃度,增强用户粘性;</li>
<li>提供用户反馈和运营数据,从运营角度提出产品优化建议。</li>
<li>审核新用户</li>
<li>当客服</li>
<li>写一些推文
等等</li>
</ol>
<p>平时可能会学习并用到的知识,看一些互联网app或者网站的运营策略,比如什么时候出活动呀,如何增加用户体验度啊等等</p>
<h2>2.UI设计人员</h2>
<p>团队的美工大触</p>
<p><strong>写这个之前,UI设计人员需要知道,咱们并不是一个大的互联网公司,所以职责界限并不是很明确,也就是说,UI设计人员也可以想点子,想一些运营的点子</strong></p>
<p>下面写的只是举例哈,<strong>不是规则</strong>。有可能还会做一些其他事情,也不像是下面写的那么“严格”</p>
<ol>
<li>用户界面设计;</li>
<li>负责界面、图标、动画等素材设计;</li>
<li>协助完成一些交互设计。
等等</li>
</ol>
<h2>3.开发人员</h2>
<p>团队的想法实现者</p>
<p><strong>写这个之前,开发人员需要知道,咱们并不是一个大的互联网公司,所以职责界限并不是很明确,也就是说,开发人员也可以想点子,想一些运营的点子,设计一些UI</strong></p>
<ol>
<li>git协同合作</li>
<li>小程序编程实现各种产品方案</li>
<li>在运营人员忙的时候审核新用户</li>
<li>在运营人员忙的时候当客服
等等</li>
</ol>
<h1>三、具体场景举例</h1>
<p>下面举一个具体的应用场景实例来解释:
【在论坛功能中,当用户发布了一个帖子后,有其他用户对其进行评论了,此时<strong>通过微信的“服务通知”功能在微信上通知用户</strong>他的帖子有人评论了,并且也在小程序里推送消息通知。】</p>
<h2>对于这个场景下不同人员的职责,以及需要考虑的事情</h2>
<p>下面由具体到抽象分职责来介绍,运营人员思考的事情比较具体,开发人员思考的事情最为抽象</p>
<h3>1.运营人员的职责</h3>
<p>运营人员要思考的事情和用户以及小程序的整体体验最为密切,也最为具体,所以最先介绍,让大家由易到难的理解不同角色的职责
对于这个场景<strong>【通过微信的“服务通知”功能在微信上通知用户】</strong>。运营人员要思考的是,</p>
<ol>
<li>需不需要通知用户</li>
<li>如果需要通知用户。是只在小程序里通知用户(方案1);还是既在小程序里通知用户也在微信里通知到用户(方案2)。哪种方式用户易于接受</li>
<li>不同方案的优缺点各是什么,比如在本例中:</li>
</ol>
<table>
<thead>
<tr>
<th>方案号</th>
<th>实施方案</th>
<th>优点</th>
<th>缺点</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>只在小程序里通知用户</td>
<td>如果有太多回复不会打扰到用户,只在用户想主动进入小程序查看时才会看到</td>
<td>可能小程序的流量会少一些,因为用户毕竟只是在想起来的时候才看看</td>
</tr>
<tr>
<td>2</td>
<td>既在小程序里通知用户 也在微信里通知用户</td>
<td>可以增加小程序的流量</td>
<td>如果评论通知过于频繁,用户可能会不喜欢,更甚者会直接关闭通知</td>
</tr>
</tbody>
</table>
<h3>2.UI设计人员</h3>
<p>对于这个场景<strong>【通过微信的“服务通知”功能在微信上通知用户】</strong>。UI设计人员要思考的是,
设计怎样的通知样式用户使用起来更方便。
在具体一点就是,假设运营人员在前面的决策中选择了【方案1|只在小程序里通知用户】。</p>
<h4>对于本例,UI设计师思考的事情之①</h4>
<p>是否要在“我的”图标上加个小红点,以及是加小红点还是具体未读通知的条数</p>
<center>![“我的”图标上的未读消息小红点](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/66442da5994a9cec96504618112c1bce)</center>
<center>图1 “我的”图标上的未读消息小红点</center>
<p>如果要加小红点,那小红点的样式是什么样子的,<strong>样式1</strong>上图那种只有一个小红点的样式、<strong>样式2</strong>下图左边那种超过99条显示99+、<strong>样式3</strong>下图右边那样超过1000条才简略显示,1000条以内显示数字</p>
<center>![小红点显示具体未读通知条数](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/9a218134b31f0cef14ea20cc4ff7b259 "小红点显示具体未读通知条数")
图2 小红点显示具体未读通知条数</center>
<h4>对于本例,UI设计师思考的事情之②</h4>
<p>消息的图标需不需要加个小红点,以及小红点的样式(样式同上,不在赘述)</p>
<center>![](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/0f8334b84a0dc711ce889d6c84cd8ad5)
图3 “消息”图标上的未读消息小红点</center>
<h4>对于本例,UI设计师思考的事情之③</h4>
<p>点击进“消息”板块后,具体的通知样式是什么样子的,是下图4,还是图5,还是其他样式</p>
<center>![](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/4ba1b807a614ee1ba782a6090bdbe82b)
图4 消息通知卡片样式一</center>
<center>![](https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/4799b365974febb839f80f2498920bb0)
图5 消息通知卡片样式二</center>
<h3>3.开发人员的职责</h3>
<p>对于这个场景<strong>【通过微信的“服务通知”功能在微信上通知用户】</strong>。开发人员要思考的是,</p>
<h4>①.提前编码</h4>
<p>在知道这个需求后,先写一个版本的代码,此时应该是运营人员刚决定用哪个方案,但是方案还没细化。UI人员更是可能还没想好具体样式是什么样子的,但是开发人员在方案基本清楚后,就可以写代码了。这样可以保证写80%的逻辑代码和页面渲染,方便后续UI设计师设计出良好的样式后,可以只注重样式上的修改,而非再从头开始写逻辑代码。</p>
<h4>②.具体完善</h4>
<p>当UI设计师给出成品稿时,开发人员就可以按照成品稿尽量还原出UI设计师设计出的样式和逻辑。</p>
<hr />
<h3>关于本文</h3>
<p>创建时间:2021.7.26
参考链接:
创建者:快乐小隆</p>