Omistettu projektipäälliköille (ja niille, jotka haaveilevat pomoista).
Tonneittain koodin kirjoittaminen on vaikeaa, mutta ihmisten hallinta on vielä vaikeampaa! Tarvitset siis tämän kirjan oppiaksesi tekemään molemmat.
Onko mahdollista yhdistää hauskoja tarinoita ja vakavia oppitunteja? Michael Lopp (tunnetaan ahtaissa piireissä myös nimellä Rands) onnistui. Löydät fiktiivisiä tarinoita kuvitteellisista ihmisistä, joilla on uskomattoman palkitsevia (vaikkakin fiktiivisiä) kokemuksia. Näin Rands jakaa monipuoliset, joskus omituiset kokemuksensa, joita on kertynyt vuosien aikana työskennellessä suurissa IT-yrityksissä: Apple, Pinterest, Palantir, Netscape, Symantec jne.
Oletko projektipäällikkö? Tai haluatko ymmärtää, mitä pomosi tekee koko päivän? Rands opettaa sinulle, kuinka selviytyä paisuneiden kalkkunoiden myrkyllisessä maailmassa ja menestyä huonosti loistokkaiden ihmisten yleisessä hulluudessa. Tässä oudossa hullujen mielisairaajien yhteisössä on vieläkin oudompia olentoja – johtajia, jotka mystisen organisatorisen rituaalin kautta ovat saaneet vallan monien ihmisten suunnitelmiin, ajatuksiin ja pankkitileihin.
Tämä kirja on erilainen kuin mikään johtamiskäsikirjoitus. Michael Lopp ei piilota mitään, hän vain kertoo asian niin kuin se on (ehkä kaikkia tarinoita ei kannata julkistaa: P). Mutta vain tällä tavalla ymmärrät kuinka selviytyä tällaisen pomon kanssa, kuinka hallita nörttiä ja nörttiä ja kuinka saada "se pirun projekti" onnelliseen loppuun!
Ote. Insinöörimentaliteetti
Ajatuksia aiheesta: Pitäisikö sinun jatkaa koodin kirjoittamista?
Randsin kirja johtajia koskevista säännöistä sisältää hyvin lyhyen luettelon modernin johtamisen "pakollisista asioista". Tämän listan lakonisuus johtuu siitä, että käsite "pakko" on eräänlainen absoluutti, ja mitä tulee ihmisiin, absoluuttisia käsitteitä on hyvin vähän. Onnistunut johtamismenetelmä yhdelle työntekijälle on todellinen katastrofi toiselle. Tämä ajatus on ensimmäinen kohta johtajan "must do" -luettelossa:
Pysy joustavana!
Ajatus, että tiedät jo kaiken, on erittäin huono idea. Tilanteessa, jossa ainoa pysyvä tosiasia on, että maailma muuttuu jatkuvasti, joustavuus on ainoa oikea asento.
Paradoksaalista kyllä, listan toinen kohta on yllättävän joustamaton. Tämä kohta on kuitenkin henkilökohtainen suosikkini, koska uskon, että se auttaa luomaan perustan johtamisen kasvulle. Tässä kappaleessa lukee:
Lopeta koodin kirjoittaminen!
Teoriassa, jos haluat johtajaksi, sinun on opittava luottamaan sinulle, jotka työskentelevät sinulle, ja luovutettava koodaus kokonaan heille. Tätä neuvoa on yleensä vaikea sulattaa, varsinkin uusille johtajille. Todennäköisesti yksi syy siihen, miksi heistä tuli johtajia, johtuu heidän tuottavuudestaan kehityksessä, ja kun asiat menevät pieleen, heidän ensimmäinen reaktionaan on palata taitoihin, joihin he luottavat täysin, eli kykyyn kirjoittaa koodia.
Kun näen, että uusi manageri "uppoaa" koodin kirjoittamiseen, sanon hänelle: "Tiedämme, että osaat kirjoittaa koodia. Kysymys kuuluu: osaatko johtaa? Et ole enää vastuussa itsestäsi, olet vastuussa koko tiimistä; ja haluan varmistaa, että saat tiimisi ratkaisemaan ongelmia itse ilman, että sinun tarvitsee kirjoittaa koodia itse. Sinun tehtäväsi on selvittää, kuinka skaalata itseäsi. En halua sinun olevan vain yksi, haluan, että sinunlaisiasi on monia."
Hyvä neuvo, eikö? Mittakaava. Hallinto. Vastuullisuus. Sellaisia yleisiä muotisanoja. Harmi, että neuvo on väärä.
Väärä?
Joo. Ohje on väärä! Ei täysin väärin, mutta niin väärin, että minun piti soittaa joillekin entisille kollegoille ja pyytää anteeksi: ”Muistatko lempilauseeni siitä, kuinka sinun pitäisi lopettaa koodin kirjoittaminen? Se on väärin! Kyllä... Aloita ohjelmointi uudelleen. Aloita Pythonilla ja Rubylla. Kyllä olen vakavissani! Urasi riippuu siitä!”
Kun aloitin urani ohjelmistokehittäjänä Borlandissa, työskentelin Paradox Windows -tiimissä, joka oli valtava tiimi. Pelkästään sovelluskehittäjiä oli 13. Jos lisäät ihmisiä muista tiimeistä, jotka myös työskentelivät jatkuvasti tämän projektin tärkeimpien teknologioiden, kuten ydintietokantamoottorin ja ydinsovelluspalvelujen parissa, saat 50 insinööriä suoraan mukaan tämän tuotteen kehittämiseen.
Mikään muu tiimi, jossa olen työskennellyt, ei ole edes lähellä tätä kokoa. Itse asiassa vuosi vuodelta ihmisten määrä tiimissä, jossa työskentelen, vähenee vähitellen. Mitä tapahtuu? Ollaanko me kehittäjät yhdessä älykkäämpiä ja älykkäämpiä? Ei, me vain jaamme taakan.
Mitä kehittäjät ovat tehneet viimeisen 20 vuoden aikana? Tänä aikana kirjoitimme paskan koodia. Koodin meri! Kirjoitimme niin paljon koodia, että päätimme, että olisi hyvä idea yksinkertaistaa kaikkea ja siirtyä avoimeen lähdekoodiin.
Onneksi Internetin ansiosta tästä prosessista on nyt tullut mahdollisimman yksinkertainen. Jos olet ohjelmistokehittäjä, voit tarkistaa sen heti! Hae nimeäsi Googlesta tai Githubista ja näet koodin, jonka olet jo pitkään unohtanut, mutta jonka kuka tahansa voi löytää. Pelottavaa, eikö? Etkö tiennyt, että koodi elää ikuisesti? Kyllä, hän elää ikuisesti.
Koodi elää ikuisesti. Ja hyvä koodi ei vain elä ikuisesti, se kasvaa, koska ne, jotka arvostavat sitä jatkuvasti, varmistavat, että se pysyy tuoreena. Tämä kasa laadukasta, hyvin hoidettua koodia auttaa pienentämään keskimääräistä suunnittelutiimin kokoa, koska sen avulla voimme keskittyä olemassa olevaan koodiin uuden koodin kirjoittamisen sijaan ja saada työt tehtyä pienemmällä määrällä ihmisiä ja lyhyemmässä ajassa.
Tämä päättely kuulostaa masentavalta, mutta ajatuksena on, että olemme kaikki vain joukko integraatioautomaatteja, jotka yhdistävät teippiä olemassa olevien asioiden eri osia yhteen luodakseen hieman erilaisen version samasta asiasta. Tämä on klassinen ajattelutapa ulkoistamista rakastavien johtajien keskuudessa. "Kaikki, jotka osaavat käyttää Googlea ja joilla on ilmastointiteippiä, voivat tehdä tämän! Miksi sitten maksamme paljon rahaa koneillemme?"
Maksamme näille johtajille todella paljon rahaa, mutta he ajattelevat sellaista hölynpölyä. Jälleen kerran, avainkohtani on, että planeetallamme on monia loistavia ja erittäin ahkeria kehittäjiä; he ovat todella loistavia ja ahkeria, vaikka he eivät ole viettäneet minuuttiakaan istuessaan akkreditoiduissa yliopistoissa. Ai niin, nyt niitä on enemmän ja enemmän!
En ehdota, että alkaisit murehtia paikkaasi vain siksi, että jotkut loistavat toverit väittävät sitä jahtaavan. Suosittelen, että alat huolehtia siitä, koska ohjelmistokehityksen kehitys etenee todennäköisesti nopeammin kuin sinä. Olet työskennellyt kymmenen vuotta, joista viisi johtajana, ja ajattelet: "Tiedän jo, miten ohjelmistoja kehitetään." Kyllä sinä tiedät. Hei hei…
Lopeta koodin kirjoittaminen, mutta...
Jos noudatat alkuperäistä neuvoani ja lopetat koodin kirjoittamisen, lopetat myös vapaaehtoisesti osallistumisen luomisprosessiin. Tästä syystä en käytä ulkoistamista aktiivisesti. Automaatit eivät luo, ne tuottavat. Hyvin suunnitellut prosessit säästävät paljon rahaa, mutta ne eivät tuo mitään uutta maailmaamme.
Jos sinulla on pieni tiimi, joka tekee paljon pienellä rahalla, niin ajatus koodin kirjoittamisen lopettamisesta tuntuu minusta huonolta urapäätökseltä. Jopa hirviöyrityksissä, joilla on loputtomia sääntöjä, prosesseja ja käytäntöjä, sinulla ei ole oikeutta unohtaa, kuinka kehittää ohjelmistoja itse. Ja ohjelmistokehitys muuttuu jatkuvasti. Se on muuttumassa juuri nyt. Jalkojen alla! Juuri tällä hetkellä!
Sinulla on vastalauseita. Ymmärtää. Kuunnellaan.
”Rands, olen matkalla ohjaajan tuoliin! Jos jatkan koodin kirjoittamista, kukaan ei usko, että voin kasvaa."
Haluan kysyä sinulta seuraavaa: oletko huomannut ohjelmistokehitysympäristön muuttuvan jopa yrityksen sisällä, kun istuit "Minusta tulee toimitusjohtaja!" -tuolissa? Jos vastauksesi on kyllä, esitän sinulle toisen kysymyksen: miten se tarkalleen ottaen muuttuu ja mitä aiot tehdä näille muutoksille? Jos vastasit "ei" ensimmäiseen kysymykseeni, sinun on siirryttävä toiseen tuoliin, koska (lyön vetoa!) ohjelmistokehityksen ala on muuttumassa juuri tällä hetkellä. Kuinka aiot koskaan kasvaa, jos unohdat hitaasti mutta varmasti ohjelmistokehityksen?
Neuvoni on, että älä sitoudu ottamaan käyttöön monia ominaisuuksia seuraavassa tuotteessasi. Sinun on jatkuvasti ryhdyttävä toimiin pysyäksesi ajan tasalla siitä, miten tiimisi rakentaa ohjelmistoja. Voit tehdä tämän sekä johtajana että varapuheenjohtajana. Jotain muuta?
"Voi, Rands! Mutta jonkun täytyy olla tuomari! Jonkun täytyy nähdä iso kuva. Jos kirjoitan koodia, menetän näkökulmani."
Sinun on silti oltava erotuomari, sinun on edelleen lähetettävä päätökset ja sinun on silti käveltävä rakennuksessa neljä kertaa joka maanantaiaamu yhden insinöörisi kanssa kuunnellaksesi hänen viikoittaista "We're all doomed" -juoksuaan 30 eurolla. pöytäkirja. ! Mutta kaiken tämän lisäksi sinun on säilytettävä insinööri-ajattelutapa, eikä sinun tarvitse olla kokopäiväinen ohjelmoija tehdäksesi sen.
Vinkkini tekniikan mentaliteetin ylläpitämiseen:
- Käytä kehitysympäristöä. Tämä tarkoittaa, että sinun tulee tuntea tiimisi työkalut, mukaan lukien koodinrakennusjärjestelmä, versionhallinta ja ohjelmointikieli. Tuloksena tulet hallitsemaan kielen, jota tiimisi käyttää puhuessaan tuotekehityksestä. Näin voit myös jatkaa suosikkitekstieditorin käyttöä, joka toimii täydellisesti.
- Sinun on kyettävä piirtämään tuotettasi kuvaava yksityiskohtainen arkkitehtoninen kaavio mille tahansa pinnalle milloin tahansa. En nyt tarkoita yksinkertaistettua versiota, jossa on kolme solua ja kaksi nuolta. Sinun on tiedettävä tuotteen yksityiskohtainen kaavio. Vaikein sellainen. Ei vain mikä tahansa söpö kaavio, vaan kaavio, jota on vaikea selittää. Sen tulee olla kartta, joka soveltuu tuotteen täydelliseen ymmärtämiseen. Se muuttuu jatkuvasti, ja sinun pitäisi aina tietää, miksi tietyt muutokset tapahtuivat.
- Ota yhden toiminnon toteuttaminen hoitaaksesi. Olen kirjaimellisesti vääntynyt kirjoittaessani tätä, koska tässä kohdassa on paljon piilotettuja vaaroja, mutta en todellakaan ole varma, voitko saavuttaa kohdat 1 ja 2 ilman, että sitoudut toteuttamaan vähintään yhtä ominaisuutta. Kun otat yhden ominaisuuksista itse käyttöön, et vain osallistu aktiivisesti kehitysprosessiin, vaan voit myös vaihtaa ajoittain roolista "Kaikesta vastuussa oleva johtaja" rooliin "Ihminen, joka vastaa yhden toteutuksesta. toiminnoista." Tämä nöyrä ja vaatimaton asenne muistuttaa sinua pienten päätösten tärkeydestä.
- Vavistan edelleen kaikkialta. Näyttää siltä, että joku huutaa minulle jo: "Johtaja, joka otti toiminnon toteuttamisen itselleen?! (Ja olen samaa mieltä hänen kanssaan!) Kyllä, olet edelleen johtaja, mikä tarkoittaa, että sen pitäisi olla pieni toiminto, okei? Kyllä, sinulla on vielä paljon tehtävää. Jos et vain pysty toteuttamaan toimintoa, minulla on sinulle ylimääräinen neuvo: korjaa joitain virheitä. Tässä tapauksessa et tunne luomisen iloa, mutta sinulla on käsitys tuotteen luomisesta, mikä tarkoittaa, että et koskaan jää ilman työtä.
- Kirjoita yksikkötestejä. Teen tämän edelleen tuotantosyklin myöhäisessä vaiheessa, kun ihmiset alkavat tulla hulluksi. Ajattele sitä tuotteesi terveystarkistuslistana. Tee tämä usein.
Taas vastalause?
"Rands, jos kirjoitan koodia, hämmennän tiimini. He eivät tiedä kuka olen – johtaja vai kehittäjä.”
Selvä.
Kyllä, sanoin: "Okei!" Olen iloinen, että uskot voivasi hämmentää joukkuettasi vain uimalla kehittäjälammessa. Se on yksinkertaista: ohjelmistokehityksen eri roolien väliset rajat ovat tällä hetkellä hyvin hämärät. UI-tyypit tekevät sitä, mitä voidaan yleisesti kutsua JavaScript- ja CSS-ohjelmoimiseksi. Kehittäjät oppivat yhä enemmän käyttökokemuksen suunnittelusta. Ihmiset kommunikoivat keskenään ja oppivat bugeista, muiden ihmisten koodin varkauksista ja myös siitä, ettei esimiehellä ole mitään hyvää syytä olla osallistumatta tähän massiiviseen, globaaliin, ristipölyttävään informaatiobakanaaliin.
Lisäksi haluatko olla osa tiimiä, joka koostuu helposti vaihdettavista komponenteista? Tämä ei vain tee tiimistäsi ketterämpää, vaan antaa jokaiselle tiimin jäsenelle mahdollisuuden nähdä tuotetta ja yritystä useista eri näkökulmista. Kuinka voit arvostaa Frankia, rakennusten rauhallista kaveria, sen enempää kuin nähtyään hänen rakennuskäsikirjoituksensa yksinkertaisen eleganssin?
En halua, että tiimistäsi tulee hämmentynyt ja kaoottinen. Päinvastoin, haluan tiimisi kommunikoivan tehokkaammin. Uskon, että jos olet mukana luomassa tuotetta ja työskentelet ominaisuuksien parissa, olet lähempänä tiimiäsi. Ja mikä tärkeintä, olet lähempänä jatkuvia muutoksia organisaatiosi ohjelmistokehitysprosessissa.
Älä lopeta kehitystä
Eräs kollegani Borlandista hyökkäsi kerran sanallisesti minua vastaan, koska kutsuin häntä "kooderiksi".
"Rands, kooderi on mieletön kone! Apina! Koodaaja ei tee mitään tärkeää paitsi kirjoittaa tylsiä rivejä turhaa koodia. En ole koodaaja, olen ohjelmistokehittäjä!"
Hän oli oikeassa, hän olisi vihannut alkuperäistä neuvoani uusille toimitusjohtajille: "Lopeta koodin kirjoittaminen!" Ei siksi, että ehdottaisin heidän olevan koodaajia, vaan ennemminkin siksi, että ehdotan ennakoivasti, että he alkavat jättää huomioimatta yhden työnsä tärkeimmistä osista: ohjelmistokehityksen.
Olen siis päivittänyt neuvoni. Jos haluat olla hyvä johtaja, voit lopettaa koodin kirjoittamisen, mutta...
Jousta. Muista, mitä tarkoittaa olla insinööri, äläkä lopeta ohjelmistojen kehittämistä.
Tietoja kirjoittajasta
Michael Lopp on kokenut ohjelmistokehittäjä, joka ei ole vieläkään lähtenyt Piilaaksosta. Viimeisten 20 vuoden aikana Michael on työskennellyt useissa innovatiivisissa yrityksissä, mukaan lukien Apple, Netscape, Symantec, Borland, Palantir, Pinterest, ja osallistunut myös startup-yritykseen, joka vajosi hitaasti unohduksiin.
Michael pitää työnsä ulkopuolella suosittua teknologiaa ja johtamista käsittelevää blogia salanimellä Rands, jossa hän keskustelee johtamisen alan ideoista lukijoiden kanssa, ilmaisee huolensa jatkuvasta tarpeesta pitää sormea pulssissa ja selittää, että huolimatta antelias palkkio tuotteen luomisesta, menestys on mahdollista vain tiimisi ansiosta. Blogi löytyy täältä .
Michael asuu perheensä kanssa Redwoodissa, Kaliforniassa. Hän löytää aina aikaa maastopyöräilyyn, jääkiekon pelaamiseen ja punaviinin juomiseen, sillä terveyttä on tärkeämpää kuin kiirettä.
» Lisätietoja kirjasta on osoitteessa
»
»
Khabrozhitelille 20% alennus kupongista - Ihmisten hallinta
Kun kirjan paperiversio on maksettu, kirjasta lähetetään sähköinen versio sähköpostitse.
PS: 7 % kirjan hinnasta menee uusien tietokonekirjojen käännöksiin, kirjapainoon luovutettuun kirjaluetteloon .
Lähde: will.com