Please look at the OpenSolaris version of the 1-pager; it has
most of the "need marketing" stuff removed. Maybe we could rename
it from using the word "business", but nothing there should be a
roadblock.
3. Business Summary
3.1. Problem Area:
// What problem or customer need does this project solve?
3.2. Market/Requester:
// Who needs the project?
3.3. Business Justification:
// Why is it important or valuable to do this project?
3.4. Competitive Analysis:
// Who are the current and anticipated players in this market?
3.5. Opportunity Window/Exposure:
// Time-to-market window, if any, and precision.
3.6. How will you know when you are done?:
// What will you measure to determine that the project is complete?
//
// This section is for explicit measurable customer CTQs that apply
// to this specific feature proposal, not to the product as a whole.
//
// We *expect* every development team to meet their Feature,
// Performance and Security and Testing goals, as well as getting
// all required ARC and PAC review approvals, so don't put that
// sort of metric here.
What would *you* change or remove?
-John
Mark A. Carlson wrote:
> Hear hear. The business justification more often than not
> is the only reason that cases stay closed.
>
> -- mark
>
> James Carlson wrote:
>> Garrett D'Amore writes:
>>
>>> I'm actually thinking that my blk2scsa interface falls into this
>>> category. When it goes to PSARC (I'll submit it next week, waiting for
>>> marketing contact first), the code will essentially be "done". But,
>>>
>> ^^^^^^^^^^^^^^^^^^^^^^^
>>
>> The unholy mix of technical and business considerations that exist in
>> the current 1-pager format has always been a pretty serious problem --
>> it often blocks project teams from complying with the "ARC early"
>> request -- and it sounds like you're another victim.
>>
>> I think OpenSolaris (and the long-forgotten demise of the SCs) gives
>> us a good excuse to sever this unnecessary tie.
>>
>>
