DrupalCon 2013 Making Support Fun & Profitable


Published on

Presentation given at DrupalCon 2013 in Portland. This presentation offers new ways at looking at the Drupal support you are offering your clients.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

DrupalCon 2013 Making Support Fun & Profitable

  1. 1. Building Bridges, Connecting CommunitiesMeghan Sweet, Anne Stefanyk,Scott Massey, Michelle KrejciTuesday May 21, 2pmMaking Support Fun & Profitable
  2. 2. IntroductionsAnne - Supporting the People in SupportMichelle - Onboarding & Auditing for SuccessMeghan - Technical SupportScott - Support Design & Management
  3. 3. Whos in the Room?
  4. 4. Drupal support is a continuation of buildingout the website, adding features, optimizing,refining and updating.
  5. 5. Physical NeedsClients: issues thatimpact their primarywebsite objective
  6. 6. Physical NeedsClients: issues thatimpact their primarywebsite objectiveDevelopers: needyummy food, beveragesand a great workenvironment
  7. 7. Safety & SecurityClients: need to be able to trust you andcommunicate effectively with the team
  8. 8. Safety & SecurityClients: need to be able to trust you andcommunicate effectively with the teamDevelopers: need a gatekeeper or someoneup the chain to turn to
  9. 9. BelongingClients: Support routineshelp clients relax
  10. 10. BelongingClients: Support routineshelp clients relaxDevelopers: teamcollaboration and collectivelearning
  11. 11. Esteem NeedsClients: empowered withmore knowledge &resources
  12. 12. Esteem NeedsClients: empowered withmore knowledge &resourcesDevelopers: empowered bysolving hard problems andworking autonomously
  13. 13. ActualizationWhen support headstowards stress free,calm work...support becomesfun and profitable
  14. 14. Survey of 365 IT managers found thatof all projects:- 16% successful- 31% were impaired or cancelled- 53% were deemed "project challenged"The CHAOS report
  15. 15. TheWYSIWYGTheme
  16. 16. - Content not available to Drupal, whichlikes to manage that sort of thing.- Does not scale.- Theme lives inside content editors head.QUICK CHECK:turn off the WYSIWYG and see whathappens.
  17. 17. Hide&SeekPHP
  18. 18. - Cannot cache.- Cannot easily trace.- Does not export well.QUICK CHECK:turn off PHP filtering
  19. 19. SecretMissionModules
  20. 20. If it is not immediately clearwhat a custom module does,it could mean a black holeof support.QUICK CHECK:Sorry, theres not.Run some scripts that check for complexityand best practices.Then try good ole looking at the code.
  21. 21. TheCodebaseHoarder
  22. 22. Uh oh.This developer never read anydocumentation 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-to-Support mentality.Have one yourself.Put all config in code:- Features- Configuration- Role Export, Block Export, Strongarm, etc.Test your shit.
  25. 25. "Given enougheyeballs,all bugs areshallow."
  26. 26. Prevention is Better than Cure
  27. 27. Drupal is an ecosystem
  28. 28. Its dynamic.Timelines, budgets, servers,core/contrib, teams abilities.Deal with what you have and dont haveStretching it only makes it worse later.Drupal is an ecosystem
  29. 29. 10 Drupal Diseases
  30. 30. 01. Overriding your overrides02. Abandoning modular structure03. Adding more hastily04. Coding rather than training05. Scattering code10 Drupal Diseases
  31. 31. 06. Features without a workflow07. Patching without sharing08. Not leaving a trail09. High coupling10. Ignoring api.drupal.org10 Drupal Diseases
  32. 32. Follow the establisheddevelopment philosophyPlay to your strengths andclients true needsEscalate when neededNon-invasive procedures
  33. 33. What is sustainable?Avoid technical debtBoth sites of the continuum areright / wrong sometimesMoral compass of technicaldecision making
  34. 34. Most of response time is figuring outwhats broken.Can I reproduce this reliability?Analyze causes/effects.Propose solution. Analyze cost/benefit.Response time
  35. 35. Keep it simple, keep it sane.Ideally your whole team candeploy.Drush aliases and ssh configfor the win.Deployment
  36. 36. Keep it simple.If it cant be simple, make itvery clear.
  37. 37. Run the table.Dont let it runyou.
  38. 38. 5 "P"sProperPlanningPreventsPoorPerformance
  39. 39. The 3 "R"s: Read it, wRite it, Repeat it.
  40. 40. Support DesignITIL/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. -Empower Team -Dont ignore burnoutBuilding a Successful Brigade
  44. 44. Lightning Round & Questions1. What do you love about support?2. "I would do anything for [client] love, but Iwont do that."3. What is your most awesome/needed tool?4. What is your biggest challenge/success?
  45. 45. Building Bridges, Connecting CommunitiesEvaluate this session at:portland2013.drupal.org/session/making-support-fun-and-profitableThankyou!What did you think?