Sharing this book helps too!
Most project courses assign each team a supervisor, i.e. an instructor who oversees the team's progress, provides expert advice on the problem domain, and possibly takes part in grading the team. Project teams can meet their supervisors regularly for consultations. The supervisor plays a critical role in your project; not only is he meant to be your best source of advice and guidance, but he may also be able to influence your grade. Therefore, it is important that you know how to work with your supervisor in an optimal manner.
Most importantly, your supervisor is not an all-knowing oracle. While even the most experienced educators have differing views about various aspects of software engineering, the supervisor you get could be an inexperienced junior faculty member or a senior student. Therefore, do not expect your supervisor to have a sure-fire solution to all your problems. Even when you get an answer from him, do not take it as the best possible answer one can get.
When faced with alternative ways of doing something, do not ask the supervisor to make the choice. Instead, ask what are the pros and cons of each alternative. You can make your final decision based on your own opinions, your supervisor's opinions, experimentation results (i.e. you can try out each alternative on a small scale to see which one is better), and other information you can gather on the subject.
When you telephone the supervisor, you are effectively saying "I don't care what you are doing now. Drop it and attend to me right now!". When you send an email or a text message to him instead, you are saying, "Attend to me when you have time". Use the former option sparingly.
If you want to meet the supervisor, make a prior appointment or follow pre-determined consultation hours. Most supervisors are too nice to turn you away if you come unannounced, but they will not be happy about the disruption.
When you make an appointment with your supervisor, PLEASE be there on time. Plan to meet together 10 minutes before the appointment time and go to the supervisor's office as a team, rather than each member joining the meeting one at a time.
You do not get credit for spending time in the supervisor's office or writing the most number of emails to the supervisor. While a supervisor might offer to meet you 'as many times as you want' and ask you to write 'as many emails as you want', it is your responsibility to limit both to reasonable levels. It shows forethought, care, and professionalism on your part. It makes the supervisor's life easier as having to switch many times between tasks could heavily disrupt his own work schedule.
Do your homework before you make contact with the supervisor. Discuss the questions with your team first. Try to find answers on your own before you approach the supervisor. Prepare your questions before you meet the supervisor. Better yet, email him the questions in advance. This helps to clear your own mind about the issue you want to discuss. Consolidate your questions into a single email rather than firing off an email the moment you encounter a problem. Keep meetings short: get in, do your business, get out. Do not start team discussions in the middle of a meeting with the supervisor.
Avoid involving the supervisor in the things you should do yourselves, such as debugging. At the same time, make sure you maintain an adequate level of interaction with the supervisor, even if he does not initiate contact himself. You do not want to be referred to as "oh, the team that never came to see me" when he sits down for grading.
Most supervisors cannot speed-read. Do not send him a document five minutes before a meeting and then expect feedback during the meeting. Be patient if you do not get immediate answers to your questions. Sometimes, supervisors have to consult other supervisors, a senior professor, or other resources before answering.
Some supervisors keep the supervisor-team relationship informal and relaxed while others want to maintain a certain level of formality. It is the supervisor's choice (or may be dictated by the course structure). You should not try to force a different level of formality into the relationship. For example, do not try to 'lighten the mood' by inserting jokes in to a discussion with the supervisor if the supervisor is clearly trying to emulate a formal project discussion.
It is important that the supervisor is in touch with all the important developments in your project. For example you can give your supervisor access to your project discussion forum, code versioning system, mailing group, etc. Copying every internal project-related email to the supervisor is a definite 'no no'; sending a weekly summary or a progress report (even if he does not ask for such) is a better alternative.
If your team is facing difficulties, let the supervisor know; pretending otherwise will prevent the supervisor from helping you on time.
On a related note, think twice before you bypass your own supervisor and approaching someone above him, e.g. approach the course instructor instead of talking to the teaching assistant supervising your team. Doing so can sour the supervisor-team relationship.
If the project did not go well, resist the temptation to blame the supervisor. While the supervisor gave all advice in good faith, it was not his responsibility to make the project a success. Besides, blaming the supervisor for a failed project can hurt your grade further, in more ways than I care to mention here.
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
|
|
Sharing this book helps too! |
---| This page is from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---