Wie organisiere ich ein Team von „Schatten“-Softwareentwicklern (denken Sie an Ghostwriter)?

Die einfachste Antwort darauf wird wahrscheinlich die Antwort sein, die Ihnen am wenigsten gefällt. Nicht...

In den letzten etwa fünfzehn Jahren haben wir ein immer höheres Maß an Transparenz am Arbeitsplatz erlebt. Dies quert alle Branchen, alle Joblevels und alle Arbeitsstile. Agile hat nicht die Zugkraft erlangt, die es hat, weil es die besten Entwicklungsmethoden aller Zeiten ist. Agile ist nicht zuletzt deshalb erfolgreich, weil es den wachsenden Wunsch nach Transparenz, Ehrlichkeit und Zusammenarbeit am Arbeitsplatz unterstützt.

Was Sie tun möchten, ist das aufzubauen, was ich früher das "KGB-Entwicklungsteam" genannt habe. Sie geben ihnen eine Reihe von Anforderungen und sie sagen Ihnen sechs Monate lang: "Keine Sorge, wir sagen Ihnen, was Sie wirklich wollen, wenn wir liefern."

Unqualifizierte Mitarbeiter – Ihr Kunde kümmert sich um funktionierende Software. Das ist ihr Erfolgsmaßstab Nummer eins. Zeigen Sie ihnen Erfolg und Sie könnten Schimpansen haben, die für Sie arbeiten. Wenn Sie immer noch versuchen, Ihren ersten Kunden zu gewinnen, müssen Sie beim ersten Mal wahrscheinlich etwas härter arbeiten. Wenn Sie ein iteratives Entwicklungsmodell anwenden, das es Ihnen ermöglicht, Ihrem Kunden innerhalb der ersten 2-4 Wochen funktionierende, getestete Software zu zeigen, dann beweisen Sie sich auf diese Weise.

Wenn Sie Ihrem Kunden gegenüber offen sind, werden sie fast immer toleranter sein. Wenn Sie ihnen nicht einmal die Namen Ihrer Entwickler mitteilen, werden einige Ihrer Kunden zur Tür rennen, weil sie ihr Produkt nicht Leuten anvertrauen, die einen fragwürdigen Hintergrund haben könnten. Jeder Kunde mit irgendeiner Art von Regierungskunden wird Sie nicht einmal anfassen.

Mitarbeiter werden von Kunden abgeworben Zunächst einmal: Wenn Sie ein gutes Arbeitsumfeld schaffen, in dem sich Ihre Mitarbeiter als Teil des Teams fühlen, verringern Sie die Wahrscheinlichkeit, dass sie das Unternehmen verlassen. Wenn Sie versuchen, ihre Namen zu verbergen, schaffen Sie lediglich etwas, das sowohl der Kunde als auch Ihr Mitarbeiter überwinden müssen. Wenn Sie einen Vertrag mit Google haben und Ihr Mitarbeiter schon immer für Google arbeiten wollte, können Sie ihn nicht daran hindern, sich mit Google zu verbinden. Und umgekehrt gibt es keine Möglichkeit, Ihren Kunden davon abzuhalten, herauszufinden, wer Ihre Leute sind, wenn sie entschlossen sind. Abgesehen von den radikalsten Black-Hat-Hackern gibt es keine Anonymität im Netz.

Es kommt direkt auf Transparenz und Vertrauen zurück. Sie müssen darauf vertrauen, dass Ihre Kunden und Mitarbeiter professionell sind. Wenn ein Kunde ständig Ihre besten Programmierer abwerbt, dann weiß er, dass dies seinen Ruf nicht nur bei Ihnen beeinträchtigen wird. Dies wirkt sich auf ihre Fähigkeit aus, mit externen Auftragnehmern zusammenzuarbeiten.

