论坛首页 综合技术论坛

我的创业体会和大公司的做事比较

浏览 52275 次
该帖已经被评为精华帖
作者 正文
   发表时间:2010-04-20  
不能把书本上写的,硬往项目里搬。否则得不偿失,应该灵活应用,也可按大家的较为效率高的习惯和方法去解决问题。最终目的就是按时,按质的完成项目。而不是一堆形式主义。。
0 请登录后投票
   发表时间:2010-04-20  
抛出异常的爱 写道
zwchen 写道
我补充两点吧:
1、文档 我们最重原型,也许因为我们是旅游电子商务网站,与业务员、设计师、开发人员沟通都是它(看附件)。
2、利益 管理的本质就是管理利益,只是没必要挂到嘴边,每个人的利益追求都不一样,薪水只是一种利益。团队成员是否开心,会有一种自然的流露。比如,我从不限制我们团队上网,只是告诉他们,要是有很想下载的大片,建议限速到100k。我们团队始终是自觉在上班时间将QQ隐藏或是不开,多数时候还是我提醒开一下QQ。我从未看到有人专门去浏览娱乐资讯,有时我可能会发一些好文给他们。我也会告诉他们,要是哪天晚上没睡好,就迟些来,因为状态不好和怠工没啥差别,对自己和公司都不好。比如今天中午大楼停电,我告诉他们:等电来,还是现在回家,你们自己决定吧,我走了。因为我要去公司业务部门沟通。

    总之,我的责任,就是挖掘他们的潜力,让他们热爱自己的工作。另外,他们进公司时,薪水都是他们告诉我一个期望值,然后我满足他们,并且还超出一点,没有一次我砍过价。

原型法。。。。
如果需求稍微复杂一点点
就看出它的能力太有限了。。。。

去年有个项目
100多页的PPT
(几乎每个按钮都有中英文说明)
最后结果是项目几乎重作。。。

画图比做程序快得多,所以PS图片原型还是很快的。改起来也快。
0 请登录后投票
   发表时间:2010-04-20  
楼主总结的很好,立意也很广,不仅仅是说项目管理的问题,看了很有同感。有些回复有点狭隘了
0 请登录后投票
   发表时间:2010-04-20  
EldonReturn 写道
抛出异常的爱 写道
zwchen 写道
我补充两点吧:
1、文档 我们最重原型,也许因为我们是旅游电子商务网站,与业务员、设计师、开发人员沟通都是它(看附件)。
2、利益 管理的本质就是管理利益,只是没必要挂到嘴边,每个人的利益追求都不一样,薪水只是一种利益。团队成员是否开心,会有一种自然的流露。比如,我从不限制我们团队上网,只是告诉他们,要是有很想下载的大片,建议限速到100k。我们团队始终是自觉在上班时间将QQ隐藏或是不开,多数时候还是我提醒开一下QQ。我从未看到有人专门去浏览娱乐资讯,有时我可能会发一些好文给他们。我也会告诉他们,要是哪天晚上没睡好,就迟些来,因为状态不好和怠工没啥差别,对自己和公司都不好。比如今天中午大楼停电,我告诉他们:等电来,还是现在回家,你们自己决定吧,我走了。因为我要去公司业务部门沟通。

    总之,我的责任,就是挖掘他们的潜力,让他们热爱自己的工作。另外,他们进公司时,薪水都是他们告诉我一个期望值,然后我满足他们,并且还超出一点,没有一次我砍过价。

原型法。。。。
如果需求稍微复杂一点点
就看出它的能力太有限了。。。。

去年有个项目
100多页的PPT
(几乎每个按钮都有中英文说明)
最后结果是项目几乎重作。。。

画图比做程序快得多,所以PS图片原型还是很快的。改起来也快。

不是快慢问题,主要是信息含量低。。。
一般的J2EE可以用原型来作。
一但是比较复杂的业务+按钮多一点,
很难一下子明白,作好。之后BUG滚滚而来
0 请登录后投票
   发表时间:2010-04-20  
抛出异常的爱 写道
EldonReturn 写道
抛出异常的爱 写道
zwchen 写道
我补充两点吧:
1、文档 我们最重原型,也许因为我们是旅游电子商务网站,与业务员、设计师、开发人员沟通都是它(看附件)。
2、利益 管理的本质就是管理利益,只是没必要挂到嘴边,每个人的利益追求都不一样,薪水只是一种利益。团队成员是否开心,会有一种自然的流露。比如,我从不限制我们团队上网,只是告诉他们,要是有很想下载的大片,建议限速到100k。我们团队始终是自觉在上班时间将QQ隐藏或是不开,多数时候还是我提醒开一下QQ。我从未看到有人专门去浏览娱乐资讯,有时我可能会发一些好文给他们。我也会告诉他们,要是哪天晚上没睡好,就迟些来,因为状态不好和怠工没啥差别,对自己和公司都不好。比如今天中午大楼停电,我告诉他们:等电来,还是现在回家,你们自己决定吧,我走了。因为我要去公司业务部门沟通。

    总之,我的责任,就是挖掘他们的潜力,让他们热爱自己的工作。另外,他们进公司时,薪水都是他们告诉我一个期望值,然后我满足他们,并且还超出一点,没有一次我砍过价。

