企业官网建设流程全解析

最近听到一句话，感触很深：
“你们做的这些竞争力特性，就算不用我这个产品，我的产品也照样卖”
一台手机上的功能，能被用户真正使用的功能是很少的一部分，有 20% 吗？就当有 20%，那么还有 80% 的功能都在干什么呢？
扎心的是：开发这些功能的费用是分摊到这台手机设备上的。
用户真的需要这些功能吗？还有更扎心的是，一旦功能特性上线之后，就很难被“日落”掉。

原因一：特性曾经受益者的直接或者间接的“阻挠”

如果特性日落，就说明当初推动这个特性上线的“领导/专家”决策有问题，当初给这些“竞争力特性”发的一些奖励，都成了笑话。谁来承担这个后果，万一这个特性是哪个一级/二级/三级部门的领导呢？每次想到这里，都觉得天天喊的一些价值观：诚信、以消费者为中心等等，都真的只是口号，践行起来，困难重重。

原因二：对产品经理来说，费力不讨好的“额外工作”

对于推动日落这个特性的人来说，后续的工作也非常麻烦

1. 到各种评审会上去说明日落这个特性的理由，并获得各个产品线相关领导的同意。这种会议通常很多，至少 3+。基本上你要准备：特性的过去半年/一年的使用率、留存率、日活、月活、NPS、NSS，评估特性日落不会产生舆情/舆情可控。
2. 评估一下日落特性的详细应对方案，例如对于升级产品来说是否还继续保留这个特性？对于从带有这个特性的产品通过数据 clone 到新的产品之后，是否要继续保留这个特性？
3. 针对日落这个特性，要给一线客服提供 FAQ，有用户热线询问的时候，能在一线客服就闭环。
4. 制定好特性日落时的舆情监控策略，安排好相关人，及时闭环现网舆情，防止舆情等级上升。
   这个工作顺利将特性日落并不会给你带来多少好处，一旦出了问题，反而会背锅。

原因三：对开发团队来说，减少投入的目标秒变双重压力

本来日落特性，可以为开发团队减负，因为减少了维护的特性，节省这部分人力。但是一旦升级产品还要保留这个特性，就给开发团队增加了额外的工作量，每次动这个特性相关的代码（随着时间推移，软件架构腐化，共用部分的代码变动），就得测试两种情况是否有影响。

总结：日落特性，对于开发团队来说，也是出力不讨好，还是干一些产品的买点、卖点特性，绩效才能更好一些。 当你在绩效输出中写上半年日落2个特性，其中一个引起C类舆情，尽管你付出很多，但是最终的绩效一定是不好的，那么谁还愿意做这些处理不讨好的事情呢？