Urani aikana olen osallistunut useisiin tosielämän ohjelmistoprojekteihin ja havainnut, miten asiat tehdään kaikilla tasoilla: päätöksenteko, käytäntöjen hyväksyminen, tiiminrakentaminen, rekrytointi, taitojen jakaminen jne. Ilmeisesti erilaiset lähestymistavat tuottivat erilaisia ​​tuloksia . Koska olen parantamiseen suuntautunut ihminen, huomasin ja keräsin tehokkaimmat käytännöt ja parhaat käytännön temput auttamaan minua työssäni.

Havainnoinnista oppiminen on vaikea ja pitkä tapa tehdä se. Olisin erittäin iloinen valitessani tämän tiedon aikaisemmin kirjoista. Valitettavasti en löytänyt aiheesta yhtään. Joten päätin jakaa kokemukseni muille tämäntyyppisen tiedon hakijoille. Toivottavasti se säästää heitä muutaman vuoden henkilökohtaisen tutkimuksen.

Tässä artikkelissa opit, miten voit voittaa alan keskimääräisen suorituskyvyn tuottamalla tukevaa ja luotettavaa ohjelmisto tuotteet, jotka vaativat 5-10 kertaa vähemmän huoltoa. Voin sanoa ilman väärää vaatimattomuutta, että viimeisten 10–15 vuoden aikana minä (henkilökohtaisesti samoin kuin joukkueeni) olen ylittänyt kaikki odotukset, jättäen jäljen menestykseen. Johtajat eivät voi olla onnellisempia.

Kerran tiimini vei tärkeän projektin mahdottomasti lyhyessä ajassa, josta ylempi johto antoi meille 'High Performance Team' -palkinnon. Kaikki tämä ilman yötä ja viikonloppua uupumasta itseämme. Vain normaalia työtä.

Tehokas ohjelmistotuotantotieto itsessään on voima. Itse asiassa se on eräänlaista mustaa taikuutta, jota monet ihmiset eivät voi ymmärtää, vaikka se selitetään yksinkertaisilla sanoilla. Saat sen ilmaiseksi. Lue, jos haluat, että sinut pidetään ohjelmistotuotannon taikurina.

Kenelle tämä on tarkoitettu?

Sallikaa minun tehdä tärkeä, tärkeä, tärkeä vastuuvapauslauseke.

Osoitan tämän niille, jotka tarvitsevat lisää tuottavuutta. Elämässä ei kaikessa ole kyse tuottavuudesta. Ei myöskään kaikki ohjelmistoprojektit. On tapauksia, joissa sinua ei arvioida suorituksesi perusteella. Nämä käytännöt eivät tietenkään auta silloin.

Nämä tekniikat ovat hyödyllisimpiä tiimien johtajille, arkkitehdeille ja projektipäälliköille, vaikka myös vanhemmat ohjelmistokehittäjät voivat hyötyä niistä.

Sääntö nro 1: Ymmärrä IT-mentaliteetti

IT-teollisuus on sekoitus tiedettä, tekniikkaa, taidetta ja liiketoimintaa. Siellä on melko vaikea navigoida ymmärtämättä näitä näkökohtia riittävän hyvällä tasolla. Suurin ongelma on, että teollisuus itsessään on melko monimutkainen; siksi myös parhaat käytännöt ovat monimutkaisia. Sinun on opittava paljon ja vahvistettava tietosi harjoittelemalla paljon menestyäksesi.

Uskomaton tekniikan päivitysnopeus tekee siitä kaksinkertaisen kovan. Mitään, mitä opit kymmenen vuotta sitten, ei enää tarvita. Joten sinun on opittava nopeutetulla vauhdilla.

Yhteenvetona kaikesta edellä mainitusta voidaan sanoa, että menestyminen IT-alalla ei perustu synnynnäisiin taitoihin tai tunteisiin, vaan koviin käytännön esimerkkeihin. Älä koskaan 'seuraa suolistoa' tai usko yksinomaan tunteen perusteella, mukaan lukien sinun.

Paras käytäntö uusien ideoiden omaksumisessa on varmistaa, että joku teki sen aiemmin ja se toimi.

Jos kyllä, idea on harkitsemisen arvoinen. Muussa tapauksessa vaadi erittäin hyvää ja yksityiskohtaista selitystä siitä, kuinka tämän polun valitseminen parantaa tiimisi elämää. Jos se läpäisee tämän testin, ajoita kevyt todiste konsepteista -projekti, joka kokeellisesti osoittaa, että se sopii ympäristösi.

Tärkeää tässä on ymmärtää, että ei ole oikeita ja vääriä ratkaisuja, koska ohjelmisto-ongelmat voidaan ratkaista monella tapaa. Ratkaisusta on kuitenkin hyviä ja huonoja käsityksiä.

Jos joku osaa selkeästi ilmaista idean yksityiskohtaisesti tai piirtää linkin tämän ratkaisun omaksumisesta tiimin menestykseen vakuuttamaan muut tiimin jäsenet, voimme luottaa tämän henkilön visioon ja toivoa suurista onnistumismahdollisuuksista.

Sääntö nro 2: Älä sekoita ohjelmistotuotantoa ja ohjelmistokehitysmenetelmiä

Ohjelmistotuotanto perustuu ohjelmistokehitykseen. Näillä kahdella on kuitenkin täysin erilaiset tavoitteet, ajattelutapa ja käytännöt. Yrittäminen ratkaista ongelma yhdestä näistä alueista toisen menetelmien avulla tuottaa naurettavia tuloksia. On tärkeää ymmärtää ero ja käyttää sopivia menetelmiä kullekin näistä maailmoista.

Ohjelmistokehitys on taiteen ja käsityön yhdistelmä. Taidekomponentti on aina olemassa automaatiotyökaluista ja ohjelmistokehitysmenetelmistä riippumatta. Siksi kehitystehtävien ratkaiseminen vaatii suurinta keskittymistä ja suojautumista muilta häiritseviltä signaaleilta.

Paras tapa motivoida kokenutta kehittäjää on esittää heille tehtävä puhtaassa teknisessä muodossaan ilman kaikkia inhimillisiä tekijöitä. Kaikki vaatimukset tulee ilmaista myös teknisellä kielellä. Niiden tulisi olla helposti todennettavissa, jotta he voisivat navigoida kohti tavoitetta soolotutkimusvaiheen aikana.

