Kysymys:
Kuinka käsitellä kehittäjää, joka puolustautuu joutuessaan koodin rikkomiseen?
HelterSkelter
2018-05-02 15:54:54 UTC
view on stackexchange narkive permalink

Aloitin työskennellä yrityksessä nuorempana kehittäjänä, kun olen suorittanut suuren ohjelmoinnin käynnistysleirin, jolla on syvällinen ja laaja ohjelmointitaito. Siitä lähtien (1,5 vuotta) opin paljon, sain uskottavuuden hyvänä ohjelmistokehittäjänä ja sain useita hankkeita vastuullani. Suuri osa edistymisestäni tapahtui kollegani vanhemmilta kehittäjiltä tänä aikana saamani avun ansiosta.

Aika ajoin vanhukset tekevät virheitä, ja joskus nämä virheet rikkovat alla olevat moduulit. minun vastuullani. Kun näin tapahtuu, menen yleensä puhumaan heidän kanssaan ja sanon jotain:

"Hei, teit muutoksen X funktioksi Y. Tämä muutos rikkoo koodini, koska se ei ota Z: tä huomioon, ja Z on se, mitä tapahtuu puolellani. Onko sinun kunnossa tehdä K korjataaksesi sen? "

Yksi heistä, kun häntä lähestytään virheen takia, puolustautuu ja sanoo esimerkiksi" Joten eikö minun sallita koodata? " tai "No, vain vaihda koodisi, jotta se noudattaa minun" (sen sijaan, että ajattelisit muita, parempia vaihtoehtoja).

Kuinka minun pitäisi ilmoittaa hänelle, että tulen hyvillä aikomuksilla, mutta saa hänet myös ymmärtämään (ja hyväksymään), että hänen on tehtävä tarvittavat muutokset viallisen koodin / moduulin korjaamiseksi?

