Szoftver szerepek és címek

Fotó: Henry (CC-BY-2.0)

Nagyon sok zavart vettem észre az iparban a különféle szoftveres szerepek és címek vonatkozásában, még az alapítók, a menedzsereket és a csapatépítőket illetően. Melyek a szoftvercsapat különféle szerepei és felelősségei, és mely munkakörök fedik le általában azokat a szerepeket?

Mielőtt ezt túl sokat tanulmányoznám, szeretném hangsúlyozni, hogy minden csapat egyedülálló, és a felelősségek hajlamosak lebegni vagy megoszlani a csapat különböző tagjai között. Bármely személy bármikor átruházhatja a felelősséget másokra, különféle okokból - ezek közül sok érvényes.

Ha a csapatod nem pontosan az, amit itt leírok, üdvözlöm a klubban. Azt gyanítom, hogy nagyon kevés csapat van, és egyes szoftveres szerepek tökéletesen megfelelnek annak, amit felfedezni fogunk. Ez csak egy általános keret, amely több átlagot ír le, mint bármely konkrét szerep vagy csapat.

A vezetői címekkel kezdtem, és különféle szerepeken dolgozom, nagyjából idő szerint.

Szeretném hangsúlyozni azt is, hogy nem szabad éreznie, hogy korlátozza a beosztása. Szeretek olyan mérnöki kultúrát építeni, amely a következőket támogatja:

  • A címekkel kapcsolatos készségek
  • Folyamatos kézbesítés határidőn belül
  • Támogassa a hibát
  • Együttműködés a verseny felett

Szeretem megnövelt felelősséggel jutalmazni a kezdeményezést, és ha valaki rendelkezik készségekkel és kezdeményezésekkel ahhoz, hogy megszerezzék és kibővítsék az általuk felkínált címet, inkább inkább előmozdítom, mint hogy kockáztatnék egy növekvő csillag elvesztését egy másik társaság vagy csapat számára.

Szoftverfejlesztési szerepek

  • Mérnöki munkatárs
  • vezérigazgató
  • CTO
  • CIO / digitális vezérigazgató / innovációs vezérigazgató-helyettes
  • Mérnöki Alelnök / Mérnöki Igazgató
  • Főépítész
  • Szoftver építész
  • Mérnöki projektmenedzser / Mérnöki vezető
  • Műszaki vezető / műszaki vezető / csapat vezető
  • Fő szoftvermérnök
  • Senior szoftvermérnök / vezető szoftverfejlesztő
  • Szoftvermérnök
  • Szoftverfejlesztő
  • Junior szoftverfejlesztő
  • Intern szoftverfejlesztő

Beszélünk egy kicsit arról is, hogy ezek a szerepek hogyan kapcsolódnak más szerepekhez, beleértve:

  • A termékmenedzsment alelnöke / termékvezető
  • Termék menedzser
  • Marketing alelnök
Megjegyzés: Néha a „rendező” vagy a „fej” címek középvezetőket jelölnek a tech menedzserek és a C-Suite között. Gyakran a „Chief” címek jelzik a C-suite címet. A C-suite alkalmazottainak általában közvetlenül a vezérigazgatónak kell beszámolniuk, és potenciálisan sok jelentést lehetnek az általuk irányított szervezetekben. Nagyon nagy cégeknél ezek az alternatív címek gyakran hasonló szerepeket töltenek be, mint a C-suite vezetõk, de jelentést tesznek valakinek, aki a nagyobb szervezeten belül egy kisebb üzleti egység vezérigazgatója. A különböző üzleti egységek néha úgy működnek, mintha különálló társaságok lennének, különálló elszámolással, pénzügyi tisztviselőkkel stb. Különböző üzleti egységek is lehetnek VP-k, pl. “Mérnöki alelnök, Kereskedelmi Operációk”.

Mérnöki munkatárs

A „fickó” cím a szoftvermérnökök teljesítményének csúcspontja. Általában azoknak az elismerésnek adják ki, akik kiemelkedően hozzájárultak a számítástechnika területéhez, és általában akkor adják ki, amikor egy mérnök számos legnépszerűbb könyvet írt, olyan díjakat nyert, mint a Turing-díj, a Nobel-díj stb. , a társak általában már híresek a szervezeten kívül, és a vállalat megpróbálja megerősíteni márkájukat azáltal, hogy erőteljesebben társul önmagához csodált és befolyásos emberekkel.

