创业公司都是这样的么?

很烦是不？所以程序员没人愿意做，成就感还不如创业公司的设计师或是产品经理。

加班暂时没碰到，倒是老板没完没了的改页面风格

一般的创业公司好像都是这样了

没有任何成就感
深刻理解到“码农”这个概念，每天就是不停复制、粘贴
做完一个增删改查，马上做下一个。

@chairo 那要怎么样才有成就感呢?
或者说 程序员眼中理想的创业公司应该是怎么样的?

纯好奇- -

产品经理改需求是一件尽量需要避免但是又难以避免的事
除非商量出政策，交付文档后不能修改。只能等着下一版才能改变。
如果紧急情况的就要走个流程来抑制随便修改的情况

自己接触的创业公司大部分都是这么个状态，我自己这边也是，很难像大公司立项那样一套文档流程走下来，甚至是大公司比较成熟的产品+设计+技术，出来干活人不多的情况下也都是乱拳打死老师傅的干法

基本都是先定大方向，找找看有没有可以参考的其他网站，如果没有是独创性的，那么做简单的原型，如果有，可能就照抄构架，换ui，懒的ui都不换

其实这个也是创业公司独有的氛围，整个过程参与的人不多，看起来乱糟糟没什么逻辑，但是每个人都把自己擅长的部分处理好，产品还是可以比较快速的推进的

至于程序员的感受，这个市场对人才总是渴望的，同等能力的人在大公司可能活的更轻松，但是也会有其他的烦恼，不可能什么都顺；自己认为，选创业团队还是要看做的东西自己感不感兴趣吧，或者是创业团队有大牛，去追随，也就这样吧

真正的创业公司没有加班的啊
大家在为自己做事，到晚上12点也不觉得在加班

当然还是要保持工作和生活和平衡

@Ziya 不好意思去培训了下。

俺不可能代表所有程序员，但我眼中不管创业公司还是非创业公司，我眼中的好产品或者好产品经理都是熟悉他所做的行业，熟悉相关业务。出一个需求起码是经得起推敲经得起讨论，而不是只出一个“点子”或者说一个“创意”。这样的产品可以持续有二期、三期

好的创业公司就起码有好的产品，好的产品经理。

现在我所经历的情况是：产品经理出一个大的方向，具体业务的逻辑关系不去考虑。文档中也不会有体现。

而且项目开发周期有最终的时间点，现在的情况就是产品出一个所谓的“框图”之后，苦逼的程序员们就凑在一起讨论这个框图规划的各个模块之间关系&&限制等逻辑，发现逻辑有冲突再去和产品沟通。

产品的框图或者说文档中同样没有测试所需要的信息：比如一个输入框上限是多少，下限是多少，是否必填，格式是否有要求等等。

现在的现实就是，开发理解的需求和测试理解的需求可能并不一致，开发结束以后会有各种没有想到的bug出现。

没有任何一个项目能如期交付，而且发现产品经理设计的产品内部逻辑冲突时候，产品经理最喜欢的就是大刀阔斧的修改一下。这样可能造成数据库结构变化，之前写的代码会有很多修改。

team中的程序员均表示压力很大。

@wenhuacn 真正的创业公司是老板嘴里的概念，对打工的程序员来说在什么公司都是打工。

@chuck911

同意。
所以国外叫海盗团队，国内叫创业公司。

创业确实是尝试，很多时候会很快发现之前的想法错，这时候要迅速调整，合理。

但连续加班是不应该的。加班并不能省时间，人的精力是有限的。自己愿意做喜欢的东西除外。

我们寻找一个人的时候，首先要确认对方是否喜欢我们做的东西，是否赞同我们的价值观。如果不行，那么其他的都没意义了。

建议去看黑客与画家

有这种想法，如果你是天才，请尽管换工作；如果不是，请不要再扯，做好自己的事情。

我认为37signals对程序员而言是理想的创业公司。
创业不必苦大愁深，但创业毕竟不是一件容易的事，会有很多脏活累活。将产品规划的功能实现出来的编码过程，很多时候是枯燥的。如果所谓的程序员只是将其他人拍脑袋的结果实现出来，那真没什么意思。
《黑客与画家》中提到黑客的概念，黑客享受的是创造的过程。
那写乐于参与创业公司的优秀程序员应当更接近与黑客。
真的很难想象一个优秀的程序员会单纯到两眼内只有技术。

居然有只出点子的产品经理。。。

想法一点都不值钱，没有文档输出的产品经理要来干嘛?而且逻辑，模块和主题界面布局这些都应该是产品经理的职责。

