Questo si riduce a quello che ho iniziato a pensare come "The Eternal Conflict" (tra business e ingegneria). Non ho la soluzione in quanto è un problema che non scompare mai, ma puoi fare cose per mitigare.
Ciò che la gente spesso non capisce è che come ingegneri stiamo solo assumendo che il problema del "business di successo" sia sempre scontato. Vogliamo che il nostro codice sia carino, ordinato e mantenibile in modo da poter aggiungere nuove funzionalità e modificare quelle esistenti rapidamente e con un minimo di clienti che eseguono il QA per noi scoprendo bizzarri casi marginali che sarebbero stati vanificati da un codice migliore. Mantenere i clienti e mantenere un vantaggio competitivo con funzionalità e finezza che nessun altro è in grado di produrre abbastanza velocemente sono entrambe le conquiste aziendali a cui il buon codice contribuisce direttamente e informa gran parte del motivo per cui desideriamo un codice migliore in primo luogo.
Quindi spiegalo. "Vogliamo fare X nella nostra base di codice perché se non lo facciamo avrà un impatto negativo sul business a causa di Y" o "... perché migliorerà la nostra capacità di rimanere competitivi migliorando la nostra capacità di trasformare i nuovi miglioramenti e funzionalità più velocemente ".
E fai del tuo meglio per cercare di ottenere prove tangibili del funzionamento dei miglioramenti. Se il miglioramento di un sottoinsieme di un'app ha comportato una funzionalità / un miglioramento più rapidi, controlla lo strumento di backlog che potresti utilizzare per dimostrarne l'evidenza e segnalalo alle riunioni appropriate.
- Porta il team sulla stessa pagina maledetta
Gli ego sono spesso un problema. Una cosa di cui i team di ingegneri hanno molto bisogno è stabilire il valore di avere un qualche tipo di approccio coerente concordato per risolvere determinati tipi di problemi rispetto a tutti quelli che fanno la propria coppa di Kool Aid d'jour perché conoscono meglio. Va bene credere che la preferenza dell'altro sia peggiore della tua, ma apprezza la coerenza rispetto all'essere più giusti se il suo approccio è praticabile ed è un argomento che non puoi vincere. Il compromesso per coerenza è fondamentale. Quando le cose sono coerenti, è più difficile sbagliarle poiché il modo coerente stabilito di solito sarà anche il modo più veloce.
- Scegli gli strumenti giusti
Esistono due scuole di framework / set di strumenti / librerie / qualunque cosa. "Prepara il 99% per me, quindi devo sapere / fare molto poco" vs. "Stammi lontano quando non ti voglio lì, ma aiutami il fai-da-te molto rapidamente e coerentemente con le cose che voglio davvero da utilizzare sulla carota anziché sul principio "stick". Favorisci il secondo. Flessibilità e controllo granulare non dovrebbero mai essere sacrificati sull'altare della rapida inversione di tendenza perché a biz, "non possiamo farlo perché i nostri strumenti non ci permettono" non è mai una risposta accettabile e la domanda sorgerà sempre per non ingegneria del prodotto banale / monouso. Nella mia esperienza, gli strumenti inflessibili vengono quasi sempre spalancati o aggirati in modo non elegante e rendono un grande pasticcio non mantenibile. Più spesso che non, le soluzioni flessibili / più facili da modificare sono altrettanto o quasi altrettanto veloci a breve termine, indipendentemente. Veloce, flessibile e gestibile sono possibili con gli strumenti giusti.
- FFS, se gli ingegneri non decidono, ottenere almeno l'input dell'ingegnere sulla scelta degli strumenti
Ho l'impressione che si tratti di una domanda dal punto di vista dello sviluppatore, ma mi sono trovata in troppe situazioni in cui le decisioni tecnologiche sono state prese con zero input da ingegnere. Che diavolo è quello? Sì, qualcuno alla fine deve effettuare la chiamata finale, ma ottenere alcune opinioni qualificate se sei un manager non tecnico, non quello che dice un addetto alle vendite o un sito demo sui propri prodotti. Tutto ciò che promette di risparmiare denaro perché le persone non hanno bisogno di essere così intelligenti o perché protegge gli sviluppatori da se stessi è una sporca, sporca menzogna. Assumi talenti di cui ti puoi fidare. Spiega loro ciò che vuoi da uno stack o altra soluzione tecnologica e prendi sul serio il loro contributo prima di decidere su quale carrozzone tecnologico saltare.
- Focus sulla progettazione oltre l'implementazione
Gli strumenti sono per l'implementazione e come tali possono aiutarti, ma la prima priorità deve essere l'architettura indipendentemente da qualsiasi set di giocattoli che hai per costruire quell'architettura. Alla fine della giornata KISS e DRY e tutte le filosofie eccellenti che si estendono da quelle questioni più che se si tratti di .NET o Java o forse qualcosa che è sia gratuito che non fa schifo.
- Registra le tue preoccupazioni
Quando il lato biz insiste che lo fai nel modo sbagliato, salva quell'e-mail, specialmente la parte in cui hai detto perché ti costerebbe. Quando tutte le tue previsioni diventano realtà e si verificano gravi problemi dannosi per le aziende, è allora che hai una grande pila di argomenti per prendere più seriamente le preoccupazioni degli ingegneri. Ma cronometra attentamente le cose. Nel mezzo dell'inferno ardente è un brutto momento per un "te lo ho detto" sul seguente codice di fuoco. Spegni il fuoco e porta la tua lista di preoccupazioni precedentemente ignorate a una riunione / conversazione retrospettiva, e cerca di concentrarti sulle preoccupazioni ingegneristiche espresse e ignorate e sul ragionamento che hai capito perché venivano ignorate, non sui nomi delle persone reali prendere la decisione di ignorare. Sei un ingegnere. Rimani sui problemi, non sulle persone. " Abbiamo espresso preoccupazione per X perché temevamo che potesse causare problemi a Y. Ci hanno detto Z e di rimandare a che fare con esso. "