You are an anonymous user who can't edit RoboWiki.
Log in if you already have an account. If you would like to become an editor for the wiki, request an account.
Log in if you already have an account. If you would like to become an editor for the wiki, request an account.
Implementation of New Management
Revision as of 19:20, 31 January 2017 by Jane (talk | contribs) (→Implementation of New Management)
Implementation of New Management
• Implementation of basecamp:
- o Programmers have been using it for the best year
- ♣ Original goal was who was working on what, what does it take to get that done, it then developed into an archive for past codes
- ♣ Natalie Luong put all of the build blog docs on Google Drive
- • Build blog is an area that students can use to check info of they weren’t here
- • We are planning to not completely abandon the build blog this year because it would be a craze
- • Archive our engineering docs into our Google Drive
- ♣ We want to use basecamp as away to monitor our subteams to ensure that they achieve their goals
- • We should put to-do lists in our basecamp
- • Put engineering notes into basecamp
- • Rationale: Reasoning why we made an engineering decision
- • Potentially act as our build blog not now, but one day
- o All communication outlets (build blog, discord, etc) should be documented somewhere
- ♣ Maybe some find way to make build blog links easier
- o There is a video (Google Drive) folder that is shared w/all mentors and officers
- o Email seems to be the most effective because motivation issues w/students
- ♣ Checklists must be created in order to maintain motivation
• Tips on how to make people be held accountable
- o Charts seem to be effective (but do what’s best for you [i.e. spreadsheet w/each subteams name is labeled])
- o Need to list what needs to be completed, when it needs to be completed, and what it means to be completed
- ♣ There should be checkpoints every period to measure how close people are to your definition completion
- o Subteam leaders need to “pull” their subgroup, but the subteam needs to push themselves
- ♣ May break subteams into 2-3 subgroups giving them a role in responsibility, which gives them the desire to “push” and be held accountable
- • Similar to elected officers to appointed officers
- • May get too complicated
- • May want to only divide up small tasks
- o This would cause a “fail fast, fail cheaply” mindset
- ♣ We may want to convey the importance of members doing their general assignment more effectively
- • Our 3 subleaders will be gone next semester, so we need to start make our students understand their responsibility
- • Gives a purpose to students, may give them a drive to work
- ♣ Don’t know our rookies well enough to know if their want to maintain their responsibility
- • May want to deal small tasks to rookies to determine their affinity
- ♣ May break subteams into 2-3 subgroups giving them a role in responsibility, which gives them the desire to “push” and be held accountable
• Expectations from
- o Taking lots of notes (each group should have an engineering notebook filled in w/dates, times, etc)
- ♣ Write what works, what doesn’t
- ♣ May include pictures (i.e. shooter designs)
- ♣ This is basically the build blog
- • Build blogs can’t be tweaked, so engineering notebooks can be used to add new colors, new notes to older designs
- • For videos in build blog, we need to label what each video contains, how it is used, and what the results were
- ♣ We should buckle down, and get things working now
- o Subteams need to incorporate measurements in docs sent to programmers to make it easier for them to code