Véleményem szerint a szervezeteknek nem szabad megkísérelni bérezni „társ” szerepeket. Ehelyett keresse meg a legjobb és legfényesebbet, bérelje fel őket, majd adja meg a címet (és az előnyöket), ha a mérnök megérdemli.

Egy munkatárs általában egy másik címet is visel a társaságban. Gyakran egy műszaki vezető, építész, a műszaki vezérigazgató vagy fő szerepe, ha vezethetnek, mentorozhatnak, vagy példaként szolgálnak és ösztönzőként szolgálhatnak a szervezet más tagjai számára.

vezérigazgató

A vezérigazgató a szervezet legnagyobb tekintélye. Általában meghatározzák a társaság látását és északi csillagát. Mindenkit egységes megértés mellett vonnak össze, hogy miért létezik a cég, mi a küldetés és mi a vállalat értékei. A vezérigazgatók gyakran a társaság nyilvános arca is, és egyes esetekben a márkanév szinonimáivá válnak (például Steve Jobs az Apple-nél, Elon Musk a Tesla / SpaceX-nél stb.)

Bizonyos esetekben a vezérigazgatók egyben a szoftver szervezet műszaki alapítói is, ebben az esetben gyakran a CTO szerepet is betöltsék, és működési, értékesítési, stratégiai és marketing alelnökökkel rendelkeznek, amelyek segítenek a többi általános vezérigazgatói felelősségvállalásban. .

Egy kis cég vezérigazgatója gyakran nagyon sok kalapot visel, mivel valószínűleg felvette az összes többi olyan szerepet, amelyek a vezérigazgatói címből kikerültek, amikor megemlítettem, hogy néhány vezérigazgató vezet a technológiai csapatot.

Mindenesetre, ha fontos szervezeti döntéseket kell hozni, akkor a felelősségi láncot sem veheti magasabbra, mint a vezérigazgató.

Ha Ön vezérigazgató, ne feledje, hogy végső soron felelõs vagy, és bízzon az ösztöneiben, de ne felejtse el, hogy még a leghíresebb vezérigazgatóknak is vannak mentori és tanácsadói, akikkel rendszeresen konzultálnak. Bízzon a bélben, de keressen okos, éleslátó embereket, akik szintén kihívást jelentenek javítására.

CTO

A vezérigazgatói szerephez hasonlóan a CTO szerepe is idővel változik. A fiatal induló vállalkozásoknál a CTO gyakran technikai társalapozó egy látnok vagy domain-vezérelt vezérigazgatóhoz. Gyakran nem képesek arra, hogy egy nagyobb társaságban megszerezzék a címet, és remélhetőleg növekedni fognak abban, ahogy a vállalat növekszik. Gyakran egy induló CTO azt találja, hogy inkább a műszaki mérnöki szerepeket részesítik előnyben, és visszatelepülnek más szerepekbe, mint például mérnök, mérnöki alelnök vagy főépítész.

Sok szervezetben az érett CTO szerepe kifelé néz. Részt vesznek üzleti fejlesztési találkozókon, gyakran segítve a nagy partnerségek vagy az értékesítés kiépítését. Közülük sokan eljutottak a konferencia körébe, és sok időt töltenek a szervezet fejlesztési tevékenységeinek a szélesebb világba történő evangelizálásával: megosztják a társaság innovációit és felfedezik a piacon olyan lehetőségeket, amelyek jól illeszkednek a vállalat alapvető kompetenciáihoz. A CTO-k gyakran szorosan együttműködnek a termékcsapattal a termékstratégia terén, és gyakran rendelkeznek belső szemlélettel a műszaki tervekben, mint például a Mérnöki Főosztály.

A CTO-k gyakran meghatározzák a mérnöki csapat jövőképét és északi csillagát. A csapat céljainak elérése.

CIO / digitális vezérigazgató / innovációs vezérigazgató-helyettes

