Marked done, and a rep still could not take an order

You were told the orders module was done. Your reps visit customers all day with a phone in their hand, and the whole point of the system is that they take the order there and then. A rep stands in a customer’s shop, opens the app, and cannot create an order. Not a rough version — there is no order screen at all.

Nobody had lied. The order module really was complete on the server: pricing, stock, numbering, permissions, forty automated checks. Every one of those things was true. What was missing was the one thing the rep needed, which was a screen.

The cost of this is not one screen. It is that the project’s progress tracker had been counting work like this as finished for months. When progress was worked out again by actually using the product rather than reading the tracker, the real figure was roughly half of what the tracker said. Plans and dates had been built on the comfortable number.

What was actually going on

Software like this is built in layers — the server, the web portal for the office, the phone app for the field — and the natural unit of a day’s work is one layer. Somebody spends a day on the server side of orders. That is a real day of work, and marking it done is honest about the day. It is wrong about the feature, because the person the feature is for has not got it yet.

The same shape turned up elsewhere once we looked. A sales pipeline had shipped as a complete server with no screens at all. Administration pages for roles and settings worked, but nothing linked to them, so nobody could reach them by clicking — which also meant nobody could test them.

Worse were the screens that looked finished and were not. Several lists in the office portal had a search box that accepted text and did nothing with it, because the server had no search for those records. An absent search box tells a user the capability does not exist. A box that does nothing tells them it exists and is broken — and they will use it, and trust results that were never filtered.

What we changed

The definition of “done” was written down and made to cross the layers: server, office portal, phone app, permissions, checks and translations, and a module is not done until a user can reach it. If the sentence describing what is finished does not have a person in it, it is not a completion report.

Progress is now measured by driving the product, and re-measured rather than accumulated. A tracker records the last thing somebody said. Using the application records what is true. The seeded demo data turned out to be missing a price list, which meant every attempt to create an order was rejected — invisible to every automated check, because the checks made their own data.

The search boxes that did nothing were removed rather than left in place, and the roughly fifteen gaps on the server that they had been papering over were written up as work to do. Where a screen could not honestly show what its heading promised, it was relabelled to say what it actually shows — a payments panel that could only show customer-level figures says so, rather than implying it is per order.

And the office portal’s list screens were brought up to one standard in a single pass rather than piecemeal: sorting only on columns the server actually supports, pickers instead of raw ID boxes, actions that respect what each record is — an order is a workflow and does not get an edit button, an invoice can be edited only while it is a draft. Nineteen browser pop-up confirmations across the product were replaced with a proper component, which sounds cosmetic and is not: a native pop-up cannot be translated or show progress, so every destructive action had been untranslated and silent while it ran.

What it did not fix

None of this is a tool you can buy. It is a definition of done that the person paying for the work has to insist on, and a habit of measuring progress by using the thing rather than reading about it. The tracker did not become accurate; it became something to check against the product, which is the most a tracker can be.

Where this ends up

A rep with a phone in a customer’s shop is the point of a field-sales product, which is why Sazinga Field treats the order taken there and the order the office sees as one record, rather than as two features on two layers.