Wissensmanagement: Welche Dokumente werden benötigt und was muss in ihnen repariert werden?

Der Dokumentationsprozess entspringt evolutionär aus mittleren Kommentaren im Code, wenn ein Unternehmen wächst. Irgendwo mitten auf der Straße tauchen normalerweise Leute auf, die sagen, dass sie wissen, wie man es richtig macht, und dass „dieses Buch sagt, wie man Dokumentation macht“, und sie bringen einen schwierigen Prozess in das Unternehmen. Darüber hinaus gibt es Diskussionen, Streitigkeiten, Links zu verschiedenen Quellen mit widersprüchlichen Ansätzen und so weiter. In der Tat ist das alles nicht zufällig. Jedes Mal, wenn wir auf solche Momente stoßen, bedeutet dies, dass es kulturelle Unterschiede gibt. Trends ändern sich und jede Ära gibt ihre eigenen Lehrbücher.

Unter dem Schnitt werden wir zusammen mit Maxim Tsepkov verstehen, welche Lehren aus verschiedenen Ansätzen gezogen werden können, wie Projektdokumente entworfen werden, was in ein Wiki eingefügt werden soll, wofür Google Text & Tabellen geeignet ist und was immer vor Ihren Augen sein muss. Wie auch immer, warum brauchen wir all diese Dokumentation? Gleichzeitig werden wir das Thema Wissensmanagement ansprechen.

Kulturprojektprogramme

Die Geschichte der IT-Branche ist in Phasen und Epochen unterteilt, von denen jede ihren eigenen Ansatz für das Projektmanagement hat: ihre eigenen Vorstellungen von Erfolg, Qualitätskriterien und Arbeitsorganisation. Anthony Lauder schrieb 2008 das Buch "Culture of Software Projects" (Links zum Original , Übersetzung und Rezension von Stas Fomin ), in dem er vier Perioden identifizierte:

• wissenschaftlich;
• Fabrik;
• Design;
• Servicekultur.

Jeder von ihnen beeinflusste Ansätze zur Verwaltung von Softwareprojekten. Und niemand dachte an Konsistenz miteinander.



Über den Redner: Maxim Tsepkov IT-Architekt und Business Analyst, Navigator und Experte in der Welt von Agile, türkisfarbenen Organisationen und Spiraldynamik.

Ich verwende eine etwas andere Periodisierung, die bis heute erweitert wurde. In dem von mir vorgeschlagenen Schema hat sich vor allem der Umfang des Projekts geändert. In der F & E-Ära war es wichtig, dass das IT-System funktionierte, in der RUP-Ära - dass es pünktlich und in der Agile-Ära durchgeführt wurde -, dass es das tut, was der Kunde braucht, und nicht nur funktioniert, weil sich herausstellte, dass sie oft das Falsche getan haben.

In der heutigen Zeit sollte ein IT-Projekt eine Lösung für geschäftliche Probleme bieten und die Interessengruppen zufrieden stellen. Es spielt keine Rolle, welches der kulturellen Teilungsschemata tatsächlich korrekt ist, es kann jedes verwendet werden, da die Unterschiede nur in den Details liegen.


Es ist jedoch wichtig zu verstehen, dass die meisten Lehrbücher zur Dokumentation in der RUP-Ära verfasst wurden, in der die Organisation des Prozesses darauf abzielte, das Budget und die Fristen einzuhalten. Dies funktionierte nicht, aber die Lehrbücher blieben und sie schrieben keine neuen Lehrbücher .

Agile schwang zu Beginn seiner Entwicklung das Pendel in die entgegengesetzte Richtung und kündigte an, dass funktionierende Software viel wichtiger ist als Dokumente. Und dann gab es private Formate: User Story, Anwendungsfälle, private Praktiken, Story Mapping usw., die sich in den Dokumenten widerspiegelten. Sie haben jedoch keine umfassenden Lehrbücher zu diesem Thema geschrieben, weil sie verstanden haben, dass die Lehrbücher nicht funktionieren.

