认识达内从这里开始

对于一些互联网公司和开发公司来说，最容易见到的就是设计师和程序员之间的掐架了，当然了一些其他的需求部门也是容易互相掐架的。而造成这个问题的最主要的原因就是因为不了解对方的工作而造成的一种认知上的误差。

今天，我们就通过案例分析来了解和学习一下，为什么说一个简单的需求功能对于程序员来说就需要很长时间来调试完成，下面我们就开始今天的主要内容吧。

提需求要有节奏感

不要误会，这个节奏感不是啪啪啪的节奏感，而是说你提的需求，要跟着项目的版本周期走。一般一个不是太拖沓的互联网产品，每个版本会经过功能开发、单元测试、集成测试、beta验证、上线几个阶段，我们分别来看一下。

功能开发阶段，简直是程序员的美好时光。下午懒散的阳光打在脸上，泡一杯浓香的卡布奇诺加一点点糖，戴上女朋友送的Beats大耳机循环一首轻音乐，手指在机械键盘上跳来跳去，噼里啪啦的，就像脑海中忽闪忽闪的灵感，根本停不下来，对对，就是这样的感觉。

这期间程序员要么做产品经理提的需求，要么闷头做一些技术需求。这是产品经理提需求的最佳时期，程序员刚刚结束了上一个版本紧张的发布期，急需要一些新鲜的需求来压压惊。技术需求是一些性能优化、代码重构之类的事情，这个虽然是程序员自己给自己提的需求，但是你一定要给他时间去做，不然程序员每天总觉得自己写的代码乱糟糟的，没有安全感。

单元测试是一个功能模块的需求做完之后，提给测试同学去找bug。集成测试时所有模块的需求都单元测试完成之后，整体来一轮测试。这时候程序员天天在改bug，你奇思妙想来一个新需求，他可能要象征性的反抗一下，但是大多数会乖乖去做。

到了beta和发布阶段，大家都绷紧了神经，天天盯着用户反馈和线上的各种指标。这时候你突然被一块石头砸中，有了一个绝妙的需求，请hold一下，一定要hold住，因为你提任何需求都是会拉仇恨的。

先自己尝试评估一下需求难度

这个就有一点技术含量了。有些需求天生是很难的，比如智能推荐、智能识别、搜索引擎这种，需要很强的技术能力。还有些需求，需要前后端联调，后端开接口，商量协议，这些时间算上去总时间要翻倍。除了这些，剩下的就是相对的了，取决于是否有现成的轮子。程序员常说，「不要重复发明轮子」，就是说如果有现成的代码，就直接用不要自己再花时间写了。现成轮子可以来自开源社区、自己项目的积累、还有系统平台提供的支持。如果某个需求有现成轮子可用，那它的难度应该至少要减半。

你想知道开源社区都是有哪些轮子，可以平时多看一些别人整理的技术博客，你可能并不需要知道里面技术上是如何实现的，你只需要记下，这个功能是有轮子可以用的，就够了。你想知道自己项目积累了哪些轮子，去问你们的开发吧，找他们抽支烟、吃个饭，很容易就套出来了。有些项目比较成熟，像推送、埋点上报、自动更新这些都有轮子可以用，但一些年轻的项目则不然，建立这一套东西也要花不少时间。你想知道系统平台提供了哪些轮子，就买一本介绍你们产品平台的技术书，比如《疯狂Android讲义》、《iOSProgramming》，大体翻一下就行了，主要是了解一下这个平台到底可以做哪些事情。

没有轮子可以用的需求怎么评估呢?少侠，你眼光不错哦，每天进来看看，你就知道答案啦。

下点功夫做准备

这是个普遍的道理，你让别人给你办事，吩咐半天讲不清楚，别人肯定不耐烦。如果你的需求是抄的别人的，可以拿别人做好的效果演示一下，这是最直接了当的。你的需求是业界首创的，可以简单画个流程图，如果这时候你能用上一两个技术上的术语，程序员肯定觉得你碉堡了。需求讲清楚了也要顺便让人理解为什么。这时候不要留情，把程序员带到你的产品世界里，用你丰富的经验打败他，他就会乖乖的跟你走了。

还有一点很重要，产品经理要给开发协调一些其他资源，像设计、测试这些，如果能提前准备好，那么即使是beta甚至上线阶段加需求，程序员也会十分感动然后再拒绝你的。

好了，关于程序员的开发和功能调试等问题我们今天就给大家简单分享到这里了，如果大家依然对软件开发等技术感兴趣的话，可以通过运城达内开设的软件开发课程系统化的学习。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益！