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

   工作五年，一晃已年过三十了。读研时，独立做项目，毕业头三年，主要在大公司工作，后来，也就是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，代码没有缩进。过几年非常难改。而好的编程习惯，可以提升开发效率，还能让自己思维清晰。
   学技术阶段，一定要注意代码的可维护性、健壮性及灵活性，只有养成对代码精益求精的态度，你才可能成为技术高手。技术学好，做技术管理就有了基础，而且别人也会服你。

评论

43 楼 betafox 2010-04-20  

楼主总结的很好，立意也很广，不仅仅是说项目管理的问题，看了很有同感。有些回复有点狭隘了

42 楼 EldonReturn 2010-04-20  

抛出异常的爱 写道

zwchen 写道

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

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

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

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

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

41 楼 yg84 2010-04-20  

不能把书本上写的，硬往项目里搬。否则得不偿失，应该灵活应用，也可按大家的较为效率高的习惯和方法去解决问题。最终目的就是按时，按质的完成项目。而不是一堆形式主义。。

40 楼 rubys 2010-04-20  

zwchen 写道

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

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

我从这里面能感觉出“无为”的思想，真希望以后会有你这样的成就，嘿嘿

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

zwchen 写道

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

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

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

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

38 楼 boyyaocheng 2010-04-20  

很赞同LZ的观点,尊重下属,培养他们的独立解决问题的能力,而不是强硬的要求;我也是和同事一起创业,也很注重员工的培养,薪水的东西基本上也是尽力满足他们,从不砍价;
我觉得一个公司真的要长久的发展,一年给员工加个1000的工资也没有什么,十年也就1万,能在公司待十年的,说明公司在管理方面也是成功的; 我的关键点在于员工的能力是否能给公司创造更大的价值;如果每个员工都因为薪资的问题而带着情绪工作,那到最后很真的得不偿失;

37 楼 zwchen 2010-04-20  

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

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

36 楼 askyuan 2010-04-20  

楼主要知道一个问题：现在的社会是讲究现实的社会，不要说什么工作开心不开心有没有前景。。。。有句话说：“没有永远的朋友，也没有永远的敌人。只有永远的利益”我觉得，待人也好，带人也罢，千万不要亏待别人，谁也不是傻子，激烈的社会竞争，如果我们年轻人都像你想的那样都去和你一起打拼，那我们的保险何在？一个人的价值有多少，你就应该给他多少。。。这样再来待人，我觉得这样成功的几率会更大，因为每个人心里都有一本账

35 楼 jili 2010-04-20  

smalllixin 写道

感触颇多~
我原来也是在管理非常规范的公司呆着的，后来来到北京来到一个创业的小公司发现很多东西都不灵了，小公司需要的是很强的执行力，需要快速的做出成果，所谓的流程、文档等等其他东西往往不是最重要的。

拿文档来说，你知道文档的目的是什么吗？大多数情况下文档是分析、沟通和取得共识承诺的载体。什么情况下可以省略文档呢？
1、项目复杂度够小，需求和设计都可以在脑海中思考清楚（也就是生命周期不超过一个迭代的项目复杂度，否则，没有文档你自己都没办法把问题考虑清楚）；
2、需求、设计、开发、测试等各方沟通非常紧密顺畅，不会出现误差（比如敏捷中对团队物理条件和客户参与的要求）；
3、在沟通不会有误差的前提下，大家没有利益差别，互相信任（比如内部项目，除了问题，投资方不会责怪追究你）；
4、在过程中通过不断确认来保证方向（持续集成，快速交付，否则交付时间稍微长一点，你自己都记不住当初的要求了）。

如果你的团队或项目环境（有时候后者是主要矛盾）没办法做到以上几点，那么所谓抛弃流程和文档，只是缺乏控制能力和偷懒的借口。成果必然不佳。

流程同理。

34 楼 jili 2010-04-20  

关于开发规范：
问题不在于具体某个规范，而在于一个开发团队必须有统一的规范。比如楼主说的jsp和ssh问题。如果一个团队中，有人jsp有人ssh，那就杯具了。从过程改进的角度来说，这个规范不应该是一个人拍脑袋定下来然后强推给大家，而应该是一个团队（至少是核心骨干）在合作过程中形成的默契和共识。当然，这个过程可能是由某个人牵头来做的。
关于制度：同上。

