IT同学们来摆一摆你经历过的失败/成功的项目吧.

crystalreal

我个人认为成功的关键在于远瞻性和坚持，一个能够适应市场需求而不断调整的项目，再加上坚持是成功的至要因素。马云说过：“今天很残酷，明天更残酷，后天会很美好，但绝大多数人都死在明天晚上”。

callcall

OVI Suite
Maemo and MeeGo
Vertu
Nokia Smarthome
没一个行的

僚人乐土

原帖由 greanbean 于 2011-10-9 21:58 发表
项目成功与否怎么定义

complete, on time, on budget

僚人乐土

前面讲了失败的那个项目，现在讲讲第二次开发成功的项目。
第一个项目的失败，对外，对上是不能公开说的，所以第二次开发我们是以升级和整合（整合功能重合的系统以降低维护费用，其实功能比不重合，这里边的政治就不说了）的名誉，因此经费不多，而且缺乏合适的开发人员，开始我觉得很玄，后来竟然搞定了。
总结成功原因：

1. 需求的把握，保证了正确的方向（再强调）
大家往往觉得需求没把握好是没有和用户沟通好的问题，其实很多情况下，需求并不是那么明确。这涉及业务模型，即管理方法。用户也需要在实践中摸索学习，才知道怎么样完成业务最好——在我们完成项目后，他们曾经和别的州，发现他们的管理水准最高。
这次的需要从以下三个方面得到了有力的保证：

• 第一个版本的问题分析；
• 更换了对系统和业务更了解人员提供需求；
• 开发人员兼职做BA。
  

2. 好的构架设计提高了开发效率
这里是一些要点：

• EF4：虽然Entity Framework由不少问题，但我们知道怎么规避这些问题，因此省了很多写数据存取代码的时间。
• 从数据存取、Web service contract，到客户端邦定，全用EF+Self Tracking Entity生成的entities，不用再写DTO之类，简化了系统。
• 在被锁定WinForms的情况下，创新地使用MVVM，使得validation在客户和服务器端的得到共享，并简化了UI邦定和错误显示。
  

3. 迭代开发以及和用户的密切沟通保证了顺利完工
有一个很给力的专职测试员，而且随时可以和用户沟通澄清需求。最后上线已没有悬念，因为双方都作了大量的测试（包括单元测试）。

中间我们想增加两个开发人员，但没招到合适的，最后竟然按时完成了，所以我们不时戏称我们是the best team in Australia.

fly050505

原帖由 僚人乐土 于 2011-10-10 22:45 发表
前面讲了失败的那个项目，现在讲讲第二次开发成功的项目。
第一个项目的失败，对外，对上是不能公开说的，所以第二次开发我们是以升级和整合（整合功能重合的系统以降低维护费用，其实功能比不重合，这里边的政治就不说了）的名誉，因 ...

其实最根本的是： 行业经验。
你要知道你的客户为什么这么操作。
如果这个都搞不明白，项目失败的风险非常大。

psaux

我做过的所有项目从技术上看都是失败的，因为客户的需求变化造成最初的设计和最后的实现出入很多，所以很多地方不完美。从公司投资上看上都是成功的，因为都给公司赚钱了。

showen

同意楼上的，好多时候用户要这改那改，还要加上team里其他人的sb意见，最后自己看自己写的东西都觉得挺恶的，想从头再重新再改过，算了，只要能跑，没那功夫弄了。

racecar

大家组建个团队吧，也搞个项目做做，发挥各自经验。

ccj5124

行业不同，如何发挥经验啊。

原帖由 racecar 于 2011-10-12 09:17 发表
大家组建个团队吧，也搞个项目做做，发挥各自经验。

key

我一直比较疑惑BA在SCRUM TEAM里怎样工作，
有机会的话，想请教一下。谢谢。

原帖由 僚人乐土 于 2011-10-9 21:49 发表


