怎么做一个产品工程师？
为什么不叫前端工程师？
前端的定义
- 维基定义：前端是软体系统中直接和用户交互的部分，而后端控制着软件的输出；将软体分为前端和后端是一种将软体不同功能的部分相互分离的抽象。
前端工程师的定义
- 百度：使用 HTML、CSS、JavaScript 等专业技能和工具将产品 UI 设计稿实现成网站产品，涵盖用户 PC 端、移动端网页，处理视觉和交互问题的工程师。
也叫切页面的那个人🙊
什么叫做产品工程师？
- 定义：能够将痛点 / 想法用技术方式转换成产品让其发挥更大的作用
- 边界：不局限于岗位、技术，更注重用技术和产品思路去解决问题
- 过程：痛点 / 想法 -> 产品思路 -> 交互稿 -> 开发 -> 产品 MVP -> 运营
-
素质：同理心、好奇心、逻辑思维、数据敏感、学习能力
痛点 / 想法从何而来？
我有一个点子，就差程序员了😵
并不是只有产品才能做产品
也不是人人都是产品经理
好的产品经理
- 需求判断：对需求的收集 -> 问题分析 -> 管理优先级
- 提出方案：绘制产品流程图 -> 产品原型线框图 -> 产品需求文档
- 项目管理：立项 ->规划 ->执行 ->监控 ->收尾
- 验证上线：确保产品符合需求标准，可以按照心目中的样子推向用户
-
数据分析和运营支持：用户行为、运营效果、财务效果
从前端到产品工程师的转变路径
1. 将每次开发都当做一个产品来做
需求开发反例
- 评审只做接收方，不提产品问题建议
- 不懂业务痛点、数据、最需要解决的问题
- 提测居然还有不少问题
-
仓库文档默认化，你的产品无文档、无演示、无使用说明
2. 从技术产品化入手培养能力
技术产品化反例
- 一句话讲不清楚我这边技术能力是做啥的？
- 勉强自己能用，别人用起来很费劲
-
不好看、拼起来的有一种 Demo 感觉
3. 其实学习 Sketch 比学 Rust 要简单很多
Sketch 技巧
- 有目标的去做一个东西，有问题再去查和学
- 多借鉴好的产品设计思路 dribbble、producthunt
-
熟悉起来后很像用组件库将一个页面拼起来的过程
4. 快速实现最小的产品 MVP
何为产品 MVP？
- 找到 值得 解决的问题，开发出可跑的解决方案，打造最小 可用 产品
- 解决的问题是不是真问题？是不是值得解决？
- 如果是？解决方案是否靠谱，如果靠谱，就去搞最小可用
-
天使用户是否满意、如果满意就产品化、不满意再优化验证或者抛弃
5. 程序员最容易忽视的一环 - 产品运营
小声 bb：妙言 Star 数据怎么看着这么像“作弊”啊🐶
—为啥会这样？
- 妙言其实两年前的就写好了放 github，只是自己用，也在慢慢优化，但是没怎么推广给用户使用
- 今年觉得还可以了，写了 2 篇介绍的文章，就慢慢起来了，至今 5K 左右用户，有不少用户 主动 推荐
- 特别是在国内互联网技术这么卷的情况下，酒香还真的怕巷子深
- 如何将自己的产品友好的推荐给大家是一门学问
如何讲明白一个东西？
假如只有 10min 你怎么介绍你做的东西？
1min 呢？
假如他不是开发呢？
如何判断做的东西是不是有用的？
- 是不是真的可以解决一个很痛的问题？
- 是不是可以给用的来带来一些便利价值？
- 是用的同学是不是很愿意给志同道合的朋友推荐？
- 懒惰指数 ：新产品价值 = （新体验 - 旧体验）- 转化成本
做产品工程师需要注意的点
1. 写代码前将整个路径基本预演一遍
- 一句话讲明白我需要解决的问题
- 我最小版本需要包括哪一些功能
- 我将用什么方案又快又好的完成需求实现
- 上线后，我的使用方是谁？我该怎么被他知道
2. 先有产品框架，再有功能填充
- 厉害的产品在做第 1 次迭代的时候，已经将后面 6 次都想好了
- 判断不加什么功能比加功能要好很多，其实不少需求用户不怎么用
- 如果不加这个功能用户是否就会感到很遗憾？
3. 除了代码之外还有很多重要的点
- 介绍产品的门面、文档等，让人一眼到就喜欢了，回忆下一见钟情
- 和你用户的联系点、交流枢纽、升级、答疑、吸收诉求
- 持续为易用性去优化，争取更多用户的 啊哈时刻
- 功能满足情况下，美 的产品其实也很重要
一些案例
Weex Ui
—
XRender
