Projektmanagement-Tools und Methoden als Beispiel für einen Startup-Pivot

    In einem früheren Artikel haben wir die Geschichte unseres Startups erzählt und drei Schlüsselkomponenten untersucht: "Idee", "Implementierung" und "Vertrieb". Aufgrund des großen Umfangs des Artikels hatte das Thema Implementierung formal nicht genügend Platz, um es zu beschreiben. Wir werden dies in dieser Veröffentlichung korrigieren.

    Die Teamleitung beginnt mit der Planung und Gestaltung. Es gibt Dutzende, wenn nicht sogar Hunderte von Projektmanagementmethoden: von ReadMe-Entwicklung bis hin zu umständlichen, aber für alle Fälle PMBOK . Da Programmierer manchmal Fahrräder erfinden, können Projektmanager auf diese Weise sündigen. Wenn wir uns mit der Methodik einige Freiheiten erlauben könnten, dann wäre das Tool bereits ohne „Fahrradbau“ ausgewählt worden ...




    Was ist ein Startup-Pivot?



    Pivot (aus dem Englischen - sich drehen, um die eigene Achse drehen) im Rahmen eines Startups ist die Ablehnung des aktuellen Geschäftsmodells, Softwareprodukts und Neustarts aller Arbeiten an einem neuen Konzept. Eine Erklärung, warum dies passiert, warum dies bei uns passiert ist, würde den Rahmen dieses Artikels sprengen. Ich werde nur erklären, was in unserem Fall "Pivot" bedeutet:
    • begrenzte Ressourcen - 4 Personen für alle Arbeiten;
    • streng definierte Termine - 30 Kalendertage;
    • die Notwendigkeit, die Aufgabe zu erfüllen: "Holen Sie sich das erste Einkommen aus dem Produkt."


    Mehr zum Ausgangspunkt


    • Das Projekt startet nicht mit „0“ - das Softwareprodukt Vorfahr war Version 2.3, hatte nach dem Refactoring eine gute Architektur mit festgestellten und festgestellten Fehlern;
    • Entwicklungsaufgabe: Machen Sie aus einem Vorfahrenprodukt v2.3 ein Nachkommenprodukt v0.1 alpha-1. Die wichtigsten Änderungen betreffen die Verarbeitung der Architektur für Mehrfachentwürfe, das Hinzufügen neuer Arten von endgültigen Dokumenten, das Entfernen unnötiger Funktionen, die Neugestaltung gemäß dem Geschmack der neuen Zertifizierungsstelle und die Schaffung eines „Demo-Modus“ für die Arbeit.
    • Finanz- und Marketingaufgabe: Ein Produkt so schnell wie möglich herauszubringen und ein Publikum dafür zu gewinnen, nachdem die Reaktion darauf analysiert wurde. Erstellen Sie auf der Grundlage der Analyse einen Plan für die weitere Entwicklung. Beschleunigen Sie mit den zusätzlich erhaltenen Finanzmitteln die Entwicklung neuer Funktionen.
    • Das Entwerfen begann mit der Erstellung eines Marketingkonzeptdokuments, in dem die wichtigsten Ideen und Thesen formuliert wurden: Welche Arbeit muss geleistet werden, um die Aufgaben zu realisieren?
    • Die Zusammensetzung des Teams und die Verantwortlichkeiten, die es wahrnimmt:
      „Programmierer“ - Front-End- / Back-End-Entwicklung, Systemadministration;
      „Tester“ - Softwaretests, Erstellen von Fehlerberichten, Verwaltung von SMM und Inhalten, Analyse und Verarbeitung von Feedback;
      „Designer“ - Entwicklung des Erscheinungsbilds und der Mechanik der GUI, Erstellung und Aufbereitung von Medieninhalten;
      „Projektmanager“ - Analyse, Design, Planung, Management (Projekt, Marketing, Finanzen usw.), Entwicklung der technischen Dokumentation, Textinhalte, SEO.
    • Eine Einschränkung ist eine Anforderung unserer Mentor-Investoren: 30 Tage, um das Produkt neu zu gestalten, Materialien vorzubereiten und an der Werbung zu arbeiten.


    Projektmanagement-Tools


    Unser Team hat Erfahrung mit drei „Bundles“ von Projektmanagement-Tools:

    „Bundle One“ von
    Google Docs - elektronisches Dokumentenmanagement und Cloud-basierter Dokumenteneditor;
    Megaplan - Tracking-Aufgaben, die nicht mit der Code-Entwicklung zusammenhängen;
    Redmine + GIT - Fehler und Aufgaben im Zusammenhang mit Codeentwicklung + Versionskontrolle;
    Kayako - ein Dienst zum Sammeln von Feedback und zum Melden von Fehlern;

    Eine solche Kombination ist gut, wenn sich mehrere Projekte in der Entwicklung befinden, mehrere Kunden usw. (Redmine), viele Mitarbeiter und Aufgaben, die nicht mit der Arbeit am Code zusammenhängen (Megaplan), viele Benutzer und dementsprechend viele: Support, Feedback, Fehlerberichte (Kayako).

    "Link Two"
    Google Docs - elektronisches Dokumentenmanagement und Cloud-basierter Dokumenteneditor;
    Megaplan - Tracking-Aufgaben, die nicht mit der Code-Entwicklung und dem CRM-System zusammenhängen;
    BitBucket statt Redmine + GIT;
    Yandex.Mail für eine Domain - zum Sammeln von Feedback und Melden von Fehlern.

    Das "zweite Bundle" ist geeignet, wenn es sich um ein Projekt handelt, und es ist relativ einfach (BitBucket). Gleichzeitig gibt es eine Menge Arbeit, die nicht mit dem Code zusammenhängt (Megaplan), und es gibt immer noch wenig Feedback-Unterstützung, so dass es genügend konfigurierte Webschnittstellen für E-Mails gibt (Yandex.pdd).

    "Link Drei"
    Google Text & Tabellen - als Cloud-Editor;
    TrackStudio + GIT - Task-Tracker, sowohl nach Code als auch nach anderen + elektronische Dokumentenverwaltung;
    Yandex.Mail für eine Domain - zum Sammeln von Feedback und Melden von Fehlern.

    Dieser Haufen ist der Richtigste. Er ermöglicht es Ihnen, Aufgaben in einem System sowohl per Code als auch mit allem anderen zu bearbeiten. Leider erfordert das Hauptwerkzeug in diesem Bundle eine Menge Ressourcen für das Tuning-Doping (TrackStudio). Yandex.pdd ist sowohl für die Unterstützung von Rückmeldungen als auch für das "zweite Bundle" ausreichend, das

    für unterschiedliche Arbeitsbedingungen ausgewählt wurde. Google Text & Tabellen wird immer verwendet: Wir lieben es einfach - es ist ein netter, schneller und bequemer Cloud-basierter Dokumenteditor.

    Unter unseren Bedingungen: Ein Projekt, wir müssen sowohl am Code als auch an der Promotion arbeiten, es gibt noch keine Benutzer, es wird nicht viel Support-Feedback erwartet, sie schlugen die Wahl eines zweiten oder dritten "Bundles" vor. Das „dritte Bundle“ (basierend auf TrackStudio) verschwand nach kurzer Überlegung - es gab weder Zeit noch Ressourcen, um dieses Tool einzurichten und in ein neues Projekt zu bringen. Wir haben uns entschieden, das "Second Bundle" mit sofort einsatzbereiten Tools (BitBucket, Megaplan) zu verwenden.

    Die Option, etwas Neues auszuprobieren, wurde aus demselben Grund nicht in Betracht gezogen, aus dem sie sich weigerten, das dritte Bundle zu verwenden. Es gab keine Zeit für Experimente, man musste anfangen zu arbeiten. Angesichts des Mangels an Möglichkeiten, Neues auszuprobieren, verließen sie sich auf die Erfahrung eines Projektmanagers, um mit einigen Dutzend anderer Projektmanagementsysteme (SOFs) zu kommunizieren, die sowohl auf Softwareentwicklung als auch auf eine breite Palette von Anwendungen spezialisiert waren: von Teamer bis BugZill.

    Planung


    Warum haben wir uns für Tools entschieden und nicht geplant?

    Denn das „zweite Bundle“ besteht aus zwei unflexiblen Diensten: BitBacket und Megaplan. Sie sind nicht in der Lage, sie für bestimmte Prozesse anzupassen. Sie müssen daher eine Projektmanagement-Methodik erstellen, um die Einschränkungen dieser Tools zu berücksichtigen. Nachdem Sie die Werkzeuge ausgewählt haben und deren Grenzen kennen, können Sie mit der nächsten Phase fortfahren - der Planung.

    Es wird jemandem so vorkommen, als ob die Situation, in der das Instrument eine Methodik und keinen Umsatz vorschreibt, sehr schlecht ist. Wenn Einschränkungen die Produktivität unserer Meinung nach nicht beeinträchtigen (z. B. übermäßige Bürokratie), können Sie sich mit ihnen abfinden.

    Allgemeine Aufgaben werden in Megaplan festgelegt, wir werden seine Terminologie verwenden. Der Ausgangspunkt in der Hierarchie des Task-Managers Megaplan - "Meilensteine". Ein Meilenstein ist ein Abschnitt eines Projekts zu einem bestimmten Zeitpunkt. Er kann dennoch als eine Reihe von Zielen beschrieben werden, die zu einem bestimmten Zeitpunkt erreicht werden müssen. Planung läuft darauf hinaus, Meilensteine ​​zu setzen. Wir werden sie als Beispiel für unsere Situation betrachten (wir überarbeiten ein Projekt in ein anderes, bereiten seine Promotion für alle 30 Tage vom 5. September bis 5. Oktober vor).

    Meilenstein Nr. 1. "Vorbereitungsphase", abgeschlossen bis zum 10. September:
    - Ausgewählte und konfigurierte Tools, lokale Server;
    - Der Arbeitsablauf ist geplant;
    - Die Aufgaben werden gestellt und verteilt;
    - Entwurf eines TOR für alle Aufgaben.

    Meilenstein 2. "Grundlegende Arbeit", abgeschlossen bis zum 15. September:
    - Der Projektcode wurde überarbeitet (beschleunigt die Umsetzung künftiger Aufgaben).
    - Vorbereitete Server und Konten, Domänen für die Produktion;
    - Entwicklung und Zusammenstellung von Schlüsselinhalten für die Werbung (gemäß der Occam Razor-Regel: 20% der Schlüsselinhalte ergeben 80% des Datenverkehrs);

    Meilenstein # 3. "Das erste visuelle Ergebnis", abgeschlossen bis zum 20. September:
    - Refactoring des Editors (nach iframe verschoben, wodurch der "Demo-Modus" schnell implementiert wird);
    - Neu gestaltete GUI;
    - "Startete" den Blog des Projekts, die Community in sozialen Netzwerken.

    Meilenstein 4. „Das erste öffentliche Ergebnis“, das bis zum 25. September fertiggestellt wurde:
    - Ein Formular für den Erhalt von Zahlungen wurde hinzugefügt.
    - Implementiert einen Demo-Modus;
    - Im Demo-Modus wurde eine Werbeseite mit 90-100% des geplanten Inhalts gestartet;
    - Version 0.0.11 ist in der Produktion behoben;
    - Gemeinschaften im sozialen. Netzwerke und ein Blog auf der Website sind mit ersten Beiträgen gefüllt.

    Meilenstein # 5. "Vorbereitete Projektförderung", abgeschlossen bis 30. September:
    - Ein Blog über Habrahabr wurde gestartet;
    - Kleinere Funktionen und Verbesserungen implementiert;
    - bestandene Moderation und angeschlossenes Abrechnungssystem;
    - Version 0.0.17 ist in der Produktion behoben;
    - Laut Veröffentlichungsplan wird die Entsendung in soziale Dienste fortgesetzt. Netzwerk und Blog-Site.

    Letzter Meilenstein # 6. „Erste Promotion des Projekts“, abgeschlossen bis zum 10. Oktober:
    - Alle für die Alpha-Version konzipierten Funktionen wurden implementiert.
    - Die Freigabe der Version R0.1 Alpha-1 ist für die Produktion freigegeben.
    - Der erste Artikel wurde in einem Blog über Habrahabr veröffentlicht.

    Geplante Meilensteine ​​# 7-X. "Schaffung der Projektgemeinschaft", abgeschlossen bis zum 30. Oktober:
    - 3-5 Artikel wurden auf dem Blog über Habrahabr veröffentlicht;
    - Vorbereiten und Veröffentlichen von Blog-Posts auf der Website in der sozialen Community. Netzwerke;
    - Es wird eine Sammlung und Analyse von Rückmeldungen sowie eine allgemeine Korrespondenz mit Benutzern durchgeführt, die an dem Projekt interessiert sind.
    - Weitere Promotion wird nach dem Marketingkonzept geplant und durchgeführt;
    - Hotfixes werden durchgeführt;
    - Die Höhe der eingeworbenen Mittel wird analysiert und mit den Möglichkeiten für die weitere Entwicklung von Projekten korreliert.

    Wir werden die Arbeit an Meilensteinen in diesem Bereich abschließen. Die weitere Planung sollte unter Berücksichtigung der erhaltenen Rückmeldungen fortgesetzt werden. Es ist zwar nicht vorhanden, aber es ist besser, daran zu arbeiten, sie zu erhalten.

    Ich möchte Sie daran erinnern, dass die ersten Meilensteine ​​auf der Grundlage von geplant wurden"Marketing-Konzept" . Unser Team besteht aus 4 Personen, die mehrere Jahre an verschiedenen Projekten zusammenarbeiten. Ähnlich wie bei den Meilensteinen für die Alpha-Version von Ahoba (die Aufgaben, die wir bereits in anderen Projekten implementiert haben. Daher wusste der Projektmanager beim Kompilieren der Meilensteine ​​bereits, wer und wie die Aufgaben lösen würde. Dieser Prozess fand informell auf der Grundlage der Vergangenheit statt Erfahrung, empirische Bewertung und analytische Prognose.

    Sie können ein Buch über diese informellen Denkprozesse, die Geschichte ihres Auftretens, Beispielversuche, Lernen aus Fehlern usw. schreiben. Sie erhalten eine Art "PMBOK Lite for Brain". Momentan gibt es jedoch nicht nur ein Buch, sondern auch ein Konzept auf Papier: Alles befindet sich zu 70% im Kopf von PM, und nur die restlichen 30% befinden sich in seiner persönlichen abstrakten Krippe. Vielleicht wird sich eines Tages und von diesen Entwicklungen herausstellen, wenn auch nicht ein Buch, sondern sicher ein würdiger Artikel für Habrahabr. Jetzt notieren wir nur, was getan wurde, ohne auf die Frage „Wie?“ Einzugehen.

    Entwicklung der Projektstruktur


    Wir haben also Meilensteine, es gibt ein Team von 4 Personen, die diese umsetzen werden. Man könnte sofort mit dem nächsten Schritt fortfahren - formale Aufgaben festlegen -, aber um die spätere Kontrolle über die Ausführung zu vereinfachen, lohnt es sich, ein anderes Tool zu verwenden - die hierarchische Struktur des Projekts.

    Zum Erstellen / Gruppieren von Aufgaben ist eine Hierarchie erforderlich. Aufgaben haben zwei Hauptunterscheidungsmerkmale: funktionaler Inhalt und Künstler. Sie können eine Aufgabenhierarchie entweder anhand ihrer funktionalen Gruppierung oder unter Bezugnahme auf einen bestimmten Ausführenden entwerfen. Dies sind formale Ansätze. Sie vereinfachen die Verwaltung, machen sie transparenter, verursachen jedoch eine Menge unnötiger Bürokratie, was wiederum die Gesamtproduktivität verringert. In vielen Situationen kann die Produktivität zum Wohle des Managements geopfert werden, und dies ist gerechtfertigt, weil gibt seine Früchte in Form von Berechenbarkeit und hoher Qualität. Wir brauchten das Ergebnis so schnell wie möglich, damit wir uns von der formalen Struktur entfernen konnten, um die Arbeit zu vereinfachen und zu beschleunigen. In jeder anderen Situation wäre ich jedoch gegen eine solche Struktur.

    Daher sind unsere Aufgaben irgendwo in Bezug auf den Ausführenden gruppiert, irgendwo in Bezug auf den funktionalen Inhalt:

    0. Design
    1. Entwicklung des Projekts
    2. Förderung des Projekts
    2.1. Ahoba Website und Blog (;
    2.2. Werbung in sozialen Netzwerken
    2.3. Werbung in Habrahabr
    3. Entwicklung von Design und Medieninhalten

    Diese Struktur wird es dem Künstler ermöglichen, sich nicht von den Aufgaben anderer Menschen ablenken zu lassen, obwohl sie im Kontext seiner Arbeit stehen, die auch mehr bieten wird Ich merke schnell.

    Aufgabeneinstellung


    Bei der Erarbeitung und Formulierung formaler Aufgaben werden alle Mängel der ausgewählten Reihe von Werkzeugen aufgedeckt ...

    Die allgemeine prinzipielle Reihenfolge, in der die meisten Aufgaben in unseren Projekten ausgeführt werden, lässt sich wie folgt beschreiben:

    Kurzkonzept der Aufgabe → Entwicklung detaillierter TOR → Erstellung von Test- / Demo-Inhalten → Erstellung von GUI-Layouts für TK → Formulierung einer formalen Aufgabe zur Implementierung im Task Tracker (TK + Layout) → Implementierung → Testen → Bugfix (falls erforderlich) → Beenden der Aufgabe.


    Verschiedene Personen mit unterschiedlichen Rollen arbeiten in verschiedenen Phasen an der Aufgabe: PM entwickelt das Konzept der Aufgabe; Wirtschaftsanalytiker, technischer Redakteur, TK; der Designer zeichnet ein Layout; PM übergibt TK und Layout an den Programmierer. Der Programmierer implementiert die Aufgabe und übergibt sie zum Testen. Der Tester überprüft die Implementierung und schließt die Aufgabe ab, wenn alles in Ordnung ist und dem TOR und dem Layout entspricht.

    Und das ist die einfachste Option ... Es gibt Situationen, in denen es unmöglich ist, genau zu bestimmen, wie die Aufgabe implementiert werden soll. Der Programmierer kann sich dann bereits in der Entwurfsphase mit der Aufgabe verbinden (z. B. können mehrere Schnittstellenprototypen implementiert werden, sodass der Usability-Experte jede Option bewertet und die letzte in der Implementierungskette erstellt).

    Als Ergebnis haben wir ungefähr 5 typische Modelle für den Lebenszyklus von Aufgaben und ein paar Dutzend „atypische“ Modelle.

    Flexible Tools zur Aufgabenverfolgung wie TrackStudio eignen sich gut, da Sie die Verwaltung für jedes Modell des Aufgabenlebenszyklus formal konfigurieren können. Dies ist sowohl ihr Vorteil als auch ihr Nachteil. Wie oben erwähnt, können Sie dieses System nicht verwenden, wenn für die Ersteinrichtung keine Ressourcen vorhanden sind. Mit dem verpackten Megaplan und BitBucket stellten wir fest, dass es nicht funktionieren würde, sie formal für unsere Lebenszyklen einzurichten. Daher ist die weitere Geschichte a la "viele, viele Krücken" über die informelle Nutzung dieser Dienste.

    Wie implementiere ich unser Task-Lifecycle-Modell im Bundle „Megaplan + BitBucket“? Zunächst werden spezifische Funktionen in Bezug auf den Code (Punkt 1. „Entwicklung“ aus der zuvor definierten hierarchischen Struktur) in BitBucket eingegeben und die Aufgaben zur Vorbereitung von Materialien für die Implementierung von Funktionen (TK + Layout + Test \ Demo-Daten) ausgeführt Megaplan-Tracker.

    Der Algorithmus
    sieht ungefähr so ​​aus: Wir haben die Aufgabe für den Business Analyst in Megaplan gestellt: " Develop TK " - mit einem Link-Hinweis " Put the finished TK in Task X for the Designer ". Für den Designer, ebenfalls in Megaplan, haben wir die Aufgabe „ Layout für TK entwickeln “ mit denselben Referenznotizen festgelegt: „ Später wird die TK von einem Geschäftsanalysten in die Aufgabe gestellt, der bereit ist, das Layout in BitBucket in Aufgabe Y zu setzen" Der Programmierer und der Tester arbeiten nur in BitBucket, wobei sich der Status der Aufgaben ändert.

    In der Oberfläche dieser SOUPs gibt es keine Vereinheitlichung der Arbeitsphasen an Aufgaben. Dies kann bei unsachgemäßem Projektmanagement zu negativen Konsequenzen führen. Aus persönlicher Erfahrung: Wenn Sie die Arbeitsverteilung nicht manuell koordinieren (und die Tools dies nicht automatisch tun), kann eine Situation eintreten, in der beispielsweise ein Programmierer wochenlang untätig ist und auf formale Beschreibungen für Features wartet. Dies habe ich am letzten Einsatzort beobachtet. Infolgedessen kündigte der leitende Entwickler und begründete seine Entlassung als Monolog im Geiste: "Ich bin gelangweilt, weil es keine Arbeit gibt, aber ich möchte Code schreiben." Dies ist ein gutes Beispiel dafür, wie unangemessene Tools oder deren informeller Gebrauch die Teammitglieder demoralisieren können. Jeder, der sich wie wir für den „Second Link“ entschieden hat, muss diese Risiken verstehen und berücksichtigen, wenn er in solchen Projektmanagementsystemen arbeitet.

    Unser Team besteht aus 4 Personen. Jeder von ihnen ist mit verschiedenen Entwurfsarbeiten befasst. Als Projektmanager musste ich dieses Projektmanagement so schnell wie möglich abschließen und anfangen, als Business Analyst / technischer Redakteur, SEO-Spezialist, Vermarkter und Texter zu arbeiten. Ich wollte nicht zur Arbeit von PM zurückkehren, und es gab keinen Weg.

    Es ist notwendig, alle Aufgaben zu formulieren und zu verteilen, sie mit Links zu verknüpfen, Auftragnehmer zu benennen und Qualitätskriterien zu definieren. Ordnen Sie den Arbeitsprozess so an, dass er nach dem entwickelten Plan 30 Tage dauert, wenn alle Teammitglieder als Ausführende von einer abgeschlossenen Aufgabe zur nächsten wechseln, ohne Zeit auf die einfache und die Peripherie zu verschwenden. Dies wird gelöst, indem eine Arbeitstabelle mit der anschließenden Formulierung von Aufgaben in Trackern erstellt wird:

    Tabelle: „Arbeiten an der Umsetzung und Förderung des Ahoba-Projekts (; ver. Alpha-1)

    usw., insgesamt ca. 50 Aufgaben.

    Es konnten konkrete Aufgaben für die Ziele aus Meilensteinen formuliert werden. Einige Ziele werden durch eine Aufgabe beschrieben, andere sind in mehrere unterteilt. Von Milestones aus konnten wir die Fristen so gestalten, dass wir uns auf die logische Abfolge der Arbeit konzentrierten. Gemäß vordefinierten Projektrollen wurden die für bestimmte Aufgaben verantwortlichen Führungskräfte ernannt. Die Aufgaben selbst bestehen natürlich nicht nur aus den in der Tabelle aufgeführten Überschriften. Die meisten von ihnen Sie wurden ergänzt durch Beschreibungen, Erklärungen, Links zur Projektdokumentation in Google Docs, Checklisten mit Schritten oder Ausführungsalgorithmen ...

    Im Übrigen ist eine frühzeitige Parallelisierung zu beachten. Während der PM an Aufgaben arbeitet, hat das Team nichts zu tun. Um Ausfallzeiten zu vermeiden, beginnt die Arbeit von PM mit der Formulierung von Aufgaben, die keine detaillierten technischen Spezifikationen oder Analysen erfordern: Der Programmierer entfernt zunächst unnötige Funktionen. Der Designer zeichnet das Projektlogo. Der SMM-Manager wählt Inhalte für Beiträge zu Themen aus, die im Konzept definiert sind. Alles ist zur Hand, und der Projektmanager arbeitet in aller Ruhe an fünfzig Aufgaben, nachdem er die Aktivitäten des Teams für die nächsten 30 Tage geplant hat.

    Dies beendet das Projektmanagement und muss nur noch gelegentlich darauf zurückgreifen: Verfolgen Sie den Status von Aufgaben, passen Sie Termine und Meilensteine ​​an, falls erforderlich.

    Formale Regeln für das Festlegen und Ausführen von Aufgaben


    Aufgaben werden formuliert und festgelegt, Fristen und Ausführende werden definiert. Um Ihre Ziele jedoch reibungslos zu erreichen, müssen Sie eine Reihe formaler Regeln befolgen:
    • Jede Idee, Anregung, Wunsch usw. Pass durch PM'a, weil Er ist verantwortlich für den gesamten Arbeits- und Lebenszyklus der einzelnen Aufgaben und definiert und führt alles Neue entsprechend der aktuellen Situation ein.
    • Alle Aufgaben sind in Projektmanagementsystemen festgelegt. Assoziiert mit dem Code - in BitBecket alle anderen - im Megaplan;
    • Für jede Aufgabe muss eine verantwortliche Person benannt und ein Termin festgelegt werden;
    • Die Aufgabe sollte eine vollständige, formale und eindeutige Beschreibung haben. Wenn der Auftragnehmer sich über die Bedeutung der Aufgabe nicht sicher ist, ist er verpflichtet, diese vor ihrer Durchführung beim Arbeitsdirektor zu verifizieren. Der Direktor ergänzt gegebenenfalls die Beschreibung;
    • Die Reihenfolge der Aufgaben richtet sich nach ihren Fristen. Wenn die Aufgaben dieselbe Frist haben, wählt der Testamentsvollstrecker, in welcher Reihenfolge sie ausgeführt werden sollen.
    • Status bei der Arbeit an Aufgaben (automatisch und manuell eingestellt) und die Reaktion darauf in Megaplan:
      1. „Neue Aufgabe“ - Sie müssen sich mit dem Wesen und den Bedingungen der Aufgabe vertraut machen, sich auf die Ausführung anderer und einer neuen Aufgabe einigen.
      2. „Zur Ausführung angenommen“ - die für die Aufgabe verantwortliche Person weiß Bescheid, wenn sie frei ist, arbeitet sie an ihrer Umsetzung.
      3. „Bedingt erledigt“ - Der Status wird manuell gesetzt, nachdem der Auftragnehmer die Arbeit an der Aufgabe beendet hat und alle darin beschriebenen Bedingungen erfüllt hat. (Zum Beispiel unter der Bedingung, dass das fertige Layout in einer verwandten Aufgabe für die Entwicklung einer GUI veröffentlicht wurde).
      4. "Abgeschlossen" - wird manuell festgelegt, nachdem der Aufgabenanbieter die Qualität seiner Ausführung überprüft hat.

    • Status bei der Arbeit an Aufgaben, Serviceinformationen in Headern (nur manuell setzen) und Reaktion auf diese bei der Arbeit in BitBucket:
      1. Für die Aufgabe muss ein Typ angegeben werden. Typ "Aufgabe" - für Aufgaben im Zusammenhang mit dem Hinzufügen neuer oder dem Ändern aktueller Funktionen festgelegt; Typ "Bug" - für die Behebung von Fehlern, Bugs.
      2. Weil In BitBucket gibt es keine Entität "Version" oder "Release". Für jede Aufgabe werden Serviceinformationen vom Typ "RX" am Anfang des Headers hinzugefügt, wobei "R" die Bezeichnung für das Release und "X" die Release-Nummer ist. Ein Beispiel für ein Etikett ist „R0.1“. Die Aufgabe wird von Release zu Release übertragen, indem das Service-Label im Aufgabenkopf geändert wird.
      3. Eine Aufgabe wird ohne Status hinzugefügt, wenn sie keine Daten enthält (z. B. das Layout der neuen GUI), und die Beschreibung sollte einen Hinweis enthalten (z. B. " Später legt der Designer das Layout fest, die Details in der Aufgabe lauten link_to_task_by_development_mock ").
      4. Die Aufgabe wird auf den Status "neu" gesetzt, dh, alle Beschreibungen sind fertig und der Programmierer kann mit der Arbeit beginnen.
      5. Die Aufgabe wird auf den Status „gelöst“ gesetzt, wenn der Programmierer die Arbeit an der Aufgabe beendet und Änderungen an den Testserver sendet. Dieser Status bedeutet, dass der Tester mit dem Testen der Aufgabe beginnen kann.
      6. Wenn in der abgeschlossenen Aufgabe Fehler gefunden werden und diese im Rahmen der aktuellen Aufgabe behoben werden können, setzt der Tester den Status auf „ungültig“. Dies bedeutet, dass der Programmierer die entdeckten Fehler beheben muss. Nach der Bearbeitung setzt der Programmierer den Status erneut auf „behoben“.
      7. Nachdem die aktuelle Aufgabe fehlerfrei implementiert wurde oder Fehler in eine separate Aufgabe mit dem Typ "Fehler" verschoben wurden, wird der Aufgabe der Status "Abgeschlossen" zugewiesen.
      8. Jeder Aufgabe wird automatisch eine eindeutige ID zugewiesen. Es ist aus zwei Gründen erforderlich: a) um Commits im Git-Repository an eine bestimmte Aufgabe zu binden; b) um die Versionsnummer der aktuellen Version zu erhalten.


    Basierend auf diesen Regeln, Tools und Methoden wurde das Projektmanagement während der Erstellung und Förderung des Ahoba-Startups implementiert (in der Phase „Alpha-1“. Die Ziele und Bedingungen, die wir ihnen diktiert hatten).



    Kirill,
    Projektmanager Online-Tool für Design SketchBuilder
    Temporary aus dem Konto unseres Programmierers Anton (@skrutty)

    Jetzt auch beliebt: