Wisp
Details
Role: Producer Members: 11 Duration: In Progress School year: 4 Engine: Maya Platform: PC Wisp is a hybrid real-time ray tracing renderer built for the demands of 3D artists. Wisp integrates with Maya to give the user a real-time in-viewport representation of the final product.
This product will help speed up the workflow of 3D artists by allowing them to see a closer representation what their model would look like after the path traced rendering. This will ensure they have to render less often and will therefore speed up their workflow. For the development of this product we will be using the new graphics cards from NVidias RTX series. |
|
Responsibilities
- Teaching the basics of project management to prepare a student to take over as producer for the rest of the year.
- Explaining how to structure a backlog, implement it into Jira and how to maintain it correctly.
- Showing the importance of a risk list, setting it up with the team and maintaining it.
- Providing structure for the team meetings and explaining best and worst practices.
- Helping the team set up their team structure and pipelines, and explaining how to iterate upon these throughout the year.
- Providing assistance in maintaining and improving their day-to-day scrum tasks and progress.
- Providing a wire-frame and feedback on how to present your product to stakeholders.
- Organizing team bonding events to create a pleasant working environment and a stronger team.
- Providing a template for the risk list, setting it up with the team, and explaining how this can be maintained throughout the year.
Lessons learned
Mentoring
For this product the team consists of only programmers, and since I had to leave them after 1 block (2 months), one of these programmers also had to take on the role of producer afterwards. Therefore my main task this block was to teach this person the basics, provide him with advise and explain methodologies they can use. Part of this was also teaching this person the mindset he'd need to have towards the product. For example during the concepting phase, letting the team think of the coolest tech but letting him think about scope, and realistic expectations for those features. This also included making sure he was aware what the target audience wants, and what our place in the market is. Therefore a competitor analysis and target audience research were conducted, to help steer decisions towards how they will affect our users.
This team was of course different from previous projects, with different people and a different product. The goal was therefore not to make the team do things exactly the way I did them during previous projects, but to explain them my reasoning behind decisions, and let them draw their own conclusions. Examples of previous work were shown and I provided an explanation of why they were set up the way they are, allowing them to pick the aspects they wanted to use while interpreting them in a way that made sense to this specific project.
Working with a team of one discipline
The first time working with a team that only has one specific discipline provided better insight of how this discipline prefers to work and how they communicate best. Due to observations during previous projects there was a base understanding of this, however working closely with this specific team of programmers provided a deeper understanding on how to approach them during various situations. To give an example from personal observations, I noticed a team of programmers works best with a clear given set of goals and deadlines. Whereas the design teams I've worked with in the past often preferred to discuss tasks upfront to have a say in their creation, and have them time-boxed. There are of course many more differences, and this can also differ per programmer team based on the project, company and individuals within a team.
Structuring meetings
Since the team was lacking any meeting structure. The meetings took very long, went off topic and had unclear goals. Therefore a meeting agenda was set up which kept track of all meetings, and the link to their minutes. To structure them further a template was also set up which was to be used during every meeting. This template included all important aspects of a (in my opinion) well organised meeting:
Mentoring
For this product the team consists of only programmers, and since I had to leave them after 1 block (2 months), one of these programmers also had to take on the role of producer afterwards. Therefore my main task this block was to teach this person the basics, provide him with advise and explain methodologies they can use. Part of this was also teaching this person the mindset he'd need to have towards the product. For example during the concepting phase, letting the team think of the coolest tech but letting him think about scope, and realistic expectations for those features. This also included making sure he was aware what the target audience wants, and what our place in the market is. Therefore a competitor analysis and target audience research were conducted, to help steer decisions towards how they will affect our users.
This team was of course different from previous projects, with different people and a different product. The goal was therefore not to make the team do things exactly the way I did them during previous projects, but to explain them my reasoning behind decisions, and let them draw their own conclusions. Examples of previous work were shown and I provided an explanation of why they were set up the way they are, allowing them to pick the aspects they wanted to use while interpreting them in a way that made sense to this specific project.
Working with a team of one discipline
The first time working with a team that only has one specific discipline provided better insight of how this discipline prefers to work and how they communicate best. Due to observations during previous projects there was a base understanding of this, however working closely with this specific team of programmers provided a deeper understanding on how to approach them during various situations. To give an example from personal observations, I noticed a team of programmers works best with a clear given set of goals and deadlines. Whereas the design teams I've worked with in the past often preferred to discuss tasks upfront to have a say in their creation, and have them time-boxed. There are of course many more differences, and this can also differ per programmer team based on the project, company and individuals within a team.
Structuring meetings
Since the team was lacking any meeting structure. The meetings took very long, went off topic and had unclear goals. Therefore a meeting agenda was set up which kept track of all meetings, and the link to their minutes. To structure them further a template was also set up which was to be used during every meeting. This template included all important aspects of a (in my opinion) well organised meeting:
- Meeting goal
- Participants
- Time-frame (How long the meeting may take, is expected to take, and actually took)
- Agenda (usually checked by all participants upfront to allow feedback and new points)
- Meeting notes (All that was said during the meeting (preferably in bullet points for better readability)
- Action points (What actions will need to be taken and by whom)