Fazit – Transparenz und Vertrauen sind die besten Wege, um ein „Schatten-Entwickler“-Team zu haben . Versuchen Sie nicht, ein Schatten-Entwickler-Team zu gründen. Sie werden das Vertrauen Ihrer Kunden nicht haben. Sie werden Ihre Programmierer nicht motivieren und es wird eine Schicht Arbeit für Sie schaffen, die das Ergebnis nicht wert ist.

Gehen Sie stattdessen die Probleme an, die Sie haben. - Qualitätsarbeit - Empfehlungen für frühere Kunden - Keine Abwerbeklausel in Ihrem Vertrag - Bringen Sie Ihre Programmierer dazu, mehr für Sie arbeiten zu wollen

Die Vertragsart ist ein weiterer zu berücksichtigender Faktor. Ein Vertrag mit festem Festpreis (FFP) kann Ihnen die von Ihnen gewünschte Opazität bieten. Die Spezifikation wird im Lastenheft oder im Statement of Objectives festgelegt. Das Produkt wird anhand der Spezifikation zur Abnahme bewertet. Um der Undurchsichtigkeit entgegenzuwirken, kann der Käufer eine „Schlüsselpersonen“-Klausel verlangen, die von Ihnen verlangt, eine bestimmte Anzahl von Mitarbeitern, ihre Qualifikationen und ihre vertraglichen Pflichten zu identifizieren.

Theoretisch legt FFP das Risiko auf den Anbieter und erlaubt dem Anbieter, die Leistung so zu erstellen, wie der Anbieter es für am besten hält (auch bekannt als die geringsten Kosten). FFP tendiert dazu, strengere Abgrenzungslinien zwischen Anbieter und Käufer zu schaffen, was die Rolle des Product Owners im Scrum-Prozess erschwert. Das ist nicht der empfohlene Vertragstyp für die Softwareentwicklung, da es eine definierte Leistung voraussetzt, was bei Anwendungen selten der Fall ist, und das Gegenteil des agilen Ansatzes ist.

Cost Plus (CP) hat eher einen Arbeitsumfang als eine Spezifikation. Gewinn und Gemeinkosten sind Teil der Festgebühr. Da die Kosten variabel sein können, muss der Einkäufer die Eingaben und den Prozess überprüfen, durch den die Leistung erstellt wird. Dadurch können sich Anbieter und Käufer das Risiko teilen. Eine Variante von CP sind Kosten plus feste Gebühr, Kosten plus Prämiengebühr (wobei Prämien für bestimmte Faktoren wie frühe Lieferung oder technische Exzellenz vergeben werden).

Ein Zeit- und Materialvertrag (T&M) hat den allgemeinsten Arbeitsumfang und die größte Flexibilität (und das größte Risiko) für den Käufer. Lohn- und Materialsätze werden bei Auftragsvergabe ausgehandelt. Dies birgt für den Anbieter das geringste Risiko, und daher verlangt der Käufer typischerweise eine größere Unsichtbarkeit des Prozesses, der Praktiken, des Personals und anderer Eingaben des Anbieters.

Aus Sicht des Vertragsrisikos bietet T&M Ihnen (dem Entwickler) also den attraktivsten Vertragstyp und ist der kongenialste Vertragstyp für agile und Scrum-Prozesse. FFP gibt Ihnen jedoch die vollständige Kontrolle über Ihre Arbeit und Prozesse, sodass Sie aus Vertragsperspektive einstellen können, wen Sie wollen. Beachten Sie, dass es Einschränkungen bei Ihren Einstellungspraktiken geben kann; ein Vertrag kann den Einsatz diskriminierender Praktiken, Gefängnisarbeit oder ausländischer Arbeitskräfte verbieten. Sozioökonomische Anforderungen und Einschränkungen sind in Regierungsverträgen üblich.

Joel sprach gut. Als jemand mit dem gleichen Problem gehe ich das Dilemma jedoch folgendermaßen an:

