作者ricky906 (boy)
看板Soft_Job
标题Re: [讨论] 我同学常对我说:资管没用.
时间Wed Oct 3 19:08:11 2007
※ 引述《atst (电脑无法阻止人类做蠢事)》之铭言：
: ※ 引述《ricky906 (boy)》之铭言：
: : 有点疑问...
: : 需求变动的事实是真实存在的啊
: : 程式因应变动而修改也不是什麽不能接受的事
: : 为什麽说这就是dirty work?
: : 建立prototype不就是为了找出问题的范围
: : 好让接下来的设计能反应事实,而不是凭空想像
: 事实上,前一阵子蛮流行的XP方法,
: 正是为了解决这类情况所提出的工程方法.
: 用短期，大量的开发周期，取代过去长期，少量的循环。
: 在每一个开发周期後，针对客户的需求，再作修正与检讨.
: 不过，虽然周期缩短了，但还是得维持一个完整的开发周期。
: 现在的问题是，不论开发周期的长短，客户都会在不适宜的情形下，介入或是打破原有
: 的开发周期。
: 举例来说，假设你现在做一个案子，使用XP方法,打算在3~5天之间,先做一个prototype
: 出来，跟客户也讲过了，5天後再依照完成的prototype做讨论与修改.
: 你很高兴的开始进入开发的第一阶段，你可能由programming开始,也可能由design开始.
: 不论你的第一步是什麽，当你在第一天的下午，很愉快的,将第一阶段完成，心里想着：
: 接下来两天，你可以把prototype完成，同时还有点时间做些内部测试，说不定还可以找
: 机会去跟QA的漂亮妹妹哈啦两句....
: 这时候电话响起了，客户劈头就跟你说:"那个xxx, 我这边还想到一个好主意...."
: 然後你就知道了，之前做的阶段全都白费了,运气不好的话，你又得重头开始....
: 所以说啦...
: 程式总是会修改的,这句话不论在商业上，或是技术上都是正确的...
: 问题是,就算要修改,你也要先有东西可以改啊....
: 如果连个屁都没生出来，就在那加一堆有的没的....那当然是Dirty Work...
嗯....感谢
看了这个例子就清楚多了
以我个人的经验, 工作到目前为止是还没遇过太夸张的"动态需求"
但是,对於这样的状况也不漠生就是了
客户机不机车 / PM 够不够力 / .... 这些造成问题的原因,我想以programmer的角色
应该是无能为力的, 所以就先放一边吧
我想请教大家的是, 有没有对策!??
Ex:
1. prototype在客户改变心意前搞定.
2. 把客户可能变动的部分 highlight 另外处理
3. 以专业的立场 引导客户的需求
4. 领先客户一步 先把功能做好等着
我觉得再频繁的变动, 只要是同一个案子 总是会有不变的地方
而且随着时间进行不再变动的部分就会愈来愈大, 也就是渐入佳境罗
如何快速的通过初期的痛苦,才是我比较关心的部分
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 58.86.128.2
1F：推 aaronliu0719:prototype本来就是确认需求用的 10/03 19:29
2F：→ aaronliu0719:能在prototype出来前就更清楚客户的心意 该烧香才是 10/03 19:29
3F：→ aaronliu0719:所以1个论点怪怪的 10/03 19:30
4F：→ aaronliu0719:2的话 要切割出「会变」和「不会变」的部分 10/03 19:30
5F：→ aaronliu0719:等於和4一样 变成先做半成品 再兜solution的形式 10/03 19:31
6F：→ aaronliu0719:这种和SAP、Oracle的模式不是差不多？ 10/03 19:31
7F：→ aaronliu0719:而上述两家公司不正也体现了3的行为？ 10/03 19:31
8F：推 ggg12345:用合约时程检视prototype来使需求与规范减少逆转,排时程. 10/03 19:30
9F：→ ggg12345:让用户选用程式的参数做为变动的输入, table driven 10/03 19:34
10F：推 ggg12345:预估会有龟毛的模组,留一些做特别的服务,仁尽义至. 10/03 19:39
11F：→ leicheong:PM预的期限通常不会让你有这种余闲去想怎样做好接口的. 10/03 19:54
12F：推 atst:多沟通吧,跟PM,客户,以及同组的组员多多沟通... 10/03 20:02
13F：推 ledia:其实在学校学了一堆软工, 最後发现还是会做人比较有用 XD 10/03 20:20
14F：→ ledia:和客户承办人打好关系, 安抚他不要天天作梦 案子会好做得多 10/03 20:21
15F：推 leicheong:楼上正解. XD 10/03 20:30
16F：→ leicheong:因此「反论」的等级要练高, 客户出要求不管怎样先挡下 10/03 20:31
17F：→ leicheong:再说... :P 10/03 20:32
18F：→ leicheong:而说服甚至催眠他们, 让他们明白那样改是坏主意. :P 10/03 20:33
19F：→ leicheong:他们满意了, 老板就满意了, 你就有好日子过了... 10/03 20:35
20F：推 ricky906:多沟通, 能沟通当然是最好的solution 10/03 23:05
21F：→ ricky906:不过我想focus在自救的方法上,去减轻沟通不良时的痛苦 10/03 23:07
22F：→ ricky906:还有其它的想法吗?! 10/03 23:10
23F：推 ggg12345:不用软工就是买通打穿,让利是天底下一定通行的办法,沟通 10/03 23:28
24F：→ ggg12345:也得用上给好处这个办法,基本上还是技术挂帅的毛病,软体 10/03 23:32
25F：→ ggg12345:公司倒了,那买的订制型软体谁来後续善後?这里存在不合常 10/03 23:34
26F：→ ggg12345:情的状况.这种状况只会出现在公务机关的行政电脑化,而且 10/03 23:36
27F：→ ggg12345:是首长偏袒身边莺莺燕燕才发生,PM/PG不理客户才可能会闹 10/03 23:37
28F：→ ggg12345:得不肯验收,现在有民代又有审调不可能一面倒,反而会是PG 10/03 23:40
29F：→ ggg12345:不耐烦不肯配合居多. 好关系跟好沟通是一体两面. 10/03 23:42
30F：推 ledia:PG 不耐烦不肯配合居多 .... 让我想到 "何不食肉靡 ?" 10/03 23:48
31F：推 trueQoo:只要多接几个专案,你会得到结果:客户全都一个样...XD 10/03 23:59
32F：→ trueQoo:不...是结论.... 10/03 23:59
33F：推 ggg12345:学校跟随他校买两校已先订制使用中的公文系统,价位不变, 10/04 00:00
34F：→ ggg12345:使用单位一开始就指明要更改几个地方做为配合,结果拖了一 10/04 00:02
35F：→ ggg12345:年,完全无法被接受,而卖方也死不肯改,最後双方作废没收保 10/04 00:03
36F：→ ggg12345:证金.这是一个需求明确也不必重新开发都能闹成这样. 10/04 00:05
37F：推 ggg12345:听说这个现成软体还维持原来的价位高达300万. 10/04 00:09
38F：推 ledia:请到刀光剑影的现实世界来吧~~~~ 10/04 01:48