Meditation-Windows Phone Software Development Beta edition

More than three months have passed. Our software development has gone through Alpha, beta, and beta2 versions, and will be released by the end of this month. After the alpha version, the team members will join in, in the beta version, our software design for beta2 is basically different from that for alpha version. The workload is much larger than the alpha version. the enthusiasm of the team members is also one after another, and the design draft has changed a lot ...... Looking back, it really deserves a lot of reflection.

............

............

............

If we try again, will we do better than now? If we continue to improve, what other breakthroughs will we make? If?

Next I will look back at our software development and improvement processes from these aspects.

The specific implementation and ideas of our software have been clearly written in the previous blog. I will not elaborate on them here.

Http://www.cnblogs.com/OMG-Team/archive/2011/11/26/2264704.html

1. Software assumptions and plans

It can be said that there must be an outline for everything. The outline can ensure that we are correctly following the plan. In beta, we continue to clarify the core of our Conference Assistant: help those attending the meeting efficiently and conveniently attend the meeting, listen to the talk, and record their favorite papers and meetings. To display the meeting schedule more quickly, we imagine two layers: the first layer is the session and the following talk, and the second layer is the talk detail interface, which then supports session, add a button for talk and set an alarm. Then, to implement our powerful functions, we choose to add the author list indexed by the author, and click the author list to go to the author's detailed interface, add a map, and add a notepad, add keyword search, add meeting settings, and add other information provided by the organizer. In fact, we only assume a lot of results to fulfill this idea. This will certainly be useful, and that will certainly be useful. The more feature we think, the better.

What is the more feature, the more powerful? Is this true?

Although we have done a user survey, we are not very satisfied with the Survey results. We have no good means to understand the user's pain and listen to their voices, because real users are our mentors and we are afraid to delay their time, the user survey is not very good, in addition to how to efficiently display agenda, users' pain points in meetings are not accurate. Based on current user feedback, in addition to displaying agenda and other information provided by users (hotels, venues, etc.), we found that other feature is not very prominent, or it is similar for users.

Another point is that our design lacks user stickiness. It is possible that this software user will not be used once, because the software is not social and is individual, there is no user communication scenario.

According to real user feedback, many participants will recommend this meeting during the meeting. The meeting will tell you what papers they have read or what papers they have written, they will also share their experiences and even their contact information.

Therefore, if we redo it, in addition to displaying agenda, we want to have multiple tags. If we feel like, interesting, read, or want to read, or anyone else who recommends them can be classified. Once labeled, we can communicate with each other through these labeled papers or meetings. It can achieve near-field communication or communicate with the surrounding servers, so that we can meet the diversified needs of users, as well as the needs for fast communication between users, and even such a scenario, the two mobile phones can communicate with each other as if they were shaking hands.

2. Personnel Management allocation and implementation

We have 5 + 1 software projects, one of which is temporarily deployed.CodeI am not very familiar with it, so I chose to assign a relatively independent task to him, while the other five code capabilities differ greatly. It can be said that one of them has strong code capabilities, the Code style is also very good, but this person has his own characteristics, his desire for anything is not very strong, and relatively independent, so it is difficult to change his ideas or motivate him to do things, the mental state is not very good during normal meetings. From then on, we can see that he is not very fond of this task. The Code capabilities of the other four people are average, and they are just getting started with C #. In alpha, a very bad phenomenon is that the individual is very powerful and basically writes all the code. The Code contribution rate of others is very low. In order to eliminate this phenomenon and ensure the overall code quality, I decided to allocate almost all the tasks in the early stage. The powerful person in the Code is responsible for building the underlying code, others are responsible for other modules that do not involve Architectural Code, and ensure the code allocation of each person. Once the code of others is completed, you can focus on integration and framework expansion.

Facts have proved that this method is quite good, and it indeed guarantees the overall good code style and quality. However, problems have also emerged one after another. We have not divided tasks into very detailed tasks and have no detailed time, is a module, a module is assigned to each of them, so the progress of each person is not guaranteed, difficult to quantify, so it is difficult to estimate their work.

We thought about it again and found that if we continue to take a step and quantify the modular work of everyone, especially the big bones of the underlying framework, the efficiency should be higher.

As a PM, I also considered that our team members do not have strong overall code capabilities, so I have very intensive time node scheduling. for a total of two weeks of tasks, I have basically completed it in the first week, although we didn't finish the week at the time, at least two weeks have been guaranteed. A lot of time is reserved for us to ensure our work progress.

This is quite good. Therefore, with everyone's enthusiasm, we put the main task ahead and compress the time to effectively ensure our development progress.

3. Code Quality

Although our team has a person with good code quality, but he can never replace all of us. Exception Handling is the most obvious, and many of us are unaware of it. What should we do if code exceptions occur? What if the resolution fails? However, after subsequent bug fixes and the code of test is robust.

Code quality is actually supervised by tester. It may be because our tester acted as Dev in the early stage. tester did not do well in the later stage. In many cases, it is always urged by PM, sometimes it is a series of reminders. Maybe I didn't mobilize their enthusiasm very much, or when the project reaches a later stage, people's enthusiasm decreases, leading to a decline in combat capability.

In this regard, PM should strengthen tester's combat capabilities and mobilize their enthusiasm, such as chatting or material rewards, and supervise tester to have a standard and strict detection standard.

4. team cooperation and efficiency

After the alpha version of the Team Cooperation training, our overall cooperation is still quite good. If there is any problem, we did report the PM in real time, but the efficiency is still a little lacking, the main factor is whether our code implementation capabilities are insufficient. In many cases, we have some ideas, but limited to code implementation, sometimes we have to compromise or compromise. However, for the first time, I believe that our code capabilities will become stronger and more efficient in the future.

5. PM coordination

In this software project, to be honest, PM has done a lot of work, both as a traditional PM role and as a Dev job. Is this a good PM?

In fact, this PM is not good.

In fact, PM does not write some blogs every day, so it is enough to supervise the progress of the team members. It is not that you think that the code writing by PM is awesome. It is more motivating for the team members.

In fact, the core of PM is the idea, the communication, the prevention of micro-dujian, the progress, the direction of the team, and the coordination of leadership and user needs. In deciding what to do next? Are you sure you want to go? It is to observe the combat power of the team members, to cheer them up from time to time, to chat with them, to see their problems, to see their needs, and to solve them immediately.

However, this PM is at best a hard task, that is, a hard task of encouraging the machine. PM uses his own time and enthusiasm to encourage everyone. In fact, such encouragement is not persistent and is short-lived.

It turns out that the same is true. Now I am working hard, and with my heart, their passion is not very well mobilized, and even the current players are sometimes motionless.

If you start again, PM will choose to do a good job of user investigation, provide more concise design, make decisive decisions, and strengthen the influence and appeal of PM.

Analyze the characteristics of each team member, and clear and communicate with each team member.

6. Summary

In fact, our software is not a complete software. It is a new application built on the academic search platform. It is not independent and many ideas are under discussion, this may also be the reason why our team members are not very enthusiastic in the later stages. Another reason is that although our software users are very clear about the use of the crowd, we still face such a problem, to get support and promotion for the host.

Although the road is a bit tangled, but since it is pm, I will come up and talk for our efforts, make more efforts for our software launch, more promotion, let the team members see that even if the road ahead is a little difficult, we will continue firmly.