Z*******n
发帖数: 694 | 1 本人在一个大型企业工作多年，最近的工作是设计开发公司内部使用的一个软件(a
software tool to support business planning)。此项目已经有两年了，说说学到的
教训。
教训第一是软件的最终用户(end user)必须很明确，而且越早确定越好（软件发展周期
越短）。本人认为，企业软件(enterprise software)跟消费者软件(consumer
software)的一个重要区别，就是企业软件的最终用户不能以数量来定大小。Facebook
可用论多少用户帐号；企业软件的用户是看用户的内部位置而定的（当然数量也重要）
，还有数据来源的复杂度。我们这个软件的用户都是在企业内部的中层领导，人数并不
多。但是我们在确定最终用户这个软件发展最重要的环节上，出过很多问题。
一开始，我们觉得这个软件的最终用户是VP和VP以上的高官。第一个示范模型做出来以
后，发现VP们根本不想自己座下来用这个软件；他们都会指定一个下属来用我们的软件
，最后也就是把我们软件的输出图表拷贝到他们的powerpoint里面。一开始我们并没有
做Executive Dashboard的界面; 后来发现，系统里面的Executive Dashboard 是非常
非常的重要。
VP的下属们也都很忙，学一个新的软件对他们来说是一个累赘，他们想方设法推迟软件
的使用。 问他们有什么意见，大都支吾过去（没有具体的、建设性的comment）。有时
解决了一个用户的问题，发现下一个用户的问题又完全不同， 我们又得修改我们的程
序。 这时真正体会到了“winning customers， one at a time”的苦楚。
用户群的确定也是一个不断发现(discovery)的过程。本来以为我们的用户群主要是公
司人事部（HR），后来发现还有策略部(Strategy Team)和运作部(Operations Team)。
这些部门的人看的数据不同，要的报表也不同。有的用户是finance出身，对财务数据
很感兴趣很熟；有的人却对财务数据很讨厌。还有他们经常有内斗，所以我们常常会被
人觉得是在讨好一部分人，而引起另外一部分人的反感。在这种场合，常常觉得自己的
communication skills还远远不够用。
最后，我们的project有公司更高层的支持，才得以持续下来，否则也早夭折了。由于
不同用户不同要求，我们的软件也在滚雪球，越滚越大。到了后来，我们这个只有几个
人的development team 已经非常吃力了，常常加班加点也还miss掉deadlines。 而且
有的用户已经开始抱怨软件太复杂了。
现在回想起来，走过很多弯路，比如一开始对用户不够了解，用户对象不能明确定下来
，而且对dashboard的接口、对数据来源的重视不够。以后要是有机会，可以跟同行们
交流交流。也希望得到同行的指点。 |
p******w
发帖数: 62 | 2 非常好的经验！谢谢分享
Facebook
【在 Z*******n 的大作中提到】
: 本人在一个大型企业工作多年，最近的工作是设计开发公司内部使用的一个软件(a
: software tool to support business planning)。此项目已经有两年了，说说学到的
: 教训。
: 教训第一是软件的最终用户(end user)必须很明确，而且越早确定越好（软件发展周期
: 越短）。本人认为，企业软件(enterprise software)跟消费者软件(consumer
: software)的一个重要区别，就是企业软件的最终用户不能以数量来定大小。Facebook
: 可用论多少用户帐号；企业软件的用户是看用户的内部位置而定的（当然数量也重要）
: ，还有数据来源的复杂度。我们这个软件的用户都是在企业内部的中层领导，人数并不
: 多。但是我们在确定最终用户这个软件发展最重要的环节上，出过很多问题。
: 一开始，我们觉得这个软件的最终用户是VP和VP以上的高官。第一个示范模型做出来以
|
l**y
发帖数: 2103 | 3 这些走的弯路，是你们自己犯的错误可以避免的呢，还是大多数你们无法控制的（比如
企业内斗之类的）？换句话说如果下次遇到一个一模一样的project，你们打算怎么做
？ |
b**j
发帖数: 20742 | 4 上个project management的课，会有帮助的。
【在 l**y 的大作中提到】
: 这些走的弯路，是你们自己犯的错误可以避免的呢，还是大多数你们无法控制的（比如
: 企业内斗之类的）？换句话说如果下次遇到一个一模一样的project，你们打算怎么做
: ？
|
Z*******n
发帖数: 694 | 5 内部斗争是我们避免不了的。但是，下次遇到一个一模一样的project,我会一开始就搞
清楚，到底谁说了算－－而不是please everybody.
【在 l**y 的大作中提到】
: 这些走的弯路，是你们自己犯的错误可以避免的呢，还是大多数你们无法控制的（比如
: 企业内斗之类的）？换句话说如果下次遇到一个一模一样的project，你们打算怎么做
: ？
|
Z*******n
发帖数: 694 | 6 这是边干边学啊；到了后来才知道project planning的重要。
【在 b**j 的大作中提到】
: 上个project management的课，会有帮助的。
|
b**j
发帖数: 20742 | 7 developer转project manager，这太正常了。呵呵。
【在 Z*******n 的大作中提到】
: 这是边干边学啊；到了后来才知道project planning的重要。
|
c*****a
发帖数: 447 | 8 谢谢分享。 这比那些成功故事有用多了。 其实大家都走好多弯路的。 有时有人能提
醒一下。 就避免好多麻烦。 不过真的有公司开始运营的人。都太忙。 大家能拿出来
社交认识下的时间也不多。
Facebook
【在 Z*******n 的大作中提到】
: 本人在一个大型企业工作多年，最近的工作是设计开发公司内部使用的一个软件(a
: software tool to support business planning)。此项目已经有两年了，说说学到的
: 教训。
: 教训第一是软件的最终用户(end user)必须很明确，而且越早确定越好（软件发展周期
: 越短）。本人认为，企业软件(enterprise software)跟消费者软件(consumer
: software)的一个重要区别，就是企业软件的最终用户不能以数量来定大小。Facebook
: 可用论多少用户帐号；企业软件的用户是看用户的内部位置而定的（当然数量也重要）
: ，还有数据来源的复杂度。我们这个软件的用户都是在企业内部的中层领导，人数并不
: 多。但是我们在确定最终用户这个软件发展最重要的环节上，出过很多问题。
: 一开始，我们觉得这个软件的最终用户是VP和VP以上的高官。第一个示范模型做出来以
|
u**k
发帖数: 771 | 9 你去个新环境可能还会碰到新问题。我觉得你最大教训应该是没有一个process。其实
只要follow一个好的process你说的这些问题都可以避免或妥善解决。
稍微正式一点的软件开发都有process。这些process都是前人磕磕碰碰总结出来的。不
需要完全照搬，参考一下绝对有好处。
【在 Z*******n 的大作中提到】
: 这是边干边学啊；到了后来才知道project planning的重要。
|
s*********e
发帖数: 4475 | 10 这是大公司政治故事，大量资源投入到一个没人要用的项目里。
创业小公司完全不是这样的。
【在 c*****a 的大作中提到】
: 谢谢分享。 这比那些成功故事有用多了。 其实大家都走好多弯路的。 有时有人能提
: 醒一下。 就避免好多麻烦。 不过真的有公司开始运营的人。都太忙。 大家能拿出来
: 社交认识下的时间也不多。
:
: Facebook
|
|
|
Z*******n
发帖数: 694 | 11 在大公司混，确实是觉得很多资源都在浪费。
我们team的每个人，都花了力气，但是最后结果还是跟开初想象的不一样。
是不是创业小公司也是有一个 “寻找”项目定位的问题？
【在 s*********e 的大作中提到】
: 这是大公司政治故事，大量资源投入到一个没人要用的项目里。
: 创业小公司完全不是这样的。
|
Z*******n
发帖数: 694 | 12 是的。
有一个同事，一直在强调process，可惜我们一开始没听他的话。还有，我们一开始都
认为，这个project一会儿就做完了，不需要正式的process. 事实与愿相反。
【在 u**k 的大作中提到】
: 你去个新环境可能还会碰到新问题。我觉得你最大教训应该是没有一个process。其实
: 只要follow一个好的process你说的这些问题都可以避免或妥善解决。
: 稍微正式一点的软件开发都有process。这些process都是前人磕磕碰碰总结出来的。不
: 需要完全照搬，参考一下绝对有好处。
|
s*********e
发帖数: 4475 | 13 大公司钱太多， 养闲人， 才需要给没用的项目找定位。
小公司startup根本没机会考虑这种项目。
【在 Z*******n 的大作中提到】
: 在大公司混，确实是觉得很多资源都在浪费。
: 我们team的每个人，都花了力气，但是最后结果还是跟开初想象的不一样。
: 是不是创业小公司也是有一个 “寻找”项目定位的问题？
|
l******f
发帖数: 210 | |
e**********a
发帖数: 279 | 15 想问问你的角度，现在和将来另一个新项目时会对那个同事再提出的意见增加重视吗？
很不幸，我最近两次的project,都沦落为你说的那个同事的位子，倒不是说我怎么厉害
有先见知名，我很痛苦，我的话不被听，我稍微坚持一下的话就被扣上没有团队合作，
不professional的大帽子。你们那个同事提的时候，你现在觉得要怎么样，能被你们当
时接受呢？
【在 Z*******n 的大作中提到】
: 是的。
: 有一个同事，一直在强调process，可惜我们一开始没听他的话。还有，我们一开始都
: 认为，这个project一会儿就做完了，不需要正式的process. 事实与愿相反。
|
m******p
发帖数: 5393 | 16 很实际，thx
Facebook
【在 Z*******n 的大作中提到】
: 本人在一个大型企业工作多年，最近的工作是设计开发公司内部使用的一个软件(a
: software tool to support business planning)。此项目已经有两年了，说说学到的
: 教训。
: 教训第一是软件的最终用户(end user)必须很明确，而且越早确定越好（软件发展周期
: 越短）。本人认为，企业软件(enterprise software)跟消费者软件(consumer
: software)的一个重要区别，就是企业软件的最终用户不能以数量来定大小。Facebook
: 可用论多少用户帐号；企业软件的用户是看用户的内部位置而定的（当然数量也重要）
: ，还有数据来源的复杂度。我们这个软件的用户都是在企业内部的中层领导，人数并不
: 多。但是我们在确定最终用户这个软件发展最重要的环节上，出过很多问题。
: 一开始，我们觉得这个软件的最终用户是VP和VP以上的高官。第一个示范模型做出来以
|
Z*******n
发帖数: 694 | 17 我现在会很愿意听我那位同事的意见。以后我也不会随便接这种project.
问题出在我们的用户们都很“大牌”，他们的requirements也变来变去。 当时我们觉
得没办法实行我们要的process。
【在 e**********a 的大作中提到】
: 想问问你的角度，现在和将来另一个新项目时会对那个同事再提出的意见增加重视吗？
: 很不幸，我最近两次的project,都沦落为你说的那个同事的位子，倒不是说我怎么厉害
: 有先见知名，我很痛苦，我的话不被听，我稍微坚持一下的话就被扣上没有团队合作，
: 不professional的大帽子。你们那个同事提的时候，你现在觉得要怎么样，能被你们当
: 时接受呢？
|
