做好作为一名甲方人员的工作

[innovate511]

做了8年的乙方，这回开始做甲方，打算从以下几点做好工作：
1. 主导架构方向，多听细节意见。熟悉公司可能要用到的各种工具。(和很多业界朋友谈最基本的统一维度建模, 要既保证数据/信息一致性的同时又同时
满足主题分析的灵活的个性化需求, 但基本都是模糊的思维, 所以面向未来的数据仓库架构还是自己来吧.)
2. 多和同事合作，和开发团队（包括乙方）一起把业务问题解决
3. 制作样板标准，把握各个环节，每次新立项目的周期需要参与管理，每个环节需要提交的文档必须符合规范，内容需要审查,各个环节必须提交所对应的文
档及相关内容。这些环节可是项目质量的重要因素,可别想偷懒.
4. 对主要矛盾需要深入研究, 把握最恰当解决方案.
5. 打好数据仓库基础后, 使客户满意初期系统, 才能和客户一起挖掘更深层次的信息.(从描述性的事实数据提取维度信息, 或者提取退化维).

虽然是摸索中, 不过希望都做得更专业, 更严谨, 更多满意度, 多些困难估计, 多些良好解决方案, 多些经验总结, 也就能更轻松, 少加班甚至
别加班.(很多项目搞得紧加班,其实是技术没把握好,或者管理不好,或者合作关系没处好, 而非项目真的很大工作量)

希望各位朋友补充内容, 无论和谁合作, 我也会抱着互相学习的态度, 善于总结得失利弊, 才是发展的硬道理.

[geraint.zhang]

甲方中的技术线,对于业务线来说还是个服务部门
信息系统的建设也是以业务驱动的,所以掌握业务应该为首要工作.
当然你要是被甲方招安的,可能本身就比较了解甲方业务了.
做业务的里面最懂技术的,做技术的里面最懂业务的.
相声演员中演戏演的最好,演员中导演导的最好,导演里面相声说得最好---玩的就是个
综合实力

-----邮件原件-----
发件人: tt...@googlegroups.com [mailto:tt...@googlegroups.com] 代表
innovate511
发送时间: 2008年3月17日 23:11
收件人: ttnn BI 观点
主题: 做好作为一名甲方人员的工作

[Qing]

1. 主导架构方向，多听细节意见

主导架构方向？那乙方干什么？这可能对你是个大的挑战吧。如果你遇到一个在架构方面比不上你的乙方设计师，你会怎么办呢？是代替他工作？还是指挥他工作？还是任其工作，即便达不到你预期的要求也无所谓？

2. 多和同事合作，和开发团队（包括乙方）一起把业务问题解决

good very

3. 制作样板标准..

好得很，甲方应该主导这事儿。当然，乙方也应该自己有一套。虽然说有点形式化，但多少代表一种专业态度。遗憾的是，即便有模板，没有质量标准，还是大问题。

 

4. 对主要矛盾需要深入研究, 把握最恰当解决方案

很好，擒贼先擒王。

5. 打好数据仓库基础后...

这个...可以归入第4个问题吧。

 

我不是甲方，不会武功，也没有靖哥哥，所以瞎说两句。

 

甲方的IT部门，是为业务部门服务的部门。我觉得工作重点应该放在质量控制上。这个问题总是不太起眼，也没什么头绪，但如果这项工作是乙方自控，那就是自己玩自己。还得有个标准，然后由甲方监控。监控也不是完全按照条条框框的标准，这当然是最省事的。关键得看交付的东西是否满足业务部门的需求（不是满足自己的需求）。

 

有的甲方把关把得很松，他几乎就是转发器，东西就直接交给业务部门。有的严一点，首先过自己那关，不行就打回去。我觉得，严一点是对大家都有好处的，当然，存心刁难是另一回事。这事儿不好说，因为没有标准。对一个交付品，是总能找到毛病的。但我想如果关系做到那个份上，已经不是技术上的失败。而质量标准，是项目开始前大家遵守的，即便这个标准不科学，但有比没有好。但有时候是没有比有好，那就是有了标准不执行，不进化，这个时候，大家就走形式，挺没意思的一件事，还不如不要什么标准。

 