Jetzt haben wir festgestellt, dass die Projekte unterschiedlich sind und es definitiv keine universellen Rezepte gibt - wir müssen das tun, was angemessen ist. Sie müssen jedoch nicht von Grund auf neu erfinden, sondern Vorlagen und Beispiele auf die gleiche Weise verwenden, wie dies beispielsweise beim Interface-Design der Fall ist. Die Schnittstellen sind unterschiedlich, insbesondere bei mobilen Geräten mit kleinem Bildschirm müssen Sie platzieren, was jetzt für die Aufgabe wichtig ist, es gibt keine universellen Dinge. Es gibt jedoch einen Styleguide , der intuitives Lernen, Muster und Übungen bietet.

Bei der Entwicklung eines Styleguides konzentrieren sie sich auf UX. Die Dokumentation ist dieselbe - im Doc Style Guide des Projekts.

Ich hoffe, dass der Bericht Grundsätze und Konzepte enthält, auf deren Grundlage Sie die Situation verbessern und Probleme mit Dokumenten in Ihrem Projekt lösen können.

Dokumente - zur Kommunikation

Die Hauptidee, von der ich ausgehe, ist, dass Dokumente nicht selbst wertvoll sind, sondern Kommunikation bieten. Genau wie die Schnittstellen selbst keine Rolle spielen, bieten sie dem Benutzer die Funktionalität, die auf der Serverseite verborgen ist.

Die Form von Dokumenten sowie Schnittstellen wird aus den Zielen der Kommunikation entwickelt.

Hierbei ist es wichtig, dass bei Langzeitdokumenten die Kommunikation über die Zeit verteilt ist. Heute schreiben Sie sich in Zukunft einen Brief, in dem Änderungen an der Funktion, die Sie gerade ausführen, erneut vorgenommen werden müssen. Wenn Sie nach anderthalb Jahren zu ihr zurückkehren, denken Sie daran, finden Sie es heraus. Entweder kann es sich um einen völlig anderen Entwickler oder Benutzer handeln, der Ihr System bedient.

Und wenn das Dokument für die Kommunikation benötigt wird, sollte es gezielt eingesetzt werden . Damit kommunizieren wir mit bestimmten Menschen und senden nicht in die ganze Welt. Daher teilen wir die Dokumente nach Zweck und Adressat auf:

• zur Entscheidungsfindung;
• aktuelle Kommunikation;
• Erhaltung des Wissens in der Zeit ("für mich in sechs Monaten");
• Wissenstransfer an andere Menschen;
• Hilfe bei der aktuellen Arbeit usw.

Jedes Ziel hat seinen eigenen Beschreibungstyp, - Standpunkt - seine eigene Beschreibungsmethode .

Dokumentqualitätskriterium

Das Qualitätskriterium ist, wie das Dokument die Kommunikation unterstützt, für die es erstellt wurde. Die Klarheit des Dokuments für alle Kommunikationsparteien ist wichtig , was die Komplexität der Notationen begrenzt. Wenn wir dem Kunden Klassendiagramme, Geschäftsprozesse und den Dokumentstatus präsentieren, dürfen wir nicht vergessen, wer die Dokumente lesen wird.

Klassendiagramme in UML sind ein sehr kompliziertes Notationskonstrukt, das in einfacher Form, wenn nur Klassen und Beziehungen gezeichnet werden, fast intuitiv ist. Wenn das Diagramm dann mit allen möglichen zusätzlichen Symbolen geladen wird, wird es schnell nur für den Autor und die Entwickler verständlich. Sie denken, dass sie die Bedeutungen vermittelt haben. Und der Kunde glaubt, dass die Entwickler hier einige Notizen für sich gemacht haben, die keinen Sinn ergeben, aber sie können sie nicht löschen. Gleichzeitig sollten vereinfachte Systeme wichtige Punkte bewahren . Es lohnt sich, alles zu verwenden, was angesammelt wurde: Hypertext, Links, Texte, Grafiken, Audio, Video, um effektiv zu sein.

