Sollten Sie Daten nach Excel und Word exportieren?

Der Export nach Excel ist eine Lösung, keine Voraussetzung. Sie müssen zu den Eigentümern zurückkehren und sie dazu bringen, ihre funktionalen Anforderungen an die Daten zu erläutern. Wenn Sie fertig sind, übergeben Sie es an die Entwickler und lassen Sie sie eine Lösung vorschlagen. Es kann am Ende Excel sein, weil es, wie Sie geschrieben haben, bereits vorhanden ist, oder es könnte eine andere Lösung sein, die die Anforderungen erfüllt.

Sie müssen jede Lösung mit ihren Vorteilen, Kosten, Risiken und anderen Nachteilen vergleichen. Die Tatsache, dass Excel bereits vorhanden ist und sie wissen, wie man es verwendet, ist sicherlich ein Vorteil, aber die Eigentümer kennen möglicherweise einige der Strafen nicht oder unterschätzen die Auswirkungen, die ihnen durch die Verwendung von Excel entstehen, und sind langfristig unzufrieden . Im Gegensatz dazu kostet das Erstellen einer neuen Lösung Geld und Zeit, und sie müssen es lernen – Kosten und Strafen –, aber es kann die Auswirkungen von Excel heilen und sie auf lange Sicht glücklich machen.

Nichts davon weißt du noch; Dies muss analysiert und für jede Lösung ein Fall erstellt werden. Aber alles beginnt damit, die richtigen Anforderungen von den Eigentümern zu erhalten.

Ob es sich lohnt, ein Excel zu haben (geschäftlich) oder nicht, ist grundsätzlich nicht Sache des Entwicklungsteams. Sie müssen in der Lage sein zu sagen, ob es machbar ist, und objektiv sagen, was die Vor- und Nachteile sind (dh es wird nicht funktionieren, wenn Sie mehr als 1.000.000 Datenzeilen haben), sie können den Kunden auch darüber beraten, ob dies wirklich der Fall ist ihr Problem löst oder nicht (und wenn nicht, konstruktiv in der Lage sein, eine andere gültige Lösung vorzuschlagen), aber sie können sich nicht weigern, ein Feature zu implementieren, nur weil sie denken, dass es wertlos ist.

Das heißt, vielleicht wurde das Problem nicht genug analysiert, und das Entwicklerteam und der Kunde sind eindeutig noch nicht auf derselben Seite; Ich persönlich würde sie also zusammenstellen, damit sie das Problem besser verstehen und zusammenarbeiten können, um die beste Lösung zu finden. Der Kunde hat seinen tatsächlichen Bedarf möglicherweise nicht vollständig zum Ausdruck gebracht, und das Entwicklungsteam kann vielleicht auf eine andere Idee kommen ...

Ich würde meine Denkweise ändern von "Wie kann ich sie überzeugen?" zu "Möchte der Benutzer wirklich nach Excel exportieren?" und "Welche Lösung wäre, meinen Kunden glücklicher zu machen und gleichzeitig Geld zu verdienen?"