至于沟通和信任，我想，在上面的前提下，这个不再是问题。


我有这样的感悟。当一个研发团队超过5个人时，必然会出现核心成员和非核心成员。不管多么大的团队，核心成员可能只有3、4个，包括了各个方面。核心成员必须专注于自己的领域，利益一致，互相有共识和默契，互相开放，互相认同。至于具体的方式方法，我认为一个健康的团队，即使要经历弯路，但是会自己成长改进,找到最适合自己的方法。

这样的核心团队的要求其实是挺高的，现实中，招聘是很难得到这种团队的。如果你的核心团队人不具备这样的素质，ok，那么你要做的是，认清楚团队能力的上限，不安排给其超越上限的任务。一般来说，搞搞企业应用这种劳苦命项目是没问题的(这也是大多数公司的现状)。但是，如果要创业，要成功，那么，就我的经验来看，大多会是杯具。
从更高层的管理角度来说，找到这样的团队成员，给他们必要的条件和资源，帮他们排除干扰，他们自然会达到最好的结果。如果你自己想成为核心成员，那么，你要自问是否达到了以上要求。


软件发展到今天，虽然有很多方法论互相pk互相争论，但是大部分还是有主流认知的。比如过程，比如设计思想，比如技术框架。但这些方法论都是有适应场景和前提条件，有不同的具体实践方式。大多数人学习这些方法论，都只是看到手段，而不知道背后隐藏的条件和思想。比如前面说的jsp和ssh，都有各自优缺点，各自适应的场景，没有绝对的优劣。所以，真正合格的人才凝聚成的团队，在信息平等的情况下，对于这些问题是很容易达成共识的。坚持主流认知之外的人，大多数要么是视野狭隘，要么是人品有问题。当然，很小概率下，也有可能是理念超前的天才。

33 楼 fengsky491 2010-04-20  

楼主 写道

你能够拿幼儿园那种教育方法来教育成年人吗？

32 楼 Aaronic 2010-04-20  

很棒的经验，收藏了

31 楼 smalllixin 2010-04-20  

感触颇多~
我原来也是在管理非常规范的公司呆着的，后来来到北京来到一个创业的小公司发现很多东西都不灵了，小公司需要的是很强的执行力，需要快速的做出成果，所谓的流程、文档等等其他东西往往不是最重要的。

30 楼 ajonjun 2010-04-20  

确实不错,大公司所有东西太流程化了,没有意思..

29 楼 duker 2010-04-19  

这篇文章实际经验之谈,值得拜读.

28 楼 fanfq 2010-04-19  

kunee 写道

大公司靠制度，小公司靠人情

大公司做人，小公司做事。

27 楼 zwchen 2010-04-19  

rikeinei 写道

zwchen 写道

针对上面帖友的回复，我补充几点吧：
1、代码可维护性  在我创业创业前的五六年，非常重视代码的可维护性和规范，可以说我写的代码非常漂亮、很易读。但现在，我们团队有一位技术高手，性格有些偏执。我提醒并纠正过多次，几乎很难改他若干年养成的习惯(比如不用log而用System.out,不用testCase而用main，想想这些对开发速度的提升也不过百分之几)，主要是他不想改，而且还打击他的热情。后来我想，我们项目要是尽快上线就不容易了，代码让我全部重写难度也不大。在代码可维护性和个人做事愉快两个方面，我最终选择了后者。商业成功永远是基础。另外，你不知道你写的漂亮代码，最后投入市场，在客人眼里，是否就是一堆垃圾。开发人员认可的质量，不等于用户认可的质量。

2、管理的境界 很赞同rrsy23的看法，最高的境界就是团队每个人的自我管理。我目前已经在实施了，效果还不错。以前五个人以我为中心，对我负责；现在是六个人形成网状，我只是一个节点，比如开发人员要修改界面，不用找我，直接找设计师，当然我会在功能测试上把关。他们的关注点是项目目标，而不是我。可能是因为我还要和几位业务人员密切沟通，这算是在沟通压力下的一个创新。

