SA re defined part 2

From UG

(Difference between revisions)
Jump to: navigation, search
(→About)
(→About)
Line 5: Line 5:
Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes:
Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes:
-
* Alex will do SA for [[Project]] type tasks. All other tasks (tweaks) can be forwarded to Andrei for SA.
+
* We need to bring Systems Analysis on a new professional level. It is a critical activity and must be done by a professional with appropriate level of technical training, experience and proven abilities
-
** New SA (or Technical writer) will be hired to provide more m/h to SA team
+
** core skills: excellent technical skills (details TBD), excellent communication skills, excellent documentation skills (Systems Analysis section and [[Proposal]])
-
* Kostya will play a role of Architect and must review all [[Project]] type specs and major tweaks.  
+
** existing staff must be re-trained or/and new staff must be hired
-
** He also must post Architect comments into "Architect Review" section (ideally) or mantis
+
** For now: Alex will do SA for [[Project]] type tasks; all other tasks (tweaks) can be forwarded to Andrei for SA
 +
 
 +
* We need to continue to improve BAs work:
 +
** train BAs to bring their skills to acceptable level
 +
** BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
 +
** skills that are critical for BA role: writing, analytical thinking, interviewing
 +
** SA must help BA to finalize her section. This means potentially re-writing it or writing it together.
 +
** SA should avoid repeating info that was already presented in BA section
 +
 
 +
* Role of Architect to be introduced who must review all [[Project]] type specs (BA and SA sections) and major tweaks.  
 +
** He must post Architect comments into "Architect Review" section (ideally) and mantis
 +
** If Architect rejects solution then it must be returned to SA (not BA)
 +
** If solution is accepted then developer must be assigned and task forwarded for estimation
 +
 
* Spec will have the following structure:
* Spec will have the following structure:
Line 22: Line 35:
  7 History
  7 History
-
* Since "Systems Analysis" section will not provide exact solution developer must fill in "Implementation Summary" so that QA and UAT know how to verify solution.
+
* Since "Systems Analysis" section will not provide exact solution I introduce Implementation Summary section.
-
* SA must help BA to finalize her section. This means potentially re-writing it or writing it together.
+
** To be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.
-
* SA should avoid repeating info that was already presented in BA section.
+
-
* If Architect rejects solution then it must be returned to SA not BA
+
== Examples ==
== Examples ==

Revision as of 23:58, 12 December 2010

About

This is a continuation of an effort to streamline SA work. Fist article is here: SA re defined

Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes:

  • We need to bring Systems Analysis on a new professional level. It is a critical activity and must be done by a professional with appropriate level of technical training, experience and proven abilities
    • core skills: excellent technical skills (details TBD), excellent communication skills, excellent documentation skills (Systems Analysis section and Proposal)
    • existing staff must be re-trained or/and new staff must be hired
    • For now: Alex will do SA for Project type tasks; all other tasks (tweaks) can be forwarded to Andrei for SA
  • We need to continue to improve BAs work:
    • train BAs to bring their skills to acceptable level
    • BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
    • skills that are critical for BA role: writing, analytical thinking, interviewing
    • SA must help BA to finalize her section. This means potentially re-writing it or writing it together.
    • SA should avoid repeating info that was already presented in BA section
  • Role of Architect to be introduced who must review all Project type specs (BA and SA sections) and major tweaks.
    • He must post Architect comments into "Architect Review" section (ideally) and mantis
    • If Architect rejects solution then it must be returned to SA (not BA)
    • If solution is accepted then developer must be assigned and task forwarded for estimation
  • Spec will have the following structure: 
1 Info
2 Business Analysis
  2.1 Requirements
  2.2 Possible solutions
  2.3 RFP
3 Systems Analysis
4 Architect Review
5 Implementation Summary
6 QA Plan
7 History
  • Since "Systems Analysis" section will not provide exact solution I introduce Implementation Summary section.
    • To be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.

Examples

Below are examples of spec that were built with new principles in mind:

Retrieved from "https://wiki.jaguarfreight.com/SA_re_defined_part_2"
Personal tools