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

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

评论

103 楼 mingjian01 2010-08-05  

个人很赞同LZ的观点，让员工做得开心和让员工对公司做的东西有认同感才是小公司最重要的关注点，但是同时这也是最难的，不知道LZ的公司招不招人，过去做，哈哈~

102 楼 zwchen 2010-08-04  

吐故纳新 写道

赞一个，楼主确实写的很不错。 我想请教三个问题：
项目管理 与 过程管理；前者关注目标与进度；成本与收益； 后者关注流程与方法；
那一名项目经理，他应该关注哪个方面呢？ 是项目管理与过程管理，还是仅仅项目管理？

另外，你提到WBS分解，分三层。第一层，领导关注；第二层，项目经理关注；第三层，开发人员关注。
那这个分三层的，详细的WBS任务分解，是项目经理来做吗？

您提到由于创业，行业业务不熟悉，工作进度难以估计。
你们现在是如何解决这个问题的，如何更好的来估计任务所需工作量、工作时间。如何制定出一个合理可行的计划。

不好意思，现在才静下心来回复：
1、在大公司，项目管理和过程管理一般会分开，偏运营和产品的企业，可能是产品经理+项目经理。这没有定论，看项目环境了。
在大公司，项目经理PM对外，主要是负责需求和客户沟通等；TL对内，负责过程管理，它甚至是架构师承担。问题不是由谁来做，而是谁更有经验和精力。也可能三角色由一人承担。

2、WBS分解，主要是项目的真正负责人，也就是那个和团队成员每天混在一起的，主要是TL，当然，PM和Architect肯定会参与，只不过他是起草者。

3、进度评估，对于不熟悉的行业和业务，最重要的原则：
A、和精通业务的人沟通，知道每个功能点的轻重和缓急。该砍的砍，该靠后的靠后。
B、和团队成员沟通，问他们对进度的看法，经常调整，一般进度不会离谱。最忌讳下命令，然后成员无条件执行。当然，最核心的前提是，建立信任、开放的团队文化。

如果以前没啥项目管理和过程管理的意识，切忌看大量相关书籍，然后照搬，这样会死得更惨。项目管理更多要经验，而过程管理，如RUP，真正了解其精髓，还能够量体裁衣，要好几年的项目体会，它无法像纯技术那样看几本书就可以写代码实现，因为管理是一种实践活动，就如同游泳，无法通过书本学会。

管理类书籍前期只需略读，在有一定项目经验和项目管理意识后，才开始深入阅读和学以致用。
任何管理方法都有其适用场景，也就是前提，一开始就照搬，往往会过分关注书中的方法，而忽视了环境/场景，就如在沙漠上种蘑菇，无论怎样施肥都没用。而你不看书，你可能会特别关注环境，方法自己摸索，这样成功概率更大。

101 楼 吐故纳新 2010-08-02  

zwchen 写道

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

赞一个，楼主确实写的很不错。 我想请教三个问题：
项目管理 与 过程管理；前者关注目标与进度；成本与收益； 后者关注流程与方法；
那一名项目经理，他应该关注哪个方面呢？ 是项目管理与过程管理，还是仅仅项目管理？


另外，你提到WBS分解，分三层。第一层，领导关注；第二层，项目经理关注；第三层，开发人员关注。
那这个分三层的，详细的WBS任务分解，是项目经理来做吗？


您提到由于创业，行业业务不熟悉，工作进度难以估计。
你们现在是如何解决这个问题的，如何更好的来估计任务所需工作量、工作时间。如何制定出一个合理可行的计划。

100 楼 aitracy 2010-07-13  

以人管人
制度管人
制度+人性化管理

99 楼 ximencf 2010-07-13  

不是每个人都对周围的人戒备。戒备往往是因为觉得自己不够安全。

不是每个人都把员工看成和股票一样的升值工具，而不是合作伙伴。也许放肚子里更好些，但这样我可以接受监督、自我约束。

不是每个人都坚持不了自己的价值观。是否坚持的根本原因，是你能多大程度忍受因坚持带来的损失，比如当前的高收入工作，急功近利所得到的回报。



顶这句话。

98 楼 ouyangmeile 2010-05-11  

偶然看到楼主的文章写得非常好，醍醐灌顶，幡然醒悟。嘿嘿

97 楼 zwchen 2010-05-11  

小公司和大公司可以比较，但如果说哪个好，就没有意义了。

每个小公司，都渴望有一天变成大公司。

小公司的管理模式，随着公司的扩大，会越来越不适应，于是就出现了管理模式的变化，而这种变化的原则，就是效率。当然，变化不代表进化，于是大公司病就出来了。

96 楼 java_will 2010-05-11  

小公司更注意员工的想法，大公司则更容易忽略员工的想法
小公司的规范和制度都是灵活的，大公司则相对稳定

95 楼 我会好好的 2010-05-10  

恩  小团队的管理是靠管理者的魅力来制胜的！

94 楼 富人村的门岗 2010-05-09  

我最近读了一篇文章，大意是：用哲学的观点来开发你的项目。你看如何？

93 楼 zwchen 2010-05-07  

抛出异常的爱 写道

这话放肚子里吧
说出来。。。。。
有点像你看的书一样了。

不是每个人都对周围的人戒备。戒备往往是因为觉得自己不够安全。

