Software development management during the entrepreneurial period (2)

Link to software development management during the entrepreneurial period (1) Software team Technical Director

The decision makers may have some knowledge about software development. They will take it for granted that the software development process is "simple": Find a technical leader from the market and then build a development team, the other thing is to release the demand. You can develop the software for me.This is a very embarrassing situation for the technical director, that is, it is necessary to explain to the leaders some problems they simply do not understand. It also needs to take on a huge amount of pressure. The demand for "inherent deficiency" is also a big challenge, because the entrepreneurial team does not have a molding and operational process that can be referenced by the technical director. This requires the technical director to have a very good market foresight and a very good architecture scalability.

During the start-up period, the Team knows what to do and how to do it. However, once refined, there will be many and complex problems. To streamline and clarify these business processes, Technical Directors are also required to provide guidance. The lack of guidance on technical implementation will be much lower than expected, and the software system may have serious scalability limitations.

Another hot issue for technical directors is that it is the impact of management methods in the upper-layer non-software development field. Enlightened bosses do not pay too much attention to the management methods of technical directors. However, when managing a new army, their combat power may be relatively low. After a while, the upper layer may be dissatisfied, they may be more confident in managing software development.At this time, it is best for the Technical Director not to care too much. We do not reject a new management method, but the technical director needs to closely observe this management method, which can absorb some good methods, however, negative effects must also be detected in a timely manner. This is not something you can find in a day or two, but the sooner the better. Establish your own right to speak on management as soon as possible, otherwise the technical director will have to bear the evaluation of "limited capabilities.

The other thing is that the technical director cannot control the demand, that is, the demand for continuous expansion and refinement. The demand issued by the boss is only directional and general. Even if you have made a detailed document, he just glanced at it because he doesn't understand it. Secondly, he has no energy or patience. Again, he thinks this should be well handled by the technical director. The best way for the boss is to let him see the original software!

Because it is a start-up phase, many things are not authenticated. With the appearance of a prototype, more and more times will be accumulated over the expected time, which will make the upper layer feel uneasy and even more terrible, in order to achieve the ultimate goal, the decision-making layer is implementing There are endless debates on the "path", which leads to a sharp shift in demand and a considerable waste of time. In this way, the enterprise has to streamline the function set within the specified period, but it may still cause delays.

Driven by this sense of urgency, software management is a challenge, because we may ignore the "quality" of the software, even if it passes through the difficulties temporarily, there may be a lot of maintenance work in the future. Even many designs need to be retried. Therefore, there is a long way to go to the technical supervisor's work.

Requirement document

Requirement documents are a challenge for the start-up stage. The ever-changing requirements and non-refined requirements make it impossible for you to have a complete and relatively stable requirement document version in the development phase. It would be quite painful to write a requirement document according to a standard document. In this case, it is best not to use formalWordTo store such document formats, we need a tool that can flexibly organize content and change content.UMLModeling tools,MindmanagerAnd so on.

The Requirement documents need to be organized by most developers at the same time. The Technical Director will divide the requirements into several major sections, which are dominated by Different developers. But there is another frustrating thing that these developers doProgramNo problem, no problem in design, no problem in understanding what you want to do, and no problem in helping you standardize business processes. The problem is that they may not be good at expressing them! Due to the lack of professionalism and the excuse of time constraints, it is very likely that the required documents they write are virtually empty. Even so, some of them still want to get this exercise. At this time, the most important product is not written in their documents, but the actual requirements are learned through communication.

It is necessary for the technical director to elaborate on the core business process in detail to make it clear and clear. Other simple requirements or relatively independent subsidiary requirements can be tolerated without strict document constraints, there is no way or effort to make the entire requirement document detailed.

Software Design

In the startup phase, takeISOTo standardize the existing software development process, just as joking. However80-20The principle is still very thorough. We must trust the capabilities of everyone in the development team, and we must give them full permission to give them full play. Everyone in the team needs to stand alone. We assume that everyone has the ability to handle small issues encountered during development. Because the tasks we allocate are allocated in a large part as needed. Everyone is the design leader andCode. Under such circumstances, it is not easy to find a balance between regulation and freedom. Here we will apply it.80-20Principles:

Our focus20%The requirement design20%Is the core of the business, and the rest80%Is secondary or secondary. We are not just20%To design, but100%Design the requirements, but focus on the core business.

For each design20%Time to write documents80%.

The content of the document is the content required by the normative document20%, Other80%No.

In addition, you must accept the following facts:

I,Yes, only20%Is excellent,80%There are "defects. These flawed designs mainly refer:

1,Lack of scalability

2,The design is too good, and some may not be used at all

3,The implementation method is not optimal.

Ii. 80%The design can work, and even those with "defects" can work, they may be directly applied to coding! Only20%The design must be re-designed.

III,Design documents do not provide guidance on coding, but can only guide the designer to coding. There are the following reasons:

1,Incomplete design documents

2,The division of duties in the kaibi team is not so detailed, and there is no dedicated coding staff or dedicated design staff.

3,The different design ideas and design habits of different team members make it difficult for them to accept others' designs. This is caused by the lack of new teams.

The Technical Director must strictly control the design process, but do not constrain the form, as long as you fully understand the designer's ideas, otherwise the future will continue to suffer. Design outputs have many defects, but they are tolerable. The Technical Director can let the architect design everything and then write the code, so that the design will be integrated. The responsibilities are clear, but the following problems may occur:

I,We have a few special forces rather than a large number of regular troops.

II,What do architects do when designing?

III,Everyone has an expressive desire, and they can do things, but they may not experience your rich experience. They also hope to grow in this environment, which is also the best growth environment.

IV,We have little time!

V,We hope that everyone in the team can lead a unit.

VI,We need to understand each other, take the essence of it, go to its dregs, and finally form our consensus.

Technical Directors can skillfully solve defective designs through team meetings, but not all problems will satisfy you. As long as they are not essentially problems, they can continue. There are many "defects" that are formed by personal habits, experiences, and personalities. These "defects" must be "inclusive" in the entrepreneurial stage.

To be continued ......