Category: Entertainment

Presentation Description

No description available.


Presentation Transcript

Systems Analysis & Design:

PowerPoint Presentation for IS-207 Copyright 2006 © Michael W. Schaffer. All rights reserved. Slide 1 Systems Analysis & Design Class 2: People and Organizations 5/13/2011 11:27:32 PM

Thoughts from Class #1:

Slide 2 Thoughts from Class #1 Products are much more diverse, so teams are more diverse. The more complex your project, the more complex your team: The harder it will be to understand “who’s who”, and what everyone wants & needs.

Myers-Briggs Personality Types:

Slide 3 Myers-Briggs Personality Types Favorite world: Do you prefer to focus on the outer world or on your own inner world? This is called Extraversion (E) or Introversion (I) . Information: Do you prefer to focus on the basic information you take in or do you prefer to interpret and add meaning? This is called Sensing (S) or Intuition (N) . Decisions: When making decisions, do you prefer to first look at logic and consistency or first look at the people and special circumstances? This is called Thinking (T) or Feeling (F) . Structure : In dealing with the outside world, do you prefer to get things decided or do you prefer to stay open to new information and options? This is called Judging (J) or Perceiving (P) . http://www.myersbriggs.org/

Management 101:

Slide 4 Management 101 A quick overview of management principals, organizational issues, and personnel matters Enable “managing-up”

Teach Points:

Slide 5 Teach Points Matrix management Roles and Titles Key Roles on a S/W Team Evolving roles by phase Inherent conflict by role Roles and Tools Testing … (if we have time)


Slide 6 Passion Corporate America does not really do well with passion but the best results come from people pouring their passion into their work The processes that we use, and our ability to understand each other will allow us to be passionate about the work, and produce great things.

People and The Matrix:

Slide 7 People and The Matrix Matrix Management Departments organized by function Teams / Projects staffed “cross functionally” -- i.e.: engineers, a marketing person, visual design, project management, training, IT How does this work?

An Engineering Team:

Slide 8 An Engineering Team

A Cross-functional Team:

Slide 9 A Cross-functional Team

Challenges of The Matrix:

Slide 10 Challenges of The Matrix Priorities and Management Managing without line authority on the team. Conflicting priorities and projects New initiatives vs. maintenance Need Clarity from Senior Mgmt! Communicated broadly and formally Ensure alignment and focus

An example of Clarity:

Slide 11 An example of Clarity Project deliverable Core team Deliverable date 1 Launch seller search, consol and sites Seller communications & pre-launch on Hub Launch Web & Hub changes Robin, David, Molly, Jesse, Kelly, Monique Oct 11 th Oct 18 th 2 Amazon Seller Services Seller communications Test plan complete Dev complete Start Beta tests with Amazon Dudley, Geoff, Manan, David, Aaron, Jesse Oct 11 th Oct 17 th Oct 21 st Oct 25 th 3 TRIPE: initial A/B tests in production on Web site John, Paul, Robin, Steve C Oct 26 th

Titles vs. Roles:

Slide 12 Titles vs. Roles Job Titles reflect an organization's structure, and an individuals rank A project role – what work you do. At Alibris, our Project Mgr.’s include: Randy, Controller Aric, Director of Product Development Dudley, Director of Business Development Throughout this class, focus is on roles

Roles and “Hats”:

Slide 13 Roles and “Hats” In most small teams, people play multiple roles (wear “many hats”) You must embrace (you have no choice), but manage it explicitly. Authority is vested in the role . High-risk when senior people play contributor roles

People: Vision and Ownership:

Slide 14 People: Vision and Ownership Who drives the vision of the product, and to whom do they report? Who drives the delivery of the project, and to whom do they report? Who is “on the hook”?

People: Key Roles in S/W Dev:

Slide 15 People: Key Roles in S/W Dev Business Owner, Product Manager, Project Manager, Technical Architect, Quality Assurance Lead, Designers (Visual, Interface, Database, Implementation) Stereotypes and Archetypes Conflict and Passion “Multiple Hats”

People: Business Owner/Sponsor:

