项目出了一些问题,感觉进行不下去了,大家帮忙看看.
我们公司目前的大概架构:
用户(USER)
老板(BOS)
商业分析组(BA) - 需要分析,出功能说明书(FS)
设计组(DS) - 设计界面(DESIGN)
研发组(ARCH) - 数据库设计,数据访问和商业逻辑层编写(SP)
开发组(DEV) - 前台程序编写,集成测试(SIT)
质量管理组(QA) - AQ,测试(UAT)
系统组(INFRA) - 安装,发布,服务器架设等等(DEPLOY)
大概流程,一些没问题的省略了:
1.BA和USER, BOS讨论需求,BA出功能说明书,分发DS,ARCH,DEV,QA,INFRA.
2.各组头头MEETING,讨论功能说明书,有问题去3,没问题去4.
3.BA就各组的反馈意见再和BOS讨论,修改功能说明书,然后去1.
4.ARCH设计数据库,开发数据访问和商业逻辑的中间层.DEV出设计需求清单,DS按清单提供设计,DEV开发前台程序.
5.SIT测试,DEV负责.
6.UAT测试,QA第一轮,BA和USER,包括BOS第二轮.
7.INFRA发布系统.
现在有一个项目,情况是这样,BA出FS了,在各组头头MEETING的时候,总是有很多问题,然后BA带着反馈的问题再去和UESR,BOS讨论,修改FS,然后再MEETING,还是会有新问题.期间BOS又可能要求做一些DEMO出来,还要求出一个各种方案所需要的时间.BOS有时还会直接和DS讨论一下DESIGN的东西,有时又跟ARCH讨论一下商业逻辑的东西,有时又和PM讨论一下开发时间的东西.
总之现在的结果,每天除了MEETING,然后就是BA不停改FS,DS不停改DESIGN,DEV不停做DEMO,PM不停做PROJECT PLANNING.ARCH还好,改动比较少,也改了一些东西.
所有人都觉得累,但是项目却一拖再拖,而且好像永远做不完一样.其实以前就发生过类似的事了,后来整个DEV TEAM的人走完,我不想再重蹈覆辙,大家帮忙出出主意,先谢了.
[解决办法]
才学程序的,来凑个热闹.看了半天,你不是就说BA不停改FS,既然这样,后面那些累的不是也没什么法子?那就定了呗,要不就定几个不同的FS,不停的改恐怕会把人折腾死.
[解决办法]
觉得这个问题很多公司有，主要就是BA经验不足、能力不足，觉得只能是把需求控制一下。最好的办法认为就是培养出牛比的BA。
以上仅是个人意见。
[解决办法]
我觉得首先是分的环节太多了，势必增加沟通成本。第二是只看到每个人是属于某个部门的，却看不到他们对项目负什么责任。我见过客户说某某软件很好用，或者某某软件一塌糊涂。但从来没见过哪个客户评价说这个软件虽然根本不能用，但是其实开发的很好（或是测试的很好）。所以我不知道几个只管自己“职责”的人怎么去保证项目的结果。
[解决办法]
BA应该是技术方面绝对NB的人，有些公司这种人叫SE（system engineer），他们负责项目竞标技术部分的支持，有这种NB的人在，你这种问题了就少得多了，但也不可能没有，客户是疯子！
[解决办法]
需求还没出来，后面的环节没必要开展。但需求也不是不变的，这就需要上一套需求变更流程。我看你的BOSS不像是做软件出身的，要不应该懂点先后关系。
[解决办法]
建议一、需求如果没有做好，这个里程碑没有完成，不要开张后面的工作。
建议二、需求和用户的讨论需要阶段性来一次，不是有问题就搞人家，客户烦了就麻烦了。
建议三、这类问题应该是QA的专长，怎么把QA做了测试工程师了，这个QA真是可悲！还是你们公司可悲？QA应该是有着N多项目管理经验的超级项目管理专家，怎么现成的老师不去问呢？反而把人家弄成一个QC了。
[解决办法]
这样的问题，需求是关键，我做项目之前就一直给客户灌输一个思想，如果需求没提准确，后期变动的工作量非常大，所以我采用原形法，让用户确认，并将系统功能做为合同附件，如果变更的话，对不起，加钱加时间。
另外，做需求的人，必须是领域专家。
象你们这种情况，估计你是改变不了的，一是你们看起来没有领域专家，二是你们的CEO来自大公司，他的想法你很难改变。
[解决办法]
案例分析：显然该项目的BA在项目的所处的商务领域缺乏业务知识，再者，PM和TL缺乏开发过程的经验，主要问题体现在PM没有起到应用的穿针引线的作用；再者就是BOSS在内部没有给予项目强有力的支持。这三者是人员对项目控制上的问题；再者是开发过程中技术层面的管理问题，主要是版本管理的问题；最后项目管理中合同管理和风险管理的问题。
解决方法：人员方面，对于所承接的项目不是以前组织所熟悉的领域，有必要从外界引入（招聘或者引入领域专家）相关业务领域的专业人员，从而可以有效解决需求分析阶段对需求的控制问题；对于PM必须在项目初期对项目的需求给予高度的关注，通过与领域专家协作分析那些是高风险的需求，并跟进项目的合同管理和版本管理；对于内部相互踢皮球的现象，PM负有主要责任。这时主要体现的是ＰＭ在公司内部沟通的能力，而且需要具备我说了算的这种气魄。对于BOSS的问题，作为打工的普通只能是无奈，当然这种老板在小型公司或者属于那种技术型领导身上经常见到。这种BOSS只能让市场告诉是对还是错。
[解决办法]
我们公司的BA不是很NB,但跟USER关系融洽,经常组织些活动与USER沟通.
USER的公司管理也规范,有什么需求,都会给一份他们的管理标准文件
BA拿到文件后分析研究,整理出业务流程,对需求进行分析,制定界面,然后与USER讨论,确认是否有偏差.
第一次确认后的需求分发给开发\设计\质量部门人员学习,其中的疑问由BA负责解答,需要用户确认的问题由BA去用户沟通.对需求取得一致意见后进行评审,FS纳入基线管理.
后续工作:
BA会参与DS\ARCH\DEV的设计的评审,检查是否有需求遗漏或偏差
BA检查测试的测试用例,是否覆盖需求.
BA参与系统集成测试,检查软件最终是否符合需求,必要时邀请用户参与
感觉我们的沟通与运作比较流畅,现在上班是朝9晚5,几乎没有加班.