Kommentteja ei käytetä laajempaan keskusteluun;tämä keskustelu on siirretty chatiin] (https://chat.stackexchange.com/rooms/77024/discussion-on-question-by-heyjude-how-to-handle-a-developer-getting-defensive-wh).
Kymmenen vastused:
#1
+288
simbabque
2018-05-02 17:12:00 UTC
view on stackexchange narkive permalink

"Hei, teit tämän X-muutoksen siihen Y-funktioon. Tämä muutos rikkoo koodini, koska se ei ota Z: tä huomioon, ja Z tapahtuu puolellani. Onko sinun kanssasi tehdä K korjaa se? "

Sinun on tehtävä tästä vähemmän henkilökohtainen. Ei ole oma koodini ja sinun koodi . Molemmat olette yrityksen työntekijöitä, ja kyseinen yritys omistaa koodin. Kirjoitit vain sen, mutta luovutit immateriaalioikeudet työnantajallesi. Omistusoikeuden saaminen on tärkeää, mutta älä puhu siitä näin.

Ajattele sen sijaan, että kaikki koodit ovat koodimme , ja ilmaise ne näin. Tai jätä se pois. Kun et keskity siihen, mitä he tekivät, vaan nykyiseen tilaan, se tuntuu vähemmän henkilökohtaiselta hyökkäykseltä.

Muutoksen X seurauksena Y muut tämä toiminto hajosi. . Katsoin sitä ja huomasin, että meidän on myös ajateltava Z: tä.

Voit sitten nähdä, mitä he sanovat. He saattavat vastata esimerkiksi "näytä minulle" tai "mene eteenpäin ja korjaa se" tai "oi, en ajatellut sitä" ja tarjoavat korjata sen itse.

Ihannetapauksessa se ei todellakaan ole riippumatta siitä, kuka korjaa ongelman. On tärkeää, että käydään vuoropuhelua, ja kaikki tekevät yhteistyötä saadakseen tuotteesta vakaan ja toimivan. Vain yksi henkilö, joka on vastuussa tietystä tuotteen kappaleesta, on sinänsä vaarallista, ja tällainen tilanne on yhtä hyvä mahdollisuus varmistaa, että kaikki tietävät tuotteen muut osat.


Teknisemmästä näkökulmasta kuulostaa siltä, ​​että haluat todella yksikötestit tai muunlaisen automaattisen testauksen ainakin kyseiselle kappaleelle ohjelmistoja. Jos on olemassa yleinen infrastruktuuri, joka käyttää niitä ja näyttää tulokset, on selvää, jos joku (ei joku (!), Vaikka tietysti git blame on tietysti) rikkonut testejä. Ne ovat siellä turvaverkkona ja kaikkien nähtäväksi, jos asiat menevät pieleen.

Lisäetuna järjestelmän kriittisten kappaleiden testeistä on, että sinun ei tarvitse mennä huomauttamaan, että asiat ovat rikki. Ei enää ole koodipoliisia henkilöä. Jos työkaluketju huolehtii siitä, kukaan ei välitä huonoja uutisia ja joukkueessa on vähemmän huonoja tunnelmia, koska riitaa on vähemmän.

Toisaalta siihen liittyy tarve päivitä testit. Keskustelu sen eduista ja haitoista ei kuulu tähän.

Paikalla!Ohjelmoija ottaa kriitikon yleensä hyvin henkilökohtaiseksi.Se piilee luonteessamme :) Puhu vain ongelmasta eikä siitä, että joku on syyllinen siihen, että jokin ei enää toimi.(Paitsi että se oli todella tyhmä)
Hän ei koskaan sanonut, että heillä ei ole automaattisia testejä.Testit eivät koskaan kata kaikkea, joten ne eivät käsittele vastustusta, jota saatetaan saada koodin rikkoneelta henkilöltä.Parempi ehdotus olisi ** lisätä ** testi, joka osoittaa, että muutos on rikkonut jotain, ja käyttää sitä vipuna saadaksesi heidät korjaamaan virheensä.
@Michael Olen samaa mieltä.Ja olet oikeassa, he eivät koskaan sanoneet, ettei testejä ole.Sitä en ehdota heidän tekevän joitain.Sanon yksinkertaisesti, että testit ovat vähemmän vastakkainasetteleva lähestymistapa, koska ne poistavat tarpeen osoittaa, että jokin on rikki, jos niitä ylläpidetään oikein.Testin lisääminen jälkikäteen ei kuitenkaan ole mielestäni todella hyödyllistä.Vastaukseni tarkoituksena ei ole saada joku korjaamaan virheensä, vaan auttamaan koko tiimiä toimimaan paremmin yhdessä.Hyvin rakennettu testipaketti todennäköisesti saa kiinni tietyistä asioista, vaikka se johtuisi vain siitä, että sitä ei ole päivitetty.
"Sillä ei kuitenkaan ole väliä kuka korjaa sen."En ole oikeastaan samaa mieltä, jos sinulla on aikataulu ja sinulla ei ole aikaa korjata muiden virheitä, sinulla on oikeus pyytää heitä korjaamaan se.
@Ckankonmange Luulen, että se riippuu tiimin rakenteesta, tuotteesta, yrityksestä ja siitä, mitä johto haluaa.On todella vaikea löytää yleistä vastausta.Olen muokannut sitä osaa, koska se oli hieman liian idealistinen.Kiitos, että osoitit sen.
@simbabque "testin lisääminen jälkikäteen ei ole mielestäni todella hyödyllistä" Milloin lisäät testin?Kirjoitatko kaikki testisi projektin alussa, etkä koskaan lisää enempää?
@Michael ei, ei tietenkään.Mutta jos muutos rikkoo jotain, jolle minulla ei ole testiä, korjasin käyttäytymisen ja lisätään sitten regressiotesti varmistaakseni, että sitä ei enää koskaan tapahdu.En jättäisi ohjelmistoa rikki ja lisäisin testin todistaakseni, että se on rikki antamaan sen jollekin muulle korjattavaksi.Ellei tietenkään, jos olisin joukkueen johtaja ja antaisin tehtävän korjata sen juniorille, jolla ei ole vielä taitoja testin asettamiseen.
@simbabque OP: n ongelma on, että hän haluaa toisen kaverin korjaavan sen.Ratkaisusi siihen ei voi olla "korjaan itse".
Tämä on erittäin jumalan neuvoja!Vain pari viikkoa sitten löysin virheen ja löysin versionhallinnan avulla kehittäjän, joka esitteli muutoksia, jotka eivät hieroneet tietoja oikein.Kerroin heille ja tiimilleni siitä, mutta vältin tarkoituksella sanomasta, että se oli kehittäjän vika kenellekään.Kun etsimme ongelman lähdettä, kävi ilmi, että se oli itse asiassa _my_ vika - en ollut määrittänyt kehitysympäristöäni oikein!Mutta koska en ollut osoittanut sormia, kukaan ei menettänyt kasvojaan.
+1 - Et myöskään halua luoda ympäristöä, jossa kehittäjät ovat liian huolissaan siitä, että heitä rangaistaan jaetun moduulin rikkomisesta, jotta he luovat toisen itse.Sitten kaikki menettävät.
Olen kerran ratkaissut samanlaisen ongelman kehittäjän kanssa, joka sanoi "en vaihda koodiani".hänen mantrana.Tein tämän: "Hei, luulen, että kirjoittamallesi koodille välitetään virheellisiä parametreja. Voisitko laittaa sinne virheenkorjauslausekkeita, jotta voimme saada syyllisen kiinni?"OIKEAT TIEDOT Oikeiden tietojen välittäminen.Se ei tuonut valoa eikä lämpöä.Ja kuten arvata voi, herra "En vaihda koodia" omistaa ongelman.
On tärkeää olla syyttämättä kehittäjää, koska et todellakaan tiedä onko se heidän syynsä.Todennäköisesti heidän tekemänsä virhe johtui jonkun toisen heille asettamista huonoista vaatimuksista.Ohjelmistojen eloon tuominen vie paljon erilaisia ihmisiä, ja kaikki ovat yhtä vastuussa lopputuotteesta.Yksilöiden syyttäminen on ajanhukkaa.Tärkeää on, että ongelmat korjautuvat.
Olen samaa mieltä siitä, ettei kehittäjää syytetä, mutta on tärkeää, että kehittäjä tunnistetaan ja varmistetaan, että hän ymmärtää virheen (jos se on todella virhe), jotta he voivat oppia.Kuulostaa siltä, että he rikkoivat avoimen / suljetun periaatteen.
@DidIReallyWriteThat kyllä, se on totta.Mutta meidän on myös pidettävä mielessä, että OP on joukkueen nuorempi jäsen ja toinen henkilö on paljon vanhempi.Sen lisäksi, että Hubris ei yleensä ole vahva joukkueen pelaaja, on vielä mahdollisuus, että he tekivät oikein, eikä juniori ehkä vielä pysty kertomaan sitä.
+1 yksikötestejä varten.Junit on pelastanut perseeni niin monta kertaa, kun minut suostuteltiin käyttämään sitä.
Virheiden hajauttaminen on kainalosauva.Vaikka vältetään tekemästä siitä henkilökohtainen, sinulla on tilanne, sillä ei ole mitään pitkäaikaisia seurauksia henkilökohtaisen kehityksen kannalta kyseessä olevalle vanhemmalle kehittäjälle.Jos hän ei pysty käsittelemään sitä, mitä sanoit, on epäilyttävää, hän kasvaa ollenkaan.Yritä pyytää häntä lukemaan materiaalia palautteen käsittelystä, voitko (esim. Toisen vanhemman kautta), jos haluat saada mukavan vaikutuksen ongelman sijasta.
@simbabque varmasti, ja tässä tapauksessa on täysin mahdollista, että OP on koulutettava.
Haluan vain huomauttaa - tämä on hieno neuvo kaikille aloille, ei vain ohjelmistokehitykseen.Liian monet ihmiset tarttuvat tähän kokonaisuuteen, "älä syytä minua. Minun osani toimii hyvin" mentaliteetti, jota kukaan ei pysty keskittymään kokonaisuuteen - toimivan tuotteen luomiseen.Kokemukseni mukaan, kun kaikki projektiin osallistuvat suhtautuvat kokonaisvaltaisesti, asiat hoidetaan nopeammin ja vähemmän takaiskuja tapahtuu.
Tämä olisi voinut olla hyvä vastaus, mutta sitten sanottiin, ettei kehittäjiä syytä syyttää.Syytä aina kehittäjiä ... = P (+1)
#2
+22
HorusKol
2018-05-02 17:21:59 UTC
view on stackexchange narkive permalink

