Wie verbessere ich den Entwicklungsprozess bei unserem kleinen Startup?

Ich arbeite für ein kleines, unabhängiges Softwareentwicklungs-Startup. Wir sind jetzt seit fast drei Jahren im Geschäft und die Dinge laufen ziemlich gut. Wir haben einen ziemlich stetigen Strom von Projekten für einen ständig wachsenden Kundenstamm und haben daher vorsichtig damit begonnen, neue Mitarbeiter und Aushilfen einzustellen. Wir haben jetzt fünf feste Mitarbeiter, von denen zwei Vollzeitentwickler sind und einer seine Zeit zwischen Entwicklung, Design und Verwaltung des Unternehmens aufteilt.

Da die Arbeitsbelastung immer höher geworden ist, sind wir auf einige Probleme gestoßen: Wir arbeiten viele Stunden, verpassen Fristen, können keine genauen Schätzungen darüber abgeben, wann ein Projekt abgeschlossen sein wird, und die Qualität unseres Codes lässt nach. Ich wurde gebeten, einen Entwicklungsprozess zu entwickeln, der besser zu unserem Unternehmen und unseren Projekten passt.

Normalerweise arbeiten wir an mehreren Projekten gleichzeitig – das ist aufgrund der Menge an Projekten, die wir übernommen haben, und der geringen Anzahl an Entwicklern, die wir haben, unvermeidlich. Derzeit teilen wir das mehr oder weniger in zweiwöchige Intervalle auf: Arbeite zwei Wochen an Projekt A, arbeite zwei Wochen an Projekt B, und dann taucht unweigerlich ein Problem mit Projekt A oder C auf und wir verbringen einen bestimmten Tag damit für Projekt B auf Projekt A und C.

Unsere Kunden kommen aus dem ganzen Land und haben unterschiedliche Hintergründe. Manche sind gesprächig, manche nicht. Einige erwarten wöchentliche Updates, andere haben kein Problem damit, zwei Monate lang nichts von uns zu hören. Wir arbeiten lieber in kleinen Iterationen: Bringen Sie einen Prototypen so schnell wie möglich aus der Tür und in die Hände des Kunden (normalerweise etwa einen Monat nach Beginn der Entwicklung) und wiederholen Sie ihn dann alle zwei bis vier Wochen. Wir haben festgestellt, dass dies für die Art von Projekten, die wir durchführen, von entscheidender Bedeutung ist, und für die Tatsache, dass unsere Kunden oft keine wirkliche Vorstellung davon haben, was sie wollen, bis sie eine Zeit lang etwas in der Hand hatten, das ihren Wünschen nahe kommt.

Im Moment ist unser Entwicklungsprozess ziemlich geradlinig, aber offensichtlich mangelhaft. Unser Designer hat eine Idee für eine Anwendung und ein rudimentäres Grafikdesign, und unsere Entwickler (einer, zwei oder alle drei) teilen sich die Arbeit ad hoc auf und beginnen mit der Entwicklung. Hin und wieder prüfen wir, wo wir stehen, und passen gegebenenfalls an. Es gibt nicht viel mehr als das.

Ich habe darüber nachgedacht, Code-Reviews durchzuführen: Jedes Stück Code wird von mindestens einem Entwickler überprüft, der es nicht geschrieben hat. Dies scheint ein guter Weg zu sein, um die Qualität unseres Codes zu verbessern, aber es kostet viel Zeit, die wir einfach nicht haben. Dasselbe gilt für Unit-Tests: Wir haben Wochen damit verbracht, Tests zu schreiben, und mussten oft die Tests ständig optimieren, weil wir herausfanden, dass sie nicht die richtigen Dinge oder nicht genug testeten. Dieses Projekt hat deutlich länger gedauert als Projekte, bei denen wir keine Komponententests durchgeführt und nur Fehler beseitigt haben, wenn wir sie gefunden haben. Auch hatten wir dem Kunden wochenlang nichts zu zeigen. Vielleicht haben wir es natürlich nur falsch gemacht.

Ich habe auch darüber nachgedacht, unserem Team einen engagierten Tester hinzuzufügen: jemanden, der Fehler findet, kategorisiert und uns meldet, damit die Entwickler weniger Zeit damit verbringen müssen, Fehler zu finden und Support für unsere Kunden zu spielen, und mehr Zeit haben tatsächlich Fehler beheben und die Anwendung entwickeln. Offensichtlich ist dies eine erhebliche Investition für ein kleines Team wie unseres, aber ich habe den Verdacht, dass es eine effektivere Art ist, Geld auszugeben, als einfach mehr Entwickler auf ein Projekt zu werfen.

