这是2年前写的，曾在v2ex上发过，今天翻到，重新在blog上贴一下。
虽然目前的想法有写差异，但也不再修改了，毕竟是那时候思考的结果。

入职创业公司一年半时间，做了开发和技术经理(3个月开始接手)两个岗位。离职半个月，早起突然有些想写点什么的冲动，整理下思路，将自己遇到的一些问题和想法总结下。因为我是技术人员，所以下面主要总结下技术相关，具体想到哪就写哪吧。

技术问题

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. 有没有产品方向的背景或积累，如果创始人、开发团队、运营啥的都没有想过经验，可能这是个全新的领域？否则人家的常识变成你的地雷，这样竞争还是有难度。

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

其实就是：聚焦 --- 聚焦在做事本身上
我们总是不经意间会忘记了解决这个事情本身，虽然说抬头看路也很重要，但是如果创业公司连基本走路都没做不好，何谈超越？而经常我们只看到远处的幻景，而忘记了脚下的泥泞。
创业者的幻景是未来的上市、财富、巨大的成功？技术的幻景是技术领域的大拿，创造的快感，自我能力的陶醉？
踩好脚下第一步吧，也许像小孩先爬好第一步才是根本。