从不规范生产套路看效率

发表于 更新于 本文字数： 2.4k 阅读时长 ≈ 2 分钟

标题好像是句废话，” 不规范” 何谈 效率 呢？

  1. 何为效率
  2. 从产品看效率
  3. 从 UI 看效率
  4. 从开发看效率
  5. 从测试看效率

何为效率？

百度百科上大概是这么定义的：是指在给定投入和技术等条件下，最有效地使用资源以满足设定的愿望和需要的评价方式

对我来说最直观的判断方式就是 项目是否有延期 线上是否有 bug

  • 效率有多重要？

    大部分的电子厂工资都是按件计费的，多劳多得，单位时间产出与收入能正比，所以工人们都非常努力 这是自发性行为 所以也是最任怨的。

    对我而言 效率能带来好心情 好状态以及好的生活态 废话 大家都一样 –

从产品看效率
一款产品的成功与否 有多方便的决定因素 产品最终都是面向用户的 一个不能为用户创造价值的产品应该是没有使用价值的，产品本就是提升效率的一种方式

那么 接下来 我要开始吐槽了

如果产品需求不明确或者需求不完整 项目要不要开始做？
一般来说 不要 绝对不要 除非是两个完全不相干的模块 昂 基本也不太可能
但是尼 为了所谓的工期 产品大大一般会这么说 做呗 先做着 我这么单（wu）纯（nai）的 每次都被套路住🤡 然后后来计算工时的时候 ： 哦 你不是从那个什么什么时候就开始了吗？👐🏽
这还不是最主要的，毕竟 时间就像海绵里的水 挤一挤总会有的😂

最主要的当然是改需求啦 这大概是所有产品最擅长的

这两者本质上是没有矛盾的，只不过产品更多的以目标为导向，需求只是手段，而对开发来说 技术是手段 需求是目标 只不过产品更容易主观，比如需求，比如说功能，比如说交互，这些都受到个人经验，眼界，学识很大影响。朝三暮四，朝令夕改，是常有的事情。

说真的
产品的功能、质量、发布时间和需要投入的资源这四者不能都是封闭条件，否则可能无解

而且现在的产品很是聪明啊 需求给了，开始做了，做到最后发现这种情况下不是很合理，简单啊 改呗 反正做到这里我逻辑也捋清楚了，也知道该咋办了产品默想到

呃.. 这两天刚遇到个类似的情况 哦 不好意思，是经常遇到，提测一周也测了一周了，代码上体验版（预上线）了

1
2
3
4
5
6
7
8
9
10
11
产品：咦？这块不是那样儿的吗？怎么是这样的？

开发：？ 前两天不是专门讨论过这个问题吗，这个就是这样儿的！

产品：哦？是吗？ 但是这样儿看起来好诡异啊！就应该是那样儿的 改一下吧

开发：...当初接口设计的就是这样儿的，怎么不早说？这都要上线啦！😩

产品："之前流程没走通 不太清楚这块儿的逻辑，现在改一下吧" 然后就走了

开发：...

还有就是排期

产品经常这么一句话：因为我们的上线时间是 XX 号 测试需要 XX 天 所以 开发排下期吧 ？

…..

排完期之后..

1
2
3
4
5
6
7
8
9
10
11
12
13
产品：昂昂，你这儿不行啊 时间太长了 能不能缩短点

开发：我按工时算的 每一项 都列出来了 不会差太多

产品：这不行啊 因为我们要XX提审 测试需要XX天 所以你必须 XX天提测

开发：这等于 XX 天的工期 你给我压到 XX／2 天

产品：嘿嘿😉

开发：...

开发OS："赶紧开发 为了给测试腾时间😂😭🙈，尼萌给开发时间充足了 问题自然就会少很多好吗 测试好像是最重要的噻"

百度过类似的问题 最好的办法是让产品也学会基础的编程，了解每一个实现都是需要耗费资源的，这样才能基于对有限资源的理解，做出更谨慎的规划。
然而，这基本不可能，所以..

实际上 那些非常紧急的需求，这么一搞成了拖延的第一个关键点

tuxie

从 UI 看效率

呃。对于用户来说 一个产品能不能吸引到你，最浅显也最重要的是眼缘，说俗气点就是颜值
而且 UI 链接 产品与开发 自然也是马虎不得的 深刻理解原型的精髓 然后利用智慧的小脑瓜设计成用户想要的样子，上面说了 他们最重要的工作是 深刻理解原型的精髓，因为 对于美，设计师总是有不一样的定义，就比如 情人眼里出西施

非常不幸 我们 UI 也是必须要吐槽的对象

直接上日常

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
开发：设计小哥，对比原型 是不是缺了一张图

设计：？

开发：搜索中状态

设计：沉默

产品：哦 那个不就是在未搜索的状态基础上把导航去掉吗？还用出图吗？

一分钟后～～

设计：突然扔出来一张图  @开发:好了

开发：瞅了一眼 @设计：嗯 ？不是这样儿的吧

设计：？

开发：把产品的话 @设计：“哦 那个不就是在未搜索的状态基础上把导航去掉吗？还用出图吗？”

设计：沉默

两分钟后～～

设计：扔出来一张图 呐 上传了

开发：嗯 现在才是对的

设计：嗯


类似的事情简直日常

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
上午～

产品：今天周五 需要把UI提的问题都改完

开发：ok

设计：ok

下午～

开发：什么时候有空，当面改

设计：嗯

下午四点～

开发：什么时候有空

设计：现在过去

开发：嗯

改了大概有两个之后 设计被叫走

又过了一个小时～

开发：快下班了 啥时候改尼

设计：今天比较忙 现在可以开始了

开发： 嗯？我看了一下 你拿到的不是最新版吧 好些问题现在不能复现了

设计：哦

一个小时之后

开发：改完了 我下班了啊 今天有点事儿

设计：嗯 好的 下班吧

开发 走了

两个小时后 忙完 开发都到家了～～

产品：@开发：在哪里呢 啥时候回来

开发：？我到家了啊

产品：你咋走了？设计小哥还在等你呢

开发：？我走的时候跟他说了啊 他知道啊

产品：我不是说了今天要改完吗 设计review了 还有一点问题

开发：... 那我明天去加班吧

第二天，到公司之后

开发：在群里@设计@产品 ：这个只有截图看不出来哪有问题噻

设计：沉默

产品：沉默

开发：...

从开发看效率

开发效率无疑存在于两方面

强健的框架支撑与准确的拆分估期

一般情况下是不会延期的 也算是这几个环节当中最可控的

从测试看效率

你理解一个开发只用了一天的功能测试测了四天的心情吗

你理解一个开发用了一周 测试用了 9 个工作日的心痛吗

🙊

结语：💊