Ohjelmistojen tuotanto sitä vastoin on enemmän liikehallinto verkkotunnus. Tiedät mitä asiakkaasi tarvitsee toiselta puolelta ja tiedät mitä tiimin resursseja sinulla on käytettävissänne toiselta. Joten yrität nyt ohjata joukkueesi ponnisteluja tavoitteen saavuttamiseksi. Sillä välin voit myös arvioida etenemisnopeutesi ja esitellä pomoille hyvin perehtynyt suunnitelma. Tärkeitä taitoja ovat asiakkaan toiveiden ymmärtäminen, tiimisi vahvuuksien ymmärtäminen ja muodollisten suunnitelmien ja aikataulujen välittäminen.

Tästä huolimatta haluaisin korostaa, että monet ohjelmistokehityksen roolit toimivat molemmissa maailmoissa - rakentamassa siltaa liiketoiminnan ja teknologian välille - kuten tiiminvetäjät, arkkitehdit, analyytikot ja projektipäälliköt. Näissä rooleissa olevien ihmisten pitäisi pystyä kävelemään helposti kahden todellisuustason välillä ja ymmärtämään, milloin on aika puhua yritystoimintaa ja milloin on aika taiteelle.

Sääntö nro 3: Käytä pysyvää tallennustilaa jatkoa ihmisen muistille

Ihmisen muistilla, vaikka sen kapasiteetti on hämmästyttävä, on rajoituksensa. Muistat asiat arvaamattomalla tarkkuudella ja kestolla, ja kun unohdat, ei ole mitään keinoa muistaa sitä haluamallasi tavalla.

Siksi käytämme pysyvää muistitilaa liikkua eteenpäin ennustettavalla nopeudella. Kyse ei ole muodollisesta dokumentaatiosta, kuten käyttöoppaista, jotka luot kauan tosiasioiden jälkeen ja joita muut ihmiset voivat käyttää. Kyse on asiakirjojen käyttämisestä kirjaimellisesti muistisi ulkoisena laajennuksena työn aikana, joka auttaa sinua käymään läpi ohjelmistokehitysprosessin.

Suosittelen, että dokumentoit ajatuksesi ja suunnitelmat matkan varrella aina, kun kohtaat ei-triviaalisia tehtäviä tai tehtäviä, joihin osallistuu useampi kuin yksi henkilö. Yritä tehdä siitä mahdollisimman halpa. Älä luo virallisia asiakirjoja, joissa on yrityksen logo. Hyvä työkalu olisi yritys wiki projektitilan kanssa. Luo omistettuja sivuja tehtäviä tai ongelmia varten (30 sekuntia). Päivitä se sitten aina, kun sinulla on idea tai keskustelet siitä muiden kanssa.

Pidä tauko keskustelussa ja päivitä se heti, kun tämä ajatus on edelleen lentämässä päähäsi.

Sano kokouksessa 'pidä kiinni, anna minun laittaa tämä alas' ja viettää 10-30 sekuntia ilmaista se kirjallisesti. Kirjoituksen ei pitäisi olla laaja, mutta sen pitäisi olla täydellinen ja johdonmukainen, kuten siirrät ajatuksen kokonaisuudessaan paperille. Myöhemmin sinun tai kenenkään muun lukevan kohtaasi pitäisi ymmärtää se yhtä selkeästi kuin sinäkin nyt. Tämä temppu säästää paljon aikaa, mutta mahdollistaa dokumentoinnin lennossa.

Tällä tekniikalla on kaksi tarkoitusta.

Ensinnäkin se lukitsee edistymisen matkalla menestykseen painamalla sitä kovasti kiveen. Ei enää riskejä siitä, että joku unohtaa jotain, toistaa saman uudelleen ja uudelleen tai neuvottelee uudelleen saman, josta jo neuvoteltiin.

Toiseksi tyhjennät mielesi ja hävität ongelman, joka kiusasi sinua. Nyt mielesi on nälkäinen seuraavaan haasteeseen. Mikä tuottavuuden lisäys!

Tämä koskee mitä tahansa projektin tai tehtävän kokoa. Suuremmille sinulla on vain suuremmat välilyönnit sivuhierarkialla, joka kasvaa vähitellen projektisi kehittyessä. Tärkeä käsite on valmistella dokumentointitila ja -rakenne ennen kuin aloitat tehtävän, jotta voit luoda nopean muistin tyhjennysprotokollan!

Teknisiä analogioita suosiville ihmisille vertaisin mielemme prosessoriin, jolla on valtava prosessointiteho, mutta rajoitettu käyttömuisti. Pohjimmiltaan voit ajatella yhtä asiaa kerrallaan. Tässä analogiassa dokumentaatiosi toimii jatkuvana tallennustilana, kun taas mielesi ratkaisee monimutkaiset ongelmat iteratiivisella lähestymistavalla. Jossain vaiheessa päätät aloittaa seuraavan iteraation, lukea edelliset asiakirjat ja ladata nykyisen tilan operatiiviseen muistiin, miettiä sitä jonkin aikaa ja päivittää koodi ja dokumentaatio uusilla havainnoillasi. Vaiheittain, kunnes se on valmis.

Kaiken edellä mainitun perusteella en kannusta ihmisiä käsittelemään paljon tehtäviä kerralla. Päinvastoin, mitä vähemmän tehtäviä sinulla on, sitä parempi. Monet työtilanteet eivät kuitenkaan ole ihmisille todella optimoituja, ja moniajo voi olla tarpeen, ja sinun on käsiteltävä se jollakin tavalla. Yllä oleva temppu auttaa käsittelemään sitä paremmin.

Sääntö nro 4: Lopeta tuhlausaika muodollisessa aika-arviossa