Ensinnäkin - ei ole epätavallista, että riippuvuuskoodi hajottaa loppupään koodin. On kehityskäytäntöjä, jotka voivat lieventää tätä, kuten hyvät eritelmät, dokumentaatio ja testit. Mutta se ei ole vastaus kysymykseesi.

Hei, teit tämän X-muutoksen kyseiseen Y-toimintoon. Tämä muutos rikkoo koodini, koska se ei ota Z: tä huomioon, ja Z tapahtuu puolellani. Onko kunnossa tehdä K korjataaksesi sen?

Mitä sanot, voi kohdata syytöksenä - sanot lähinnä "rikkoit koodin" - ja tämä saa ihmiset puolustuskannalla.

Parempi tapa on pitää tämä vähemmän "rikkoit koodin" ja enemmän "haluaisitko katsoa uudelleen X: tä? Luulen, että sen täytyy tehdä K toimiakseen Z: n kanssa".

Jos taas tämä henkilö on murna riippumatta siitä, miten lähestyt häntä, sinun on ilmoitettava pomollesi, että työsi viivästyy, kun sinun on korjattava grumpin työ. Jälleen, älä osoita sormia, mutta jätä se "Z: n käsittely viivästyi X: n muutosten vuoksi ja minun piti tehdä ensin K".

