je专家挺多，想多请教一下

楼主这个平台究竟是打算给普通用户用还是给开发人员用？

在我看来两者都不适合，最适合的用户应该是系统管理员之类的人，既然如此，一开始就不要考虑针对不同的用户提供不同的工具，那样只会无端增加工作量。

YES。

也考虑过研发这类平台的问题，正是基于上述原因，后来就放弃了。
现如今开发工具越来越灵活好用， 自主开发平台的日子应该越来越难过了。

你不说，我还真不注意。是不是我动了谁的奶酪？

看我说的帖子内容，好像对普元不是很有礼貌，但是我也没有做评价啊。

你说的这个问题很好，这就是产品定位问题，做这类工具的定位很难。因为这类工具的用户首先是开发人员，因为项目实现是开发人员的职责范围。但是要实现好一个项目，却不是只靠开发人员才能解决的。

首先业务逻辑是掌握在业务人员手里的，你不管怎么做需求分析，哪怕让业务人员签字画押。最终等开发人员实现之后，他是说翻脸就翻脸的。因此业务逻辑的实现，最好交给业务人员，或者和业务人员一起来做。

流程是掌握在管理人员手中的，当然管理人员可能会交代一个业务人员来实施。但也是业务人员说了算的。

开发人员只是关注实现的对不对，性能好不好。

所以要为这几类人员都能提供功能。当然还是侧重业务人员多一些。因为技术实现的手段太多了，作为平台你不可能做到最好的技术实现。因此我们要做的是把和业务相关的提出来，采用简单化的方式来实现。而和性能相关的，或者和网络环境或者软件环境相关的，留给技术人员，让其用传统的编码方式来做。

对excel, powerpoint之类需求最大的肯定是总监，经理和主管之类的人，但是有几个经理和主管用excel和powerpoint？大部分都是秘书之类的文职人员。

因此指望业务人员用这个平台有点不现实

面向开发人员的工具是越来越多，而且越来越好用。但是能同时面向最终用户的工具却很少，功能如果能够做到技术人员和业务人员，分工协作，能让业务人员也能参与进来。

这将会是一个新的局面。软件的需求变动问题，可维护性问题的局面会发生根本的变化。

在国内，很多人都在做这类工具的工作，不管是自己的兴趣还是公司的需要。但是个人做的话，不用考虑全，只要合用就行。就像木匠一样，凭着兴趣搞些小玩意，在自己日常的工作中提供帮助。

所以说，如果你有想法，就去实现他，当然不要想他会有多大市场，就当是自己的小玩意而已。

管理人员是不会去做任何东西的，工作都是手下的人来做的，比如一个文员或者担当。

我们的目标不是说完全交给业务人员来做，我们的目前是让业务人员可以直接参与进来。不让软件项目的开发像一个黑盒一样提供给业务人员。

而是他可以来完成一些和他相关的工作的。

当然实际工作中，可能业务人员字都懒得写，话都懒得说，这也是很多的。这就需要你的实现是其能够理解的，我们不需要它来动手，只要他告诉我们这样错了，我们改了之后问他对不对就行。

这就有个前提，你的实现他是不是能够看懂，另外就是你的改动是不是足够快。只要做到这两点，那么业务人员就完全可以参与进来，并且对业务的实现负责。

我觉得很多事情讨论过多会让自己犹豫不前，LZ还是尽快制定出详细方案再来讨论，这样有意义的多。
如果自己都没主心骨，讨论过多也是浪费时间。

谢谢你的提醒，不过有时候多讨论一下，梳理一下思路也是有必要的。

我从2001年开始做了一个金融行业的开发平台，采用ejb作为构件，采用delphi来开发流程设计工具，然后直接生成java代码，应该说是一个开发工具。当然我只是管理者，不大开发。

2003年开始自己开发，是兴趣所致吧。采用POJO作为基本的组件，采用Eclipse来进行开发。开发配置器来生成业务逻辑。

做了这么多年，代码也重构了好几遍，回头看，好像也没做什么工作。感觉做的东西也不怎么样。所以想出来讨论一下。

我们先不要假设自己做不出来。我想讨论的是，究竟做出一个什么样功能的东西，才是真正实用的。然后才考虑哪些功能自己能做，那些暂时还不能做。

技术这个东西是这样的，你找不到门路的时候，可能觉得很难。那就暂时放一下。等突然有一天，你看到某个产品或者某篇文章之后，一下子顿悟了，那个功能也就自然而然做出来了。

所以先讨论一下需要实现的功能，还是需要的。

真是混蛋, 偶投了15票良好对冲一下...