Kaksi samanlaista hanketta ei ole. Seuraavan kerran, kun teet samanlaisen projektin, sinulla on erilaiset asiakkaat, erilaiset tavoitteet, erilainen tiimi; ehkä jopa erilaisia ​​tekniikoita. Jopa vakiotyökalujen ja komponenttien avulla sinun on silti mukautettava niiden kokoonpano ja arkkitehtuuri. Kun käsittelet ohjelmistoprojekteja, pidä mielessä, että niihin liittyy 50% - 100% mukautettua työtä. Ne edellyttävät tutkimusta, keskusteluja, ajattelua, kokeiluja ja muuta erittäin arvaamatonta toimintaa. Käytännössä saatat kokea valtavan eron siinä, mikä näyttää pinnalla olevan sama tarkka projektityyppi ja mitä olet aiemmin tehnyt. Uutta projektityyppiä on melkein mahdotonta arvioida tarkalleen.

Jos se on niin arvaamatonta, kuinka miten projektipäälliköiden on esitettävä projektiaikataulu ja pidettävä siitä kiinni?

Tätä varten on yksi muodollinen menetelmä, joka on kuvattu kirjallisuudessa; nimittäin jakaa koko projekti pienempiin vaiheisiin, arvioi kuinka kauan jokainen vaihe kestää, ja laske sitten projektin kokonaispituus yhdistämällä yksittäisten kappaleiden työpituus. Tämän menetelmän takana on tonnia teoriaa, jota opetetaan MBA-kursseilla.

Valitettavasti mikään matematiikka ei kuitenkaan voi tallentaa sitä. Tämä menetelmä on tunnetusti epätarkka siinä määrin kuin se on täysin käyttökelvoton ja epäkäytännöllinen, puhumattakaan siitä, kuinka uskomattoman aikaa vievää se on. En koskaan nähnyt projektipäällikköä, joka käyttäisi muodollisia laskentamenetelmiä ilman muutoksia, edes metodologisten fanaatikkojen joukossa. Ei edes silloin, kun yritys tiukasti määritteli tällaisen menetelmän käytön! Itse asiassa parhaiten menestyvät johtajat käyttävät täysin erilaisia ​​vaihtoehtoisia menetelmiä, kuten alla kuvataan:

Hyvä projektipäällikkö virittää suoliston tunteensa tutkimalla ja tarkkailemalla paljon aikaisempia projekteja.

Hyvä projektipäällikkö ottaa huomioon projektityypin, ympäristön, mukana olevat resurssit, organisaatiotyypin ja kaikki muut työn tosiasiat, jotka vaikuttavat projektin todelliseen pituuteen. Kukaan ei tietenkään tarvitse oppia yksinomaan omista virheistään. Tällaiset havainnot voidaan tehdä sekä suoraan että epäsuorasti; esimerkiksi kirjojen kautta tai tutkimalla muiden ihmisten tekemiä projekteja tai jopa yksinkertaisesti välittämällä osaavan henkilön henkilölle. Tällainen tilastollinen huipputason tieto parantaa henkilökohtaista projektiaikataulun navigointia.

Haluan tuoda esiin edellä kuvatun menetelmän kaksi tärkeää seurausta.

Ensinnäkin arvioinnin tarkkuus paranee kokemuksen myötä. Ei ole mahdollista, että kokematon henkilö, jolla on aseita millä tahansa vahvalla metodologialla, voi olla siinä hyvä. Toiseksi jopa paras arvio on edelleen hyvä vain tilastollisesti. Toisin sanoen voidaan sanoa, että tietty projekti voi kestää noin neljä ja kaksitoista kuukautta. Oletetaan, että tämä on oikein, on ymmärrettävä, että on 50% mahdollisuus, että projekti kestää yli kahdeksan kuukauden keskimääräisen ajan.

Tilastollisen ennusteen ymmärtämisellä on niin uskomaton vaikutus. Viisas johtaja laati vain 12 kuukauden arvion tällaiselle projektille ja sitten wow kaikki suorittamalla sen aikaisin. Toisin sanoen kukaan ei odota joukkueen noudattavan projektin aikataulua päivään.

Yleinen neuvo projektipäälliköille ja heidän päälliköilleen olisi lopettaa ajanhukkaaminen muodollisiin aikaennakomenetelmiin. Kannusta sen sijaan hankkeen kestoa koskevien tilastotietojen keräämiseen ja jaa nämä tiedot yrityksen kesken. Tunnen yrityksiä, joissa tällainen lähestymistapa toteutettiin koko yrityksen tasolla, mikä johti ihmeelliseen ennakoivaan tarkkuuteen.

Sääntö nro 5: Ymmärrä tehtävien vaihdon ja taisteluprioriteettien kustannukset

Ihmisen mieli on hämmästyttävän luonnosta. Vaikka se on uskomatonta, sillä on rajoituksensa. Toisin sanoen, se on suunniteltu menestymään tietyillä alueilla ja tietyntyyppisissä tehtävissä.

Kehittäjän mieli on ehdottomasti suuri voimavara ohjelmistokehityksessä. Olisitko projektipäällikkönä kiinnostunut ymmärtämään sitä paremmin ja asettamaan sen asentoon, jossa se toimii parhaiten?

Sanotaan yksinkertaisesti sanalla välttämällä liikaa teoriaa. Muista, että teoria vie sinut niin pitkälle, ennen kuin sinun on opittava joko omasta tai muusta kokemuksesta.

Ihmisen mielellä on vahva ongelmanratkaisu ja ideoiden tuottamispotentiaali. Valitettavasti tätä potentiaalia ei aina voida hyödyntää lähinnä siksi, että ideoiden luomisen tukemiseksi sinun on pidettävä kaikki ongelman osat yhdessä aktiivisessa muistissasi samanaikaisesti. Siksi monimutkaisten ongelmien ratkaiseminen käy läpi yksinkertaistamisvaiheen, kun tehtävä yleistetään tai muotoillaan uudelleen tärkeiden kappaleiden leikkaamiseksi ja muistissa pidettävien elementtien määrän vähentämiseksi samanaikaisesti. Toisin sanoen voimme joko ratkaista yhden hyvin kapean monimutkaisen ongelman tai useita yksinkertaisia ​​ongelmia.

Suhde ei kuitenkaan ole lineaarinen. Samanaikaisesti tekemiesi asioiden määrän lisääminen heikentää merkittävästi ongelmanratkaisukykyjäsi. Siksi ihmiskunta on aina työskennellyt ja käyttää roolien erottamista elämän optimointina. Kaksi henkilöä, jotka työskentelevät erikseen kahdessa tehtävässä, tekevät läpimurron nopeammin kuin jos molemmat työskentelevät molemmissa tehtävissä samanaikaisesti.