Ja tämä on merkittävä syy käyttää SemVeria.
"Parempi tapa on pitää tämä vähemmän" rikkoit koodin "ja enemmän" haluaisitko katsoa X: n uudelleen?Mielestäni sen on tehtävä K toimiakseen Z: n kanssa. "Tämä tarkoittaa, että sinä _ tosiasiallisesti_ vain _ ajattelet_ sen tarvitsee tehdä niin, ja toinen kaveri ei hyvinkin ehkä _ ajattele sitä].Se ei kuitenkaan tapahdu täällä, OP tietää * varmasti *, että muutos on rikkonut olemassa olevan toiminnallisuuden, ja se on jotain, johon * varmasti * on puututtava.
@Demonblack OP saattaa olla väärä.OP saattaa todellakin olla se, joka tarvitsee päivittää koodin vastaamaan vanhemman kehittäjän koodia.Tärkeä neuvo on puhua koodin ongelmasta sormen osoittamisen sijaan, ei siitä, kuka on oikea tai väärä.
Sillä ei kuitenkaan ole väliä kenen on muutettava mitä.Vaikka muutos olisi järkevä, et tee jotain, joka rikkoo olemassa olevan koodin, puhumatta etukäteen asianomaisiin ihmisiin.
#3
+12
u8it
2018-05-03 00:00:38 UTC
view on stackexchange narkive permalink

Tämä on todella hyvä mahdollisuus naamioituna. Suurin osa insinööreistä ei ymmärrä kuinka valtava tämä on nykyiselle työnantajalle tai mahdolliselle työnantajalle. Teknisten taitojen rinnalla on kykysi tehdä yhteistyötä ihmisten kanssa, ottaa vastuu virheistä, työskennellä muiden kanssa omien tahojensa kautta ja puolustaa tahdikkaasti ajatuksiasi. Yhteinen yksimielisyys on, että tämä voidaan parhaiten osoittaa haastattelemalla jakamalla anekdotinen tarina. yleensä ihmiset niittävät tällaisia ​​tarinoita jälkikäteen, mutta voisit olla hyvin strateginen ja ymmärtää, että sinulla on mahdollisuus kirjoittaa täällä upea tarina, joka vastaisi kysymyksiin, kuten "miten hoidat konflikteja", ja luultavasti avaisit yllättäviä mahdollisuuksia nykyiselle työnantajallesi .

Huomioitavaa on sitten taktiikkasi vs. strategiasi.

Taktiikka

Taktiikkasi on järjestelmät ja toimet, jotka valitset auttamaan ongelmasi. Joten esimerkiksi valitset paremman sanamuodon, joka on vähemmän henkilökohtainen, oikean ajan valitseminen, tarkkaavaisuus yleisölle / sivullisille, auttaminen vastaanottamallesi henkilölle tai kasvojen automaattinen testaaminen virheen havaitsemiseksi. Vietä aikaa oppimiseen ja hyvien taktiikoiden harjoittamiseen. Tämä on työkalupakki, jota voit hyödyntää strategiassasi.