innovate将架构放在第一项工作，不光要主导还要关注细节，对此，我认为这不是重点。更重要的还是质量。目前，我们这个行当并没有什么数据仓库质量标准，唉，希望innovate可以实践出一套方案出来。

 

话说回来。现在估计的这些问题可能在未来的工作都不重要，重要的却成了炮制亮点，那就挺可悲的了。不光是甲方可悲，大家都可悲。

[innovate511]

老板之所以找我，就是因为之前2年由知名咨询公司主导，结果还多花钱买了个行业模型，那个模型设计很完备，但是在数据层次上只是单一的，所以架构根本谈
不上，很多内容也用不上，或者不清楚怎么用。至于项目流程，甲方老成员人太少也管不过来，当然原因是多方面的，原因也比较复杂。挑战谈不上，老板和我谈
的时候，我就说如果面向未来的架构，5-10年没啥问题，再长不好说了。不过需要从现有架构着手，逐步转移到新的架构上去，不能一步到位，那不现实。当
然这是机会，现在越来越多项目，只能跟着人家架构做开发，即使架构很烂，也没办法，最终客户不知道啥是好架构，只知道表面的东西，能改就改了，而项目定
位也决定了这些。

所以以后架构的问题，一般不用乙方去操心。

样板不仅仅是形式，更重要的是内容。重要文档必须要有，而且要有质量。举例说明，调研阶段完后必须有规范的调研报告，如果内容少了或者有失，需要再做
好；设计阶段完时需要有设计设计文档出来，内容不能精简，不专业的一下就看出来，不清楚的可以开个会，谁都会了；再如测试阶段，必须有详细的测试文档，
包括记录测试结果，需求变化后需要有相关的回归测试文档。

之所以要有对应的文档，历史告诉我们，相对成功满意的项目，问题会少，初级问题更少，因为任何问题在文档中都会找到，如果找不到，你去系统里一个一个的
找？那你不加班谁加班？之所以很多人不喜欢写优秀的问题，主要是习惯问题，其实在调研的同时，开发期间开会之后，测试过程，文档就可以写很多了，思路就
可以很清晰了，有了良好的习惯和意识，这些东西需要很多时间么？

我这里说的主要矛盾，主要是项目当前的主要问题，比如是业务逻辑问题，还是ETL效率问题，或是BI展示问题。有了良好的开端，才能在未来的一步步建设
中走得更远更好。

如果我是QA，即使不看技术和业务方面，仅仅从软件开发角度，现在国内绝大多数项目都不合格，毛病我都能大体指出来，还可以有相应的解决方案。虽然我只
做过3年规范项目，就是所谓的500强企业项目，不过规范项目中也会有小问题，我都自己总结过，当然，对于身边不规范的项目，自己以前参加过的不规范项
目，更是有得失总结。我以前就很喜欢和兄弟项目组的讨论项目中存在的问题，并给他们建议。

成败的关键，不仅仅是技术、业务，还有流程和管理，有人总结技术和业务，不过都一起来总结的，好像不是很多，可能因为很多东西太普遍了，习惯了，就觉得
是正常的了。

[innovate511]

对了，顺便请XD们推荐下Informatica开发人员，最好熟悉Oracle数据库。工作资历在2年以上，上不封顶，最好Informatica大
型项目经验，薪资面议，需要和大老板谈，如果有实力，应该不会比知名的国内公司薪水差。

另外就是要有足够的团队协作精神，互相学习，你Informatica好，我也会虚心请教，当然你也可以看见面向未来5-10年多种BI需求的架构系统
如何一步步搭建起来的，外部所谓成熟行业模型如何在实际系统中如何利用起来的。

[wang yiyun]

什么甲方公司

[innovate511]

