个人的一点项目总结

wangdiaming

补发几段有关方案制定的，希望对你的需求调研有所启发

wangdiaming

@方案讨论和评审时，一定确保相关部门和人员到位参会
方案讨论和评审，其实一个很重要的作用就是帮助项目组确保没有遗漏重要内容。对应XX集团公司这种复杂、庞大、客户投入人员不足的项目，方案评审尤其重要。某些项目组为了加快进度（可能也是为了尽快把方案确认了），采取了并行方式，导致评审会议的参与人员不全。这一做法导致在后期的时候，才发现部分流程图出现了遗漏，于是匆忙进行补充，造成了不好的影响。
其实在项目中，不管进度再紧，方案评审的时间，是一定要留出来的。为了压缩成本和进度而采取简化方案评审的做法，就好比饮鸩止渴，最终会带来更大的成本损失

BTW:queryQ,可以通过多部门评审的方式，以流程图为依据，进行评审确认

wangdiaming

@方案制定，应先考虑框架，再考虑细节
某些项目制定方案的方式是写方案要点说明，再让关键用户制作方案流程图。这种方法有优势也有劣势，优势是可以尽量减少顾问的工作量，劣势则是流程图太晚才出来，容易导致很多问题没有被发现，甚至一些重要的内容被遗漏（因为没有按照流程图的思路来整理方案内容）。
因此，在制定方案时，可以先考虑框架，保证框架的完整性（特别是客户的一些特殊业务）——可以以流程为主线，先把流程要点和单据落实清楚，再在框架下充实细节的内容，从而避免重要的内容被遗漏。
BTW：queryQ，你也可以依据以前的经验，理一个框架，包括一些特殊的业务，然后再和用户进行沟通，对细节进行补充

wangdiaming

@业务调研后，让关键用户确认重要的业务点
业务调研时，如果一些重要的业务点出现沟通偏差，容易造成不好的影响。因此，调研时，应该记录下重要的点，并请用户进行确认。
记录应保存以备后查。
BTW:queryQ，让用户确认一次，有时候可以帮助你发现更多的问题

wangdiaming

发得有点多了，有点像灌水了，嘿嘿

kitty9103

不错 好东西

queryQ

原帖由 wangdiaming 于 2011-2-11 22:58 发表

1、首先你得说说哪些方面被漏掉，这样我们来逐一分析
2、不同行业都有自己的特殊需求，如果你对某一行业不熟悉，难免有一些特殊业务都漏掉的，我想这个也比较难以避免，只能是依据完整流程图的框架，反复进行沟通

长老，你好
  1、总体框架性的流程不会有太大变动，但流程中的细节处理往往在调研时没有深入下去。
2、让用户确认，确实是发现问题的很好的方式，但如此往往会反复多次。
3、长老可否将你的压箱底的“方案”和“流程”贡献出来给大家参考参考？

wangdiaming

原帖由 queryQ 于 2011-2-12 21:29 发表

长老，你好
  1、总体框架性的流程不会有太大变动，但流程中的细节处理往往在调研时没有深入下去。
2、让用户确认，确实是发现问题的很好的方式，但如此往往会反复多次。
3、长老可否将你的压箱底的“方案”和“流程”贡献出来给大家参考参考？

PUB里面太多熟人，恐怕不太方便

wangdiaming

原帖由 queryQ 于 2011-2-12 21:29 发表

长老，你好
  1、总体框架性的流程不会有太大变动，但流程中的细节处理往往在调研时没有深入下去。
2、让用户确认，确实是发现问题的很好的方式，但如此往往会反复多次。
3、长老可否将你的压箱底的“方案”和“流程”贡献出来给大家参考参考？

其实也没有什么压箱底的东西，客户认可的，就是好的。
再说，我一贴，不是就告诉别人我是谁了？客户看到了可不好

wangdiaming

原帖由 queryQ 于 2011-2-12 21:29 发表

长老，你好
  1、总体框架性的流程不会有太大变动，但流程中的细节处理往往在调研时没有深入下去。
2、让用户确认，确实是发现问题的很好的方式，但如此往往会反复多次。

1、在调研阶段投入更多精力，保证需求的准确性和全面性，方案阶段相对顺利很多
2、到方案初稿制定出来后，再重新去考虑方案，有时候甚至要改动其他涉及的方案
两种选择，你选哪个？