创业公司都是这样的么?

[chairo]

产品经理弄一个简单的原型图，然后给开发讲解他们的想法。具体细节在开发过程中才由开发人员自己补充（当然可以随时和产品经理讨论）。
但是，如果开发过程中有可能随时出现业务上有逻辑冲突或者产品经理随时会修改需求的情况。
问了几个创业公司的朋友，发现大部分都是这种情况，创业公司都是没完没了的加班……

[zhangjingqiang]

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

[iwinux]

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

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

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

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

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

[proper]

@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/

[avatasia]

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

[zealot]

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

[zealot]

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

[chairo]

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

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

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

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

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

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

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


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

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

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

[chairo]

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

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

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

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

[zealot]

@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]

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

[chairo]

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

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

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

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

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

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

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

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

[chairo]

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

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

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

[tokki]

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

[flyingkid]

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

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

[zealot]

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

[zealot]

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

[tokki]

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

[tokki]

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

[kekecen]

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

[j]

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

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