Az innovációs vezérigazgató-helyettes (CIO) olyan, mint egy CTO, de általában olyan társaság alkalmazottja, amelyet általában nem tekintünk „tech-vállalatnak”. A CIO célja, hogy átalakítsa a társaságot olyan vállalattá, amelyet a fogyasztók technikai értelemben hozzáértőnek és innovatívnak tekintnek: Megmutatják a világnak, hogy milyen az ipar jövője, függetlenül attól, hogy mi ez az iparág. Például egy otthoni átalakító szupermarket láncban lehet egy CIO, amely felelős a technológiai vállalatokkal való együttműködésért egy vegyes valóság alkalmazás létrehozásáért, amely megmutatja a vásárlóknak, hogy egy adott kanapé vagy a fal színe hogyan néz ki a nappaliban, vagy blokkláncok és kriptovaluták használatával javíthatja a az ellátási lánc logisztikájának biztonsága és hatékonysága.

Nem szabad összetéveszteni az információs vezérigazgatóval (CIO), egy olyan címmel, amelyet általában a technológiától még jobban elszigetelődő vállalatoknál használnak, és érdekli, amennyiben az segíti az alapvető működésüket. Az innovációs vezérigazgatótól eltérően, az információs tisztviselő inkább a technológiai integrációt és az adatáttelepítési projekteket vezeti, mint új alkalmazásokat épít, és megpróbálja kitalálni, hogy egy vállalat miként képes zavarni magát belülről. Vannak olyan információs tisztviselők, akik inkább az innovációs vezérigazgatók körében viselkednek, de véleményem szerint a megfelelő címet kell használniuk.

A legtöbb tech-natív vállalatnak (alkalmazásfejlesztőnek stb.) Nincs ilyen típusú informatikai vezetője. Ehelyett ezek a felelősségek a CTO-ra és a Mérnöki Alelnökre hárulnak.

Mérnöki Alelnök / Mérnöki Igazgató

Míg a CTO-k gyakran kifelé mutatnak, a Mérnöki Főképviselő gyakran befelé néz. A mérnöki tisztviselő gyakran felelős a mérnöki csapat felépítéséért, valamint a mérnöki kultúra és működés kialakításáért. A CTO megmondhatja a mérnöki csapatnak, hogy mit kell tennie a nagy léptékben, például: „Legyen a vezető újító az ember és a számítógép közötti interakcióban”. A mérnöki tisztségviselő elősegíti a „hogyan” irányító kultúra előmozdítását. A mérnöki legjobb VP-k először találkoznak valakivel, aki ott van, hogy segítse a csapat hatékony működését, majd majdnem eltűnnek. A csapat fejlesztői jól működnek együtt, mentorálnak, hatékonyan kommunikálnak, és azt gondolják: „Hé, nagyszerű csapat vagyunk. Nagyon jól működünk együtt! ”És talán azt gondolják, hogy ez mind szerencsés baleset.

Az igazság az, hogy szinte soha nem történik véletlenül. Ennek oka az, hogy a mérnöki tisztviselő folyamatosan figyeli a csapat előrehaladását, folyamatát, kultúráját és a kommunikáció hangját. Arra ösztönzik a fejlesztőket, hogy használják bizonyos eszközöket, bizonyos típusú találkozókat tartanak meghatározott időpontokban annak érdekében, hogy elősegítsék a jobb együttműködést kevesebb megszakítással. A mérnökök legjobb mérnökei a mérnökök voltak, mind diszfunkcionális, mind nagyon funkcionális csapatoknál. Ismerik a hatékony szoftverfejlesztési munkafolyamatok mintáit és anti-mintáit.

A termékfejlesztőkkel és a termékmenedzserekkel működnek együtt annak biztosítása érdekében, hogy jó termék-felfedezési folyamat legyen (nem vezetik, vagy nem vállalják át őket, csak ellenőrzik, hogy valaki rajta van-e és jól csinálja-e), és hogy ez a termék és A tervezési eredményeket a mérnökök megfelelő módon felülvizsgálják a megvalósítás előtt. Megállom, mielőtt könyvet írok az összes munkáról, amely a hatékony fejlesztési műveletek vezetéséhez vezet. A témával kapcsolatos további gondolataimmal kapcsolatban lásd: Hogyan állítsunk össze nagysebességű fejlesztőcsapatot.

Sok induló vállalkozás túl kicsi ahhoz, hogy teljes munkaidős műszaki vezérigazgató-helyet foglaljon el, de továbbra is nagyon fontos, hogy a mérnöki kultúrát a lehető leghamarabb megkapjuk. Ha segítségre van szüksége ezzel kapcsolatban, keresse fel.

