经历了太多乱七八糟的产品和项目，听到了很多有趣的猜想和假设，我把他称之为"研发大猜想"
猜想1：这个系统架构和代码太烂了，我们重新做个2.0系统吧，前面的问题就都解决了 感觉好像新做的2.0代码就不会和1.0系统一样烂了，结果就是和以前一样前期赶需求，后期集中测试，什么设计，什么内建质量都是太浪费时间，最后搞了大半年搞出了跟1.0一模一样的代码烂泥。怎么办喃，还可以3.0嘛。
“如果不改变做事的方式，永远都只能做出一样的系统”
猜想2：因为业务要的太急，所以我们没有时间写单元测试，没有时间做代码评审 听着很有道理，就好像不那么忙的时候，他们就会写单元测试了。实际上他们从来没写过单元测试，也永远不会去写。因为从思想上就没有理解什么是合格的代码。一个合格的程序员交付给测试人员的代码应该是很难再测出问题，测试人员花大量的努力都无法验伪的程序。这个才是一个刚刚合格的程序，因为这方面仅仅是功能无问题，还要涉及设计的合理性，抽象性，耦合性，代码可测性等代码结构事宜。
“一个合格的程序员，应该有这样的品质：自己写的代码，应该在功能上很难验伪，在设计上保持代码健康。”
猜想3：业务两周就要一个版本，连回归测试的时间就不够，我们干脆把版本周期加长，然后搞几个前后并行的版本，这样人处于最忙状态，研发就最快了 在集成测试阶段开发人员有空闲，所以下个并行版本要进入到开发阶段。最好在第三个并行版本进入到需求分析阶段，这样大家就看起来都很忙了。下面的人保持最忙的状态，才显得上面的人员指挥恰当。 结果就是搞需求的时候，还要同时搞开发，搞缺陷，搞开发的时候还要同时搞上版本缺陷修复，每个事情都没做好。结果是需求没有搞清楚，开发设计一团乱，缺陷一大堆，就这样往复循环。但每个人都很忙，真的很忙。
“好好体验一下，做好每件事情，大脑处于专注流的状态”
猜想4：一个功能需求写了很多复杂逻辑，各种场景覆盖，产品经理的价值体现就在能把事情考虑周全 写产品需求是很枯燥的事情，不是某个领域熟悉的人，却想写出解决这个领域问题的产品需求，还要能读懂使用者最终怎么用这个产品，同时还想产品功能面面俱到。遇到这样的产品经理，研发团队是痛苦的，平白的做了大量的复杂业务逻辑。最后用户认为功能难用，不能解决问题，推翻重做，产品经理美其名曰“我在试错”。这样的产品经理从来考虑不清楚，这些功能的价值是什么，能解决什么问题。拍脑袋写大量的文档是他们最喜欢的事情，为什么呢？因为不用思考。 殊不知就算你熟悉这个领域，也不该一开始设计复杂的功能逻辑。简单即是美，往往是简单的功能才能解决用户问题。
“优秀的产品经理真的很稀有”
猜想5：项目会有紧急需求，遇到紧急需求的项目要加人，我的项目总是缺人，要多补充人，就能把事情完成 人能解决所有的问题，人多我就什么都能搞。不了解沟通的耗费，不了解优秀程序员和劣质能写hello world 人的区别，不了解往进行中项目加人的影响。只想通过加人解决问题。问题真的是人不够吗？ 你见过谁说我的项目人太多了，需求太少的事情吗？
“问题的本质真的很重要”
猜想6：项目大部分是倒排期，不合理 按照估算排期就是正确的？怎么证明按照估算排期就是正确的？我倒是觉得估算排期证伪比较容易。看看历史数据估算和实际偏差有多大就知道了。 “所以动态规划就很重要了”，实时的适应变化，这个迭代需求多了，减少点， 需求少了，增加点。要满足某个倒排期的市场需求，去找寻mvp。
猜想7: 我们团队没有产品经理，团队无法明确需求，需求经常做偏 程序员要做好两件事情，搞明白要做什么，正确的做出来。有了产品经理，就指望这个人把做什么搞明白，再告诉你。做的东西用户不满意就是产品经理的问题。你再不用了解用户遇到什么问题，也不用思考怎样能解决用户的问题。没有产品经理，你就什么都不会了。 你都不想理解问题，就开始写代码.
“难道真的是不要把爱好变成工作？”