Kysymys:
Käsittely jonkun kanssa, joka luulee olevansa "jumalallisesti oikeassa"
Karlson
2012-04-11 19:44:26 UTC
view on stackexchange narkive permalink

Olen viime aikoina törmännyt tilanteeseen, jossa minun on kohdattava henkilöä (ohjelmistoarkkitehti), joka näyttää ajattelevan, että hänen keksimänsä ohjelmistoratkaisu on pohjimmiltaan "jumalallisesti oikea" ja sitä voidaan soveltaa kaikkiin tilanteisiin. Menemättä liikaa yksityiskohtiin ratkaisun yksityiskohdista olemme suorittaneet nopean analyysin ratkaisun soveltamisesta käsillä olevaan ongelmaan ja tulleet esiin lisää kysymyksiä ja ongelmia, jotka haluan luetella kysymyksessä, mutta tämä henkilö jatkaa soveltamista ratkaisu.

Jotkut ensimmäisistä yrityksistä käyttää ratkaisua tämän henkilön keksivät tuotetut Rube Goldbergin koneet, joiden on osoitettu toimivan mitattavasti hitaammin kuin edelliset ratkaisut (ei väliä kuinka vanhentunut ja huonosti kirjoitettu).

Tältä henkilöltä on pohjimmiltaan palannut, kun kysymyksiä alkaa esittää: "Näin olen päättänyt tehdä sen ja me teemme tämän!"

Kuinka käsittelet tällaista ihmistä?

Mitä tekemistä tällä kysymyksellä on Peter-periaatteeseen?
OP on jättänyt pois kriittisen osan - kuinka paljon arvostat mielenterveyttäsi :) Vakavasti - jos he ovat asemassa, joku todennäköisesti tukee heitä. Niin kauan kuin tämä pätee, sinulla ei todennäköisesti ole vaihtoehtoja.
@JohnFx Koska täältä näyttää siltä, ​​että tämä henkilö saavutti "oman epäpätevyytensä tason", mutta poistin sen joka tapauksessa.
@AffableGeek Konsulttina oleminen ei välitä minusta, koska Rube Goldbergin koneet voivat maksaa laskut lähes loputtomiin. :)
Aiheeseen liittyvä metakeskustelu: http://meta.workplace.stackexchange.com/questions/35/do-we-have-a-quality-control-issue
Neljä vastused:
#1
+22
kevin cline
2012-04-11 21:11:47 UTC
view on stackexchange narkive permalink

Ainoa nopea ratkaisu, jonka olen löytänyt näissä tilanteissa, on löytää uusi tilanne. Olet tekemisissä organisaation hulluuden kanssa, etkä pysty korjaamaan sitä milloin tahansa. Väärää henkilöä on ylennetty, eikä hänen johtajansa näytä tietävän tai välittävän. Sinulla ei ole tarpeeksi vaikutusvaltaa muutoksen tekemiseen, ja tekniset argumentit eivät toimi .

Vaihtoehto on mennä tehottoman prosessin mukana ja säästää aikaa. Lopulta kustannusten ylitykset pakottavat jonkun huomioimaan. Arkkitehtiä kannustetaan tekemään jotain muuta. Jos olet pysynyt lähellä, tehnyt yhteistyötä ja voittanut ystäviä, ehkä olet seuraava arkkitehti.

BTW, lähdin hyvin samanlaisesta tilanteesta viisi vuotta sitten. Epäpätevät tekniset johtajat vaihdettiin viime vuonna.

* ehkä sinusta tulee seuraava arkkitehti * ei tässä tapauksessa, mutta hyvä ajatus.
Voi kestää paljon aikaa, ennen kuin tällaiset ihmiset korvautuvat. Jos tämä on krooninen ongelma, sinun pitäisi ajatella vakavasti siirtymistä.
Yea, there's always a little A -> B vector thing going on, where the visible incompetent person B is being supported by some senior person A who vouches for them being A Good Person And Therefore Not the Source Of Our Problems.
+1 for finding a new situation. I have struggled with the 'divine rightness' of a key decision maker for a few years. The big frustration for me is not personal disagreements or not having it my way but the business cost of a bad decision diminishing the success of my colleagues - if you work as a team, you should strive to win as a team.
#2
+4
jefflunt
2012-04-11 20:12:50 UTC
view on stackexchange narkive permalink

