软件开发项目里千万要避开的几种人

最近开始也陆续接了一些项目在做，聊一下项目管理相关的事情吧。从业也有13年了，也陆陆续续接触过不一样的项目管理，基本上来说的一点，没有任何一个项目管理方式可以解决所有问题，还是要根据团队本身做不同程度的调整。

说起软件项目，大致的流程就类似下面这张图

在软件项目实施的过程中，我们总是能碰到这几种人

产品经理

对于互联网公司来说，产品经理是一个非常重要的角色，一个好的产品经理可以做出不断让用户喜爱的产品，一个差的产品经理可能就会让团队陷入各种需求返工和大量的资源浪费。

但产品经理的入门门槛低，但做好却异常的困难。毕竟这个时代，谁都能说自己是产品经理，跟技术不一样，技术毕竟要实实在在的去编写代码。

所以大多数情况是产品经理直接沟通需求，所以这个就会发生一个问题就是，对于业务人员/产品经理来说，他的需求是希望用户能登录系统。但对于开发人员来说，他更多的是想知道实现细节，越详细越好，比如说通过账号密码提交，账号是手机号。密码不能超过多少位，如果找不到用户提示什么。密码错提示什么等等。

但是对于一个差的产品经理来说，他只能写出他的需求是希望用户能登录系统。但对于开发人员来说，他更多的是想知道实现细节，越详细越好，比如说通过账号密码提交，账号是手机号还是其他。密码不能超过多少位，如果找不到用户提示什么。密码错提示什么，如果涉及到外部登录，那么这里和系统的账号里权限怎么区分等等。

这就会发生一个很魔幻的情况，产品经理不知道自己要补充什么，他觉得他讲的够清楚了。开发人员也没办法讲全这些情况，每次碰需求总是能发现一堆逻辑问题，没有办法能推进下去。

更可怕的事情就是，对于项目的预期会有来自老板的压力，这样就会导致大量的需求不明确的情况下，强行的进入开发阶段来保证快速迭代。

然后就出现了项目过程中第二个悲剧的发生， 需求变更。

这也是大家声讨最多的地方，造成产品经理和开发人员矛盾最多的地方。在我从业这么多年里，我见识过很多非常优秀的产品经理，从需求的背景到需求的描述，搭配各种规则表格和流程图等等。你能看得出来，他是非常用心的在做产品。

但我发现很多开发人员都觉得这些事情很简单，不就是写一些话和弄一些图，自己也能做，毫无敬畏之心。在我制作自己的产品的时候，花最多时间并不是在开发上，反而是在产品的设计上。不断为自己的缺乏经验交学费，很可能做了一个功能，但是最后使用的人没几个。

回到主题，为什么开发这么痛恨需求变更呢？我认为问题还是出现在双方认知不一致的情况上，对于产品经理来说，可能觉得这些改一下很简单。但是对于开发来说，这个可能就非常大的问题。

举个例子，现在做一个微信里的H5活动，突然跟你说需要加入背景音乐持续播放。如果一开始没说，那么可能处于开发效率的考量。你可能直接就使用后端渲染来做，这样毕竟不用单独再写一份API接口。

但是在网页进行跳转的时候，那么音乐必定会被打断。虽然说也是有办法解决的，比如iframe嵌入，换成单页应用等等。但是引入新的实现就会破坏现在已经开发完的功能，好比你地基都打好了，然后去动地基，然后在评估可能的影响，说真的，就算连开发本身都很难预判清楚。

然而这个功能普通人都觉得很简单，毕竟其他页面也有类似的功能。很容易判断为是开发的能力不行，这么简单的功能都搞不掂。

我见识过一些优秀的产品经理会专门花时间去了解技术实现方案，也会跟开发人员沟通自己的一些小九九，这样在前期设计的时候尽量能考虑进去。

架构师与码农

那进入开发阶段了，是不是项目就没问题了呢？

这时架构师要出场了，有些读者不是很理解架构师主要做什么。其实架构师只是一个统称，更多的情况是项目的设计者，这个人可能是团队的技术经理，或者主要的核心开发程序员，或者一个技术大牛，简单说就是为项目打地基的那个人。

好的架构师会根据现有的项目情况，选择适合的技术方案。这个项目情况可能包含但不限于以下几点，项目周期、项目目标、资源情况、面向人群等等，会考虑到技术的可行性，并发情况，需求拓展等等。基本上来说会从多个维度去选择一个当前最优的方案。

但是一个差的架构师可能就毁掉整个项目，好的架构师会重构，差的架构师会重写（当然也有例外，我也见识过重写后无论是性能和开发效率都提升非常高，并且不会影响到项目本身预期）。

所以这里重写哥就要出场了，面对项目，会指责出这里不好，那里有问题，所以有各种各样的问题，只要重写了，一切都不是问题。