1. Sprechen Sie mit den Beteiligten. Sie denken vielleicht an Excel als vertraute Methode, um die Funktionalität zu beschreiben. (Eine Lösung, nicht die Anforderung). Aber sie könnten Excel trotzdem bevorzugen (eine direkte Anforderung). In diesem Fall:
2. Suchen Sie nach Alternativen. CSV-Dateien können beispielsweise von Excel geöffnet werden und sind einfacher zu vergleichen. Sie können unter Linux und Mac verwendet werden und sollten einfacher zu entwickeln sein.
3. Machen Sie dem Kunden klar, dass Sie jede gewünschte Lösung anbieten. An diesem Punkt machen Sie sich keine Sorgen darüber, mehr Stunden zu arbeiten. Sie sind besorgt darüber, eine Lösung zu entwickeln, die für sie möglicherweise nicht funktioniert. Anschließend können Sie über die Kosten sprechen, wenn dies ein Problem darstellt.
4. Stellen Sie sicher, dass der Kunde die Probleme versteht. Sie könnten beispielsweise zwei Dummy-Excel-Dateien erstellen und ihnen mitteilen. "Wie würden Sie sie vergleichen?"
5. Überprüfen Sie, ob die Daten zu groß für Excel sind, und einige konservative Leistungsmetriken (es kann eine Stunde dauern, um in einem nächtlichen Batch-Prozess nach Excel zu exportieren).
6. Fragen Sie "Was haben Sie mit diesem Excel vor?". Eine Sicherung? Sie sollten in der Lage sein, die Datenbank zu sichern. Ein Bericht? Könnten Sie den Bericht automatisch erstellen?
7. Sobald der Kunde eine Entscheidung getroffen hat, senden Sie das Protokoll, um einen schriftlichen Beweis dafür zu erhalten, dass er die Konsequenzen akzeptiert hat. Stellen Sie sicher, dass die E-Mail leicht auffindbar ist.
8. Erklären Sie dem Entwicklungsteam, dass dies eine direkte Anforderung des Kunden ist. Nicht von Ihnen selbst und Ihren Bemühungen, nach einer besseren Lösung zu suchen. Danke ihnen für ihren Beitrag. Selbst wenn der Kunde unflexibel war, sind Sie besser dran, wenn Sie die potenziellen Probleme vorher erklärt haben.

Ich arbeite in einem sehr kleinen Büro und muss viele der Scrum-Rollen selbst besetzen, also muss ich die Seiten und Argumente für solche Entscheidungen in meinem Kopf abwägen, diese Entscheidung war für mich eine einfache Entscheidung, obwohl das Backend Der Typ konnte die Aufgabe nicht erledigen (ich mache jetzt meine eigene).

Ich habe neben einer CSV-Kopie von Flash-Datentabellen XML-Tabellen für Excel basierend auf dem erstellt, was tatsächlich in einer Actionscript-Datentabelle angezeigt wird (eine riesige Zeichenfolge, die in einen als .xml gespeicherten Notizblock eingefügt wird).

Die Erstellung von Excel-Tabellen im Backend ist trivial. Ich kann mir kein Szenario vorstellen, bei dem es sich lohnt, darüber zu streiten, anstatt nur die Anfrage zu erledigen. Sogar die Umwandlung der 1-Datentabelle in eine 3-Blatt-Excel-Datei mit Parameterdaten und Haftungsausschlüssen war nicht besonders schwierig.

Ich arbeite sehr eng mit Kunden zusammen, aber ich bin mir nie 100 % sicher, was alle ihre Endanforderungen sind. Wenn ich ihnen Excel-Ausgaben gebe, können sie 80 % aller möglichen Verwendungen und Interpretationen der Daten für 20 % des Aufwands übernehmen.

Wichtig war nicht, das Excel in die Software zu bekommen, sondern das eigentliche Problem aus dem Team herauszuholen.

Denken als Techniker Wenn die Informationen in einer Datenbank mit einer bestimmten Beschreibung gespeichert werden, ist es in der Regel nicht allzu schwierig, den Benutzern Lesezugriff auf die Tabellen zu gewähren, die sie sehen möchten, und sie dann die Daten direkt aus Excel importieren zu lassen, wobei die Anwendungsfront umgangen wird -end (Entwickler müssen nichts tun) entweder mit Excel-Datenimportfunktionen oder mit benutzerdefinierten VBA-Skripten.

Denken als Manager Sprechen Sie mit Ihrem Business Analyst, um die Anforderung in einer sinnvollen Form hinzuzufügen, oder bitten Sie alternativ den Product Owner / Projektsponsor / Chef wie eine Person, die Arbeit zu priorisieren. Es hört sich so an, als ob Sie sich in einem „Lösungsdenken“ befinden, was nicht die Aufgabe eines PM ist. Nur weil Menschen Excel lieben, heißt das nicht, dass sie tatsächlich eine Export-zu-Excel-Funktion benötigen, manchmal kann dies zu Sicherheitsrisiken führen.