原型法。。。。
如果需求稍微复杂一点点
就看出它的能力太有限了。。。。

去年有个项目
100多页的PPT
(几乎每个按钮都有中英文说明)
最后结果是项目几乎重作。。。

画图比做程序快得多,所以PS图片原型还是很快的。改起来也快。

不是快慢问题,主要是信息含量低。。。
一般的J2EE可以用原型来作。
一但是比较复杂的业务+按钮多一点,
很难一下子明白,作好。之后BUG滚滚而来

举个例子吧,我们是不需要数据库移植的,我们只用mysql,移植到Oracle,纯粹是yy。

原型对我们表达需求基本够用,我们就限定在这一个项目。

如果换一个项目,我们可能会很看重架构图和数据库ER图。
0 请登录后投票
   发表时间:2010-04-20  
嗯,讲的很好。。。
0 请登录后投票
   发表时间:2010-04-20  
关键是让你的队员理解他们做什么,并觉得有意思。

另 生存为王,没到需要的时刻,不要拿出耗时耗力的单元测试,流程文档来祭旗。。

他们有巨大的作用,但只有在恰当的时候才有恰当的作用,单元测试最核心的意义在于修改。而流程文档的意义在于铁打营盘流水兵,如果暂时无此忧虑可不去考虑。
7 请登录后投票
   发表时间:2010-04-20  
repsihWDX 写道
关键是让你的队员理解他们做什么,并觉得有意思。

另 生存为王,没到需要的时刻,不要拿出耗时耗力的单元测试,流程文档来祭旗。。

他们有巨大的作用,但只有在恰当的时候才有恰当的作用,单元测试最核心的意义在于修改。而流程文档的意义在于铁打营盘流水兵,如果暂时无此忧虑可不去考虑。

这个可以有
你要是作过EJB就会明白了。
重启一次要盒钱。
0 请登录后投票
   发表时间:2010-04-20   最后修改:2010-04-20
抛出异常的爱 写道
repsihWDX 写道
关键是让你的队员理解他们做什么,并觉得有意思。

另 生存为王,没到需要的时刻,不要拿出耗时耗力的单元测试,流程文档来祭旗。。

他们有巨大的作用,但只有在恰当的时候才有恰当的作用,单元测试最核心的意义在于修改。而流程文档的意义在于铁打营盘流水兵,如果暂时无此忧虑可不去考虑。

这个可以有
你要是作过EJB就会明白了。
重启一次要盒钱。

如果我的项目根本就不可能出现EJB?
不要拿技术说事,先说环境。你的环境,如项目业务特点、项目组人员构成、项目进度、资金等决定你要采用什么技术。我以前是崇拜技术,现在是玩技术。
刚刚看到一篇文章,可能和这个主题有一点点关系:http://java.dzone.com/articles/creating-software-product-are

引用
The goal of software, be it web, mobile or desktop applications, is to help achieve business goals. However, without achieving people's goals, and with that the ones of software users, it is very unlikely that the business will achieve its own goals. This is why software projects should start with design, not programming. User centric design, that is, where accent is on understanding users and especially their activities. Not to diminish the value of other aspects, the quality of user experience is the most important.

0 请登录后投票
   发表时间:2010-04-20   最后修改:2010-04-20
告诫各位处于开发第一线的朋友,千万不要受本文的误导,把规范和设计文档不当回事。

我的看法:
1、文档的多少和深度决定于项目环境。
    如果是大项目,比如二三十开发人员,架构文档、需求文档、代码规范等都是必须,否则开发人员不能迅速了解项目技术和业务特点,从而无法快速开发,也即是规范可以降低培训成本和团队沟通;另外,项目开发中后期可能根本不可控,谁都看不懂其它人的代码。部署时看到的一些bug无法及时修复,因为到处都有地雷。我以前经历过这样的项目,最后加班都没用。

    如果是产品型,规范更重要。当然我说的产品可能是2.0版以后,因为这时候的产品基本得到了市场的认可。而在初版时,代码写得烂都没关系,因为你不不知道用户会不会买单,也不知道能否按进度开发完成。而在后续版本,如果没有规范文档,维护的成本都不亚于重新开发。特别是处于一线的开发人员会怨声载道:为什么要我来收拾残局?那么,这样的士气,开发效率怎么会高,项目质量怎么会高?

2、成熟型大公司那套做事流程,可能高手受不了,但可能是最优的方案。因为,到项目后期维护,往往只是一些业务功能的删减改进,不需要技术高手,这个过程可能漫漫几年,项目维护成本会非常高,雇佣高手一来他不愿意干二来也不需要这种人,如果项目代码还维持在一种“秩序”,初中级开发人员就可以胜任,有什么不好呢?
   项目上线时,是为了追求利润。项目维护期,是为了省成本。

3、刚入道的朋友,最好是按规范来,就像学武术,先要学套路。否则,养成的编程坏习惯,比如文件名叫Aaa1.java,代码没有缩进。过几年非常难改。而好的编程习惯,可以提升开发效率,还能让自己思维清晰。
   学技术阶段,一定要注意代码的可维护性、健壮性及灵活性,只有养成对代码精益求精的态度,你才可能成为技术高手。技术学好,做技术管理就有了基础,而且别人也会服你。

0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics