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

   工作五年，一晃已年过三十了。读研时，独立做项目，毕业头三年，主要在大公司工作，后来，也就是08年，半创业。具体点，合伙人吧，自己负责IT部门，到现在6人，公司总共20来人，旅游业。这两年严酷的创业经历，让我越发觉得管理(做事)，以及领导(带人、待人，不是管人)的重要性。因为，随着组织的扩大，混乱度无形中就会增大，管理和领导，就是让这种混乱重归有序，重归单人作战那种意图和行动的高度统一。

    说得功利点吧，一个人的财富和其影响力是成正比的。影响力本质上就是对他人的价值。比如，郎_xian_评的出场费一天超过15万。作为技术人员，如果我们只能影响周边几个人，那么我们凭什么拿那么高的报酬，除非我们做的事情影响了很多人，比如杨勃的豆瓣网。所以，我还是觉得，技术人员往高处发展，逐渐应该有管理意识、培养自己的管理能力。技术从书本上可以学到很多，管理还真得实践，书上看到的，你觉得很弱智的问题，比如盲目扩张，自己亲身经历时，一样会犯，也许是行为习惯在起作用，看书不足以改变行为。

    回到正题上。
    也许是自己曾经在较大公司或团队的做事习惯和视野，刚创业时，用在这种小团队的商业项目开发上，几乎惨败。
    先说项目开发这块吧。
    大家知道，项目管理和过程管理是两码事，前者关注目标和进度，成本和收益；后者关注做事流程、方法。
    项目管理，体会最深的，就是目标和任务分解、进度控制，以及沟通。

    项目管理软件
    从大公司出来的人，我想最喜欢玩的，就是借助于项目管理软件(核心是甘特图)。市面上的大多数知名的项目管理软件，无论是桌面版还是网页版的，我都试过。当然最后也选择了一款：ConceptDraw Project，用了一年多，也多少有些用。但最后还是发现，它其实对项目进度和质量关系并不大。也许，一个Excel表格更实用。
     项目管理软件，本质上是解决一种沟通和职责分配的问题。比如，一个项目，折叠成一个三层树形结构，老板只关心第一层，也就是整体进度；中间是项目经理关注的功能层，最后一层，也就是具体的任务，是开发人员关注的。想想，如果没有这玩意，你怎么告诉其它项目干系人进度？但又引出几个问题：
    靠文档来沟通，还是靠信任? 太在乎文档，往往导致每天去关注文档如何漂亮、有说服力，并为此花大量时间，而不是项目如何漂亮。另外，是否有文档就可以防止扯皮、兑现承诺？我们是关于项目目标，还是关注彼此的博弈？

    进度偏差 创业型项目，往往都是以前没有接触过，其进度评估往往有很大误差，比如业务需求的挖掘和变化，技术难点，开发人员素质。我们是关注进度，还是关注项目本身的质量？两者都要，但如何兼顾？虽然有方法学，比如砍掉优先级低的，但你怎么让老板相信某个核心功能就得四天时间。
    在我们的进度设计不合理情况下，是否开发人员完成甘特图(WBS)下的任务就ok？远远不够，任务分得太细，往往限制了开发人员的创造性和自我评估能力，如果提前两天完成呢？
    我们现在是以项目管理软件为辅，任务的下达主要以邮件传达，每周一上午的周例会会白板宣布。我发现白板比投影仪PPT好用。

   关于规范
   这也是大公司特别喜欢玩的。
   也许我们前期会制定一个的架构、设计文档，代码规范，这有一个规范建立的时间成本以及规范本书的合理性，再说如果一个开发人员，特别是高手，如果不认同你的设计和规范，你要强推，他要么走人要么怠工。规范的本质是为了协作和后期可维护，如果只有两个人或一个人写某个模块，你觉得有这个必要吗？规范整洁的代码，在项目初期，对用户的价值关系很小，你会关心豆瓣网的js代码写得很漂亮吗？我们应该关注代码的健壮性而不是可维护性，我们不是在开发Windows。

    人适应项目，还是项目适应人
    大公司，往往是来了一个项目，赶快招人，人来适应项目。小公司呢，我现在的看法是，项目适应人。小公司，往往一个项目做砸，公司就面临解散。所以，我认为，最好还是按照开发人员的擅长，保证功能质量，最快的速度上线。另外，为了达成进度，可以在上线初期砍掉不太重要的栏目或功能。
    我在这个上面栽过跟头的。比如开发人员的擅长，如果他擅长jsp开发模式，而不是Hibernate+Spring的分层开发，就让他按自己的意思做吧。因为，创业型项目都不会太大；即使技术实现你感觉完美了，用户可能感觉不爽；再说，项目开发，涉及到业务调研、需求分析、原型界面、架构、开发、部署、推广。开发，也就是代码实现，占去项目时间，也许不到30%。项目如果证实有商业前景，代码重新实现一遍，花不了多少时间。
    但我也深深地意识到我们项目管理的级别，就如同CMM1到CMM4。但我还是觉得目前是最好的选择。
    如果最低层次的用户需求目标都达不到，直接考虑代码怎么有可扩展性、可维护性，对于小公司就是找死。
    另外，尊重和信任、支持开发人员的技术选择，往往是一种激励、增强团队凝聚力的方式。万众一心，比什么目标、进度更有效、实际。
    我们应该培养一种团队成员的内部创业心态，而不只是敬业。

    在进度把控上，我现在更倾向于强调我们的项目目标和紧迫性，而不是他们的任务。因为我希望大家的关注点是项目，而不是他的上级，他应该对项目负责，而不只是对上级负责。

    说说沟通
    项目管理中最难处理好的，就是沟通。以前，我比较关注于工具，如邮件、文档、ppt讲稿会议，逐渐我关注效率和效能，特别是态度。沟通最基础的就是态度。如果网站上线后，订单提交出现一个核心bug，你是直接找开发人员问责；还是告诉他哪儿出了问题，这个问题的严重，并且自己反省，比如测试流程出了问题。出现这种事情，也许需要负责人举重若轻的气度。但更深层次的，如果负责人能够培养其员工质量意识，危机意识，才是治本。因为一个有强烈质量意识的团队，他自然会去对代码健壮性、功能易用性精益求精，自然会去配合测试流程。
   刚才那个沟通问题，对开发人员的态度，前者是负面，后者是中立。那么前者，开发人员的反应是如何不让领导下次责怪自己，比如只做领导安排的事情；后者的反应是怎么去改进，不让这样的事情发生。
   如果你认可创新就可能出错，如果你认可开发人员都是想做好的。那么所有的事情，朝正向发展迈出了最决定性的第一步。

   沟通:命令式还是征询式
   在沟通，特别是下达任务或做决策这类事情上。应该说中国绝大多少管理者都是用命令式。我过去经常在用，但一直在试图改正，改用建议式和征询式。管理者最需要、最难开口的一句话是：Do you think so？命令的方式，经常出现下级不能理解上级的意图，严重的出现抵触。每个人，其实都喜欢别人按自己的想法做事，但你怎么知道自己的想法或决策是对或不是偏颇的，怎么让团队愿意去执行？去征询团队其他成员的意见，让他们参与，往往能够培养其主人翁意识、责任感、向心力，还能够完善自己的想法。但要将员工参与意识，转化为一种习惯，太难。
    当大家都没有主见时，需要领导者的果断、魄力和强势，但这种机会并不多，而且这种情况，需要团队成员对领导者的信任。
   
    遵守制度，还是建立信任
     在大公司，往往是告诉你怎么去遵守公司制度。在小公司，我认为最基础、最核心的一件事，就是建立信任，让团队信任你的人品(说到做到)，信任你的能力(能够把大家带到一个新的高度)。建立了信任后，下一步的核心工作，怎么将你的个人目标，也就是团队目标，转化为每个成员的个人目标。
    有了信任这个基础，才会有了团队建设的第二个核心：激励。
    是激励，而不是约束、监督，让团队有战斗力。但大公司往往喜欢后者。也许，大公司都是职业经理人，反正是打工，太关注于事。如果说有个所谓的中国式领导，我觉得就是以人为本，对人的尊重。人的关系处理好了，事情就好做。
    加班、考勤、上网监控，这类对信任、激励极具破坏力的行为，也许是工业型社会对我们这个思考性创造性行业的侵蚀。知识型劳动者，需要一种与体力型劳动者完全不同的管理模式，这种模式也许需要一个从萌芽、生长到成熟期。现在在目前的中国，还只是刚走出萌芽期。
   
    以前完整看过余世维的11套视频，还看过几遍。他那种人本理念我还是很认同，只是，他在大公司、规范公司的做事情方法和风格，完全照搬拿到小公司，非常危险。你能够拿幼儿园那种教育方法来教育成年人吗？小公司不具备大公司那种职业化的环境，也不具备大公司在行业中的市场地位及资金实力。
    如果说大公司讲究做事方法、流程，如SWOT分析法、BCG矩阵，小公司更看重灵活性、市场适应性。小公司应该适当短视、急功近利，否则在你实施一个三年计划时，第二年还不赚钱可能就撑不下去。
    所以我觉得，在跨国大企业呆惯了，出来创业很危险。一个是做事方法不适应，另外一个就是没有平台。如果要出来创业，以前那种大企业的经历可能更是一种劣势。 也许有一种情况，你是大公司的高官，拿到一笔很大的风险投资，然后出来创业。
    
    人事招聘
     薪水  如果公司给得起，并且应聘者能力差不多。 就不要太在乎那200、300。虽然说至少要不低于行业平均值（IT人员是IT行业平均值，而不是本公司所在的行业平均值），但最重要的，还是不要低于当事人的期望值，因为最核心的是满意度，而满意度决定于期望值和实际值的差距。对于小公司，往往一个人技术人员的成本和收益，和其工资差距非常大，有可能10倍。所以，我们的关注点，应该是怎么一开始留住这位人才。然后，怎么让其充分发挥潜力。小公司往往不是因为节省那几千几万的工资成本死掉的，而是充分利用这位人才才活下去了。

     另外，不要以为有多少人才选择的机会，小公司往往不受高级人才的青睐。太高级的人才，可能养不起，而且往往太有个性，很难合作愉快，除非在来公司前有很长时间的了解。
     招聘到合适人才后，应该让其忘掉薪水，专注于工作，寻找工作本身的乐趣。当然，要做到让其在薪水上有优越感，也许是项目很盈利的那一天，开始时很难。

     人才标准 如果其能力和你预期相差不大的话，更应该考虑其态度、做事风格，甚至是价值观。因为其能力的发挥，和这个环境，特别是他的直接利益相关者，也就是上司，关系太大。如果配合得好，一个人可以顶三个。否则，那种内耗导致的进度延期，由此引起的市场机会丧失，公司财力无法支撑，往往是致命的。因为一个几人的IT团队，每一个人的职责就如同那木桶的一块板，缺了那块都存不了水。
     比如关于质量，更确切说是内容质量，我们目前做旅游电子商务，我认为内容质量很核心。但你招进来的同事，始终认为先要量，什么都可以抄，而我强调质，原创、半原创，可以少而精，而不能多而乱。除开项目进度，怎么去沟通？最好两个人一开始都认同原创的力量。

     提升一个人的技能不难，但改变一个人的态度比较难，改变一个人的价值观几乎不现实。所以先找志同道合的人吧。    
     别期望人才是可替代的。我们不是大公司，我们缺了谁，那一块就不转。
     大家都知道，松耦合要付出代价，比如SOAP协议的低性能，AMF私有协议的高性能。创业期，不要太多考虑人才替换，而是关注怎么发挥人的潜力，留住人，尽快高质量完成项目。人才替换的一个假设，可能是你对自己管理的不自信，因为你不相信自己能够留住人。
    
     这次就写这么多吧。
     我似乎有这种体会，考大学、四六级这类资格、证书类考试最好混，因为只要勤奋就可以，再加点方法就可以出类拔萃了。  上班也比较好混，说找工作吧，像我搞技术的，本身对技术很狂热，根本就不愁找不到工作，因为面试时我觉得那家伙应该比我牛，正好可以切磋切磋，没想太多所以没啥怯场或不自信。工作吧，如果是技术类，特别是商业软件，技术难度都不大，按上司意思来，很容易搞定。创业呢，自己要做商业判断、业务决策，还要协调若干人的工作(协调的本质是协调利益)。做事和管事，完全是两码事，有些难。不过，创业还是很有意思，因为你可以按自己的意愿去工作去生活，当然也是受限环境的自由。