Was bessere Schätzungen betrifft, habe ich keine wirkliche Ahnung. Wir haben uns mit der Planung von Poker beschäftigt, aber meiner Erfahrung nach war das kaum mehr als die völlig ungenauen Vermutungen, die wir bereits gemacht haben. Schließlich möchte ich den Designprozess bis zu einem gewissen Grad stärker formalisieren. Offensichtlich können wir aufgrund der iterativen Entwicklung kein Design wirklich in Stein gemeißelt haben, aber es würde wahrscheinlich nicht schaden, wenn wir im Vorfeld etwas mehr Zeit damit verbringen würden, sowohl die Anwendungsarchitektur als auch das grafische Design zu formalisieren.

Grundsätzlich habe ich eine vernünftige Vorstellung davon, was wir verbessern können und was uns derzeit fehlt, aber ich habe keine wirklich konkreten Vorstellungen, wie wir dieses Ziel erreichen können. Daher wende ich mich an Stack Exchange. Wahrscheinlich gibt es viele von Ihnen in ähnlichen Unternehmen wie unserem, die mit denselben Problemen zu kämpfen hatten. Wie hast du sie überwunden oder in welche Fallen bist du getappt, die wir deiner Meinung nach vermeiden sollten?

Wie lang ist Ihr durchschnittliches Projekt in Bezug auf Kalenderzeit und Arbeitsstunden?
Einige Gedanken zu Unit-Tests: Unit-Tests sollten idealerweise vor dem Produktionscode geschrieben werden. Das nachträgliche Schreiben von Komponententests, wie Sie es anscheinend getan haben, ist in der Tat sehr zeitaufwändig und ohne offensichtlichen kurzfristigen Nutzen. Unit-Tests zahlen sich erst langfristig aus. Ob sie sich also lohnen, hängt von der Art der Projekte ab, die Sie durchführen. Je länger die Lebensdauer Ihrer Produkte, desto mehr lohnt es sich, in Unit-Tests zu investieren. Versuchen Sie es auf jeden Fall mindestens einmal in der richtigen TDD -Manier, bevor Sie ein Urteil fällen.
Durchschnittliche Projektzeit: zwischen sechs und 12 Monaten. Mannstunden, würde ich ungefähr zwischen dem Doppelten oder Dreifachen sagen.
Wir schreiben die Komponententests nicht nach dem Schreiben des Produktionscodes. Wir haben die Tests geschrieben und dann den Produktionscode implementiert, der erforderlich ist, damit jeder Test bestanden wird. Das Problem war, dass wir im Laufe der Zeit feststellten, dass die Tests nicht die richtigen Dinge testeten, dass wir Tests aufgrund geänderter Anforderungen ständig neu schrieben usw.

Antworten (5)

Konzentrieren Sie sich auf Qualität und Schätzungen

Sie haben vier Probleme identifiziert. Von diesen würde ich die folgenden beiden als Ihre Hauptprobleme ansehen (lange Arbeitszeiten und verpasste Fristen sind wahrscheinlich die Folge davon):

  1. Die Qualität Ihres Codes lässt nach : Wenn die Qualität schlecht ist, erledigen Sie am Ende viel ungeplante Arbeit. Dies führt zu langen Arbeitszeiten und verpassten Fristen, nicht zu vergessen, die Moral des Teams.

  2. Es ist nicht möglich, genaue Schätzungen darüber abzugeben, wann ein Projekt abgeschlossen sein wird : Dies würde auch zu langen Arbeitszeiten und entweder schlechter Codequalität oder verpassten Fristen oder beidem führen.

Sie scheinen mehrere Optionen zur Verbesserung der Qualität Ihres Codes ausprobiert oder in Betracht gezogen zu haben:

  1. Code-Reviews : Bei meinem vorherigen Auftrag hatten wir Probleme mit der Codequalität. Durch die Einführung der Codeüberprüfung konnten wir Fehler vor der Veröffentlichung erkennen und die Veröffentlichungsqualität erheblich verbessern. Überprüfen Sie zumindest den Code mit hohem Risiko.

  2. Unit-Tests : Wir hatten große Probleme damit, Unit-Tests einzuführen. Wenn Sie es bereits eingeführt haben, ist mein Vorschlag, es zumindest in einigen Projekten fortzusetzen. Einige Benutzer haben von enormen Vorteilen durch Unit-Tests berichtet. Stellen Sie selbst fest, dass es nicht die Vorteile bringt, bevor Sie es aufgeben.

  3. Engagierter Tester : Ich würde dringend einen engagierten Tester empfehlen. Entwickler haben blinde Flecken. Außerdem haben Entwickler nicht die Geduld, sich wiederholende Aufgaben zu erledigen, die oft für sorgfältige Tests erforderlich sind.

