Come gestite le API / la tecnologia over-the-head

Immagino che molte persone si siano trovate in questa situazione.

Inizia la pianificazione iniziale del progetto. I requisiti sono indicati. Dopo la revisione dell'architettura e l'ordinamento tramite API / Frameworks viene scelta la tecnologia di adattamento. Lo sviluppo ha inizio.

E poi inizia. Non appena è necessario eseguire alcune operazioni di supporto apparentemente semplici, framework / API iniziano a ritorcersi contro e, invece di svolgere qualsiasi lavoro, si finisce per combattere contro la tecnologia. Il tempo della ricerca sale alle stelle, i forum sono silenziosi, nulla sembra essere fatto, e anche quando fai funzionare qualcosa, non sei davvero sicuro che sia fatto bene.

Come gestisci queste situazioni? Ti piacciono gli hack, fai ulteriori ricerche, cosa dici al management?

Prototipo, prototipo, prototipo !!

Se il tuo team non ha familiarità con un determinato framework, prototipa qualcosa al suo interno per valutare dove si trovano i punti deboli.

Matt Raible (ragazzo del comparatore di framework Web Java) suggerisce di lavorare con un framework per una settimana, se possibile.

Il prototipo include l'indagine del supporto della comunità dietro una struttura e altri fattori

La gestione delle dipendenze esterne è la rovina di molti progetti IT. Molti anni fa i programmatori esperti con cui ho lavorato si sono sempre assicurati di avere il controllo sulle loro dipendenze - di solito insistendo sul fatto che le licenze del codice sorgente fossero state acquistate.

Personalmente, questo non è stato il mio approccio. Tendo ad essere sotto la promessa, oltre a consegnare la scuola di pensiero. Ci sono momenti in cui ho dovuto sporgere il collo, ma prima faccio ricerche private per essere sicuro al 99% - di solito sto facendo un progetto privato spesso ai miei tempi per assicurarmi che la tecnologia sia in grado di offrire. In effetti prototipo, test, convalida quindi promessa.

Ci sono situazioni in cui mi sorprende e devo tornare indietro o essere inventivo. Avere una mente creativa con molta esperienza ampia aiuta qui, ma anche parlare con altre persone. - e non sempre programmatori. A volte le soluzioni provengono da luoghi davvero strani.

Per quanto riguarda la gestione, la chiave è l'onestà. Parla presto e spesso. Non lasciarlo all'ultimo minuto perché deludere i gestori / i clienti il ​​giorno prima di una grande consegna ti fa sembrare dei dilettanti. Essere in grado di dire 2 mesi prima della scadenza che i gestori devono scegliere tra il rilascio di alcune funzionalità e / o il ritardo della spedizione potrebbe non essere popolare al momento, ma consente al resto dell'organizzazione di fare il proprio lavoro e pianificare . La chiave per riuscire a farlo è avere un buon sistema di gestione delle attività che tiene traccia dei tempi e delle stime delle attività. Avere prove concrete a sostegno del tuo punto di vista rende molto più probabile che tu sia ascoltato.

"Come gestisci queste situazioni?". Quello che ho visto / vissuto:

il punto numero 1 Concordo con Tolomeo: sii onesto:

Se è davvero un problema: vai in quella stanza, racconta il problema, siediti per aspettare la risposta della rabbia e poi ... lavora per un nuovo piano / soluzione. (il ragazzo non è arrabbiato con te personalmente).

Esistono corsi di informatica che affrontano solo questa situazione. Vieni collocato con attori e mettono il cliente arrabbiato che ascolta questa notizia. Hai molti consigli su di esso. Sembra stupido, ma probabilmente solo dopo averlo notato ne noterai il valore. Sono partito con un foglio con 80 punti da ricordare in quelle situazioni ... (e pratica).

Questa situazione è tipica probabilmente ancora di più oggi, dove i budget sono limitati, le vendite vengono effettuate in "offerta più bassa", la pianificazione che hai dato viene ridotta 5 volte prima di essere accettata dal cliente ... (incluso quel prototipo poiché "sta assumendo tu perché sei l'esperto e altrimenti sono altri 10 in attesa ") ecc ...

- Un'altra cosa potrebbe essere il pensiero laterale: se non si può fare in questo modo, provare a proporre qualcosa di completamente diverso che offra lo stesso valore al cliente. Se la tecnologia non funziona TUTTO / è interrotta / salta fuori dall'affare / ecc ... Se il cliente accetta questo, può fornire lo stesso valore alla fine. Ma portarlo è anche piuttosto difficile. (per alcuni e totalmente non per altri). Hai bisogno di ragazzi davvero esperti per questo. Una situazione simile è che la tecnologia NON È ANCORA all'altezza ... ci vogliono alcuni mesi ... Quindi è necessario convincere il cliente a ripianificare e accettare la ripianificazione e l'impatto sulla sua organizzazione ...

- Un'altra "lezione appresa" è quella di invocare i ragazzi senior non appena noti che va in questa direzione. Spesso si sono occupati di progetti problematici e sono davvero utili in queste situazioni. Spesso viaggiano solo da un progetto travagliato a un progetto travagliato.

- Un'altra lezione appresa è quella di far passare i tuoi elementi architettonici attraverso i canali di verifica, specialmente sui progetti più grandi. Una firma può coprirti il ​​culo. (salva tutte le tue e-mail LOL)