Making Support Fun & Profitable: DrupalCon Portland
-
Upload
anne-stefanyk -
Category
Technology
-
view
161 -
download
0
description
Transcript of Making Support Fun & Profitable: DrupalCon Portland
Building Bridges, Connecting Communities
Meghan Sweet, Anne Stefanyk, Scott Massey, Michelle Krejci
Tuesday May 21, 2pm
Making Support Fun & Profitable
Introductions
Anne - Supporting the People in Support
Michelle - Onboarding & Auditing for Success
Meghan - Technical Support
Scott - Support Design & Management
Who's in the Room?
Drupal support is a continuation of building
out the website, adding features, optimizing, refining and updating.
Physical Needs
Clients: issues that impact their primary website objective
Physical Needs
Clients: issues that impact their primary website objective
Developers: need yummy food, beverages and a great work environment
Safety & Security Clients: need to be able to trust you and
communicate effectively with the team
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
Belonging Clients: Support routines help clients relax
Belonging Clients: Support routines help clients relax
Developers: team collaboration and collective learning
Esteem Needs
Clients: empowered with more knowledge & resources
Esteem Needs
Clients: empowered with more knowledge & resources
Developers: empowered by solving hard problems and working autonomously
Actualization
When support heads towards stress free, calm work...
support becomes fun and profitable
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
The WYSIWYG
Theme
- 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.
Hide &
Seek PHP
- Cannot cache. - Cannot easily trace. - Does not export well.
QUICK CHECK: turn off PHP filtering
Secret Mission Modules
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.
The Codebase Hoarder
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.
Yes. Yes, we do.
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.
"Given enough eyeballs, all bugs are shallow."
Prevention is Better than Cure
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.
Drupal is an ecosystem
10 Drupal Diseases
01. Overriding your overrides
02. Abandoning modular structure
03. Adding more hastily
04. Coding rather than training
05. Scattering code
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
10 Drupal Diseases
Follow the established development philosophy Play to your strengths and client's true needs Escalate when needed
Non-invasive procedures
What is sustainable? Avoid technical debt Both sites of the continuum are right / wrong sometimes
Moral compass of technical decision making
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
Keep it simple, keep it sane. Ideally your whole team can deploy. Drush aliases and ssh config for the win.
Deployment
Keep it simple. If it can't be simple, make it
very clear.
Run the table. Don't let it run
you.
5 "P"s Proper Planning Prevents Poor Performance
The 3 "R"s: Read it, wRite it, Repeat it.
Support Design
ITIL/ITSM -Strategy -Design -Transition -Operation -Continual Improvement
"Build Quality into the process." -W Edward Deming
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
Contract Design -Deliverables are "achievables" -Risk is your guide for agreement type. -Templates, not snowflakes
(menu: the vortex in atlanta)
-Empower Team -Don't ignore burnout
Building a Successful Brigade
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?
Building Bridges, Connecting Communities
Evaluate this session at:portland2013.drupal.org/session/making-support-fun-and-profitableThank
you!
What did you think?