如果需求是个人的话，估计要被程序员虐上千百遍。从产品经理与程序员的相爱相杀，可以看得出需求在程序员心中有着举足轻重的作用。到底如何正确看待需求，一定程度上也决定了你程序员生涯的高度。
题图 from unsplash
初中级程序员更容易关注技术点，这是由其时间阶段性决定的。刚步入职场，迫切的需要技术的提升来证明自己的价值，而需求往往处于被动接受，能按时编码任务就算交差，无所谓理解深刻不深刻。有一种情况，初中级的小伙伴们会跳出来指出需求问题，那就是需求变动，导致不得不返工重做时，才会重新审视需求。这是种后置的做法，前期错误的需求会随着软件过程的前行逐步被放大，后期要花数倍的时间来修复这些问题。
由于程序员自身的成长背景和知识结构，前期还没有办法更深切的关注需求，主要还是认识不足，而技能提升是一个更加显性的过程。随着工作年限的增加。程序员小伙伴们就不得不重新审视需求，因为你要做核心设计、做架构设计，必须要以需求为前提，理清需求之后，后期的详细设计、核心流程设计、存储设计、架构设计等才有所依附，否则都是空中楼阁。
如果你愿意重视需求，这个无关经验，即便是刚入门，一样可以理解的很透彻。业务本身就是这个世界运转的方式，接触多了，能打通不少盲点，反过来更能促进技术的精进。
当然也有例外，有一些朋友就是不喜欢业务，就是喜欢钻研技术，这是一个自欺欺人掩耳盗铃的做法，技术难道用在非业务的地方？
也有小伙伴会说我做基础开发的，不了解需求也没事。中间件是为什么系统服务？适用于什么场景下？其实这也是一种业务需求，没有场景问题需要解决，中间件也没有存在的意义，纯粹是为了技术耍酷，公司也不会允许。
需求有产品经理呢，程序员跟着瞎搀和什么？
需求不会说话，需求借助于产品经理的大脑与程序员进行沟通，所以需求的完整性与否准确度如何，有赖于产品经理对需求的把握程度。没有人希望需求会变，产品经理也不例外。但市场在变，业务在变，只有满足业务的需要，才能灵活的应对市场的变化，抱着过期的需求，做着白日梦，技术用武之地何在？放博物馆展览吗？
有时候产品经理被程序员吓怕了，经常会问这个需求能不能做？往常我给产品经理小伙伴的答复是：如果逻辑上说得通，在可控的成本范围内，实现上基本没有问题。
当然强势的产品经理会说，实现细节我不管，我只想知道下周一能不能上线？产品经理主导产品迭代的节奏，那程序员是不是没有话语权？程序员如果对需求掌握的深刻，可以与产品经理一同来探讨需求，把不合理的讨论清楚，在迭代开发过程中尽量的减少返工，提高效率。产品经理提出的不合理需求，程序员有底气与之PK吗？
产品经理与程序员处于一种撕逼对立的状态，无疑对产品开发来讲是一种内耗。特别在创业公司中，更是致命的，因为大家的目标不一致，力不往一处使，团队价值产出会大打折扣。还是要尽量相爱，而不是相杀，别动不动要搞出来祭天的活动。
有些招聘需求上明确写着有相关经验者优先，这个经验就是行业业务经验，特别是一些业务门槛稍高的行业，比如银行、制药、制造等等。行业经验就是你做技术开发的附加价值，有些人沉浸在一个行业里做很多年，既可以做成技术专家，也可以做成业务专家。路只会越走越宽，而不会被技术局限死。同样的业务，可以用很多种技术来实现。
程序员能忽悠一个不懂技术的产品，但忽悠不了一个技术出身的产品，技术出身的产品创业者，要远比分别招一个产品和程序来做更高效。技术与业务相互促进，不可偏颇其一，即便你也要做技术专家，也不可忽略业务的价值。
成长，最好的办法就是找一群志同道合的人同行，因此我特地建立了一个知识星球，来，说出你的困惑，我来帮你拆解，助你拨开迷雾，看清方向，共同成长。