传统行业，民营企业。其实呆了3年外企环境，突然去民营企业，而且是传统企业，IT只是服务部门，对我来说还是蛮有挑战的。只是我看重BIDW规划，看
重我可以把我的DWBI经验、综合技术和项目开发管理经验都有最大发挥余地。

On 3月19日, 下午10时16分, "wang yiyun" <wang.yi...@gmail.com> wrote:
> 什么甲方公司

>
> On 3/18/08, innovate511 <innovate...@gmail.com> wrote:
>
>
>
>
>
> > 对了，顺便请XD们推荐下Informatica开发人员，最好熟悉Oracle数据库。工作资历在2年以上，上不封顶，最好Informatica大
> > 型项目经验，薪资面议，需要和大老板谈，如果有实力，应该不会比知名的国内公司薪水差。
>
> > 另外就是要有足够的团队协作精神，互相学习，你Informatica好，我也会虚心请教，当然你也可以看见面向未来5-10年多种BI需求的架构系统

> > 如何一步步搭建起来的，外部所谓成熟行业模型如何在实际系统中如何利用起来的。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[raullew]

你做了这套系统，就会有人提数据需求（假如公司提倡奋斗精神的话），这时最头痛的事情很可能是生产系统的不完善、随意性，数据的不规范、编码的没有体
系

> > - 显示引用的文字 -- Hide quoted text -
>
> - Show quoted text -

[interstage]

首先恭喜innovate511被招安,乙方被甲方招安总比继续在乙方要好,尽管对于甲方的IT部门来讲,它也是业务部门的乙方或者服务部门,但毕竟是
一个公司内,所以和业务部门关系不会太好,也不会太坏,这也比真正的乙方要对付甲方的2个部门甚至几个部门要好多.
其次,对于你的甲方工作几点,我个人真的很不以为然,这只是你BIER职业素质的一种工作态度和能力的表达方式,与你现在所在的甲方具体岗位好象没什么
关系,任何甲方(不管是什么类型或者什么行业的企业)IT部门负责BI的岗位好象都可以这样描述.
所以,个人建议，你换一个描述,首先描述你现在所在岗位的具体责任是什么,每个企业肯定不一样,然后描述一下为承担或者实现这个具体责任,你认为需要什
么样的岗位技能(这和你本身的技能无关,比如自信,有冲劲,这些是个人技能,不是岗位技能),定义了岗位技能后,才能定义出岗位的工作方式和工作安排,
这样才是真正的一名合格甲方人员的工作,最后,在实施这些工作方式和工作安排后,如何持续改善,使岗位责任更清晰,更优秀.
呵呵,我不指望和你能合作BI,但我觉得BIER能去甲方是幸福的,祝福你在甲方的工作中能够学习和领悟到比你在做BIER的时候不一样的技能或者心
得,这才是人最大的财富,至少我自己是这样认为的,你说,对吗?

[innovate511]

我在甲方相当于半个乙方，属于研发单位，如果有大项目要立，还是要乙方的帮忙。至于定位，肯定我不是搞业务为主的，公司有老IT人员直接和各个业务单位
接口，他们本身就是业务系统研发出身的。如果每个甲方人员一定位就是以业务为生，还是全靠乙方搞技术，那这家甲方会死得很惨。首先乙方能力高的不多，要
好的，很难养得起长远，要知道养公司可比养人贵多了，一旦不养了，换家公司思路又不一样了，这系统搞得，就不多说了。

谢谢前辈的鼓励。还有前辈同学，我不想老斗嘴，不知道你在我有些帖子是否是善于的讽刺，不过我也算国内DWBI界的早期工作者，虽然比国内最早的商业应
用晚了2年，但在某些方面有自己的见解和执着。我知道前辈在业务分析和流程上有独到的经验和理论，我也经常拜读，只是没发留言，不精通就是不精通，需要
多学习和理解嘛，当作知识领域的提升和扩展。不过要知道BIDW知识领域太广，不是10年就能接触到所有技术、管理、流程、方法领域的。