@chairo 还是在说产品啊...可我想知道的其实是程序员视角...
是否可以理解为,如果排除这些对产品的抱怨,是否就是程序员眼中理想的创业环境了呢?

@virushuo 大牛居然也进来了。不过您说的是不是前后矛盾“但连续加班是不应该的。加班并不能省时间，人的精力是有限的。自己愿意做喜欢的东西除外。 ” “我们寻找一个人的时候，首先要确认对方是否喜欢我们做的东西”

这样来，你招到的人都是喜欢连续加班的了……开一点玩笑，同意对于喜欢的产品是可以付出精力付出激情。

“迅速调整”这个是肯定的，有错误是需要改。但如果说产品总是处于随时“调整”就是否应该不太正常了？

而且我现在碰到的情况是，在需求讨论阶段就已经是在“随时调整”了。而且产品出“原型”的时间已经占用了项目开发时间的一半以上。

@Ziya 俺作为一个程序员来说，维护一个值得长期维护，值得去为之持续付出的产品是我所重视的，我认为产品做完之后可以在同行中是优秀的，是领导行业趋势的就是好的工作环境。我用词是工作环境，而不是创业环境。因为创业这个概念应该属于老板而不是程序员。能看到一个优秀的产品在手下诞生就是我觉着会很开心的事情。

所以我大多在发泄对产品的不满，因为我现在所在公司的产品仅仅是产品经理们的“点子”，换一个好听的说法是：这个行业没人这样做过。

@avatasia 俺不是天才，但已经换工作了。最后一周在这公司了，年前一直在犹豫，因为这公司所在的大行业是很熟悉也喜欢的一个行业，年前就收到了其他公司offer，考虑过后节后才决定离开。

走上创业的路上，不管是什么角色，都会无休止地工作吧，哪怕看起来有些成员很闲，但很有可能他的脑子就没日没夜的思考中...

@chairo 谢谢你满足了我的好奇心....:)

@chairo 我说精力是有限的，所以被迫加班没用。所谓自己喜欢的东西除外，意思是会为实现一个功能而付出更多的劳动，但总有忙或者不忙，总共付出的精力总共还是差不多的。所以我无论是创业还是在大公司带团队，都比较反对加班。我比较支持让程序员在自己喜欢的时间段工作，他们有可能在短期付出更多时间（为了更早看到自己的劳动成果，希望快点做好。但这和被迫加班不一样），但长期看来人们*有效*劳动时间总是差不多的。

最讨厌的是和不懂软件的人搞软件，
还要听从明显错误的指令就郁闷了，
有条件还是自己开公司凭自己想法，
不然总是摆脱不了这个那个坏情况。

1. 没有加班，但反正在公司里也没别的事情干，所以除了吃饭睡觉看书之外基本都在写代码咯……

2. 没有正式的需求文档确实是个问题，每实现一个功能都要来回问N个问题，效率比较低

3. 需求变动已经习惯了，功能上的变动还好，最怕是前端界面的修改……

4. @chairo 所说的复制粘贴我无法理解，是指复制第三方的代码么？我们用 Rails 做开发，所以第三方的代码都是通过 gem 的形式复用的

总的来说我觉得目前这份工作很好玩。

@chairo 觉得你说得问题不是创业公司的问题，而是你们的流程问题。而且似乎前后逻辑关系不大，看不出来需求更改和加班的必然联系。
所以你的问题可以简单分解为：
1. 你们公司是创业公司
2. 你们公司经常加班
3. 你们公司的产品经理提出原型，然后经常改需求

觉得2你可以跟公司谈谈看看是不是分配给你的任务过多。

3其实你自己也是决策者之一，因为产品经理只是设计出来大概的原型而已，细节是你定的。你是具体实施的那个人。永远也不能指望别人知道你需要什么，除非你清楚得说出来。文档不能解决大部分问题，只会创造更多的问题，比如这个帖子本身。
当然，如果你的意见被忽略了，这是公司本身管理的问题。

最后用Agile Manifesto共勉吧：
“
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
”
from http://agilemanifesto.org/

@chairo 其实程序员的能力，第一能力是协调能力，因为真正做东西用到的技术可以很简单。

一点看法
1) 产品经理任何情况下都不应该随时改需求
2) 产品经理不应该只是讲想法，而且要为自己的想法写下文字记录、说明，以及期望的目标
3) 产品经理只要给出产品结构上的信息就行，比如”在用户名称旁边放置一个头像“，结构如何安排。细节交个UE、开发完成，但是产品经理需要去协调
4) 开发人员需要参与产品设计，不然去大公司、死板的公司做螺丝钉好了，不要趟创业的水
5) 开发人员(尤其是前端)需要重点参与产品细节设计，工程师不关注web上的细节设计，工作状态停留在”A需求？可以做；B需求？做不了“，那哪来HTML5？哪来IE7？哪来进步？
6) 研发人员一天天对着代码，光靠文档就能了解需求？不懂需求哪来系统设计？

