??多问几个为什么：这比如你这个需求背后的目的和价值是什么？做了之后有什么预期的收益，为什么这么做就可以达到这个收益，你可以不直接问业务方，但是你也需要问自己，业务方的这个目标和做这个需求的路径是否可以匹配得上，如果实现路径存在逻辑漏洞或者不是最佳的则这个需求也就没有做的必要性；
??给出替代方案：经过上面的步骤，其实你会发现你已经过滤了一批无效的一句话需求，而有些需求可能是有一定的存在价值，但是可能业务方提到的点并不是有效的方案或者说成本太大的方案，这时你就需要思考替代方案，尽量通过现有方案或者小成本的方式来满足业务方，间接的达到“拒绝”的效果；
??不能直接说不，但可以有条件的说是：当你确定这个需求是 ok 的，但你确实暂时抽不出时间来搞定这个事情的时候，这时关键在于我们不能直接拒绝业务方，长此以往会影响到后续的合作关系，这种情况你可以说：这个需求我接受，但是我可能需要较长一些的缓冲时间或者砍一些需求(部分满足)。又或者必须要按时上的话，不能保证项目的上线后的效果、质量等，让业务方来做部分的取舍
你是否为一个口头需求而忙不迭失的改代码，又因为种种原因，需要改回去？
你是否因为，拿到需求后没有充分理解，制定技术方案，而导致写到一半写不下去？
你是否因为，一千个人，一千零一种代码风格，而导致花大量时间理解业务？
你是否因为。。。。影响开发效率的情况千万种，唯有规范化流程，才是解决问题的正道。
也许不是所有项目都支持“瀑布模型”，但是标准化的流程，绝对通用！！!
怀有感激之情拥抱codereview，新人怕code review就像怕Error一样。某大佬同事说，code review是一种哲学，不仅提升代码质量，也是一次学习的机会。他会不断鞭策你做得更好。
很多新人，抱着去公司去学习的心态进入到一家公司，这样的心态究竟好不好呢？首先，企业肯定是欢迎具有上进行的员工的，但是企业也不是福利机构，招你进来是让你来创造价值，创造利润的。
以前，我们团队内宣扬业务先赢、业务先行，后来发现，业务是先赢了，但是个人的技术成长、沉淀，有些拉跨，那如何完成业务与个人成长双赢呢？
老板们对此也进行过讨论，结论是：团队内的之间的学习交流占比百分之70%，个人积极主动占比30%。当你冷漠的拒绝别人的提问，就是给自己关闭一扇门，每个人主动去帮助身边的人成功，去分享自己学的新技术，你会收获的更多。
你有没有在闲暇时刻主动去汲取一些？对待新技术，你是否依然拥有热情？学后有没有沉淀?是否有做笔记、文档或是博客等形式的输出？
关于思考业务赋能和做技术规划，其实是一个非常值得不断探讨&锻炼过程，建议平时多和老板， 团队内高 P 沟通和交流，他们是过来人比较有经验，可以在思考的深度和格局给出非常多的建议，有的时候这种交流会有一种醍醐灌顶的感觉。
前段时间，阿里并购网易考拉，完成跨境业务电商布局。阿里有一种若隐若现的文化，告诉我，人家有不错的东西直接用就好，网易考拉跨境业务做的好，没必要再去花时间再做一个。
当第一次接触框架时，我就在想这辈子一定要写个牛逼的框架，供世人使用。看着别人用自己的框架，脸上露出满足而又神秘的微微一笑缓缓走过。
很多对技术狂热的朋友，热爱源码，并想做一些研发，造一些轮子，但我们都知道一个成熟的技术需要时间的考验，需要拍坑，要很长的周期才能达到比较好的效果。
无论是缓存，数据库，搜索，消息中间件，等等很多随便列几个，都有一类多套的成熟的解决方案。可以根据不同业务需求选择使用。
如果你一定要做，先问自己几个问题。你要做的是解决什么问题？为什么要做这个（没有可采用的技术吗）？你该怎么做？
①批判性思维到底是什么？批判性思维是指自己在决定要相信什么或者要做什么时所进行的合理和反思性的思考。
②为什么需要批判性思维？为了更好的学习，更加理性客观的去思考问题，解决问题。我们每天都接受外界很多信息，我们对于信息和知识需要对话、互动，通过筛选和甄别形成自己合理的判断。而这个对话、互动、筛选、甄别的过程就是一个批判性思维的过程。
③3W模型。观点的来源是什么（what）？为什么是这样（why）？不是如此又是怎样（how）？
ps：我觉得3W模型，真的太万能了。做任何事我都可以问自己，是什么为什么怎么做。
最后，请不要怀疑，唯一不需要怀疑的就是怀疑一切。①建立目标
如何对事物抽象出具体目标，或是一个完整的任务？
②目标拆解（拆解维度）
象限法则，根据轻重缓急去拆解任务。
根据复杂程度去拆解。
任务拆解的方式千万种，具体业务具体分析，选择一种最好的方案并讨论。
③子项达成决策前充分讨论，决策后坚决执行?。?
????????
如果说五感是人类对世界信息自以为是的初级判断，那么认知则是人类对世界机理自以为是的高级判断。如果类似五感的接收器的改变世界的根本面貌（其实是幻想），那么认知的差别，同样可以让我们生活在不同的精神世界。
眼界决定高度，多看、多想、多保持好奇心、多问几个为什么，久而久之自然就迈上了一个新的台阶。
很多人总是抱怨在自己公司只是写增上改查，没有成长。那为什么同样是CRUD,有人能从小公司走进BAT呢？同样是写if-else，有没有想过如何code更优雅呢？
如果以普通的视角去看，那么螺丝钉那也就只是一颗螺丝钉，但是如果跳脱出目前的视角，站在更高的角度去看，它其实是航母的一部分。你的主管并不是因为他是你的主管所以他就应该你比更高瞻远瞩，而是因为他看问题的高度比你更高、想得更远、做得更深，所以才成为了你的主管。
有意识地超前想一步，多想一点，学习一个技术一个组件，想想为什么要学这个，能解决什么问题。举个例子：学Redis，为什么要学这个？学这个能做什么？如果只是想到缓解数据库压力就太低级了。有人说“键盘敲烂，月薪过万”，没有思考的代码，是危险的。还是要多思考，从宏观角度，提升自我知识体系。
关于提升格局和看待问题高度，推荐两本书《杜月笙传》、《原则》。
我们是技术人，但我们的工作中，代码并不是全部。我们团队可能仅占百分之30
我们有pd需要去了解需求，需要了解需求背景，一个需求开发之前需要交流技术方案
开发过程中，我们需要和相关的同学去沟通，上下游进度不理想我们还要去推动进度
开发完成，我们又要去协作，完成联调，提测。
出现问题，我们又该对外怎么说，对内怎么做？当你发现一个问题，有没有以正确方式去落地？一声不吭闷头干，你会发现干得好没事，干不好惹身骚。（没有团队意识是很可怕的）
无论你身处何处，所为何职，我相信你都不是孤军奋战，团队或有大小。时刻拥有团队意识，owner意识，做一件事情，为大家想一想一定没有坏处。技术能让你走的高，但是综合素养才能让你走得远。
owner意识，时间观念，以终为始，闭环思维，保持敬畏，事不过二，设计优先，善于提问，空杯心态。是否查漏补缺？
关于软技能范围太广了，这块我以沟通交流为主线。推荐《认知心理学》、《传播学概论》
1.需求迭代的同时，兼顾问题的复盘，总结，归纳，团队内分享。避免下次出现相同类似问题。
2.是否由小到大，见微知著。从需求出发，是否理解某一块业务，理顺上下游关系
3.通过一块业务，是否充分理解相关技术框架/基础组建的用法
4.整个项目构建，设计上，有哪些做的不好的地方？能否提出合理的改进意见或者推动改进？
5.团队上：进度安排，沟通协调是否存在不足？
失败的原因千奇百怪，成功者的经历不尽相同。成功者之所以成功，归纳为三点:解决错误，复盘错误，避免错误。【空号 | 文】如果觉得有用，欢迎star和指教
原文地址：https://www.cnblogs.com/JavakongHao/p/11961462.html
