△ホリスは、人々を符号化するためのユニークなクエストを持って△
これはホリスセクションで 251ピアンオリジナル共有
著者リットルのホリス
出典リットルホリス（ID：hollischuang）
最近、全国のホームオフィスモデルを始め、今、このパターンは、会社の事務所への可能なリターンを持っているために、少なくとも月まで、長期間にわたって継続されます表示されます。
実際には、プログラマは、実際には何も以上のコードのみをノックするどのようなオフィスでは大きな違いではありません。
時間はすぐに、ホームオフィスから始まる、常に何かを言いたかったが、紙にペンを入れたことがなかったし、今以上の二週間、書き込み何かにそれの時間を持って、二週間は、2つの点がある私に最大の感じを与えました。
まず、以前よりもミーティング
自宅で仕事をした後、電話会議、ビデオ会議、音声会議、すべての種類など、毎日。
同社のオフィスは、時間では、このようなニーズアセスメント、設計レビュー会議としてのみいくつかのイベントは、唯一のプロジェクトチームモーニング会などがあり、同様に必要です。
しかし、自宅で仕事をした後、次の日のための私の議題である、各種会議に参加するために、毎日引かれます。
 9:00から20:00の朝は、会合している、そして時には会議の一致がたくさんあります。
この時間は自宅で仕事の利益を反映して、私は同時に複数の会議に参加することができます。ネイルは、ビデオ会議を開き、携帯電話の電話会議を開きます。私は小麦の禁止を入れたとき、私は必要ありません。
例えば、いくつかの会議は、私が最終的な結果を得るために、議論の下に、利害関係者を一緒に引っ張るためだけの責任だけど、私はうまく外にメッセージを送りました。これは、私はちょうどライン上で聞く、話す必要はありません。
その後、私はちょうどうまくオープン小麦話すのこの部分を議論する時間が必要な会議などの会議、わずかな関連する技術的ソリューションの私のレビューの一部などであってもよい、多数あります。
それは会社での会議であれば、それは同時には不可能である、それは代わりに大幅会議の効率を向上させます。
第二には、カットが需要Genghenを切断しました
私は自宅から持ってきたの変化を期待していなかった、知っていること、良いか悪いかではありません：私はカットデマンドカットGenghenに持っています！
相信很多一线开发人员都和我一样，每天都会接到各种各样的需求，而给我们提需求的人也是形形色色。
而各种奇葩需求更是让我们哭笑不得，但是大多数程序员在做过一些心理斗争之后都会想办法解决这个需求。
其实，所有需求都需要解决的，这没错，但是我还是给大家提一个建议：先用嘴解决需求，不行的话再用代码解决。
在家办公之后的这两周，我负责的一个项目目前正处于联调阶段，但是这个阶段还是会接到一些需求，这其中有些是产品经理提出来的需求变更、新增需求等，还有些是合作方技术提出来的有些技术需求，如要求接口同步、要求多一次系统交互、甚至要求ERROR_CODE的格式等等。
因为我负责的这个项目是个新产品上线，完全初期，要尽快上线接收用户检验，没必要一开始就搞的特别复杂。所以对于这些需求，目前的状态是能砍则砍，不能砍的先用最简单的方式先上去。
所以这两周来，我越发的发现我砍需求砍的原来越狠了，甚至有一次，我团队的另外一个同学问我一个单据的状态问题，我随口问了下问这个干什么，他说产品经理让他实现个小需求。
我了解下来之后，就拉他和产品经理一起开了个电话会议，然后动之以情，晓之以理，把"不合理"的地方都砍了，把"能优化"的也都优化了。
本来需要2-3个系统合作才能实现的一个查询功能，经过调整之后，变成只需要查询一个系统就可以实现。这既减少了系统交互、降低了风险，又减少了用户的理解成本。何乐而不为呢？
我始终认为，啥需求都接的程序员，一定不是个好程序员！但有些需求，总要有人先站出来砍！就算最后没砍掉，我认为也是有好处的：
1、可以让我们理解这个需求背后的东西。之所以最终没砍掉，肯定是有很多原因在的，只有在讨论的过程中我们才能更多的理解这些背后的原因。否则最后可能只是你毫不情愿的实现了一个你认为"垃圾"的功能，但是实际上可能这个需求背后有一些你不理解的原因。如合规风险、法务风险等等。
2、表达一个我们的态度。我觉得，作为一个程序员，态度还是很重要的。比如有些恶心的或者需求，我们可以"迫于压力"去实现，但是我们还是有权利表达我们"不认可"的态度。而且这个表达的过程，也是你树立话语权的一个过程。
我砍需求有很多考虑，但是减少工作量绝对不是最重要的。最近几天砍需求，我大概总结了一下，用到的很简单的几个架构设计原则：
1、Keep It Simple ， Stupid
2、Open/Closed Principle
3、Single Responsibility Principle
4、Minimize Coupling
5、Avoid Premature Optimization
简单点，无论是系统功能，还是系统代码，最怕的就是复杂。越复杂的功能用户越不喜欢，所以，如果一个功能很复杂，那大概率是个垃圾功能。
系统实现上面也是，如果一个功能，实现起来很复杂，那大概率会存在很多问题。而解决这些问题最好的办法就是提前减少复杂度。
除此之外，要明确知道系统边界以及系统关系，实现一个功能可能有100种方式，但是到底由谁来实现比较合适？如何才能降低系统间的耦合度？如何实现才有更强的可扩展性和可维护性？这些都是要考量的。
还有比较重要的一点，在初期，不要过早的做所谓的优化。记住：Done is Better than Perfect，
我们日常要接的需求中，有一些是业务需求，还有一些是技术需求。那么，有什么好的原则或者办法可以参考呢？到底哪些能砍，哪些不能砍？到底应该怎么砍呢？
关于这些问题，我后面会写一篇详细的方法论，结合我工作中的例子，论如何砍需求。大家如果有更好的建议，或者对这个话题感兴趣，可以给我留言，欢迎探讨！
愿这个世界没有需求变更！~
关于作者：Hollis，一个对Coding有着独特追求的人，现任阿里巴巴技术专家，个人技术博主，技术文章全网阅读量数千万，《程序员的三门课》联合作者。
- MORE | 更多精彩文章 -
如果你喜欢本文,
请长按二维码，关注 Hollis.
转发至朋友圈，是对我最大的支持。
好文章，我在看❤️
