我转产品了-前端转产品是一种什么样的体验

程序之路

入门前端的 3 年，前端技术从 pug/handlebars/jquery 制作各种企业官网，再到 gulp/vue/react/webpack 的工程化开发后台管理、
webapp 。然后是 node/express/koa ，开始涉及全栈。
代码管理工具也从 svn 到 git ，然后制定提交规范，分支管理规范，结合 gitflow/githook 以及各种 lint 保证团队开发风格及可维护
性。
产品发布的方式从 ftp 上传，到 npm/nodejs/shell 脚本，然后再到 jenkins/docker/git 多分支多环境部署。

从第 3 年之后就感觉技术没什么提升了 ，后面都是在各个小作坊担任前端组长角色（其实感觉就是救火队长），哪里项目急去哪里，哪里有难题去哪里。实际比 UI、比测试、比实习产品的地位还低，基本没有话语权。

为什么转产品

严格来说，并不是专门的喜欢产品这个职位，而是希望了解产品经理所做的事。因为在软件开发的工作里，工作的内容和返工程序大大取决与产品对用户需求的理解能力，业务熟悉能力。而作为前端，经常只集中精力在处理页面还原、交互实现、数据对接、浏览器兼容等工作上面。对整个系统的业务逻辑是比较片面的。

如果对用户需求和产品业务有所了解，那可能在开发之前就能发现需求上的不必要性，发现设计上的错误，而减少程序开发的返工率。

总的说来，是期望：

• 
  
• 拒绝无效编程
  
• 深入理解业务
  
• 培养跨部门沟通能力
  
• 培养产品设计能力
  

是否适合转产品

根据上面所说的几点理解，我自身而言并不拒绝，这是在心理方面。

在能力方面，我认为我是可以去学习和培养得到这份能力的。因为自己做的一个程序库 demo，得到了第一份前端工作。前端工作 2 年后，老板尝试让我做产品，并在过程中得到老板的一些建议。1、做产品就不要去考虑程序实现；2、如果自己是对的，就要去坚持，争执得面红耳赤也没有关系。对于这两点建议现在我是如何理解的，后面我会讲。

在习惯方面，我经常会吐槽 xx 产品应如何实现，经常觉得 xx 产品很难用，也经常自己开发 xx 小工具。当然这里我想说：人人都是产品经理，我是认可这句话的。因为产品的受众就是大众，而大众的感受就是产品。至于我自己的 xx 小工具，当然也会被吐槽，不过我觉得这并不影响“喜欢做产品”这个习惯，而做出好产品，是在做产品的过程中去获得的能力。

如何得到这份工作

严格意义上的这份工作，大家都知道一般而言薪资是比开发要低一些的。我说下我能给到的：

• 
  
• 接受作为入门岗产品的薪资，不考虑自己的开发经验的工资
  
• 能陪开发一起加班，一起赶项目
  
• 能在与客户的需求讨论阶段，通过自己的开发经验给出符合客户所需和较低开发成本的解决方案
  
• 能处理好产品核心的工作，例如需求文档、原型设计等(仅限于我当前对产品职务的了解)
  
• 必要时可为前端团队提供技术方案
  

真正意义的产品岗的入门工作

我入职这家公司，公司管理层有征求我的意见。问公司现在缺产品，把我拉来填这个位置，问我的想法之类。我接受之后，在这个公司的职位就正式为产品了。

前期的工作，是与另一个兼职的产品去客户现场去了解需求，我做会议纪要，每场会我都在。

领导的意思是，因为兼职的那个产品可能会照顾不到。所以期望我今后能全权接受他手上的项目和往后的产品项目。

另一个公司的项目是两个团队开发的，公司一个团队，公司外部一个团队。这个项目有二期，计划我来接手二期。因为一期临近上线，把我接去做测试，说是我也刚好可以熟悉一下这个项目。虽然在之前我的理解中，产品就是产品，测试就是测试，心里多少有一点抵触。但想到确实在测试过程中多少可以增加对系统的了解，也坦然接受了。

然后在临近上线时，客户认为当前的产品流程不符合需要。需要修改流程，还要增加一个额外的流程。本来项目时间有所有延后，又加上客户添加需求，所以双方决定延后半月上线，但要添加新的流程以及再加一个二期功能。

这个二期功能中有一个拓客功能就是我将来要设计的模块。现在相当于我要提前介入。

不过好在这个系统的客户都还比较好相处，在客户现场做测试、改 BUG、讨论需求的这几天里，经常各种好吃好喝的东西都拿过来。饭点也问大家的口味情况，不重样的给大家点餐。系统有不少的问题，客户也没发脾气（这个我至今没理解）。

一个拓客模块原型

在我的构思中，是打算把整个拓客功能高度抽象化，尽量减少与原系统的耦合度。希望将来其他系统能便于复用这个模块，因为拓客功能是面向 C 端程序常见需求，并且流程也容易标准化。

所以构思了很多东西。

当与客户讲了这些东西之后，客户表示很多东西都有考虑到位。当然也有客户的自己侧重点的东西和必要上的东西的考量，这些东西在前期可能作为产品是比较难感知到的。

与客户讨论需求的部分心得

心得来源于分歧。

虽然这次需求沟通总的来说达到了自己的预取。但这边负责人后面批评了我，所为什么我要给客户讲这么多东西？为什么要答应他们？我们做不完！

