Thursday, 25 April 2013
Monday, 22 April 2013
How can I motivate people to play with programming tech?
Thursday, 11 April 2013
Must project managers be technically savvy?
On the question 'must project managers be technically savvy' posed by Luc Richard (link), my answer is a fairly obvious 'yes', however I will qualify it by saying that the project manager does not need to be the technical architect, indeed I judge that the two roles should be completely separate in teams of greater than 3 people. Richard makes some strong claims:
On estimating
"In order to create a project plan, you must be able to estimate how much effort is required to complete all of the required tasks. Needless to say, you can't estimate effort unless you truly understand what's involved in designing and implementing those features."On scheduling:
"A project manager must be able to schedule activities in a logical sequence."Assuming you are starting from the conventional project management perspective you will find that the questions raised by Richard are, as it happens (coincidence?), the defining areas of the PMBOK. But a careful reading of Richard's responses reveals something else, an underlying assumption that the project manager does everything.
In response to Richard's assertion that "To be an effective project manager, you must be capable of designing and developing the solution yourself." I claim to be an effective project manager you must instead develop skills and sensitivities for getting the best out of heterogeneous, multitalented, multidisciplinary, mixed gender, culture, age, experience teams!
Unless of course you're working on a team of 1! (or 2, or 3)
As an antidote to too much PMBOK and too much Technology I strongly recommend having the following on your bookshelf:
Beck, K. (2000) Extreme Programming Explained : embrace change, Reading, MA, Addison-Wesley.
Brooks Jr., F. P. (1995 (1987)) The Mythical Man-Month : Essays on Software Engineering, Reading, Mass., Addison-Wesley Pub. Co.
Cockburn, A. (2002) Agile Software Development, Indianapolis, IN, USA, Pearson.
Cohn, M. (2006) Agile Estimating and Planning, Upper Saddle River, NJ, Pearson Education.
Demarco, T. & Lister, T. (1999) Peopleware: productive projects and teams, New York, NY, Dorset House Publishing.
Kidder, T. (1981) The Soul of a New Machine, New York, NY., Little, Brown and Company. Hachette Book Group.
Mcconnell, S. (1996) Rapid development: taming wild software schedules, Microsoft Press.
Poppendieck, M. & Poppendieck, T. (2003) Lean Software Development: An Agile Toolkit Upper Saddle River, NJ, USA, Addison Wesley.
Monday, 8 April 2013
User experience or engagement?
There is a rather subtle aspect of technology design that is often neglected, that is 'how design works within a whole context'. This idea is rather like thinking in terms of a design ecology rather than a design 'thing'. The truly difficult issue to address is 'the audience' or users, actual people.
Engagement is a long term value. A good user experience doesn't necessarily equate with engagement with a technology system. The basic unit of analysis for user experience is probably a strand of end-to-end goal driven interaction, whereas engagement looks at involvement with the technology system over days and weeks, ideally years. Engagement also considers performance within the technology ecosystem. While engagement isn't the same as 'product as a service', many successful technology engagement experiences are with long duration technology systems that operate as services.
I was thinking about examples of good and not so good engagement experiences. A good user experience may well be successfully paying my bin collection fee online or reviewing my phone bill online. I complete the tasks in less than 10 minutes, I feel confident the process is safe, I get feedback on progress and successful completion. But I'm not engaged with either of those experiences, I don't return out of curiosity or to tweak my preferences or add things. A good engagement experience might be my preferred use os Chrome for logging into 10+ different webmail accounts, my tweaking of the Chrome bookmarks or launch page. Engagement is evident in the whole experience of using my iPod, taking photos, curating some of my photos on Instagram, linking some of them to my Facebook, and the quick seamless experience of my Apps, particularly the email client on that device.
Jim Kalbach expands on his version of this discussion on his Wordpress blog (link).
Engagement is a long term value. A good user experience doesn't necessarily equate with engagement with a technology system. The basic unit of analysis for user experience is probably a strand of end-to-end goal driven interaction, whereas engagement looks at involvement with the technology system over days and weeks, ideally years. Engagement also considers performance within the technology ecosystem. While engagement isn't the same as 'product as a service', many successful technology engagement experiences are with long duration technology systems that operate as services.
I was thinking about examples of good and not so good engagement experiences. A good user experience may well be successfully paying my bin collection fee online or reviewing my phone bill online. I complete the tasks in less than 10 minutes, I feel confident the process is safe, I get feedback on progress and successful completion. But I'm not engaged with either of those experiences, I don't return out of curiosity or to tweak my preferences or add things. A good engagement experience might be my preferred use os Chrome for logging into 10+ different webmail accounts, my tweaking of the Chrome bookmarks or launch page. Engagement is evident in the whole experience of using my iPod, taking photos, curating some of my photos on Instagram, linking some of them to my Facebook, and the quick seamless experience of my Apps, particularly the email client on that device.
Jim Kalbach expands on his version of this discussion on his Wordpress blog (link).
Subscribe to:
Posts (Atom)