Schemata und Modelle sind viel effektiver als Text , da die natürliche Sprache nicht eindeutig ist. Die Erfahrung zeigt, dass Schemata und Visualisierungen viel weniger verzerrt und falsch interpretiert werden als Text. Den Schemata müssen jedoch Beschreibungen beigefügt sein, die vor allem den Inhalt nicht duplizieren, sondern das Wesentliche erklären.

Es ist notwendig, ein Wörterbuch mit Konzepten zu erstellen, eine einzige Projektsprache, aber es ist wichtig, nicht die Begriffe, sondern den Inhalt zu diskutieren. Sie müssen nicht darüber streiten, wie Sie das Wort für ein Konzept verwenden sollen. Wir müssen darüber streiten, welche Konzepte und Objekte wir in diesem Themenbereich haben, und sie hervorheben. Zum Thema terminologischer Pluralismus und zu seinen Herangehensweisen gibt es in den Vorlesungen über systemtechnisches Denken von A. Levenchuk gute Fragmente.

Der nächste wichtige Punkt, den Sie beim Entwurf eines Dokumentationssystems beachten sollten: „Warum“ und „Warum“ sind wichtiger als „Was“ . Der Anwendungsfall beschreibt, was im System getan werden muss, und in der User Story gibt es einen „Warum“ -Teil: „Als <> möchte ich < -> , um < > zu < > “. Darüber hinaus kann dieses User Story- Format als Vorlage betrachtet werden, d.h. Alle Teile müssen sein. Sie sind nicht sofort aus der Erfahrung hervorgegangen, aber jetzt wissen wir, dass das „Warum“ sehr wichtig ist. Das Ziel der User Story, das Ziel aller Anforderungen ist die zeitlich verteilte Kommunikation des Kunden (Anwenders) mit dem Entwickler und Analysten als Vermittler.

In dieser zeitverteilten Kommunikation ist es sehr wichtig, die Bedeutungen zu vermitteln, damit der Entwickler bestimmte Entscheidungen treffen kann. Es gibt immer unvorhergesehene Alternativen: durch die Position der Schaltflächen im Formular, durch den Code, durch die Flexibilität, durch die Allgemeinheit der Lösung. Wenn die Entscheidung kritisch ist, wird der Entwickler natürlich unterbrechen und klären. Aber es ist besser, dass er in diesem Moment die Geschäftsaufgabe selbst festlegen und eine Entscheidung treffen kann - eine Unterbrechung des Codierungsprozesses ist teuer. Die Antwort auf die Frage „Warum“ in der Dokumentation hilft sehr, deshalb ist sie erschienen.

Die Lektion über „Warum“ und „Warum“ sollte berücksichtigt werden, auch wenn Sie andere Formate verwenden, um die Ziele von Benutzern und Unternehmen ausgehend von den Projektzielen festzulegen. Und dann kommt der Inhalt der Ziele des Projekts oft auf "Geschäft aus irgendeinem Grund ist notwendig".

Keine Notwendigkeit, blind seltsame Dinge zu tun, die das Unternehmen nicht versteht, warum sie wollten. Normalerweise hat er völlig rationale Gründe, nach denen sich herausstellt, dass völlig andere Dinge getan werden müssen.

Wir entwerfen Projektdokumente

Wie entwerfe ich? Wie jedes andere System. Die wichtigste mentale Sache, die Sie an sich selbst ändern müssen, ist, dass Sie die fertige Vorlage nicht nehmen und kopieren müssen, sondern eine neue entwerfen müssen, wie Sie dies mit Schnittstellen tun. Es ist notwendig, die Schnittstellen Ihres Systems unter Berücksichtigung der Vielfalt zu übernehmen und zu entwerfen.

