tool doc - Schedule, scope and completing goals

Schedule, scope and completing goals for tool work

1. All work needs to be justified

   1. Make sure you understand what the end goals are.

      1. This sounds pretty obvious but I have made assumptions about what my end goals were and then realized after i thought i was done that I had missed some targets and spent time on unnecessary work. 

   2. Make a Technical Design Document for all proposed work and present it to people to be critiqued.

      1. My initial ideas of my end goals can be wrong. I have found it incredibly helpful to write out my ideas of what needs to be done including my end goals and why each step is important. This slowly evolves into a Technical Design Doc (TDD).

         1. Once I think I have wrapped my brain around what needs to be done I present it to users, other tech artists and engineers for review. This is an incredibly important part of the process and the feedback I have received has helped create a better product

         2. Once the TDD is done i use it to start writing code based on the specifics of what is called out in the TDD. I often start by writing functions or classes named after tasks in the TDD

   3. Schedule in a meaningful way.

      1. Write out delivery milestone based on the TDD

      2. Write out what task needs to be done in order to reach your milestones.

         1. schedule time based on tasks that needs to be done to reach your milestones

            1. If you fail to meet anything on your schedule you need to adjust immediately and inform people your schedule is off and as such completion may be off.

   4. Do not "over engineer". Is all the work you do necessary to accomplish your end goals?

      1. From personal experience I have spent more time than necessary on implementing "systems" that may not have been needed. As technical people we can have romantic ideas about what can be done versus what needs to be done. The desire to over engineer can be strong so I make sure I stay focused on task needs to be done to reach my milestones defined in the TDD.

      2. Any systems that fall outside of needed milestones are noted but not implemented. In other words I write things so that I can add functionality later and will call that out but if something is not needed to accomplish a task I do not spend time on it.

   5. Get as close as you can to the end goals as soon as possible.

      1. If i am writing a tool to export data from Maya that will be used in-game, my first milestone is going to be proving that I can do that. Most functionality for that milestone will be roughed out and just placeholder to get something in-game. All future milestones need to maintain that in-game functionality. If at any point my a task breaks getting stuff in the game the milestone it is part of is not complete until it is addressed.

   6. Check back in with your users and others to make sure you are on track.

      1. It is easy to get lost in implementation. Make sure you continue the initial consulting steps you took to develop the TDD throughout development. Talk to the same people who gave you feedback on the TDD to make sure you are on track.