Toinen tärkeä mielen ominaisuus on sen kyvyttömyys vaihtaa tehtävien välillä heti kuten tietokoneet. Et todellakaan voi vain lopettaa ajattelemasta jotakin haluamallasi tavalla. Et myöskään voi heti alkaa ajatella uutta konseptia täydellä nopeudella. Tällaista henkistä inertiaa kuvaavat täydellisesti lennonjohto-operaattorit. Vaikka he katsovat tutkaa ja näkevät kokonaiskuvan, heidän on silti ladattava se muistiinsa, jotta ne voivat toimia nopeasti. Uuden operaattorin katselu ruudulle kestää kymmenen minuuttia, ennen kuin hän voi vaihtaa vanhan vaihdon yhteydessä.

Pahempaa on se, että emme voi unohtaa asioita haluamallamme tavalla. Kaikki oppimamme pysyy kanssamme ja häviää vähitellen ajan myötä, viemällä tilaa, jota voimme käyttää uuden tiedon saamiseen. Ja mikä vielä pahempaa, tähän vaikutukseen liittyy toisinaan 'keskeneräisen liiketoiminnan' tunne. On paljon helpompaa unohtaa jotain, joka on valmis ja jota et enää koskaan tarvitse. Kun laitat asiat sivuun viimeistelemään myöhemmin, aivosi tarttuvat luonnollisesti tietoihin, jotka on merkitty 'tulevaa käyttöä varten', eivätkä halua antaa uuden tiedon tulla paikoilleen.

Okei. Nyt kun olemme hahmottaneet ajatuksen tehtävien vaihtamisesta, katsotaanpa, miten se toimii todellisessa (niin sanotussa) ajatuskokeessa.

Kuvittele, että kymmenen säännöllistä kehittäjääsi työskentelevät kymmenen säännöllisen tehtävän parissa - yksi tehtävä per henkilö. Olettaen, että voimme sulkea ne täydelliseen häiriötöntä ympäristöön, kukin tehtävä voidaan ratkaista tietyssä ajassa yhdellä mielellä. Koko asia kestää niin kauan kuin kestää pisimmän yksittäisen tehtävän suorittaminen.

Toistetaan nyt sama henkinen kokeilu. Tällä kertaa vaihdamme tehtäviä jatkuvasti kehittäjien välillä ilman (tärkeää) syytä. Jokainen kehittäjä saa joka päivä uuden tehtävän. Vielä parempi, vaihdetaan se joka tunti. Kuinka pian he päättävät, luuletko? Ehkä ei koskaan.

Ensimmäisen skenaarion projektipäällikkö pystyi toteuttamaan projektin tehokkaasti. Toinen onnistui 'toteuttamaan' sen, se on varmaa ... siinä mielessä, että ne helpottivat sen kuolemaa. Onnittelut. Tämä projektien tappamisen tekniikka on erityisen tehokas, koska pelkän ajanhukan lisäksi se myös laskee työntekijöiden moraalin nollaan.

Kun ihmiset kokevat tällaisen 'tehtäväkarusellin', he menettävät kaiken tunnelman saavutuksestaan ​​ja ymmärtävät, että tämä projekti ei ole missään.

Suurin osa ihmisistä olisi samaa mieltä yllä olevan esimerkin kanssa, kun se esitetään heille puhtaasti akateemisella tavalla. Tosielämässä he kuitenkin unohtavat kaiken yhtäkkiä pienimmässäkin paineessa. Iso pomo vaatii edistymisraporttia tai asiakas kysyy tietystä ominaisuuden käyttöönottopäivämäärästä - melkein mikä tahansa ulkoinen tapahtuma voi saada projektipäällikön kiirehtimään joukkueen luo ja ilmaisemaan huolensa, minkä jälkeen tehtävän uudelleen määrääminen ja priorisoitu jongleeraaminen ovat mahdollisia. yrittää voittaa vähän aikaa täällä ja siellä, mikä lopulta johtaa vain projektin heittämiseen radalta vielä enemmän.

Tämä on tosielämän skenaario, jota esiintyy valitettavasti melko usein.

Hyvä johtaja nousee seisomaan ja suojaa tiimiä sellaisilta pieniltä häiriöiltä absorboimalla emotionaalisen sokin aallon ja muuttamalla sen tuottaviksi tulevaisuuden keskusteluaiheiksi. Se on ehdottomasti vaikeaa emotionaalisesti, mutta se on ainoa tapa pitää tiimi hyvässä rytmissä ja antaa heidän toimia.

Sääntö nro 6: Käytä arkkitehtuuriarvosteluja keinona parantaa järjestelmän suunnittelua

IT-teollisuus toimii käsitteillä yli - ja alla -tekniikka. Kun se tulee esiin haastattelussa, kaikki sanovat, että ylisuunnittelu on huono. Siihen on helppo vastata, koska kysymys itsessään välittää negatiivisen merkityksen sanalle 'yli', mikä tarkoittaa 'liikaa'. Todellinen käytännön tietämys olisi tunnistaa, kun arkkitehtuurisi muuttuu yli, ja välttää se varhaisessa vaiheessa.

Sallikaa minun antaa muutama kokeiltu ja totta osoittava asiani siitä.

Ensinnäkin ratkaisu voidaan laskea ylisuunnitelluksi, jos on olemassa jokin toinen yksinkertaisempi ratkaisu, joka tarjoaa kaikki tarvittavat toiminnot. Tämä tarkoittaa, että jos et tiedä yksinkertaisempaa ratkaisua, niin mikä tahansa yksinkertaisin ratkaisu, jonka voit tarjota, on paras silmäsi, ellei joku todista sinua väärässä.

Jos kuvitteellinen arkkitehtimme pyrkii aidosti ratkaisujen täydellisyyteen, tavanomainen arkkitehtuuriarviointi takaa sen olevan riittävän optimaalinen. Valitettavasti arkkitehtuurin tarkastelu vaatii ainakin muutaman muun pätevän arkkitehdin. Se on vaarana olla poissa käytöstä tai epäkäytännöllinen monissa tapauksissa. Vertaisarvioinnin puuttuessa arkkitehdit ovat alttiita yleisille virheille. Tarkastellaan ne yksitellen ja keskustellaan mahdollisista korjaustoimenpiteistä kullekin.

