Opgedragen aan projectmanagers (en degenen die ervan dromen baas te worden).
Het schrijven van tonnen code is moeilijk, maar het beheren van mensen is nog moeilijker! Je hebt dit boek dus gewoon nodig om te leren hoe je beide kunt doen.
Is het mogelijk om grappige verhalen en serieuze lessen te combineren? Michael Lopp (in kleine kringen ook bekend als Rands) slaagde erin. Je vindt fictieve verhalen over fictieve mensen met ongelooflijk lonende (zij het fictieve) ervaringen. Dit is hoe Rands zijn gevarieerde, soms vreemde ervaringen deelt die hij heeft opgedaan tijdens zijn jaren van werken bij grote IT-bedrijven: Apple, Pinterest, Palantir, Netscape, Symantec, enz.
Bent u een projectmanager? Of wil je begrijpen wat die verdomde baas de hele dag doet? Rands leert je hoe je kunt overleven in de giftige wereld van opgeblazen kalkoenen en hoe je kunt gedijen in de algemene waanzin van disfunctioneel flamboyante mensen. In deze vreemde gemeenschap van maniakale breinen leven zelfs nog vreemdere wezens: managers die door een mystiek organisatorisch ritueel macht hebben verworven over de plannen, gedachten en bankrekeningen van veel mensen.
Dit boek is anders dan welk management- of leiderschapsmanuscript dan ook. Michael Lopp verbergt niets, hij vertelt het gewoon zoals het is (misschien moeten niet alle verhalen openbaar worden gemaakt: P). Maar alleen op deze manier zul je begrijpen hoe je met zo’n baas kunt overleven, hoe je met nerds en nerds om moet gaan, en hoe je “dat verdomde project” tot een goed einde kunt brengen!
Uittreksel. Engineering mentaliteit
Gedachten over: moet u doorgaan met het schrijven van code?
Rands' boek over regels voor managers bevat een zeer korte lijst van moderne management-'must-dos'. Het laconisme van deze lijst komt voort uit het feit dat het concept ‘moeten’ een soort absoluut is, en als het om mensen gaat, zijn er maar heel weinig absolute concepten. Een succesvolle managementmethode voor de ene medewerker zal voor de andere een echte ramp zijn. Deze gedachte is het eerste item op de ‘must-do’-lijst van de manager:
Blijf flexibel!
Denken dat je alles al weet is een heel slecht idee. In een situatie waarin het enige constante feit is dat de wereld voortdurend verandert, wordt flexibiliteit de enige juiste positie.
Paradoxaal genoeg is het tweede item op de lijst verrassend inflexibel. Dit punt is echter mijn persoonlijke favoriet, omdat ik geloof dat het helpt de basis te leggen voor bestuurlijke groei. Deze paragraaf luidt:
Stop met het schrijven van code!
Als je manager wilt worden, moet je in theorie leren degenen die voor je werken te vertrouwen en de codering volledig aan hen over te dragen. Dit advies is meestal moeilijk te verteren, vooral voor nieuwe managers. Een van de redenen waarom ze managers zijn geworden, is waarschijnlijk vanwege hun productiviteit bij de ontwikkeling, en als er iets misgaat, is hun eerste reactie terugvallen op de vaardigheden waar ze het volste vertrouwen in hebben, namelijk hun vermogen om code te schrijven.
Als ik zie dat een nieuwe manager ‘verzinkt’ in het schrijven van code, zeg ik tegen hem: ‘We weten dat je code kunt schrijven. De vraag is: kun jij leiding geven? Je bent niet langer alleen verantwoordelijk voor jezelf, je bent verantwoordelijk voor het hele team; en ik wil ervoor zorgen dat u uw team zelf problemen kunt laten oplossen, zonder dat u zelf de code hoeft te schrijven. Jouw taak is om erachter te komen hoe je jezelf kunt opschalen. Ik wil niet dat je er maar één bent, ik wil dat er velen zijn zoals jij.”
Goed advies, toch? Schaal. Beheer. Verantwoordelijkheid. Zulke algemene modewoorden. Jammer dat het advies verkeerd is.
Niet correct?
Ja. Het advies klopt niet! Niet helemaal fout, maar wel fout genoeg dat ik een aantal oud-collega’s heb moeten bellen en mijn excuses moest aanbieden: “Herinner je je die favoriete uitspraak van mij over hoe je moet stoppen met het schrijven van code? Het is verkeerd! Ja... Begin opnieuw met programmeren. Begin met Python en Ruby. Ja, ik ben serieus! Je carrière hangt ervan af!”
Toen ik mijn carrière als softwareontwikkelaar bij Borland begon, werkte ik in het Paradox Windows-team, een enorm team. Er waren alleen al dertien applicatie-ontwikkelaars. Als je mensen van andere teams toevoegt die ook voortdurend aan de sleuteltechnologieën voor dit project werkten, zoals de kerndatabase-engine en de kernapplicatiediensten, kreeg je 13 ingenieurs die rechtstreeks betrokken waren bij de ontwikkeling van dit product.
Geen enkel ander team waarvoor ik ooit heb gewerkt, komt zelfs maar in de buurt van deze omvang. Sterker nog, elk jaar neemt het aantal mensen in het team waarin ik werk geleidelijk af. Wat gebeurd er? Worden wij ontwikkelaars samen steeds slimmer? Nee, we delen alleen de last.
Wat hebben ontwikkelaars de afgelopen twintig jaar gedaan? Gedurende deze tijd hebben we een enorme hoeveelheid code geschreven. Zee van code! We schreven zoveel code dat we besloten dat het een goed idee zou zijn om alles te vereenvoudigen en open source te worden.
Gelukkig is dit proces dankzij internet nu zo eenvoudig mogelijk geworden. Als u een softwareontwikkelaar bent, kunt u het nu meteen bekijken! Zoek je naam op Google of Github en je ziet code die je al lang vergeten bent, maar die iedereen kan vinden. Eng, toch? Wist je niet dat die code voor altijd leeft? Ja, hij leeft voor altijd.
De code leeft voor altijd. En goede code leeft niet alleen voor altijd, maar groeit omdat degenen die er waarde aan hechten er voortdurend voor zorgen dat deze actueel blijft. Deze stapel hoogwaardige, goed onderhouden code helpt de gemiddelde omvang van het technische team te verkleinen, omdat het ons in staat stelt ons te concentreren op bestaande code in plaats van nieuwe code te schrijven, en de klus te klaren met minder mensen en in een korter tijdsbestek.
Deze redenering klinkt deprimerend, maar het idee is dat we allemaal slechts een stel integratie-automaten zijn die ducttape gebruiken om verschillende stukjes bestaande dingen met elkaar te verbinden om een iets andere versie van hetzelfde te creëren. Dit is een klassieke gedachtegang onder senior executives die van outsourcing houden. “Iedereen die Google kan gebruiken en wat ducttape heeft, kan dit doen! Waarom betalen we dan veel geld aan onze machines?”
We betalen deze managementjongens heel veel geld, maar ze denken zulke onzin. Nogmaals, mijn belangrijkste punt is dat er veel briljante en zeer hardwerkende ontwikkelaars op onze planeet zijn; ze zijn werkelijk briljant en ijverig, ook al hebben ze nog geen minuut aan geaccrediteerde universiteiten gezeten. Oh ja, nu zijn het er steeds meer!
Ik stel niet voor dat je je zorgen gaat maken over je plek alleen maar omdat een paar briljante kameraden ernaar zouden jagen. Ik stel voor dat u zich er zorgen over gaat maken, omdat de evolutie van de softwareontwikkeling waarschijnlijk sneller gaat dan u. Je werkt al tien jaar, waarvan vijf jaar als manager, en je denkt: ‘Ik weet al hoe software wordt ontwikkeld.’ Ja, je weet het. Doei…
Stop met het schrijven van code, maar...
Als u mijn oorspronkelijke advies opvolgt en stopt met het schrijven van code, stopt u ook vrijwillig met deelname aan het creatieproces. Om deze reden maak ik niet actief gebruik van outsourcing. Automaten creëren niet, ze produceren. Goed ontworpen processen besparen veel geld, maar brengen niets nieuws in onze wereld.
Als je een klein team hebt dat veel doet voor weinig geld, dan lijkt het idee om te stoppen met het schrijven van code mij een slechte carrièrebeslissing. Zelfs in monsterbedrijven met hun eindeloze regelgeving, processen en beleid heb je niet het recht om te vergeten hoe je zelf software moet ontwikkelen. En softwareontwikkeling verandert voortdurend. Het is nu aan het veranderen. Onder je voeten! Op dit moment!
U heeft bezwaren. Begrijpen. Laten we luisteren.
'Rands, ik ben onderweg naar de regisseursstoel! Als ik code blijf schrijven, zal niemand geloven dat ik kan groeien.”
Ik wil u dit vragen: sinds u in uw “Ik sta op het punt CEO te worden!”-stoel zat, heeft u gemerkt dat het softwareontwikkelingslandschap verandert, zelfs binnen uw bedrijf? Als uw antwoord ja is, dan zal ik u nog een vraag stellen: hoe verandert het precies en wat gaat u aan deze veranderingen doen? Als u op mijn eerste vraag ‘nee’ hebt geantwoord, moet u naar een andere leerstoel verhuizen, omdat (ik wed dat!) het vakgebied van softwareontwikkeling op dit moment aan het veranderen is. Hoe ga je ooit groeien als je langzaam maar zeker vergeet hoe je software moet ontwikkelen?
Mijn advies is om jezelf niet te verplichten tot het implementeren van talloze functies voor je volgende product. U moet voortdurend stappen ondernemen om op de hoogte te blijven van de manier waarop uw team software bouwt. Dit kun je zowel als directeur als als vice-president doen. Iets anders?
‘Euh, Rands! Maar iemand moet de scheidsrechter zijn! Iemand moet het grote plaatje zien. Als ik code schrijf, verlies ik het perspectief."
Je moet nog steeds de scheidsrechter zijn, je moet nog steeds de beslissingen uitzenden, en je moet nog steeds elke maandagochtend vier keer rond het gebouw lopen met een van je ingenieurs om te luisteren naar zijn wekelijkse "We're all doomed" tirade gedurende 30 minuten. minuten. ! Maar daarnaast moet je een technische mentaliteit behouden, en daarvoor hoef je geen fulltime programmeur te zijn.
Mijn tips voor het behouden van een ingenieursmentaliteit:
- Gebruik de ontwikkelomgeving. Dit betekent dat u bekend moet zijn met de tools van uw team, inclusief het codebouwsysteem, versiebeheer en programmeertaal. Het resultaat is dat u de taal die uw team gebruikt wanneer ze over productontwikkeling praten, vloeiend leert spreken. Hierdoor kunt u ook uw favoriete teksteditor blijven gebruiken, die perfect functioneert.
- U moet op elk oppervlak en op elk moment een gedetailleerd bouwkundig diagram kunnen tekenen dat uw product beschrijft. Nu bedoel ik niet de vereenvoudigde versie met drie cellen en twee pijlen. U moet het gedetailleerde diagram van het product kennen. De moeilijkste. Niet zomaar een schattig diagram, maar een diagram dat moeilijk uit te leggen is. Het moet een kaart zijn die geschikt is voor een volledig begrip van het product. Het verandert voortdurend en je moet altijd weten waarom bepaalde veranderingen hebben plaatsgevonden.
- Neem de uitvoering van één van de functies over. Ik huiver letterlijk terwijl ik dit schrijf, omdat dit punt veel verborgen gevaren met zich meebrengt, maar ik ben er echt niet zeker van dat je punt #1 en punt #2 kunt bereiken zonder je te verplichten om ten minste één functie te implementeren. Door zelf een van de functionaliteiten te implementeren, wordt u niet alleen actief betrokken bij het ontwikkelingsproces, maar kunt u ook periodiek overschakelen van de rol van “Manager die de leiding heeft over alles” naar de rol van “Man die verantwoordelijk is voor de implementatie van één van de functies.” Deze nederige en bescheiden houding zal u herinneren aan het belang van kleine beslissingen.
- Ik tril nog steeds over mijn hele lichaam. Het lijkt erop dat iemand al tegen mij schreeuwt: “De manager die de uitvoering van de functie op zich heeft genomen?!” (En ik ben het met hem eens!) Ja, jij bent nog steeds de manager, wat betekent dat het een kleine functie moet zijn, oké? Ja, je hebt nog veel te doen. Als je de implementatie van de functie gewoon niet op je kunt nemen, dan heb ik nog wat advies voor je: repareer enkele bugs. In dit geval zult u de vreugde van het creëren niet voelen, maar zult u begrijpen hoe het product tot stand komt, wat betekent dat u nooit zonder werk zult zitten.
- Unittests schrijven. Ik doe dit nog steeds laat in de productiecyclus, wanneer mensen gek worden. Zie het als een gezondheidschecklist voor uw product. Doe dit vaak.
Opnieuw bezwaar?
'Rands, als ik code schrijf, zal ik mijn team in verwarring brengen. Ze zullen niet weten wie ik ben: een manager of een ontwikkelaar.’
Oke.
Ja, ik zei: "Oké!" Ik ben blij dat je denkt dat je je team in verwarring kunt brengen door alleen maar in de ontwikkelaarsvijver te zwemmen. Het is simpel: de grenzen tussen verschillende rollen in softwareontwikkeling zijn momenteel erg vaag. De UI-jongens doen wat grofweg JavaScript- en CSS-programmering kan worden genoemd. Ontwikkelaars leren steeds meer over het ontwerpen van gebruikerservaringen. Mensen communiceren met elkaar en leren over bugs, over diefstal van de code van anderen, en ook over het feit dat er geen goede reden is voor een manager om niet deel te nemen aan deze enorme, mondiale, kruisbestuivende informatiebacchanaal.
Wil jij bovendien deel uitmaken van een team dat bestaat uit eenvoudig vervangbare componenten? Dit maakt uw team niet alleen wendbaarder, het geeft elk teamlid ook de kans om het product en het bedrijf vanuit verschillende perspectieven te bekijken. Hoe kun je Frank, de rustige man die verantwoordelijk is voor de builds, meer respecteren dan nadat je de eenvoudige elegantie van zijn build-scripts hebt gezien?
Ik wil niet dat je team verward en chaotisch wordt. Integendeel, ik wil dat uw team effectiever communiceert. Ik geloof dat als je betrokken bent bij het maken van het product en het werken aan functies, je dichter bij je team komt te staan. En nog belangrijker: u bent dichter bij de constante veranderingen in het softwareontwikkelingsproces binnen uw organisatie.
Stop niet met ontwikkelen
Een collega van mij bij Borland heeft mij ooit verbaal aangevallen omdat ik haar een ‘codeerder’ noemde.
'Rands, de codeerder is een hersenloze machine! Aap! De codeur doet niets belangrijks, behalve het schrijven van saaie regels nutteloze code. Ik ben geen codeur, ik ben een softwareontwikkelaar!”
Ze had gelijk: ze zou mijn eerste advies aan nieuwe CEO’s gehaat hebben: “Stop met het schrijven van code!” Niet omdat ik suggereer dat ze programmeurs zijn, maar meer omdat ik proactief suggereer dat ze een van de belangrijkste onderdelen van hun werk gaan negeren: softwareontwikkeling.
Daarom heb ik mijn advies bijgewerkt. Als je een goede leider wilt zijn, kun je stoppen met het schrijven van code, maar...
Flexibel zijn. Onthoud wat het betekent om ingenieur te zijn en stop niet met het ontwikkelen van software.
Over de auteur
Michael Lopp is een ervaren softwareontwikkelaar die Silicon Valley nog steeds niet heeft verlaten. De afgelopen twintig jaar heeft Michael voor verschillende innovatieve bedrijven gewerkt, waaronder Apple, Netscape, Symantec, Borland, Palantir, Pinterest, en heeft hij ook deelgenomen aan een startup die langzaam in de vergetelheid raakte.
Buiten zijn werk beheert Michael onder het pseudoniem Rands een populaire blog over technologie en management, waar hij ideeën op het gebied van management met lezers bespreekt, zijn bezorgdheid uit over de voortdurende noodzaak om de vinger aan de pols te houden, en legt uit dat hij, ondanks de royale beloningen voor het maken van een product, uw succes is alleen mogelijk dankzij uw team. De blog vind je hier .
Michael woont met zijn gezin in Redwood, Californië. Hij vindt altijd tijd om te mountainbiken, hockey te spelen en rode wijn te drinken, want gezond zijn is belangrijker dan bezig zijn.
» Meer details over het boek zijn te vinden op
»
»
Voor Khabrozhiteley 20% korting met coupon - Mensen begeleiden
Bij betaling voor de papieren versie van het boek wordt een elektronische versie van het boek per e-mail verzonden.
PS: 7% van de prijs van het boek gaat naar de vertaling van nieuwe computerboeken, een lijst met boeken die aan de drukkerij worden overhandigd .
Bron: www.habr.com