Stategy

Kohtamasi ongelma on oireenmukainen vieläkin suuremmasta ongelmasta: tämä henkilö ei todellakaan pidä sinusta. Sitä haluat strategisesti korjata.

Työpaikalla, etenkin tiimissä, sinulla ei ole hallintaa, että sinulla on henkilökohtainen suhde jokaiseen joukkuetovereihisi. Ehkä joku ei pidä sinusta ja sinä et pidä niistä, liian huono, sinut pakotetaan suhteeseen olemalla tiimissä. Voit valita, ovatko nämä suhteet hyviä vai huonoja. Voit halutessasi ponnistella toisten ihmisten kanssa vai ei. Todellinen ammatillinen kasvu tapahtuu, kun ylität itsesi pelkkänä koodinmurskaajana (mikä johtaa koodin ylimielisyyden ongelmiin), mutta tiimin toimivana jäsenenä ja haluat osoittaa, että joukkueesi kanssa tiimi on suurempi kuin sen osien summa. Se tarkoittaa suurta relaatiotietoisuutta.

Strateginen päätös on kysyä itseltäsi, miltä haluat tämän suhteen näyttävän? Onko se mahdollista? Mitä puuttuu tai mitkä haasteet saattavat estää suhdetta? Mitä sinun on tehtävä, jotta tämä tapahtuisi? Esimerkiksi monet suhdeongelmat johtuvat luottamukseen. Joten strategia olisi näyttää tälle kehittäjälle, että ajattelet hänen etujaan eikä vain omia, ja tuoda suhteesi siihen pisteeseen, jossa tämä henkilö luottaa sinuun. Älä ole stoinen tietää kaikkea, mikä ei saa ihmisiä puolellesi, vaikka olisit oikeassa ja perusteltu. Strategiana on ymmärtää, että haluat ihmisten puolellesi, ja miettiä, miten se tapahtuu. Mikä toimii ja mikä ei. On myös tärkeää ymmärtää, että onnistunut strategia vaatii usein kärsivällisyyttä. Saatat joutua työskentelemään ja haastamaan itsesi enemmän kuin haluat edistyä todella.

Hienoa tässä on, että jos sinulla on todella vankka suhde tähän vanhempaan kehittäjään, taktiikat, jotka saivat sinut sinne, ovat paljon vähemmän tarpeellisia ja on helpompaa olla tehokkaampi ja menestyksekkäämpi työssäsi. Hyvä strategia voi viedä sinut hyvään suhteeseen, ja hyvässä suhteessa sinun on paljon helpompaa saavuttaa tavoitteesi. Joten mieti työskennelläksesi suhteessasi tähän henkilöön, kun ongelmaa ei ole, ja se helpottaa tämänkaltaisten asioiden esiin tuloa.

#4
+11
user8365
2018-05-02 18:32:41 UTC
view on stackexchange narkive permalink

Kuinka minun pitäisi ilmoittaa hänelle, että minulla on hyvät keinot, mutta saa hänet myös ymmärtämään (ja hyväksymään), että hänen on tehtävä tarvittavat muutokset viallisen koodin / moduulin korjaamiseksi?

Sinun on parasta varmistaa, että pomosi / tiimisi on samaa mieltä siitä, että näin tulisi toimia. Ihannetapauksessa koodausympäristössä on jonkinlainen automaattinen testausjärjestelmä, joten jos koodia yritetään tarkistaa taukoissa, se hylätään, kunnes se on korjattu. Yleensä tämän tekee muuttaja. Jokaisen tulisi olla ylpeä työstään, johon liittyy vastuun taso haluta korjata rikkoutuneet asiat. systeemi. He ajattelevat, että tehtävä jätetään nuoremmille kehittäjille; En ole samaa mieltä tämän kanssa. Sinun on selvitettävä, kuinka tämän pitäisi toimia.

