技术能力

能力：
1.绘制产品原型图，交互说明标注，动态交互
2.搭建及整理需求池，撰写并修订prd文档
3.协同技术人员敏捷开发
4.逻辑梳理清晰明了
5.整合需求排序，排列优先级，定出排期
6.APP整体视觉走查
7.参与测试APP整体功能及体验
8.配合运营团队面向活动设定板块

一般的日常工作分两部分，

1.对产品现在要做的事情；

2.对产品将来要做的事情。

对产品将来要做的事情有以下几点：

1. 用户调研

a. 前期的焦点小组-即群P：调研可以理解成：找5，6个不是你团队的专业人员，一个会议室，拟定一个话题一组问题，大家胡侃乱绉可以但别跑题太远，定时1到2个小时，你团队派一个话题引导人moderator,一个记录员recorder参加。

b. 前期的Interview，即单挑：简单的一对一问询

c. 前期的问卷调查

2. 竞品分析

分析竞品当时的目标是什么，当时是如何做的，从开始到现在经历了哪些变化，以及未来的规划是什么，如果有可能尽量拿到UV，PV，DAU等等。

3. 数据分析

流量、用户的分析。这两个拓展了就是流量多少，流量从哪儿来的，哪些搜索关键词带来的流量。访客的分析那就是多少人过来访问，新增了多少人，多少人是来客户。

除了这些就是结合具体的互联网产品做的分析，来你的网站的用户是带着需求来的，是买东西？是得到某种服务？那就看这项服务有没有完成和实现，转化是不是顺利？这个叫转化的分析。

如果是搜索引擎，视频这种服务，服务是没有成本的。如果是电商，你卖的东西有成本，你要分析哪些商品赚钱多，哪些东西赚钱少，哪些东西好卖，哪些东西如何定价，哪些东西怎么采用打折的方式更吸引用户。这个就不是电商分析了，就有点像零售和销售的分析了

除此之外有些网站靠广告挣钱，要看你家的广告被点了多少次。这个结合用户，广告的类型，位置几个维度分析。

4. 需求整理

将上述的几点中得到的一些数据和一些想法，整理成产品文档，产品文档包括逻辑图，PRD，思维导图等等。

对产品现在要做的事情，跟技术的同学们配合的比较多一些：

1. 项目进度把控。

2. 跟踪现有产品的功能和BUG

项目经验

一、了解系统现状
1.描述

首先要解决，这个系统解决的核心问题是什么？这个核心要足够的简单，例如仓储就是解决货在哪里的问题，核算系统就是解决钱被谁花了等等。足够的简单，才能明确系统的边界。

然后围绕这个核心，去梳理现在这个系统的现状，有哪些功能不属于这个系统但是因为历史原因包含这个系统里面去了，导致没有进行良好的业务解耦；有哪些功能是这个系统应该有的，但是因为历史原因一直没有做；现在系统应该包含的功能，优先级是什么样的，哪些是核心？这个都需要考虑

2.涉及人

系统当前使用者、系统的测试和研发、以及其他产品

3.输出

这个阶段应该输出系统现状流程图，系统现在的异常流及其处理方式，系统现在已有的需求池及其优先级。

二、明确系统正确的玩法
1.描述

现在的系统因为各种原因，总会有这种或者那种问题。这个时候需要有人知道这个系统最正确的玩法是什么，最理想的情况应该是怎么设计的。

这个过程的难度是很高的，我个人的方式是先自己调研竞品和业内其他资深人士，然后出一个方案。再拿着这个方案跟公司相关负责人不断的碰撞这个事情。最终确定一个比较理想的系统设计方案。

好的系统设计是契合现实世界的模型的，好的系统设计是足够的简单。例如商品促销的核心就是商品改价，实际只是改价的形式不同，但总绕不开这个本质，然后再将改价结果记录到订单维度，进行促销核算即可。

2.涉及人

业务部门负责人、产品负责人和研发负责人等有决策权的相关人。业内竞品和业内其他资深人士等

3.输出

理想系统结构图、理想系统流程图、系统与其他系统的边界与交互方式

三、结合现状，明确路线图
1. 描述

现状已有，理想蓝图也有了，之后就是一步步实现这个蓝图。这个时候，需要重点考虑两部分东西：一是业务需求的优先级，保证业务仍能够快速发展；二是在系统开发上，确保骨架是逐步搭架好的，不能频繁重构系统。

这个部分的重点是理解业务发展，对于公司整个阶段要有自己的理解。并且需要跟研发负责人沟通，看如何保证系统的骨架是逐步搭建的，不要给自己挖坑。

2. 涉及人

业务部门负责人、业务部门使用人、研发负责人和测试负责人

3. 输出

产品路线图，未来一个月、一个季度、一年做什么做到什么程度。

四、明确下个版本，正式开动
1. 描述

梳理了那么多，现在正式开始落地，下个版本我们要做什么功能，需要怎么进行设计，PRD设计是怎么样的，时间点是怎么样的，预期效果是什么。前面梳理了清楚之后，这一步的梳理相对简单。

前面的工作都是为这一步打基础，保证系统的重新设计是足够得到共识的，有足够的资源做这些事情。但是在实际上，需求可能很多，如何安抚各个业务方的情绪是很重要的一点。所以在重新设计过程中，最好能够做一些亮点功能，影响面小，但是能够极大提升业务方的效率，降低新系统的推广难度。

2. 涉及人

业务部门使用人、研发和测试

3. 输出

产品设计文档、需求设计文档、项目计划表

推动与沟通
在系统重新设计中，涉及的方方面面多，而且每个人都有自己的想法和见解，沟通成本很大。所以这部分也踩了比较多的坑，单独总结一下。

一、蓝图共识
针对蓝图共识，难度很高，这部分单独说。因为这部分个人能力不够的时候，非常难以达成共识。因为不同的人站的角度不同，理解事物的方式不同，每个人需要优先确保自己系统/业务，所以沟通成本很高。
这个时候，建议自己先出想法，然后找沟通和输出能力很强的人，帮忙进行输出（通常这个人就是你leader）。然后在产品内部达成沟通，保证系统的产品设计没有问题。然后根据路线图，再与业务方聊，看蓝图是否需要进行修正，进一步达成共识。

二、产品内共识
产品与产品直接的沟通时相对高效的，理解的方式相对统一，而且彼此都能从整体的系统设计上，较宏观的方面考虑这些事情，提出比较中肯的意见，完善系统设计。所以建议先在产品内进行共识的达成。

三、产研共识
因为是系统设计，需要研发弄清楚目前的系统现状，各个系统耦合的程度，评估新系统设计的合理性。在与研发沟通时，最佳的方式，与研发的架构师或者类似架构师的角色直接沟通即可。不建议与各个系统的研发单独沟通，单独达成共识，这样的沟通成本很高，而且在重新设计后，还需要跟他们一群人不断核实，效率较低。

四、业务方共识
在系统设计没有完成前，需要与业务方不断的聊，集中聊需求场景和未来的规划，尽量不要让业务方自己设计系统（业务方能力超强除外）。然后通过产品共识和产研共识之后，整理出系统设计的方案，再跟业务方根据已经设计出的系统聊，讨论系统合理性和查漏补缺。因为有个实际具体的初案以后，业务方可能才想会完

团队情况