我们是采用SCRUM，项目分为大约12个迭代(iteration/Sprint)，其中，还分为两个阶段，第一阶段结束就上线使用。第二阶段增加额外的功能。而且，我们都是在现场开发，我们（包括开发人员）和最终用户（他们叫system administrator，负责 ...

key

行业经验当然重要。SCRUM TEAM里依赖PO来提供行业经验。

我想了一下，觉得撩人同学失败项目的主要原因应该是在BA和System Admin那里，
也就是僚人提到“最终竟然还是需求问题”。
System Admin提供的是一线需求，但他可能因为自身的经验和水平问题，
提供的需求并没有权威性，不能很好的反映系统真正的客服的要求。
当然，由于System Admin提供的是一线需求，所以，这个系统对于一线用户来说应该是友好的。
而BA落实文档，多少会存在一定的偏差。在这个SCRUM TEAM里，PO是由BA + System Admin
组成的两层结构。
SCRUM TEAM里PO应该具体很高的拍板权力，但僚人的项目里，PO差不多就是纯需求的提供者，
这也会存在一定的问题。不过僚人的团队由他自己做ARCH，这解决了一定的项目方向执行的问题。

后来项目重做，这个时候需求才是真正明确了，所以做起来容易多了。如果评价这个项目，
应该说是一个两倍于原来周期的迭代项目。

原帖由 fly050505 于 2011-10-10 23:17 发表


其实最根本的是： 行业经验。
你要知道你的客户为什么这么操作。
如果这个都搞不明白，项目失败的风险非常大。

key

原帖由 僚人乐土 于 2011-10-10 22:45 发表
前面讲了失败的那个项目，现在讲讲第二次开发成功的项目。
第一个项目的失败，对外，对上是不能公开说的，所以第二次开发我们是以升级和整合（整合功能重合的系统以降低维护费用，其实功能比不重合，这里边的政治就不说了）的名誉，因 ...

这个项目做得很靠谱，解决了前面一个项目的重要问题。而且由于已经有一个版本，又是同一套开发人员，的确有了天地地利人和。

更换了对系统和业务更了解人员提供需求；
开发人员兼职做BA。

这个问题我在读你前面的贴子里就发现。当然，我只是疑问，远远达不到“先见之明”。
BA在SCRUM TEAM里是很尴尬的角色。但一定说没有用，我也不敢这样下结论，还是希望僚人同学结合自己的结验说一说。

3. 迭代开发以及和用户的密切沟通保证了顺利完工
有一个很给力的专职测试员，而且随时可以和用户沟通澄清需求。最后上线已没有悬念，因为双方都作了大量的测试（包括单元测试）。

我觉得重点在于“澄清需求”这里。
我不知道你们是否有sprint demo会议，估计你们是有的。
所以，我理解这个“澄清需求”是一个及时的需求澄清，而不需要等到每个sprint结束或下一个sprint开始才去搞清楚需求。
这个很重要，学习了。

僚人乐土

BA在SCRUM TEAM里不算尴尬。其实这也就是个文档员的职位——澳洲有几个BA，不就是把用户说的写成文档而已呢？
System Admin则更像PO的角色，但对于用户来说（相对于公司自己开发的产品的PO），一般都需要BA帮忙落实成文档。
BA要在每个Sprint结束前，把下一个Sprint的需求细化成文档。

大家可能忽略了我说的 “大家往往觉得需求没把握好是没有和用户沟通好的问题，其实很多情况下，需求并不是那么明确。这涉及业务模型，即管理方法。用户也需要在实践中摸索学习，才知道怎么样完成业务最好”。 我们第一个项目做出来的东西，确实是用户要求的东西。问题是他们在实际使用中发现，有些功能的切实，使完成某些业务很不方便（这可以通过增加功能的维护工作来改善，这里有些政治斗争使得维护工作推进很慢）；原来的数据模型在处理某些业务的时候不能很好吻合（这可就伤筋动骨了）——用户如果不是真正使用第一个版本，可能也没法有这种切身体验而得出更好的管理方式。