Főépítész

Kis szervezeteknél a főépítész műszaki társalapító lehet az öntudatossággal annak felismerése érdekében, hogy a vállalat növekedésével nem akarják a CTO felelősségét. Lehet, hogy nem szeretnek utazni, vagy egyszerűen inkább a szoftver-tervezés iránt érdeklődnek, mint a konferenciabeszélgetések, üzleti fejlesztések és értékesítési hívások, amelyek beszivárognak sok CTO életébe. A főépítész felelős lehet a technológiai halmok kiválasztásáért, az együttműködések és a számítási rendszerek közötti interfészek megtervezéséért, a számítási szolgáltatások kínálatának (AWS, Azure, ZEIT Now stb.) Kiértékeléséért és így tovább. A főépítész az iparág kínálatának széles skáláját értékelheti, és előre jóváhagyott vagy kedvezményes ajánlásokat tehet az egyes gyártókkal való együttműködésre.

A vállalat érett állapotában a főépítésznek szintén szorosan együtt kell működnie a CTO-val és néha partnerszervezetekkel a szolgáltatások közötti integráció fejlesztése érdekében. Sok vállalatnál a CTO főépítészként is szolgál.

Szoftver építész

A szoftver-építész a főépítész számos célját szolgálja, de általában a kisebb funkcionalitások keresztmetszetekért felel. Az építészek gyakran együttműködnek a főépítészekkel, hogy megvalósítsák a nagyobb építészeti elképzelésüket. A szoftver-építészek gyakran a tech-stack-választást választják bizonyos alkalmazásokhoz vagy szolgáltatásokhoz, nem pedig a vállalati szintű döntéseket.

Mérnöki projektmenedzser / Mérnöki vezető / Projektmenedzser

Egy mérnöki projektmenedzser (más néven „Engineering Manager” vagy egyszerűen „Project Manager”) felelõs a mérnöki csapat munkafolyamatáért. Néhány nagyobb vállalatnak van mind műszaki vezetője, mind projektvezetője. Ebben az esetben a mérnöki vezető általában úgy viselkedik, mint a mérnöki helyettes a helyi csapat körében, míg a projektmenedzser vállalja az itt leírt felelősségeket.

A projektmenedzserek általában kapcsolódnak mind a termékvezetőkhöz, mind a mérnöki vezetőkhöz, például a mérnökök VP-jéhez, a CTO-hoz vagy egy középvezetőhöz a munkamaradások átalakításához és megrajzolásához, a munkajegyek előrehaladásának nyomon követéséhez, a részletes előrehaladási jelentésekhez (mérföldkő leégett táblázatok, kitöltött vs nyitott jegyek, havi / havi jelentések stb.) Gondolhat rájuk, mint a gyártó összeszerelési üzletvezetõjének analógjára. Figyelembe veszik a munkapadot, és ellenőrzik, hogy az összeszerelő sor zökkenőmentesen működik-e, és a munkatermék nem halmozódik fel a padlón egy szűk keresztmetszet előtt.

A legjobb projektmenedzserek is sok időt töltenek a problémák és hibák osztályozásával annak érdekében, hogy elemezze a mutatókat, például a hibasűrűség jellemzőpontonként, mi okozta a legtöbb hibát (tervezési hiba, specifikációs hiba, logikai hiba, szintaxis hiba, típushiba stb.) stb. Az ilyen típusú mutatók felhasználhatók a különféle kezdeményezések hatékonyságának mérésére, és rámutatnak arra, hogy miként lehetne javítani a mérnöki folyamatot.

A mérnöki vezetők hajlamosak megérteni a különféle csapattagok erősségeit, és jól tudják elosztani a munkabérleteket a megfelelő felelős feleknek, bár ennek együttműködési erőfeszítésnek kell lenniük, amely visszajelzést kér az egyes fejlesztőktől arról, hogy mi a karrier céljaik és amire összpontosítani akarnak a rendelkezésre álló projekt hatókörén belül.

Ha időbeli nyomás vagy munkahátralék halmozódik fel, a projektmenedzsernek együtt kell működnie a mérnöki és termékvezetőkkel a kiváltó oka kiderítése és a működési zavar mielőbbi kijavítása érdekében.