补充一个：
产品经理也是人，不要指望产品经理有多年的经验就可以拍拍脑袋，搞出来个火爆的产品
创业团队小改动应该是持续的、经常的，但是没有合理的AB Test方案、不做日志统计、不做分析、不做回顾、总结与分享，那所有的改动就是扯淡
同一团队、同一个目标。产品经理不应该是PRD上的那个作者，程序员不应该是死开发。一起并肩作战，兄弟一样的感情和沟通才是创业团队应该有的气氛。

@zealot 下午时候和一个技术出身跑去做产品经理的朋友聊了一下，他的观点和您其实差不太多。

3) 产品经理只要给出产品结构上的信息就行，比如”在用户名称旁边放置一个头像“，结构如何安排。细节交个UE、开发完成，但是产品经理需要去协调
这一点，我碰到的产品经理完全可能会给一个文档“注册->登录->退出”，中间功能只要求“好用”即可，好用的程度取决于运营同事或者其他用户。当然这个是特例，但这种粗度的需求估计正常的产品经理都应该不会给到吧，但我现在公司的产品经理就干过这事。

我觉着文档足够细了会节省开发人员和产品经理来回口头或者书面沟通的次数，同样细一些的文档也一样节省测试人员和开发人员之间理解差异的问题。

举个工作中的例子：产品经理的注册用户原型图中只写了注册用户名。但这个用户名长度有没有限制不说清楚，数据库中存储用户名字段长度设置成多少才合适？测试人员测试时候经常会问，产品的文档中没有说明多少长度才合适，为什么研发人员就限制了10个字符？我常用用户名明明是20字符，但却输不进去。

如果产品的文档中有说明：用户名长度 6-12个字符，这样的问题可能根本不会产生。

而创业公司，至少我现在的公司产品经理只可能会说：我需要注册功能，填入用户名密码，点击确定，给用户发一封激活邮件。注册功能就结束了。

但研发人员和测试人员关注的点文档或者原型图中一般都不会有体现。


6)光靠文档就能了解需求？不懂需求哪来系统设计？ 这一点可能我不大同意，如果文档粒度足够细，完全可以通过文档了解需求，足够细的文档完全可以做到技术和测试完全脱离产品来做开发&测试的。

“同一团队、同一个目标。产品经理不应该是PRD上的那个作者，程序员不应该是死开发。一起并肩作战，兄弟一样的感情和沟通才是创业团队应该有的气氛” 现在我纠结的不是感情或者气氛的问题，我聊过的产品经理基本都是给研发灌输一个我需要xx功能的概念，但概念落实到编码上是需要一些约束或者规则的，这些本来就是需求文档中应该体现，而且这些约束规则并不该三天两头就变动的。

要知道文档粒度不够细就会增加研发->产品、测试->研发、测试->产品之间相互沟通的成本。虽然可以说是“关系融洽”，但时间是确确实实浪费掉了……

@zealot 您其他意见我基本都是很赞同的…
当然，有一部分可能是因为立场不同。归根结底可能是因为俺太懒，有一些类似产品规则和限制等部分正常应该是产品经理来做决定，而我接触过的相当一部分产品经理的文档中不会有这样的体现。

有的人说也就是开发时候问一句话的事，一句没问题，100句就会是问题了…开发的时间本身在一个完整项目可能只占三分之一的比重，来回沟通这些问题可能又占去了三分之一或者更多。这样的产品质量可想而知……

赶时间写出来的代码bug绝对不会少。

而且最重要的，开发人员为了赶进度就不得不加班，为了省事直接从其他地方复制代码而不去思考如何复用代码的可能性就会大大增加（思考如何写高质量的代码也是需要时间的，如同产品经理写一个详细的需求文档也需要时间一样一样的）。

@chairo
我的想法绕来绕去就那些，不逐条回复了
还是些个人暂时的想法

文档粒度
"足够细粒度"的文档，在我看来既不是很好的定义，也没办法执行；除非补充一下详细说明：细化到伪代码粒度。产品经理做High Level的设计就好了，细节根据任务特点分别由美工和研发做更专业、更自由。至于产品经理职责不是设计产品，而是分析产品、用户行为等，设计产品是指一个产出而已。所以非常细的粒度完全没有必要，但文档是必要的、变更记录是必要的，产品回顾、效果分析与分享是必要的。
开发、测试、产品、运营坐在一起办公，很多问题都能解决掉了。我说的”一起“意思是旁边或对面，有问题靠吼来解决，而不道社区讨论，比如站起来，冲旁边经常一起踢球的产品经理吼“你他妈的上午刚提的需求，我都要开发，怎么下午就要改了？”
创业公司里独立项目走事业部制最理想了