Sie könnten einfach Gas geben und dem Kunden geben, was er will, aber solange die Entwickler nicht verstehen, warum das Feature nützlich ist, werden sie es wahrscheinlich nicht auf sinnvolle Weise implementieren. Sie werden Ihnen einen sinnlosen Excel-Export geben, der nicht verwendet wird, und sie werden sagen: "Sehen Sie, ich habe es Ihnen gesagt".

Ich denke, das Beste ist, die Kluft zwischen den Benutzern und den Entwicklern zu überbrücken. Nehmen Sie ein paar Entwickler, vorzugsweise diejenigen, die dem Front-End am nächsten sind und die am „menschenfreundlichsten“ sind, und lassen Sie sie die Benutzer einen Tag lang beschatten . Lassen Sie die Benutzer ihnen zeigen, was sie erreichen wollen und warum es für sie nützlich ist. Im schlimmsten Fall stellen Sie sicher, dass die Funktion tatsächlich das tut, was die Benutzer wollen (und nicht das, was sie sagen, dass sie es wollen) und im besten Fall erreichen die Benutzer und Entwickler eine kreativere Lösung, die das Problem wirklich löst.

Schließlich ist es nicht die Aufgabe des Benutzers, die Software zu entwerfen, und es ist nicht die Aufgabe des Entwicklers, die Anforderungen auszuwählen. Sie müssen zusammenarbeiten, um etwas Wertvolles zu schaffen.

Wenn Sie es dann wirklich richtig machen wollen, bringen Sie die Benutzer und die Entwickler dazu, einige Mockups zusammen zu verdrahten. Testen Sie diese Mockups an anderen Benutzern, um sicherzustellen, dass sie sie verstehen, und besprechen Sie sie dann mit dem Team, bevor Sie sie implementieren.

Letztendlich ist dies die Art von Dingen, die Ihr Interaktionsdesigner / UX-Manager tun sollte. Es ist verständlich, wenn Sie keine davon haben, aber ich empfehle, darauf hinzuarbeiten, eine zu haben. Nehmen Sie dies als Übung. Senden Sie drei Entwickler, um mit den Benutzern zu interagieren. Wählen Sie diejenige aus, auf die die Benutzer am besten reagiert haben und die die Übung am meisten zu mögen schien, und beginnen Sie damit, ihm/ihr mehr Design-ähnliche Verantwortung zu übertragen. Nicht Design wie beim Photoshopping, wie die Schaltflächen aussehen sollten, sondern Design wie beim Sammeln von Benutzergeschichten, Mockup und Benutzertests potenzieller Funktionen und Zusammenarbeit mit den anderen Entwicklern, um die Implementierungsdetails herauszufinden.

Das Exportieren großer Datensätze nach Excel kann sehr leistungsfähig sein und Ihre Anwendung für viele weitere Benutzer noch wertvoller machen. Excel verfügt über einen so reichhaltigen Funktionsumfang, dass der Versuch, es zu duplizieren, eine Verschwendung des Branchenwissens Ihrer Entwickler wäre.

Benutzer können in Excel auf nahezu beliebige Weise filtern, sortieren, Diagramme erstellen und Pivots erstellen. Können Sie jeden möglichen Workflow definieren, den die Benutzer benötigen, und ihn Ihrer App hinzufügen? Was ist mit dem Benutzer, der Daten erkunden und einige nicht offensichtliche Pivots ausprobieren möchte?

Bei großen Datensätzen stellt sich die Frage, wie groß? Der Export in eine Datenbank für Business Analytics ist möglicherweise die bessere Wahl, wenn der Datensatz groß genug ist, um Excel zu ersticken. Mehr Daten geben mir eine größere Stichprobengröße und Vertrauen, daher sehe ich dies nicht als negativ an.

Was mobile Benutzer betrifft, weiß ich nicht, dass ich auf meinem iPhone umfangreiche Analysen durchführe. Wenn ich Berichte auf meinem Handy bekommen kann, her damit. Lassen Sie sich davon nicht aufhalten!

Abschließend stimme ich Grimm dem Opiner zu 100 % zu: „Das Scrum-Team kann nicht entscheiden, was eine Benutzeranforderung ist oder nicht“. Dies liegt ganz klar beim Product Owner.