Hi Guys and Gals..
I've attended several of the business tracks in drupalcon boston and one of the emerging patterns (Which was verbally advocated by Boris Mann in his session) was to form a pool of joint resources to improve and add methodology to our business practices.
The most inspiring example I've seen was by the "Drupal performance agency" and was handed out by the tag1 consultants.
You can see the example here - http://tag1consulting.com/drupal/performance
These performance checklist are superb and are licensed under the creative commons attribiution sharealike2.0 license.
If we could create similar requirement gathering checklist that would be great.
I currently lack this methodological "check list" approach but from the talks in drupalcon, bigger drupal shops may have the following resources and might get the recognition and "performance leaders branding" tag1 has achieved by stepping up and providing added value to the drupal community.
So, What's can we put in this resource?
- Requirements gathering checklists
- Initial Installation profile module list
- Recepies, Recepies, Recepies...
I open this as a wiki page because this is work in progress.
Feel free to build upon this page and let's make this an amazing resource for all of the new drupal shops forming out there...
Lior
Comments
Changed to discussion
Lior -- I changed this post type to a Discussion instead of a wiki page. It will probably be easiest to have one page per type of resource. For instance, a Requirements Gathering sheet, a Recipes page, etc. etc.
Thanks for posting this "call to action".
How did you do that?
Boris,
How did you change a wiki page to Discussion (Story) page?! I thought you had to recreate the post to do that?
Erik
Erik Britt-Webb
drupal@ebrittwebb.com
Magic powers
I'm one of the admins here on g.d.o -- I actually don't know off hand what module Moshe has installed (might even be devel?), but I have the option when I edit.
Summaries
Hi Boris,
I'm leading the discussion in the qualified module lists for instance and I think that the discussion eventually creates great content.
But this needs to be consolidated to one page which should probably be a wiki.
What is the correct way to create one resource (A page) should an aditional wiki page be created in the end of each discussion summarizing it?
Maybe the initial post should be changed?
What do you think will serve as a good resource?
Linnovate - Community Infrastructure Care
Drupal Services in Israel
http://www.linnovate.net
Linnovate - Community Infrastructure Care
Drupal Services in Israel
http://www.linnovate.net
jobs and their best practices
I was thinking of a job specific approach, from the top of my head for:
information architecture
design
theming
development
site building
editing
site management
etc.
For each of these steps we could work out a set of standards:
-input: a questionnaire/check list with information required to successfully fulfil these jobs
-output: a checklist to see if the results of a job fulfil the quality requirements
-a guideline with best practices.
If these are the same between companies it will make it easier to collaborate.
I was thinking about doing this on a dedicated site is there any existing place where we can collect/build these?
--
Check out more of my writing on our blog and my Twitter account.
Just get started...
I think the best thing to do is to just get started, rather than yak shaving about setting up sites, etc.
e.g. shared collateral on educating clients about:
Wel let's start creating our own if there is none existing...
Ok...
I thought we'd have something from one of the existing drupal shops...
Let's try to build this out deliberatively.
Where I have a lack of resources and methodology is the efficient way to collect the "inputs" and "outputs" as kristoff mentioned.
So let's start to brainstorm from the begining
How do you Qualify a customer?
How do you decide to take a project?
Who and where do you send the client once your not interested in him?
Different companies have different entrance threshold maybe we should pass on to somebody with the drupal community and not lose the project to a joomla or plone shop.
I think we should start it by issues posted in this group and that way try to "harvest" procedures and to develop best practices for each of the stages... (and add more if you have an idea)
1. Initial Qualification (web or phone..)
2. Requirement Gathering (The big webform/questionare on the web?)
3. First frontal meeting.
4. How to write a drupal based functional specification document.
5. What to define as essential requirements in a specification document/wireframe created by someone which is not you?
6. How to asses times for tasks , how to break up the work?
7. Ongoing monitoring of the work done/ project management best practices.
8. Waterfall vs Agile - war stories...
9. How and when to QA? Is the customer involved in checking? When?
10. When does a project end/ Acceptence tests.
11. Scope creep - Horror stories and best practices for avoidece of them.
Let's start stage by stage and start brainstorming serially on the issues here.
Linnovate - Community Infrastructure Care
Drupal Services in Israel
http://www.linnovate.net
Linnovate - Community Infrastructure Care
Drupal Services in Israel
http://www.linnovate.net
Training
I would think that training the client how to use Drupal would be an important one to be added to the list.
Another training issue...
In the same vein there's the issue of bringing on new people, who have varying levels of Drupal/Web experience. I'm sure that everyone here who has worked in an IT department before has come across a good number of people who have great resumes, but who couldn't troubleshoot their way out of a paper bag, so one big question facing Drupal shops is whether to bring on people who are already Drupal developers or train people who show motivation and promise.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
It's all about passion - baby!
I am a big believer of the latter - Of finding that potential resource and molding it to be a ninja.
People that are autodidacts and are passionate about drupal even if they are newbies are a good sign,
People that have tons of questions both asked and answered all over google are a good sign.
People that have previous experience using and self-learning oss are a good sign as well.
I try to be active and attentive in the communities I founded and participate in and when somebody start giving smart and thought out answers that's when they enter the "watch out for" list.
Another great resource are QA and Support people that are very good and passionate about what they do.
They high end support and QA personal tend to want to make the shift to development and have a solid understanding of the exterior world (support talk to clients and QA pretends to be one) this makes very good and sometime cost effective candidiates (again when that passion thing fuels their growth).
just my two cents..
and btw I have no choice I simply can't afford the oldschool drupal rockstars :)
Linnovate - Community Infrastructure Care
Drupal Services in Israel
http://www.linnovate.net
Linnovate - Community Infrastructure Care
Drupal Services in Israel
http://www.linnovate.net