建立一款软件产品的一些心得总结

致敬那些保持初衷的软件开发者，推动国内软件发展的开源社区者，这也是自己的愿景和努力方向，在这个过程中追求和寻找软件技术的乐趣。

背景

目前最多的技术依然还是从国外传入，国内的更多是的翻译还有培训传播，国内的基础软件并不是很发达，还有很多进步的空间，自己接触的软件这十年并不长，见到现状有改变，在追赶，过程是不断的突出和展现类似于阿里、百度、腾讯等这些对国内社区产生影响力的产品，同时很多优秀的开源项目，推动国内软件的进步，这些是值得尊重和致敬的。

自己原来的初衷也是把过程的一些研究成果贡献和体现，在这个行业中，以自己的一些经验，给一些团队或者个人提供参考经验，同时可以和国内知名的技术团队或者个人进一步的交流沟通，自我提升，这是开始的初衷。过程也困难很大，而对于自己来说，前期最大的是能让自己的设计理念活下去，不烂尾，不间断，可持续，这是一个过程的完整体现。同时，自己提供了完整的手稿和设计思路开源，希望可以给这块做设计的人员一些参考。

概述

对于软件产品来说，自己开始遇到的概念更多的是项目，或者开发技术，并不是理解一个产品的概念，同时对产品经理或者设计的角色理解比较片面，并不是真正一款产品本身的意义，也是在这个过程中，不断的加深理解，不断的学习。

针对于当前社区的产品，真正的来说，推动行业的进步和发展，解决过程的很多的痛点（这里指的是软件产品），比如Nexus解决了包的问题，Docker解决了容器化管理的问题，Hadoop解决了企业落地大数据的问题等等这些，Jenkins解决团队DevOps的问题等，推动软件行业的进步，同时这些都是国外的社区产品，国内也有类似于Skywalking、Kubeshpere等。自己本身是软件工程专业，对这块的痛点和进步，是更多的理解和体会。

后来发现，每一款产品的背后，都是一个团队很大的付出和努力，过程更多的也需要承受很多的未知挑战，怎么让产品能活下去，而不是变成烂尾，持续输出应该有的能力，类似于ElementUI在前段时间没有维护，很多人也是觉得可惜，以前Dubbo在国内是服务化的代表，各种方面都不比Cloud差，但是前几年突然停止维护，很让人可惜，如果能持续进社区发展，可能Cloud就很难切入，开始也觉得奇怪，但是自己在做的过程发现，要真的去维护一个产品，需要消耗很大的精力，特别是在前期没有任何收益的情况下，能支持下来真的很难，在跟挺多开源项目的作者聊，往往下班或者业余的时候都是排得满的，这里也是致敬国内社区的开发者。

这里阐述从开始社区的开源产品说起，这个过程是怎么建立项目，然后再到新版本闭源，再到商业化，再到目前可以持续输出我们可以输出的产品设计稿一些心得总结：

• 基于一些方法论的自我探索和产品型规划
• 开源到商业化的转变，团队运营和促进可持续性
• 团队后期一些坚持的理念和一些初衷还有输出 从以上几个点进行一产品建设总结，我有我思，以供参考。

过程

过程并不是特别顺利，会遇到很多的问题，也会遇到很多困难，还有很多失误，但是从18年到现在，欣慰的大家还是可以现在，并且还在发力发展期。

基于一些方法论的自我探索和产品型规划

建设产品型软件的思路来自于服务化的一些困难，同时方案查找，发现缺少的挺多，而基于很多企业还有项目的限制，同时也包括自身的限制，进行了产品的定位，把自己的一些经验通过文档和编码和形式进行沉淀和输出，期望可以和同行进行更多的交流，同时也想促进自己的进步。

进行了整体的从产品的方向，架构，技术，编码，前后端，运维，测试，自动化等等进行了一系统的规划，基本上第1年的时候，

这个时间通过结识是一些对软件有兴趣的人，包括一些社区的人员，整体聚合起来的人，都以兴趣为主，本身就是编码出身，开始并不喜欢接触一些商业化的内容，通过前期的容器化还有服务化，同时各类Ops的研究，结合自己本身的经验进行的产品化架构。开始产品化的思维并不是从一开始就存在，而是以前的项目经验和编码中，对自己的一些经验总结和案例总结，包括大学时期的一些经验总结，重复性的编码确实消耗了很多时间，组件化和产品化的能力，会节省很多的时间，不需要重复的建设，这些基本上都是传统项目的痛点。

在本身工作后不断的提升，不想把时间消耗在基础能力的建设上（类似于发布很麻烦），当时在找了很多方案之后，在社区上找不到合适的，另外就是方法论较多，缺少实践的过程和能力，类似于中台、微服务、数据治理等，很多偏向于表面层，网上的资料偏向于demo整合或者一半一半的，没有完整的体系（现在应该比较成熟了）。

基于以上，只能基于各类开源项目还有自身的经验，进行的产品化的建设。

