刚才突发奇想，对于开发的流程有了一点新的想法。就发出来，供大家拍砖。不知道大家对这个流程有什么不满呢，尽管说，希望尽快完善它，尽快应用它。好了，说正文吧。

就是了解客户，或者是市场的需求。可能要结合调研，深入体察，问卷调查之类的形式。尽可能了解市场的动向，方便把握我们的方向。

了解的需求，定义的产品方向之后，就需要进行业务建模了。又可以分为三个阶段：

业务分析：分析市场的需求，划分业务的方向，找到业务的主体以及业务的大概内容和范围。

整理业务粗粒度的用例：分析完业务之后，将分析的结果整理为粗粒度的业务用例。可以用工具来辅助这个阶段的工作。把握业务的脉络和方向。

细分业务用例：有了粗粒度的业务用例之后，需要进一步的细分，整理业务的细枝末节，考虑每种业务的可能性，业务的流程，业务数据的流向。

这个阶段参数的人员不包括开发人员，主要是业务分析人员，需求分析人员，和系统的架构师，如果需要的话，可以引入高级软件工程师。

这个传播主要是说，需要将成型的业务知识传播给开发人员。一个系统，经过了分析，最终是要实现的，要用代码的堆积的，所以再开发之前，需要开发者了解业务的脉络，否则实现的东西会偏离方向，而且有可能实现的过于简单或者过于复杂。

这个阶段有两种做法：

1）开发人员在高级软件工程师的辅助下，将细粒度的业务用例整理为技术用例，也就是想办法实现每个业务用例。当然了，有可能细粒度的业务用例和技术用例是一对一的关系，也有可能不是，而是其他关系。反正，要转化为技术用例。技术用例的内容包括：需要什么技术手段，什么算法，如何实现，循环还是如何，修改哪些表，是否需要数据库事务，使用sql事务还是代码写事务，等等技术细节。最好达到伪代码，也就是谁拿到了，都可以实现的地步。

2）高级工程师在架构师的辅助下，完成第一种做法的内容，不让开发人员参与。

这两种做法的区别就是有无开发人员的参与，各有各的好处。开发人员参与，可以锻炼他们的分析能力，但是他们介入业务也不是一件好事。因为我们都知道，开发人员的思维方式和业务人员的思维方式是反过来的，不是一种方式，容易没有结论。而且，开发人员专注于技术，对他们也是好事，尽量不要分散他们的精力，让他们尽力实现软件，尽力用更好的方式实现软件。

技术用例也出来了，这样就可以划分工作了。每个人划分几个技术用例，估算出实现需要的时间，列一个表格，或者是用什么管理工具管理一下，反正方便控制进度就好了，需要知道的是每个人都在做什么，什么做完了，什么还没有完成。

每个Job Item有四个阶段：未分配，已分配（未开始），进行中，结束。根据这些阶段，对于功能的实现进度一目了然。这可能需要开发人员每天更新自己的工作内容，或者是主管每天跟踪进度之后，修改进度表。

不要以为任务分配好了，就一切万事大吉了。跟踪是必要的，一定要跟踪进度，而且要定期的检查，否则后果不堪设想。每一层的主管负责跟踪自己范围内的完成进度。

技术组长：组员技术用例的完成情况，技术的实现有什么困难，手段是否合理。跟踪的过程中顺便给予指导。

项目经理：跟踪的目标就是业务用例，细粒度的，粗粒度的，根据职责范围跟踪。还是就是整体的进度，是否需要加人，是否需要加班，人员的情绪是否正常，等等。