workflow

原帖由 key 于 2011-10-17 15:50 发表


这个项目做得很靠谱，解决了前面一个项目的重要问题。而且由于已经有一个版本，又是同一套开发人员，的确有了天地地利人和。


这个问题我在读你前面的贴子里就发现。当然，我只是疑问，远远达不到“先见之明”。
BA在SCRUM  ...

Key哥也来足迹啦，不跟青山同学辩论了？

workflow

说BA没用，我非常不同意，BA是非常重要的位置，当然在某个时候可能也是尴尬的位置，澳洲这边的BA职位太笼统了，低级的BA基本就是文档员，会议记录，高级的BA基本能当solution Arch用。看上面的发言，很多技术出身的同学有个共同的观点，就是项目失败主要责任在于business，business就是end user，想想乔帮主怎么做的，把责任一味推卸给end user，从end user那里全盘copy过来的requirement，即使上线也住定是一个boring失败，而且短命的项目。

BA的重要性就在于此，差劲的BA畏畏懦懦，生怕得罪business，business说什么就是什么，无法guide用户，好的BA则会引导客户，smart的处理掉一些stupid的requirement case，当然在真正的项目，这又会涉及到N多的政治斗争，用户都不傻，当他们作出一些看似stupid的decision的时候，总是有原因的，这就需要BA去挖掘去协调，一个项目的成败可能从这个时候就已经注定了

收路费

说得很好 非常同意
现实中也的确是从BA出身的solution architect 比从developer 出身的多

greed

solution architect更需要从业务层面思考。dev出身的人往往习惯于从系统方面思考，所以还是做system architect更适合。当然如果ba方面有一定的技术背景，可以降低业务需求和系统实现的冲突。同时遇到冲突时，最终说服客户总是要以他们能理解的业务角度切入，而不是一味强调技术方面的优劣。

workflow

谈项目的成败，技术因素的影响其实非常小，这也是很多技术出身的同学不愿意面对或者承认的，我之前的一个BI项目，花了３，４年的时间，几乎上千万预算，build了巨大的EDW，最后却没有一个business来用，反而一个替代项目，只花了３个月时间一个developer，Access＋SQL Server＋Excel，用户已经用了一年，至少从上面的反响来看，还不错，尽管这个short term solution我们从技术角度看来简直就是屎一样的垃圾

key

原帖由 僚人乐土 于 2011-10-18 00:11 发表
BA在SCRUM TEAM里不算尴尬。其实这也就是个文档员的职位——澳洲有几个BA，不就是把用户说的写成文档而已呢？
System Admin则更像PO的角色，但对于用户来说（相对于公司自己开发的产品的PO），一般都需要BA帮忙落实成文档。
BA要在每个Sprint结束前，把下一个Sprint的需求细化成文档。

把Sprint需求细化成文档，好处是明显的，但似乎也有一定的缺点。首先具体文档是很heavy的东西，包括文档的制作，以及文档的更新。
前者由BA来做，对开发组来说，（某种意义说）累死他大家也未必有太大感觉。但SCRUM强调灵活性和变化，BA一旦把文档编好，大家再要求他改，
难度就有点大了。

而我最担心的则是BA对于需求是否理解正确 —— 这倒不是质疑 BA 的个人能力。如果在 PO 和开发团队之间再隔了一层 BA，会引入一些失真，
这是理论上存在的。所以，你的团队里有一个很好的补充是你来负责ARCH的工作，所以可以利用你特殊的关系和个人能力，纠正这种失真。
另外，BA也不是一无用处，因为他把东西文档化，如果System Admin有较好的文档审读能力，就可以快速的反馈 —— 可惜的是，这种System Admin
可遇而不可求。

“大家往往觉得需求没把握好是没有和用户沟通好的问题，其实很多情况下，需求并不是那么明确。这涉及业务模型，即管理方法。用户也需要在实践中摸索学习，才知道怎么样完成业务最好”