开源到商业化的转变，团队运营和促进可持续性

在前期建设的一年多，手稿和形态基本上已经形成一稿，同时也会发现很多的问题。

一个最明显的问题，可持续性，后来发现，很多开源项目同样面对此类似的问题，可持续性来说，对于一些来说，可能是一阵热风，这个时候兴起某个技术，就会去做这个，然后过了之后，这个就没有了，或者放弃维护，自己同样也面临这个问题。

当然，自己本身来说，并不是特别期望的商业化运作，直白一点的，这个只是业余的经验总结输出和研究，开始并没有需要一定是需要商业化，更多的是经验的分享和社区的交流目的，自己本身的生存收益并不是来源于这块，同时也并没有说这块特别困难。

后来发现，其实坚持做一件事情的，而且能持续的投入的人员是很难的，很多可能面临生活，工作等问题，久了很快最后提交代码的，就只有我这边，社区的会议也减少到几乎没有。在不断的寻找他人一起互相分享学习的时候，基本上都是被冷脸或者闭门的，本身会不断的发展和提升产品的成熟度，过程中接触的人群也普遍不同，但是这个找兴趣团队的过程，确实很难，培养他人起来也很难，一个人孤军会存在莫大的孤独感，大半夜往往也只有你一个，后期也有很多人兴趣的朋友加群加微信讨论，大家没有前期的基础，也很难跟上，基于项目的不断完善，进步过程还需要接触很多架构和思维。

这个状态持续了近大半年，发现这样对原来的产品化和发展形成极大的影响，是在维护，但是这并不是一个健康的发展状态和维护状态。

这个过程意外的是，免费分享的很多并不太喜欢，但是需要商业化支持的却有挺多的，常常会收到一些社区或者厂家的联系，进一步的商业化支持的倒是挺多的（即投资），开始是拒绝的。因为我并不想拉扯上太多的关系，简简单单的互相分享，业余时间的沟通感觉会更好，后来发现，这个太难了。基于上面的情况，自己也不得不反思如何后期如何做这个项目。

在看到其它的开源类项目，为什么可以做到，也想学习，不断参考，后面明白，你并不是那个项目的负责人，你也不是他，每个的条件和环境是不一样的，不能说别人做了淘宝，你也复制他的模式也会成为淘宝，你很难跟得上，需要考虑另一个模式，比如拼多多模式。考虑到项目的持续性和可用性，在跟多家团队负责人商谈后，不断磨合，考虑良久，进行了商业化改变，通过投入人员和项目，进一步的促进项目的可持续性和成熟。

再进一步的产品化能力和团队运营管理。

团队后期一些坚持的理念和一些初衷还有输出 在后期建设的过程，自己要承担的角色和责任可能会有一些变动，但是推动产品化的进程是加速了很多，从0.0.1版本不断的提升到2.1.3版本，不断的跟进当前行业的发展和技术整合，也是做了很多的调整和升级，当然，也做了很多的减法。

与运营团队的配合操作，有一些是远超过我的想像之外的，也消耗了大量的精力，后面有一段时间全身心的投入到里面，开始有考虑过这个过程，也有一定的预期心理准备，同时也需要做很多方面的管理，当然，本身也提升了很多，产品化和项目化也基本上符合预期实现，在这个过程中遇到的问题点，团队的成长还有产品的成熟都基本上能达到预期效果，而且后面维护可以做到保障，这个是自己特别关注的。

在接触的过程中，这几年，也遇到很多中小团队在做类似的内部项目，可能更偏向于内部，这些也是原来的自己想做的经验分享，在当前的网络环境上，也已经有很商业的化的产品，同时也提供了很多方案，但是全套型的依然很少，即从0到1的过程还有最终的效果。

当前在各个方面较为稳定的情况下之后，针对于自己的初衷，考虑左右，梳理了很多过程中的手稿内容，同时梳理了很多过程中手稿，包括产品化设计、架构、思路等，进行输出，希望可以给一些建设过程中的团队一些参考意见，规避过程中的一些坑点，有个方向参考，即从政策、产品、团队、管理、方案、架构、自动化等形成的一套参考方案，当然，每个团队不一样，但是有方向就会规避掉很多的迷茫点，至少会快很多，毕竟这些积累了很多年的架构经验和项目实践经验。

这些是我所带团队能对自己原来初衷的保持和最大化方式，毕竟在涉及到多方之后，你需要考虑很多很多。

收尾

在建设过程中，会遇到很多问题，同时看到国内技术社区的推动，国内社区产生影响力的产品，同时很多优秀的开源项目越来越多，提交到apache的项目也越来越多，推动国内软件的进步，这些是值得尊重和致敬的。

也许在这个过程中，本身并没有达到他们的层面，但是在本身的经验里面，可以做出一定的分享，这是个人能做的。

以上为从零建设软件产品的一些心得总结，以供自我复盘和勉励。