Ich bin vor ein paar Jahren in dieses kleine Unternehmen eingetreten, das derzeit weniger als 10 Mitarbeiter hat. Das Hauptprodukt ist eine SAAS-Anwendung, deren Kundenstamm stetig wächst. Der Gründer und CEO hat das meiste davon von Grund auf selbst programmiert, mit der Hilfe von gelegentlichen Handlangern. Ich respektiere sehr, was er bisher mit dem Geschäft gemacht hat, ich habe nicht so viele getroffen, die so ehrgeizig sind wie er.
Dann wurde ich als erfahrener Entwickler eingestellt, um eine Art technischer Leiter zu sein, mit dem Ziel, das Qualitätsniveau zu erhöhen und die organisatorische Skalierbarkeit codeweise zu erweitern, damit wir in der Lage sein könnten, mehr Entwickler einzustellen, die wir bereits haben, und zwar bald hoffentlich noch mehr. Bisher habe ich Versionskontrolle und Tests eingeführt und versucht, zusammen mit meinem Team ein gewisses Maß an Codierungsstandards und -richtlinien zu modernisieren und festzulegen, was ziemlich gut funktioniert, immer noch mit deutlichem Verbesserungspotenzial, aber auf dem richtigen Weg. Das Problem ist für mich der CEO. Er ist Autodidakt, nicht dass das ein Problem an sich wäre, aber er hat sich keine Programmierkenntnisse angeeignet, die über grundlegende Tutorials auf niedrigem Niveau hinausgehen, die für die von uns verwendete Technologie spezifisch sind. Aus Gründen, die ich niemals in Frage stellen würde, verbringt er wenig Zeit im Büro, hauptsächlich Führungsaufgaben ausführt, wie er es auf jeden Fall tun sollte. Er geht früh oder arbeitet einige Tage komplett weg und verbringt dann oft Zeit außerhalb der Bürozeiten mit Programmieren. Er springt meistens auf neue Ideen oder spezielle Funktionen ein, die einzelne Kunden angefordert haben, und fügt sie direkt in die Produktion ein, wobei er unsere regulären Verfahren hinter sich lässt, als wäre er immer noch der einzige Entwickler, der sich nicht um die Standards kümmert, denen er immer sehr positiv gegenübersteht. Seine Arbeit führt manchmal zu Problemen, die bei mir und meinen Teamkollegen landen, oder einfach zu neuen Funktionen, von denen wir nicht wissen, wie sie funktionieren sollten, weil wir keine Zeit haben, sie durchzugehen, und wenn er nicht da ist, verbringen wir unnötig Zeit mit Fragen von Kunden über sie. Er springt meistens auf neue Ideen oder spezielle Funktionen ein, die einzelne Kunden angefordert haben, und fügt sie direkt in die Produktion ein, wobei er unsere regulären Verfahren hinter sich lässt, als wäre er immer noch der einzige Entwickler, der sich nicht um die Standards kümmert, denen er immer sehr positiv gegenübersteht. Seine Arbeit führt manchmal zu Problemen, die bei mir und meinen Teamkollegen landen, oder einfach zu neuen Funktionen, von denen wir nicht wissen, wie sie funktionieren sollten, weil wir keine Zeit haben, sie durchzugehen, und wenn er nicht da ist, verbringen wir unnötig Zeit mit Fragen von Kunden über sie. Er springt meistens auf neue Ideen oder spezielle Funktionen ein, die einzelne Kunden angefordert haben, und fügt sie direkt in die Produktion ein, wobei er unsere regulären Verfahren hinter sich lässt, als wäre er immer noch der einzige Entwickler, der sich nicht um die Standards kümmert, denen er immer sehr positiv gegenübersteht. Seine Arbeit führt manchmal zu Problemen, die bei mir und meinen Teamkollegen landen, oder einfach zu neuen Funktionen, von denen wir nicht wissen, wie sie funktionieren sollten, weil wir keine Zeit haben, sie durchzugehen, und wenn er nicht da ist, verbringen wir unnötig Zeit mit Fragen von Kunden über sie.
Ich verstehe, dass wir wachsen und eine höhere Rentabilität erreichen müssen, aber es fühlt sich definitiv so an, als ob er kurzfristig niedrigen Bällen hinterherjagt, um coole oder große Kunden zu gewinnen, die sich auszahlen oder nicht auszahlen können, und sagt, dass wir (die Entwicklermitarbeiter) reparieren und säubern werden später, sondern wird stattdessen zu vielen kleinen Kopfschmerzen, an denen wir sowieso keine Zeit haben, weil es immer etwas Wichtigeres gibt.
Ich habe versucht, meine Probleme mit meinem Chef und dem Mitbegründer des Product Owners zu besprechen, und sie reagieren mit Akzeptanz und Verständnis. Aber bei unserer letzten Mitarbeiterbeurteilung bekam ich tatsächlich das Feedback, dass ich „manchmal versuchen sollte, Aufgaben schneller zu erledigen, anstatt zu versuchen, den bestmöglichen Weg zu finden“, aber auch, dass sie von der Qualität meiner Arbeit im Allgemeinen beeindruckt sind. Ich stimme zu, dass Sie nicht so viel Zeit für jede Aufgabe aufwenden können, und ich akzeptiere die Prämisse, dass ich eine enge Perspektive haben könnte, aber gleichzeitig glaube ich, dass der CEO weder über Entwicklungsmethoden Bescheid weiß noch ein theoretisches Verständnis davon hat Softwarearchitektur oder sogar mehr als eine sehr einfache Objektorientierung, was dieses Feedback etwas schwer zu schlucken macht.
Ich glaube langsam, dass ich nicht gut zu diesem Unternehmen passe. Ich weiß, dass ich die technischen Fähigkeiten habe, aber ich glaube, ich vermisse die Soft Skills, die erforderlich sind, um ein technischer Leiter in dieser Art von Organisation zu sein, die ich sein sollte und möchte. Ich sehe einfach nicht, wie ich das angehen kann, ohne abschätzig zu sein, da ich das Gefühl habe, dies bereits zu schreiben. Ich bin wahrscheinlich ein bisschen frustriert darüber, dass ich das Gefühl habe, aufgrund dieser Situation ein schlechterer Entwickler zu werden.
Ist es einfach an der Zeit, weiterzumachen und eine Gelegenheit zu finden, bei der ich diese Fähigkeiten in einem für mich besseren Umfeld erweitern kann? Oder gibt es einen besseren Weg, so etwas zu handhaben?
Dies ist ein sehr häufiges Problem in kleinen Geschäften; Ich habe die gleichen Probleme selbst verursacht, als ich damals ein Software-Startup betrieb.
Der Schlüssel zur Lösung ist Bildung. Unabhängig davon, ob Ihr CEO daran interessiert ist, ein Big-D-Entwickler zu sein, ob er mit Ideen zur Codequalität konfrontiert ist, was Unit-Tests sind und warum sie wichtig sind usw., er wird es verstehen und sich letztendlich an Sie wenden, um die Führung zu übernehmen .
Eine Möglichkeit, ihn zu schulen, besteht darin, ihn dazu zu bringen, zu mehrsprachigen technischen Konferenzen wie CodeMash oder That Conference zu gehen , und ihn zu ermutigen, „mit neuen Ideen zur Verbesserung unserer Codequalität zurückzukommen“. Noch besser: Gehen Sie mit ihm und sprechen Sie das Thema „Wie man keine schlechte Software veröffentlicht“ mit anderen auf der Konferenz an, während er in der Nähe ist.
Eine weitere gute Option besteht darin, ein lokales technisches Beratungsunternehmen einzuladen, vorbeizukommen und ein Brown-Bag-Mittagessen zu diesem Thema zu geben. Die meisten tun so etwas kostenlos und (Bonus!) können darauf bestehen, dass der Chef da ist, da sie so Umsatz erzielen. (Sie sollten das in diesem Fall als Hinweis an das Beratungsunternehmen geben: „Bitte stellen Sie sicher, dass unser CEO anwesend ist; er muss das wirklich hören.“) Ein großer Vorteil von Beratern ist, dass sie ein unabhängiger und glaubwürdiger Dritter sind, der bezahlt wird den Mächtigen die Wahrheit zu sagen, was in diesem Fall nötig ist. (Haftungsausschluss: Ich arbeite derzeit für ein Beratungsunternehmen.)
In Bezug auf das Feedback, das Sie bezüglich der Geschwindigkeit im Vergleich zu „der bestmögliche Weg“ erhalten haben, könnten Sie darauf hinweisen, dass es einen erheblichen Unterschied zwischen „einfach versenden“ mit fehlenden Funktionen und „jetzt versenden“ gibt. mit Fehlern, die Benutzer frustriert und wütend machen. Wenn er den Zusammenhang zwischen Softwarequalität und zufriedenen Kunden versteht, wird er Sie eher unterstützen.
Wenn der CEO überhaupt ansprechbar ist, sollte er für dieses Feedback absolut offen sein. Schließlich hat er Sie als technischen Leiter eingestellt. Wenn Sie also entscheiden, dass bestimmte Standards erfüllt werden müssen und dass seine Beiträge diesem Standard nicht entsprechen, müssen Sie ihn das wissen lassen.
Wenn Sie dies auf die "weichste" Weise tun möchten, die nicht den Anschein erweckt, als würden Sie ihn herausgreifen, würde ich obligatorische Codeüberprüfungen für den gesamten Code einführen, der festgeschrieben wird (falls Sie dies nicht bereits tun). Stellen Sie sicher, dass alle Arbeiten über PR eingereicht werden und nicht direkt an den Hauptentwicklungszweig, und wenn dann jemand eine PR einreicht (Sie, Ihr Junior, der CEO usw.), beauftragen Sie eine andere Person, diesen Code anhand der dokumentierten Codequalität zu überprüfen & Standardregeln vor der Genehmigung. Viele Systeme erlauben es Ihnen, dies zu erzwingen, sodass das direkte Festschreiben an den Hauptzweig verboten ist.
Natürlich, wenn der CEO das verneint oder sich darüber beleidigt fühlt, dass sein Kodex nicht auf dem neuesten Stand ist, haben Sie nicht wirklich viele Möglichkeiten - er ist der Boss. Wenn Sie sich entscheiden, woanders eine Anstellung zu suchen, ist die gute Nachricht, dass Sie dies in Ihrem eigenen Zeitrahmen tun können. Diese Art von Codierungsstil verursacht eher mittel- bis langfristig Probleme (technische Schulden), sodass Sie nicht sofort aussteigen müssen, wie dies bei größeren Problemen der Fall sein könnte.