Slide 16 People: Business Owner/Sponsor Responsible for Strategy: WHY is this project being undertaken? Keep asking “why?” – re-visit and re-justify as design details and cost estimates become clearer. Revisit tradeoffs and alternatives. Watch out when Sponsorship shifts or becomes unstable.

People: Product Manager:

Slide 17 People: Product Manager Responsible for “What” is to-be-built (feature mix) Will normally push for “bigger” (more features, more stuff). Must maintain a clear understanding of external forces (competition) and customer needs – fact-based . Authority on the team needs balance from other senior team members.

People: Technical Architect:

Slide 18 People: Technical Architect Responsible for “How” to build Not responsible for saying “no” – only for designing solutions and estimating costs, providing options Watch out for “grumpy IT guy” syndrome (too many scars) Flip side: watch out for “gratuitous complexity”

People: Quality Assurance Lead:

Slide 19 People: Quality Assurance Lead Responsible for measuring quality & alignment to requirements Not the scapegoat for bugs and slips in the schedule. Not the only “bad cop” on the team. QA is your trump card in process & management Where does QA report?

People: Designers:

Slide 20 People: Designers Responsible for Vision Ensure great communication of requirements to these folks to get great designs Applicable in technical and non-technical areas Limit them with process to get on-time deliverables in scope.

People: Project Manager:

Slide 21 People: Project Manager Responsible for “When” Not responsible for understanding every detail of implementation PM needs to engage all team members to extract dependencies and contingencies PM needs serious “spine” to get straight answers to “how long?”

Ad-hoc Teams:

Slide 22 Ad-hoc Teams Teams that exist for one phase or a specific deliverable Prototype Team Release Team Beta Team

People: Seniority and Scale:

Slide 23 People: Seniority and Scale The project’s scope & scale can determine the relative seniority of each resource in the project, for each role. A specific title, like “Senior Software Engineer” could take on many roles - Technical Architect, Lead Developer, Tester, Project Manager

Dual Career paths:

Slide 24 Dual Career paths

People: Work and Tools:

Slide 25 People: Work and Tools The work you do is defined in part by the tools you use. Be aware of your time spent in specific tools … and how that reflects on your role and focus. Executive: Email, PowerPoint, Excel, Word Visual Designer: Illustrator, Photoshop Data & Process Designers: Visio, Erwin, DB Artisan, etc. Project Mgr: MS Project, etc. Developer: Dev. Environments, “hand tools”, misc. lang.’s QA: Test tools, etc. A quick way to really see who is doing what (or not) on a particular project. Follow the money

People: Work and Tools (cont):

Slide 26 People: Work and Tools (cont) Look around to see that someone is using the right tools.  Tools “Gap” analysis Regardless of title, is someone maintaining a project plan? A budget? A requirements doc? Are managers using “hands-on” tools? Is this OK?

Testing Basics:

Slide 27 Testing Basics Unit Testing Integration Testing Compatibility & Platform Testing Performance & Stress Testing Pathological testing

Beta Testing, Old School:

Slide 28 Beta Testing, Old School Alpha: feature complete, all features testable. Specifications frozen. Ready for end-to-end testing, using “friendly” testers. Beta: ready for external testers (customers, partners, etc). Formal program with measured feedback.

Beta Testing (cont).:

Slide 29 Beta Testing (cont). Manage carefully: not a time for enhancement requests Limit participation to ensure you get value from each site Code that is too “raw” can create more damage than value “Rolling Beta” ...

Prototypes vs. Production:

Slide 30 Prototypes vs. Production Be clear on purpose. Develop metrics and validate. Be clear on limitations “Build one to throw away” Fred Brooks, Mythical Man-Month


Slide 31 Exercise Release Team Bug Assessment QA, Product Mgr, Project Mgr, Development Engineer, UI / UE Guy Review stack of bugs: defer, fix, document, “not a bug”, dupe Conflict?

A Customer-centric model:

Slide 32 A Customer-centric model Everybody has a customer: external, or internal Need to understand who your customers are, and how to serve those customers