Jos koodi rikkoo moduulin rajoja, tämä on ehdottomasti vanhempi kehittäjämateriaali.
Sen on vanhemman kehittäjän, joka päättää, kuinka korjata se.Mutta se ei tarkoita sitä, että heidän on kirjoitettava korjaus henkilökohtaisesti tai että korjauksen on oltava heidän kirjoittamassaan koodissa.
@ThorbjørnRavnAndersen - voi olla järkevää osoittaa se vanhemmalle kehittäjälle, mutta useimmat projektit ovat ajoittain kaoottisia, eikä parhaita käytäntöjä noudateta.Sitä voidaan myös pitää opettavana hetkenä nuoremmalle ohjelmoijalle selvittää se ja saada vanhempi jäsen tarjoamaan enemmän valvontaa.
#5
+5
Sentinel
2018-05-03 04:24:40 UTC
view on stackexchange narkive permalink

Minun lähestymistapani tällaiseen ongelmaan on varmistaa, että käytössä on riittävästi metodologiaa ja työkaluja, jotta asiasta tulisi tekninen eikä henkilökohtainen.

Varmista esimerkiksi, että sinulla on automaattiset koontiversiot ja savutestit. Jos nämä hajoavat, on sääntö, jonka mukaan rikkojan on annettava ruokaa seuraavassa tiimikokouksessa.

Joskus ihmiset vain haastavat rohkeasti status quon itsekkäässä henkilökohtaisen edistymisen etsinnässä. Tavallaan tämä on normaalia. Se on parhaimmillaan yrittäjyyttä. Yksilö etenee kehyksessä, joka sallii sen. Joten, muuta kehystä. Tämäntyyppisiä ihmisiä ei estetä, he edistyvät eri tavoin. Joten johtajana tavoitteena on hyödyntää tätä henkeä ja ohjata sitä tiimille ja tavoitteille myönteisellä tavalla.

Osa tahdonvaljastusstrategiaa on varmistaa, että ihmiset tuntevat edelleen järkevän omistuksen. Tässä toistaiseksi suosituin vastaus kannattaa omistusoikeudesta luopumisen filosofiaa. Mielestäni tämä voi olla haitallista. Anna ihmisten intohimoisesti omistaa alueensa. Mutta varmista, että he eivät riko muita.

Kirjoitin vastauksen, johon tarkoitat, ja olen samaa mieltä myös siitä, mitä sanot.Kyseisen joukkueen juniorille neuvosi eivät kuitenkaan ole erityisen käyttökelpoisia.En usko, että he voivat muuttaa tapaa heidän yrityksessään.Voitteko antaa konkreettisempia neuvoja ei esimiehen roolille vaan pikemminkin OP: n nimenomaiselle asemalle?En ole varma itsestäni, miten he voisivat vaikuttaa siihen, joten menin vastauksellani toista tietä.Haluaisin kuulla mielipiteesi.
@simbabque Kyllä, vastaukseni on enemmän kohti esimiestehtäviä.Luulen, että OP voisi aina levittää johtajalle samoja neuvoja, mutta minusta tuntuu, että se pitää ongelman edelleen "ihmissuhteissa", missä tekninen ratkaisu saattaa olla käytettävissä.Yksityiskohtia on vaikea tietää, mutta tapa, jolla OP ilmaisee ongelmansa, viittaa siihen, että hän on vastuussa vikojen siirtämisestä, ja kulttuuri on löysä, jossa OP menee vain kollegoiden luokse ja kasvotusten kaataa vikoja ihmisille.Teknisesti hän voi välttää tämän lisäämällä lisää testejä tai tekemällä koodin pakottamaan riippuvuudet rakennus- / käännösaikaan.
Kiitos vastauksestasi.Näen nyt mistä tulet.Ollakseni rehellinen, ymmärsin sen enemmän tavalla, jolla OP on melko nuorempi ja kokematon, ja hyppää siten johtopäätöksiin ehkä liian nopeasti.Siksi luulen, että toimintatapojen ehdottaminen johtajalle ei ehkä ole ensisijainen liike heidän kulttuuristaan riippuen.
@simbabque On vaikea tietää.Mielestäni kun vika kirjataan ja siinä lukee "moduuli A tuottaa arvot 1..6" ja "riippuvainen moduuli B odottaa tuloja 1 ... 5", jonkun on määritettävä, missä muutos tulisi tehdä, jos kulttuuri kannustaaalueen omistus.Jos se ei onnistu, kuka tahansa voi tehdä muutoksen.Joka tapauksessa minusta näyttää siltä, että tämä on teknisen johtajuuden ja tälle kulttuurille ominaisen välimiesmenettelyn ongelma.
@simbabque Jos tavoitteena on varmistaa, että käytössä on riittävät työkalut ja metodologia, ja jos eskaloituminen hallinnon kautta ei ole vaihtoehto, omistajariidan vastapuolet voivat ratkaista ongelmansa työskentelemällä ennaltaehkäisevästi työkalujen / metodologian parissa.
#6
+3
HopefullyHelpful
2018-05-03 17:06:32 UTC
view on stackexchange narkive permalink

