項目管理trello

轉載來自    http://community.uservoice.com/blog/trello-google-docs-product-management/

Last fall I returned from vacation to find that UserVoice‘s Product Manager, Dejana, had replaced my precious Google Doc “Roadmap” with a Trello board.

It should be noted that my initial reaction to this new process was not positive. My issues weren’t really with Trello but rather how we were using it. Trello is a VERY open ended product. Trello, purposefully, doesn’t prescribe a “right” way to use it so it requires you to get inside and move the furniture around a bit to get it feeling like home.

However after much experimentation, I think we’ve finally arrived at a process we’re very happy with and I thought we should share how it works and what we’ve learned along the way. This will be a longer post than usual and, if you’re not into the process of delivering web products, probably a bit dry. If you prefer to skip directly to our lessons learned, I’ll be sad but not offended.

Our Process

Our development process spans 6 different Trello boards. The focal point of all of these boards is the Current Development board. The goal of all the other boards is to feed cards (representing either an enhancement or a bug, more on these in a minute) into the Current Development board and specifically into its Next Up column. The Next Up column is THE single prioritized list that all of the product team (developers & designers) looks at when they’re ready to take a new card to work on.

Before we dive into the role of all these different boards let’s talk about the blood cells in our product development circulatory system: Trello cards.

Cards

A card represents a single story to be implemented. It could be a new enhancement, a refactoring task or a bug.

Enhancement cards start out as a simple idea, 1-2 sentences long. But before they can move in development they’ll be expanded to include a link to a full-blown Google Doc “spec” and a set of wireframes or (rough) mock ups.

We use the term spec fairly loosely here. These aren’t the specs you remember from your college project course or that crappy enterprise IT consulting company you worked for right out of college. The spec explains the high level customer story, why (from a business perspective) we’re addressing this, what we hope to achieve, and maybe some notes on suggested implementation (though engineers may take or leave this section at their discretion; it’s supposed to be helpful not prescriptive). A good spec will also include first-hand customer stories and a link to the related idea on our UserVoice forums.

If the card is a bug then it simply has steps to reproduce the bug (which hopefully includes a screencast) and a link to the UserVoice Helpdesk ticket that originated it.

Here’s an example of what an actual “spec” looks like.

How the sausage is made

The Current Development board is the “where the magic happens” board. It has the following columns:

• Next Up
  • Prioritized list of all cards vetted and ready for design & development.
  • It’s worth noting that as a engineer or designer you’re not required to take the top card off the stack but rather the top card you feel most apt to handle.
• In Progress
  • These are the cards that are under active design or development.
  • Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.
  • When an engineer takes a card they assign a due date on it to let others know the “expected” delivery date of this card to QA. A quick scan of our board tells me that this rule is more aspirational than executed upon. 
• QA
  • When the engineer thinks they’ve completed the story, they’ll deploy it to staging (or sometimes to production but hide the feature behind a “feature flag”) and drag the card to QA.  At this point it our QA manager and Head of UX are responsible for taking a look and verifying that everything looks okay for this to go live.
  • As mentioned previously, If the card is an enhancement project that’s quite large we’ll spin up a whole new board dedicated to issues that came up during QA of that project. The project card will stay in QA until all the cards on the project specific QA board are done.
• Launchpad
  • These cards have been reviewed by QA and are ready to be deployed (but not necessarily launched, but more on that in a minute) and there’s probably a GitHub Pull Request associated with it (which will be merged into master by the person that opened the pull request. It’s worth noting that there is no central chokepoint for merging into master: everyone can do it).
  • If the card is a bug or refactoring task it will be deployed to production immediately (but not after 3p PST unless you, as the deployer, are willing to be around for the next 90 minutes to monitor any issues that come up).
  • If the card is an enhancement then it will be deployed to production but will be hidden from end-users by a “feature flag”. Feature flags are named conditional bits that can be turned on, on a per-account basis, to grant access to the new feature. We’ll immediately turn it on for our own UserVoice account and any customers selected by the customer team for early access but otherwise it falls to Marketing to turn on for all accounts when it’s officially launched.
