Making Support Fun & Profitable: DrupalCon Portland

307 views

Published on

After the site launches and the project is over, there are two paths: developers and project managers can shake client's hands, pat backs, and all head our separate ways. Or we can continue to build a relationship - continue being a part of our client's success. Strong long-term relationships benefit clients by providing trust and security, like a familiar mechanic or the barber we have had since we were a kid. As merchants, we also benefit. Happy clients mean referrals and recurring income.

Offering support is a different type of commitment, requiring a different strategy. A dev shop becomes a different type of service provider, and needs to prepare for great execution. This session will cover the why, how, and when of offering support, as well as exchange ideas about the many aspects: selling, marketing, staffing, delivering and monitoring support for Drupal.

Appealing to both the technical and non-technical, topics include:

- How to determine what type of support your clients need
- Organizing support requests, working within budgets and architecting timelines
- Workflow tactics and tools we love
- How to audit a site, understand it, and help it grow
- Best practices for your support development workflow
- Developer notes from the trenches- what you should know and look for

Come hear different perspectives on support and join the conversation!

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
307
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Making Support Fun & Profitable: DrupalCon Portland

  1. 1. Making Support Fun & Profitable Meghan Sweet, Anne Stefanyk, Scott Massey, Michelle Krejci Tuesday May 21, 2pm Building Bridges, Connecting Communities
  2. 2. Introductions Anne - Supporting the People in Support Michelle - Onboarding & Auditing for Success Meghan - Technical Support Scott - Support Design & Management
  3. 3. Who's in the Room?
  4. 4. Drupal support is a continuation of building out the website, adding features, optimizing, refining and updating.
  5. 5. Physical Needs Clients: issues that impact their primary website objective
  6. 6. Physical Needs Clients: issues that impact their primary website objective Developers: need yummy food, beverages and a great work environment
  7. 7. Safety & Security Clients: need to be able to trust you and communicate effectively with the team
  8. 8. Safety & Security Clients: need to be able to trust you and communicate effectively with the team Developers: need a gatekeeper or someone up the chain to turn to
  9. 9. Belonging Clients: Support routines help clients relax
  10. 10. Belonging Clients: Support routines help clients relax Developers: team collaboration and collective learning
  11. 11. Esteem Needs Clients: empowered with more knowledge & resources
  12. 12. Esteem Needs Clients: empowered with more knowledge & resources Developers: empowered by solving hard problems and working autonomously
  13. 13. Actualization When support heads towards stress free, calm work... support becomes fun and profitable
  14. 14. The CHAOS report Survey of 365 IT managers found that of all projects: - 16% successful - 31% were impaired or cancelled - 53% were deemed "project challenged"
  15. 15. The WYSIWYG Theme
  16. 16. - Content not available to Drupal, which likes to manage that sort of thing. - Does not scale. - Theme lives inside content editor's head. QUICK CHECK: turn off the WYSIWYG and see what happens.
  17. 17. Hide & Seek PHP
  18. 18. - Cannot cache. - Cannot easily trace. - Does not export well. QUICK CHECK: turn off PHP filtering
  19. 19. Secret Mission Modules
  20. 20. If it is not immediately clear what a custom module does, it could mean a black hole of support. QUICK CHECK: Sorry, there's not. Run some scripts that check for complexity and best practices. Then try good 'ole looking at the code.
  21. 21. The Codebase Hoarder
  22. 22. Uh oh. This developer never read any documentation ever. Proceed with caution. QUICK CHECK: Look at what modules are enabled, see if you can find them.
  23. 23. Yes. Yes, we do.
  24. 24. Until then... Look for shops or contractors with a View-toSupport mentality. Have one yourself. Put all config in code: - Features - Configuration - Role Export, Block Export, Strongarm, etc. Test your shit.
  25. 25. "Given enough eyeballs, all bugs are shallow."
  26. 26. Prevention is Better than Cure
  27. 27. Drupal is an ecosystem
  28. 28. Drupal is an ecosystem Its dynamic. Timelines, budgets, servers, core/contrib, team's abilities. Deal with what you have and don't have Stretching it only makes it worse later.
  29. 29. 10 Drupal Diseases
  30. 30. 10 Drupal Diseases 01. Overriding your overrides 02. Abandoning modular structure 03. Adding more hastily 04. Coding rather than training 05. Scattering code
  31. 31. 10 Drupal Diseases 06. Features without a workflow 07. Patching without sharing 08. Not leaving a trail 09. High coupling 10. Ignoring api.drupal.org
  32. 32. Non-invasive procedures Follow the established development philosophy Play to your strengths and client's true needs Escalate when needed
  33. 33. Moral compass of technical decision making What is sustainable? Avoid technical debt Both sites of the continuum are right / wrong sometimes
  34. 34. Response time Most of response time is figuring out what's broken. Can I reproduce this reliability? Analyze causes/effects. Propose solution. Analyze cost/benefit.
  35. 35. Deployment Keep it simple, keep it sane. Ideally your whole team can deploy. Drush aliases and ssh config for the win.
  36. 36. Keep it simple. If it can't be simple, make it very clear.
  37. 37. Run the table. Don't let it run you.
  38. 38. 5 "P"s Proper Planning Prevents Poor Performance
  39. 39. The 3 "R"s: Read it, wRite it, Repeat it.
  40. 40. Support Design ITIL/ITSM -Strategy -Design -Transition -Operation -Continual Improvement "Build Quality into the process." -W Edward Deming
  41. 41. Design Specifics “Do nothing that is of no use” -Miyamoto Musashi -No PM Workflow -Can your SE draw the process? -Get a PSA application -Monitor & Automate
  42. 42. Contract Design -Deliverables are "achievables" -Risk is your guide for agreement type. -Templates, not snowflakes (menu: the vortex in atlanta)
  43. 43. Building a Successful Brigade -Empower Team -Don't ignore burnout
  44. 44. Lightning Round & Questions 1. What do you love about support? 2. "I would do anything for [client] love, but I won't do that." 3. What is your most awesome/needed tool? 4. What is your biggest challenge/success?
  45. 45. What did you think? Evaluate this session at:portland2013.drupal.org/ session/making-support-fun-and-profitableThank you! Building Bridges, Connecting Communities

×