文章转载自：http://www.javaeye.com/topic/646406
说得功利点吧，一个人的财富和其影响力是成正比的。影响力本质上就是对他人的价值。比如，郎_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，代码没有缩进。过几年非常难改。而好的编程习惯，可以提升开发效率，还能让自己思维清晰。
学技术阶段，一定要注意代码的可维护性、健壮性及灵活性，只有养成对代码精益求精的态度，你才可能成为技术高手。技术学好，做技术管理就有了基础，而且别人也会服你。
我的看法：
1、文档的多少和深度决定于项目环境。
如果是大项目，比如二三十开发人员，架构文档、需求文档、代码规范等都是必须，否则开发人员不能迅速了解项目技术和业务特点，从而无法快速开发，也即是规范可以降低培训成本和团队沟通；另外，项目开发中后期可能根本不可控，谁都看不懂其它人的代码。部署时看到的一些bug无法及时修复，因为到处都有地雷。我以前经历过这样的项目，最后加班都没用。
如果是产品型，规范更重要。当然我说的产品可能是2.0版以后，因为这时候的产品基本得到了市场的认可。而在初版时，代码写得烂都没关系，因为你不不知道用户会不会买单，也不知道能否按进度开发完成。而在后续版本，如果没有规范文档，维护的成本都不亚于重新开发。特别是处于一线的开发人员会怨声载道：为什么要我来收拾残局？那么，这样的士气，开发效率怎么会高，项目质量怎么会高？
2、成熟型大公司那套做事流程，可能高手受不了，但可能是最优的方案。因为，到项目后期维护，往往只是一些业务功能的删减改进，不需要技术高手，这个过程可能漫漫几年，项目维护成本会非常高，雇佣高手一来他不愿意干二来也不需要这种人，如果项目代码还维持在一种“秩序”，初中级开发人员就可以胜任，有什么不好呢？
项目上线时，是为了追求利润。项目维护期，是为了省成本。
3、刚入道的朋友，最好是按规范来，就像学武术，先要学套路。否则，养成的编程坏习惯，比如文件名叫Aaa1.java，代码没有缩进。过几年非常难改。而好的编程习惯，可以提升开发效率，还能让自己思维清晰。
学技术阶段，一定要注意代码的可维护性、健壮性及灵活性，只有养成对代码精益求精的态度，你才可能成为技术高手。技术学好，做技术管理就有了基础，而且别人也会服你。
