Caring for (and exploiting) non-technical types
•Download as PPT, PDF•
0 likes•235 views
Presented at Barcamp Saskatoon 2010. Tips for software developers and testers to take advantage of the things non-technical colleagues can do for them, to make better products and happier work environments.
![Who am I? ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Viewers also liked
Similar to Caring for (and exploiting) non-technical types
Similar to Caring for (and exploiting) non-technical types (20)
Recently uploaded
Recently uploaded (20)
Caring for (and exploiting) non-technical types
- 1. Caring for (and exploiting) your non-tech types Kari Halsted @kayayarai
- 5. First
- 6. First
- 13. * n o t m y m o m
- 29. What are the worst things about non-techs?
- 36. What are the best things about non-techs?
- 42. A word about diversity
- 43. D&C
- 45. All this to say … … and back to my point.
- 46. Things non-techs can do for you
Editor's Notes
- Make your life better: Reduce your workload; get rid of “menial” tasks; give you time to work on stuff you do like; make your products better. My experience, YMMV, heavily influenced by software dev. Not meant to be divisive, or pidgeonhole people, but to get us all thinking about diversity, less binary. And often, we non-techs tend to ask a lot of you techies, so this pres should give you some ideas of stuff you can get us to do for you.
- Tech vs. non-tech is not either/or.
- It’s a fuzzy, mushy spectrum. These are examples, not strict categories, mushy, with flexibility. You may recognize your peers or yourself in one or several places along the spectrum. But for the purpose of this, we’ll start at the traditionally untechie end, and meander toward technical.
- Lawyer I think we can all agree that of all the people we encounter during our days, lawyers are the least technical. – source: http://kitsunenoir.com/blogimages//lawyer.jpg
- HR Manager
- Sales guy source: http://www.thinkflood.com/blog/images/CrazySalesguy.jpg Okay, we’re getting a little more technical. These guys at least know a thing or two about your product, maybe have even used it. But they’re still slightly less technical than …
- Interpretive dancer source: http://mysticmedusa.com/wp-content/uploads/2009/06/504x_ballet061609.jpg
- Graphic designer source: http://www.graphicdesignbasics.com/uploadedfiles/2009/07/photoshop-class.jpg
- Tester source: http://images.shine.com/Up/arunavedited128581578717862450.jpg
- My mom: ource: http://www.bestlaw.com/wp-content/uploads/2010/01/Francis_4589_A.jpg
- UX professional: source: http://www.sophisticatededge.com/assets/images/Careers/Business%20101/business-casual-conference.jpg
- Tech Writer Here’s somebody with “technical” right in their job title, but alas, also “writer”
- Product Manager – this is Todd Jackson, product manager for Gmail and Buzz Source: http://www.wired.com/images_blogs/underwire/2010/03/google_f.jpg
- Wil Wheaton source: http://www.readthesmiths.com/articles/Images/Tech/Geeks/wheaton.jpg
- xkcd reader – source http://imgs.xkcd.com/comics/sandwich.png
- Slashdot readers source: http://images.slashdot.org/articles/03/08/tshirt-contest-Images/6.jpg
- /b/tards
- Web Developer – HTML/CSS/JS/Perl/Python/PHP/Ajax etc source: http://i33.tinypic.com/fvwf94.png
- Linux sysadmins. Source: http://www.flickr.com/photos/10304942@N08/1297384901/
- Smart phone app developers source: http://blog.wirelessground.com/wp-content/uploads/2010/09/iphone-vs-android.jpg
- Java developers:
- C++ developers
- Cobol developer
- Fortran
- Assembly
- They don’t understand my constraints
- They speak jargon
- Extroverts: source http://onstartups.com/Portals/150/images/salesguy.jpg
- They’re girls: source: http://4.bp.blogspot.com/_6Be_0T7bQ48/ST4iVCqb_JI/AAAAAAAADvc/WNqzQfR7vAw/s400/16.jpg
- They ask dumb questions
- They’re of no use whatsoever
- They are users = irrational, don’t understand constraints
- They talk to customers; they can help you talk to customers. There is no substitute.
- They ARE users. They eat your dogfood. Source http://500hats.typepad.com/photos/uncategorized/2007/09/24/dogfood.jpg
- They are reasonable hand-drawn facimiles of users: same demographics, (in-) experience with software or domain.
- They ask dumb questions. http://www.youtube.com/watch?v=xrbyVDMUT10
- They contribute diversity: http://www.flickr.com/photos/deestea/130262190/
- I didn’t want to subject you to the images I found when I googled this one. D&C is one of the more invasive medical procedures a woman can undergo, usually exacerbated by a corresponding negative emotional, stressful and exceedingly personal event (miscarriage, abortion, etc).
- Globe and Mail report: http://www.theglobeandmail.com/news/national/if-you-want-collective-smarts-include-women-in-your-group/article1736571/ On US study at Carnegie Mellon; Collectively intelligent teams are ones that have social sensitivity, promote the involvement of all members, and contain more women (a linear relationship – more women = better performance)
- These are things that developers/testers in *some* companies do, today, to varying degrees of job satisfaction or actual success. I’m not saying developers should stop doing these things, but that they could, given the right mix of people and projects. And that it will make the developer’s life better to do so.
- Test your use cases and stories
- Write messages and error text
- Improve design, sometimes by asking dumb questions, sometimes by being a neutral party, sometimes by not being constrained by your constraints, sometimes in the process of writing error messages -Sarah Packowski
- Be an audience for your demos
- Do your demos for you
- Many of us can read code. We can comment. We can write the “this is what this really does” docs. You can review it.
- We can be your eyes and ears on other arms-length related projects in the company, because usually we’re spread among several.
- Richard Feynman, famous for blowing holes in technical problems by asking basic, “stupid” questions Ask dumb questions … see http://articles.techrepublic.com.com/5100-10878_11-1049536.html?tag=content%3bleftCol - Why are we still using this tool? Can you explain this to me in simple terms? What does that acronym actually stand for? Who’s our best person at dealing with this kind of problem? Why is this [X] here?
- Influence your test plan. Marketing plans, user docs, company blog posts can help you write and prioritize test cases, because they reveal the message the product is sending to customers (that is, the expectations you’re setting). You don’t have to re-do all that research.
- Talk to users – mediate. If talking to users is time consuming, annoying, or just against your nature, get someone else to do it. It’s better than NOT doing it. The non-tech can serve as a user advocate AND as a buffer for the dev team (from sales, customers, etc). Especially if the user is also on the non-technical side of the spectrum.
- Help you figure out who you WOULD hire next time. So keep notes.