复制代码问题
这个我完全不认为复制代码提高效率，即使短期效率提升也未必。这个我很难三言两语说清我的想法。长期来说自然没好处：1）维护性差，很多复制代码风格、实现方式没法融入 2）不求甚解的复制最可怕 3）没有学习和理解，到头来终究是有报应的 短期也未必提升效率：1）N多次帮人调代码都是赶在上线前发现拷贝的代码根本没理解，出了问题不会调试不会解决 2）相当一部分bug出在复制代码上 3）复制代码就是花20%时间完成80%的开发，外加100%的时间去调试和解决bug，再加300%的时间去解决上线后的bug，再花不知道多少时间去重写

产品经理(PD)和研发分工(RD)，再扯上美工(UE)
这个不同公司、不同的职责定位都有差异，我更倾向于PD做产品分析、用户行为分析，而不是去纠结用户名最长多少字节，不是纠结实时性服务延迟1分钟还是1分半。最牛叉的PD，我也不敢跟着他拍脑袋决定的想法去干活。如果可以的话，我更希望知道做个产品、加个特性究竟是为什么，而不是说这个人经验丰富。
要我做PD，RD问我用户名最长多少，那就不限制最好了；实时服务延迟多长时间能接受，是个做产品设计的都希望不要延迟；
再回到用户登陆用例上来说一下我想象中的分工
1) 假设用户登陆长远来看并非重要功能，仅仅只是产品中若干个地方真的依赖注册用户，那就随意设计就好了，当面跟UE、RD聊一下想法，记录下来UE作图、RD按照自己的想法去做。不重要的内容PD就不用太关心、纠结细节了。至于担心页面风格不伦不类，那是UE职责，相信他；至于安全、开发细节等相信RD；至于若干功能细节，讨论前整理一些基本资料，开会确定一下就好了。
2) 如果用户中心是个非常重要的功能的话
我希望PD能够知道（或调研）一下各种方案，包括中文用户、英文用户还是邮箱作为用户名；注册页面是ID+密码，还是再加详细信息；是立即注册，还是填写订单后再注册；是否采用OAuth登陆；分析优缺点，结合产品属性与规划，做出相应决策；；同样，用户名长度不是重点。
RD需要知道（或调研）各种实现细节，比如OAuth；安全，比如密码保护、加密方法；是否采用https等。最重要一点：在技术上给PD提供参考与建议。比如单点登陆、https等有些技术，或者某些新技术PD可能不知道，这时候就是RD参与产品设计的一个点。
UE去页面美工、交互，比如js验证一下用户名长度等

修改：创业公司里独立产品线(不是项目)走事业部制最理想了

@zealot "要我做PD，RD问我用户名最长多少，那就不限制最好了" 这个是"PD做产品分析、用户行为分析"的结果么？

一个团队中肯定要有一个拍板这些细节的人，RD并不会去对产品行为分析，所以RD并不知道用户名长度多少是合理的。

在一个项目中，开发人员的时间能给到三分之一就不错了，在这三分之一的时间里还要去考虑每个字段多长合理，还要去考虑注册用户是填一遍密码好填两次密码好这种问题……时间怎么可能够用。

我比较倾向是 文档来驱动项目，PD手里有调研，有大量数据可以证明6-12字符用户名长度就最常见的话，那直接在文档标明：用户名6-12字符长度，不可包含特殊字符 就能解决RD和QA来回沟通的成本？为什么产品经理不愿意标注在文档上？

我很不明白为什么产品经理就不喜欢“细节”？

作为一个产品经理来说，这个产品应该是他最熟悉，用户名长度多少这个简单问题，有产品前期调研，有前期大量数据分析才能证明多少长度是用户最常用，最习惯的。这样的产品才好用，才会让用户在不知不觉中觉着产品使用最舒服？

这种问题不应该是产品经理最专业？难道是不会分析数据不会调研市场的RD更专业？

现有多少创业或者非创业公司在推出新产品时候会要求“RD参与”？RD一般都是被用来实现PD的想法的工具而已吧？如果一个新产品从调研到数据分析，架构设计、编码都有RD参与的话，那这个公司RD规模会有多少？那还要PD这个岗位干嘛？完全可以干掉PD只保留RD吧

