创业公司之教训

入职创业公司一年半时间，做了开发和技术经理两个岗位。离职半个月，今天起来突然有些想写点什么的冲动，整理下思路，将自己遇到的一些问题和想法简单总结下。因为我是技术人员，所以下面主要总结下技术相关，具体想到哪就写哪吧，没有很好的整理，欢迎吐槽。

技术问题

1. 语言、框架应尽量选择开发团队比较熟悉的，至少也应该很容易学习的，基于团队整体能力

   开始团队里有个牛人，很喜欢使用一些比较新的框架和解决方案。虽然我个人很欣赏，但是其他开发人员跟不上他，而且其并不喜欢辅导他人。导致其开发的部分模块无人接手，后来他走了之后，其他人员只能重新开发。 后面我接手团队之后，做了几个限制。语言只能在我们团队已经大量使用的中选择了(Python 和 Java)；框架尽量使用当前使用的，新框架必须确实有需要，同时不能有太陡的学习曲线。

2. 尽量使用成熟的开源方案，在此基础上做少量定制开发

   因为需要做分布式任务调度，团队花费了大量人力(那段时间 50%以上人力)重头定制了一个分布式任务调度，当时我还是开发，虽然个人表示反对，但是无效。后来这个调度问题不断，稳定性、可维护性、扩展能力等各方面问题不断。最后我选择了一个开源方案，又花费了个把月进行迁移，此后一直稳定，偶有问题，也大部分是使用配置问题，很快解决。

3. 建立完善的开发流程和工具链，形成团队开发风格

   虽然技术人员大多不喜欢什么流程，但是流程依然很重要。当然这里指的广义上的流程，包括开发过程、进度、发布、运维等都在内。创业团队应该尽量使用自动化的工具，比如每日集成、发布，提示日常效率。坦白讲，这块我没做好，虽然建立了一些，但并没能形成端到端的流程建设和工具使用。部分团队人员个人风格强烈也是一部分原因，但主要是我自己没能做好，使团队的风格能逐步融合并稳定。

4. 做完善的分析不如做个简单的 Demo

   基本的产品方案调研、需求分析还是需要的，但是：

   1. 团队人员有限 2)技术团队交流面对 Demo 比文字明显要顺畅的多 3) Demo 更容易发现坑 4 ）一些 Demo 很容易向产品转化

总体而言，技术方面的目标：尽快的把事情做成并稳定可"复制"。因此我们需要控制技术和造轮子的冲动，创业团队人少、钱更少，但是时间是最少的，有限的时间内，能做更多的事情才是重点。又快、又省、又好的事情是没有的，但是在当前的技术生态体系下，又快、又省、又"足够好"，还是可行的。

方向问题

技术团队是个执行者，不负责也无法决定产品和方向问题。技术是有风险的，很多决策者或者创业人员只看到了未来广阔的发展，总是要做各种产品，这时候我们需要将风险提出来，主要是什么？

1. 时间、人力, 根本就是钱

   大部分时候，做一个 Demo 和正式的产品之间花费的时间和人力都有天壤之别(除非这个产品就是 "Hello, World!")。 对开发而言而言，就像代码里 70%以上是处理各种层面异常一样。产品需要开发、测试、发布、维护; 需要实现比 Demo 多的多的"无用的"需求; 同时新产品又很容易对现有产品造成挤压，人员的效率进一步下降。

   这个问题扩展开来讲可能可以写本书，这里只是提醒技术团队们要学会说不， CEO 们要会学会算技术方面的账。

2. 产品本身

   但是任何产品都应该有其自身的逻辑，不展开，但是有几个教训：

   1. 是否和现有产品有关系，如果和现有产品完全不搭界，那等于又开创一片新天地，是不是考虑重新开个公司？
   2. 技术方面是否能使用现有的用户、数据、平台、代码等，如果还是没啥关系，可以考虑重新开个公司？
   3. 有没有产品方向的背景或积累，如果创始人、开发团队、运营啥的都没有想过经验，可能这是个全新的领域？否则人家的常识变成你的地雷，这样竞争还是有难度。

总之产品是需要花费大量的时间、人力和知识等成本的(云时代的好处是基础设施成本很大程度上只需要用钱就行)，并不是拍脑袋然后"就缺一个程序员"能搞定的。