这也是我一直以来的观点：当客户看不到最终系统之前，基本上他不会给你什么有价值的意见。
所以Agile Architecture的一个重要原则是快速成型，在开始的一两个sprint里就能拿出一个东西摆在客户或 PO 面前，
让客户或PO来发现问题，提出新的观点和确定下一个阶段的计划。

总的来说，你的经验很很贵，谢谢分享，让我受益非浅！

key

那个是无聊乱搞一通……
反正说了也白说，还是找个有意思的地方灌灌水算了

原帖由 workflow 于 2011-10-18 10:02 发表

Key哥也来足迹啦，不跟青山同学辩论了？

典

请问失败的原因是什么？政治？需求？

key

原帖由 workflow 于 2011-10-18 10:15 发表
说BA没用，我非常不同意，BA是非常重要的位置，当然在某个时候可能也是尴尬的位置，澳洲这边的BA职位太笼统了，低级的BA基本就是文档员，会议记录，高级的BA基本能当solution Arch用。看上面的发言，很多技术出身的同学有个共同的观 ...

我倒不敢General地说BA有用还是没用，
我只是想知道，以大家的经验，在SCRUM TEAM里，BA的作用是什么。

好的BA则会引导客户，smart的处理掉一些stupid的requirement case，当然在真正的项目，这又会涉及到N多的政治斗争，用户都不傻，当他们作出一些看似stupid的decision的时候，总是有原因的，这就需要BA去挖掘去协调，一个项目的成败可能从这个时候就已经注定了

处理掉requirement case这个有一定风险，除非这个“好”的BA行业经验真的丰富得很。
从产品的角度来说，这种决策非常好，也很重要。
但从项目性产品的角度来说，风险就高了。
不过我非常认同“引导客户”这种做法，客户是很需要引导的。

workflow

原帖由 典 于 2011-10-19 11:02 发表
请问失败的原因是什么？政治？需求？

水很深，算是政治吧，不过BA的问题很大

key

我以前公司也有类似的失败经历。
所以我现在一提到重型技术，长周期开发，我都头痛，不敢往下想。

原帖由 workflow 于 2011-10-19 09:59 发表
谈项目的成败，技术因素的影响其实非常小，这也是很多技术出身的同学不愿意面对或者承认的，我之前的一个BI项目，花了３，４年的时间，几乎上千万预算，build了巨大的EDW，最后却没有一个business来用，反而一个替代项目，只花了３个月时间一个 ...

workflow

原帖由 key 于 2011-10-19 11:22 发表
我以前公司也有类似的失败经历。
所以我现在一提到重型技术，长周期开发，我都头痛，不敢往下想。

这种项目没有一个CEO级别的高管长期支持，基本注定会失败，大公司大项目都喜欢找ACN，IBM这些consulting公司，而ACN，IBM这些公司的老板很多都跳到客户那边，关系错综复杂，比如原来Telstra的CIO就是ACN跳过去

Fernando

我们这里的CIO也是IBM过来的，高层经理都是CIO从IBM带过来的。很多PM，manager都是contract，只要进了他们那个圈子，就可以长久得做contract混下去，那些人随便一年就超过足迹平均水平了

很少有项目失败是技术原因造成的，曾看到一个DW失败的，也是因为政治原因选错平台的关系。

key

原帖由 Fernando 于 2011-10-19 11:45 发表
很少有项目失败是技术原因造成的，曾看到一个DW失败的，也是因为政治原因选错平台的关系。

嗯，这句话在这个贴子里被提了两次，
看来下次面试时，不能用“项目成功”也证明自己技术过关了。

黑山老妖

做项目最怕可能是公司内部的politics

workflow

don't be afraid, politics are everywhere

[ 本帖最后由 workflow 于 2011-10-19 13:30 编辑 ]

黑山老妖

有时候politics绝对可以让一个project死翘翘。