我说我没有答应他们什么，我只是尽可能的去了解客户想做的，和让客户知道我想做的。后面我有意识到，由于这个模块是在这半月之类要临时加上去的，负责人害怕客户会认为我给他讲的那些功能就是这半月之类要上的功能。

所以，在这种情况下，在与客户表达功能的同时，要避免客户对功能产生错误的预期。

所以我后面单独找客户聊了，由于时间紧迫，之前给他讲的那些功能并不能完全实现。然后给他展示我这边能给到的一个满足他拓客条件的简化版本。客户表示理解，欣然接受，这个简化版本也与团队进行了同步，没什么问题。

另外，对于一个功能的实现，有很多做法和分支。我们不用一开始做得很细，当与客户沟通，得到客户想做的方向之后（当然客户想做的方向不一定正确，而如何能提前知道客户的方向不正确，这可能是更上一层的能力，比客户更了解客户所面临的问题）。

一个需求文档

拓客所处的项目第一期进行了近一年左右，神奇的是居然没有还没有需求文档。现在项目要上线了，负责人要去找客户结账了才想到要这文档。然后这文档让我来写，对于半路介入这个项目并且刚试岗这个职位的我来说简直头皮发麻。因为据我了解需求文档这东西巨细无遗，需要深入到系统的每个流程和细节。

谁让我现在是这个角色，我不入地狱谁入地狱？随后我反手就找公司把公司的需求文档模板发我一下。模板发了，但我一眼看过去，只知道需要填些什么内容，像是一个骷髅，却想不有内容的样子应会是怎样的，不知道一个有血肉甚至是有灵魂的样子是怎样的。

然后又让公司把以前的其他项目发我一份。然后公司随手发我一份，我打开一看，好家伙，161 页，部分内容如下：

以我之前的了解，需求文档这东西主要是用于验收的（实际开发中需求文档根本来不及跟上需求的变化）。而验收时为了表达工作量，需求文档通常都是内容越多越好。

所以这真也是个体力活。

为了让需求文本能与现有的实现相符合，我打开了现在的系统，现在的系统有些流程还跑不通，然后又根据我的之前的测试结果和现有原型的理解，进行梳理，先把页面和功能拉出来，大概如下：

# 后台管理系统

- 登录

  - 用户名

  - 密码

  - 验证码

  - 记住密码

- 系统管理

  - 区域架构

    - 展开和折叠

    - 上级区域

    - 名称

    - 排序

    - 状态是启用还是停用

    - 区域层级

    - 搜索 -- 名称、层级、状态

......

......

......


# 小程序

- 推广中心

  - 统计面板

    - 奖励总金额 -- 考虑隐私问题暂不展示应邀人员的细目

    - 注册人数 -- 考虑隐私问题暂不展示应邀人员的细目

    - 去提现 -- 跳转到体现页面

  - 去提现

    - 展示总的可提现金额

    - 输入想提现的金额发起提现申请

    - 展示提现申请记录


- 登录

  - 有手机号时授权登录

  - 无需要号时通过验证码登录，并进行实名认证

  - 设置安全密码

......

......

......

然后根据页面和功能点去展开描述。具了解，需求文档需要包含以下内容：

- 产品概述

- 功能概述

- 用户需求

- 功能分析

- 非功能性需求

- 界面设计

- 数据需求

- 约束和假设

而在功能需求中，有几点是常见的：

- 功能概述

- 功能分析

- 界面设计

- 数据需求

看起来就是功能概括是怎样的？功能具体是怎样的？界面怎样的？数据库设计是怎样的？

很明显，数据库设计这个我暂时细致不了，而且我看现有的需求文档中也不是每个功能都把数据库设计放上去的。总之我认为，能基本把功能描述清楚，看起来够分量就行啦。

那么基于上面我列出的功能结构，例如：

- 登录

  - 用户名

  - 密码

  - 验证码

  - 记住密码

是很容易能推导出来：

- 功能概述

- 功能分析

- 界面设计

这东西的：

### 功能概述

本功能旨在提供用户登录系统的功能，包括输入用户名、密码和验证码，并提供记住密码的选项。


### 功能分析

用户登录功能主要涉及以下几个要素：


1. 用户名：用户需要输入其注册时使用的用户名。

2. 密码：用户需要输入与用户名对应的密码。密码应该以安全的方式进行存储和传输，例如使用哈希算法进行加密。

3. 验证码：为了增加登录的安全性，可以添加验证码功能，要求用户输入验证码。验证码通常是由字母和数字组成的随机字符串，用于验证用户的真实性。

4. 记住密码：提供一个选项，让用户选择是否记住密码。如果用户选择记住密码，下次登录时系统会自动填充用户名和密码。


### 界面设计

用户登录界面应包含以下元素：


- 用户名输入框：用于输入用户名。

- 密码输入框：用于输入密码。密码应以隐藏或替代字符的形式显示。

- 验证码输入框：用于输入显示的验证码。

- 验证码图片：用于显示验证码的图像，以便用户看到并输入。

- 记住密码复选框：用于让用户选择是否记住密码。

- 登录按钮：用户点击此按钮以提交登录表单并尝试登录系统。

然后我就以这种方式完成了 98 页的需求文档，这样应该能先交差一版了。