Yksi suosituimmista virheistä on suunnittelu ilman liiketoiminnan tavoitetta. Vaikuttaa ilmeiseltä, että kaiken työn tulisi olla sidottu loppukäyttäjän tyytyväisyyteen, yrityksen menestykseen tai vastaavaan liiketoiminnan tarpeeseen. Silti usein voit nähdä arkkitehtuurin, joka on suunniteltu kokonaan tai osittain ilman tätä tarkoitusta. Perustelut joko puuttuvat tai heijastuvat käyttämään mahdollisimman monta nykyaikaista kelloa ja pilliä.

Arkkitehti ei tässä tapauksessa tee sitä, mistä kuluttaja on maksanut. Sen sijaan he leikkivät hienoilla leluilla omaa hauskaa ja nautintoa varten. Tämä ei ole millään tavalla hyväksyttävää muodollisessa teollisuudessa. Ja silti näyttää siltä, ​​että sitä tapahtuu joka tapauksessa melko usein.

Joskus ongelma on arkkitehdin persoonallisuudessa ja heidän pakkomielteessään tiettyihin tekniikoihin tai työkaluihin. He vain haluavat käyttää niitä eivätkä pysty selittämään johdonmukaisesti mitä liiketoimintatarpeita he yrittävät ratkaista. Lähellä sitä on toinen tapaus, kun ihmiset eivät tiedä mitään sen lisäksi, että rakennetaan jotain pienistä paloista. Jokainen ulkoinen tapahtuma laukaisee varmasti halun sukeltaa muotoilumaailmaan eikä koskaan palata todellisen asiakkaan luo. Vaikka alkuperäinen laukaisu voi olla pätevä yritystoiminta, heidän pitkäaikainen irtautuminen todellisuudesta vähentää heidän taideteoksensa hyödyllisyyttä.

Parannus tähän on hyvin yksinkertainen, mutta vaatii itsekuria. Hyvä arkkitehti ei saa koskaan koskettaa kynää ja paperia, ennen kuin hän voi vastata itse ja selkeästi, miksi sitä tarvitaan. Tällainen tarve voi tulla eri muodoissa. Se voi olla muodollinen vaatimus, implisiittinen tarve tuotteiden parantamiseen tai uusien tekniikoiden syntyminen, jotka tekevät aikaisemmasta suunnittelusta vähemmän tehokkaan. Joka tapauksessa sen ei pitäisi olla muodollinen laukaisu, kunhan arkkitehdit itse ymmärtävät liikkeellepanevan voiman. Sitten he voivat käyttää tätä voimaa lopullisena todenteena suunnittelunsa laadusta.

Toinen vaikeasti havaittavissa oleva ongelma liittyy estoarkkitehtuuriin. Tällaisen mentaliteetin omaavat ihmiset uskovat, että kaikelle on olemassa ratkaisu, ja mainittu ratkaisu toteutetaan aina rakennuspalikkana. Toisin sanoen ne kääntävät toiminnallisuuden komponenteiksi suoraan arvioimatta arkkitehtuuria kokonaisuutena. He voivat vain liittää komponentin, joka toimittaa halutun toiminnallisuuden järjestelmään, kun tällaisen toiminnallisuuden tarve ilmaantuu. Suurimman osan ajasta tämä täyttää muodolliset vaatimukset, mutta jättää järjestelmän epäyhtenäiseen tilaan. Uutta lohkoa ei valittu järjestelmän nykyisen yhteensopivuuden pohjalta kehityksen, tuen tai edes yrityksen lisenssimallin perusteella. Joten joukkue yrittää muokata olemassa olevaa kokoonpanoa tai toteuttaa tämän toiminnon olemassa olevan järjestelmän kapasiteetin kautta. Tämän seurauksena järjestelmän tuki ja ylläpito muuttuvat vähitellen sekavaksi painajaiseksi, jota seuraa tarkasti suorituskyvyn heikkeneminen.

Tähän ongelmaan ei ole yksinkertaista ratkaisua, koska järjestelmän suunnittelu on taidetta eikä koskaan voida ennustaa, onko uusi komponentti lisättävä vai voidaanko sitä välttää. Paras käytäntö olisi luultavasti ylläpitää ylläpitoon ja arkkitehtuuriin liittyviä ongelmia, joita kertyy ajan myötä, minkä jälkeen seurataan säännöllisesti järjestelmän kokonaisarkkitehtuuria. Tämä säännöllinen tarkastelu voi myös ottaa huomioon syntyvät tekniikat. Joten arkkitehtuuriarviointien ei pitäisi olla ongelmien korjaaminen, vaan haluttujen parannusten ja koko järjestelmän mahdollisen elinkelpoisuuden arvioiminen vanhentuneisuuden uhkaavan väistämättömyyden vastaisesti.

Sääntö nro 7: Arvoa joukkueiden pelaajille

Useimmilta IT-alan ammattilaisilta kysyttiin haastattelussa, ovatko he hyviä tiimipelaajia vai toimivatko he hyvin ryhmässä. Luultavasti kukaan ei kuitenkaan koskaan nähnyt sille selkeää määritelmää kirjallisuudessa. Ilmeisesti tällainen henkilö edistäisi joukkueen menestystä yleensä, mutta harvat ihmiset pystyvät itse määrittelemään sellaiset henkilökohtaiset ominaisuudet, jotka takaavat tällaisen menestyksen.

Havaitsin monia eri tasoilla työskenteleviä ihmisiä ja näin, kuinka heidän henkilökohtaiset ominaisuutensa vaikuttivat projektin etenemiseen. Haluaisin esitellä seuraavat huomautukset henkilökohtaisista ominaisuuksista, joista on eniten hyötyä tiimityössä.

Viestintä

Ensimmäinen ja tärkein ominaisuus on tietysti kyky kommunikoida.

