Bagaimana Anda menangani API / teknologi over-the-head

11

Saya kira sebagian besar orang berada dalam situasi ini.

Perencanaan proyek awal dimulai. Persyaratan diuraikan. Setelah ulasan arsitektur dan memilah-milah API / Kerangka teknologi pas dipilih. Pengembangan dimulai.

Dan kemudian mulai. Segera setelah Anda perlu melakukan beberapa hal pendukung yang seharusnya sederhana, kerangka / API mulai menjadi bumerang, dan alih-alih melakukan pekerjaan apa pun, Anda akhirnya berjuang melawan teknologi. Meroket waktu penelitian, forum diam, sepertinya tidak ada yang dilakukan, dan bahkan ketika Anda mendapatkan sesuatu untuk bekerja, Anda tidak benar-benar yakin itu dilakukan dengan benar.

Bagaimana Anda mengatur situasi ini? Apakah Anda melakukan peretasan, penelitian lebih lanjut, apa yang Anda katakan kepada manajemen?

technology research

— Coder
sumber

+1: Pertanyaan yang sangat bagus. Layak mendapat nilai +10. Saya memiliki pengalaman yang sama.

— Jim G.

Itu pertanyaan yang bagus. Sering kali saya melihat di mana kata-kata seperti "leverage" dan "sinergi" digunakan untuk menjual beberapa barang pihak ketiga. Jadi Anda terkunci di dalamnya, dan mereka pergi dan menariknya dari bawah Anda. (MS suka melakukan itu.) Sementara itu, penginjil asli sudah lama hilang.

— Mike Dunlavey

9

Prototipe, Prototipe, Prototipe !!

Jika tim Anda tidak terbiasa dengan kerangka kerja tertentu maka buat prototipe sesuatu di dalamnya untuk mengevaluasi di mana titik-titik rasa sakitnya.

Matt Raible (pembanding kerangka kerja Web Java) menyarankan bekerja dengan kerangka kerja selama satu minggu jika memungkinkan.

Prototyping termasuk menyelidiki dukungan masyarakat di balik suatu kerangka kerja dan faktor-faktor lain

— Martijn Verburg
sumber

+1 untuk prototipe. Memiliki sesuatu yang benar-benar berfungsi walaupun itu disatukan dengan lakban dan disangga dengan tongkat, dan akan hancur jika Anda membiarkannya sendiri selama lima menit, merupakan tonggak pencapaian yang sangat berharga untuk dicapai.

jika perencanaan proyek awal dimulai, seperti ditunjukkan dalam pertanyaan, itu berarti bahwa perjalanan untuk proyek telah diberikan sehingga telah SUDAH dijual kepada pelanggan. Jadi ... jika tidak ada "prototyping" dan biaya dalam hitungan jam dimasukkan ke dalam WBS ini maka tidak ada prototip di tempat. Idealnya Anda ingin ini terjadi sebelum bahkan menjual solusinya. Jadi sebelum satu atau lebih proyek berperan dari itu. Jauh sebelum proyek itu Anda ingin menempatkan "prototyping" sebagai bagian dari jam yang dibutuhkan dan beberapa evaluasi. Ini sulit bagi kebanyakan pelanggan karena mereka menginginkan solusi.

— edelwater

dan spesifikasi server spesifikasi server van van voren ....

— edelwater

6

Mengelola dependensi eksternal adalah kutukan banyak proyek TI. Bertahun-tahun yang lalu, programmer berpengalaman yang bekerja dengan saya selalu memastikan mereka memiliki kendali atas dependensi mereka - Biasanya dengan menegaskan bahwa lisensi kode sumber dibeli.

Secara pribadi, itu belum menjadi pendekatan saya. Saya cenderung menjadi di bawah janji, lebih dari memberikan sekolah pemikiran. Ada saat-saat ketika saya harus berusaha keras, tetapi saya melakukan penelitian pribadi sebelumnya untuk memastikan 99% - biasanya melakukan proyek pribadi sering kali di waktu saya sendiri untuk memastikan teknologi dapat memberikan. Pada dasarnya prototipe, tes, validasikan lalu janjikan.

Ada situasi di mana saya terjebak - dan harus mundur atau menjadi inventif. Memiliki pikiran kreatif dengan banyak pengalaman luas membantu di sini, tetapi begitu juga berbicara dengan orang lain. - dan tidak selalu programmer. Terkadang solusi datang dari tempat yang sangat aneh.

