Video game tester jobs online

Day Camp 4 Developers Project Management

Day Camp 4 Developers Project Management

Just over three of weeks ago I attended the third online Day Camp 4 Developers event, which this time focused on the subject of project management. The DC4D events are aimed at filling the "soft skills" gap that software developers can suffer from, and rather than being a "how-to" on project management (arguably there are already plenty of other places you can learn the basics) the six speakers covered a range of topics around the subject - some of which I wouldnt initially have thought of in this context (for example, dealing with difficult people). However as one of the speakers noted, fundamentally project management is as much about people as it is about process, and all of them delivered some interesting insights.

The first talk (which unfortunately I missed the start of through my own disorganisation) by Brian Prince about "Hands-on Agile Practices" covered the practical implementation of Agile process in a lot of detail. Ive never worked with Agile myself, but I have read a bit about it in the past and Brians presentation reminded me of a few Agile concepts that sound like they could be usefully adopted elsewhere. For example: using "yesterdays weather" (i.e. statistically the weather tomorrow is likely to be the same as todays) as a way to plan ahead by considering recent performance; and the guidelines for keeping stand-up meetings concise could also be applied to any sort status meeting (each person covers the three points "what I did yesterday", "what Im doing today and when it will be done", and "what issues I have"). The idea of focusing on "not enough time" rather than "too much to do" also appealed to me.

The next presentation "Dealing with Difficult People" by Elizabeth Naramore turned out to be an expected delight. Starting by asking what makes people you know "difficult" to interact with, she identified four broad types of behaviour:

• "Get it done"-types are focused on getting information and acting on it quickly, so their style is terse and to-the-point,
• "Get it right"-types are focused on detail, so their style is precise, slow and deliberate,
• "Get along"-types are focused on making sure others are happy, so their style is touchy-feely and often sugar-coated, and
  
• "Get a pat on the back"-types are focused on getting their efforts recognised by others, so their style is more "person-oriented".

The labels are instantly memorable and straight away Im sure we can all think of people that we know who fit these categories (as well as ourselves of course). Elizabeth was at pains to point out that most people are a mixture of two or more, and that none of them are bad (except when someone is operating at an extreme all of the time). The important point is that they affect how people communicate, so if you can recognise and adapt to other peoples styles, and learn to listen to them, then youll stand a better chance of reducing your difficult interactions.

Rob Allen was next up with "Getting A Website Out Of The Door" (subtitled "Managing a website project"), and covered the process used at Big Room Internet for specing, developing and delivering website projects for external clients. Rob included a lot of detail on each part of the process, what can go wrong, and how they aim to manage and reduce the risks of that happening. One specific aspect that I found interesting was the change control procedure, which is used for all change requests from their clients regardless of the size of the change, essentially:

• Write down the request
• Understand the impact
• Decide whether to do it
• Do the work!

I think that the second point here is key: you need to understand what the impact will be, and how much work its really going to be (Im sure weve all agreed at one or another to make "trivial" changes to code which have turned out in practice to be far more work than anyone first imagined). A more general point that Rob made was the importance of clear communication, particularly in emails (which should have a subject line, summary, action and deadline).

Rob was followed by Keith Casey talking about how "Project Management is More Than Todo Lists". One of the interesting aspects of Keiths talk was that he brought an open source perspective to the subject. In open source projects the contributors are unpaid and so understanding how their motivations differ from doing work paid work is important for the projects to successful: as Keith said early on in his talk, in this case "its about people".

He argued that people managing open source projects should pay attention to the uppermost levels of Maslows Hierarchy of Needs (where the individual focuses on "esteem" and "self-actualisation"), but there was also a lot of practical advice: for example, having regular and predictable releases; ensuring that bugs and feature requests are prioritised regularly, and that developements should be driven input and involvement by the community. I particularly liked the practical suggestion that frequently asked questions can be used to identify areas of friction that need to be simplified or clarified. He also recommended Karl Fogels book "Producing Open Source Software", which looks like it would be a good read.

Thursday Brams presentation "Project Management for Freelancers" was another change of direction (and certainly the subtitle "How Freelancers Can Use Project Management to Make Clients Happier than Theyve Ever Been Before" didnt lack ambition). She suggested that for freelancers, project management is at least in part about helping clients to recognise quality work - after all theyre not experts in coding (thats why they hired you), so inevitably they have an issue with knowing "what does quality look like?". (If youve ever paid for a service such as car servicing or plumbing then Im sure you can relate to this.) So arguably one function of project management is to provide a way to communicate the quality of your work. The key message that I took away from Thursdays talk was that "what makes people happy is seeing progress on their projects". Again I felt this was an idea that I could use in my (non-freelancer) work environment.

The last session of the day was Paul M. Jones talking about "Estimating and Expectations". Essentially we (i.e. everyone) are terrible at making estimates, as illustrated by his "laws of scheduling and estimates":

• Jones Law: "if you plan for the worst, then all surprises are good surprises"
• Hofstadters Law: "it always takes longer than you expect - even when you take Hofstadters Law into account"
• Brooks Law: "adding more people to a late software project will make it even later"
  

However there are various strategies and methods we can use to try and make our estimates better: for example, using historical data and doing some design work up front can both provide valuable knowledge for improved estimates. In this context Paul also had my favourite quote of the day: "Its not enough to be smart; you actually have to know things" (something that I think a lot of genuinely clever people can often forget, especially when they move into a domain thats new to them).

It felt like Paul packed an immense amount of material into this talk, covering a wide range of different areas and offering a lot of practical advice drawn from various sources (Steve McConnells Code Complete, Fred Brooks The Mythical Man Month and Tom DeMarco and Timothy Listers Peopleware: Productive Projects & Teams were all mentioned) both for estimation techniques and for expectation management - where ultimately communication and trust are key (a message that seemed to be repeated throughout the day).

In spite of a few minor technical issues (the organisers had opted to use a new service called Fuzemeeting, which I guess was still ironing out some wrinkles), overall everything ran smoothly, and at the end I felt Id got some useful ideas that I feel I can apply in my own working life - in the end surely thats the whole idea. It was definitely worth a few hours of my weekend, and Im looking forward to being able to see some of the talks again when the videocasts become available. In the meantime if any of this sounds interesting to you then Id recommend checking out the DC4D website and watching out for the next event!
download more info