Persiapan pengembangan web dan seluruh alur kerja proyek


9

Saya bekerja sebagai programmer tunggal pada proyek pengembangan web (depan dan belakang) - Saya telah menyelesaikan beberapa proyek, jadi saya cukup baru dalam hal ini, saya telah membaca dan mencoba beberapa pendekatan dan mencapai cara untuk pergi tentang mereka. Pertanyaan dan deskripsi saya cukup panjang jadi harap bersabar.

Apa yang saya cari, adalah:
1. Persiapan / Perencanaan yang biasanya dilakukan sebelum Anda memulai pengembangan, setelah Anda tahu persis apa yang perlu dibangun.
2. Dari pengalaman Anda, tolong beri saya umpan balik / saran tentang proses yang saya ikuti saat ini.

Klien yang bekerja dengan saya umumnya adalah pemula dan memiliki anggaran terbatas sehingga saya tidak dapat membebankan biaya pada mereka per / jam (saya pikir itu adalah bagaimana perusahaan besar biasanya menagih klien mereka [pada pria / jam] untuk proyek pengembangan) dan harus bekerja dengan anggaran tetap.

Ini adalah proses yang saya ikuti saat ini:
1. Mengukur ruang lingkup proyek dan mencoba memahami apa yang mereka coba capai dalam beberapa pertemuan.
2. Beri mereka gambaran kasar di taman dengan kutipan yang menjelaskan secara umum apa yang mereka harapkan dari proyek, saya mencoba untuk lebih spesifik tentang fitur, tapi, saya tidak terlalu banyak menghabiskan waktu karena ini saya tahu klien mungkin hanya meminta tanda kutip, dan tidak benar-benar mengkonversi.
3. Saya mengikuti saran Jeff Atwood untuk pembayaran & pekerjaan:

Pembayaran 15% - Dimuka sebelum memulai pekerjaan apa pun
Selama fase ini mockup HTML situs web akhir dibuat, diagram alur (dengan yEd ) yang menjelaskan situs web sedetail mungkin dan dokumen yang menyebutkan fitur lain yang tidak ada dalam bagan alur . Ini dilakukan dengan masuk ke semua detail proyek dan menyelesaikan bit yang akan cocok dan hal-hal yang terlalu banyak pekerjaan untuk diterapkan untuk harga yang disepakati. Karena spesifik tidak dibahas sebelumnya, sebagian dari ini juga lebih atau kurang merupakan negosiasi tentang apa yang sebenarnya akan mereka dapatkan. Karena ini adalah proyek anggaran tetap, harus ada persyaratan tetap, jika tidak, harga saya terus turun karena lebih banyak fitur ditambahkan.
Skema warna, desain wireframe desain dan desain PSD juga diselesaikan.

Pembayaran 35% - Mulai Pengembangan
Proyek sudah pasti, mulai pengembangan. Saya meng-host situs di server saya, di mana klien dapat mengakses front-end, tetapi, tidak memiliki akses ke kode apa pun.

Pembayaran 30% - Alihkan kode ke server klien / berikan klien detail akses server
Jadikan situs tersebut hidup.

Pembayaran 20% - Beberapa minggu setelah situs ditayangkan, setelah semua bug diperbaiki.


Pertanyaan:
1. Setelah Anda tahu persis apa yang akan Anda bangun, perencanaan seperti apa yang akan Anda lakukan sebelum mulai membuat kode?

2. Dari pengalaman Anda, bagian mana dari keseluruhan proses yang akan Anda lakukan secara berbeda?


Sayangnya banyak klien tidak pernah mencapai titik untuk mengetahui dengan tepat apa yang mereka ingin Anda bangun. Pendekatan terbaik yang saya temukan adalah dengan melakukan maket dari beberapa halaman penting dan kemudian duduk dan mulai menceritakan Kisah Pengguna. Saya sengaja membuat beberapa kisah yang jelas keliru untuk memaksa klien mengatakan, "Tidak, saya ingin itu bekerja dengan cara ini ..." Ini akhirnya membawa kami ke sesuatu yang mendekati spesifikasi proyek, tetapi akhirnya berubah pada akhirnya. Mendesah.
Peter Rowell

@ Peter, dengan sengaja memperkenalkan cerita pengguna palsu kadang-kadang bisa menjadi bumerang bagi Anda dan menyebabkan klien kehilangan kepercayaan pada Anda. Teknik itu harus digunakan dengan hati-hati.
maple_shaft

@maple_shaft: Saya menyadari itu. Ketika saya mengatakan 'jelas salah,' maksud saya sangat terang-terangan Bogus® sehingga saya biasanya mendapatkan lebih dari beberapa tawa. Mendapatkan klien untuk diinvestasikan penuh di situs web mereka (visi / waktu / uang) sangat penting untuk proyek yang sukses. Sungguh mengejutkan (setidaknya bagi saya) berapa banyak orang berpikir bahwa sebuah situs baru adalah sesuatu yang dapat mereka tangani dan akan muncul secara ajaib.
Peter Rowell

