|
|
Drate 发表于 2011-11-24 19:13 ![]()
呵呵，这位仁兄的点评相当中肯，谢谢！！
明源软件这些年的发展非常快，在我们的软件技术层面也做了许 ...
随便在鲁班前面弄下大斧。
职业病的原因我目前还比较关注项目在实施阶段的很多具体工作，想要脱离针对产品的实施向业务甚至管理实施转型，我觉得明源的实施团队主要可以在以下一些关键任务做一些改进：
1、需求调研工作的前置。这需要实施与咨询/售前的协作。在与明源的第一次合作中我特意让实施组项目经理做了主体解决方案的讲解而非咨询/售前，目的是让实施团队参与项目前期方案制定，可惜你们的政策让这想法最终泡汤；
2、强化业务蓝图/解决方案设计阶段。在这一点上我比较推崇SAP的方法论，不光关注标准业务，特殊业务甚至一些可能出现的业务问题都要深思熟虑，在这一阶段出的蓝图应该是基于业务的，由业务引申至软件设置与功能的，由功能引申至二次开发定义的，所以在这一阶段完结时出了针对二次开发的项目变更单；
3、逻辑测试、集成测试与压力测试。很难想象一个没有测试过的解决方案甚至项目会是什么样子。可以简单定义逻辑测试是针对软件功能的，集成测试是针对解决方案的，压力测试是针对最终用户的。所以我强调了测试的必要性，强调了测试脚本及步骤记录的重要性，虽然这次只是一次小范围集成测试，但解决方案需要经过集成测试进行修订，完善；
4、弱化/分散操作培训。项目各个阶段都在进行知识传递。之前的培训搞得很正规，但建议把更多的精力放在蓝图跟测试那里，我在做项目经理的时候是不让顾问做End user的操作培训的，一切操作培训由关键用户完成，当然现在很多地产企业甲方团队还不具备有成为关键用户的能力；
5、Go or not go。这步其实可以有，而确实明源的项目经理也在这么去做，我觉得比较欣慰；
6、上线准备会做些什么。不光是宣布上线日期与计划，必要的风险评估，可能会遇到的问题及解决方案等等，这些更加体现顾问的价值；
7、项目成果文件。举2个例子：二次开发设计规格书与测试报告是必要的且相辅相成的，当然做到这个其实并不容易；最终用户操作手册说服甲方基于标准操作手册进行完善。其他的就不多说了；
8、系统环境搭建。这个让我比较崩溃，感觉没有明确的环境搭建标准，几个环境，各个环境在哪些阶段及环节的作用是什么，何时切换。鉴于软件技术层面的熟悉程度我不能给太多建议，但是乙方应该在项目前期考虑好了，没有准备的话显然不专业了；
说太多了。回过头去看发现确实有点吹毛求疵，做大事应不拘小节，还是有些职业病的成分，选择性忽略吧。从整个地产行业来看，大部分的项目实施仍然还应该是面向产品的实施，从这个角度来看，明源的方法论是没什么大问题的，从成功率就看得出来；但既然要转型，就要优化一下方法论，以适用于越来越多的像我这样挑剔的甲方。我至少还会和明源的实施团队再合作2个项目，希望能看到转变。
最后Complain下明源开发团队与实施团队配合开发团队的二次开发人天预估，我知道这是公司层面的问题，但既然如此，就希望你们提升一下内部团队协作能力，另外最好给我个*1.5的解释，这曾经让我百思不得其解。。。 |
|
楼主: hwayw
IP卡
狗仔卡
发表于 2011-11-24 19:13
显身卡
。