Open Source Software: An Edge For Your Growing Business
DrupalCon 2013 Making Support Fun & Profitable
1. Building Bridges, Connecting Communities
Meghan Sweet, Anne Stefanyk,
Scott Massey, Michelle Krejci
Tuesday May 21, 2pm
Making Support Fun & Profitable
2. Introductions
Anne - Supporting the People in Support
Michelle - Onboarding & Auditing for Success
Meghan - Technical Support
Scott - Support Design & Management
9. 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
16. Survey of 365 IT managers found that
of all projects:
- 16% successful
- 31% were impaired or cancelled
- 53% were deemed "project challenged"
The CHAOS report
18. - 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.
22. 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.
24. 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.
28. 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.
32. 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.
Drupal is an ecosystem
34. 01. Overriding your overrides
02. Abandoning modular structure
03. Adding more hastily
04. Coding rather than training
05. Scattering code
10 Drupal Diseases
35. 06. Features without a workflow
07. Patching without sharing
08. Not leaving a trail
09. High coupling
10. Ignoring api.drupal.org
10 Drupal Diseases
36. Follow the established
development philosophy
Play to your strengths and
client's true needs
Escalate when needed
Non-invasive procedures
37. What is sustainable?
Avoid technical debt
Both sites of the continuum are
right / wrong sometimes
Moral compass of technical
decision making
38. Most of response time is figuring out
what's broken.
Can I reproduce this reliability?
Analyze causes/effects.
Propose solution. Analyze cost/benefit.
Response time
39. Keep it simple, keep it sane.
Ideally your whole team can
deploy.
Drush aliases and ssh config
for the win.
Deployment
46. 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
47. Contract Design
-Deliverables are "achievables"
-Risk is your guide for agreement type.
-Templates, not snowflakes
(menu: the vortex in atlanta)
49. 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?
50. Building Bridges, Connecting Communities
Evaluate this session at:portland2013.drupal.org/
session/making-support-fun-and-profitableThank
you!
What did you think?