我将我的一个回复放在这个地方，特示警醒：

引用

告诫各位处于开发第一线的朋友，千万不要受本文的误导，把规范和设计文档不当回事。

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

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

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

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

评论

63 楼 wxw404 2010-04-22  

小团队需要有干劲的人\想创业,才会有未来。
感觉楼主讲的很实在，有点想去你那坐坐。

62 楼 sichanlandag 2010-04-22  

lz写得不错 呵呵 我现在也的好好学习

61 楼 andey007518 2010-04-22  

恩，看到楼主的文章，想想自己的以后是否可以达到这样的高度？专业技术，项目管理，公司经营，对于自己，还有很长的路要走。一起加油～～

60 楼 maincoolbo 2010-04-22  

   在什么位置 说什么话，，楼主是在 中层的位置上，说的话，我们这样干活的都爱听，，


    明天楼主做了大老板，，可能就不这么说了，，

59 楼 taochenpfj 2010-04-22  

兄弟们，我们这行的公司就像是“围城”，哪里都可能有吸引我们的地方，哪里都可能有其缺点，但是lz所言的确值得思考，学习了

58 楼 rikeinei 2010-04-21  

zwchen 写道

一蓑烟雨任平生 写道

流程和规范跟公司大小没有关系，我没有见过什么高手敢抵触公司的条例，既然进公司就要遵守公司的制度，这是职业操守，拿不住他不就是因为没钱找人替换他么？拿不住以后出事问题更大。因为没钱所以找低成本的人，指望通过项目能把人培养出来，这个想法很不现实。有潜质的人做的好很快就走，留下来的该怎样还怎样。

