银行业务需求分析模式及路径初探 - 第2页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

nunton 发表于 2014-6-6 08:38
我不这么认为，技术总说业务方面没有做好需求的规划，问题是很多时候业务发展是迅速，有的时候甚至是不可预 ...
同意对需求进行分类
具有长远或明确规划的的确可以做更多的要求，尤其是那些具有蓝图规划和战略导向的。这部分应该占据大部分
对于市场热点，短期利润点，监管，快速套利等临时紧急的需求，的确需要一个机制进行快速的决策和支持。问题是这类需求信息化需要科技的机制保证，也需要周边业务的同步协同及合理的信息化支持，尽可能的利用已有平台和现有功能的复用和支持。科技部门只有深入理解业务趋势才能在架构支持，预埋模块等才能做到快速响应。
科技部门只有深入理解业务趋势才能在架构支持，预埋模块等才能做到快速响应。
这点我不认同，业务部门自身都无法把握业务趋势，何况科技部门呢？
快速解决最有效的方案是简单设计。简洁，逻辑清晰的代码才是最具可维护性的。当然，更重要的是一支来之能战的科技团队。
Ray001 发表于 2014-6-7 17:46

这点我不认同，业务部门自身都无法把握业务趋势，何况科技部门呢？
快速解决最有效的方案是简单设计。简 ...
同意
Ray001 发表于 2014-6-7 14:46
这点我不认同，业务部门自身都无法把握业务趋势，何况科技部门呢？
快速解决最有效的方案是简单设计。简 ...
正是矛盾所在，工行的产创不的模式也部分失败了，作为下游的技术部门只能最大可能的努力，因为自己是最大最后的下游输出部门，不得已而为之
本帖最后由 nunton 于 2014-6-7 22:21 编辑
家住海淀 发表于 2014-6-7 22:01

正是矛盾所在，工行的产创不的模式也部分失败了，作为下游的技术部门只能最大可能的努力，因为自己是最大 ...
因为技术部门是最后一道，所以压力会全部集中在技术部门。但是反过来业务部门也很无奈，能够在业务设计层面尽量有前瞻性当然好，但是尤其这几年创新太多太快，指望业务部门在业务层面想全了不现实，我倒是觉得应该在系统主体功能外，基于业务最核心和最基本的一些逻辑，构建一个简化版的用于及时响应业务的新要求，此时业务的要求也不会太复杂。等业务要求复杂了，自然也就整理出思路了，从而系统也就能规整。
所以我们的以客户为中心的理念还需要改进，配合到组织职能层面的同步配套。
实际上我理解客户层面的管理必须配备合约管理及客户定价，全行必须有完整的产品体系规划！
2、又有几个人认为自己真的(100%的,把每句话,每个词都掰开揉碎的)理解了作者的意思？
3、又有几个银行需求管理部门的领导真的认为他的团队具备足够的理解能力和执行能力，能够在实践中很好的按照这套理论去操作？
最后,作者能够保证自己文章中的每个观点,每句话,每个词都是认真推敲,并经过实践反复验证的么?而不是罗列一大堆舶来的专业术语,只为了把人镇住,以便发表一篇论文？
这种行文风格恐怕需要改改了
说实话，我也做一些需求分析。我没有理论，主要靠实践。我很关心的需求范围分析、影响性分析和衍生需求、隐性需求的具体方法是啥？完全没有提到。
Ray001 发表于 2014-6-7 17:46

这点我不认同，业务部门自身都无法把握业务趋势，何况科技部门呢？
快速解决最有效的方案是简单设计。简 ...
所以这永远是一个矛盾，
科技需要精通业务本质，能够预见趋势的专家。但科技工作吸引不了这类人。
最终系统就只能是跟着业务的变化东改西改，或者是重复再重复了