3、领导 确实，在小公司还是靠领导者的人品和魅力。我也是技术出身，我不会让我几年经历中对公司或领导不爽的地方带到目前的团队，比如加班、催促。目前我坚持的原则是尊重和信任，时刻反省自己的行为是否违背了它。我自认为大家还是很认可我的人品，虽然我不善表达。

4、敏捷 每日晨会、工作日志，这些东西用起来还是看环境，除非大家都认同，并且工作类型、开发者能力差不多。其实它们本质是解决沟通和风险控制。在沟通频率，比如一天、两天、随时；沟通渠道，比如周会、邮件、当面等选择上，我更关注效率和效能，而以沟通方式为辅。

对于1，关于代码的可维护性，这个是由维护代码的人评定的。如果可以预先安排谁维护，那么就不妨让他定规范，哪怕是写main,ss是写system.out。如果不知道将来谁来维护，再好的代码也没有耐心看下去，还是保留一份及时更新的设计书来地实在点。

对于3，靠人品和魅力管人？我也是技术出身，我觉得以前经过的公司和领导让我不爽的地方，是值得我反思，借鉴的。让下属不爽并不一定是坏事，一个坚强的人会在不爽中迅速成长。

什么都是成本，而考虑成本投入的唯一依据，就是收益。
规范是成本，设计文档时成本，改变开发人员的习惯是成本，代码维护性也是成本。
收益有短期和长期，如果短期收益都得不到，都快死掉，是否应该考虑长期收益？这是小公司面临的尖锐问题。

26 楼 rikeinei 2010-04-19  

zwchen 写道

针对上面帖友的回复，我补充几点吧：
1、代码可维护性  在我创业创业前的五六年，非常重视代码的可维护性和规范，可以说我写的代码非常漂亮、很易读。但现在，我们团队有一位技术高手，性格有些偏执。我提醒并纠正过多次，几乎很难改他若干年养成的习惯(比如不用log而用System.out,不用testCase而用main，想想这些对开发速度的提升也不过百分之几)，主要是他不想改，而且还打击他的热情。后来我想，我们项目要是尽快上线就不容易了，代码让我全部重写难度也不大。在代码可维护性和个人做事愉快两个方面，我最终选择了后者。商业成功永远是基础。另外，你不知道你写的漂亮代码，最后投入市场，在客人眼里，是否就是一堆垃圾。开发人员认可的质量，不等于用户认可的质量。

2、管理的境界 很赞同rrsy23的看法，最高的境界就是团队每个人的自我管理。我目前已经在实施了，效果还不错。以前五个人以我为中心，对我负责；现在是六个人形成网状，我只是一个节点，比如开发人员要修改界面，不用找我，直接找设计师，当然我会在功能测试上把关。他们的关注点是项目目标，而不是我。可能是因为我还要和几位业务人员密切沟通，这算是在沟通压力下的一个创新。

3、领导 确实，在小公司还是靠领导者的人品和魅力。我也是技术出身，我不会让我几年经历中对公司或领导不爽的地方带到目前的团队，比如加班、催促。目前我坚持的原则是尊重和信任，时刻反省自己的行为是否违背了它。我自认为大家还是很认可我的人品，虽然我不善表达。

4、敏捷 每日晨会、工作日志，这些东西用起来还是看环境，除非大家都认同，并且工作类型、开发者能力差不多。其实它们本质是解决沟通和风险控制。在沟通频率，比如一天、两天、随时；沟通渠道，比如周会、邮件、当面等选择上，我更关注效率和效能，而以沟通方式为辅。

对于1，关于代码的可维护性，这个是由维护代码的人评定的。如果可以预先安排谁维护，那么就不妨让他定规范，哪怕是写main,ss是写system.out。如果不知道将来谁来维护，再好的代码也没有耐心看下去，还是保留一份及时更新的设计书来地实在点。

对于3，靠人品和魅力管人？我也是技术出身，我觉得以前经过的公司和领导让我不爽的地方，是值得我反思，借鉴的。让下属不爽并不一定是坏事，一个坚强的人会在不爽中迅速成长。

25 楼 poson 2010-04-19  

很不错啊！

24 楼 kunee 2010-04-19  

大公司靠制度，小公司靠人情