Sedangkan untuk berurusan dengan manajemen, kuncinya adalah kejujuran. Bicara lebih awal, dan sering. Jangan biarkan sampai menit terakhir sebagai mengecewakan manajer / pelanggan sehari sebelum pengiriman besar hanya membuat Anda terlihat seperti amatir. Dapat mengatakan 2 bulan sebelum batas waktu yang harus dipilih oleh manajer antara menjatuhkan beberapa fitur dan / atau menunda pengiriman mungkin tidak populer pada saat itu, tetapi hal itu memungkinkan organisasi untuk melakukan pekerjaan mereka dan merencanakan . Kunci untuk dapat melakukan ini adalah memiliki sistem manajemen tugas yang baik yang melacak waktu dan perkiraan tugas. Memiliki bukti kuat untuk mendukung sudut pandang Anda membuat Anda lebih mungkin didengarkan.

— Michael Shaw
sumber

Saya telah melakukan banyak hal yang sama dengan yang Anda sebutkan di sini dan itu telah bekerja dengan sangat baik untuk saya. Sejauh pengetahuan saya, klien yang pernah bekerja sama dengan saya sangat puas dengan apa yang saya sampaikan karena saya umumnya melebihi harapan yang mereka miliki. Mereka juga sangat menghargai komunikasi tentang bagaimana hal-hal mengalami kemajuan dan ketika ada masalah apa itu dan dampaknya.

— Ken Henderson

2

"Bagaimana Anda mengelola dalam situasi ini?" Apa yang saya lihat / alami:

poin 1 saya setuju dengan Ptolemy: jujur:

Jika itu benar-benar masalah: pergi ke kamar itu, ceritakan masalahnya, duduklah untuk menunggu respons kemarahan dan kemudian ... kerjakan rencana / solusi baru. (pria itu tidak marah pada Anda secara pribadi).

Ada kursus TI yang hanya menangani situasi ini. Anda ditempatkan dengan aktor dan mereka menempatkan klien yang marah yang mendengar berita ini. Anda mendapatkan banyak tips di sekitarnya. Kedengarannya bodoh tapi mungkin hanya setelah melakukannya Anda menyadari nilainya. Saya pergi dengan selembar dengan 80 poin untuk diingat dalam situasi itu ... (dan berlatih).

Situasi ini tipikal mungkin bahkan lebih hari ini di mana anggaran sangat ketat, penjualan dilakukan pada "penawaran terendah", perencanaan yang Anda berikan dipangkas 5 kali sebelum diterima oleh pelanggan ... (termasuk prototipe itu karena "ia sedang merekrut Anda karena Anda ahli dan sebaliknya 10 orang menunggu ") dll ...

- Hal lain mungkin pemikiran lateral: jika tidak dapat dilakukan dengan cara ini cobalah untuk mengusulkan sesuatu yang sama sekali berbeda yang memberikan nilai yang sama bagi pelanggan. Jika teknologi tidak bekerja sama sekali / rusak / melompat keluar dari kesepakatan / dll ... Jika pelanggan membeli ini, ia dapat memberikan nilai yang sama di akhir. Tetapi membawanya juga cukup sulit. (untuk beberapa dan sama sekali tidak untuk yang lain). Anda membutuhkan orang yang benar-benar berpengalaman untuk ini. Situasi yang sama adalah bahwa Teknologi TIDAK BELUM sanggup melakukannya ... dibutuhkan beberapa bulan ... Jadi, Anda perlu meyakinkan pelanggan untuk merencanakan ulang dan menerima perencanaan ulang dan dampak pada organisasinya ...

- 'Pelajaran lain yang dipelajari' adalah untuk memanggil para senior senior segera setelah Anda perhatikan bahwa itu mengarah ke arah ini. Mereka sering berurusan dengan proyek yang bermasalah dan sangat membantu dalam situasi ini. Seringkali mereka hanya melakukan perjalanan dari proyek bermasalah ke proyek bermasalah.

- Pelajaran lain yang dipelajari adalah membiarkan hal-hal arsitektur Anda melalui saluran verifikasi terutama pada proyek-proyek besar. Tanda tangan dapat menutupi pantat Anda. (simpan semua email Anda LOL)

— edelwater
sumber