Do not discuss methods with your customers

I have such experience. When you negotiate with your customer with your proposal and want to win this project with super-powerful technology, it is often not as expected. It is true that when you develop a large number of concepts, such as object-oriented design, design patterns, AOP, agility, or SOA, the customer's negotiating representatives will often admire you for your conversation, even dizzy, but customers can always grasp their final bottom line and "stick to Qingshan ". After all, to negotiate a project, in addition to the company's strength, project experience, and the relationship between business personnel, the customer is most concerned with your WBS and quotations, and the project or product delivery time.

Therefore, when talking about the method, you can be admired by the customer, but you cannot be recognized by the customer.

So in the project development process? No matter what the project is, the final success of the project should be achieved, and the judgment criteria should be the customer. Therefore, communication with customers is crucial during project development. Even so, the degree of customer participation directly limits the project's success or failure. Agile Software Development places customers first and emphasizes communication with customers. By discussing with on-site customers or productowner, user stories (product backlog or feature) are scheduled ), and their priority. Then, through the iteration (Sprint) method, we regularly deliver products that can work for the customer to determine whether the developer's implementation meets the customer's needs. Undoubtedly, this is one of the factors for the success of agile software development.

However, in real projects, it is difficult to find the ideal customers mentioned in the method. If the customer is a field expert, we may need to save a lot of things. However, this kind of things is inevitable. In addition, it is difficult to exclude that the field experts will interfere with project development. We cannot protect our project members and will not be disturbed by such strong customers. If the customer is only familiar with the business needs in the traditional field, unfortunately, we have to take responsibility for guiding the customer. Most importantly, we need to develop a set of communication standards recognized by both parties, so as to reduce the large-scale emergence of ambiguity. If a project has more than one customer, you will not be faced with problems, but a disaster that destroys the earth! Where can we talk about software development when customers cannot unify their own needs? The project manager will be drowned in the customer's Wenshan huihai. Besides, there are endless demand changes waiting for you.

Most commonly, our customers often do not understand software technologies. At this time, are you willing to talk to them about the specific methods? In turn, are customers willing to listen to your preaching?

Error! Error! Error! Customers do not want to become software experts after a project, nor do they want to pile up meaningless terms in their minds. What agility, what field-driven models, and what architecture design are all about! What we need is visible and tangible products! It is the kind of windwos interface that allows you to see the results through mouse operations. That is the magic. This is simple for customers.

Ron Jeffries mentioned in a discussion group about agility that our customers should not care about agile development. Our customers are only responsible for their business, but not limited to software development. They should be interested in:
-- Get the software you really need;
-- Software that can work reliably;
-- Software delivered as soon as possible;
-- Minimize the impact on them;
-- Software runs in the easiest and most natural way.

In fact, communication with customers is a collision between technology and technology. Field technologies are not available to developers, but they must be followed. I used to develop a CIMS system for an enterprise that produces liquid crystal display. I am so afraid of many concepts related to the production line. We strongly need developers who are proficient in the field to succeed in this project. However, in most projects, we cannot have such luck.

Why agile? It is not because we can be agile, but because customers require us to be agile. It is hard to imagine that customers can still endure those documents while a project is closed for several months. I have experienced such a closed-doors car building project, and the result failed. In fact, not agility is better than other project development methods, but we must grasp the agile spirit, because we attach importance to communication with customers, because our team is self-organized, it is because we can deliver products that can work within the scheduled time.

Isn't that what the customer wants to see? However, we must never stop talking about the technology. Customers do not want to hear about methods or technologies. Whether or not the project uses agility is irrelevant to him. Even if the project uses waterfall software development, the customer will approve the success. Therefore, no matter what method, as long as the product can be delivered regularly with high quality, it is a good method. The only difference is that successful agile implementation may help eliminate customers' misunderstandings and increase their confidence.

My grandmother often taught me: "Do not be a talking giant, a dwarf of action !" Sincerely speaking!