“我有一个改变世界的IDEA，就等你来写代码了，不谈钱，给你股份！”

“我已经谈好机构愿意投资我了，就差app跑数据了，你照那谁抄一个就行！”

“在新页面上加两个按钮，很简单的，今天能搞定吧？”

“我有了个新想法，绝对颠覆传统商业模式，咱试试呗！”

“刚听朋友说了，咱的APP用XXXX框架就行，你那套不行了！”

“这五版都不好，还是改回第一版吧！”

……

程序员不易，CTO更苦，那些摆在技术面前的坑，正在变着花样的汹涌而来，总有一款适合你。

“新需求”相信已经成为技术研发不得不面对的十宗罪之首了。

改完bug新需求来了，新需求做完发现了bug……无限循环，相信这是很多程序员的现状。没有准时下班，没有双休，如果捎带手做了运维，那就是7*24小时的命，所以，别总说我们没有妹子了。

在创业环境下的用户需求是多变的，尤其是一个全新的产品、服务。需求的验证和迭代过程，在一个有计划、头脑清晰的CEO手中是可以快速推进的，但在一个完全不懂技术、听风就是雨的CEO面前，那就是一场噩梦了。

他们还总是用代码提交的数量作为评价工作量的标准，要知道，有时候一个关键问题的解决或是一个隐秘bug的筛查，可能会花费大量时间，说不好一天就搭进去。如果真的说“提交多少代码=做了多少工作”，那研发个自动提交代码的程序对于技术来说不算难，这么互相骗下去，双方都有损失，为什么不能多一些理解和沟通呢。

所以，请不要单纯拿延期和工作量来评价技术研发工作了。

新需求，可以说是技术的日常，不是不能加，而是要加的合理。

你以为加一个按钮是UI设计好、改改界面就能搞定的？一个简单的调整可能牵一发而动全身，影响了前端不说，甚至连后台逻辑都要改。

举个栗子，做平台链接供需双方，想加一个聊天功能，虽然界面看上去是一个按钮的事儿，而且聊天功能现在很多产品都实现了，开源也有，但是否能直接拿来和现有业务逻辑合并？是一对一聊，还是多人群聊？每换一个或加一个人进来，之前的记录是否保留？如何避免双方聊上之后互换联系方式最终跑单等等，需要非常全面的考虑，不是说拿来copy一下就能直接上的。

最恐怖的是，老板想加一个搜索功能，需求就是“要像百度一样”……

不懂技术没关系，不了解背后的逻辑和复杂程度也没关系，但新需求能否沟通下再做结论？别让技术总是最后一个知道，连产品经理都蒙逼，连需求文档都没有的情况下，就让技术去实现，这可真不是晚上加会班的事儿。

什么？下礼拜上线？呵呵哒~

用人不疑，相信是很多老板挂在嘴边的原则，但是否能落实到行为上就另说了。

不怕一无所知，就怕一知半解，自以为懂点技术就指手画脚，听风就是雨，看到刷屏级H5就想复制一个，看到外面有人说react混合开发成本低就想试试，看到小程序流行就想追个热点掺和一下。

这还是外行想要追求新突破提出的建议，一般内部交流、讨论下就能说服老板，但就怕遇上一知半解自以为懂代码恨不得自己下手写的。

CEO的本职是什么？找钱、找人、搞定公司发展，为未来谋划，而不是把那些细枝末节都强加在自己身上。

的确，有的技术可能真的不如CEO专业，能力差的可以替换，有潜力的可以培养，否则强的只是CEO一人，于整个团队无益。

一个人做不完所有事，兼顾不了所有细节，CEO要有包容的胸怀，信任他就交给他去做，可以提出建议、方法，但不要过分介入、干涉。比起直接干预，可以请个外部技术大牛，换一个角度帮助团队发现问题、解决问题，会令所有人都信服。

既然专业事交给专业人去做，那CEO还有必要懂点技术么？

叨叨曾遇到过为了与程序员交流更顺畅而去学习技术的CEO，精神可嘉，但更重要的，还是看心态。

很多被技术坑过的CEO都会想懂些代码，但一方面做个全面的创业者，另一方面学习技术并实践，对于非技术背景的CEO是不现实的。但基础的了解还是有些必要，最起码的要知道PHP和JAVA是不同语言，分析师、架构师、IOS/Android/PC端、运维、前端、后台、测试分属不同专业领域、有着不同岗位职责，不要一股脑以为有个CTO就够了。

另外，了解一些技术并不是为了干涉程序员的具体工作，而是能够从更全面的角度分析产品，避免提出那些不合理的需求，提高团队工作效率。其实对于“懂点技术”，更多的可以是对产品经理的要求。

比如腾讯，非常提倡技术出身的产品经理，一方面善于发现、筛选用户需求，另一方面懂得在技术实现与用户需求之间找到平衡点，比如腾讯创始人，他就是这样一位技术出身的产品经理，还做了CEO。

聊完专业的，再聊聊日常。

程序员的日常和电脑有着不可分割的密切关系，但这并不意味着技术就会修电脑。有多少技术没帮助运营妹子修过电脑、装过软件？开始可能会乐此不疲，但时间久了也是会烦的，更不用说在梳理逻辑的时候被打扰，真的是@#￥！&*#￥&@*

不只是程序员，被误解最深的恐怕就是CTO了。

很多不懂技术的老板对CTO的定位就是“万能魔术师”，仿佛一个好的IDEA只要有了CTO的加入就能改变世界、改变全人类。

但事实上呢？

知乎上“程序员pilot”的回答很有意思，“顶着CTO的名头干着技术组长兼打杂的事情，包括但不限于招聘，裁员，拉网线，查机房，装系统，重装系统，讨论方案，推翻方案，谈合同，签合同，哄手下，骂手下，被老板哄，挨老板骂，确定进度，拖延进度，重新定进度，取悦老板，揣摩老板，写画饼邮件，写辞职邮件等工作，工作内容一般不包括编码。”

所以，对老板而言，只要他们认为目前技术团队不够好，不够给力，不够预期，就认为自己缺CTO。

几点建议，供大家参考：

1.一纸协议永远比承诺更靠谱。不要觉得股权无所谓，该争取的不要碍于情分、面子而觉得不好开口，要知道，只有明确了利益归属，才好绑在一起加油干。

协议中要明确约定公司协议主体和性质、股权比例、出资方式和期限、回购条款等等，这类注意事项搜一下都能找到，不再赘述。

2. 警惕公司改革。那位被坑了7年的技术合伙人就是在不知不觉中被CEO将股份转移至自己名下，所以，和谁签的协议一定要明确，并且信息可以在工商备案中查到具体信息。

3.明确退出条件。无论项目上市、被并购，还是中途离开、被离开，都要明确你会得到什么、如何得到、各自的前提是什么。

4.明确工作成果的所属权。相信没人愿意最终对簿公堂，但万一出现这种情况怎么办？当对方一口否认工作成果属于你，将你贬得对公司毫无价值怎么办？所以，必须留有“证明工作成果属于你”的证据，比如在你开发的代码、软件里面埋几个彩蛋，只有你自己知道彩蛋的出现方法，前提一定是不影响业务正常发展、不恶意留后门。友情提示：翻墙证据无效。

至于其他的坑，比如重构别人代码、钻到N年前别人写的代码里修bug、和苹果审核撕逼、旧系统没有源代码等等，篇幅有限，下次再聊。

程序员的坑虽多，但远没到绝望的程度。

更绝望的是，明明知道是坑，却还是要努力完成它……

向每一位战斗在代码一线的程序员致敬，祝早日找到妹子！