[PetiteCloud] grate book on how to specify systems

Aryeh Friedman aryeh.friedman at gmail.com
Fri Feb 14 17:26:15 PST 2014


All tech support goes to the tech team (one of our duties as a member of
that team is to *ANSWER* tech support questions) here is a rather dated
outline of our specific model:

 For the above reasons we have the following tech support policies:



  * The community (when possible) is the first source of answers. This
should eliminate the vast majority of non-bug report style tech support
requests.

 * The remaining questions will be handled in-house solely by the person(s)
responible for maintaining the feature(s) that are problematic in the report

 * Aryeh and Dee and a team will decide how to route all tech support
requests with the following status classifications:



  "Resolved" - the question has been resolved and all
needed/code/UI/documentation needed to resolve it "for good" are complete.



  "Planned for" - The requested functionality is already planned for in the
development plan



  "Unresolvable" - All possible solutions are in some way fundamentally
incompatible with PetiteCloud



  "Impossible" - The requested behavior is either physically/theortically
impossible or breaks the petitecloud architecture in a
non-trivial-to-repair way.



  "False alarm" - A question that somehow slipped through the community
filter



  "Open question" - The problem involves an "open question" in computer
science, software engineering and/or cloud archicture.



  "Open" - The question is still being dealt with internally

 * If the number of false alarms makes it impossible meet delivery
deadlines then we should review our documentaion and UI's for ways to
eliminate the most common false alarms

 * If the remaining false alarms still make it impossible to meet we
appoint one of the development team members to do full time tech support.
The will keep development duties (just less of them).

 * No tertiary version (the z in x.y.z) will be marked as complete until
the list of open tech support requests contains nothing but false alarms
that cannot be fixed by improving the documentation and/or the UI.

 * Whenever possible (without revealing corporate security and/or
compromising a user's ID), all tech support requests should be logged in
the project files for the product or other publicly accessible (even to
non-petitecloud users) place. This logging should include all steps taken
to resolve the issue.



  The philosophy behind using such an expensive approach to tech support is
that for every bug/UI hiccup/confusion/etc. problem we hear about there are
at least 20 more people who did not report the very same issue. We further
assume that out those 20 at least 5 have stopped using PetiteCloud and
those 5 at least 1 has complained about it publicly. That single complaint
has the potential of sinking a perfectly good product (some times before it
even gets off the ground) costing us untold amounts (certainly much more
then it would have been to just fix the bug in the first place).



On Fri, Feb 14, 2014 at 8:20 PM, Michael Thoreson <m.thoreson at c4labs.ca>wrote:

> There are a few solutions to the typical tech support failures.
>
> 1) All tech calls get reviewed by a dev or dev team periodically.
> 2) Devs rotate from developing to taking tech support calls on a set
> rotation
> 3) A Dev or Dev(s) is available and dedicated to assisting tech support
> intake with any unusual problems
> 4) Don't train monkeys how to answer phones and read flow charts of text
> book answers and expect to solve problems.
>
> Michael Thoreson,
>
>
> On 14/02/2014 7:01 PM, Aryeh Friedman wrote:
>
>> A little glue in the *RIGHT* places and a nice skin will win *EVERY*
>> time. The inappropriate marketing of any kind of product will always fail.
>> Namely no appropriate marketing is possible if the product sucks. Only once
>> you have a soild product can you start the real marketing (this assumes
>> your aware of marketing 101 and know that without a market to market to no
>> amount of marketing will sell your product). But you need one more element
>> here which is prove that your product does in fact solve the actual problem
>> the potential customer has. Now that everything is in place we can start
>> the real work of marketing which is making the people who have the problem
>> your product solves know that you have the a solution (a good healthy
>> multi-vendor market should offer several solutions that are all
>> appropriately marketed). Thus the real job marketing of an appropriately
>> product is to just let people know about what your product is and what it
>> can do. If it does not do what they want or in the way they want then no
>> amount marketing will sell it to them if they are aware of a number of
>> competing solutions. If all these competing solutions depend on a common
>> enabling technology (like a cloud computing platform... in this case it
>> need not be petitecloud just the ability to manage instances and such) then
>> it is *CRITICAL* that every competitor have a fair say in it's creation....
>> there is a problem here though if you allow everyone to have an equal say
>> then you end up with crap every time.... there fore the only reasonable
>> model I see for the above to work for something like petitecloud is a
>> democratic benevolent dictatorship (the philospher king model)... namely we
>> (the core team) will take input from everyone and have open processes and
>> all that but what is actualy committed to code is our say and our say
>> alone... same goes for contributions we welcome all and except for cases of
>> introduction a requirement for radical refactoring we will take it
>> (assuming it is safe, stable and robust).
>>
>> A comment on "we don't support that feature"... here is a quote from our
>> business plan on that:
>>
>> All software companies to some extent have "technical support" questions
>> that must be answered (or people will simply stop buying their products).
>> This is usually delegated to a tech support department. Having to deal with
>> a "tech support specialist" of large companies is one of the quickest ways
>> to anger our target market. The reason is despite how long we wait on hold
>> (with the world's worst music played in a tin can) or how many useless
>> menus we go through and have very carefully explained for the n^th time
>> that we have already read the manual and searched the online knowledge base
>> it is still guaranteed that an actual developer who can fix my issue will
>> never be told about the issue, thus guaranteeing it will never be fixed and
>> will eventually get buried so deep in the code base that it will be
>> impossible to fix. This entire process is alienating to freelance
>> developers because they often know as much, if not more, about the product
>> then the tech support people do.
>>
>>
>>
> _______________________________________________
> petitecloud-general mailing list
> petitecloud-general at lists.petitecloud.nyclocal.net
> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-
> petitecloud.nyclocal.net
>



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.petitecloud.nyclocal.net/pipermail/petitecloud-general-petitecloud.nyclocal.net/attachments/20140214/d614c863/attachment-0003.htm>


More information about the petitecloud-general mailing list