Ahol csak lehetséges, a projektmenedzsereknek kellene csak azoknak lennie, akik a feladatokat közvetlenül az egyes mérnökökre ruházják át a többszörös főnök problémájának elkerülése érdekében. A mérnököknek világosnak kell lenniük arról, hogy kinek közvetlenül számolnak, és ki felel a rájuk delegálásért. Ha Ön másfajta mérnöki vezető, és bűnös azért, hogy közvetlenül a mérnökökre ruházza át, akkor valószínűleg jó ötlet egyeztetni az általa delegált jelentés felelõs mérnöki vezetõjével, és átruházni azon keresztül, hogy a a munka helyes, összehangolt prioritást kap, és a mérnöki menedzser tisztában van azzal, hogy az egyes mérnökök miként aktívan dolgoznak egy adott pillanatban.

Nagyon kicsi szervezeteknél a mérnöki vezető gyakran a mérnöki műszaki vezető és a műszaki vezérigazgató is (a megfelelő címekkel vagy anélkül). Ha ez te vagy, ne aggódj az előző bekezdés miatt.

Általános diszfunkció az, hogy a mérnöki vezető elkezdi azt gondolni, hogy mivel a termék elveszti a szükséges munkát a mérnöki megvalósításhoz, és mivel a mérnöki vezetők szorosan együttműködnek a termékcsoportokkal, a mérnöki menedzser jelentést tesz a termékmenedzsernek. Minden esetben, amikor láttam, hogy ez megtörténik, hiba volt. Lásd alább a „Működési zavarok elkerülése” című részt.

Technikai vezető / csapatvezető

A Tech Lead vagy a Team Lead általában néhány fejlesztő vezetője. Általában idősebb mérnökök, akik mentorokként, példákként és útmutatókként viselkednek a csapat többi tagja számára. Általában a mérnökök jelentést tesznek a projektmenedzsernek vagy a műszaki vezetőnek, de egy technológiai vezető felelős lehet a csapat kódminőségi intézkedéseiért, például annak biztosításáért, hogy megfelelő kódértékeléseket végezzenek, és hogy a csapat műszaki szabványai (mint például a TDD) fogadható el.

Mérnök karrier előrehaladás

A mérnökök általában két karrierút egyikét választhatják: menedzsmentbe léphetnek, vagy kódolhatnak. A vezetői pozíciók nem mindenkinek szólnak. Sok mérnök inkább a műszaki úton marad. Ez a haladás több irányt, fordulatot és fordulatot vehet fel, de így néz ki:

Gyakornok -> Junior szoftverfejlesztő -> Szoftverfejlesztő / mérnök -> Senior szoftvermérnök -> Fő szoftvermérnök -> Szoftverarchitektúra -> Senior Szoftvertervező -> Főépítész -> CTO -> Mérnöki munkatárs

Alternatív megoldásként azoknak a mérnököknek, akiket az emberek vezetői szerepe érdekel, az előrehaladás így néz ki:

Gyakornok -> Junior szoftverfejlesztő -> Szoftverfejlesztő / Mérnök -> Csapatvezető / Technikai vezető -> Mérnöki vezető / Projektmenedzser -> Senior Engineering manager -> Mérnöki igazgató -> Mérnöki főnök

A műszaki vezetés működési zavarainak elkerülése

Az IMO-nak, a műszaki vezérigazgató-helyettesnek, a CTO-nak, a termék-elnöknek és a marketingért felelős VP-nek mind közvetlenül az ügyvezető igazgatónak kell beszámolniuk. Mindegyiküknek felelősnek kell lennie a saját folyamatáért. A külső felületű CTO-knak nem kell közvetlen jelentéssel rendelkezniük (ha igen, ez általában azt jelenti, hogy mind a CTO-t, mind a Mérnöki Szereplőket betöltik). Ehelyett a mérnöki vezetők jelentést tesznek a mérnöki alelnöknek. Ennek célja a két főnök diszfunkciójának elkerülése, hanem azért is, mert ezek a szerepek alapvetően különböznek: az egyik az ügyfelekre és a szervezetnek a szélesebb világba illesztésére összpontosít, a másik a belső, napi műveletekre összpontosít. Két vadul különféle képességkészlet, néha versengő prioritásokkal.