Als nächstes heben wir die Kommunikationsfälle hervor und bestimmen die Dokumente, die sie unterstützen. Wenn die Kommunikation über einen längeren Zeitraum verteilt ist, benötigen Sie eine Person, die für die Pflege der Dokumente und die kompetente Annahme der Dokumente verantwortlich ist. Wenn wir nach 3 Jahren feststellen, dass die Beschreibungen beispielsweise nicht sehr verständlich sind, wird dieses Feedback etwas verspätet sein und es wird niemanden geben, der es übermittelt.

Im weiteren Verlauf des Nutzungsprozesses bewerten wir die Qualität und verbessern sie auf die gleiche Weise wie Usability und UX.


Zum Entwerfen benötigen Sie Schaltungen. Ein praktisches Schema ist das V-Modell , das die Projektkette als Beispiel für die Abstraktion zeigt und dann das Ergebnis liefert.


Wenn wir in diesem Modell die klassischen Artefakte der Interaktion zwischen dem Kunden und dem Team platzieren, gibt es: Anforderungen, Entwicklungsaufgabe, Testfälle, PMI , Versionen. Die Artefakte werden einen verantwortungsvollen Rückstand haben.

Nicht die Tatsache, dass Sie diese Dokumente benötigen. Dies gilt insbesondere für die Anforderungen und Entwicklungsaufgaben.

Es gibt zum Beispiel eine Alternative - Domain-Driven Design, nach der anstelle von Anforderungen und Entwicklungsaufgaben ein Systemmodell als kollektives Artefakt verwendet wird. Das Modell spiegelt das System wider und wird einerseits von Analysten und andererseits von Entwicklern durchgeführt.


Es gibt viele solcher Optionen und Praktiken. Alle von ihnen sind eng mit dem Entwicklungsprozess verbunden, da dabei Kommunikation entsteht. Schauen Sie sich Ihren Prozess an und machen Sie Artefakte dafür geeignet.


Das V-Modell ist ein Erbe der F & E- und RUP-Epochen. Seitdem haben sich die Kulturen verändert und das moderne Design ist viel breiter. Anstelle des Konzepts entstanden Dinge wie Benutzeranforderungen und Geschäftsmöglichkeiten. Auf der rechten Seite gab es anstelle einer einmaligen Wartung eine Lieferung der nächsten Version und einen kontinuierlichen Support rechtzeitig.

Anforderungen

Es gibt normalerweise ein Schlüsselartefakt zwischen dem Konzept und dem Start des Projekts - das Konzept oder die Vision , die die Startposition des Projekts erfasst. Wir werden mit dem Konzept korrelieren, während sich das Projekt entwickelt, aber am wichtigsten ist, dass auf seiner Grundlage zu Beginn eine Entscheidung getroffen wird, ob das Projekt übernommen werden soll oder nicht.

Wie viel das Konzept oder die Vision im Detail ausgearbeitet werden soll, wird funktional festgelegt: Das Dokument sollte so kurz wie möglich sein, weil schnell, aber damit die Stakeholder eine Entscheidung über den Start des Projekts treffen. In der Regel sollte das Konzept Folgendes widerspiegeln:

• Projektidee - eine Chance für Unternehmen: Was, für wen und wie?
• die Machbarkeit und Machbarkeit der Idee;
• Interessen und Erwartungen der Hauptakteure an das Projektergebnis;
• Produktdesign und Verwendungszweck;
• Einschätzung der für das Projekt benötigten Ressourcen.

Darüber hinaus können sich Interessen und Erwartungen ändern, und wenn dies geschieht, ist es wichtig, dies rechtzeitig zu beheben.


Bei der Bearbeitung von Anforderungen ist beispielsweise die Außengrenze des Projekts wichtig. Mit dem Kulturwandel änderten sich die Vorstellungen darüber von Funktionen als Teil des Systemdesigns (in der F & E-Ära) zu Funktionen als Funktion eines Systems, das etwas in sich selbst tut, und jetzt ist eine Funktion ein Wert für Benutzer. Dies sind verschiedene Ebenen von Artefakten, für die verschiedene Spezialisierungen verantwortlich sind: Architekt, Systemanalyst, Geschäftsanalyst. Dies ist jedoch ein funktionaler Ansatz für das System.