@zealot 为什么我喜欢文档呢？因为PD不可能随时都在位置上等着RD去喊一下“这个用户名设置成多长才合理呢？”。PD白纸黑字写明白让RD和QA随时去参考不是更方便……

还有一个原因是因为好记性不如烂笔头，讨论时候PD说明了，但开完会或者讨论完万一RD忘记了呢？写在文档里就万一忘记了可以随时去翻，去验证

最后复制代码问题：为了节省时间，为了产品快速上线，为了把之前和PD沟通的时间追回来，复制代码都是最快的办法。哪怕之后维护不方便…因为时间有限

@zealot 哥们30左右 爱打星际 对不对

这个要看领导人的。能否带动起积极性。带起来了，你真的不认为自己在加班，而是在创造。因为这样的领导人知道如何去运作团队，而他只需要能运作产品的人。

好的团队好的领导人能彻底改变掉一个人！

@chairo 如果这样理解：RD只是PD实现想法的工具。那么不要趟创业这趟水，IBM/Oracle(中国)或许更合适。
p.s. PD参不参与市场分析这个得分公司，不同公司有不同的组织结构。

@tokki 刚满25，7、8年没玩星际了，没有了高中那种一起翻墙溜出去玩星际的人、条件和兴致了。

@zealot 我印象中大多数玩星际的人都比我年纪大 基本都30了 因为我玩的时候身边都是高年级学生。。

偏离主题了 可耻，创业公司什么的 我也面试过一些 基本都是抄袭别人项目 或者自己也说不清 也可能不肯告诉我 最后还是跑大公司去做了 要知道大公司基本上就是熬事件啊 最终做产品设计了 只给自己写代码－。－

我倒是觉得能够提供这种高自由度的产品经理，不是很有种就是很无能。
LZ的团队缺乏一点沟通和少少默契而已，和我见过的某些频繁对未出品的东西加以修改，甚至连基本方向都不能钉实的比起来，LZ幸福多了。

实际项目中，工程师对细节的逻辑经验会高于一般的产品经理，对于常规流程能“充分的脑补”是个自我要求。

产品经理最重要的三件事是
1要会写文章
2要会写文章
3要会写文章

@zealot 看了你说的这些，我觉得都是你的理想化，现实世界是很需要面对现实的，程序员做为
人活着，首先考虑的问题就是怎么在最适合自己的情况下最好的存活下去，为啥PD产品经理在创业公司中享受到那么多的资源和成果，而付出却不像想象中的那么多呢？而程序员就得不停拼命的写代码来赶工呢？享受到的资源与成果都不同，就好比又想让骡子多干活却又不多给吃的。哈哈
主要还是看站在什么角度看待这个问题。

@skywinger 知音啊.内牛满面

程序员想少干点活，少干活就表示少加班。所以需要一个详细的产品需求文档，可以迅速的安装文档做出产品

产品经理也想少干活，出个点子，画个框图。其他内容别人丰富去吧……

最根本的原因都是因为大家都懒，都想省事。而俺身为一个苦逼程序员就想少去想那些弯弯绕的东西，写完代码之后闲暇时间再去站在产品经理的角度想想做完的这个东西为啥要这样做为啥不这样做。

而不想在干活的同时还要去想这些屁事。这些屁事本应该在干活前由需求提供人就想好了的。

不想再继续讨论这个话题了，大家让这个帖子沉了吧

最后感谢@zealot 一直陪我扯这些，可能咱们站的位置不同，也可能我的眼光不够长远，也可以说我的职业生涯并不想朝一个产品经理的角色发展而是希望是项目经理或者技术主管的方向发展，所以咱们的观点会有一些出入。

感谢帖子中所有参与的同学，不一一点名。我已经做过了选择，过年时候和年后这一个月的时间想的也挺多了。在v2ex发贴本意只是想发泄一下，顺便看看大家的工作环境是不是都是一样，争取一点大家的同情而已。

再次感谢@all。

缺少交互设计环节的结果，产品经理的无能

开发人员自身也应该了解现在的业务和能为将来的业务多想想

作为一个身在大公司，做着创业项目的人，我很理解楼主的想法
这东西各有利弊，创业团队（或者公司）最大的目标不是盈利，而是寻找可持续发展路径，每一步都是探索，别说改页面，就算是你刚辛辛苦苦熬夜加班，数十个工作日搞出来的东西，直接重做都是有可能的。

流程也有流程的麻烦，你会厌恶开会、厌恶所有的人都被叫做资源，厌恶沟通不顺畅，厌恶，厌恶产品的傻逼需求，而你只能照做，厌恶一个螺丝钉的生活，厌恶等级制度，厌恶官本位，厌恶……