不是每个人都把员工看成和股票一样的升值工具，而不是合作伙伴。也许放肚子里更好些，但这样我可以接受监督、自我约束。

不是每个人都坚持不了自己的价值观。是否坚持的根本原因，是你能多大程度忍受因坚持带来的损失，比如当前的高收入工作，急功近利所得到的回报。

92 楼 zwchen 2010-05-07  

一蓑烟雨任平生 写道

“我们没地方住(买不起房)”
不会连LZ你都买不起房吧？

实话说，还没买。去年公司做亏了，这两年把以前挣的钱都花了，没啥收入。07年全部资金投入股市，亏得一塌糊涂。

当然了，我没钱不代表家庭买不起房。

91 楼 qn_lf 2010-05-07  

太经典了 收藏

90 楼 一蓑烟雨任平生 2010-05-06  

“我们没地方住(买不起房)”
不会连LZ你都买不起房吧？

89 楼 抛出异常的爱 2010-05-06  

这话放肚子里吧
说出来。。。。。
有点像你看的书一样了。

以下是我真实的想法。

引用

您好 xxx 9 小时前
一直看到您帮人解决了很多问题，我在此冒昧的向您请教个问题，记得看到过一个您的回复，说你公司培养了的员工跳了，如果工资翻一番，你是不是很痛恨这样？
回复 转发 收藏 删除
Re: 您好 抛出异常的爱 8 小时前
我以前只培养新员工技术
之后就让他们干些无聊的杂活。。。
所以他们会去找其它的工作

现在会多加一些能让工作有乐趣的事
你知道为了工资翻翻这种事跳槽是拦不住的。
但是干的开心有人会没事找活干么？
不找活工资翻翻的工作机会就少了很多。

88 楼 王者之剑 2010-05-06  

zwchen 写道

不管别人怎么看我，我会走出一条和一般人不同的路，以自己的直觉和理解去善待这个世界，特别是和我一起工作的人：工作的开心是我最大的追求。

下面是我上次给部门新同事的欢迎信，我只想说一句话：我是真诚的：

引用

今天开始，我们IT团队正式加入了一位新成员：设计师xxx。
从组织结构上，我们团队已经很完备。公司虽然小，但我们每个人都很专，这样，大家可以专注于自己的兴趣，深度发展，而不是打杂。工作本来就应该是一件很开心的事情，创造性会带给人极大的成就快感。

我们提倡尊重、信任、自由、共享的团队文化，特别是后两者：自由和共享，我认为自己做得还不够，我会继续努力的。

我还是固执地认为，曾经，窒息的应试教育和野蛮的公司文化，让学习和工作，本应该很开心的事情，变成了一种无奈的选择。
生活应该是阳光的，在这儿，我们来一起打造这种阳光文化，因为工作就是生活。

我很欣赏罗永浩这个人，因为他坚持自我，率真，因为追求公平和正义而对这个世界怀有一种罕见的善意和温柔。大家可以看看他的演讲：http://v.youku.com/v_show/id_XMTY5NTc2MzMy.html 。

在这个越来越恶劣的社会，我们没地方住(买不起房)，也没地方说(政府言论封锁)，但我们不应该妥协，因为妥协会埋没我们的潜能，潜能是我们最大的一块宝藏。至少，在xxxx这个地方，我会和大家一起，去开发这块宝藏。

87 楼 zwchen 2010-05-06  

不管别人怎么看我，我会走出一条和一般人不同的路，以自己的直觉和理解去善待这个世界，特别是和我一起工作的人：工作的开心是我最大的追求。

下面是我上次给部门新同事的欢迎信，我只想说一句话：我是真诚的：

引用

今天开始，我们IT团队正式加入了一位新成员：设计师xxx。
从组织结构上，我们团队已经很完备。公司虽然小，但我们每个人都很专，这样，大家可以专注于自己的兴趣，深度发展，而不是打杂。工作本来就应该是一件很开心的事情，创造性会带给人极大的成就快感。

我们提倡尊重、信任、自由、共享的团队文化，特别是后两者：自由和共享，我认为自己做得还不够，我会继续努力的。

我还是固执地认为，曾经，窒息的应试教育和野蛮的公司文化，让学习和工作，本应该很开心的事情，变成了一种无奈的选择。
生活应该是阳光的，在这儿，我们来一起打造这种阳光文化，因为工作就是生活。

我很欣赏罗永浩这个人，因为他坚持自我，率真，因为追求公平和正义而对这个世界怀有一种罕见的善意和温柔。大家可以看看他的演讲：http://v.youku.com/v_show/id_XMTY5NTc2MzMy.html 。

在这个越来越恶劣的社会，我们没地方住(买不起房)，也没地方说(政_府言论封锁)，但我们不应该妥协，因为妥协会埋没我们的潜能，潜能是我们最大的一块宝藏。至少，在xxxx这个地方，我会和大家一起，去开发这块宝藏。

86 楼 danielli007 2010-05-06  

看得出来，楼主在管理上还是以人为本。赞同这样的做法！提到的很多管理方式方法，值得去学习。。

85 楼 solomon2133 2010-05-05  

楼主太强悍了...学习下

84 楼 Ben.Sin 2010-05-05  

好文，我也对目前公司的考核制度以及编码规范和习惯有些看法。或者我应该跳出来作为一个旁观者考虑一下。