1. Beziehungen, nicht Fähigkeiten, sind wichtig. Ich stelle nur hervorragende Leute ein, sei es Techniker oder sonstiges. Daher ist es mein Ziel, mit Mitarbeitern, von denen die meisten über mich Verträge abschließen, eine hervorragende Arbeitsbeziehung zu haben. Wenn sie gehen wollen, ist das schade für mich, aber hoffentlich werden die Anreize, in einer hochklassigen Firma mit exzellenten Projekten, nahezu perfekter Organisation und guter Bezahlung zu arbeiten, sie dazu bringen, zu bleiben.
2. Mehr, nicht weniger Transparenz ist wichtig. Ihr Problem ist, dass Sie die Kontrolle über Ihr Team behalten wollen. Das ist, respektvoll, kindisch. Die Leute werden ihre Entscheidungen treffen und wenn du das nicht respektieren kannst, dann wirst du sie nicht halten können. Wenn jemand versucht, sie wegzuheuern, werden sie wahrscheinlich gehen. In meinem Geschäft haben alle die gleiche Transparenz: Ich teile nicht unbedingt alles, aber ich teile alles im Rahmen des Zumutbaren. Mitarbeiter sprechen bei Bedarf mit Kunden und können selbst entscheiden, wann dies der Fall ist. Wenn jemand versucht, sie einzustellen, sage ich ihnen direkt, dass sie tun können, was sie wollen. Manchmal gehen sie und manchmal nicht. Aber ich habe deswegen noch nie negative Erfahrungen gemacht. Egal was, wenn ich meinen Leuten vertrauen kann und umgekehrt,
3. Arten von Mitarbeitern spielen keine Rolle (außer gesetzlich). Wenn Sie einen 16-Jährigen beschäftigen und ihm gesetzlich nicht 40 Stunden Arbeit pro Woche geben dürfen, verstehe ich das. Gute Leute sind schwer zu finden, und Gesetze, die als veraltet gelten, sind schwer in Einklang zu bringen. Aber bedenken Sie das Risiko für Ihr Unternehmen, wenn Sie es herausfinden. Es lohnt sich fast nie. Aber was noch wichtiger ist, wenn Sie beide offen über die Situation sprechen und sich darauf einigen, was zu tun ist, sollte es Ihnen gut gehen.

Ich arbeite mit allen Typen, lokalen und entfernten, englischen Muttersprachlern und Menschen in fernen Ländern, 60+ und sogar jemandem, der 15 Jahre alt ist. Es gibt eine Gemeinsamkeit: Sie sind alle Menschen. Behandle sie als solche und es wird dir gut gehen. Aber bedenken Sie die rechtlichen Auswirkungen aller Fälle.

Vertrauen ist schwer zu bekommen und schwerer zu verdienen. Ich beginne jedes Meeting mit einem einzigen Satz: „Mein Ziel ist es, Ihnen zum Erfolg zu verhelfen, und um das zu tun, sind wir absolut transparent. Das gilt für potenzielle Auftragnehmer und Kunden gleichermaßen. Ich sage es immer wieder und ich meine es jedes Mal mehr. Es bringt mich wirklich um, wenn ein neuer Kunde oder Auftragnehmer entlassen werden muss, weil er nicht offen bleiben kann. Ich bin kurz davor, einen Kunden nach einer letzten Warnung zu entlassen. Ich habe weder die Zeit noch die Geduld, mich mit armen Kunden zu befassen, die nicht konsequent und klar bleiben können, weil sie sich weigern zu teilen. Ich habe kein Interesse daran, mit Leuten zusammenzuarbeiten, die ihre Arbeit verbergen, lügen oder anderweitig fabrizieren.

Das Leben ist zu kurz für BS. Also machen Sie es richtig, machen Sie etwas, worauf Sie stolz sind, und machen Sie weiter mit der nächsten Sache.

Da Sie für eine Situation plädieren, in der (zumindest einige) Ihrer Mitarbeiter von der Anonymität profitieren, fällt mir nur eine Option ein:

Codenamen

