[读]3. Simplify essential complexity; diminish accidental complexity

http://architect.97things.oreilly.com/wiki/index.php/Chances_are_your_biggest_problem_isn't_technical

Chances are your biggest problem isn't technical

 

Right now someone's running a failing project to build a payroll system. Probably more than one someone. Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We've all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn't up the the task? Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about what it takes to help make those people successful. Equally, there's a good chance that there's someone who you think is "just not doing it right" and is undermining the project. In these cases, the technology you need to solve your problem is very old and well established indeed, in fact it's possibly the most important technical innovation in the history of humanity.

What you need is a conversation.

Mere familiarity with the conversation as a technology isn't enough.  Learning to treat people with respect, and learning give them the benefit of the doubt, is one of the core skills that turn a smart architect into one an effective architect. There's lots more to it than this, but a couple small tips can significantly increase your conversational effectiveness:

1) Approach these events as conversations -- not as confrontations. If you assume the best about people and treat this as a way to ask questions you definitely learn more, and you are less likely to put people on the defensive.  
2) Approach these conversations only after you've got your attitude right. If you're angry, frustrated, annoyed, or otherwise flustered its very likely that the other person will interpret you non-verbals as indicating that you're on the attack.  
3) Use these as opportunities to set mutually agreed upon goals. Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people's participation. Explain that some people are more introverted and need longer silences before they jump into a conversation, and ask if they will help you out by waiting 5 seconds before jumping in.

If you start with a shared purpose, treat people "problems" as an opportunity to learn, and manage your own emotions, you'll not only become more effective, you'll also discover that you learn something every time.

By Mark Ramm This work is licensed under a Creative Commons Attribution 3

 本条提出了软件项目成功与否的关键：人而不是技术。技术无好坏之分，只有是否适合，一项眼下最火的技术，明天可能就会不再合适，即使这项技术很强大，也要看怎么用。说道怎么用，就要提到用它的人了，所以能够让开发项目的人员能够按照正确的方法、使用正确的技术，则此项目必能成功。

 

本条没有说明如何合适使用的技术和方法，而是针对如果帮助团队成员正确的做事——交流，这是最重要的手段，有效沟通才能够让团队目标明确、步调一致，也就是齐心协力！作为架构师，在交流时要注意3点：避免冲突，一旦有人产生防备心态，就很难有效沟通了；为此在沟通前首先要摆正自己的心态；最后，明确沟通的目的是为了达成共识，最好让所有人都能参与到交流中，尤其需要鼓励那些比较内向、不善于表达的成员。

 

最后，对于架构师来说，交流也是一个机会，一个学习的机会。