Tämä kysymys riippuu todennäköisesti suuresti yrityksen kulttuurista.

On yrityksiä, joissa "virheitä ei tapahdu". Tai pikemminkin, et saa puhua heistä, ja johtaja, joka tuntee jonkun tekemän virheen, "tarkkailee kyseistä henkilöä tarkasti".

Tässä tilanteessa ilmoitat ongelmasta kyseiselle henkilölle henkilökohtaisesti. tavallaan johtaja kuulee siitä vain, jos se on ehdottoman välttämätöntä, kertoen heille tarkalleen, mitä haluat heidän tekevän tai korjaavan, kun yritit korjata sen itse. (Pitäisi myös juosta, punaiset liput yada yada.) Sinun tulisi myös kertoa heille, että se on sinun ja heidän välillä ja että olet viileä.

Missä tahansa toimivassa yrityksessä sinun on varmistettava, että paljastaminen ei kuulosta syytökseltä.

Sinun on silti varmistettava, että kerrot heille tarkalleen mitä haluat heiltä ja miksi et voi tehdä sitä itse (koska jos pystyt korjaamaan sen, miksi sitten valitat, korjaa se nopeasti ja jatka eteenpäin, he eivät tehneet sitä luodakseen sinulle työtä, heidän täytyi korjata oma ongelmansa).

Varmista myös, että johtaja tai projekti johtaa on tietoinen ja on antanut kunnon heidän korjaavansa ne.

He eivät voi päättää, mitä tehdä omalla ajallaan, ja saada johtajan / projektin johtajan määräämät työt.

Tuleminen mukaan ja puhuminen virheestä lipussa, joka pitäisi tehdä jo tekemättä niitä asioita ennen sitä ja osoittamalla niitä suoraan, aiheuttaa stressiä ja vaikutelman, että haluat heidän tekevän työtä ajoissa, missä heidät on osoitettu jollekin muulle tai vapaa-ajallaan.

#7
+1
Steve B
2018-05-04 17:49:36 UTC
view on stackexchange narkive permalink

Useimmat ristiriidat tai ongelmat ihmisten kanssa johtuvat prosessin taustalla olevista kysymyksistä. Näin on todellakin tässä tapauksessa.

ja toimiminen tästä näkökulmasta on avain ratkaisemaan taustalla olevat laatukysymykset, jotka johtivat suoraan kokemaasi ongelmaan. Se on myös avain yhteisen keskustelun löytämiseen kollegojesi kanssa (esim. On helppo sopia prosessikysymyksistä, jotka aiheuttavat sinulle tuskaa).
#8
+1
Andrew Ebling
2018-05-07 17:22:54 UTC
view on stackexchange narkive permalink

Vaikka luultavasti haluat vain saada työn tehtyä ja edistyä urallasi, vahingoitat työsuhdettasi parhaiten suoriutuneiden henkilöiden kanssa, jos olet kokenut, että sinulla on mahdollisuus saada yksi kokeneemmista työtovereista. auttaakseni sinua.

Neuvoni on ehdottaa korjausta joko yksityiskohtaisesti (esimerkiksi vetopyynnönä) tai pääpiirre kokonaisuutena, jonka ehdotat ratkaisuksi. Vie tämä henkilölle, jonka koodin katsot rikkoneen, ja pyydä hänen mielipiteitään. Ja mikä tärkeintä, kuuntele vastausta .