Jos kyseisellä henkilöllä on päätöksentekovalta, niin se on. Jos se ei täytä asiakkaan vaatimuksia (eli asiakas on eri mieltä siitä, että ratkaisu täyttää heidän vaatimukset), hänen ei tarvitse välttämättä maksaa siitä (ellei sopimuksessa toisin mainita), ja he voivat sanoa jotain niin yksinkertaista kuin "Ok , Kuulen, miksi haluat mennä tällä tavalla, mutta se ei ratkaise ongelmaa, jonka tarvitsen ratkaisun [ohjelmisto / tuote / ratkaisu]. "

Egot ovat korkealla. Tämä on osa mitä tahansa työpaikkaa. Insinöörityyppien osalta voit yrittää esittää objektiivisia, mitattavissa olevia suorituskyky- ja laatumittareita (jos tämä pätee tilanteessasi) - insinöörit (ainakin yleisesti) vastaavat perusteltuihin argumentteihin. Jos se epäonnistuu, sinun on mietittävä, kenellä on päätöksentekovalta, onko tämä taistelun arvoinen taistelu vai ei, ja miten se vaikuttaa asiakkaisiisi ja liiketoimintaasi. Minusta ei ole haittaa tehdä huolesi tiedoksi, kunhan se on perusteltu, objektiivinen näkökulma eikä henkilökohtainen hyökkäys insinööriä vastaan.

Kaikki mitä sanotaan, mitä emme Kysymyksestäsi ei ole insinöörin näkökulma - ehkä olet väärässä tässä, ehkä et ole - on vaikea tehdä päätös tuntematta molempia osapuolia.

* Jos se ei täytä asiakkaan vaatimuksia *. Valitettavasti asiakas on yrityksen sisäinen eikä hänellä ole tapaa eikä tietoa arvioida ratkaisua.
* mitä emme näe kysymyksestäsi, on insinöörin näkökulma * Toivon, että hän antaisi sen pidemmälle kuin "tässä ovat marssi tilauksesi".
Sikäli kuin asiakkaalla ei ole tietoa ratkaisun arvioimiseksi, en ymmärrä, kuinka se on mahdollista. Huomaan, että asiakkaalla ei ole teknisiä taitoja argumentoida ** teknisiin ansioihin ** perustuvan ratkaisun puolesta tai vastaan, mutta asiakas ** välittää asioista, kuten jos ohjelmisto tekee työnsä riittävän nopeasti anna pyydetyn liiketoiminnan arvo, jos ohjelmisto tuottaa oikeita tuloksia jne. Jos tekninen ratkaisu, jonka insinööri ehdottaa, ei vaikuta asiakkaaseen kummallakaan tavalla, niin miksi sillä on väliä mikä ratkaisu valitaan? Heidät palkataan teknisiksi asiantuntijoiksi.
Olette oikeassa, että heillä ei ole teknistä asiantuntemusta arvioida, mutta heille myydään lasku tavaroita, jotka vaikuttavat heihin. Ongelmana on, että myyjä (insinööri) ei ole henkilö, joka toteuttaa ratkaisua. Ratkaisu vaikuttaa liiketoimintaan, mutta vastuu toteutuksesta ei ole insinöörillä.
En tiedä voinko auttaa sinua siellä - tämä tuo mieleeni paljon kysymyksiä. Ei ole selvää, miksi insinööri on mukana keskustelussa, jos he eivät aio olla mukana toteutuksessa tai jatkuvassa tuessa. Onko tämä henkilö osaston / ryhmän johtaja, jolle on annettu nämä päätökset? Tuovatko he mukaan muita insinöörejä, jotka toteuttavat / tukevat ratkaisua ja ottavat heidän näkökulmansa huomioon päätöksessä? Tämä kuulostaa oudolta.
Oletetaan Behemoth-pankki, jolla on "Technology Architecture Group", "Trading Group" ja "Software Development Group". "Teknologiaarkkitehtuuriryhmä" keksi ratkaisun ja antoi "Software Development Groupille" tehtäväksi toteuttaa se samalla myymällä "Trading Groupille", että tämä on suurin asia viipaloidun leivän jälkeen. Jossakin nenäverenvuodon korkeudessa Arkkitehtuuri- ja Kehitysryhmät raportoivat samalle henkilölle, mutta valitettavasti se on niin korkea, että: http://www.fortunecity.com/campus/books/845/shithap.htm
Okei, mutta tällöin törmäät politiikan, rakenteen ja organisaation alueisiin. Olet päässyt täysin irti alkuperäisestä kysymyksestä, joka oli kuinka käsitellä henkilöä / egoa. Kaikkien näiden ehtojen ja erityispiirteiden lisääminen alkaa kääntää tämän pohjimmiltaan erilaiseksi kysymykseksi: eli kuinka navigoida rakenteissa ja politiikassa, joka liittyy siihen, miten organisaatioissa päätökset tehdään. En voi antaa siihen hyvää vastausta ** tämän ** kysymyksen puitteissa, koska se on täysin erilainen kysymys.
#3
+2
Ourjamie
2012-05-15 15:06:46 UTC
view on stackexchange narkive permalink