Wenn wir über die Zufriedenheit der Benutzer sprechen, wurde dort auch eine Reihe von Spezialisierungen angezeigt: ein UI-Designer, der für die Zufriedenheit der Benutzer mit dem Erscheinungsbild, der Benutzerfreundlichkeit - über die Verwendung verantwortlich ist, und ein UX-Spezialist, der an der intuitiven Benutzerfreundlichkeit der Benutzeroberfläche arbeitet. Diese Grenze verschiebt sich ebenfalls. In Ihrem spezifischen Projekt kann dies anders sein, da die Unternehmensentwicklung eine Sache ist, für die es ein Schulungssystem gibt, und der Benutzer wie ein 1C-Buchhalter nirgendwo hingehen wird, da dies sein Arbeitsplatz ist. Und noch etwas ganz anderes, zum Beispiel die mobile Entwicklung. Wenn die Fluktuation des Filialpersonals so ist, dass der Verkäufer oder Ladenbesitzer durchschnittlich 3 bis 6 Monate arbeitet, ist die Frage relevant, ob eine mobile Anwendung für die Arbeit in 2 Tagen und nicht in 2 Wochen Schulung entwickelt werden soll.


Die Aufrechterhaltung der Anforderungen sollte mit dem Testansatz übereinstimmen und umgekehrt. Wenn Sie die klassischen Anforderungen von Anforderungen und Architektur haben, ist testgesteuertes Design möglich und verhaltensgesteuertes Design unwahrscheinlich. Weil BDD sicherstellen soll, dass Sie ein Szenario für Benutzer formulieren, dh auf einer höheren Abstraktionsebene. Wenn die Anforderungen kein Szenario enthalten, gibt es keinen Ort, an dem sie übernommen werden können. Solche Beziehungen müssen berücksichtigt werden, und die Kosten für die Wartung und Überprüfung von Testfällen sollten kontrolliert werden .

Benutzerdefinierte Fokusartefakte

Eine separate Klasse von Artefakten für den alltäglichen individuellen Fokus. Dies sind beispielsweise die Schaltkreise, die gedruckt werden und vor dem Entwicklerraum hängen . Eine von Agiles Lektionen: Ein Task Board und ein Burn-Down-Diagramm , die physisch in einem Raum hängen oder mit Hotkeys in elektronischem Format konfiguriert sind, sind sehr hilfreich. Ein abgelenkter Blick in Gedanken haftet versehentlich und die Informationen werden ständig aktualisiert. Ebenso bei architektonischen Entwürfen wichtige Prinzipien.

Es stellt sich heraus, dass, wenn Sie alles Empfohlene an die Wände hängen, diese so aufgehängt werden, dass die Bedeutung der Fokussierung auf das Dokument, bevor Ihre Augen verloren gehen, in der Masse, die sie als Hintergrundbild wahrnehmen, verloren geht. In diesem Sinne die Frage "Was soll man an die Wände hängen, welche Artefakte werden immer vor Ihren Augen sein?" Ist auch ein Designproblem, das angegangen werden muss. Natürlich sollte genau das hängen, was wichtig ist.

ER-Diagramme, ein Schichtdiagramm der Anwendung oder der Hauptkomponenten finden Sie in der Dokumentation. Aber die ganze Zeit in der Dokumentation zu liegen oder an der Wand zu hängen, ist ein großer Unterschied. Wenn ein Entwickler denkt: "Aber nicht schräg ein Loch in die API über dem geschichteten Modell graben?", Weil dies tatsächlich die Entwicklungszeit eines bestimmten Features verkürzt (aber dann mit Begleitung einhergeht) und das Schema in der Zwischenzeit vor Ihren Augen hängt, wird er es höchstwahrscheinlich sehen dass es ein Loch sein wird. Befindet sich das Diagramm irgendwo im Dokument, können Sie es vorübergehend vergessen und schnell Code schreiben, der gegen die Architektur verstößt.