Saya setuju tentang maket juga, tidak ada jumlah teks tertulis yang akan membuat klien memahami apa yang akan mereka dapatkan (kebanyakan tidak dapat memahaminya atau peduli untuk memahaminya) - maket akan membuat segalanya menjadi jelas bagi klien, juga beberapa dokumentasi (spec) + kontrak atau sesuatu yang mengatakan: "Anda akan mendapatkan semua ini, dan tepat ini, tidak lebih" membantu. Sementara pengembangan, saya pikir mungkin ada beberapa fleksibilitas untuk mengubah hal-hal di sekitar, tetapi jika ada sesuatu yang muncul sebagai lebih banyak pekerjaan daripada yang Anda perhitungkan, saya pikir tiruan dan dokumen spesifik perlu ditarik keluar dan pekerjaan tambahan berarti biaya tambahan juga.
DMin

Jawaban:


10

Poin bagus untuk diskusi!

Untuk memenuhi syarat - Saya bekerja di proyek pengembangan web BESAR di industri pertahanan. Kami umumnya memiliki tim 10-40 orang yang mendukung satu pelanggan, memproyeksikan tahun terakhir, dan pelanggan memiliki uang dan tuntutan tinggi. Jadi jarak tempuh dapat bervariasi - Anda tidak ingin berlebihan!

1 Setelah Anda tahu persis apa yang akan Anda bangun, perencanaan seperti apa yang akan Anda lakukan sebelum mulai membuat kode?

Ini setelah bagian 15%, pada awal 35%, kan?

  • Tentukan server dan bahasa web target
  • Tentukan penyimpanan data - XML, Database, basis data yang mana?
  • Tentukan API utama - ketekunan data, GUI, logging, injeksi ketergantungan, dll.
  • Tentukan mekanisme login - dengan memperhatikan risiko dan informasi yang Anda coba lindungi. Mungkin termasuk mekanisme pembayaran.
  • Rencanakan arsitektur tingkat tinggi dan konvensi penamaan
  • Pilih urutan peluncuran fitur, sehingga Anda tahu tempat yang bagus untuk memulai
  • Tentukan strategi pengujian dan tahap kerangka kerja pengujian otomatis jika berlaku
  • Atur sistem CM

2 Dari pengalaman Anda, bagian mana dari keseluruhan proses yang akan Anda lakukan secara berbeda?

Saya tidak akan merencanakan. Saya akan memfokuskan pekerjaan perencanaan saya pada menyelesaikan sesuatu - seperti membangun lingkungan, server, testbed, CM - dan hanya menghabiskan sedikit waktu merencanakan arsitektur, memilih alat, dan memutuskan di mana untuk memulai. Saya merasa seperti apa pun, tahap perencanaan amorf selalu melibatkan lebih banyak waktu berkeliaran di padang pasir ketidaktahuan daripada seharusnya.

Jika Anda berurusan dengan biaya tetap dan pelanggan yang tidak membuat tuntutan teknis (seperti bahasa atau API apa yang Anda gunakan), saya akan merencanakan dalam 1 item yang selalu menjadi dorongan bagi Anda, secara teknis. Hanya 1 dan tetap sisanya sama. Saya pikir pada setiap proyek, Anda ingin memperluas keterampilan Anda, tetapi Anda tidak ingin menjadi begitu liar sehingga Anda tidak mengerjakan apa pun yang Anda ketahui atau pahami dengan baik.


2

Saran terbesar saya kepada Anda adalah sangat berhati-hati dengan pekerjaan pengembangan harga tetap. Jika Anda tidak memahami persyaratan sebelum pekerjaan dimulai maka satu dari dua hal bisa terjadi.

  1. Estimasi pada ruang lingkup ternyata undershot dan Anda kehilangan baju Anda.
  2. Pelanggan tidak atau tidak bisa mengetahui semua ruang lingkup sebelum Anda mulai membuat mereka tidak puas dengan hasil akhirnya.

Bagi Anda, nomor 2 adalah situasi yang lebih baik karena jika mereka keluar dari ruang lingkup dan kemudian berubah pikiran, Anda dapat melakukan negosiasi ulang untuk mendapatkan lebih banyak uang. Pastikan bahwa ANDA memahami ruang lingkup sebelum Anda memperkirakan, dan bahwa mereka memahami ruang lingkup dan apa yang akan Anda berikan.

Pastikan bahwa mereka menandatangani di ruang lingkup! Perusahaan yang menuntut harga tetap dan menolak untuk keluar dari ruang lingkup adalah KLIEN YANG BURUK dan Anda tidak ingin membuang waktu dengan itu. Kamu akan selalu kalah.

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.