今天项目演示时老板说ui设计的图不够科技感，UI小姐姐此时心里有很多个问号，居然说我设计的图不够科技感，毕竟我也是参考了市面上相关软件，死过无数个脑细胞，呕心沥血设计完成的，怎么一句就否定了呢？？？，我#$%&*@%^&&*%!￠℃￥ξοωχυλβιμητσ。。。（非骂人的想法，是我们喜乐忧愁的一种表现，就是一些正常的不开心的想法啦），我做的图又白费了，心中在滴血，心中默念求求老板放过我吧，科技感到底是个啥？能不能给我说得清楚一点呢？给我个方向呀老板，最最好给我个参考案例，UI小姐姐心中波涛汹涌，心情顿时不美丽了。

UI小姐姐马上询问老板能否给个案例呀，老板会后找了相关截图发在群里，项目经理提醒UI，老板发了案例，UI满心欢喜的打开老板发的图片一看，心中顿时凉了一大截，发的啥玩意？有啥参考的价值，和我们系统又不一样，产品方向也不一样，顿时感觉无语了，经过60秒的无语后，心中又出现了#$%&*@%^&&*%!￠℃￥ξοωχυλβιμητσ。。。（非骂人的想法，是我们喜乐忧愁的一种表现，就是一些正常的不开心的想法啦）的想法。

紧接着项目经理马上来到UI小姐姐工位旁边询问参考的怎么样，小姐姐回复了一句：没什么可参考的。项目经理顿时有点无语了，只能耐心和UI小姐姐讲解，我们从老板发的文件能够参考哪些方面，对我们项目有什么改进价值等。最后UI小姐姐只能温柔且带着小脾气说：你们说怎么改就这么改，听你们的意见就行了，我的想法最终还不是要按照你们的要求改。

这里项目经理询问UI小姐姐的想法后，结果UI小姐姐说了没有任何参考价值，相当于直接堵死了下一步工作的内容。作为项目经理，老板的需求肯定有求必达,满足不了，创造条件也要满足需求。很多时候我们作为项目经理或者产品负责人，在分配任务后，开发人员直接回复不知道怎么搞，不知道，没搞过，其实是很无语的。

通过这个事情我从两个方面进行剖析:

（1）从老板的角度来说。老板作为公司的掌舵人，更多的是把控方向，处理宏观的问题，不可能事无巨细地处理细枝末节的事情，不然的话老板就成了打工人，当处理琐碎的问题势必分散老板的注意力，相信这样的老板也不会做的很大，所以我们不可能要求老板很细致的给我们讲解哪里要怎么改，要怎么处理；

（2）从开发者（项目管理者）角度。一般情况是，客户是上帝，老板或者客户有需求就要尽最大的努力满足。虽说是要满足客户需求，但仍然是有策略的，客户的需求不一定是100%满足的，需求受可行性、成本等方面的影响。另一个方案。作为实施需求的开发者，在细节上其实是最清楚，需要结合自己的特长敏锐发现问题，这也是对自己能力的一个提升。

如何处理需求问题？

需求是有理解成本，当我们拿到需求（老板的建议也属于需求）时，需求方会进行讲解，可能需求方觉得讲解很详细了，但开发人员任然可能出现理解偏差，这时需要开发人员总结需求方的要求，对需求进行复述，确保能够准确的理解需求，然后结合需求形成方案，最后确定方案，进行实施。针对前边的场景，老板提了意见，作为开发人员我们需要有敏锐的洞察力，从需求者角度思考为什么会出现这种问题，而不是觉的老板在挑刺，提意见的人也是一种优点，思维是很可贵的，至少他对该问题还是进行了思考，能够对解决的问题查漏补缺，而不是人云亦云。

洞察需求就需要我们有丰富的经验，尤其是刚毕业的应届生是非常缺乏的，这就需要我们在一次次的项目中锻炼，从而不断提升自己解决需求，解决问题的能力。另一个方面，可能有些人会觉得，老板的一个建议是不是细致一点更好呢？这里其实存在两个问题（1）需求已经被详细地讲解，我们很难让需求方按照我们的理解去讲解，这就需要我们做功课，去理解。（2）可能需求方暂时也没有更好的想法，但就是觉得不满意。综合这两个问题，我们需要有做功课，形成方案，然后在进行研讨，不然需求就变得很虚幻，无法推进。

先假定需求是能够被满足的会更好。

我们需要先假定能够满足 ，然后我们从可行性、成本角度进行分析，判断该需求是否可行，不可行的原因是什么，会存在什么问题，然后从成本的角度给出解决方案，最终让需求方定夺。这样再确定需求是否被满足会有更好的说服力，而不仅仅是直白回复不能做，做不了。