Zur besseren Einschätzung habe ich drei Vorschläge:

  1. Continue Planning Poker : Es zerlegt das monolithische Projekt zumindest in kleinere Teile (Epics/Stories). Indem Sie die Schätzungen mit den tatsächlichen Zahlen vergleichen, können Sie sehen, in welchen Bereichen Ihr Team tendenziell Fehler macht. Außerdem bringt es die Teammitglieder dazu, frühzeitig über den Arbeitsumfang, den Entwicklungsansatz und etwaige Risiken/Annahmen zu sprechen. Erfasse diese in der Story/dem Epos.

  2. Zeitplanvorkehrungen : Treffen Sie die folgenden Vorkehrungen, wenn Sie Zeitpläne für neue Projekte erstellen:

    • 10 % (ein Tag in allen zweiwöchigen Sprints) für Wartungsarbeiten an bestehenden Projekten.

    • 10 % für Urlaub, Schulungen und Hilfe bei Ausschreibungen für zukünftige Projekte.

  3. Verfeinern Sie Ihre Schätzungen und planen Sie nach dem Prototyp-Feedback : Wenn Sie das Feedback von Ihrem Kunden erhalten, ist der Umfang klarer (für Ihren Kunden und für Sie). Es ist an der Zeit, Ihre Schätzung zu verfeinern und Ihrem Kunden jede Änderung im Zeitplan mitzuteilen.

