[思考记录]技术思维&产品思维

        在选择邮件服务的开源解决方案时，从一大波方案中筛出来一新一老两套方案。经过前段时间的实际体验，记录下当前自己的一些感受。

        这个老牌方案是极度的“模块化”，感觉上整体是偏技术思维。而新兴的项目则“是一体化综合解决方案”，更偏产品思维。前者，由多个开源项目配合实现，每个项目都只负责单一的模块；后者，提供了集管理于一体的综合方案，更注重邮件服务的全面性和易用性。

        采用老牌方案，想要实际用起来，通常要三个核心模块的搭配。如果需要更多功能，则可以继续搭配更多模块，且大概率有现成的开源项目提供支持。这种模块化设计具有诸多优势，如方便灵活搭配、各模块专业性强。用户可以根据需求选择部署的模块数量，简单使用可以少部署，追求功能或有特殊用途则可额外搭配，满足各种需求。各团队也能专注于自己的模块，不断将其优化至极致。

        然而，这些优势可能更多是从技术的角度在考虑。但从产品角度看，正是这些“技术优势”带来了相应的劣势。
1、灵活搭配虽然提供了更多选择，但对于大多数使用者来说，我们可能只是需要一套常用的邮件服务方案，而非自行搭配各种模块。感觉像极了早期个人电脑的兼容机——大多数人只是想要一台好用的电脑，而不愿意花费时间学习基础知识并自行攒机。
2、各个专职模块可能导致多方成本增加及一致性降低。当功能特性贯穿多个模块时，模块间需要制定交互标准并进行协商确认，变更后还可能涉及复杂的兼容问题。这不仅增加开发成本，更给使用者带来额外的配置和维护成本。在模块化思维下，各模块可能更关注自身功能的强大，而忽视了整体解决方案的完整性及易用性。

        当然，也有开源项目将相应模块打包集成。但我目前所感受到的，仅仅是部署方便、封装提供了一点管理功能，并未达到质变的效果。而新兴项目则似乎综合了以上优缺点，所以我是还蛮看好和期待它的发展。或许不久的将来，我们会有机会切换过去。

乱想记录：
1、做产品与做技术确实存在不同。老牌项目更像是技术大佬们低头打磨各自的那一块功能，不断在框架内精进技术与功能，却少了些关注用户的心。而新兴项目则更像是做产品，从整体视角去看待问题，除了技术外，更注重产品应该做成什么样、如何融合新技术和资源来提供良好的用户体验。
2、同样做产品，产品思维对技术思维是种降维打击？两个方案，如果都同样成熟，我必然会投票给偏产品思维的新兴方案。
3、技术这条路上，即便拥有再好的过往履历和壁垒，如果在创新上停滞不前，也可能面临倾覆的风险。就像邮件这种看似技术相对固化的领域，仍然有新兴项目能去冲击已发展完善二十多年的大牌项目。时代在变，技术在更替，更需要我们以发展和动态的眼光去看待事务、并审视已经存在的东西。否则，被淘汰会是迟早的事。