还真的有关系，小公司招人不容易，能力强点的，看到小公司都不投。我们招聘条件上明确了薪水，还是有竞争力的。

另外，人的替换成本很高，如果就三个人开发代码，走了一个，那么进度就可能延期一个月。

技术好的，一般会有些性格，让其做的开心，往往其责任感会强很多，效率也会高很多。再说，几个人开发的项目，复杂性又难到那里去？

小公司，如果没有很雄厚的资本，真的很难做到强势。再说，做到强势又能怎样？强势能够拉拢人心吗？我最关注员工内心是否对上级、对团队、对公司喜欢、信任、有信心。有了这个基础，其它的就好推进了，这是一个阶段和层次问题。

可以换个角度，没有员工会无缘无故的对团队，对公司喜欢，也没有员工对公司会一直信任，有信心下去。

目前的情况是，实力强的，不仅会有点性格，而且有自己的追求；员工给你干活，绝对不是为了张扬个性，关键是公司能否满足他们的追求；而且重要的一点，实力强的去小公司为了什么？凭什么选择你？

小公司，活下去容易，但要做大，就不要指望一个人的超强；把责任，压力，利益都拿出来与核心人员分摊。

一个好汉三个帮，谁拉关系，谁来做，项目做完谁来搽屁股；做项目的时候，谁业务能力强，谁干活猛，谁做事稳；

