SA re defined part 2

From UG

(Difference between revisions)
Jump to: navigation, search
Line 19: Line 19:
** skills that are critical for BA role: writing, analytical thinking, interviewing
** skills that are critical for BA role: writing, analytical thinking, interviewing
** BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
** BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
 +
 +
* To improve BA to SA cooperation:
 +
** BA is to post/manage her info in [[RFD]] type wiki
 +
** SA is to post/manage his work in Dev type wiki
 +
** See example here: [[:Category:Acc]]
 +
** SA is to forward only dev type wiki to Architect/Developer
 +
** SA must help BA to finalize her section. This means potentially re-writing it or writing it together.
** 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
** SA should avoid repeating info that was already presented in BA section
Line 49: Line 56:
** This value indicates a level of impact of particular task on entire system deign
** This value indicates a level of impact of particular task on entire system deign
** tasks with impact = ihigh/imed must be reviewed by Architect before coding or even SA phase
** tasks with impact = ihigh/imed must be reviewed by Architect before coding or even SA phase
 +
** tasks with impact = ilow could be assigned directly to Developer
* Below see examples of specs that were built with new principles in mind.
* Below see examples of specs that were built with new principles in mind.

Revision as of 18:03, 14 December 2010

Subject: New directives to streamline SA (and BA) work

From: CT2 Project Manager

To: CT2 Team

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

Due to additional negative feedback about recently submitted designs/specifications I introduce the following directives:

  • 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:
    • continue to train BAs to bring their skills and experience to acceptable level
    • skills that are critical for BA role: writing, analytical thinking, interviewing
    • BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
  • To improve BA to SA cooperation:
    • BA is to post/manage her info in RFD type wiki
    • SA is to post/manage his work in Dev type wiki
    • See example here: Category:Acc
    • SA is to forward only dev type wiki to Architect/Developer
    • 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:
    • must review all Project type specs and major tweaks (after BA and SA sections are completed)
    • must post Architect comments into "Architect Review" section
    • 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
    • Kostya will play this role
  • Spec will have the following structure: (template is here Spec Example)
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
  • I introduce Implementation Summary section
    • needed since "Systems Analysis" section will not provide exact solution, just direction in many cases
    • to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.
  • I am adding "impact" mantis field. With values: {ihigh, imed, ilow}
    • This value indicates a level of impact of particular task on entire system deign
    • tasks with impact = ihigh/imed must be reviewed by Architect before coding or even SA phase
    • tasks with impact = ilow could be assigned directly to Developer
  • Below see examples of specs that were built with new principles in mind.

Examples:

Personal tools