文档1体化改进意见[1).docVIP

文档一体化的改进意见 权限工作和WBS的工作是一次性的，所以，对一些默认的结果能够实现就可以了，页面的改进和易用性的改进可以放在以后。 权限默认的结果：组织结构图中实现上下级的监督关系，即上级可以看下级的工作内容，在项目管理中表现为可以“订阅”下级参与的项目。目前已经实现的功能保留。 WBS的默认结果：组员添加后有默认的权限，如本项目的递交权和查看权； 对审批权而言，只有本项目的组长可以审批本项目的递交文档；同时，本项目组长递交的文档不再需要审批。 再来看易用性，因为日常的工作就是发邮件，看邮件（当然，也包括递交的文档，或是邮件的附件），所以这一点一定要方便、清晰。Work list，也就是项目平行列表，起到了一个邮件分类的作用，在邮件发出或收到时，邮件就已经按自己所在的项目分类了。 审批，仅是组长要做的工作，若不是组长，建议，不要显示“审批”一栏。 在每人项目总的入口，建议显示所有的信息，按分类为：work list、邮件、审批、订阅。其中，邮件应显示所属项目；work list应该显示所有新加入文档的数量；审批应该显示所在项目和提交人；订阅应该显示和work list相同的内容（不是自己参与，但是自己关注的项目）。 有一个原则：从work list入口进入写的邮件（或递交的文档）应该带有本项目的归类属性。 从项目树进入或从work list进入项目（任务）后，应该显示该项目的所有成员，组长后面可以打一个星号（或用其他标记），组长有管理组员和开列子项目的权利。对该项目成员来说，应该显示该项目的邮件和归档文件，未阅读的应该有标记。对组长，还应该有待审批的文件。 对本项目成员（包括组长）的上级（就是组织结构图上的上级）来说，就是本项目“编外”的成员，他从项目树和work list进入（考察）本项目后，可以直接对该项目成员发送邮件，该邮件也自然带了本项目的归类属性。文档递交的动作，上级也可以做，但同样要组长审批。 再强调一下，邮件和文档一定是带有“项目归属”这个属性的。 对一些默认规则的说明： 审批权，组长有审批权，成员没有。若有权限的人（比如组长或系统管理人员）赋予了特定的人在项目中的审批权，则该特定的人（可以是组员）在项目入口时有审批权。 角色，是一些权限的集合，可以有一个人，或一群人来承担这样的角色，这些权限在角色定义的时候，也定义了使用的范围（比如对”房产VCD制作”这个项目的审批权） 投递权，参与项目的成员应该都有对该项目的投递权 文档查看权，参与项目的成员应该都有对该项目的投递权 开子项目权，项目组长有开子项目的权利 出错：系统设置?部门设置?部门操作?删除部门?出错信息 （若部门内或下属部门有人员时发生出错信息，若为空，则顺利执行删除动作）建议显示：部门有成员存在，不能删除。 建议，部门操作的三个动作（增加、删除、修改）放在同一个页面，并展示全部操作属性，以button键作三种操作的选择 建议，目录树、组织结构树在操作后作展开动作。目前的状态是操作后缩进。 建议，组织结构树显示数字（×/××）×：本部成员数；××：本部以下（含本部）所有成员数（数的负担太大） 疑问，新来成员（成员添加）的ID可以重复？现在系统是允许重复的，不知如何处理，建议在添加时有校对功能，不允许重复。（已增加校验） 建议，增加成员信息：公司电话、手机、报到时间、部门、职位、出生日、其他、附件 建议，在员工展示栏里增加：“手机”“年龄”栏 建议，调职功能时，子部门列表显示全路径。如：总部?市场营销部?市场处?渠道组 建议，调职部门列表时按组织结构树同序展开 建议，离职人员不显示在成员目录中，不可添加为组员 建议，增加人员管理统一入口，对其部门、在岗状态、个人信息等做统一处理 改进，增加每位员工管理自己帐户的功能和展示组织结构和结构成员的功能（仅能查看） 改进，复职管理应该有统一界面，先展示所有人员，他们没有部门属性，再选定部门，上岗 错误，权限管理?加入权限?权限对象 浏览的对象无法展开全部(部门已经解决) 建议，对已经指定的权限有修改的入口（范围的修改）（先删除，再添加） 建议，角色定义时，人员列表默认按ID序号显示，或可以按部门显示（为查找方便），同时，多显示两列：手机、邮件 建议，对人员操作时，如角色变换、部门调整，动作后应通知本人（自动邮件） 改进，角色添加时，非成员不应该包括离职人员。即，离职成员不参与系统任何操作。 改进，角色在增加权限时，应显示权限列表，并以botton方式选择。现在的方式是下拉框 改进，对可见项目，操作“订阅此项”，然后，显示“取消订阅” 疑问，项目?权限管理?权限对象 若对象发生变化，即项目名称改动了，什么结果？是权限不到了（不可见）还是没有变化（也就是和项目名字无关，对象是用数字编号表示的） 改进，审批文档