个人觉得，这些谁谁谁，都是关键人物，都应该拉出来分摊责任，压力，利益。

你是老大没错，但是还要定位好自己，不能拉关系，找不到项目和资金来源，那就得退居二位，让有路子的人上位，咱给他干，等攒够了钱，再建一个堂口罢了

57 楼 aroundall 2010-04-21  

楼主说的几点确实有道理，深有体会。小公司很多时候就是在跟死神赛跑，曾经由于自己很多不成熟的决定，差点致公司于绝境。由一个开发人员转为技术管理型人员是一个艰难、痛苦而且寂寞的过程。
虽然最近离开了创业团队，但是一直在思考这两年。

56 楼 zwchen 2010-04-21  

一蓑烟雨任平生 写道

流程和规范跟公司大小没有关系，我没有见过什么高手敢抵触公司的条例，既然进公司就要遵守公司的制度，这是职业操守，拿不住他不就是因为没钱找人替换他么？拿不住以后出事问题更大。因为没钱所以找低成本的人，指望通过项目能把人培养出来，这个想法很不现实。有潜质的人做的好很快就走，留下来的该怎样还怎样。

还真的有关系，小公司招人不容易，能力强点的，看到小公司都不投。我们招聘条件上明确了薪水，还是有竞争力的。

另外，人的替换成本很高，如果就三个人开发代码，走了一个，那么进度就可能延期一个月。