创业团队最大的优势在于灵活，最大的劣势可能是过于灵活，如果你不能改变，你不妨试着建议

楼上各位有些说法过于偏激甚至对程员这个职位或工作不满，所有的职位都可能碰到傻逼的问题，只是换了一种表现形式。我很反感这种自嘲，甚至有人叫自己所从事的职位为码畜、码奴之类的，你不尊重这个行业，就是不尊重你做的工作，如果自己都不尊重自己的工作，为了生存而留下来又何必呢？

人这一生能够做主的时间不多，希望所有抱怨的人都能找到自己合适的位置和工作，既然不能改变别人，或许改变自己是个不错的想法

第一次在v2ex上看到看不完的贴 创业应该是蛮欢乐的才对 累绝对是正常的 但最起码人人平等 老大拍板或集体抉择 如果只有闷头写代码的权力 这样创业不创也罢

@chairo 我是做了10年程序员的人，这点怎么会想不明白呢？我看真正不明白程序员心理的人是如zealot这类的人。不过我现在的发展方向也是产品经理这块的（只不过我从事行业的产品是偏向硬件方面的）

原来大公司的文档能细化到这个程度么,做程序员要懒的话,最理想不就是搞外包么?连函数命名都不用自己想了.希望工作就是把文档转换为代码的话明显不应该去创业公司吧.

主要原因是优秀靠谱的产品经理太少了，明明是个助理的能耐，顶个产品经理的title，自然不是dev被杯具就是他自己杯具，如果dev不够聪明搞得清状况的话，就是一起杯具

@undeadking 文档足够细化不是一件好事么？哪怕开发人员离职了，接下来维护的人一看文档也能很清楚的知道需求。

从来没进过外包公司，不知道外包公司的文档什么样子，但文档足够细可以避免很多人和人之间的沟通成本。磨刀不误砍柴功，前期准备工作做好了，接下来工作才会顺畅。

为什么“把文档转换为代码的话明显不应该去创业公司”？创业公司就一定文档不全？君不见那些创业公司上市前好多都是要在苦逼的补各种文档？做需求时候就已经留下了各种文档岂不是直接一步到位？

不清楚是不是所有“大”公司都主张细化文档，但我在的公司好像都是要求尽量这样的。而且一些“大”公司出来的同事甚至说他们公司的产品经理出了需求文档之后直接放在版本管理中限制产品经理为只读。增加修改需求都是要求重新评估工期的……

@chairo 这两天我们公司也在扯这个问题，人说把需求文档写全了写细了太耗时间了，所以采用 “先这样吧，您哪不懂哪有问题您再来问我我细化” 这么个方式。 现在的情况基本上是需求文档出个大概，程序自己补全细节然后文档化，同时写代码。

作为一个前外包公司的员工，可以就文档化说两句，在大连对日外包这一块，文档细化到，每一个单独的功能模块都会写出伪代码，基本上所谓的程序员就是从文档中把函数或者方法copy出来，改个符合规范的名字。然后再做少许修改即可。，没做过具体的对日项目，不清楚项目以后的维护性如何

我觉得不仅仅创业公司吧，人和人之间的想法肯定没办法完全相互了解的
只有不断的沟通不断的沟通
大公司顶多是沟通的机制比较好

37signals那样的公司在中国是不存在的。因为现在大部分公司的创始人都不是技术高手，他们没有能力实现自己想要的产品，任何工作都要交代下属完成。这样就导致LZ提出的问题的存在。而真正的高手，要么被外企挖走了，要么就是缺少创业的其他能力（如沟通啊，人际啊。）这就是教育体制导致的。所以，与其说现在的中国公司叫创业公司，不如说是批量复制公司。

看这个帖子最大的感受就是。我根本不懂大家at的是谁。。。每次都要回头找。

@chairo 文档在软件工程中的重要程度很高.不过基本只有大公司才能承担得起这么流程化的东西,成本很高,而且很不灵活,不适合短平快的开发,小团队根本没必要细化文档的,探索中的东西太多,没多少东西是能固定死的.

创业公司文档全不全我不清楚,就我所在的国企来说,文档多数是给客户和领导看的,对开发有用的文档恐怕只有数据库字段说明之类的玩意,给香港做项目都是先写代码再补文档的,这样的文档根本没用.

习惯了就好了.
第一.创业公司没有大公司的工作流程,人数也很难实现美好的头脑风暴.
第二.创业公司的点子基本上都是边做边想的....很正常...

为什么没有市场参与？

@alsotang v2ex 这点做得真是不好， 希望向网易评论盖楼学习。 这样只是@ 根本无法正常浏览长回复。

