管理项目管理中的业务层和画面同步的问题

[gujixiake]

大家好，我现在管理一个项目，业务层由一位高手来做，几个经验不丰富的负责开

发前台画面，现在由于前期确认不足，导致很多实体属性的遗漏，以及业务层接口

定义不足，而且前台开发人员对设计的思想完全不知道，这样前台画面开发者开发

起来很痛苦，基于目前这个情况，有什么解决方案可以改善乃至解决这个问题？ 请

大家帮帮忙。

[以专业开发人员为伍]

业务层定义、支持不足的就毫不犹豫地补充上。业务层不是有“高手”吗？别是那种眼高手低的高手。看起来，你们被这个所谓高手困扰了，应该找一位真正的高手做pm来规划各项任务，而不是找一位高手做低层次的编程。

[以专业开发人员为伍]

[Quote=引用楼主 gujixiake 的帖子:]
现在由于前期确认不足，导致很多实体属性的遗漏，以及业务层接口

定义不足，而且前台开发人员对设计的思想完全不知道，[/Quote]

你这里体现的正如楼上所说是“假象能通过详尽的业务分析，把所有东西跃然纸上，大家各自开发各自的，最后成功对接。但这样实际的难度很大”。这类开发往往看似用90%的事件做完了90%的事，结果做到最后10%的事才发现同样需要90%的时间，甚至更长时间也不能达到需求和质量要求。

你和你的“高手”应该以1、2周为单位增量地追加业务接口极其实现，一边开发一边与用户一起确认需求，而不是把责任推给“前期确认不足”。

[火星人陈勇]

对，或许世界上有能把需求完全开发出来的方法，但是却没有天生清晰的、完全一成不变的需求。
所以即使有这种方法，也没用。

“客户的需求是模糊的、变化的”是这个世界的本质，敏捷开发是这个世界里边的开发人员认识到这个本质后与上帝妥协的产物。

[以专业开发人员为伍]

当然，敏捷开发与鼠目寸光地想到哪里写到哪里的区别在哪里呢？需要设计师有非常全面的面向对象开发技术，如果你的设计、测试技术并不高超和彻底，而是含含糊糊对许多基本问题都拿不定主意，看似敏捷开发的过程反而会让你产生更多的废品。参见帖子《我来支持》

[火星人陈勇]

不知道为什么发表在敏捷区了，那就用敏捷的方法来解决吧，呵呵。

我01年做项目经理的时候，我们也是很希望用分层的方法让大家的水平在各自层次上发挥出来。但是很快就发现，中间的接口发生了问题，也就是你说的接口遗漏（更逗的是，更多的问题是“多余”的接口）。

现在用敏捷的思路分析，那就是大家没有用故事把软件功能串起来，而是假象能通过详尽的业务分析，把所有东西跃然纸上，大家各自开发各自的，最后成功对接。但这样实际的难度很大。

实际上最好的开发方法是：业务高手在头脑中要有整个需求的概况，但是每次只和大家分享其中一个关键业务，然后大家集中把这个业务实现出来，再追加次重要的关键业务。当然这就考验业务高手的能力了，因为这里的“关键”2字，包含了很多因素：是否对客户重要，是否对产生稳定架构有所贡献，是否要考虑到未来的影响等等。

项目组的人要坐得近点，随时沟通，集中在这个关键业务上，谁也别多做东西，但也别漏了什么。

我现在不做软件开发了，但是我和我的组员坐在一起，旁边永远有一个空位置（给你说的那位“对设计的思想完全不知道”的兄弟留的），还有一个白板，每小时几乎都与当前与我合作的人沟通一下。谁也别多做东西，但也别漏了什么。