"Wie schreibe ich technische Dokumente? "Der Kommentar ist überraschend. Ein Artikel über" Wie man ein gutes Designdokument schreibt "ist voller Feindseligkeit.
Ich bin mir nicht sicher, ob meine Ideen in der neuen Ära des Internets veraltet sind. Es scheint, dass das Schreiben von Dokumenten zu einer Minderheit geworden ist. In jedem Fall bringen Sie Ihre Ansichten klar zum Ausdruck.
Alle Meinungen in diesem Artikel sind persönliche Meinungen, und es gibt kein "Urteil", um zu teilen, was Sie für richtig halten.
Voice-over: Das Material im folgenden Text, Screenshots aus "Wie schreibe ich technische Dokumente? "Im Kommentar sind der Avatar und der Name versteckt.
1. 
Wie schreibe ich technische Dokumente? "In den Kommentaren ist der ähnlichste Punkt: keine technischen Dokumente schreiben, denn nur auf diese Weise wagt der Chef es nicht, ta beiläufig zu ersetzen, was ta" unersetzlich "macht.
"Die Unersetzbarkeit des Arbeitsplatzes"
bedeutet jedoch nicht:
"Ich habe viele versteckte Gruben begraben. Nur ich weiß, wo sich die versteckten Gruben befinden, also bin ich unersetzlich."
Es bedeutet vielmehr:
"Ich habe eine Kernwettbewerbsfähigkeit, die andere nicht haben. Es kann sich um Einstellung, berufliche Fähigkeiten oder ein gutes Aussehen handeln."
Sonnenschein positive Energie:
Wenn Sie am Arbeitsplatz hart nachdenken und Ihre „eiserne Reisschüssel“ durch „Graben von Löchern“ behalten, ist es besser, hart zu arbeiten, um Ihre Wettbewerbsfähigkeit zu verbessern, damit Sie überall essen können.
2. Der 
zweite Gesichtspunkt ist, dass das Dokument so geschrieben ist, dass andere es sehen können, für den Chef, für den Kunden, für die Person, die kommunizieren möchte, und für die Person, die das Projekt übernehmen möchte. Die Projektteilnehmer müssen keine Dokumentation schreiben.
Warum Designdokumente schreiben?
Lassen Sie sich selbst helfen, klarer zu denken, bevor Sie den Code schreiben: Stellen Sie
für Projekte die Konsistenz der Informationen sicher, stellen Sie die Kontrollierbarkeit des Projekts sicher und verringern Sie die Projektrisiken. Stellen Sie
für das Team die Fällung und Vererbung von Wissen sicher.
Wie viele Subsysteme sind an dem Projekt beteiligt, wie viele Module sind an jedem Subsystem beteiligt, welche Abhängigkeiten bestehen zwischen Modulen, wie viele Schnittstellen müssen einander bereitgestellt werden, welche Parameter sind für jede Schnittstelle erforderlich, wie vor- und nachgelagerte Interaktionen im Schnittstellenimplementierungsprozess und welche technischen Lösungen für die Kernlogik verwendet werden Realisieren ... Wissen die relevanten Techniker alles?
Viele selbstbewusste Technologiegötter "denken", dass sie verstehen, aber sie verstehen es nicht. Tatsächlich verstehen sie es einfach nicht.
Viele "sprechen klar", aber "unklar geschrieben" werden eigentlich nicht verstanden.
Nur wenn ein Projekt und ein technisches Problem in Worten und logisch beschrieben werden, bedeutet dies, dass das wirkliche Denken klar ist.
Voice-over: Wenn Sie auf dem Papier landen, können Sie viele Probleme im Design finden.
Wie stellt das Dokument die Konsistenz der Informationen sicher und reduziert Projektrisiken?
Um ein einfaches Beispiel zu nennen: PHP-Ingenieure müssen eine HTTP-Schnittstelle zum Abrufen von Auftragsinformationen bereitstellen und sich später mit IOS / Android / FE-Ingenieuren abstimmen. Außerdem müssen QS-Ingenieure testen.
Ist es nicht notwendig, die HTTP-Schnittstelle auf Papier zu bringen?
http://daojia.com/order/getinfo?oid=${oid }
cookie: uid = $ {uid}
cookie: token = $ {token}
…
RESTFUL-Schnittstellenformat, Eingabe- und Ausgabeformat, die Informationen sind PHP / IOS / Android / FE / QA-Ingenieure benötigen klare Informationen, da sonst die damit verbundenen gemeinsamen Debugging- und Testarbeiten für Forschung und Entwicklung nicht durchgeführt werden. Müssen diese Informationen jedes Mal mündlich kommuniziert werden?
Ein Jahr nach dem Start des Projekts muss die Benutzeroberfläche iterativ aktualisiert werden. Müssen Sie den Code jedes Mal überprüfen?
Voice-over: Notizen sind sehr wichtig. Notizen und Dokumente stehen nicht in Konflikt. Sie lösen nicht das gleiche Problem.
Sonnenschein positive Energie:
Ein gutes Dokument zu schreiben ist gut für Sie selbst, für das Projekt und für das Team. Warum nicht?
3. Der 
dritte Gesichtspunkt ist: keine Zeit zum Schreiben.
Gott ist fair, Zeit wird gespart, mehr Zeit damit verbracht, über das Design nachzudenken, die Codierung wird definitiv reibungsloser sein, kann viel Kommunikations- / Wrangling-Zeit reduzieren, kann viel zusätzliche Modifikation / gemeinsames Debugging / Testzeit sparen, die durch Programmänderungen verursacht wird Dies kann viel Zeit für die langfristige Wartung sparen.
Sonnenschein positive Energie:
Ich möchte trainieren, aber ich habe keine Zeit.
Ich möchte Englisch lernen, aber ich habe keine Zeit.
Ich möchte ein gutes Dokument schreiben, habe aber keine Zeit.
Ich habe Zeit, Momente, Schlagzeilen, Vibrato und Verfolgungsjagden zu lesen. Ich habe Zeit.
Lehnen Sie die Ausreden ab, handeln Sie zusammen und schreiben Sie technische Dokumente.
Viertens 
gibt es noch einen anderen Gesichtspunkt: Anforderungen ändern sich schnell, Lösungen ändern sich schnell und Dokumente werden langsam geschrieben. Daher ist das Schreiben von Dokumenten nutzlos.
Wenn Sie eine Angelegenheit diskutieren, besprechen Sie zuerst die Rationalität. Wenn es vernünftig ist, aber Schwierigkeiten gibt, dann schauen Sie sich die schwierigen Lösungen an. Normalerweise sollte es eine solche Logik sein, oder?
Denn:
"Anforderungen ändern sich schnell, Lösungen ändern sich schnell und Dokumente werden langsam geschrieben",
also:
"Es ist sinnlos, Dokumente zu schreiben"
Die Logik selbst ist falsch.
Wir (insbesondere der technische Leiter mit dem Recht zu sprechen und Entscheidungen zu treffen) sollten wir zunächst nicht darüber nachdenken:
- Die Nachfrage ändert sich ständig, ist es vernünftig?
- Der Plan ändert sich immer, ist es vernünftig?
- Ist es sinnvoll, Dokumente langsam zu schreiben?
- Ist es sinnvoll, keine Dokumentation zu haben?
Sollten Sie sich diese Fragen nicht zuerst stellen?
Wenn Sie der Meinung sind, dass "das Schreiben von Dokumenten langsam und unvernünftig ist", sollten Sie dann nicht als nächstes darüber nachdenken:
Warum ist das Schreiben langsam? Dies liegt an der unzureichenden Bereitschaft der Mitarbeiter, den unzureichenden Fähigkeiten der Mitarbeiter, dem schlechten Einsatz von Tools oder anderen Gründen?
- Wenn die Bereitschaft nicht ausreicht, wie kann die Bereitschaft der Mitarbeiter erhöht werden?
- Wenn die Fähigkeiten nicht ausreichen, wie können die Fähigkeiten des Personals verbessert werden?
- Wenn das Werkzeug nicht gut ist, wie die Effizienz des Werkzeugs zu optimieren
...
Existenz kann nicht vernünftig sein:
- "Sklaverei" gibt es seit Tausenden von Jahren. Ist es also vernünftig, ein Sklave zu sein?
- "Die Gesamtnachfrage ändert sich, Pläne ändern sich immer und keine Dokumentation", aber sind diese unbedingt angemessen?
Sonnenschein positive Energie:
Als technischer Leiter sind die Brüder und Schwestern in Ihrem Team in einer Notlage, aber Sie handeln nicht. Fühlen Sie sich nicht schuldig? Bitte handeln Sie im Rahmen Ihrer eigenen Möglichkeiten, um zu versuchen, den unangemessenen Status quo zu ändern und eine technologische Atmosphäre zu schaffen.
V. 
Ein Gesichtspunkt: Wenn andere nicht schreiben, schreiben Sie selbst und verlieren Sie Geld.
Ein Gesichtspunkt: Der Chef braucht Dokumente, die Code-Landwirte brauchen sie nicht.
Ein Gesichtspunkt: Das Gehalt ist so niedrig, schreiben Sie es nicht, wenn das Gehalt erhöht wird, schreiben Sie es.
Ein Gesichtspunkt: Schreiben von Dokumenten ist es, andere zu erreichen.
Voice-over: Es gibt zu viele Kommentare, daher werde ich sie nicht einzeln veröffentlichen. Weitere Informationen finden Sie direkt unter "Wie schreibe ich technische Dokumente?". "Kommentar unten.
Ein Artikel "Wie schreibe ich technische Dokumente? ", die meisten Punkte in den Kommentaren sind" es ist nutzlos ", was ich nie erwartet hatte.
Voice-over: Ich hoffe, alle scherzen nur über mich, anstatt es zu denken.
Sogar, denke ich, worauf ich immer bestanden habe, ist es richtig?
Als ich 2011 versetzt wurde, habe ich eine ernsthafte "Modulübergabe" durchgeführt. Ich habe die 13 Module, für die ich zu diesem Zeitpunkt verantwortlich war, aussortiert und zusammengefasst. Ich befürchtete, dass der übernehmende Ingenieur nach der Übertragung möglicherweise nicht in der Lage ist, das Projekt und das Modul zu bearbeiten, und ich würde mich äußerst schuldig fühlen.
Selbst einige Monate nach der Übertragung werde ich, wenn der Kollege, der mein Modul übernommen hat, Fragen hat, zum Schreibtisch des Kollegen gehen, um die Frage des Kollegen zu beantworten.
Ende:
Unabhängig davon, ob jemand ein Dokument schreibt oder nicht, ich denke, das ist das Richtige, und ich werde es tun.
Unabhängig davon, ob andere Führungskräfte Unterlagen benötigen oder nicht, werde ich dies in meinem Team tun.
Nach vielen Jahren werden Sie vielleicht feststellen, dass Sie gerade deshalb, weil Sie eine Entscheidung getroffen haben, die sich von anderen unterscheidet, ein anderes Sie geworden sind als andere.
gegenseitige Ermutigung!
Road-Sharing Landable Technologies des Architekten
verwandter Vorschlag:
"Wie schreibe ich technische Dokumente? "
Die Nachfrage ändert sich immer, ist es vernünftig?" 》
Forschung:
Tut Ihr Chef etwas Unvernünftiges?