DrupalCon 2013 Making Support Fun & Profitable

50
Building Bridges, Connecting Communities Meghan Sweet, Anne Stefanyk, Scott Massey, Michelle Krejci Tuesday May 21, 2pm Making Support Fun & Profitable

description

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

Transcript of DrupalCon 2013 Making Support Fun & Profitable

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?