做产品开发的感想

　　还有三个月的时间，工作就两年了。在此期间收获了很多东西，特别是对平台产品的开发有了比较深刻的理解和认识，在此做个总结，一是通过总结归纳来完善和提高自己，而是希望和大家分享经验，交流感想。

　　两年的时间不长不短，在这段时间里，通过bug的修改、功能点的开发、模块开发到整个产品的开发维护过程让我对现在的产品有了很全面深刻的理解，如果说前面的路是铺垫，是相对平坦自己能够轻松胜任的，那么现在的工作就是挑战，需要通过不断的提高完善自身来出色的完成自己的工作。

　　从目前的经验和专业水平来说，我觉得做好平台产品，需要从以下几个方面下功夫：

1. 定位和发展路线

　　定位和发展路线用一句话来概括就是：要做什么，分那几步做。以目前做的工作流为例，国外的工作流产品和国内的产品所实现的业务模型是有区别的，国内的工作流产品中针对企业的和针对政府的业务模型是不同的，而政府中协同办公和行政执法的业务模型还不一样。假如现在要做工作流的产品，我们就需要考虑这款产品针对的市场是什么？以后还有可能向那些行业或者市场扩展？这些行业和市场的共性有哪些？如何从当前主要市场扩展到相关市场？要搞清楚这些问题，就需要进行调研，研究目标市场和相关市场的企业或者政府的办事流程，将其主要的工作流程进行分析，提炼业务模型，找到流程中的共性，同时结合现有的相关标准，决定自己要实现的工作流业务模型。业务模型确定之后，需要根据目前市场、内部资源配置等情况，制定产品的发展路线。

2. 架构

　　业务模型和路线确定之后，接下来就是进行实现了。不管是迭代开发还是瀑布式开发，首先需要确定产品架构，也就是对业务模型进行建模，确定支持业务模型的技术模型。建模的过程中我们首先要保证该技术模型能够满足之前确立的核心业务模型，同时需要为以后的业务扩展方向预留必要的接口，以满足后期市场拓展的需求。技术模型的确立需要不断的验证和改进，因为几乎没人可以一次性的完成一个产品的架构，并且保证这个架构就是准确、健壮、可扩展、易维护的；所以需要通过原型开发和场景检验工作来验证、改进架构的准确、扩展和可维护性。架构一旦确立，后期改动的成本就很高了，所以一定要甚重，充分考虑到当前的可配置资源（人员、成本、技术平台、开发周期等）以及后期的业务拓展和相关标准支持。

　　3. 质量

质量是产品的生命线，功能再强大的产品，如果没有质量做保证，那也是浮云，最终会磨灭在时间的轨迹中，所以要想自己走的更远，就需要把好质量关，从开发的起始阶段就要做好测试工作。良好的测试需要合理的过程规范，保证我们所有的每一步都是正确的，都是一步一个脚印的。首先我们要保证新功能的正确性，确保我们开发的成果是满足用户需求的，是健壮的、易用的。通过相关测试部门的功能性验证，基本能够达到这个效果。其次需要保证新功能增加之后，已有的接口或者功能是正确的，不受影响的。这个工作如果通过测试人员来完成，那么工作量是随时间快速增长的，在人力和成本有限的情况下这显然是行不通的，所以我们需要自动化的测试工具来完成此项工作。单元测试是个不错的选择，虽然开始进行单元测试会有些不适应，而且这会牵涉一部分的精力，但是相对于后期带来的收益，这部分的付出还是相当有价值的。完成了这些工作，我们基本能够保证给产品的每次升级都是正确的，当然产品升级包也是需要进行相关测试来验证的。

4. 性能

　　在保证质量的前提下，性能的提升是产品必须要做的事情，长时间的等待是令人难以忍受的。当然，这也取决于产品的定位，如果数据量本身就不大，那可能性能提升的价值就没有那么高。但是，如果每天的数据量就有上万，那么可能很小的失误就能带来几秒甚至十几秒的延迟，这直接决定了用户体验，进而影响客户对产品的看法，最终决定了产品的生存能力；同时，性能提升也需要甚重，千万不能不升反降。要提升性能，我们首先要有依据，找到影响性能的瓶颈，然后我们才能够有的放矢。通过完善的压力测试可以达到这一个目的，找到瓶颈，进而保证产品能够满足用户数据量、访问量的需求。

5. 文档支持

　　好的产品，离不开完善文档的支撑。再好的东西，如果别人不知道怎么用，那也是扯淡，所以不仅要code，还需要写文档，虽然大多数的编码人员厌烦写文档。但是如果我们抱着提高自己、完善自己的心态去做这件事情，或许文档并没有我们想象中的那么枯燥。完成自己的功能，教会别人去使用这也是一件很快乐的事情。同时，如果文档很麻烦，步骤很多，那可能易用性就有问题，或许通过写文档可以让自己的产品在细节上做的更好一些。《开发指南》，《api接口》，《功能示例文档》，《faq》这些应该是每个产品必备的内容。

6. 需求控制

　　产品开发完成之后，并不是就可以高枕无忧了，我们需要面对其他产品的竞争，需要在日益恶化的市场上站稳脚跟就需要通过项目反馈来不断提升自己的产品。项目反馈的问题自然不用说了，这些都是必须要解决的问题，但是对于来自于项目上的需求就需要慎重的处理，不是每个需求都是合理的，不是每个需求都是可以做的，不是每个需求都是放到产品中的。 这里说的合理性，需要对业务的把握，因为大多数的用户在表述他们所需的时候，并不能准确、真实的反映他们对信息系统的要求，这就需要通过经验和对业务的理解来引导客户，确定用户的真实需求。有些情况下，需求甚至是开发人员自己想象出来的，这对中间件平台开发者来说是家常便饭，这个时候更需要保持清醒，弄清楚真正的客户需求是什么。

　　哪些需求可以做，哪些不可以做，这个在弄清楚真实的客户需求之后就很明了了。但是可以做的需求却不一定要放到产品中，因为产品可能面对比较多的市场，不同的市场有自己个性化的需求，这些个性化的需求很可能有冲突，即使没有冲突，放到产品中也会影响产品的稳定和扩展性，将业务和产品绑定，影响到后期的发展和维护。所以对于需求的处理，一定是共性的东西才能放到产品中，同时对于个性的东西做好扩展接口。

7. 产品比较

　　任何时候都需要知己知彼，这样才能更好的活下去，任何时候都不能固步自封，对竞争产品不予重视，相反的，我们应该及时掌握竞争产品的动态，了解、理解竞争产品，取其长处，补己短处。

8. 标准研究

　　在国际化的大形势下，产品必须要有长远的眼光，很多东西老外比我们有经验，比我们先进，而标准是领域专家经验和思想的结晶，通过对相关标准的研究，我们能够把握目前国际上相关领域产品的发展方向，感知先进的思想。标准能够让我们少走弯路，提高产品的通用性和用户认可度，提供产品的竞争力。