技术好的，一般会有些性格，让其做的开心，往往其责任感会强很多，效率也会高很多。再说，几个人开发的项目，复杂性又难到那里去？

小公司，如果没有很雄厚的资本，真的很难做到强势。再说，做到强势又能怎样？强势能够拉拢人心吗？我最关注员工内心是否对上级、对团队、对公司喜欢、信任、有信心。有了这个基础，其它的就好推进了，这是一个阶段和层次问题。

55 楼 topcode 2010-04-21  

因地制宜
量体裁衣

54 楼 tomxh001 2010-04-21  

挺好，集思广益，大家都发表自己意见，学到了不少东西

53 楼 一蓑烟雨任平生 2010-04-21  

成本和品质是个平衡体，小公司是要考虑成本，但是也要考虑因为成本低导致无法聘到高水平的人员，还有人员流动。感情的笼络代替不了公司运营的收益。

在没有一个明确的业务目标的前提下，组建一个软件公司，无法预计在人员培养、技术管理等方面的投入所带来的收益，单纯依靠项目来养开发团队是非常辛苦的。技术负责人首先要对这个有认识，跟老板有沟通，投入多少回报多少，要给技术这块争取最大的利益。

大公司之所以会重视流程和管理，是因为这些东西一来有稳定的业务支撑，投入大但是不缺钱，二来是抗风险，公司最大的风险是人，业务是稳定的，所以要把人视作可替换的资源，规范细致的流程和文档同时也是做给客户看的，让客户也觉得没有风险，这样保证业务的稳定，这些投入有客户买单，业务稳定带来的收益不愁找不到人。

流程和规范跟公司大小没有关系，我没有见过什么高手敢抵触公司的条例，既然进公司就要遵守公司的制度，这是职业操守，拿不住他不就是因为没钱找人替换他么？拿不住以后出事问题更大。因为没钱所以找低成本的人，指望通过项目能把人培养出来，这个想法很不现实。有潜质的人做的好很快就走，留下来的该怎样还怎样。

小公司同样可以有好的流程，但是前提是要有明白人，就你一个人明白没有用，具体要落实下来得要有能力强的人去做，而要找到能力强的人，就是要靠公司的业务发展来支撑，说白了还是有钱才有人、有人就有钱。

52 楼 dmhorse 2010-04-21  