Simlar-tilanteissa olen luottanut siihen, että saan varmuuskopion luettelosta resursseista (kirjat, blogit, standardit ja ohjeet kehitystilan suurimmilta toimittajilta, esim. IBM, Microsoft, Idesign, Thoughtworks). ne pisteet, jotka yritän päästä eteenpäin ja joiden on valitettavasti täytynyt tuottaa niitä kokouksissa.

Jos olet käynyt läpi prosessin ja sinulle kerrotaan edelleen, et ole oikeassa, väärä tai he tietää paremmin. Sitten tee niin kuin sinua käsketään tekemään, mutta pidä kiinni lähdemateriaalistasi, jos jokin menee pieleen peittämään itseäsi ja omaa ammatillista koskemattomuuttasi. Myönteinen se on, että se auttaa parantamaan taitojasi, kun opit tekemään tarvittavat tutkimukset väitteidesi tueksi ja vaikeuksien (ihmiset, tilanteet ja puutteelliset lähestymistavat) käsittelemiseksi.

Lopuksi kysy vain, kuinka he tulivat päätöksensä tuloksiin. Ohjelmistoarkkitehdin tehtävänä on näyttää suunnittelun tarkoitus ja tarkoitus ja kuinka kaikki työosat sopivat yhteen ratkaisun tarjoamiseksi.

#4
  0
Lucas Kauffman
2012-04-11 19:55:09 UTC
view on stackexchange narkive permalink

Asia, jonka voit tehdä, on keskustella hänen kanssaan ryhmässä siitä. Jos tämä on yhteinen ponnistelu, sinun täytyy nähdä, mitä muut ihmiset ajattelevat hänen ratkaisustaan ​​ja onko olemassa parempi vaihtoehto.

Jos sinusta tuntuu, että hänen ratkaisunsa laatu ei ole tarpeeksi hyvä ja tekisi sinun asiakas onneton tai vaarantaa projektisi. Ota se tiimisi johtajan tai pomosi kanssa. Selitä heille, miksi hänen mielestään hänen ratkaisunsa ei ole oikea. Näytä vaihtoehto. Kuitenkin, jos olet ainoa joukkueestasi, joka ajattelee olevansa väärässä, sinun on mentävä virtaan, jota pelkään.



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