Project Overview, and Working with Clients UNC COMP 523 Wed Aug - - PowerPoint PPT Presentation

Project Overview, and Working with Clients

UNC COMP 523 Wed Aug 12, 2020

• Prof. Jeff Terrell

1 / 40

First, a word from Peter Liao Commercialization Manager UNC Office of Technology Commercialization Email: liaopb@unc.edu

2 / 40

announcements

lecture recording posted to web site (as of Mon. evening) will generally have recording posted by evening or next morning won't announce anything about recordings from now on project/client applications are posted on the web site will post more details as they're available e.g. client-provided titles/summaries and slides I noticed the PDF version of slides is a little weird, FYI

Project Overview & Working with Clients

3 / 40

agenda

• 1. narrative arc of a project
• 2. working with clients
• 3. picking a project
• 4. assignment 0: pitch preferences

Project Overview & Working with Clients

4 / 40

agenda

• 1. narrative arc of a project
• 2. working with clients
• 3. picking a project
• 4. assignment 0: pitch preferences

Project Overview & Working with Clients

5 / 40

narrative arc of a project

. understand what's needed . storyboard . prototype . iterate . launch . hand off

Project Overview & Working with Clients

6 / 40

narrative arc of a project

• 1. understand what's needed
• 2. storyboard
• 3. prototype
• 4. iterate
• 5. launch
• 6. hand off

Project Overview & Working with Clients

7 / 40

• 1. understand what's needed

$5 word of the day: desiderata, i.e. "what's desired"

• bviously, you'll need to talk to your client for this