但更多的时候，重写哥无法讲出为什么会有这样的问题，更多是针对历史开发人员，而不是导致问题产生的具体原因，给大家一种我不是针对各位，是各位在我眼里都是辣鸡。还有一种情况就是，重写哥看不懂之前开发者的代码，但又拉不下脸皮去请教，所以唯有重写这条路可以走了。

就我目前看下来的经验，大多数上来就要求重写的，最后落地的质量比原来的质量更差，抛开人的问题，因为很多历史遗留的原因是新的开发者不知道的，往往在重写过程中就忽略了这些问题，导致产品质量下降。

聊完重写哥，我们来聊下轮子兄，轮子兄喜欢做的事情是造轮子，跟重写哥一样，有一种迷之自信，总觉得项目里现成的方案、框架、语言太辣鸡，问题太多。自己造一个出来，吊打全部。跟重写哥有同样的问题，缺乏对现有需求的理解或者轮子无法满足现有需求，更多的是满足轮子兄自己的需求。

最后来提的就是架构师，架构师，顾名思义，就是搭建架构的人。架构师最喜欢的就是谈并发、性能、架构，如何去理解呢？

我见过很多项目的搭建者，明明是新项目，没什么流量，但是却以高并发去设计系统（当然大部分情况下，设计出来的系统并不能抵御高并发），然后以十倍的资源和时间去设计一个巨复杂而且扩展困难的系统。

我见识过为了一张表专门设计了一个增删改查的微服务，也见识过一个新项目需要部分6-7个服务才能跑完一个接口流程。

另外一种是大家喜欢自嘲的码农，这类开发准确说是粘贴工，他们是新手级别的重写哥，只考虑完成当前的功能，通过复制粘贴修改，当需求变更的时候，调整的复杂度也呈几何倍数暴涨。当累计到无法调整的时候，他们就会进化成重写哥，一盘梭哈清空重新再来。

测试

当项目躲过了上面这些大哥，是否就能顺利完成了呢？

测试是在项目过程中非常重要的岗位，也是把控项目质量最后一道关卡。前面那些哥们挖了这么多坑，项目延期咋办。合着一讨论，为了项目能顺利上线，压缩测试时间，什么？测试时间也不够，那我们来全民测试。

很多人觉得测试根本不重要，也是个谁都能做的岗位。和产品经理一样，好的测试门槛非常高。

但实际情况是，大部分测试都是连问题都无法描述清楚的，和大部分产品经理一样，连需求都无法说清楚。有些传统项目连测试都没有，觉得开发出来就不会有bug。

在我职业生涯中，接触过一些测试，在问题描述上反复的沟通，极高的沟通成本让人接近于崩溃。通常他们的描述都是说这里有bug，但却不提供复现步骤，所用的账号环境、截图等，需要反复确认。还有的连需求都搞不清楚，然后把自己认为不合理的地方描述成bug。

大部分测试连验证的测试用户都没办法写出来，比如产品要做一个登录功能，使用手机号登录。他的测试用例永远和产品需求一样，而不是各种验证用的测试用例。

最后连到底怎么算验证通过也不知道，然后就上线了，最后被用户抓到很多问题。

项目经理

项目经理在很多情况下，会由技术经理或者产品经理兼任，我待过的一些规模大的公司的也有专门的项目经理。

项目到这个地步，项目经理会跳出来说，在座的各位都是辣鸡，然后像上面一样细数大家的罪状。但大多数的项目经理只能沦为一个问时间的工具人，他不参与到项目里，只会隔三差五的问好了没。时间上压缩一下，明天上线。他无法知道现在问题到底卡在哪里，然后项目里的所有人都不理他。

当项目有问题的时间，永远是A有问题，B有问题，C有问题，但就没有一个没问题的时候。但却回答不出一个清晰的计划，比如今天团队要完成什么工作，本周有什么工作完成，依赖的其他团队的对接在什么时候等等。

结尾

软件开发过程中的复杂度远远比我上面说的人的原因大很多，比如瀑布式开发和敏捷开发，高效的项目管理工具使用，项目流程优化等等。

在我从业经历中，经历了数不清楚的项目，我们或多或少做过一些上面说到的事情，但我发现好的团队也是磨合出来的，因为每个人的性格、经验、能力都不一样，大家总归会犯错，但互联网的发展速度让团队的磨合时间变短，快速的架构调整让团队丧失了磨合的时间，祸害了一个又一个的项目。

这也是为什么出现了奋斗党和摸鱼派，其实他们本质上是一样的，都是在以工作时长来向外界表达我都这么努力了，肯定不是我的问题。只不过一个是把自己累死，一个把自己耗死（毕竟要等领导下班才能下班）。

或者，大家发现了软件开发过程中的银弹，那么就是996和007。

我是卢灿伟，一个从业13年的技术，曾是一些公司的技术负责人，也是一名全栈开发。目前也承接一些项目开发工作，所以你有兴趣，欢迎洽谈。