Projekt Bewegungswissen

Im Scrum-Prozess gibt es spezielle Punkte, um Wissen über die Projektbewegung zu generieren:

• Demo - Präsentation des Projektstatus für diejenigen, die die Ergebnisse Ihrer Arbeit nutzen, und andere Interessierte.
• Retro ist eine Selbsteinschätzung: ob wir richtig arbeiten und was verbessert werden kann.
• Tägliches Treffen - Synchronisation der Ideen des Teams über die Bewegung des Projekts.
• Planung - Synchronisation von Absichten.

Es ist wichtig, dass diese Kommunikationstreffen voneinander getrennt sind und sich jeweils auf das eigene Ziel konzentrieren. Darüber hinaus werden für sie Formate entwickelt. Es gibt ganze Bücher darüber, wie man Retrospektiven durchführt und welche Artefakte sie begleiten sollten. Darüber hinaus sind einige Artefakte, wie der Code, durchgängig, da Aufgaben, die gemeinsam geplant werden müssen, von Retro stammen. Dementsprechend summieren sich Rückblicke auf die Aufgabe zum Rückstand, sind aber beispielsweise mit Farbe gekennzeichnet. Wir arbeiten mit dem einen oder anderen - das ist normal.

Langzeitbeschreibungen

Bei der Erstellung von Langzeitbeschreibungen besteht die Hauptfrage darin, zu bestimmen, welche Fälle von der Beschreibung unterstützt werden . Optionen können völlig unterschiedlich sein:

• Bringen Sie einem neuen Benutzer bei, mit dem System zu arbeiten.
• Geben Sie Referenzinformationen zu den seltenen Funktionen des Systems an.
• Stellen Sie einem neuen Entwickler das Konzeptdesign des Systems vor.
• Damit der Autor das Gerätefragment des Systems zur Verbesserung zurückrufen kann.
• Beschreiben des Gerätemodulsystems für die Entwicklung durch einen neuen Entwickler.
• Stellen Sie dem Support-Techniker Informationen zum Systemgerät zur Verfügung.

In diesem Sinne formulieren Sie zuerst, welche Aufgabe Sie unterstützen müssen, und erstellen dann Dokumente mit dem erforderlichen Detaillierungsgrad und so weiter.

Die universelle Beschreibung ist detailliert, teuer, irrelevant und auch unnötig, da Sie aufgrund ihrer Details nicht die erforderlichen Informationen darin finden können.

Es ist notwendig, den Zweck festzulegen , die Einhaltung zu bewerten und sich daran zu erinnern: Je detaillierter das Dokument ist, desto teurer.

Eine typische Frage: Sollten die Protokolle regelmäßiger kleiner Besprechungen mit dem Kunden klar sein und nur an diejenigen erinnern, die an der Besprechung teilgenommen haben, oder so, dass sie an alle Personen gesendet werden können, die nicht an der Besprechung teilgenommen haben, und sie könnten es auch herausfinden? Dies ist ein wichtiges Thema.

Detailliertere Protokolle sind natürlich viel teurer . Dies muss verwaltet werden, und Kompromisse können anwendbar sein. Geben Sie beispielsweise eine kurze Zusammenfassung in das Protokoll ein und lesen Sie das aufgezeichnete Video oder Audio für Einzelheiten. Es kann wirklich nützlich sein, viele kehren zu Videoaufnahmen zurück.

Gleichzeitig vergessen wir nicht, die Logik der Entscheidungen in der Zusammenfassung festzulegen und nicht nur "was zu tun ist", wenn wir zum "Warum und Wofür" zurückkehren. Kurz, aber es ist wichtig.