产品经理只管出点子，别的啥都不干？

这样的创业公司的产品经理是废物啊，还不如程序员一手包办得了。

1.在创业公司
2.是老板
3.是产品经理
4.从不做文档
5.经常改需求

怎么解决

1.先沟通大体框架

先用语言与程序员描述一下之后要做的功能，说明用户之间的关系等等。这时候我们的工程师就会在脑内构思整个实现方法，包括数据库。然后反馈给产品经理实现难度和时间，这时候就看功性价比，决定是否开发。

2.不做文档，做JPG

与设计师进行大量对接，做出一比一的设计图。字段多长，是否必填都在设计上一眼看到。

3.工程师领域的创造

当开发过程中有一些现成的实现方案可以套用的时候，我们工程师都会抛开设计自己动手做。不会盲目。毕竟有时候我们不知道对于开发来说最简单的实现方法是什么。


为什么不做文档？

文档的目的就是沟通，做文档就是希望不用沟通。因此这是一个性价比问题。当做一个文档的时间超越对话沟通的时间，就不做。

大公司人多，功能多，一个问题没办法和很多人同时说。但是创业公司可以。

而且我们的工程师都是有自己的创造力和决策权。一些通用的标准，例如用户名多长，这些他们自己就可以决定，问题不会很大。

为什么经常改需求？

1.怎么为之经常改需求？一个网站有十类页面。一类页面有十个板块，十个功能。总共1000个点，只要改1%都有十点要改的。

这样一看，会好像觉得：要改十个地方，好多啊。但其实这很正常。

2.改需求是一种常态。假如是创业，没有公司是按着最开始的商业计划书执行到上市的。更何况功能？再完美的功能都有值得深挖的地方，怎么更加简洁，怎么更加直观，怎么配对推荐。这种从技术的角度上是改需求，但其实也是一种改进。

3.产品不是妥协的产物。需求是服务用户的，不合就要改。产品构思和创造不是一次深思熟虑之后就会出来一个好产品的。连乔布斯这些世界级产品经理都会经常在做好之后把产品完全推倒重来。因为有时候想着的功能，看着的设计在脑子里面好像很棒，但往往在真正做出来的时候才会被发现其实并没有那么好。

怎么看心里会舒服一点？

1.我不是打工的。团队自己也有份，有什么不对提出来就好了。你觉得哪里经常不明白，可以自己做一个文档，交给你的产品经理，提醒他给你功能之前需要搞明白这些问题。或者叫他有什么奇思妙想的时候记得先告诉自己，看看实现起来的难度。

2.我不是一个实现别人想法的工具。在一个产品里面从来就没有“别人的想法”。工程师也是人，是人就是个用户。这个产品好不好用，这样设置我愿不愿意点击。自己脑子里面都可以过一遍。有什么不对的也是可以说的。

3.工程师并不苦逼。真不知道将自己看低一层有什么解决方法。这就是为什么我们喜欢招些快乐的，真正喜爱编程的工程师的原因吧。（即便这个“喜欢”里面有80%时间是干自己不爱的部分）

总的来说，一个快速运转的团队。如果一个产品经理只出点子是不对的，而一个技术只编程也是不健康的。每个人在自己职位都应该为别人多想一点，多给点方便。这就是我们所最看重的素质：http://www.v2ex.com/t/21741 (广告一下，还在招聘中）

@KingKidz
说白了，就是待遇决定一切，做老板的要深刻意识到这点。
不然就会有偏差的。

@skywinger 待遇是很重要，但不是决定因素，基本上到一个点就拼其他因素的了，工作意义、团队成员、工作环境、所在城市、自我实现、能学到什么、公司品牌、晋升机制、企业文化。

把待遇放到第一位的情况，往往是做的东西没啥意思，团队成员也是白痴，然后人就会想：你妹，要我做这种破工作，除非付很多钱给我。然后就会：“那请问贵公司的待遇如何呢？”

@KingKidz 神马叫做做的东西有意思，没钱，不产生经济效益的东西会有啥意思？
靠谱的还就是自己对公司给予自身的价值的衡量就是靠钱和资源（也就是权力）
另外问你下，一个月给10万和给20万，到底有没区别，是否向你描述的那样没啥区别，钱都够花了；
就可以拼其他的因素了？
在中国的当前环境下，讲其他的所谓要素一点都不靠谱，程序员还是多赚点钱，跑国外去做
自己喜欢的事才比较靠谱。

@skywinger 一个人的价值，或者直接一点，他能获得的工资，在一定时期都是固定的。你不可能在这个公司拿2K，在其他公司能拿到10W。更有可能就是这个公司5K，那个公司6K。那么，如果两间公司都给6K。这对于大部分人来说是可以接受的。

