Bagaimana Anda meyakinkan manajemen untuk membuang prototipe?


16

Saya suka membuat prototipe sebagai cara cepat dan efektif untuk menempatkan UI di depan pengguna.

Namun berkali-kali, manajemen mendapatkan paruh mereka di jalan, dan prototipe diseret menendang dan berteriak ke dalam pengembangan arus utama.

Bagaimana Anda mengelola manajemen agar tidak melakukan ini?


11
Jangan tunjukkan mainan yang mengkilap kepada anak-anak dan mereka tidak akan bisa bermain dengannya. Serius, buatlah lebih buruk, atau sesuatu, buatlah mereka TIDAK menginginkannya tetapi tetap tunjukkan apa yang Anda coba ekspresikan.
Michael Todd

7
Tanpa sengaja, kehilangan kode;)
Pemdas

9
Gunakan bahasa pemrograman non-mainstream favorit Anda untuk menulis prototipe. Jika tidak berhasil, setidaknya Anda tidak akan keberatan memeliharanya.
Larry Coleman

3
Yup, coba gunakan Napkin Look and Feel napkinlaf.sourceforge.net
Job

1
Nah, prototipe disebut seperti itu karena suatu alasan. Mereka seharusnya dibuang. Jika mereka tidak memahaminya, saya setuju dengan Larry Coleman.
sakisk

Jawaban:


28

Gunakan alat seperti Microsoft SketchFlow , atau buat prototipe Anda dalam bahasa atau platform lain, sehingga hampir mustahil untuk diintegrasikan ke dalam pengembangan utama.

Ada juga esai joelonsoftware tentang menunjukkan tangkapan layar dan prototipe, di mana ia membuat aspek yang tidak diimplementasikan dan tidak dikerjakan tampak jelas rusak / tidak diterapkan, membuatnya menjadi jelas di mana pekerjaan masih perlu dilakukan.

Konsekuensi Penting Dua. Jika Anda menunjukkan layar nonprogrammer yang memiliki antarmuka pengguna yang 100% cantik, mereka akan berpikir programnya hampir selesai.

...

Apa yang dapat Anda lakukan tentang ini? Setelah Anda memahami Rahasia Gunung Es, mudah untuk bekerja dengannya. Pahami bahwa setiap demo yang Anda lakukan di ruangan yang gelap dengan proyektor akan menjadi soal piksel. Jika Anda bisa, bangun UI Anda sedemikian rupa sehingga bagian yang belum selesai terlihat belum selesai. Misalnya, gunakan scrawl untuk ikon pada bilah alat hingga fungsionalitasnya ada. Saat Anda membangun layanan web, Anda mungkin ingin mempertimbangkan untuk benar-benar meninggalkan fitur-fitur dari halaman utama hingga fitur-fitur tersebut dibangun. Dengan begitu orang dapat menonton beranda mulai dari 3 perintah menjadi 20 perintah karena semakin banyak hal yang dibangun.

Jadi, cobalah membuat prototipe Anda di Photoshop daripada Visual Studio, atau sesuatu seperti itu.


1
ya, saya suka Balsamiq!
ozz

+1 SketchFlow mengambil pendekatan cemerlang untuk masalah umum ini; membuat tampilan UI dibuat sketsa. Hitam / putih, menjemukan ... pendekatan yang fantastis untuk menyelesaikan masalah seperti ini. Kedengarannya sederhana namun memiliki efek luar biasa pada mereka yang melihat UI memungkinkan mereka untuk memahami bahwa itu sebenarnya prototipe.
Aaron McIver

1
Poin bagus. Jika itu adalah aplikasi yang berfungsi, maka itu bukan prototipe.
JohnFx

1
Anda dapat mencoba Pensil alih-alih SketchFlow. Gratis: pencil.evolus.vn/en-US/Home.aspx
Brad

-1 tautan utama rusak
Michael Durrant

12

Jangan membuat prototipe dengan kode kerja. Prototipe dengan pensil dan kertas, atau perangkat lunak yang setara .

Menggunakan Mockup terasa seperti menggambar, tetapi karena ini digital, Anda dapat mengubah dan mengatur ulang dengan mudah. Tim dapat datang dengan desain dan beralih secara real-time dalam suatu pertemuan.

http://www.balsamiq.com/images/mockups/screenshots/components.png

Menggunakan kertas memiliki keuntungan yang dapat dengan mudah dilompati oleh anggota tim, dan semua orang mengerti itu hanya selembar kertas kosong. Ini membuatnya tampak kurang berharga.


1
+1: Ini! Setiap kali saya membuat prototipe sesuatu dengan sukses menggunakan kode, saya menyesal nanti ketika kondisi memaksa saya untuk menggunakan kode itu lagi situasinya lama melewati tanggal kadaluwarsa yang dimaksudkan. Dengan kata lain ... JIKA Anda menggunakan bahasa kode produksi untuk membuat prototipe, jangan terlalu terkejut jika nanti berakhir di kode produksi.
mummey