Schaffen Sie eine Kultur von „Ninja-Trupps“ oder einer ähnlichen Metapher für Supertalent. Alle Ihre Entwickler sind remote, also schneiden sie nicht durch F2F. Sie können jedem individuell die Art und Weise vermitteln, wie der Codename / die Persona ihnen einen Hauch von Mysterium, Kontrolle gegen Vorurteile und Wahrnehmung und andere "schlechte Assery" jeder Art verleiht, die sie anspricht.

Sie müssen einen schmalen Grat zwischen wirklichem Hochhalten und der Aufrechterhaltung der Professionalität gehen – sowohl intern als auch extern. Da Ihr Team regelmäßig und möglicherweise in gemeinsamen Gesprächen auf diese Weise angesprochen wird, sollten Sie es bei der Auswahl coachen (wenn es etwas wählt, das zu weit geht). Vielleicht möchten Sie einen Grafikdesigner dafür bezahlen, dass er sich mit jedem neuen Teammitglied „berät“.

Es gibt noch viele tückische Herausforderungen auf diesem Weg, aber zumindest haben Sie einen guten Umgangsstil und andere schwierige Kräfte.

Ich sehe keinen Weg, um zu vermeiden, dass es sich um eine Spielerei handelt, und das wird nur die Glaubwürdigkeit Ihres Unternehmens untergraben. Bei Geschäftsbeziehungen geht es um Vertrauen – und Sie sprechen davon, dieses Nebendesign zu brechen. Daher denke ich, dass sie am besten Pseudonyme verwenden.

Ich spreche hier von einigen Erfahrungen. Ich habe Beratungsunternehmen unter Vertrag genommen, die versuchten zu verbergen, wie viele verschiedene Entwickler an der Arbeit arbeiteten. Es war offensichtlich. Als Ergebnisse in Frage kamen, hatte ich keinerlei Vertrauen, dass irgendetwas Zuverlässiges getan oder gesagt werden würde. Jedes Ergebnis danach war nur ein Mist-Shooting, bis es gesendet und validiert wurde.

Ich gehe davon aus, dass dies keine Frage der Integrität, sondern eher der Logistik ist. Als PM gehe ich davon aus, dass Sie auch einen Verhaltenskodex haben, den Sie in Ihrem B2B-Kommuniqué erklären. Abgesehen davon habe ich dies mit Rollen anstelle von Programmierernamen und -adressen getan. ZB: „Lead Developer“, „J2EE-Entwickler“, „WET4-Ingenieur“ usw. Dies erlaubt mir, den Programmierer zu wechseln, falls ich keinen Vertrag mehr mit Jimmy habe. Meine Kunden haben nie gefragt, wer der Entwickler ist oder wo er/sie auf dem Planeten lebt. Letztendlich hört der Bock hier bei mir auf.

So könnten Sie es mit Git machen:

• Erstellen Sie für jedes Arbeitspaket einen Feature-Branch mit Nur-Lese-Zugriff auf andere
• Bitten Sie Ihren Entwickler, den Zweig zu forken, und erstellen Sie dann einen Pull-Request mit seinen Änderungen
• Überprüfen Sie den Pull-Request und führen Sie ihn nach der Genehmigung in Ihren Feature-Branch ein (im Git-Protokoll sind Sie der Autor des Merge-Commits).
• Schreiben Sie bei Bedarf eine Logik, um die neue Funktion zu integrieren (z. B. Labels umbenennen, Portnummern passend zu Ihrer Client-Umgebung korrigieren, Farben in GUIs korrigieren usw.)
• vom Feature-Branch zum Main-Branch deines Clients zusammenführen

Dieser Arbeitsablauf bedeutet Folgendes:

• Sie müssen jede Anforderung vertreten und Ihrem Programmierer erklären, dann alle Fragen sammeln und sich mit Ihrem Kunden beraten, was kompliziert sein kann
• Sie müssen sehr gut im Delegieren werden und dürfen Ihre Entwickler nicht im Mikromanagement verwalten
• Für mich hat das Arbeiten mit Screen-Casts, das Erklären, was zu tun ist, das Schreiben von User-Stories und die Durchführung regelmäßiger Skype-Meetings gut funktioniert