Nagyon sok működési zavart láttam a mérnöki vezetésben azért, mert zavart volt a kérdés, hogy a műszaki vezetők miért felelősek, és ez általában a katasztrófa receptje. Bármi is legyen a szervezetének megfelelő, ügyeljen arra, hogy a felelősség és a hatalmi lánc egyértelmű legyen, annak elkerülése érdekében, hogy a mérnökök két vagy három „főnök” között szakadást érzzenek.

Hasonlóképpen, egy elegendő méretű szervezetben a terméknek és a mérnököknek két külön vezetett csapatnak kell lenniük. Ez alatt azt értem, hogy a termékmenedzsernek kell a tulajdonosa a termék ütemtervének. A felhasználók evangélistainak kell lenniük, és valóban csatlakozniuk kell a felhasználókhoz, gyakran 1: 1 arányban vegyenek részt velük, és mélyen megismerjék munkafolyamataikat és fájdalompontjukat. Szakértőknek kell lenniük a piac igényeihez, és nagyon ismerniük kell a társaság erősségeit és képességeit ezen igények kielégítésére.

Ennek ellenére a mérnöki tisztviselőnek (vagy bárkinek, aki ezt a szerepet tölti be) a szállításért és a gyártási ütemért kell felelnie. Míg a termékmenedzsernek kell lennie az ütemtervnek, addig a műszaki vezetőknek felelősséget kell vállalniuk az ütemterv prioritásainak megteremtéséért, a műszaki kapacitásokhoz való hozzáigazításáért és az időzítés jelentéséért. A termék- és marketing csapatoknak erős véleményük lesz arról, mikor kell valamit szállítani, de csak a mérnöki vezetés mérlegelheti, hogy ezek a szállítási határidők lehetségesek-e vagy sem, tekintettel az ütemterv követelményeire. A mérnöki csapatnak nemcsak az időzítés visszaszorítására, hanem a legtöbb esetben az időzítés teljes megszervezésére, a vezérigazgató, a termék- és marketing csapatokkal való együttműködésre kell törekednie, hogy kitalálhassa a prioritásokat, megértse a vállalat stratégiai igényeit, majd segítsen alakítani egy olyan fejlesztési ütemterv, amely kielégíti ezeket az igényeket anélkül, hogy behúzza a határidőket, amelyek végül sértik a vállalat azon képességét, hogy megbízható ütemben szállítson minőségi termékeket.

A legjobban teljesítő csapatok, amelyekben valaha is részt vettem, feliratkoztak a határidők nélküli megközelítésre. Kiváló termékeket építünk anélkül, hogy előzetesen bejelentenénk őket, majd hagyjuk, hogy a marketing csapatok előmozdítsák a már elvégzett munkát. Alternatív megoldásként, ha nyilvános nézetben dolgozik, az átláthatóság kiváló megoldás. Tetszőleges határidő betartása helyett inkább ossza meg előrehaladását a jegyek leégési táblázataival, tiszta képet kapjon a fennmaradó munkáról, az előrehaladásról, a tempóról és a fennmaradó hatókörről, és változjon az idő múlásával, ami jelezheti a hatókör kúszását. Ha részletes információkat oszt meg az elért haladásról, és osztja azt a filozófiát, hogy nem ígérhetjük a kézbesítési dátumot, de megoszthatunk mindent, amit tudunk a fejlődésről, az emberek maguk is megnézhetik a munkát és a tempót.

Az eltérő, gyakran egymással versengő célok miatt a terméknek, a marketingnek és a mérnöki tevékenységnek külön szerepköröknek kell lennie, amelyeket közvetlenül az ügyvezető igazgatónak kell bejelenteni, ha egyikük sem tudja diktálni egymást. Ha a csapata időben nyomást gyakorol a túlórákra, vagy összecsap, hogy valamilyen kulcsot el lehet érni valamilyen lemondási határidő előtt, ez a működési zavarra utal. Vagy a mérnöki vezetők rossz embereknek számolnak be, vagy a csapatnak nincs erős mérnöki vezetője, aki megérti a szoftverbecslések hiábavalóságát, valamint azt, hogy a mérnöki és a termék közötti együttműködésre van szükség-hoz-vesz-e a szállítás rugalmasságának biztosítása érdekében. visszatérő MVP-k, hogy elérjék a szállítási célokat.