Seitdem bin ich zu dem Schluss gekommen, dass eine bessere Qualitätssicherung der effektivste Weg ist, um diese Probleme zu beheben (oder zumindest einen wesentlichen Beitrag zu ihrer Behebung zu leisten). Seitdem habe ich von anderen den Vorschlag erhalten, dass Code-Reviews für ein so kleines Team nicht viel bringen, es sei denn, es gibt ernsthafte Kommunikationsprobleme. Das ist nicht der Fall, aber wir sehen den Code des anderen nicht wirklich, weil wir alle Sachen für unsere eigenen Spezialisierungen schreiben und ständig im "Halt die Klappe halten und versenden"-Modus zu sein scheinen.
Mir gefällt die Idee, risikoreichen Code zu überprüfen, aber ich schätze, wir müssen irgendwie feststellen, was ein hohes Risiko ist und was nicht. Unit-Tests sind etwas, was ich persönlich gerne sehen würde, aber bisher hat es viel Zeit in Anspruch genommen. Offensichtlich habe ich keine Möglichkeit zu messen, ob dies die Zeit ausgleicht, die für die Behebung von Fehlern aufgewendet wurde, die es möglicherweise entdeckt hat, aber es ist immer noch frustrierend. Ich denke darüber nach, es für Teile von Projekten einzuführen - Kerncode usw. - und mehr Zeug für langfristigere Projekte zu testen. Der dedizierte Tester ist etwas, das jeder zu empfehlen scheint. Ich hoffe, dass ich das hinbekomme.
Planungspoker: Ich werde es noch einmal versuchen, aber ich bin noch nicht wirklich davon überzeugt, dass es etwas Wertvolles bieten wird. Das Verfeinern von Schätzungen und Zeitplänen nach Feedback scheint ein Kinderspiel zu sein. Ich bin mir nicht sicher, warum wir anscheinend nicht in der Lage sind, das jetzt zu tun.
Ich habe meine Antwort bearbeitet und unter Schätzungen ein weiteres Element hinzugefügt.
  • Nehmen Sie keine zusätzliche Arbeit mehr auf, es besteht die Versuchung, aber wenn Ihre Organisation auf Linie gebracht wird, dann kommt das Geld. Halten Sie einfach genug, um Ihren Cashflow aufrechtzuerhalten. Gier ist eine sehr zerstörerische Kraft im Geschäftsleben.
  • Verwenden Sie so etwas wie eine SWOT-Analyse, um Ihre aktuelle Position zu ermitteln.
  • Erstellen Sie eine Risikomatrix, um herauszufinden, wo die Notfälle liegen, damit Sie einen Aktionsplan erstellen können.
  • Verwenden Sie SMARTERe Prinzipien, um Ziele oder Meilensteine ​​zu erreichen.
  • Holen Sie sich einige gute Kontrollen an Ort und Stelle. Finden Sie anhand Ihrer Risikoanalyse einige Indikatoren, die eine Verschlechterung Ihres Veränderungsprogramms anzeigen. Erst stabilisieren, dann versuchen, sich zu verbessern – schrittweise.
  • Nehmen Sie Designern die Initiierung von Arbeitsprojekten ab. Ihre Aufgabe ist es, das zu entwerfen, was der Kunde braucht ... Ihre Kunden sollten den Zug liefern. Wenn Sie Produkte herstellen und dann Käufer für Sie finden müssen, verschwenden Sie Ressourcen auf die schlimmste Weise. Einfache Ökonomie: Angebot und Nachfrage.
  • Ziehen Sie das gesamte Team zusammen, beziehen Sie alle Stakeholder (jeden, der irgendwie mit Ihrem Unternehmen interagiert) ein und finden Sie heraus, wo Sie Ihre Verfahren standardisieren können. Gibt es eine Möglichkeit, Ihre Berichtsmethoden zu standardisieren? Je mehr Sie gemeinsame Elemente zusammenbringen können, desto mehr Zeit sparen Sie.
  • Beginnen Sie damit, nach Bereichen mit Einschränkungen oder „Engpässen“ in Ihrem Produktionsprozess zu suchen. Dies hilft herauszufinden, wo die schnellen Gewinne erzielt werden können.
  • Versuchen Sie nicht, Ihre Praktiken auf einmal zu aktualisieren, dies kann zu viel Instabilität führen. Sie sollten einen Plan mit Beiträgen von allen in Ihrer Organisation erstellen.
  • Achten Sie auf die Fähigkeiten der Mitarbeiter: Gibt es Überschneidungen? Gibt es Multitalente? Ihre Mitarbeiter sind Ihre größte Ressource. Versuchen Sie, einen Weg zu finden, alle ihre Fähigkeiten optimal zu nutzen, sie werden sich besser geschätzt fühlen und Ihre Produktivität wird steigen.
  • Schauen Sie sich die Stimmung des Personals an; lange Arbeitszeiten und verpasste Termine können zu einem Motivationsrückgang führen, der sich auf die Produktion auswirkt. Behalten Sie das Management im Auge; Ihre Aufgabe ist es zu verwalten, es mag herablassend klingen, aber allzu oft vergessen sie ihre Rolle; Die Ärmel hochzukrempeln, um den Arbeitern zu helfen, ist manchmal nicht die beste Art zu helfen.
  • Finden Sie für das Zeitmanagement ein paar gute Tools und Indikatoren und bleiben Sie dabei. Zu oft greifen die Leute nach dem nächsten großen Ding, bleiben fünf Minuten dabei und sind dann hinter dem nächsten Werkzeug her. Stellen Sie sicher, dass Sie verstehen, wie sie funktionieren und ob sie das sind, was Sie brauchen. Ich würde demütig immer die einfachsten Dinge vorschlagen: Gantt-Diagramme, Produktflussdiagramme, Taktzeiten, um nur einige zu nennen. Halte es einfach ; Jeder in Ihrer Organisation muss sie verstehen können, damit Sie alle im gleichen Rhythmus auf die gleichen Ziele hinarbeiten können.
  • Holen Sie sich einen Berater. Sie müssen entgangene Einnahmen gegen die Kosten für die Beauftragung eines Fachmanns abwägen, der Ihnen bei der Lösung dieser Probleme hilft. Change Management sollte von jemandem übernommen werden, der sich nicht in die üblichen Angelegenheiten des Unternehmens einmischt.

Es gibt viele Bücher über Ihre Situation und Bücher zu jedem Punkt, den ich hier erwähnt habe. Der wichtigste Punkt, den ich noch einmal wiederholen werde, ist der Umgang mit Ihrer aktuellen Situation. Sie müssen vor allem anderen stabilisieren und eine feste Grundlage schaffen. Ich habe zu viele Unternehmen in der Situation erlebt, dass sie „Häuser auf Sand gebaut“ haben.

Ich glaube, du stellst hier vielleicht die falsche Frage. Sie haben erwähnt, dass das Problem darin besteht, dass Sie Fristen verpassen und nicht in der Lage sind, genaue Schätzungen darüber abzugeben, wann die Arbeit abgeschlossen sein wird. Der natürliche Instinkt der meisten Techniker ist es, nach einer Delivery-Management-Lösung zu suchen – und genau das haben Sie getan.