也就是说，在BI系统DW这块，我有足够的自信和经验积累，BI系统业务分析/流程见识有限，就只能借助提升这块来提升我的整体能力，充分支持我的强
项。如果非要用BI系统业务分析、流程来挑战甚至讽刺我的DW领域这块，而非谈DW领域本身，那我就没办法了，只能反讽刺了，做技术的人可能显得比较
直，但希望能平平和和地讨论问题本身，而不是斗嘴。

> > 希望各位朋友补充内容, 无论和谁合作, 我也会抱着互相学习的态度, 善于总结得失利弊, 才是发展的硬道理.- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[huangkan]

我看innovate和interstage从那篇《数据仓库项目规划》抬杠到这里，忍不住再说几句。innovate去了甲方，看得出来，见多识广，自信满满，准备把自己的多年积累在这个甲方实现了，这是好事，一来实现自己价值，二来弘扬数据仓库，但是，我觉得还是要注意方法和力度，每个企业有每个企业的特点，毕竟你刚去，很多东西可能不了解，还需要多看，多听，要能听别人说话，既要能听领导的话，也要能听BIer的话，呵呵。当然，我们的数据仓库规划也要做，但不是完全搬经验中的东西，因为各个地方的实际情况还是不一样的，如果啪的一下丢出来，大家可能会有抵触情绪。罗罗嗦嗦说了这么多啊，为啥？数据仓库项目有个特点，涉及的人和部门相当多，动不动还是一把手工程，因此，人脉畅了才能把事情做好，任何一个环节有抵触都会影响结果，典型的"大家好才是真的好"。一句话，"广积粮，缓称王"。

[innovate511]

数据仓库方向规划, 就是高层定的事情, 你以为我为了表现自己, 自己去挑的事情? 那各位太抬举我了吧?

至于抬杠, 大家能看到, 谁在抬杠, 如果要讨论, 就针对数据仓库本身去讨论, 不要动不动抬到业务管理和战略管理的高度, 这不搭边吧? 说不
好听点, 难道人家写数据仓库书的人, 就得根据某个企业的具体战略和业务需求逐个去写?

当然规划和写书是两回事, 写书要写得够细, 大家都能看懂, 面面具到. 而规划, 只是一个方向, 并非面面具到, 很多细节心中清楚, 在内部能
解释清楚即可. 规划的面要窄得多, 只含高层技术面, 但能说明技术的结构层次, 以及现在的起点, 未来的立足点.

至于人脉关系, 架构规划能影响人脉? 这个和业务本身又没关系. 难道你是指, 我在这里丢一个高阶讨论, 这里的BIer会抵触? 不会都象那位前
辈那样吧, 做技术的不至于如此如此吧?

On 3月23日, 上午10时54分, huangkan <erichuangta...@gmail.com> wrote:
> 我看innovate和interstage从那篇《数据仓库项目规划》抬杠到这里，忍不住再说几句。innovate去了甲方，看得出来，见多识广，自信满满-，准备把自己的多年积累在这个甲方实现了，这是好事，一来实现自己价值，二来弘扬数据仓库，但是，我觉得还是要注意方法和力度，每个企业有每个企业的特点，毕竟-你刚去，很多东西可能不了解，还需要多看，多听，要能听别人说话，既要能听领导的话，也要能听BIer的话，呵呵。当然，我们的数据仓库规划也要做，但不是完全-搬经验中的东西，因为各个地方的实际情况还是不一样的，如果啪的一下丢出来，大家可能会有抵触情绪。罗罗嗦嗦说了这么多啊，为啥？数据仓库项目有个特点，涉及的-人和部门相当多，动不动还是一把手工程，因此，人脉畅了才能把事情做好，任何一个环节有抵触都会影响结果，典型的"大家好才是真的好"。一句话，"广积粮，缓称-王"。

> > > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[villa7 li]

真是好同志啊，还有这样的打算

只希望不要被甲方的一些风气给同化，要记得乙方的不容易：）
 

在08-3-17，innovate511 <innov...@gmail.com> 写道：