Kuvittele henkilö, jolla ei ole kommunikaatiokykyjä. Varmasti, ettei palautetta saada tiimin jäseniltä, ​​he ovat täysin hyödyttömiä. Tämä on niin ilmeistä, että kukaan ei todellakaan mittaa tätä taitoa haastattelun aikana, mikä tarkoittaa, että taito on riittävän hyvällä tasolla niin kauan kuin henkilö pystyy puhumaan hyvin.

Viestintä ei ole binäärinen kyllä ​​/ ei-taito; se on enemmän tiedonsiirtoikkuna. Mitä laajempi se on, sitä nopeampi ja selkeämpi tiedonvaihto.

Viestintätaito on kerroin kaikille muille taidoille, joita hänellä on.

Koska kyseisen ikkunan avoimuus vaihtelee suuresti väestön välillä, tällaisen ikkunan leveyden mitta on tärkeä joukkueen pelaajan ominaisuus. Muista, että puhumme tiedon välittämisestä tässä yhteydessä, mutta emme sujuvasta puhumisesta tai ihmisten rohkaisemisesta tai motivoimisesta tai organisoinnista puhumisen ja viestinnän kautta.

Viestintätyyli on myös merkityksetön. Tiedot voidaan toimittaa suullisesti, tekstin, kuvina tai sekoitetusti. Henkilö voi puhua nopeasti tai hitaasti. He voivat olla ystävällisiä, kuten katsella silmäsi ja hymyillä koko ajan, tai he voivat katsoa poispäin ja puhua yksitoikkoisella äänellä. Tyyli voi vaikuttaa henkilökohtaiseen käsitykseen työtoveristasi, mutta niin kauan kuin ymmärrät selvästi, mitä he tarkoittavat, kaikki tyylit ovat riittävät.

Siirrytään käytännön tapauksiin viestintäkyvyn havaitsemisessa ja mittaamisessa.

Viestintätaidoilla on yleensä kaksi pääkohtaa. Ensinnäkin on halu jakaa tietoa. Jotkut ihmiset ovat innokkaita jakamaan, mutta toiset yrittävät salata tietoja. Kaltevuus on enemmän tai vähemmän luonnollista, mutta sitä voidaan muuttaa hitaasti itse motivaatiolla ja harjoittelulla. On turvallista olettaa, että henkilö, jolla on tietyntyyppinen tiedon jakamista haluavansa, osoittaisi sen tulevaisuudessa. Siksi tämä ominaisuus on hyvä ennustamaan ehdokkaan tulevaa menestystä joukkueessa.

Tosielämässä ihmiset, jotka yrittävät salata tietoja, ovat helposti havaittavissa. He yleensä yrittävät luovuttaa tarkoituksellisesti hyödyttömiä tietoja kaiken oikean tarvitseman sijaan. Tai he kysyvät alustavia kysymyksiä kääntääkseen tietovirran sisäänpäin ja minimoidakseen vastauksensa 'tiedon tarve' -tapaukseen. Heidän taktiikastaan ​​riippumatta tunnet loppujen lopuksi, ettet saanut heiltä toivottuja tietoja tai että tietojen hankkiminen vaati liikaa ylimääräistä vaivaa.

On tärkeää ymmärtää aikomus, koska tietyntyyppiset avoimet henkilöt voivat esittää sinulle ennakkokysymyksiä ymmärtääksesi kysymyksesi paremmin ja antaa sitten vastauksen sinulle sopivimmalla tavalla. Henkilö, joka aikoo salata tiedot, kysyy lisäkysymyksiä vain ohjaamaan keskustelua pois eikä koskaan vastaa alkuperäiseen kysymykseesi.

Toinen osa viestintätaitoa on kyky virittää kuuntelija.

Eri ihmisillä on erilainen aiheiden ymmärtäminen, erilainen viestintätyyli ja ehkä jopa erilainen kiinnostus tiettyihin yksityiskohtiin. Jotkut kommunikoivat älykkäät ihmiset vaihtelevat keskustelunsa riippuen kuuntelijan kyvystä ymmärtää se ja valmistaa vastauksensa toimittamaan erityistä tietoa. Tällaisessa valmistelussa voidaan kysyä joitain alustavia kysymyksiä kuuntelijan mielenkiinnon kaventamiseksi alaspäin. Kyky 'selvittää' kommunikaatioeroja on todella hieno taito, koska sen avulla voimme saavuttaa ymmärrystä melkein kaikissa tapauksissa. Toisaalta joustavat keskustelijat voivat toisinaan vain jumittua väärinkäsitysten ratkaisemattomiin umpikujaan.

Vahvuuksien ja heikkouksien ymmärtäminen

Keskitymme toiseen joukkueen pelaajan kannalta välttämättömään henkilökohtaiseen laatuun.

Useimmat ihmiset olisivat yhtä mieltä siitä, että tiimiympäristön tulisi olla keskimääräistä ympäröivää maailmaa ystävällisempi yhteistyön edistämiseksi ja tuottavuuden lisäämiseksi. Siksi on tärkeää, että tiimi ymmärtää jokaisen jäsenen vahvat ja heikot alueet tehtävien jakamiseksi oikein ja peittää heikkoudet vahvuuksilla. Ensimmäinen askel tällä polulla on, että kaikki jäsenet mittaavat rehellisesti taitojaan toisiaan vastaan. Psykologisesti tämä voi olla vaikeaa, koska meillä on luonnollisesti taipumus salata heikkoja kohtia muilta suojelemalla itseämme.

Täällä ystävällinen ilmapiiri tulee auttamaan.

Luottamuksen rakentaminen on kahden miehen työ.

Joten uuden jäsenen odotetaan pelaavan joukkueen sääntöjen mukaisesti. Valitettavasti jotkut ihmiset eivät voi laskea vartijaansa edes ystävällisessä ympäristössä. He käyttäytyvät kuin yksinäiset sudet koko elämänsä ajan. Tämä on vahvempi kuin heillä. Valitettavasti tällainen asenne ei edistä tiimityötä.

Haastattelussa on helppo tekniikka tunnistaa tällaiset yksinäiset sudet. He eivät koskaan myönnä, etteivät tiedä jotain. Tietenkin ihmiset haluavat näyttää parhaansa, näyttää kaikki kykynsä ja yrittää ratkaista jokainen kova ongelma. Silti kaikilla on tietoraja. Rajamme muokkaavat taitojamme. Rajojen tunnustamatta jättäminen tarkoittaa sitä, että ehdokkaat esittävät olevansa kaikkien kauppojen jack, joka on yhtä hyvä kaikessa ja ei missään.

