Tag: micromanagement


Mar
2014

Requirements Gathering: set up to fail

categories: Developer Hell

Without project requirements gathering, a project is nothing. One failure point is letting the wrong people gather the requirements.

Image courtesy Rebecca Dominguez (CC BY-NC-SA 2.0)

There are basically two types of requirements for an application project: the functional/feature-set and the technical.

Traffic ConePitfall: There must be at least one cycle of comparing Functional to Technical requirements to ensure they sync up, followed by adjustments to both (as necessary).

Functional

This answers the two questions:

  1. What will this application do?
  2. How will the user interact with the application to get #1?
function requirements gathering can specify oven-baked fries
Oven baked fries (source: Wikipedia)

If you want your application to feed the user by ordering from Fries-2-Go™, the 24-hour french-fry delivery service (fries in 27.5 minutes or you supersize for free!), that is #1. If  you say that the user will push the Big Red Button on the app, then say what flavor fries they want (Creamy Chicken Velouté, Herb Hollandaise, or Buttery Béchamel), that is #2.

Note that we didn’t say HOW this magic happens. That is not the purview of the Functional Requirements.

Traffic ConePitfall 1: the stakeholders (especially people who are representative of those who will use the app) MUST participate when crafting the requirements, especially any workflow.

Traffic ConePitfall 2: failing to involve an experienced technical architect during this phase may result in defining requirements that are not technically feasible, craft a clumsy/unwieldy workflow, or miss borrowing from solutions in similar applications.

Technical

These requirements are concerned with the plumbing, the hidden part of the iceberg and the underground kingdom of the Troll People. Functional requirements—from a high level—are absolutely required (see what I did?) to be defined before the technical requirements are attempted.

Traffic ConePitfall: any attempt by non-technical folks to attempt to work on these will result in flawed implementation, busted schedule, cost overruns and lowered team morale (lowered productivity).

Failure Examples

A high-level manager defined functional requirements with no input from field staff or technical architects. She then defined technical requirements based upon an internal standards white-paper, but without the understanding necessary to apply the standards to this project.

The technical staff was brought in at the last minute and told to review the requirements quickly so that work could begin. Immediately, the staff noticed several major flaws. For example, one of the functional requirements violated app store constraints, which would prevent the app from ever being accepted by the app store. In addition, the requirement was completely unnecessary, as there were external apps that provided the same features.

The manager (perhaps to save face) ordered the project proceed with the original functional requirements intact. This resulted in a product that cost more than necessary, it could not be distributed via well-known app stores, and it contained useless and confusing functionality.

Enhanced by Zemanta

Jul
2012

Don’t Call Yourself A Programmer

categories: web development

I’ve always hated the term “Programmer.” Like a craftsman, I’m a Developer.

Patrick McKenzie has a great writeup on this:

Engineers are hired to create business value, not to program things: Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs.

…

Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.

I’ll add that adding perceived business value is also a goal (playing off McKenzie’s “Businesses do things for irrational…reasons”). If your boss feels happy, then you’re doing the right thing. Most of the time.

Where we run into trouble is when the boss is a micro-manager, is inexperienced and/or plain-ol-wrong. What do you do? As a professional, speak up and say what’s on your mind, diplomatically. Then do whatever the boss says, cheerfully.

Is this always the best solution? Sometimes it is and sometimes it is not. The boss that thinks for his employees is doing exactly the wrong thing, though:

by Kathy Sierra
“The more you use the reins, the less they’ll use their brains.”