understanding is progressive: start with the high-level view successful projects need ongoing communication between devs and client to deepen understanding as things unfold critical element: feedback loops, to reflect and improve your understanding (we'll come back to this)

• utput of this phase: user stories

Project Overview & Working with Clients

8 / 40

user stories

to avoid getting sucked into fun technical questions, I recommend capturing requirements as user stories template: "As a <role>, in order to <goal>, I can <describe feature>." example:

> "As an authenticated user, in order to keep up with my friends, I can see a

note the first-person perspective, which helps you focus on value delivered rather than implementation details after creating user stories, invite feedback from your client (better to discover misunderstandings early!) user stories are Assignment 3

Project Overview & Working with Clients

9 / 40

narrative arc of a project

• 1. understand what's needed
• 2. storyboard
• 3. prototype
• 4. iterate
• 5. launch
• 6. hand off

Project Overview & Working with Clients

10 / 40

• 2. storyboard

developing software is a creative act like other substantial creative acts, design is helpful

• ther designed things have a design artifact to guide implementation

Project Overview & Working with Clients

11 / 40

(from here)

12 / 40

(from here)

13 / 40

• 2. storyboard (2)

goal: create a design artifact for the app that will guide implementation challenge: more views than a blueprint challenge: not linear like a storyboard for a video solution: a "clickable prototype" Example

Project Overview & Working with Clients

14 / 40

• 2. app storyboards: clickable prototypes

not a live app prescripted; a canned experience but it looks and feels like the real thing, including navigation to different screens can do it lo-fi ("wireframe" or sketch-like) or hi-fi ("pixel perfect") this is extremely valuable both:

• to reflect a _very concrete_ understanding to the client early
• to synchronize the dev team about what to build

after creating clickable prototype, invite feedback from your client (better to discover misunderstandings early!) if there's a misunderstanding far easier to change this than an interface embodied in

Project Overview & Working with Clients

15 / 40

narrative arc of a project

• 1. understand what's needed
• 2. storyboard (clickable prototype)
• 3. prototype
• 4. iterate
• 5. launch
• 6. hand off

Project Overview & Working with Clients

16 / 40

• 3. prototype

story: my high school team programming project my failure: only connecting everything together at the end

• ne problem: client can't see in-progress app; feedback loop is destroyed

another problem: this is stressful! and you might fail to deliver anything useful! my approach: integrate first to create a "walking skeleton" integrate the frontend, backend, database, infrastructure, etc. before adding features then you can develop with confidence and invite feedback at every step of the way this is hard, but worth it; tackle this sooner to avoid your future self cursing you this is Assignment 8

Project Overview & Working with Clients

17 / 40

narrative arc of a project

• 1. understand what's needed
• 2. storyboard (clickable prototype)
• 3. prototype (walking skeleton)
• 4. iterate
• 5. launch
• 6. hand off

Project Overview & Working with Clients

18 / 40

• 4. iterate

with a clickable prototype done, you know the target with a walking skeleton done, the foundation is laid and deployment is a known quantity so working on features is relatively straightforward (and hopefully parallelizable) a feature isn't done until it's deployed for the client to see and it's not really done until the client has given feedback on the feature: either a thumbs up or requests for changes don't forget to add tests! (Assignment 11)

Project Overview & Working with Clients

19 / 40

narrative arc of a project

• 1. understand what's needed
• 2. storyboard (clickable prototype)
• 3. prototype (walking skeleton)
• 4. iterate
• 5. launch
• 6. hand off

Project Overview & Working with Clients

20 / 40

• 5. launch

you've already deployed all your code (see Step 4) this is more about releasing the app to its users maybe start with alpha and beta testers and invite feedback getting a diverse set of perspectives can uncover bugs and issues this is not required for a COMP 523 project, but nice for client

• ften this requires more of the client than the developer, e.g. actually publishing the

app in the App Store, marketing, etc.

Project Overview & Working with Clients

21 / 40

narrative arc of a project

• 1. understand what's needed
• 2. storyboard (clickable prototype)
• 3. prototype (walking skeleton)
• 4. iterate
• 5. launch
• 6. hand off

Project Overview & Working with Clients

22 / 40

• 6. hand off

write a README.md file with everything a CS friend of yours would need to know to start working on this project (Assignment 12) write another document (preferably in-repo) describing the project to your client, paying attention to where code lives and where the various application components and services live (Assignment 13) share the client overview with your client, and ensure they have access to the code if client doesn't own infrastructure, transition it to be owned (and paid for) by client

Project Overview & Working with Clients

23 / 40

summary

understand what's needed, and invite feedback create a clickable prototype, and invite feedback create a walking skeleton, to enable feedback

• integrate and deploy frontend/backend/database first
• client should be able to see and use fledgling app

iterate on features, and invite feedback (optionally) launch, and invite feedback hand off the project, and invite feedback

Project Overview & Working with Clients

24 / 40

agenda

• 1. narrative arc of a project
• 2. working with clients
• 3. picking a project
• 4. assignment 0: pitch preferences

Project Overview & Working with Clients

25 / 40

Working with clients

Clients are connected with some need that software might could meet You are connected with software development skills This can be a fruitful collaboration, if a bridge can be built between these two worlds

Project Overview & Working with Clients

26 / 40

A bridge from the client

Your responsibility is to understand the need the client brings What is the need? Why is it important? Who would actually benefit from software? What range of things would meet the need? (E.g. spreadsheets, a Trello board, etc.?) Story: creative solution to autofocus issue Is there a need under the need? Story: admin panel for managing whitelist of allowed users

Project Overview & Working with Clients

27 / 40

A bridge to the client

Your responsibility is to educate the client about software What can software do in general? What kinds of things are within the reach of your skills? What kinds of things are possible but would take a while? Note: some clients already understand software. But even they can't tell you what's within your reach.

Project Overview & Working with Clients

28 / 40

A healthy collaboration

A healthy client/developer relationship is one in which: the developer understands what the client wants the client listens when the developer talks about costs, constraints, and tradeoffs the developer trusts the client to temper their expectations in light of technical constraints the client trusts the developer to work diligently and be honest the client can make choices about priorities among features informed by developers indicating approximate effort e.g. that highly desired feature isn't as interesting if it's either that or 10 other less desired features

Project Overview & Working with Clients

29 / 40

Common dysfunctions

What are some common ways the relationship can be unhealthy? either party is not responsive when the other asks a question the developers use technical smokescreens to hide a lack of skill, an unwillingness to use a particular technology, or a problem the client doesn't really know what they want the client doesn't listen when you talk about tradeoffs and technical constraints the client doesn't understand or believe that such constraints are fundamental rather than a reflection of developer's lack of skill the client can't be bothered to make decisions about things

Project Overview & Working with Clients

30 / 40

Constraints and tradeoffs

A critical thing for both developers and clients to understand is that tradeoffs are everywhere in a creative project Pushing one interface element up the screen pushes others down Making everything highly noticeable can drain users' attention Getting faster servers costs more Spending more developer time working on feature A means there's less time for features B-Z These tradeoffs (and plenty more) are due to constraints: on screen space, on user attention, on money, on developer time, etc. Key insight: these are finite resources that can be exhausted d d l ll ll h d ff d l ll l d

Project Overview & Working with Clients

31 / 40

Technical debt

A classic tradeoff in software development is called technical debt Basic idea: taking shortcuts to get a feature done, with short-term benefit but long- term cost Example: skipping writing tests for a feature: it's done sooner, but more likely to break later Financial analogy of debt: swipe the credit card to buy something now, but then you have to pay cost and interest "Interest" in a software project creates "drag" on progress (same as credit card interest creates a drag on finances) Examples: slogging through an unorganized module, working around known problems with a function, dealing with an awkward aspect of the database schema, etc.

Project Overview & Working with Clients

32 / 40

Technical debt (2)

When to incur technical debt, and when to pay off the debt, is an ongoing conversation

• f healthy collaborations

Sometimes, it might be better not to expose clients to the concept:

• they have demonstrated a lack of interest in processes and tradeoffs
• they are already struggling to understand and appreciate tradeoffs and tech
• you are careful not to accrue technical debt

Note: technical debt is a useful tool, especially when the deadline looms Opposite problem of technical debt: overengineering the solution or pursuing elegance to the point of starving work on features YAGNI: Ya Ain't Gonna Need It

Project Overview & Working with Clients

33 / 40

agenda

• 1. narrative arc of a project
• 2. working with clients
• 3. picking a project
• 4. assignment 0: pitch preferences

Project Overview & Working with Clients

34 / 40

Picking a project

There are many valid ways to rank projects: clarity of the proposal maturity of the idea (e.g. are there UI designs already?) client flexibility/reasonableness/friendliness social impact of the project connections/influence of the client (e.g. can the client hire you after graduation if they like your work?) impressiveness of the project for your portfolio and interviews what languages, tools, and technologies you might be able to use or learn li t il bilit ( i ll i t t f b t )

Project Overview & Working with Clients

35 / 40

Rating clients

note that the next two class periods (Fri and Mon) are client pitch days clients will pitch their ideas, 6 minutes each, back to back, all day these pitches will be a blur! I recommend thinking (before class on Friday) about what's important to you write up a quick rating sheet, and rate each pitch immediately afterward, while it's fresh counters a natural bias to prefer either the first pitches (when you were fresh) or the last pitches (which are most recent in your mind)

Project Overview & Working with Clients

36 / 40

Poll: to Piazza or not to Piazza

I suspect we've all used Piazza at this point in this class, every project is different, so you're less likely to get help from others but maybe it's a comfortable place to ask questions also, it could be useful to find partners example: anybody else prefer to work on a Swift/iOS mobile app? so take the poll: pollev.com/jeffterrell

Project Overview & Working with Clients

37 / 40

agenda

• 1. narrative arc of a project
• 2. working with clients
• 3. picking a project
• 4. assignment 0: pitch preferences

Project Overview & Working with Clients

38 / 40

Assignment 0: pitch preferences

writeup on website due next Wednesday (Aug 19) at 8am

I/we prefer to prioritize the [team/project] preferences. My/our project preferences are: [list of 10 letters] Am I/Are we comfortable with an IP assignment and confidentiality agreement? [yes or no] My/our preferred teammates are: ["none" or list of 1-2 names]

You can submit a team of 4 at your own risk: I may break it up, depending. Please don't drop the class after submitting preferences!

Project Overview & Working with Clients

39 / 40

Questions?

40 / 40