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

不管公司大小，首先要抓住的是明白要做什么的人，项目或者产品都是这个道理，我是业务优先论者，知道要做什么，怎么做就不是什么难事。所以做技术负责人，也要有这方面的认识，开发的细节和流程在创业阶段，优先级放在后面。

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

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

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

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

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

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

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