Tämä antaa työtoverille, jonka olet ehkä juuri keskeyttänyt, ratkaisun pikemminkin kuin ongelman ja siten lisätyön. Pystyt paitsi oppimaan jotain saamastasi vastauksesta, mutta sinua pidetään hyödyllisenä ja joukkuepelaajana.

Kuten muut ovat ehdottaneet, sinun on poistettava tämä henkilökohtaisuudesta. Koodilla olisi oltava yhteisomistus. Vähemmän "rikkoit muutokseni!" ja enemmän, kuten "kuinka saamme molemmat muutokset toimimaan hyvin yhdessä?"

Voit myös miettiä, onko viestinnän parantamisen mahdollisuutta päivittäisten valmiustilojen aikana (jos sinulla on niitä - tai ehdottaa niiden käyttöönottoa, jos ei), niin että yleensä on enemmän tietoisuutta siitä, mitä ihmiset työskentelevät, ja siten vähemmän ristiriitaisia ​​tai rikkovia muutoksia.

Oikean yksityiskohtaisuuden tarjoaminen standupeissa on hankalaa, mutta jos kollegasi eivät ole Kun tiedät työskentelemäsi koodin laajan alueen, sinun kannattaa harkita hieman tarkemman tiedon antamista.

Jotain muuta pidettävä mielessä - nuorempana, mutta vähemmän kokeneena kehittäjänä on täysin mahdollista, että voit koodata kokeneempia kollegoitasi nopeammin (nuoremmat, terävämmät aivot ovat joskus todellinen voimavara!), mutta sinun pitäisi ymmärrä myös, että vanhemmilla kollegoillasi on kokemuksen edut ja että heitä voidaan harkita heidän lähestymistavassaan vuosien kokemuksensa perusteella. Suurin osa kehityshankkeista muistuttaa pikemminkin maratonia kuin 100 metrin pikajuoksua. Parhaat joukkueet hyödyntävät kaikentyyppisiä kokemuksia.

#9
  0
KishKash
2018-05-04 01:17:04 UTC
view on stackexchange narkive permalink

Kuinka minun pitäisi ilmoittaa hänelle, että tulen hyvillä aikomuksilla, mutta myös saa hänet ymmärtämään (ja hyväksymään), että hänen on tehtävä tarvittavat muutokset viallisen koodin / moduulin korjaamiseksi?

Olen samaa mieltä suuresta osasta jo sanottuja. Eri ihmiset tulkitsevat samaa viestiä eri tavoin, ja mitä yksi henkilö kokee täysin normaaliksi, tehokkaaksi viestinnäksi, toinen tuntee ärsyttävän tai pelottavan - mistä tahansa syystä. Kyseinen henkilö todennäköisesti viestii (epäsuorasti), että hän pitää tyylisi epämiellyttävänä. Kokeile jotain muuta seuraavalla kerralla. Yritä muuttaa asetusta - pidä hänet kiinni suihkulähteestä eikä istuimestaan. Istu hänen viereensä ennen kuin aloitat keskustelun, sen sijaan että seisot hänen yläpuolellaan. Kokeile erilaisia ​​lähestymistapoja - käytä tervettä järkeäsi.

Ja vielä yhden asian, jota voin ehdottaa, yritä tasapainottaa viestintääsi hänen kanssaan. Jos hän on arkaluontoinen sinusta huomauttaessasi virheistään, etsi mahdollisuuksia kiittää häntä (vilpittömästi) älykkäästä suunnittelusta tai tehokkaasta toteutuksesta - se menee pitkälle useimpien ihmisten kanssa.

#10
  0
cpphilosophy
2018-05-04 15:13:00 UTC
view on stackexchange narkive permalink

Helpoin tapa käsitellä sitä on olla käsittelemättä sitä. Anna kehittäjän riitauttaa epäonnistuneen testin sijaan. Kysy heiltä, ​​kuinka koodin pitäisi toimia, ja rakenna sitten testi sen ympärille. Anna heille testi ja kerro heille, että se epäonnistuu.

Passiivis-aggressiivinen ja he saattavat löytää ratkaisun, joka sekä läpäisee testin että rikkoo koodisi.Mitä sitten - eskaloidaan älykäs alkaja?


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 4.0-lisenssistä, jolla sitä jaetaan.
Loading...