2015.9.29国庆前夕，庆幸新的项目按时完成，在此总结经验教训，希望以后遇到类似的情况，能做得更好。倘若我稚嫩的言论对正在阅读的你有所帮助，那是我莫大的荣幸。
项目概述：我负责的产品时一款母婴垂直领域的社交电商产品，以电商功能为起点，现在着重打造社交模块，希望能通过社交电商特有优势，在众多竞品中站稳脚跟。社交是我们现有的短板，之前有过一次小的社交功能试水，效果不理想。在最近比较看好的图片社交的带领下，我们“理所当然”地用图片社交作为突破口。借助之前’晒单“的产品需求，二者融合，产生了移动端去写博客（类似简书或Lofter)，并且能对图片裁剪，加标签，加滤镜处理（类似nice和in)。这里不分析（吐槽）需求的真伪性和产品路线问题，单论自己这一路踩了多少坑，以警醒自己。
项目开始之前，程序员和我都认为滤镜是整个模块的难点，实际上，找到滤镜Demo之后，发现滤镜可以通过颜色矩阵的调试实现，程序员不懂滤镜颜色调试，但是视觉设计懂，在工具的帮助下，视觉设计不断地调试颜色，终于调试出想要的效果，而且颜色矩阵之上还可以叠加蒙版效果，最后滤镜的效果十分满意，这反而成为整个项目中最容易的一环。
自己犯的错：滤镜对于我和程序员都是未知的挑战，在开发之前，对滤镜的实现原理不求甚解，导致在跟领导回复时，只能回复：”滤镜效果只能程序员在网上找到什么效果就实现什么效果，没有更多选择。“而找到的效果都很差，不能我们自己调试。其实，自己明明对接程序员和视觉设计，却没有捅破这一层窗户纸，最后领导出面解决，是整个项目最大的教训与收获。今后千万要求甚解，多思考，走未走之路。
项目评审时，自己设计的是图片统一裁剪为1:1尺寸处理，这样会节省时间，然老板反驳，为什么裁剪成1：1，我觉得1:1并不好看。当时回复这样最简单的处理是平衡了视觉和可实现性，后面可以扩展为支持等比缩放。最后，没说服老板。在开发过程中，因为图片比例问题，出了太多太多乱子，如果当初坚持1:1，整个开发的时间可以节约30%。后面遇到类似的问题，可以借这段苦逼的经历，用数据说服老板了...
下图是In图片处理的界面，大家保留裁剪，滤镜和标签功能后，去除其他功能，就是我们处理图片的界面。和其他线性图片处理的产品不同，裁剪，滤镜和标签这个三个任务采用平行处理的设计。这比线性处理复杂很多，去计算边界值，图片小了，大了，不规则如何处理，裁剪了之后，加标签怎么处理，这两两组合，产生太多逻辑去判断。
MicrosoftInternetExplorer402DocumentNotSpecified7.8 磅Normal0
在整个新功能的任务线中，处理图片只占涉及图片模块的三分之一。余下编辑页面和显示页面也都和图片相关联。而这三个页面在开发过程中是由三个不同的人完成。从产品的逻辑出发，处理图片上面的滤镜效果，裁剪，标签显示，和编辑页面以及详情页要一致，再扩大一步，IOS上处理的图片要在Android和触屏版上一致，所以整个开发团队在算法处理上要保持一致，而且事先就要选择最好的方案，以避免标签位置偏移的现象。不幸的是，IOS 团队缺乏沟通，三个人未保持一致，快上线时，发现在IOS上处理的图片在触屏板上位置不对。更粗心的是，处理图片的开发人员，在对标签的位置计算时，不是针对处理后的图片，而是针对原图，这就造成一旦使用裁剪功能，再次添加标签，位置就会出现偏差。
事后总结这段经历，IOS负责图片处理的开发不愿沟通是造成损失的部分原因，IOS上的问题很多都是在和Android开发人员沟通中发现的。自己想的不够细，没有经验是另外一部分原因。
最后再谈谈对这个功能的看法：
结论是新功能很难玩起来，参与门槛太高。
这个功能的需求起点是晒单，Boss是微博达人出身，所以想在产品上做粉丝经济。用达人的概念带领产品。起点并无对错。
隐患在于产品设计时，已经是一个操作复杂的功能（酷炫的富文本编辑，加上图片的三度处理）。而Boss认为我们在产品形态上模仿微博，显示140个字，就可以兼顾轻微博的模式。
然而，本来移动端就不适合写作的特性，加上多分支的功能设计，使得产品设计与产品意愿相违背，在这种矛盾下，我们的社区能否热闹起来，我自己心中也画了一个大大的问号。
最后，为自己的产品祈祷。
网友评论