In software companies, as in many corporations, the only thing that is not changed is “change” itself. A change in team membership and structure is usually called “re-organization”, or “re-org”. In sports, we call it “转会季节”.
At the beginning of this class, 5 teams were formed after a short period of chaos and excitement. Many students joined various teams based on incomplete info, a hutch, or just the need to have a team. Now after the alpha stage, I bet everyone has a clear and deep understanding of what does it mean to ship a software – your team’s software. There could be several reactions:
a) This project is great, I’ll keep working on it in Beta stage, and after that!
b) This project is ok, I’ve done my part. I want to try a different project to practice my other skills, can I?
c) I have different opinions about this project, and we can’t convince each other, so can we go different ways, and still be friends?
d) I don’t care what kind of team I’m in…
e) We love this project, but we need more hands to help out!
f) …
So it seems we need an re-org after Alpha. In my past ASE class with USTC students, I had tried the “re-org” and some people didn’t like it – mostly because they don’t like surprises. To reduce the amount of surprises, I’m telling you this news ahead of time, so that you can prepare for it.
1) When will this re-org happen? Right after Alpha release
2) What is going to happen exactly? Each team will decide one or two team members leaving the team. Each team must take at least one new member from other teams.
3) What’s the process to decide? The PM/leader of the team will decide which process the team will take (e.g. dictatorship, consulting, vote, consensus, random number, etc), and the PM will report to TA and me their names.
4) Where will these “free members” go? they can pick their next team (got to be a different team), they can negotiate with other teams. Of course, if your team needs more people, it’s a good time to recruit talented classmates.
5) What if no team wants a “free member”? if all negotiations fail to work, by default, the free members will go to the next team in order (e.g. from team1, go to team 2; 2 to 3, … 5 to 1). The receiving teams have to accept these members.
6) Of course, the departing team members need to have good documentation of his/her work (remember to write comments in your code!), and the new member needs to learn quickly how to work on a “legacy system”, this is part of skills in Software Engineering,
Some people might feel this is a bit chaotic, but great people can thrive on chaos, so enjoy the re-org!