Kun palkkaat asiantuntijan, haluat todennäköisesti välttää tällaisia ​​ihmisiä. Sen lisäksi, että ylimielinen asenne liittyy usein toiseen punaisen lipun piirteeseen: haluttomuus pyytää apua. Kyky pyytää apua on ehdottoman välttämätöntä tiimityössä. Ilman sitä emme voi edetä ja kehittyä yhtä nopeasti. Tällainen itsepäinen ihminen polttaisi yrityksen resursseja ja aikaa, taistelemaan loputtomasti vaikeissa tehtävissä, mutta ei koskaan kutsunut joukkuetovereitaan avuksi. Tällaisten ehdokkaiden löytäminen haastattelussa on helppo temppu. Esitä heille kysymys, jolla ei ole järkeä, tai mainitse jotain hölynpölyä. Normaali, ihanteellisesti utelias henkilö sanoisi vain, että hän ei tiedä, ja kysyy, mikä se on. Puolustava henkilö ei koskaan tekisi niin, vaikka korostaisit, ettei ole olemassa oikeaa tai väärää vastausta ja että 'En tiedä' ei estä häntä.

Sääntö nro 8: Keskity ryhmätyön organisointiin

Tiimityön organisoinnista on yhtä vähän tietoa kuin mistä tahansa edellisestä aiheesta. Kaikki tietävät, että ryhmätyö on parempi, mutta miten rakentaa ja ylläpitää tiimi on edelleen mysteeri. Vaikka on mahdotonta käsitellä kaikkia tiiminrakennuksen näkökohtia, voimme ainakin tutkia muutamia keskeisiä tiiminrakennustekniikoita.

Rakennusosaaminen

Jokainen IT-projekti on ainutlaatuinen. Menestyäkseen siinä on opittava ja hallittava projektin yksityiskohdat. Ne voivat sisältää sekä teknistä että ei-teknistä tietoa. Esimerkki ei-teknisestä tiedosta voi olla henkilökohtainen verkosto johdolle, asiakkaille, teknisen tuen ryhmille jne. Erityinen tekninen tieto on lisätietoja yleisten IT-taitojen lisäksi.

Saatat esimerkiksi joutua tuntemaan Mavenin rakentamaan projektia. Tarkka rakennerakenne, ominaisuuksien sijainti ja suodatus vaihtelevat kuitenkin projektikohtaisesti. Kuten minkä tahansa tiedon kohdalla, tällaisten yksityiskohtien hallitseminen vie aikaa; mitä enemmän aikaa siihen investoidaan, sitä paremmin he voivat suorittaa. Aika on arvokkain resurssi, joka sinulla on. Haluat pitää tiimisi jäsenen keskittyen samaan toiminnalliseen alueeseen niin kauan kuin mahdollista hyödyntämään osaamistaan ​​ja kehittämään sitä entisestään, mikä parantaa jatkuvasti tiimin suorituskykyä.

Valitettavasti sitä ei ole mahdollista tehdä loputtomiin. Toisaalta ihmiset voivat vain kyllästyä. Toiselta puolelta olet vaarassa menettää heidän asiantuntemuksensa, mikä saattaa projektisi yllättäen vaarantaa.

Katsotaanpa, onko olemassa tapoja selviytyä haitoista estämättä tiimin suorituskykyä paljon.

Suurin osa älyllisistä työntekijöistä on luonnollisia oppijoita. He haluavat oppia tietyn alueen, kunnes he menestyvät siinä.

Jaa kohdealueet tiimin jäsenten kesken ja anna heidän kehittää osaamistaan ​​niissä. Jossain vaiheessa ne saavuttavat riittävän korkean tason, mikä on järkevää tämän projektin laajuudessa. Ylimääräinen oppimisvoima ei paranna sitä merkittävästi tässä vaiheessa. Ilman motivaatiota ja haastetta älykkäät ihmiset kyllästyvät ja alkavat vihata työtä.

Estää tämä avaamalla heille oppimismahdollisuuksia muualla. Pidä heidät ajan tasalla projekteista ja yrityksen teknologiasta ja avaa uusia haasteita. Jos heidän kiinnostuksensa kuuluu projektin soveltamisalaan, saat kaksinkertaisen palkkion, kun pidät joukkueesi haasteena ja laajennat hyödyllisiä joukkueen taitoja samalla. Jokainen itsensä kehittäminen on kuitenkin hyvä ikävystymisen välttämiseksi, vaikka se ei leikkaudu välittömiin projektitarpeisiin. Niin kauan kuin tiimin asiantuntija-aivot ovat mukana, he tukevat jo opittuja projekti-alueita mielensä takana.

Poistuessaan yrityksestä joukkueen asiantuntijat vievät suuren osan asiantuntemuksesta mukanaan. Yksi vastatoimista, joita voit käyttää, on levittää laajasti dokumentaatiota, jota voidaan päivittää lennossa. Ajattele aiemmin mainittua 'pysyvää muistitallennustilaa'.

Silti projektipäällikkö haluaisi kopioida tietoa tiimin jäsenten päähän, jos mahdollista. Jos jokaisesta asiantuntijasta olisi kaksi, se olisi yksinkertainen ratkaisu, vaikkakin kaksi kertaa kalliimpaa. Mutta on olemassa kevyempi tapa tehdä se. Temppu on antaa useimmille kehittäjillesi kehittää asiantuntemusta useilla aloilla, jotta jokainen projektin osa on vähintään yhden syvän asiantuntijan kattama. Samalla hän valitsi muutaman vanhemman jäsenen kasvattamaan laajuuttaan ja syventämään asiantuntemustaan. Yleensä tämä rooli on parhaiten joukkueen kehityksen johtaja tai arkkitehti. Tiimin johtaja on vuorovaikutuksessa kaikkien tiimin jäsenten kanssa ja osallistuu kaikkiin tehtävien toteuttamiseen. He voivat hyödyntää projektin jokaista osa-aluetta ymmärtämällä kaikki sen sisäosat. Tällä tavalla, vaikka menetät yhden asiantuntijoista, johtaja voi ottaa haltuunsa ja jatkaa projektin etenemistä, kunnes voit palkata ja kouluttaa korvaavan henkilön.