非常感谢你的分享,而且还是管理上的分享,非常难得. 同时,在实践中,我非常认可你对CMMI的看法,和因时因地利而采取的策略,换我来做,我会采取相近的方法.

从风格上,我觉得你不像一个商人.能说说创业的过程吗?

现在IT业已经是一个竞争非常激烈的行业,你公司的方向是什么?

51 楼 抛出异常的爱 2010-04-21  

zwchen 写道

抛出异常的爱 写道

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.

别急下结论
试试看看效果

反正我只作过一回EJB
但junit-TEST这个毛病算是落下了

设计？一次设计好很难
真的很难
我不知道你会不会在设计之前REVIEW几次设计
我一般只RE一次
我的设计在写代码之前会有个方案

在coding时这个方案多多少少会改进。
有时是异常没考虑到
有时是数据太理想化
写到哪里会对哪里认识更深刻
再去改设计？
再去REVIEW以前的代码？

加个CASE就全搞掂
我不是咨询行业的
不靠新名词吃饭
每个我使用的方案
都是实践过的

想想你们开发时遇到没遇到过这些状况就能明白

50 楼 zwchen 2010-04-20  

告诫各位处于开发第一线的朋友，千万不要受本文的误导，把规范和设计文档不当回事。

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

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

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

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

49 楼 zwchen 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.

48 楼 抛出异常的爱 2010-04-20  

repsihWDX 写道

关键是让你的队员理解他们做什么，并觉得有意思。

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

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

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

47 楼 repsihWDX 2010-04-20  

关键是让你的队员理解他们做什么，并觉得有意思。

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

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

46 楼 mis98zb 2010-04-20  

嗯，讲的很好。。。

45 楼 zwchen 2010-04-20  

抛出异常的爱 写道

EldonReturn 写道

抛出异常的爱 写道

zwchen 写道

我补充两点吧：
1、文档 我们最重原型，也许因为我们是旅游电子商务网站，与业务员、设计师、开发人员沟通都是它（看附件）。
2、利益 管理的本质就是管理利益，只是没必要挂到嘴边，每个人的利益追求都不一样，薪水只是一种利益。团队成员是否开心，会有一种自然的流露。比如，我从不限制我们团队上网，只是告诉他们，要是有很想下载的大片，建议限速到100k。我们团队始终是自觉在上班时间将QQ隐藏或是不开，多数时候还是我提醒开一下QQ。我从未看到有人专门去浏览娱乐资讯，有时我可能会发一些好文给他们。我也会告诉他们，要是哪天晚上没睡好，就迟些来，因为状态不好和怠工没啥差别，对自己和公司都不好。比如今天中午大楼停电，我告诉他们：等电来，还是现在回家，你们自己决定吧，我走了。因为我要去公司业务部门沟通。

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

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

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

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

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

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

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

如果换一个项目，我们可能会很看重架构图和数据库ER图。

44 楼 抛出异常的爱 2010-04-20  

EldonReturn 写道

抛出异常的爱 写道

zwchen 写道

我补充两点吧：
1、文档 我们最重原型，也许因为我们是旅游电子商务网站，与业务员、设计师、开发人员沟通都是它（看附件）。
2、利益 管理的本质就是管理利益，只是没必要挂到嘴边，每个人的利益追求都不一样，薪水只是一种利益。团队成员是否开心，会有一种自然的流露。比如，我从不限制我们团队上网，只是告诉他们，要是有很想下载的大片，建议限速到100k。我们团队始终是自觉在上班时间将QQ隐藏或是不开，多数时候还是我提醒开一下QQ。我从未看到有人专门去浏览娱乐资讯，有时我可能会发一些好文给他们。我也会告诉他们，要是哪天晚上没睡好，就迟些来，因为状态不好和怠工没啥差别，对自己和公司都不好。比如今天中午大楼停电，我告诉他们：等电来，还是现在回家，你们自己决定吧，我走了。因为我要去公司业务部门沟通。

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

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

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

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

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