all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Orange
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
On a GoToMeeting session with Alan. Our original plan for the day was - Review and then focus on internal processes and how to apply it as we move forward. We have tons of future internal projects. Let's practice there because we can manage and control some of the aspects of those projects. ---------------------------------------------------- New brainstorming dealing with internal projects: Q-1. What do we want to be done when working on internal projects? A-1. Water, slush, to ice analogy. Start with a dream or a concept, talk about it, record some notes about it, let it sit and simmer. As it sits, keep adding new aspects, expansions, ideas, cautions, etc. We've gained tons by letting things sit for a bit and get some feedback from others and see how they inter-relate to other projects and/or needs. Record the notes and ideas as you go. We are pretty good up to this point (currently with our normal flow). Form here, we start getting into a lack of a real process. We have tons of ideas, post-it notes, and other brainstorming notes and documents but we can't really hand it off to another developer to run with it. It then falls on me, to point people to where to get the project info. Lots of time in training, showing the vision, and orienting people as to what is needed. The next step would be to start standardizing things and bring it all together. It might be nice to then start putting them (the notes and such) together in a common place where everybody could get at them. That is what we developed elements of time for, and it is only partially being used. Tons of potential, but no real set flow. Then once we decide to roll with it, we would come up with naming conventions, and start putting the project together and implementing it. This would be specs, functionality, requirements, and even wish list items. We could then beat that up a bit and refine it. This works best if we do the beat-up drill with the person who is going to be doing the work on the project. This helps educate them and gets their input. Can we break it? What about this and that? Do you understand this or that? What about the UI (user interface or user experience)? Is it easy to use? Does it do what we want and need it to do? What other places does it touch? etc. It would be nice to have a starting place or template that we ran every bigger project through. This could have a bunch of questions that we could answer so that we at least think about and/or consider. Things such as: general usage, common holes, pit falls, we've been burned here before (warnings), trickle-down effect (cause and effect relationships), one-to-many, one-to-one, corp-specific, automated, short cuts, custom (naming, sorting, placement, aliases, rules, settings), permissions, special settings (corp, location, user), and the list goes on. This template document could be in our style vs. a hard fast technical doc. Keep it somewhat loose but still get the major points across. Then make sure that the document is tied to the project. Update it as needed. This could be full replacements (overwrite the older doc with the new ones) and/or incremental pushes (new doc with new changes - leave the old ones in place). Once we feel we have most of the things listed out and we have an actual plan, we would start working on the project using the project specs and virtual to do list as the guide. We would then keep coming back to the project specs doc and even adding to it as we go (this is kinda like internal change orders). Keep documenting the new ideas and possible enhancements. Internally, we may allow more freedom with internal change orders. Treat it like an idea farm and be willing to do some harvesting. If the project is more of an external project, we really need to deal with the change orders on a more rigid level. We may also want to do different rounds on projects. If a huge round is still needed. Start a new future project where we can start dumping ideas and start the process over again. Iterations and multiple rounds are great. Maybe start using a key word like "round 2 of elements of time" in your notes so that we could find things again. Just an idea. Pretend that the project is built and/or ready to be released (even in phases is ok). When ready, we do code sign-off, we merge, and we push the project live. We then finish up the documentation, help files, and let others know about it (think education and maintenance). We may need to do new videos, updates, and let any marketing avenues know about the new updates, tools, and features. This last part has been lacking due to crazy pressure to keep running as fast as possible. As an idea, in order to get the developers (including ourselves) to finish the project, what if we scheduled the full and up and down trip (pretend it is a hike to a mountain peak - plan for both up and down the hike). This means planning, research, concepting, coding, sign-off, merging, deploying, documentation, training, and even maintenance stuff. That would be really cool. Especially if we had funds allocated for all of the pieces and the developers only got paid based off of what they have finished and/or completed. Treat it kinda like how Morning Star used to use the system as the bad guy in order to get title work, paper work, payments, etc. If we tie it back to pay, we may have more success with it. We may even want to put things on both the developers and the leads (some one in admin) so that we get everything done. We could even use some bonuses in order to help keep things going. Make a plan and/or a budget to get the whole project done - both the up and the down part of the trip. Other things we would like to take into consideration are: Timelines, wages, budgets, bonuses, reviews, communications. Do we care about speed, durability, a combo of both, or what else are we looking for? How do we manage this? We do want speed but we also want stable and well fitting pieces. More focus on well fitting pieces and planning for years vs. quick and unstable code. We can do combos of sprints, marathons, or just steady walks. We may need to mix and blend based on the project and the pressure we are getting. Ideally we would consider the impact of the project, the stability, what else it touches, expectations, budgets, available persons and talents (assets), etc. Other random questions: What about risk management? Are there certain things that need to be done in sequence? How much freedom do we give the developers in the process? Is this a copy and paste job? If yes, from where? Was it cleaned up? Did the developer and lead go through the standard adilas developer's guide (general process for all developers)? Who is being assigned to what? Are there back-up persons for the different pieces? Who is in charge of what? What happens if other projects come up or someone has to leave to do something else (sick, leave, quit, health issues, school, etc.)? How is it funded? Is the project fully funded (start to end) or will it be on the fly or hourly funding? How do we manage the balance between payment and deliverables including final stage stuff like education and maintenance stuff? Alan is going to do some reading on project management stuff and what other pieces and processes we may want to look into. Alan was talking about a thing called "the spiral method" where you have small goals and build things out to that point. You then circle back around and advance to the next goal, whatever that is. It could be as simple as let's do some research on such and such and that is the project. Or it could be let's plan out project x or y or it could be something like let's actually do project xyz. Basically, tons of mini goals and then work towards a bigger end goal. Instead of trying to tackle the whole mother load, you tackle some little pieces and keep chipping away at the whole. Bite size pieces. |