一个输入框你要做一周？

如果PO说这是个很小的改动，你不要信他

一次有争议的估点

在某次迭代会议上，PO希望交付这样一个“简单”功能：在应用中，用户可以输入自己的地址，这样我们可以定期邮寄一些宣传册给用户。

按照PO的描述，这只是一个很简单的文本输入框，用户填写地址之后，地址信息随着其他个人信息一起存到数据库即可。PO甚至在白板上画了一个不太规则的长方形作为示意，然后满怀期望的将目光投向了你 — 一个做事情还算靠谱的开发 - 友善的问道：“你觉得实现这样一个输入框，需要多长时间？如果你觉得太小的话，我们是不是可以在做其他卡的时候顺手做了？”。

你定了定神，在脑海里大致验算了一遍，说：“嗯，我觉得在理想情况下，大概需要五、六天。如果算上开会……”。

“什么？这样一个输入框你要用一周？！”，PO敲着白板上那个不规则的长方形问道。

“呃……，我说的是理想情况，实际上应该会比这个时间更长……”

“……"

如果你有过和非技术出身的PO（或者站得太高而忘记地面是什么样子的架构师）一起工作过，大约很大程度上有过类似的经历。通常来说，预期有这么大的偏差，很可能是大家说的并不是同一件事儿：要么是PO想的过于简单，要么是开发想的过于复杂。

遗漏掉的细节

由于专业知识的屏障，以及对细节的过度简化，使得非专业人士往往会低估完成某项工作所需要的工作量。另一方面，对于专业人士自身，如果忽略了外部环境中客观存在的阻力，同样会对实际工作量产生错误的判断。

“简单”的输入框

在PO眼中，一个普通的文本输入框大约长这个样子：

输入之后，传到后端保存一下就完事儿了。当然，可能还需要一些必要的校验，比如长度不能太短或者太长，地址遵循一定的格式之类。

不那么简单的输入框

不过在一个有经验的开发眼里，一个“普通”的文本输入框是这样的：

显然它拥有更多的状态，也更加复杂：

• 禁用状态
• 内容为空的时候
• 设置焦点之后的状态
• 非法输入状态
• 提示信息（helperText）
• 可用性（Accessibility）
• 其他状态

通常来说，在初始状态下，输入框会显示一个占位符。当用户开始输入时，需要有各种各样的反馈：拼写错误、太