Bagus sepanjang waktu. Sekarang giliran berbicara tentang merancang proyek. Dari pengalaman saya sendiri, saya tahu kadang-kadang lebih sulit membuat proyek dari awal daripada merapikan apa yang sudah ada. Ini sebagian besar disebabkan oleh warisan yang Anda atau Anda tinggalkan. Dalam artikel ini saya akan mencoba memberi tahu Anda apa yang perlu diperhatikan dan menyarankan rencana singkat untuk diikuti.
Memahami proyek
Sebelum Anda merencanakan sesuatu, Anda perlu memahami proyek apa yang perlu Anda implementasikan. Bagi saya sendiri, saya telah mengidentifikasi beberapa kategori proyek, seperti:
- Kerajinan satu kali adalah proyek yang bertujuan menciptakan semacam konsep grafis dan penjualan lebih lanjut kepada investor. Fitur khas dari jenis proyek ini adalah:
- Dokumentasi gila. Ide dasarnya jelas, tetapi kasus bisnis benar-benar kacau, dan tidak ada lubang logis untuk dipertimbangkan.
- Tenggat waktu. Hingga 3 bulan dari menulis dokumentasi hingga prototipe.
- Tidak ada rencana pengembangan dan tidak ada dukungan lebih lanjut yang direncanakan.
- Tim kecil. Biasanya hingga 5 orang, termasuk desainer.
- Kurangnya proses bisnis. Semua interaksi kacau, berdasarkan komunikasi antarpribadi, klarifikasi poin-poin utama dan / atau penemuan saat bepergian.
- Peran tidak jelas. Tidak ada pembagian kekuasaan dan bidang tanggung jawab yang jelas.
- Tidak ada data nyata. Semua data dihasilkan untuk "keindahan" dan dirancang untuk tampilan terbaik.
- Untuk mempercepat pengembangan, dependensi eksternal digunakan secara penuh.
- Startup adalah proyek yang dikonfigurasi untuk mengimplementasikan ide tertentu, dengan pengembangan selanjutnya. Biasanya, proyek-proyek ini dikembangkan sesuai dengan model spiral dan, untuk alasan ini, memiliki fitur khas yang hampir sama dengan jenis pertama (kerajinan satu kali):
- Hapus pengelompokan menjadi beberapa tahap. Minimum: istilah dan daftar fungsi yang harus diterapkan dalam periode waktu tertentu.
- Dokumentasi yang relatif waras. Analisis dilakukan, tolok ukur untuk tahap penyelesaian yang ditetapkan, perbaikan sering terjadi selama sprint. Paling sering menggunakan air terjun, meskipun fakta bahwa Agile mengklaim.
- Tenggat waktu rata-rata untuk fungsi utama. Rata-rata, dari 6 hingga 12 bulan.
- Pada tahap awal, dependensi eksternal digunakan, yang akhirnya berubah menjadi implementasinya sendiri.
- Tim kecil. Biasanya hingga 7-10 orang.
- Ada pemisahan peran, tetapi tanggung jawab kabur.
- Sebuah proyek dapat bermutasi. Pada satu tahap, konsep atau pendekatan implementasi dapat berubah. Biasanya ini karena persyaratan dari investor, ide yang awalnya gagal atau kesalahan dalam arsitektur.
- Data langsung bersyarat. Berjalan dalam grup fokus atau mem-parsing data langsung dari sumber daya pihak ketiga. Benar, ini tidak selalu terjadi ...
- Sistem informasi adalah proyek yang mengimplementasikan ide dengan rencana integrasi ke dalam layanan pihak ketiga.
- Ada rencana pengembangan.
- Dokumentasi yang ditulis dengan jelas. Minimum: Deskripsi API didokumentasikan.
- Anda mungkin perlu berintegrasi dengan layanan pihak ketiga, memasang kruk, atau membangun kembali bagian-bagian sistem.
- Ada rilis menengah, perbaikan panas.
- Tim menengah. Biasanya dari 10 hingga 20-30 orang.
- Pemisahan tanggung jawab yang jelas.
- Persyaratan keamanan: setelah analisis, kasus dibuat yang dapat menyebabkan runtuhnya sistem.
- Waktu dikhususkan untuk pengujian.
- Digunakan oleh Agile.
- Hampir selalu ada jaminan simpanan.
- Hanya dependensi eksternal yang mahal untuk diterapkan sendiri yang digunakan. Ini dipraktikkan setara dengan yang berpemilik.
- Sistem tertutup adalah proyek produktif yang dirancang untuk melayani kebutuhan spesifik Pelanggan, dengan penyempurnaan lebih lanjut.
- Pelanggan spesifik.
- Ada rencana pengembangan.
- Dokumentasi desain untuk pengembangan. Untuk membantu pengguna, dokumentasi terpisah telah ditulis atas permintaan Pelanggan.
- Diferensiasi hak pengguna.
- Hampir selalu ada jaminan simpanan.
- Ukuran tim biasanya lebih besar dari rata-rata. Sebagai aturan, dari 10 orang hingga kehilangan denyut jantung.
- Digunakan oleh Agile. Dari waktu ke waktu, tugas tambahan tiba yang harus dilaksanakan dengan segala cara.
- Demonstrasi yang tidak terduga. Permintaan terjadi atas permintaan manajemen senior, sehingga rangkaian uji yang dapat diterapkan tidak akan pernah mubazir.
- Solusi Saas adalah proyek produktif dengan konfigurasi yang fleksibel dan kustomisasi lebih lanjut untuk pelanggan tertentu.
- Sistem multimodular. Sistem ini dibagi menjadi beberapa bagian. Yang dapat digunakan secara individual, bahkan di luar ruang lingkup proyek tertentu.
- Perencanaan yang jelas. Minimum: biaya tenaga kerja diperkirakan untuk penerapan fitur. Waktu diletakkan untuk modernisasi dan refactoring.
- Dokumentasi volumetrik. Hampir semuanya dijelaskan, sebagai suatu peraturan, termasuk kasus-kasus uji.
- Sebagai aturan, tidak ada dependensi eksternal dan implementasi bagian sistem mereka sendiri ditulis. Bahkan jika ada implementasi pihak ketiga.
- Beberapa tim pengembangan. Setiap orang bertanggung jawab atas bagian mereka dalam pengembangan, baik itu dukungan atau front.
- Uji cakupan segalanya dan segalanya. Tes otomatis, unit, regresi, dan integrasi digunakan.
Semua gradasi adalah tipe bersyarat dan mengalir yang paling sering ditemukan. Saya ingin mencatat bahwa semua jenis dapat bermutasi satu sama lain, satu-satunya nuansa adalah dalam biaya modernisasi. Misalnya, proyek ini awalnya merupakan "kerajinan satu kali", dan kemudian berkembang menjadi "sistem tertutup". Biasanya, ini mengarah pada penulisan ulang sistem yang lengkap atau hampir lengkap atau refactoring-nya. Seperti yang Anda tahu, ini tidak layak secara ekonomi. Untuk alasan yang sama, disarankan untuk memahami jenis proyek apa yang perlu Anda buat dari awal, dan mencoba menentukan nasibnya di masa depan.
Untuk menentukan jenis proyek, di bawah ini saya telah memberikan pertanyaan, setelah menerima jawaban yang akan jelas bagi Anda apa yang mereka inginkan dari Anda:
- Tujuan proyek?
- Daftar lengkap apa yang perlu diimplementasikan?
- Apakah ada dokumentasi?
- Apa tenggat waktunya? Tanggal yang akurat diinginkan.
- Apakah interaksi eksternal direncanakan dengan sistem pihak ketiga, atau akankah proyek memiliki API eksternal
- Apakah ada perkembangan?
- Ukuran tim?
- Siapa yang bertanggung jawab atas apa? Siapa yang menetapkan tugas, siapa yang menerima, siapa yang memiliki hak veto.
- Adakah rencana pengembangan dan apakah itu?
- Siapa pelanggannya
- Apakah ada anggaran untuk pembelian solusi turnkey?
- Metodologi apa yang Anda rencanakan untuk dikerjakan
- Apakah ada analog?
Seperti yang Anda lihat, daftarnya tidak terlalu besar. Namun, untuk beberapa alasan yang tidak diketahui, beberapa orang mengajukan pertanyaan seperti itu sebelum mulai melakukan sesuatu. Anda bertanya mengapa saya harus memahami jenis proyek ?! Anda selalu harus membuat proyek hidup selamanya?! Pada umumnya, Anda benar, tetapi ada nuansa, seperti dalam lelucon yang beruap. Nuansa ini adalah sumber daya dan jadwal. Jangan lupa bahwa kami bekerja untuk kebaikan bisnis dan menjalankan tugas. Ketika Anda mengetahui jenis proyeknya, Anda dapat mengorbankan sesuatu tanpa sedikitpun suara hati untuk mencapai tujuan Anda.
Pemilihan teknologi
Dalam pilihan itu lebih baik mematuhi aturan: teknologi tidak harus supernova, tetapi juga ketinggalan jaman. Jika teknologi atau kerangka kerjanya baru, ini dapat menyebabkan masalah seperti:
- Cari personil yang berkualitas
- Prospek untuk pengembangan: pada tahap awal, pengembangan mungkin mati, atau, sebaliknya, jika teknologi sudah tua, maka bug harus disembuhkan oleh diri kita sendiri.
- Kurangnya solusi turnkey untuk yang baru, dan kurangnya pembaruan untuk yang lama.
Daftar masalah ini relevan tidak hanya mengenai teknologi, tetapi juga dengan ketergantungan pihak ketiga. Semua hal di atas dapat mengubur proyek sejak awal.
Sebelum Anda memilih sesuatu yang spesifik, pikirkan beberapa kali. Buat tabel manfaat yang terkenal dengan faktor penting untuk proyek.
Contoh ini untuk proyek fiksi:
Nama fungsionalitas proyek.
| Rasio Pentingnya Proyek
|
|---|
Bekerja dengan formulir
| 3
|
Routing
| 1
|
Kemudahan menulis animasi
| 0,3
|
Seperti dapat dilihat dari tabel, kriteria penting untuk seleksi adalah "bekerja dengan bentuk" dan "routing". Kesederhanaan membuat animasi untuk proyek ini tidak signifikan. Selanjutnya, kami akan memutakhirkan tabel dengan menambahkan kolom teknologi baru. Dalam kasus kami, akan ada dua.
Nama fungsionalitas proyek.
| Rasio Pentingnya Proyek
| Teknologi 1
| Teknologi 2
|
|---|
Bekerja dengan formulir
| 3
| +
| ±
|
Routing
| 1
| +
| ±
|
Kemudahan menulis animasi
| 0,3
| +
| -
|
Berdasarkan data dalam tabel, kami memahami bahwa "Teknologi 2" bekerja dengan bentuk dan perutean yang lemah, dan membuat animasi seperti memanggil Setan. Akibatnya, berat spesifik dari teknologi ini adalah 2. Anda bertanya mengapa 2? Semuanya sederhana! Jika Anda menetapkan ±, maka dalam teknologi ini kami akan menerapkan fungsional tertentu, tetapi dengan semacam "tongkat penyangga", atau lebih padat karya. Dalam perbandingan kami, "Teknologi 1" akan lebih menguntungkan, dengan total 4,3. Saya pikir penjelasan tentang pembentukan jumlah tidak perlu. Tabel ini bekerja tidak hanya dengan teknologi, tetapi dengan segala sesuatu yang membutuhkan perbandingan dan pemilihan dari daftar. Hal utama adalah jangan lupa bahwa semakin banyak kriteria yang Anda tulis, semakin mudah bagi Anda untuk membuat pilihan.
Arsitektur
Saat ini, dimungkinkan untuk memilih dari berbagai layanan yang berbeda yang menyediakan alat untuk desain arsitektur. Benar, ada di antara mereka yang memiliki kelemahan, untuk beberapa mereka kritis, tetapi untuk seseorang yang tidak. Karena saya “orang tua”, saya lebih suka selembar kertas dan pena atau papan dan spidol.
Untuk memahami apa yang harus diambil di tempat pertama, Anda perlu menguraikan bagian utama sistem, dan kemudian memilih cara untuk membangun arsitektur. Sebagai aturan, dalam praktiknya, hanya tiga yang digunakan:
Turun - pengembang mendorong dari node besar sistem dan pergi ke yang lebih kecil. Arti arsitektur adalah bahwa komponen prioritas adalah node besar yang berisi yang lebih kecil.
Naik - pengembang mendorong dari bagian kecil dan pergi ke bagian yang lebih besar. Arti arsitektur adalah bahwa pada awalnya banyak komponen kecil dibuat, dan yang lebih besar sudah dikumpulkan dari mereka.
Monolith adalah arsitektur tak terpisahkan, sering disebut sebagai "warisan". Bahkan, ini adalah struktur yang kaku, perubahan yang membutuhkan solusi tanpa "tongkat penyangga". Ini adalah pilihan terburuk, tetapi, seperti semua yang ada di dunia kita, ini memiliki hak untuk hidup. Monolith digunakan untuk mengimplementasikan fungsi spesifik dan tidak berencana untuk memeliharanya di masa depan. Dibandingkan dengan yang lain, kecepatan pendekatan ini jauh lebih cepat. Ya, hanya karena Anda bisa menutup mata.
Pilihan arsitektur tergantung pada tujuan proyek dan kecepatan pengembangan. Biasanya, metode pertama digunakan ketika tenggat waktu tidak habis, dan jumlah modul besar kecil. Fiturnya adalah memungkinkan untuk secara akurat mewakili hubungan antara modul-modul tertentu. Dari minus, saya dapat mencatat waktu pengembangan yang panjang terkait dengan serangkaian tindakan.
Metode kedua lebih disukai ketika kecepatan pengembangan tinggi diperlukan dan tidak ada pemahaman tentang arsitektur tingkat atas. Fitur adalah banyak komponen kecil yang kadang-kadang digunakan dalam unit besar yang berbeda. Perlu dicatat bahwa hampir semua pengembangan dapat dilakukan secara paralel, tanpa memperhatikan tugas-tugas lain. Kerugian dari pendekatan ini adalah komponen yang tidak memenuhi persyaratan arsitektur tingkat atas dan, oleh karena itu, mereka harus ditulis ulang atau menciptakan kemungkinan penyesuaian.
Seperti yang ditunjukkan oleh praktik, semua teknik pengembangan direduksi menjadi pendekatan spiral, ditandai dengan peningkatan fungsionalitas secara bertahap. Saya tidak menganggap pantas untuk mempertimbangkannya dalam kerangka artikel ini.
Perencanaan
Yang disebut "Peta Jalan" akan membantu Anda melakukan pekerjaan Anda dengan lebih efisien. Bahkan, ini adalah jadwal, dengan tenggat waktu bersyarat untuk pengiriman fungsional tertentu. Tanggal dapat ditunda, tetapi, seperti yang ditunjukkan oleh praktik, dengan implementasi yang tepat dari poin-poin di atas, amandemen akan mencapai 30%. Dalam praktiknya, ini biasanya 10-15%. Perencanaan akan memungkinkan Anda untuk melacak kemajuan proyek, melihat kendur, melakukan penyesuaian dalam bentuk sumber daya atau perubahan tenggat waktu, dll.
Untuk itu nanti mereka akan berterima kasih
Setiap proyek dimulai dengan dokumentasi, dan semakin banyak, semakin baik! Jadi jangan malas - kami mendokumentasikan SEMUANYA. Ya, itu akan memakan waktu, tetapi selanjutnya dapat menyelamatkan Anda dari murka kepemimpinan jika ada yang salah, bukan salah Anda. Juga, jangan lupa bahwa setelah Anda muncul di proyek orang-orang yang harus memahami apa yang Anda buat. Dan tanpa dokumen, ini tidak akan mudah.
Kesimpulan
Artikel ini menjelaskan cara bertindak dan apa yang harus dicari ketika memulai proyek. Tahap-tahap ini bersifat universal untuk depan, belakang, pengujian atau semuanya bersama-sama. Saya sengaja menghindari spesifik teknologi, agar tidak menyesatkan.
Saat Anda memiliki pilihan tentang tumpukan teknologi yang akan digunakan, arsitektur, dan Anda perlu menentukan jangka waktu proyek, tabel di bawah ini dapat membantu Anda:
Jenis / Fitur Proyek
| Kerajinan sekali pakai
| Startup
| Sistem informasi
| Sistem tertutup
| Solusi Saas
| Beberapa proyek lain
|
|---|
Jumlah orang di bawah 5
| | X
| X
| X
| X
| |
Jumlah orang dari 7 hingga 10
| | | | | | |
Jumlah orang dari 10 hingga 30
| X
| | | | | |
Kuantitas lebih dari 30
| X
| X
| | | | |
Tanggal penyelesaian hingga 3 bulan
| | X
| X
| X
| X
| |
Periode pengiriman dari 6 hingga 12 bulan
| | | | | | |
Masa lebih dari 12 bulan
| X
| | | | | |
Dokumentasi
| | | | | | |
Persyaratan integrasi dengan sistem lain
| | | | | | |
Pelanggan spesifik dikenal
| | | | | | |
Dukungan selanjutnya direncanakan
| | | | | | |
Perencanaan
| | | | | | |
Peran jelas digambarkan
| | | | | | |
Ketergantungan eksternal diizinkan
| | | | | | |
Ada data langsung untuk pengujian dan analisis.
| | | | | | |
Persyaratan keamanan
| | | | | | |
Diperlukan pengujian
| | | | | | |
Membutuhkan dokumentasi atau instruksi produk
| | | | | | |
Diperlukan implementasi modular
| | | | | | |
Beberapa tim pengembangan
| | | | | | |
Total
| | | | | | |
Cara menggunakan tabel, saya pikir semua orang sudah menebak, tetapi untuk berjaga-jaga - persis sama dengan yang sebelumnya, hanya dengan tambahan kecil dalam bentuk sel yang diisi. Ini berarti bahwa nilai tidak dapat digunakan untuk proyek ini. Harap perhatikan juga bahwa tabel mungkin tidak lengkap, tambahkan baris yang Anda anggap perlu.