A terméknek a folyamatos felfedezési folyamat birtokában kell lennie. A folyamatos szállítási folyamatnak a mérnököknek kell lennie. A marketingnek együtt kell működnie a termékcsoporttal annak biztosítása érdekében, hogy a termék világszerte történő üzenetküldése pontosan megjelenjen. Az egésznek össze kell illeszkednie, mint egy csővezetékbe, simán áramló, pozitív visszacsatolási ciklust létrehozva. A futószalaghoz hasonlóan a folyamat leglassabb szűk keresztmetszetének is meg kell határoznia a folyamat többi részét, különben egyre növekvő elmaradáshoz vezet, amely annyira felhalmozódik, hogy a hátralévő elemek elavulttá válnak, és a hátralékkezelés teljesé válik. -idős munka.

Azoknak a termékcsoportoknak, akik úgy érzik, hogy a mérnöki munka nem lép lépést, először a mérnöki kézbesíthető anyagok minőségére kell összpontosítaniuk. Megfelelően megvizsgáltuk a terveket? Vált-e egy mérnök konstruktív visszajelzést a kézbesítés előtt? A szoftverhibák 80% -át specifikációs vagy UX-tervezési hibák okozzák, és ezek közül sokat meg lehet engedni, mielőtt a munkát valaha átadják egy mérnöki csapatnak. Miután ezt a folyamatot finoman befejezte, kérdezd meg magadtól, vajon valóban elegendően alaposan feltárták-e a termék dizájnterületét. Építettél egy UX-ot, és úgy hívtad, hogy kész, vagy kipróbáltál több variációt? A felhasználói munkafolyamatok variációinak felépítése és tesztelése az egyik legértékesebb hozzájárulás, amelyet a termékcsapat nyújthat. Van olyan megbízható felhasználók vagy ügyfelek csoportja, amelyekkel A / B prototípus teszteket futtathat?

A szoftvercsapatok egyik legnagyobb működési zavara az, hogy a termékcsoport al-par teljesítményeket állít elő (néha néhánynál több, rohanó, hibás makettként), és az ügyfelek vagy a mérnökök egyikét sem tudja futtatni, mielőtt azokat átadnák. . Ez a diszfunkció halom újból végzett munkát és mérnöki lemaradást okoz, amelyet gyakran a műszaki csapatoknak hibáztatnak.

Ügyeljen arra, hogy a felelősség-átruházás ésszerű legyen, hogy ne gyakoroljon indokolatlan időigényt a mérnöki munkára, és hogy van egy nagyszerű termékcsapat, amely részt vesz az együttműködésen alapuló termék-felfedezési folyamatban, és valódi felhasználókkal dolgozik a legjobb termék készítésében.

Mérnöki vezetők, nem engedtem el a horogból. Ha ezek a működési zavarok fennállnak a csapatodban, akkor a felelőssége, hogy kezelje őket termék-, marketing- és üzleti vezetéssel, valamint a mérnökökkel szemben támasztott követelményekkel. Az is a felelőssége, hogy megvédje csapata termelési ütemét, de további forrásokért küzdjön denevérre, ha a csapata nyomást gyakorol arra, hogy a jelenlegi kapacitásainál többet termeljen, egyértelműen számoljon be a munka üteméről és elmaradásáról, valamint a befejezett munka bemutatójára és gondoskodjon arról, hogy csapata esedékessé váljon az elvégzett finom munkáért.

Ne hibáztasson, hanem bizonyítsa, hogy csapata a lehető legjobban teljesíti a munkáját.

Eric Elliott elosztott rendszerszakértő és a „Szoftver készítése” és a „JavaScript alkalmazások programozása” könyvek szerzője. A DevAnywhere.io társalapítójaként megtanítja a fejlesztőknek a távoli munkához és a munka / magánélet egyensúlyához szükséges készségeket. Fejlesztőcsoportokat épít és tanácsad kriptoprojektekhez, és hozzájárult az Adobe Systems, a Zumba Fitness, a The Wall Street Journal, az ESPN, a BBC és a legjobban felvevő művészek, például Usher, Frank Ocean, Metallica és még sok más szoftveres tapasztalatainak fejlesztéséhez.

Élvez távoli életmódot a világ legszebb nőjével.