于是就需要拼其他因素了。

我说了待遇是重要，但不是决定因素。不用想象得做有意思的事情就是没钱，不产生经济效益。

而且为什么在中国讲其他要素不靠谱？为什么国外就靠谱？

@KingKidz
因为当前中国社会都是个急功近利的社会，人们的心理普遍急躁。都想着怎么快挣钱，挣大钱。
物价涨的快，人们考虑问题的第一要素就是赚钱。因此你所谓的那些，是你个人主观意愿的观点，
并不代表广泛的普世观点。在中国只要有人开价比你的高，你的人才就肯定留不住。
另外如果产品经理都只向你描述的那么简单的工作，主要工作都由程序员来实现，但是产品经理
却享受着高薪与掌控着各方面的资源，程序员会是怎么看待呢？至少会觉得，自己干的太多，
而产品经理却干的少拿得多，心理失衡很正常吧。

@skywinger 这种情况在我接触的网页游戏行业很多，公司与公司间的不正当竞争，往往开2倍到3倍的价格挖竞争对手公司项目的核心成员，挖过来让对方的项目进度变慢或者干脆就黄了，然后过几个月找个理由把挖过来的人开掉。所以跳槽不是坏事，毕竟人往高处走，但是得分清楚跳去的地方对不对，如果跳错了，就很悲催了，两边不是人

@skywinger

说到个人主观意愿我就笑了……

“开价高，人必走” ？
“产品经理比程序员多钱” ？

这些都肯定有特例的吧。

每个人都有自己需要负担的，有自己的欲望。对于物质的需求肯定是有多有少。物质之外的追求，即便没法苟同，也不能够一概而论吧。我自己就拿1500一个月，除了产品经理还做UI设计、SEO、微博运营、写文章、文案、招聘、推广、商务开拓、销售、项目沟通、售后，甚至买饭盒、买文具。我如果需要钱我可以在公司给自己开更多的工资。

但我就喜欢我现在做的事情，每天工作12小时都没有所谓。

会为钱而来的人，最后一定会为钱而走。所以我们招的成员，钱不会少，但这绝对不是决定因素。

难道谈论理想和自己喜爱的事情就变得那么不可能吗？外国就肯定好，有钱就肯定走。一个信任的领队，一件有意义的事情，一个融洽的团队难道不是人可以追求的东西吗？

我从头到尾都没有这么要求人家，我只是说有这么一种人会是这样。37singals并不遥远，不用到国外就能找到这样的团队。就看自己是怎么做的。

@KingKidz 你说的这种情况是可能的，但不一定适用与工作5年以上的技术人员，工作5年以上的程序员更多的压力在于生活方面，只有首先解决了钱的问题，才有可能生存下去。另外我不知道你的公司是否给予所有程序员相应的股份或是期权呢？如果程序员想提前兑现部分期权用于改善生活呢？

“好的创业公司就起码有好的产品，好的产品经理。

现在我所经历的情况是：产品经理出一个大的方向，具体业务的逻辑关系不去考虑。文档中也不会有体现。
...
”

如其他人所说，文档这东西对创业公司来说就是鸡肋，指望一个好的产品经理解决文档问题、需求变更问题是不大现实的，甚至可以说需求变更是常态，是必须的，而好的程序员应该思考的是如何以最小的代价应对大量的需求变更，如有必要，你也可以说服产品经理从一开始就按你的想法实施，以降低维护成本。产品经理永远都在说做这件事情的意义，而程序员一直要说的是做这件事情的代价。

@chairo 成就感是你对自己的要求，而不是对别人的要求；成就感是你自己争取的，而不是别人赋予的。想想清楚自己要的到底是什么，是每天8小时松散的工作安排？是团队其乐融融的互相扶持和理解？是努力加班换来高薪的回报？奋力争取你想要的东西，不要被那些细枝末节，生活琐碎扰乱了你的心情，比如单单拿技术活和设计、产品活做时间价格对比是不会有结果的。

@skywinger 成就感这东西因人而异的，如果你觉得产品经理、设计师好，那你可以奋力去尝试哈。

文档是死的，人和需求都是活的。做一个产品，最好是团队的设计者和实现者有一个对产品的共识，这样去做比较好。如果程序员只是希望照着需求文档开发，连注册用户名几个字符都要别人写好，那这个程序员和机器人有什么差别？产品的创造过程是整个团队的共同工作的结果。产品经理和美工和前端和后端都有创造的角色在里面。这就像一个交响乐，不是你每拉一个音符用什么感情都要指挥告诉你的。