程序员·看创业
我没创过业，只是在一家创业公司工作。所以是在看别人如何创业。
如果想从这篇文章中学到如何进行互联网创业，或是如何避免互联网创业过程中的一些问题，还是请绕道吧。我只是想要抱怨抱怨、发泄内心积压的负面情绪，想要站在一个员工的角度说说在互联网创业公司存在的一些问题。其中尽是些个人观点，不足以取。如果你也一样是一个在互联网创业公司里打拼的员工，又与我有着相似的经历、想法和看法，希望能得到此交流。
先来点自我介绍吧，我是一个有理想的程序员，我想要写出牛B晃晃带闪电的代码（呵呵~ . ~呵呵）。我有多个老板，因为他们是联合创始人。
不废话了，开始吐嘈
针对以下问题一个一个喷，希望能够带起节奏来。
- 需求频繁变动，这事怪谁？
- 几位联合创始人意见不同时，听谁的？
- 老板与技术意见不同时，听谁的？
- 大家与技术意见不同时，听谁的？
需求频繁变动，这事怪谁
在一个互联网创业公司，无论老板懂不懂技术，都会存在这样的问题（我猜的）。需求不稳定就急着让开发，代码还没写好需求就变了，你给领导（老板）说重构，领导给你谈时间成本。产品还没上线，第一次需求中的A已经变成了C，第一次需求中的“南”已经变成了“西”。这还不是最头疼的问题，因为你还会遇到从A变成B、变成C，变成D再变回A的需求。
结果是最终上线的产品，代码乱糟糟，功能勉强能用。再经过几个月的迭代（一直增加新业务，没时间供优化旧代码），代码完全无法维护了。出了问题后，老板找到产品，产品推给技术，技术无能为力。你说这事怪谁？
作为一个程序员，第一反应：“这锅我不背，要想程序稳定可维护，要么需求别变，要么重构代码”。
产品可能会说：“老板A让加的a功能，他是老板他说的算。老板B把a功能改成了b，他是这个领域的专家，他说的有道理啊。老板C说这个功能需要改成c，他做市场，这是客户提的要求，没毛病。”
老板们可能会说：
- 我觉得客户应该这么用；
- 我是站在客户的角度提的要求；
- 有哪儿哪儿的某某用户说了，这个功能不好用，要是加上XX就好了，YY地方也有用户提过类似的要求。
上面这只是很小很小很小很小的一小小小部分需求变动的场景。作为一个程序员，我是解决不了这些问题的，我也开发不出万能的程序，更是不敢再吹牛说自己想写出牛B晃晃带闪电的代码了（笑哭）。
联合创始人意见不同，听谁的
先说明一下，这里可不是上一节中提到的“A改成B，B改成C，C改成D”的问题（呼呼+白眼）。
人的经历不同，知识深度、宽度、领域的不同，对同一事物的看法和观点也不尽相同（又是瞎猜，没有理论依据）。几位联合创始人，必是各有优势，形成了互补，所以组合到一起才更容易达成目标（瞎BB）。举个例子（开始忽悠了），“一个计算机专家 + 一个管理精英” ， “一个计算专家+一个计算机专家”和“一个管理精英+一个管理精英”这三种组合，哪一种做互联网创业的成功率大一些？
别走神啊，上面这些只是为了说明，联合创始人很容易产生意见上的分歧。还需要明确的一个问题是，“听谁的”和“应该听谁的”不是同一个问题。我们不聊“应该听谁的”，因为我也不知道应该听谁的。
场景一
A板：“我们还没起步，还没有用户数据，如何做大数据”
B板：“既然是战略规划，自然要想的长远一些”
C板：“对，这可能是我们最终的目标，算是最大的战略规划了，在公司的发展中长期不变的……”
B板：“不对不对，不能算是最终目标，也不是最大的战略规划；你可以把公司上市当成最终目标，或者上市都不能是咱们的最终目标，上市之后公司还是要发展要前进；或者说公司没有‘最终目标’一说，我们实现一个目标后，肯定会再有一个更大的目标；但这可以作为公司的第一个长期的战略目标。”
C板：“对对对，需要一个长期的战略目标，既然是战略目标，就不能一年半载的就变一次吧”
A板：“嗯……，好吧”
A板内心独白：“那我们的技术现在要做些什么呢？”
A板：“开发一个支持大数据分析的xx管理系统，技术y个月后可以出第一个方案；从方案确定到上线可能需要1.5年左右的时间”
B板：“我们现在只是要做一个xx管理系统，不需要做大数据支持啊，大数据是我们长期的战略规划，现在做为时过早了”
C板：“对啊，你只需要在现在系统中预留好支持大数据分析的口子就行了，这样应该多用不了太多时间吧”
A板：“仅预留接口的话，开发的时间可以省下不少，但是设计和方案还是需要出……”
B板：“那先不考虑大数据的事，这只是一个长期的战略规划，我们的xx管理系统下个月初出Demo，十月一号上线的时间点不能变”
场景二
B板：“我上次让加的功能xx，做的不错，如果能再加点yy功能就更好了”
A板：“我们开发这个功能时，没有考虑在xx上再加yy功能的事”
B板：“这样可不行啊，技术上不是应该考虑兼容性、扩展性、易维护的吗”
A板：“上次你周一说要xx功能，并且要求周六就得上线，我安排技术部加了两个晚上的班赶出……”
B板：“时间紧也不能不考虑扩展性啊，那个yy的功能是无法扩展上了吗”
A板：“也不是不行，重构需要时……”
B板：“别别别，别动不动就重构啊，你先叠加上去吧，尽快上线就行”
场景三
A板：“我觉得咱们可以举行个xx活动，调动员工的积极性”
B板：“调动员工积极性，不一定非得xx活动啊”
A板：“正好还可以让员工之间有个交流”
B板：“平时员工之间都不交流吗”
A板：“部门内容交流很多，但跨部门交流很少”
B板：“那可以用yy的方式促进跨部门的交流啊”
A板：“这个活动可以一举两得啊”
A板：“如果效果好，我们还可以选出xx大使，代表公司对外出席xx活动，一举三得”
B板：“要选xx大使，在tt部门内部选就行了，不用全公司都参与啊”
A板：“我觉得这个xx活动挺有意义的”
B板：“你要是觉得有意义，你就去做好了，不用征求我的同意”
C板：“这个活动可以做，但确实意义不大”
结论：不了了之
好吧，我承认，以上场景都是我脑补出来的。如有雷同，纯属巧合，如不雷同，算我瞎编。
老板与技术意见不同时，听谁的
场景一
技术：“这个实现起来技术难度比较大，并且时间也来不及啊”
B板：“这个是用户的要求，用户就是上帝，我们怎么能不听上帝的呢”
技术内心独白：“这周末能不加班吗？我想让所有技术去教堂做礼拜，祈求上帝少说两句”
技术：“晚几天上线行……”
B板：“时间上肯定不能再推了，你可以压缩一下代码，这样时间不就剩下来了吗？”
技术内心独白：“压缩代码？这不是应该增加时间的吗？”
B板：“反正就是你不用把代码写的那么完美，先能用起来就OK”
技术：“好吧，我们加班试试”
结论：全体技术周末不休息。
场景二
B板：“xx地用户大量反映需要这样一个功能”
技术部：“可以实现这样的功能，需要做一个长远的规划，方便以后的扩展和维护”
A板：“这样需要的时间会很长吧”
B板：“这个功能必须要，尽快做就行了，至于你们怎么实现就是你们技术内部的事了”
技术部：“长远考虑，还是应该好好规划一下”
B板：“嗯，同意长远考虑，但长远考虑之前，先把这个功能上线了”
技术部：……
大家与技术意见不同，听谁的
市场部（第N次提需求）：“这个效果不错，如果能在咱们平台实现应该可以吸引不少眼球”
C板：“你们把这个想法和技术聊一下，看看好实现不？”
技术部（内心有十万匹草泥马在奔腾）：“咱们系统的当前架构要支持这个功能，不太好实现”
市场部：“那就是能实现呗”
技术部：“……”
技术部发邮件，抄到负责技术的A板：“这个功能加上后，系统的原有结构就不统一了，以后维护会很困难”
A板回邮件抄送C板和B板详细的说明了情况，然后B板招呼大家开会。
B板：“这个东西不错，咱们的系统需要这样高大上的功能”
C板：“市场部了解到，XX省YY市的XX用户希望咱们的系统中能出现这个功能，这个需求是直接来源于用户的”
A板：“调整框架支持这个功能需要x周，但仍然对咱们之前的软件系统规划有出入，……”
B板：“技术上我也听不懂，你直接说能不能实现就行了”
A板内心：“草！”
A板：“嗯……，可…以 …实…现…”（内心是流血的）
技术部内心：做吧，出问题了再说吧。
总结
需求来了，公司里所有人都认为技术是万能的，所以没有实现不了的需求。我没有列举任何软件出问题后的场景，因为我是一个程序员，我不想把自己眼泪写给大家看。但出问题后，你应该能够想到，所有的问题都是技术的。技术是什么都不行，所有需求都实现不了。