Saman idean toinen maku on kouluttaa kehittäjiä viereisillä alueilla antamalla heidän tarkkailla, oppia ja toisinaan kokeilla ikäisensä työtä. Muista, että tämän ristikoulutuksen ei tarvitse olla laajaa, joten se ei häiritse keskittymistä kehittäjien ensisijaisiin tehtäviin eikä haittaa tuottavuutta. Asiantuntemuksen kehittäminen johtamis- ja ristikoulutuskehittäjien keskuudessa rakentaa sinulle suojan tyynyn odottamattomia elämäsyyntejä vastaan ​​ja antaa sinulle aikaa liikkua projektiresursseilla.

Häiriöiden minimointi

Ohjelmistokehitys on monimutkaisen ja luovan ongelmanratkaisun ketju. Vaikka teollisuuden kehityksen myötä nämä monimutkaiset ongelmat automatisoituvat yhä enemmän, työstä ei tule helpompaa. Siihen liittyy edelleen suuri määrä taidetta ja henkilökohtaista näkemystä, jota on vaikea ennustaa ja joskus jopa vaikeampaa ryöstää.

Kehittäjät ovat aseen reuna. Niiden pitoisuus vastaa aseen kärjen kovuutta. Lisää heidän keskittymistään ja leikkaat läpi ongelmia, kuten kuuma veitsi voin läpi. Häiritse heitä ja päädyt kömpelösti voin tylpällä kepillä.

Tätä ei voida korostaa liikaa: Ei-ongelmanratkaisutyötä voidaan tehostaa motivaatiolla tai ylimääräisellä ponnistelulla. Tarvitset ongelmanratkaisutyöhön mahdollisimman irtaantumisen arkipäiväisestä maailmasta. Kaikkien jokapäiväisten ongelmien on vaikea jättää taakseen, ja hyvän projektipäällikön tulisi rakentaa hiljainen kehitysympäristö sekä fyysisessä että henkisessä mielessä. Kehittäjän työpaikan tulee olla samanlainen kuin aistinvarainen puutesäiliö.

Fyysisesti tämä toteutetaan suljettuna työtilana. Jokaisella tiimin jäsenellä tulisi olla kuutio ainakin siellä, missä he voivat sukeltaa yksinäisyyteen. On suositeltavaa välttää kovaa ääntä ja käytävän keskusteluja. Nopea ihmissuhde tulisi ylläpitää sähköpostitse ja chatilla. Suurten ryhmien tulisi käyttää kokouksissaan suljettuja huoneita, jotta he eivät häiritse muita. Tämä on melko vakiokuva toimistoelämästä, kuten ennen.

Valitettavasti avoimen avaruuden paradigma otetaan käyttöön yhä laajemmin myös suurissa toimistoissa. Varoitan hänen villityksestään. Vielä pahempaa on, että yhdessä avoimien tilojen kanssa ylimmän johdon kannustimet paikallisiin tiimikeskusteluihin. Tämä tarkoittaa pohjimmiltaan huutamista toisen rivin henkilölle osallistumattoman tiimin jäsenen pään yli. Kehittäjällä, joka keskeytetään kovalla keskustelulla kaksikymmentä kertaa päivässä, ei ole enää pirstale keskittymistä. Varmasti suuri suorituskyvyn tappaja.

Oppimiskäyrän salliminen

Itse tieto on valtaa. Tämä pätee erityisesti niin monimutkaiseen teollisuuteen kuin IT. Jokaisella tehtävällä on säännöllinen sykli: oppia, tutkia, toteuttaa. Erityisesti oppimisvaihe on korvaamaton. Sen lisäksi, että parempi ymmärrys mahdollistaa paremman ja nopeamman toteutuksen, on olemassa tietyt tietorajat, jotka on ylitettävä, jotta saavutettaisiin jotain. Tietysti myöskään ei ole mitään järkeä ylioppimiselle. Jokaisen taiton tulee vastata tuotantotarvetta eikä olla paljon sen yläpuolella.

Kehittäjiä painostetaan kuitenkin usein vastakkaiseen suuntaan; lopettaa oppiminen ja tehdä muuta kuin tuottaa. Oppiminen koetaan tuhlaavaksi ponnisteluksi, koska se ei liiku tehtävän etenemispalkkia. Tämä näyttää olevan todella helppo ratkaista ongelma, istua kotona ja lukea tämä artikkeli. Silti tosielämässä pienintäkään työpainetta tekee jokaisesta esimiehestä että vaativa idiootti, joka vaatii kaikkia 'lopettamaan oppimisen ja aloittamaan tekemässä jotain jo. ' Vannon, että olen kuullut nuo tarkat sanat niin monta kertaa koko työurani ajan ... Hyvän johtajan ja tiiminvetäjän tulisi ymmärtää, että oppiminen on tärkeä osa prosessia, vaikka se ei suoraan edistäisikään edistymispalkkia.

Kilpailukykyisen työpajan rakentaminen

Edellä esitetyt vinkit ovat osa tehokkaan ohjelmistotuotannon osaamista. Ymmärtämällä ja soveltamalla niitä tosielämässä parannat tuotannon tehokkuutta vähitellen. Jos luulet, että he ovat suurelta osin yhteydessä toisiinsa ja että heiltä puuttuu teoreettinen perusta, olet aivan oikeassa.

Haluan korostaa, että kilpailukykyisen kehitystyöpajan rakentaminen ei ole yhden tieteenalan tehtävä. Se vaatii tietoa ja asiantuntemusta useilla vierekkäisillä alueilla. Tällaisen asiantuntemuksen rakentaminen on kovaa työtä. Ei ole yhtä teoreettista perustaa tai ideaa, joka ratkaisisi kaikki ongelmasi kerralla. Uskominen tällaiseen hopeamalliin vain häiritsee sinua todellisesta tavoitteesta.

Kokeile näitä vinkkejä työssä nähdäksesi, kannattaako ne ottaa käyttöön pysyvästi. Jos pidät niistä hyödyllisinä (tai ei), jätä kommentti alla ja jaa kokemuksesi!