+1 untuk tautan Balsamiq. Saya sering menggunakannya dan ini benar-benar luar biasa.
Ryan Hayes

Saya suka Balsamiq, tetapi bahkan prototipe samar seperti itu bisa menjadi terlalu 'berharga' dan mengabaikan pengembang dalam prosesnya. Seringkali yang terbaik adalah menggunakan pena dan kertas bekas yang bagus - dan tempelkan pena di tangan setiap anggota tim!
Alex Feinman

5

Jangan pernah kompromi kualitas kode Anda.

Menulis kode sampah adalah ekonomi palsu.

Seperti yang disarankan poster lainnya, Anda dapat mencapainya dengan menggunakan alat khusus untuk mock up.

Namun, ada berbagai alasan untuk membangun prototipe. Terkadang Anda dapat menunjukkan apa yang Anda butuhkan tanpa menulis kode, tetapi seringkali ini tidak terjadi. Seorang pemangku kepentingan mungkin ingin Anda menunjukkan kelayakan teknis dari suatu fitur.

Bangun hal paling ramping yang Anda bisa untuk menunjukkan fitur / buktikan konsepnya. Tinggalkan yang lainnya.

Untuk fitur UI, pastikan Anda tidak mengembangkan apa pun di server - jangan menyentuhnya sama sekali. Kembangkan lagi tiruan / tipuan bawaan.

Jika Anda perlu berusaha membuat UI sesuai dengan gaya sisa aplikasi jangan repot-repot. Jika terlihat cukup baik tanpa usaha maka ubah warna untuk membuatnya menonjol, atau mungkin bahkan tanda air untuk menunjukkan bahwa itu adalah prototipe.

Saya telah menemukan bahwa pelanggar yang menyebabkan prototipe berubah menjadi kode produksi adalah orang-orang penjualan. Mereka akan menjual produk Anda ke pelanggan baru - tanpa fitur baru ini, klien tidak akan menandatangani. Anda tidak bisa menyalahkan mereka, mereka punya target. Berhati-hatilah dengan mereka; pastikan mereka tidak membuat Anda mengeluarkan hal-hal yang menunjukkan bahwa itu adalah prototipe. Anda harus bertahan - mereka mungkin seharusnya tidak menyesatkan pelanggan.

Manajemen Anda mungkin mulai memaksa Anda untuk mengubah prototipe menjadi kode produksi sepotong demi sepotong, jika Anda mengikuti saran pertama saya untuk tidak pernah menulis kode jelek, maka Anda seharusnya tidak ada masalah. Secara bertahap, Anda membangun perangkat lunak, tanpa kompromi.

Kemudian jika manajemen mulai memaksa Anda untuk mengurangi kualitas, Anda harus bertanya pada diri sendiri mengapa. Apakah mereka pasif? lemah? putus asa? Tidak satu pun dari hal-hal itu merupakan alasan bagus untuk bertahan di sebuah perusahaan.


1
Saya yang kedua ini. Setelah Anda mencapai tingkat pengalaman tertentu, mudah untuk membangun prototipe dengan kode kualitas produksi seperti halnya kode sampah. Dan cara utama Anda mencapai tingkat pengalaman itu adalah dengan menolak untuk menulis kode sampah.
Amy Blankenship

4

Cukup sederhana kok. Beri tahu mereka bahwa mereka pada akhirnya akan kehilangan klien favorit mereka jika mereka akhirnya membuat kekacauan kereta ini untuk ditampilkan.

Dan ya, minta mereka untuk mengambil risiko jika mereka benar-benar tahu.

Akhirnya: Tolong jangan katakan prototipe memiliki bug spesifik A, B dan C. Kemudian Anda akan dibuat untuk memperbaiki bug itu, dan manajemen akan mengklaim mereka menyalurkan energi untuk membuat produksi perangkat lunak siap.

Kemungkinannya adalah dengan bonus kinerja dan hibah saham masa depan hari ini, mereka akan mendengarkan.


1

Hindari masalah di tempat pertama. JANGAN SELESAI ITU. Maksud saya jangan membuatnya terlihat cantik atau seperti itu cocok dengan gaya yang ada di situs. Tujuannya adalah hanya untuk mendapatkan versi kerja yang paling mentah dari kemungkinan sehingga Anda dapat melihat bahwa aliran UI yang sangat dasar berfungsi. Jika Anda membuang gaya situs yang ada atau terlalu memolesnya, mereka akan menganggap Anda bisa "mencolokkannya." Manajemen seperti Pakled dari Star Trek. Mereka hanya ingin Anda "berhasil". Semakin siap Anda membuatnya tampak, semakin siap mereka akan berpikir itu.