Ich würde jedoch vorschlagen, dass das, was Sie erleben, ein Problem mit der Kundenbeziehung ist. Wenn sich Kunden über verpasste Fristen und ungenaue Lieferschätzungen beschweren, könnten Sie diese Probleme angehen, indem Sie die Beziehung zu Ihren Kunden besser verwalten.

Ich würde empfehlen, dass Sie für jeden Kunden jemanden, vielleicht pro Kunde eine andere Person, als Ansprechpartner benennen. Sie sollten eine Beziehung zu diesem Kunden aufbauen, die es ihnen ermöglicht, über Fristen und Liefererwartungen zu verhandeln. Dadurch wird der Druck abgebaut, den Sie derzeit verspüren, lange zu arbeiten und unter engen Zeitvorgaben zu liefern.

Möglicherweise finden Sie auch einige Prozessverbesserungen, die Ihnen helfen, aber die Realität ist, dass sich der Großteil der Forschung in diesem Bereich auf größere, besser strukturierte Teams bezieht. Wie Sie festgestellt haben, ist der Versuch, „Best Practice“ für die Branche anzuwenden, für kleine Start-up-Gruppen tendenziell sehr problematisch.

Ich könnte der Antwort, die vorschlug, "keine Arbeit mehr zu übernehmen", nicht mehr widersprechen. Das Gewinnen von Arbeit ist das Lebenselixier kleiner Organisationen, und Sie sollten unbedingt jeden Kunden gewinnen, den Sie erreichen können. Aber tappen Sie nicht in die Falle des Ingenieurs und denken Sie, dass die einzige Lösung für ein Problem mit der Kundenwahrnehmung darin besteht, die Lieferqualität zu verbessern. Kunden können leichter mit verbessertem Kundenservice und etwas persönlicher Aufmerksamkeit zufrieden sein.

Es sind jedoch nicht die Kunden, die sich über Terminüberschreitungen und ungenaue Kostenvoranschläge beschweren, sondern wir. Wir sind unglücklich über das Verpassen von Fristen, weil dies bedeutet, dass sich noch mehr Arbeit vor uns ansammelt. Ich würde sogar behaupten, dass sich unsere Kunden nicht über die verpassten Termine beschweren, weil unsere Kundenbeziehungen bereits recht gut sind. Es ist jedoch ein interessanter Punkt und definitiv etwas, das ich im Hinterkopf behalten werde, falls solche Probleme in Zukunft auftreten sollten.

Ich kann James Shores „Art of Agile Development“ wärmstens empfehlen, um die Migration zu einer agilen Kultur anzukurbeln.

Eingebettet in die im Buch vorgeschlagenen Praktiken sind Konzepte wie „Weniger ist mehr“ zusammen mit einer guten Definition von „Erfolg“ (Schnittpunkt von technischem, persönlichem und organisatorischem Erfolg) und wie man ihn erreicht.

Es klingt, als stünden Sie vor der klassischen „Opfer Ihres eigenen Erfolgs“-Situation. Der Prozess, der Sie erfolgreich gemacht hat, behindert Ihr zukünftiges Wachstum.

Ich würde vorschlagen, dass Sie zunächst alle Gründe verstehen, warum Sie Fristen verpassen. Es ist unwahrscheinlich, dass es nur einer ist. Ich würde vorschlagen, ein Tool wie ein Ishikawa-Diagramm zu verwenden, http://en.m.wikipedia.org/wiki/Ishikawa_diagram . Stellen Sie sicher, dass Ihr Team daran beteiligt ist, alle Gründe zu identifizieren.

Zweitens priorisieren Sie die Themen, welche Gründe in kürzester Zeit die größte Wirkung haben werden. Dies ist das Problem, das zuerst angegriffen werden muss.

Sobald Sie sich entschieden haben, ein einzelnes Problem zu verbessern, seien Sie hartnäckig. Wenn Sie beispielsweise feststellen, dass Fehler Sie daran hindern, Fristen zu verpassen, implementieren Sie frühzeitige Codeüberprüfungen. Bleiben Sie dran, bis Sie eine Verbesserung sehen und die Veränderung in Ihre Kultur übernommen wird.

Versuchen Sie außerdem, wo immer möglich, Daten zu Ihrem Prozess zu erfassen, wie viele Verzögerungen Sie feststellen und was sie verursacht hat. Dies wird Ihnen helfen, den Wert Ihrer Verbesserungsbemühungen zu demonstrieren.

Ich würde Ty auch raten, nicht mehr als ein Problem gleichzeitig zu beheben.

Wie verbessere ich den Entwicklungsprozess bei unserem kleinen Startup?
AntwortenHierDatenschutz-Bestimmungen1y, 0v