Mit den normativ notwendigen Dokumenten gemäß GOST müssen Sie verstehen, ob sie für die Lieferung des Projekts oder für etwas anderes benötigt werden. Normative Dokumente stellen in der Regel die Kommunikation des Kunden mit seinen Inspektoren sicher und sollten in dem Umfang verfasst werden, in dem dies erforderlich ist, und die Verwendung durch den Kunden berücksichtigen. Manchmal handelt es sich um schreibgeschützte Dokumente. Zum Beispiel haben wir Kunden, für die Arbeitsdokumentation und Dokumentation für Inspektoren separat erstellt werden. Aber es gibt diejenigen, die möchten, dass die zu prüfenden Dokumente funktionieren, grundlegend. Abhängig davon ist der Dokumentationsprozess unterschiedlich, aber sobald wir den Zweck verstanden haben, ist alles in Ordnung.

Kommunikation vermittelt Bedeutungen

Lassen Sie uns ein wenig abschweifen und diskutieren, dass Kommunikation Bedeutung vermittelt.


Alles beginnt mit der Annahme der RUP-Ära, aus der der objektorientierte Ansatz (Object-Oriented Approach, OOP) hervorging. Wenn wir die Welt in Objekte und Verbindungen zerlegen, erhalten wir ein eindeutig interpretiertes Bild der Welt.


Der Kunde kann die Welt als eine Sammlung interagierender Agenten im Haskell-Modell sehen, die Nachrichten austauschen. Die Agenten sind die gleichen und die Wörter sind klar, aber das Bild ist völlig anders. Das Schema spiegelt im Gegensatz zum Text diesen Unterschied wider. Daher verwenden wir das Schema.

Eine andere Denkweise ist die Norm . Hierarchische Modelle, Taxonomien gingen von der wissenschaftlichen Entwicklung der Welt aus, in der alles auf eine strenge Form reduziert und "in den Regalen ausgelegt" wird. Mit der Entwicklung des Internets ist das Denken der Welt als Wolke von Tags mit Verbindungen beliebt. Es gibt sogar ein spezielles Wort - "Volkswirtschaft" . Ein solches Denken ist effizient und praktikabel. Marketing, die Medien bauen darauf auf. Und die Welt der IT-Ingenieure, die dem wissenschaftlichen Bild der Welt näher sind, ist zunehmend damit konfrontiert.


In diesem Sinne müssen Sie den Unterschied im Denken kennen und beheben . Andernfalls erstellen Sie ein quadratisches System, und der Kunde bereitet ein rundes Loch dafür vor. Dann beginnt der Kombinationsprozess und Sie müssen sich mit einem tropfenförmigen Krokodil zufrieden geben, da eine Ecke Ihres quadratischen Musters nicht abgeschnitten werden kann - es besteht aus massivem Architekturmetall.

Was zu tun ist, ist verständlich. Zeichnen Sie die Diagramme . Wir müssen vorgefertigte, bekannte Quellen nehmen, zum Beispiel UML. Denken Sie jedoch daran, dass formale Notationen nicht von allen gut verstanden werden und viele skizzenhafte, informelle Schemata ausschließlich als Bilder wahrnehmen.

Die orthogonale Quelle für Schemata außerhalb der IT ist die SMD-Methodik (siehe den Bericht „Kommunikation mit einer anderen Denkstruktur - Taxonomie versus Volkswirtschaft“ ).

Grundsätze der Dokumentenverwaltung

1. Das Dokument hat keinen Autor.

Er lebt länger als der Erstautor, daher arbeiten wir gemeinsam und leiten keine Wiki-Systeme weiter. Sie können auch Google Text & Tabellen verwenden, es gibt jedoch separate Dokumente, was nicht immer praktisch ist. Für kurzlebige Produktionen eignet sich Google Text & Tabellen hervorragend.

Eine wichtige Konsequenz ergibt sich aus dem Prinzip, dass ein Dokument keinen Autor und keine Erfahrung in Wiki-Systemen hat: Ich habe gesehen, was verbessert werden muss, mache es sofort, Koordination ist nur durch Meinungsverschiedenheiten notwendig.