Jika itu tidak menyelesaikan masalah Anda, dapatkan pekerjaan di setidaknya satu perusahaan dengan nama merek terkenal selama setahun. Letakkan email dan nomor Anda di resume online dan Anda akan melawan perekrut kembali dengan tongkat, yang akan memungkinkan Anda untuk mengatakan kepada mereka "sama sekali tidak" dengan kepercayaan seorang dev yang tahu apa yang mereka lakukan dan bisa mendapatkan pekerjaan baru besok di mana semoga keahlian Anda dalam masalah ini ditangani dengan lebih serius.

Saat ini saya sedang mengerjakan basis kode yang tidak memiliki dua tetapi triple-stack-whammy dari Rails, .NET dan Java. Alasan kami membuat Rails ditempelkan adalah karena prototipe dilakukan di Rails dan anjing teratas di perusahaan mengatakan "selesaikan." Kita kadang-kadang perlu mengatakan tidak. Selama kita tidak melakukannya sepanjang waktu, mereka harus menganggap kita serius.

Tapi ya, apa pun yang Anda lakukan dengan prototipe, pastikan itu dimulai dengan jelek.


1

Jangan Khawatir tentang Itu.

Jika Anda duduk dan melempar kontrol UI untuk "prototipe", sebenarnya tidak ada alasan Anda membuang desain itu secara otomatis. Jika itu cukup baik untuk menunjukkan manajemen, maka itu adalah tempat yang baik untuk memulai kapan kode program "nyata".

Pindah dari prototipe ke UI yang lebih "dipoles" seharusnya tidak lebih dari serangkaian langkah yang sepenuhnya dapat dibenarkan. Anda harus menambahkan tombol kedua. Anda mendapat umpan balik dari pengguna yang mereka anggap membingungkan. Grup standar organisasi Anda mendikte perubahan kecil. Anda harus mengubah ukuran kotak teks untuk internasionalisasi.

Tidak satu pun dari alasan itu adalah "yah, itu hanya prototipe." Dalam desain UI atau dalam kode atau tulisan, APA SAJA dapat berakhir hidup selamanya. Dan mereka yang tidak semuanya harus memiliki alasan yang sangat baik untuk membunuh mereka.

Dan manajemen mungkin tidak peduli.

Secara realistis, jika alasan Anda tidak hanya memasukkan UI ke kode yang ada adalah "Saya harus menulis ulang dalam kerangka kerja yang benar", itu sudah cukup menjadi alasan. Dan jika tidak, Anda mungkin harus berdiskusi tentang kerangka UI itu sendiri, tapi itu pertanyaan lain.


0

Dulu saya memiliki masalah ini, sampai, saya menyadari itu bukan masalah tetapi cara membebaskan diri dari standar pengembangan yang agak ketinggalan zaman yang diberlakukan di sebagian besar toko.

Jadi, Anda memberi tahu manajemen Anda bahwa Anda sedang menulis prototipe, Anda memilih teknologi yang paling cocok untuk Anda, untuk bidang masalah ini, dan Anda kemudian menulis perangkat lunak dengan sepengetahuan penuh bahwa itu akan digunakan untuk produksi.

Anda lolos dari kebosanan "aplikasi harus dalam java 1.6 menggunakan Web (masukkan mesin J2EE mahal pilihan manajemen)" dan standar penamaan yang tidak berguna dll.

Bahasa prototipe pilihan saya saat ini adalah "php" (yang benar-benar skala untuk lingkungan produksi tugas berat - hanya meminta Facebook) dan kombinasi yang sangat elegan Groovy / Java dengan Tomcat atau Jetty.

Kombinasi groovy / java sangat bagus untuk pengembangan yang cepat. Groovy bagus untuk digunakan dengan cepat untuk dikembangkan tetapi berkinerja seperti siput geriatrik, namun itu mudah untuk faktor ulang kinerja bagian kritis ke Jawa murni. Pernikahan aplikasi ke Tomcat atau Jetty berarti tidak pernah harus berurusan dengan EJB dan kengerian J2EE lainnya lagi.

Keuntungan utama memiliki prototipe yang berfungsi sebagai lawan sketsa seperti yang diusulkan oleh beberapa poster adalah umpan balik pengguna. Prototipe adalah cara yang bagus untuk membuat bisnis benar-benar terlibat dalam desain. Begitu mereka menyadari mereka dapat mengatakan hal-hal seperti "seharusnya bidang itu tidak ada di layar utama" dan hei presto! itu ada di layar utama di demo berikutnya mereka membuka dan terlibat dalam desain yang membawa pengalaman bisnis bertahun-tahun yang berharga ke proyek.


"Groovy bagus untuk digunakan dengan cepat untuk dikembangkan tetapi berkinerja seperti siput geriatrik, namun mudah untuk memasukkan kembali faktor-faktor kinerja kritis ke Jawa murni." Anda benar-benar perlu memperbarui seluruh prototipe ke Jawa jika Anda menggunakan Groovy untuk membuat prototipe.
Vorg van Geir
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.