6 things to draw when working on big projects
On the occasion of my project to receive the company's "Best Project Of The Year" award, today I would like to exchange some experience and lessons learned during the project. Although the product has not been released yet, at this time, it can be considered as a success because it ensures the determined criteria of completing the job, satisfying the customers, not OT, ensuring that everyone works in the environment. comfortable.
1. Change Request Management is a vital element that decides the success of a project
Today we work less with the Waterfall model, and most work on Agile models, or cross between Waterfall and Agile. Talking about Agile, we cannot forget the principle of number 2
Welcome changing requirements, even late in development. Agile processes harness change for competitive customers.
We always welcome change in specs. However, that does not mean that change is done. Change Request management is an important determinant of the success of the project. Every change of the customer, we should actively discuss to clarify the problem, why so, rather than just follow compliance. The time-consuming changes need to be carefully considered, because not simply effort is more cost, but unforeseen post-production if we rush to follow customers.
Personal experience
There are 3 things we do throughout the project when working with Change Request
- All tickets for change request are gathered under a large ticket to have an overall view and easy statistics estimate time. You may have a different approach, but the principle is how to see these changes as quickly as possible.
- The first attitude to change request, is not "obedient" obedience, but calmly studying, thinking of the biggest possible difficulties to negotiate with guests.
- Absolutely not hurry to do it. Even if the change is reasonable, consider the priority before deciding to do it. And fortunately, there are quite a few changes requests, after 1-2 weeks we have not made it, guests have self-rejected. Imagine how we can do it all the time.
2. Building process is extremely important
Processes are indispensable, especially with large projects with diverse human structures and complex specs. Before the project I started, I had about 1 month to study the plan on the plan and build the process for the whole project.
Ticket management process on Redmine, code review process, deploy process, Q & A process, … until the process of adding a new person to the project is available to ensure everything is operated smoothly.
The plan stage, the process is often overlooked and itself causes incalculable consequences later. We just need to work and think that as soon as possible, while under the management perspective and especially managing large systems, building a new process is really important. Early work sometimes only leads to an early rework, while a good process helps to limit human risks.
People are born no one has no flaws, human work is not always perfect, so the process was born to limit human errors!
I share with you the picture above is our process, Q&A process. You can see that the person directly involved in the Q&A process is Questioner (Dev or QA) and BrSE. But the person who updates the specs is a middleman, Comtor. Why?
Firstly, we always update the specs, to make sure the specs are always up-to-date. There was a project I did, people wade all hundreds of lines of Q&A just to confirm a small specs line. So in this project, we focus on updating the specs to make sure it's always up-to-date and everyone can follow them.
Secondly, we choose a middleman with Q&A process to update the specs. Here is the comtor. This ensures that a third person reading Q&A file also understands what the problem is and when updating, there is an objective view, which makes anyone understand the problem.
There are many other processes in the project, but I personally find it still not really complete and in my career, I will try to learn to improve it.
3. Say no to OT
The 8th principle of Agile's 12 principles addresses this issue
Agile sustainable development promote processes. The sponsors, developers, and users should be able to maintain an indefinitely constant pace pace.
Obviously, we need a comfortable and sustainable working environment for our members, so that they can implement the "resistance period" and not the "OT term". OT causes a lot of bad consequences, affecting the health and spirit of the members. And with the whole project, it is affecting the work performance. Not every OT, overtime is good. Recall how humans struggled to get 8 hours of work a day to rest. Too much work is often not as effective as the amount of time it takes.
So try to find out why we OT.
- Because we estimate wrong, leading to overtime to fix.
- Because we want to show it to customers. Try to make it quick, having Change Request is a quick fix to impress.
- Because our ability is limited, the estimate is quite correct for some people, but sometimes the "weight" team is too unbearable.
- Customers press progress, must finish in a certain time.
There are many OT causes and I list here some of the most common causes in the company.
The cause of subjective numbers 1 and 3 is subjective to us personally. However, the incorrect estimate is fully negotiable with the customer, if we explain to them the problem (for example, my project is difficult to work with 3rd party libraries). Another subjective cause of humanity is that we must correct it. Remember that man-month cannot be substituted for each other, not every poor level member is slow to add people, we need to understand the capacity of the member so that there is a way to divide tasks, training and main thing proper progress.
The number 2 cause is completely coming from our side. Remember that the more you do, the more you have to do, the faster you respond to the Request, the more Change Request you have. Not every change is necessary but every change takes time, so once again, consider this.
The reason number 4 is that in some circumstances can be negotiated, some circumstances are not. Basically, it will depend on the project situation and I personally do not have many comments. However, I am sure that one thing is that OT will only cause fatigue and reduce work performance.
In another subjective perspective, OT belongs to each person's mindset. When a person has OT thoughts, they will prepare OT spirit, leading to neglect during working hours, going to work later because … at any rate, OT. Replicated, OT or not is the mind set of the project. If PM wants OT, the member will not listen. If BrSE likes OT, then at the end of the day, I will force him to do it and then lead to OT. If the member likes OT, during the tea break, Facebook surfing, then going back to OT, the manager is also very tired, …
Therefore, no OT ideology needs to be communicated and smoothed throughout the project. It is possible to create a team that can unite and work effectively.
4. Please manage the database very closely
This is a very technical issue and is often not mentioned when talking on a management level. However, believe me, if you do it well, you will feel very relieved even if you've entrusted your project to more than 40 people at all different levels.
Have you ever encountered the case of 2 people doing 2 different screens, but there are some schools related to each other. Updates on this screen do not see updates on the other screen. Just because of 2 different people and doing with 2 different data in DB.
Or have you ever encountered a person who just deleted or renamed a field in a table related to your screen, then made a die of someone else's screen?
Or a beautiful day you open DB, and you see how strange the school name is, or there are two schools whose names differ only one "s"
All came from the inconsistency of the DB due to loose management. If you work on a small project, you will only see 1.2 people changing the DB so you will find the DB too simple. But with the database of hundreds of tables, what about 3-4 teams managing? Usually, they only care about the functions they do (which, after all, are difficult to catch a whole system of 40 people doing), do not care about what others do. The naming of arbitrary tables lacks consistency or is difficult to understand on the field, making it difficult to develop later.
Therefore, my advice is that there should be one person who understands the whole project specs and manages the whole project DB. BrSE is the most suitable person, but if BrSE does not have a good knowledge of the database, it may be better to assign a leader in charge, with the assurance that this person is a full-time project.
Any system, no matter how big, encapsulates the data in and data out process. Therefore, good database management will greatly reduce errors, especially in business systems.
At my project, BrSE manages the entire DB, every time it deletes it all through BrSE. When deleting a column or changing a table structure, BrSE will determine which effect of that change on the functions and screens will have appropriate edits to each team.
5. The problem of managing people is always very headache
Managing people is a very difficult problem. What's more worrisome is that even if you try to build a good process, if the people in it aren't really "happy", so do you. I focus here on managing relationships, and specifically between Developer and QA.
The first month of my project was in tension, when QA and dev didn't have a common voice. Mostly because people have no experience, the way to exchange is sometimes a bit too harsh or impolite.
Developer thinks that QA tries to dig up their mistakes. QA said that developers do not respect their work. Stress continues when the heads can't find a common voice.
The work of those who have experience in the project is to reconcile, delineate right and wrong. But we need to be flexible and alert, so identifying the last thing we need to do is solve the problem of specs, bugs, not digging into the mistakes of others.
Fortunately, after a long time working together, we no longer have the tension between Dev and QA. Everyone determines the ultimate goal is a successful project with the best quality.
6. You always need superheroes in the project
In section 2, I mentioned the importance of the process. It helps minimize human errors. However, in the end, all products are made up of people, and therefore people need to be very concerned about human factors.
Do not think there is a good process, accompanied by a few big hand-outs that can do a great project without the contribution of the superheroes in the project. Remember the process can be used for many projects, advisor is actually "outsider" of the project. A person who wholeheartedly contributes to your project with great ability is what you need most.
In our project, besides the experienced young members are veteran members, both dev and QA. They play an important role in shaping the project, the direction of implementation for member and support them as fully as possible as well as training when needed. They can also instantly find a critical bug issue to resolve as quickly as possible, or find a solution to a difficult problem and do it right away.
You don't need the whole project of 40 superheroes, it's too wasteful, but some superheroes are enough to build a strong team.