Es scheint, dass jeder versteht, dass es keinen Autor gibt, aber nur wenige das Dokument eines anderen korrigieren. Die Rechtschreibung ist immer noch in Ordnung, aber wenn etwas komplizierter ist, muss der Autor gehen und schreiben. Nein, Sie müssen es nehmen und reparieren . Alle Wiki-Systeme haben Benachrichtigungen. Wenn der Autor an dem Dokument interessiert ist, wird er einen Hinweis sehen, die Änderungshistorie anzeigen und erklären, ob Sie falsch liegen. Aber in den meisten Fällen wird er es entweder nicht bemerken oder entscheiden, was normalerweise behoben wird. Der Erfolg von Wikipedia ist genau das.

2. Das Dokument wird schrittweise erstellt.

Ein großes Dokument ist veraltet, bevor es geschrieben wird. Es genügt, Konzepte zu präzisieren und nach Bedarf zu detaillieren. Wir erledigen den Teil des Dokuments, der sich auf die aktuelle Aufgabe bezieht.

Die von Agile mitgebrachten Formate: User Story, Anwendungsfall, Story Mapping wurden im Gegensatz zu den vorherigen monolithischen Produktionen nicht sofort angezeigt. Sie konzentrieren sich genau auf die schrittweise Erstellung von Dokumenten und die schrittweise Ausarbeitung. Sie sind nicht überall, aber sobald wir entscheiden, dass wir die Dokumente schrittweise einreichen und detaillieren, werden der Struktur von Artefakten die gleichen Einschränkungen auferlegt wie dem Code. Sobald wir das System inkrementell schreiben und nicht vollständig debuggen, sollten wir den Code entsprechend organisieren: Komponentenarchitektur, Mikroservice-Architektur - es gibt viele Optionen, aber keinen Monolithen.

3. Inhalt ist wichtiger als Form.

Formale Dokumentanforderungen funktionieren nicht. Sie können verwendet werden, um zu Beginn Zeit zu sparen, dies ist jedoch kein Qualitätskriterium. Die Kriterien für die Eignung von Stakeholder-Nutzungsdokumenten funktionieren: Checklisten und Expertenbewertung.

Zu diesem Zeitpunkt funktionieren die Vorschriften nicht - dies ist eine Lehre aus der Entwicklung der IT-Branche und nicht der IT-Branche. Jeder kann in Wiki-Systemen bearbeiten, es gibt keinen langen Genehmigungsprozess usw. Gleiches gilt für Commit-Richtlinien in vielen OpenSource-Projekten. Natürlich gibt es Genehmigungen usw., aber es ist eine materialisierte Erfahrung, die genutzt werden sollte.

4. Wir hinterlassen Spuren.

Dieses andere wichtige Prinzip betrifft Sitzungsprotokolle und Zusammenfassungen von Gesprächen. Das heißt, wir haben live gesprochen, uns unterhalten und eine Zusammenfassung von 1-2 Sätzen in Task Tracker aufgeschrieben. , , -, , .

. , , , . . , , . - , . , .

— , , .. , - , -, , , , . : , .

:

• Archimate.
• Archimate.
• - , Domain Driven Design.
• OMG Essence.
• viewpoint' ISO 42010.

. , , .

, , . , , , , , , , , : , .

, Wiki — , , , , , .. , - . CUSTIS MediaWiki. , Jira Confluence, OpenSource http://4intra.net. , , wiki- , .

— . Slack, Task Tracker Google Docs, .

. , wiki. wiki git, - wiki- , .

— , .

, , .

, « » . , : « , ?» , . , , « » , British Petroleum. , , , .


. . , .

, , 5–7 , . .

, , , C# , . .

— . — , wiki — , . . , , , . , , .

— , . BBC , , , . , , . , , .

IBM: — .

IBM : , - , . , . IBM , . , , , , , , , « , , ». . — , , .

• .
• .
• , .
• , .
• — .

mtsepkov.org (, , wiki) , agile , .

— . , : , , , , Knowledge Conf .

25 TeamLead Conf . , .