• Live (Week #)
  • These cards have been deployed and are no longer hidden behind feature flags.
  • The only people who move cards to “Live” (essentially our Completed list) are the Product Manager (for enhancements) and the Bug Reporter (for bugs). This helps ensure that the feedback loop is completed before cards move out of sight.
  • Each week has it’s own Live column so we can track what got launched when.

In addition we use 3 labels that can be applied to a card:

• Bug
• Staging – Deployed to staging
• Production – Deployed to production

That was easy right? It’s very much a Kanban style approach to development. Now let’s dive into how cards get onto this board in the first place.

Mommy, where do cards come from?

New cards can come from one of 4 different boards:

• Product Roadmap
  • This has all the major projects for each quarter looking roughly 3 quarters ahead. These big projects are moved to the Planning board once that quarter begins.
• Inbox
  • There are two columns on here: one for ideas from anyone in the company and another for customer ideas (related to UserVoice Helpdesk support tickets or ideas submitted to our UserVoice customer feedback forums).
  • The ideas on this board are reviewed once a week during our Inbox Review meeting (see below for more details).
• Bugs
  • There are 3 columns here:
    • Inbox – unvetted reported bugs.
    • Needs input – We’ve had issues reproducing the issue and the original reporter needs to provide more info.
    • Accepted – Yes, this is almost most certainly a bug.
  • If a bug moves to Accepted and is considered “Critical” by the customer team (you can see how we decide that by reading our critical issue escalation process) then it moves immediately to the Current Development board and the “dev on call” is alerted.
  • If the bug is not critical it stays in Accepted until the Head of Customer Service moves it into the Next Week column which is the bugs that will be fixed next week (duh). The caveat is that he’s only allowed to pick 7 bugs per week. Why only 7 you ask? Because there are always bugs and the customer team always wants them all fixed but one of our major learnings was to set a constant throttle of how much time we’d devote to (non-critical) bug fixing.
• Engineering
  • We keep a list of areas that we think might need refactoring.  Each list is a category (eg, Backend, Frontend, Tests, Infrastructure), and each card is a refactoring project or other non-customer-facing project.
  • Engineers take small cards when they feel like it and add them to in progress; larger cards need to be planned in the Next Up list

Who said central planning doesn’t work? (Planning board)

The Planning board is where myself, our PM, and head of UX spend the majority of our time. It has the following columns:

• Next Up
  • This is our roughly prioritized list of the next projects we want to spec out for development
• Spec
  • This means “someone needs to write a spec”. The card at this point is usually just a rough idea.
  • We use Google Docs for specs and heavily rely on contextual comments to asynchronously discuss any contentious points with other members of the team. Any sufficiently complex contentious concept will be fleshed out in an impromptu design meeting (more on this in next section).
• Design
  • Means that the card needs a designer to take a look at it, duh. This doesn’t necessarily mean that a wireframe or mockup will be made as the design stage isn’t just about the look of it, but very much about taking the spec requirements and ironing out design concepts, usability, workflows, and impact on existing functionality – essentially vetting it and hammering out any show-stopping kinks before it goes into the dev cycle. (Also, if the spec needs to go back to the drawing board, it’s sent back to the Spec list.)
• Ready
  • We have spec that’s been reviewed by the idea creator and by the design team. We optionally have a wireframe or other needed artifacts. This is ready to be moved to the Next Up column on Current Development (after it’s reviewed at the Product Planning meeting).

On every other board cards move almost exclusively only from left to right but not on the Planning board. It’s not uncommon for a card to go from Design or Ready back to Spec one or more times before it’s finally moved to Current Development.

Our Meetings (or How cards get to moved between Boards)

We only have a few regular product meetings per week:

• Monday morning – Product Meeting (30 mins)
  • Attendees: Everyone in the company
  • This is our big all-hands meeting designed to make sure everyone knows what’s going on with the product and to celebrate the work of our product team members that went live. Our PM runs this meeting and it’s the only meeting that has a presentation built for it.
  • We’ll use one slide to review all the bugs that were fixed last week with avatars to show by whom. There’s a sense of pride of seeing your picture next to a big list of bugs fixed.
  • Each enhancement has its own slide that includes the avatars of all people involved in the project, the number of points this project was worth and a screenshot or (increasingly) a video. Whoever worked on an enhancement will take 20-30 seconds to explain what exactly was built.
  • PM or CEO present any new projects moved into Next Up and provide insight into what these cards are and why they’re a priority (the business case).
• Friday morning – Inbox Review Meeting (30 mins)
  • Attendees: PM and Head of UX – mandatory; everyone else – optional
  • If you submitted a card to Inbox board, in either the Customer or Internal column, you are expected to attend this meeting and introduce the story behind the card (you can learn more about how we think customer feedback processes should work here).  The goal is to help the rest of the team understand the associated use cases and pain points. In order to make sure we’re looking at the most pressing issues of the week, we limit the number of cards per person to 3.
  • The key to keeping this meeting focused: solutions are not discussed, only problems.
• Friday afternoon – Product Planning Meeting  (1 hr)
  • Attendees: CEO, PM, Head of UX, Lead Engineer
  • The goal of this meeting is to review all cards from the Planning and Engineering boards ready to move to the “Next Up” column on the Current Development board. For each card we move we’ll make sure there are no outstanding questions or concerns and we may discuss what the next step is (ex: do we need to build a prototype first?). Once all the “ready” cards are moved to Next Up we’ll re-sort the entire Next Up queue according to priority (yes, even cards that were at the top of the list last week may now be moved to the bottom).
  • We’ll also assign a level of effort estimate to each card. We measure the effort in terms of easy (1 star), medium (2 stars), hard (3 stars). This estimate is based on previous experience (as a company, not individuals): have we done anything similar before, how familiar are we with this domain, do we have any in-house experts, etc. We’ll use the cards to give engineers a sense of how much work is beyond this card and also we use it as a signal to the rest of the team how big of a deal a card is (during the product meeting) and to celebrate progress.
  • Finally we’ll review all the bug cards the customer team promoted to “Next Week” status. If a card doesn’t have enough info or if it’s going to take significant development time (more than a few hours) we won’t move it to “Next Up”. All cards we do move to “Next Up” go to the top of the queue before everything else. Above all else we want to make sure we’re always fixing what’s broken first.
• Every morning – Standup (10 mins)
  • Attendees: All product team members (designers, engineers & QA)
  • We do these over Skype MWF (we have two offices) and via HipChat on T-TH (our “quiet” days where no internal meetings are scheduled).
  • We try to drive standups to be discussion of what people need to accomplish their task rather than a boring “I did this; I’m doing this”.

That’s all of our “official” regular meetings but it’s worth mentioning that myself, our Head of UX & PM will often have impromptu 3 hour meetings where we have in-depth design discussions spanning multiple cards on the Planning board.

These impromptu design discussions usually happen later in the week (Thursday/Friday) once it’s clear there’s a difference of opinion on a couple cards we’ve been working on. These are some of our most productive (and for me: most fun) meetings that we have. Outwardly they may even seem less than productive as we often end up coming full circle on a design decision and end up right back where we started. But really it’s a (positive) sign that we truly understand the trade-offs we’re making with the path we’ve chosen: we’re making a decision from a position of understanding rather than blindly rushing in.

Lessons Learned

Always @mention someone in a card comment if you actually want a response  
If you write a comment without mentioning someone then that means you just meant this as a footnote for yourself for later. If you actually want someone to pay attention, you need to specify whom.

Have a single prioritized list for the product team to work from.
Initially there was a column of prioritized cards for each area of the product (admin console, onboarding,widgets, iOS, end-user web portal, emails). That might work if we had separate product teams for each subsystem but we don’t and it just lead to confusion about what really should be the next thing people should work on. It also was very unwieldy to look at and figure out what exactly the team was focusing on. (Protip: if you find yourself using a horizontal scrollbar often in Trello then you’re probably doing it wrong.)

Don’t have a separate system for bugs
Initially we maintained our previous bug tracker and used Trello for new product dev. This became problematic for many of the same reasons that the multiple columns failed us: once we have more than one list then prioritization breaks down.

Have a set amount of time per week that will be spent on bugs
We have roughly achieved this by setting a limit on the number of bugs we’ll accept into Next Up per week. This was a bit contentious at first but has resolved a lot of strife about whether a bug is worthy. The customer team is now empowered (or burdened) with choice of choosing which cards will move on. It’s the product development version of the Hunger Games.

Only add new cards to (and re-sort) the Next Up column once a week
This prevents Next Up from becoming a constantly shifting sand dune. Once the new projects are presented during the Monday morning you know where they are in the queue for the rest of the week. You don’t have to worry about the project you wanted to do falling to the bottom of the heap (and thus not actionable) in the middle of the week.

Good specs tell the (customer) and business story rather than act as an implementation recipe
For everyone to give a project their best they really need to be sold on why they’re doing it. This means trying to bring the customer pain point (or business pain) to the engineer that has to fix it.

Don’t try to do project estimates
Before, when we did actual sprints, we’d spend a LOT of time (almost a whole day per 2-week sprint) doing estimates and planning in a futile attempt to draw a line and say “We’ll get through all of these cards in the next two weeks”. It was a lot of work and it was almost always wrong anyways so instead we decided to embrace the uncertainty.

Try to celebrate what gets deployed
It’s easy to put people on a treadmill where there’s always something else to work on. We create a separate column for the cards that went live every week so it’s clear what we achieved this week. We also have the pictures of everyone who finished a task and a screenshot as part of our Monday morning meeting.

---

I hope you’ve found this useful. It’s one of those things that you evolve over time to the point at which every point in the process seems almost obvious but clearly isn’t. Well-deserved kudos to Dejana Bajic (PM), Joshua Rudd (Head of UX), and Jonathan Novak (Lead Engineer) for building such a solid process.

So what’s your product development process? What tips or hard lessons learned could we benefit from?