Anda Membutuhkan Pahlawan: Manajer Proyek

Artikel ini untuk Anda, pengusaha pemberani dengan ide aplikasi di hati Anda dan sedikit uang di bank. Diagram yang Anda tulis di serbet koktail akan mengganggu seluruh dunia, dan truk sampah penuh uang telah dikirim ke rumah Anda. Untuk memastikan bahwa mereka tiba tepat waktu, berikut adalah beberapa saran sederhana untuk membuat siklus produksi Anda berjalan dengan lancar.

Mengapa Anda Membutuhkan Manajer Proyek?

“Program komputer adalah hal paling kompleks yang dibuat manusia,” kata Douglas Crockford. Anda mungkin belum pernah mendengar nama itu sebelumnya, tetapi dia cukup terkenal untuk seorang programmer. Saat ini dia adalah arsitek perangkat lunak senior di PayPal, dan dia telah memelopori segala macam teknologi keren yang berada di luar cakupan artikel ini. Dia adalah seseorang yang tahu banyak tentang mengerjakan proyek-proyek besar.

Untuk saya sendiri, saya telah memprogram selama 13 tahun, dan bahkan sekarang, pada titik tertentu, setiap proyek membawa saya ke wilayah yang belum dipetakan. Ada begitu banyak teknologi yang berbeda di luar sana, dan teknik-teknik baru sedang dirancang pada tingkat yang mengkhawatirkan sehingga saya tidak pernah merasa bahwa saya benar-benar di atas apa yang sedang terjadi. Sementara setiap proyek memiliki tantangan yang unik, ada beberapa konstanta:

• Proyek ini memiliki tekanan waktu.
• Anggaran lebih kecil dari yang saya inginkan.
• Saya lebih mahal daripada yang diinginkan klien.
• Saya tidak mendengarkan sesempurna yang diinginkan klien.
• Klien tidak menjelaskan hal-hal sesempurna yang saya inginkan.

Jelas, kita membutuhkan babysitter. Seseorang harus turun tangan untuk menetapkan aturan dasar, menjaga semua orang jujur, dan memastikan bahwa kita tidak melupakan sesuatu yang penting. Seseorang harus memfasilitasi komunikasi antara semua pihak.

Seseorang ini, pahlawan ini, adalah manajer proyek.

Toptal tidak menawarkan kontrak dengan manajer proyek ketika saya mulai menulis artikel ini, tetapi mereka melakukannya sekarang. Sinergi! Saya hanya bisa membayangkan bahwa kekuatan yang membaca nasihat berikut dan menyadari bahwa mereka kehilangan kesempatan besar.

Mengapa Seorang Programmer Tidak Menjadi Manajer Proyek yang Baik

Selain sertifikasi oleh Institut Manajemen Proyek, hal terpenting yang dapat dibawa oleh seorang manajer proyek ke meja adalah pengalaman. Akibatnya, banyak programmer akan menjadi manajer proyek yang cukup baik; kami memiliki lebih banyak pengalaman dengan proyek teknis daripada orang lain dan pikiran analitis kami mahir dalam membuat katalog informasi dan menetapkan tujuan yang konkret.

Astaga, Anda membayar kami cukup, jadi tampaknya masuk akal untuk berharap bahwa kami dapat mengatur diri kami sendiri daripada memaksa Anda untuk membayar waktu orang lain juga, bukan?

Sebagai permulaan, Anda membayar kami untuk membuat kode.

Ketika kami keluar dari kebingungan pemrograman kami untuk membuat keputusan tentang apa yang harus diprioritaskan, atau untuk berdebat tentang berapa banyak yang sebenarnya akan diselesaikan minggu ini, kode tidak sedang ditulis. Kemudian dibutuhkan setidaknya 10 menit untuk kembali ke "zona", terutama jika kita stres oleh percakapan yang baru saja kita lakukan, yang mungkin terjadi jika kita memperdebatkan prioritas fitur. Boo hoo, saya tahu, tapi ini semua tentang memanfaatkan sumber daya yang mahal secara efisien.

Yang terpenting, kami benar-benar tidak bisa melihat hutan untuk pepohonan. Jika Anda tidak mengambil hal lain dari artikel ini, harap pahami ini: Ketika saya menghabiskan sepanjang hari menatap beberapa serangga tertentu, otak saya kehilangan gambaran yang lebih besar.

Otak saya memberi penghargaan ketika saya memperbaiki bug itu, dan saya berasumsi bahwa saya telah melakukan hal-hal hebat dan bisa bermain video game sekarang. Ketika seseorang mengingatkan saya bahwa beranda masih rusak, itu benar-benar mengejutkan karena saya telah menghabiskan hari mengisi otak saya dengan pengetahuan yang sangat rinci tentang bagian yang sangat kecil dari keseluruhan proyek dan agak melupakan sisanya. Begitulah cara kerja otak saya, dan banyak programmer lain memiliki susunan psikologis yang serupa.

Mengapa Klien Tidak Menjadi Manajer Proyek yang Baik

Kalau begitu, jika kita programmer tidak ingin mengambil tanggung jawab untuk menyelesaikan hal-hal manajerial proyek, maka itu harus jatuh ke tangan Anda, klien. Ini uangmu. Ini adalah visi Anda. Bagaimanapun, Anda pada akhirnya bertanggung jawab atas semuanya.

Anda, bagaimanapun, juga memiliki banyak hal di piring Anda.

Banyak klien hanyalah manusia biasa dengan pekerjaan sehari-hari seperti kita semua, dan beberapa bahkan diketahui menderita penundaan atau pelupa. Meskipun ini tidak selalu menggambarkan Anda, secara khusus, harap pertimbangkan gagasan untuk memiliki Pengingat Profesional sehingga Anda dapat kembali ke pekerjaan penting untuk menjaga seluruh proyek tetap hidup.

Jika Anda telah mengerjakan, atau mengawasi, proyek teknis dengan cakupan serupa, Anda mungkin memang menjadi manajer yang baik untuk proyek Anda. Jika belum, tolong jangan meremehkan nilai seseorang yang bisa memprediksi masalah yang mungkin muncul. Perkiraan waktu selalu hanya perkiraan, dan bug cenderung muncul pada waktu yang paling tidak tepat. Ini sepadan dengan biaya karyawan lain (jika hanya paruh waktu) untuk memiliki seseorang di sekitar yang tahu bagian mana dari proses yang membutuhkan, atau kemungkinan besar membutuhkan, perhatian paling besar.

Ambil jaminan kualitas (QA), misalnya. QA yang tepat sangat penting untuk mendapatkan apa yang Anda inginkan dari proyek apa pun, dan itu tidak pernah mendapat perhatian yang layak. Manajer proyek yang baik akan memanfaatkan sumber daya QA yang terbatas dan juga akan menjamin kualitas pemrogram Anda untuk Anda. Terkadang, kita keluar dari kedalaman kita, dan terkadang kita membuat kesalahan. Anda memerlukan orang yang ahli secara teknis dalam peran pengawasan untuk menentukan apakah programmer Anda hanya sedang libur, atau apakah dia, pada kenyataannya, tidak cocok untuk proyek tersebut. Mengatasi masalah personel lebih awal dapat berarti perbedaan antara hidup dan mati untuk proyek Anda.

Terakhir, bahkan Anda, klien, terkadang membutuhkan sedikit cek dan/atau keseimbangan. Itu sulit bagi saya untuk menulis karena kami programmer komputer tidak terkenal dengan sifat vokal kami. Cukuplah untuk mengatakan, saya telah mengerjakan banyak proyek di mana klien bersikeras bahwa semuanya adalah prioritas utama dan benar-benar segala sesuatu yang diperlukan untuk diselesaikan. Meskipun saya tidak ragu bahwa ini sepenuhnya benar, sayangnya, klien-klien ini tidak memiliki kendali atas jumlah jam dalam sehari. Mereka tidak berakhir dengan hasil positif yang mereka inginkan dan/atau pantas dapatkan, dan saya merasa bahwa hasil ini dapat dihindari jika klien mempercayakan manajer proyek wewenang untuk menilai beban kerja dan dengan bijaksana, namun tegas, menjaga segala sesuatunya tetap terkendali. . Sulit untuk membuat panggilan penilaian yang tidak memihak yang dibutuhkan sebagian besar proyek teknis ketika ide Anda dan uang Anda dipertaruhkan dan komputer tidak peduli jika Anda atau saya menangis dan berteriak karenanya. (Saya tahu ini benar karena saya sudah mencobanya berkali-kali.)

Daftar Teknik yang Tidak Lengkap untuk Mengelola Proyek Teknis

Apakah Anda telah memutuskan untuk mengabaikan kata 1000-an sebelumnya dan mengelola proyek Anda sendiri, atau apakah Anda akan mempekerjakan seseorang tetapi ingin lebih mengetahui prosesnya, daftar ini akan membantu Anda. Saya tidak pernah (secara resmi) menjadi manajer proyek, jadi saya tidak bisa mengatakan alat mana yang akan digunakan oleh manajer proyek tertentu, tetapi saya telah sukses dengan semua teknik ini:

Tonggak sejarah

Saat memulai proyek baru, kebanyakan orang secara intuitif tahu bahwa penting untuk membagi proyek menjadi bagian-bagian yang sedikit lebih mudah dikelola, dengan masing-masing bagian mulai dari pekerjaan beberapa minggu hingga beberapa bulan. Di awal proyek, ada baiknya mengadakan pertemuan awal untuk menetapkan tonggak-tonggak ini. Tidak apa-apa untuk sedikit samar tentang bagaimana Anda akan menjangkau mereka, yang paling penting adalah untuk terus memeriksa setelah setiap tonggak sehingga mendapat manfaat dari peningkatan pemahaman semua orang tentang proyek, dan untuk memastikan bahwa tonggak proyek masih ( kira-kira) ukuran yang sama seperti yang awalnya diyakini.

Perkiraan Waktu

Kami pemrogram benar-benar membenci perkiraan karena kami tahu itu akan salah dan kami tahu itu akan digunakan untuk melawan kami. Tidak apa-apa bahwa mereka salah karena, menurut definisi, mereka didasarkan pada beberapa hal yang tidak diketahui. Tidak apa-apa juga jika mereka digunakan untuk melawan kita karena pekerjaan kita cukup nyaman dan tidak ada salahnya jika cambuk itu retak sesekali.

Jadi jangan ragu untuk meminta perkiraan setiap kali pekerjaan dimulai pada tonggak baru. Anda harus mengharapkan satu atau dua baris untuk setiap fitur utama bersama dengan perkiraan kasar berapa lama fitur itu akan berlangsung. Saya biasanya membuat perkiraan optimis, lalu menggandakannya. Lebih sering daripada tidak, waktu ekstra ini menyebabkan jebakan yang tak terlihat.

Cerita Pengguna

Cerita pengguna adalah deskripsi singkat dari satu fungsi dalam aplikasi. Mereka berguna sebagai catatan fitur penting dan harus berukuran kecil, dapat ditampung pada kartu indeks dan sering disertai dengan gambar kecil. Lebih penting lagi, mereka berfungsi sebagai jembatan antara apa yang diinginkan klien dan apa yang harus dikatakan programmer kepada komputer. Mereka cukup sederhana untuk Anda, klien, untuk melumpuhkan dalam beberapa menit, tetapi cukup rinci bagi kita, para programmer, untuk tenggelam gigi kita.

Untuk beberapa info singkat tentang cerita pengguna, saya menemukan tutorial ini oleh Mountain Goat Software dan Roman Pichler berkualitas tinggi dan ringkas. Untuk informasi lebih lanjut tentang seluruh filosofi manajemen proyek tangkas, coba posting blog Toptal ini The Ultimate Introduction to Agile Project Management oleh Paul Barnes.

Komposisi (Mockup)

Ini bukan artikel tentang mengapa Anda membutuhkan seorang desainer karena saya merasa sebagian besar klien sudah memahaminya, tetapi ini perlu diulang karena Anda akan melihat peningkatan produktivitas yang sangat besar jika Anda menerapkan desain yang konkret dan dipertimbangkan dengan baik di depan programmer Anda. Setiap kali kita harus membuat keputusan desain, kita harus meninggalkan "zona", dan setiap kali kita harus kembali dan mengubah sesuatu karena kita tidak diberikan draf akhir, nah, Anda yang menghitungnya... I' Saya tidak mengeluh, karena desain itu menyenangkan, tetapi menurut pengalaman saya, ini adalah sumber No. 1 dari jam tambahan yang dapat ditagih dan dapat dihindari.

Kebanyakan desainer menyediakan komposisi, juga dikenal sebagai comps, dalam Adobe Photoshop, Adobe Illustrator, atau Sketch. Jika Anda melakukannya sendiri, Anda dapat menggunakan salah satu alat online yang tak terhitung jumlahnya seperti Balsamiq atau InVision. Komp tidak harus memiliki warna dan gaya yang sama dengan produk jadi (karena ini dapat dengan mudah diubah nanti), tetapi harap luangkan waktu ekstra untuk memastikan bahwa semua elemen UI ada dan diperhitungkan.

Rapat Berdiri

Rapat panjang terkadang tidak dapat dihindari, tetapi Anda benar-benar tidak ingin membebani programmer Anda atau menghabiskan lebih banyak waktu daripada yang diperlukan. Saya memiliki klien yang sepertinya mengharapkan saya untuk mengingat semua yang dikatakan selama pertemuan dua setengah jam; mereka sangat kecewa. Rapat stand-up umumnya dibatasi hingga 15 menit, dan merupakan kebiasaan untuk berdiri selama durasi tersebut. Aspek berdiri seharusnya memastikan bahwa semua orang berpartisipasi, serta menjaga pertemuan tetap singkat.

Selama stand-up, semua orang berkeliling dalam lingkaran untuk memberikan laporan status singkat, menjaga agar semua anggota tim mengetahui kemajuan satu sama lain. Anda dapat menemukan lebih banyak tentang stand-up di ExtremeProgramming.Org. Jika Anda semua bekerja dari jarak jauh dan tidak ingin semua orang menggunakan Skype setiap hari, Anda dapat mencoba alat yang menyenangkan seperti 15Five sebagai alternatif untuk stand-up. 15Five memungkinkan anggota tim memberikan masukan kapan pun mereka merasa nyaman, dan itu akan mendorong mereka dengan pertanyaan survei untuk memberikan tanggapan yang lebih mendalam.

Sistem Tiket

Meskipun siapa pun dapat memelihara sistem catatan tempel dan Google Documents (dengan tugas setiap orang disorot dalam warna berbeda), itu sebenarnya tidak perlu; banyak orang telah mencoba untuk memecahkan masalah ini untuk Anda. Basecamp dan Trello terkenal karena kemudahan penggunaannya, sementara Pivotal mencoba merangkum seluruh filosofi "gesit" ke dalam paket yang sangat apik. Apa pun pilihan Anda, sistem tiket yang baik akan memungkinkan Anda, minimal, untuk:

• Buat tugas
• Tetapkan prioritas dan tanggal jatuh tempo
• Tautkan tugas dan subtugas
• Tetapkan resolusi yang berbeda seperti "selesai" atau "pengujian gagal"
• Tampilkan semua tugas yang diberikan kepada pengguna tertentu

Ketika seorang manajer proyek menunjukkan kepada Anda 40 tiket prioritas teratas berwarna merah cerah yang semuanya jatuh tempo pada hari yang sama, Anda akan benar-benar memahami nilai dari pandangan luas proyek ini.

Kontrol Sumber

Anda bahkan mungkin tidak pernah melihat kode dalam sistem kontrol versi proyek Anda, tetapi kontrol sumber (atau pembuatan versi) adalah salah satu alat terpenting yang kami miliki, sistem cadangan terbesar yang dapat dibayangkan.

Sebagian besar proyek modern menggunakan Git, meskipun terkadang Anda akan mengalami Subversion (SVN) saat mengerjakan proyek yang sudah ada selama beberapa waktu. Github memungkinkan Anda untuk meng-host repositori publik tanpa batas secara gratis (ditambah, ini berisi sebagian besar proyek sumber terbuka dunia), sementara Bitbucket memungkinkan Anda untuk meng-host repositori pribadi tanpa batas dan oleh karena itu merupakan pilihan yang disukai untuk proyek komersial.

Sistem kontrol versi mana pun yang Anda pilih, ia menyimpan kode kami dari jarak jauh jika terjadi sesuatu, ditambah melacak setiap kali kami "melakukan" kode padanya sambil memaksa kami untuk menulis pesan kecil yang menjelaskan apa yang sedang kami kerjakan. Ini mencegah pengembang yang berbeda untuk saling menimpa kode satu sama lain, ini memungkinkan kita melihat semua perubahan yang dibuat selama periode waktu tertentu, dan memungkinkan kita membuat cabang kode baru untuk menyimpan fitur yang tidak langsung ditayangkan. Ia bahkan memiliki perintah yang disebut "menyalahkan" yang menunjukkan siapa yang bertanggung jawab atas baris kode tertentu, dan kapan itu dilakukan.

Kontrol sumber adalah yang terbesar.

Pengembangan Berbasis Tes

Ini adalah praktik yang relatif mahal, yang berarti tidak sering digunakan dalam proyek yang anggarannya terbatas untuk beberapa pekerja lepas. Jadi Anda, sebagai wirausahawan pemula, tidak perlu merasa sedih karena tidak melakukan ini, tetapi saya harus menggantungkan ide di depan Anda karena ini memberikan pertahanan terbaik terhadap bug. Pada dasarnya, pemrogram Anda menghabiskan waktu ekstra untuk menulis tes (blok kode kecil) yang memastikan bagian tertentu dari aplikasi berperilaku dengan cara yang spesifik, dapat diprediksi, dan dapat diulang. Misalnya, saya mungkin menulis tes yang menyatakan bahwa ketika tombol "login" diklik, sebuah popup terbuka dengan bidang nama pengguna di dalamnya.

Keindahan tes adalah setelah saya menulisnya, saya dapat menjalankan semuanya dengan satu perintah. Jika saya memiliki 200 tes yang ditulis, saya dapat menjalankannya setelah merilis versi baru aplikasi untuk memastikan tidak ada bug yang dimasukkan ke dalam 200 fitur tersebut. Ini tidak sempurna, tetapi sedekat yang kami bisa untuk menjamin aplikasi bebas bug (setidaknya bug-lite).

Bungkus

Itu saja yang saya ketahui tentang manajemen proyek. Saya tidak yakin berapa banyak dari ini yang akan dikumpulkan di Project Management Institute, tetapi itu semua adalah hal yang saya ambil dengan mengerjakan proyek web selama dekade terakhir. Tentu saja, saya menyarankan Anda mempekerjakan seseorang untuk mendapatkan manfaat dari pengalamannya, tetapi saya harap informasi ini bermanfaat bagi Anda meskipun itu bukan sesuatu yang dapat Anda lakukan. Anda akan menjadi otoritas tertinggi dalam proyek ini, jadi semakin Anda memahami tentang cara kerja bagian dalamnya, semakin besar kemungkinan Anda untuk memimpinnya menuju kemenangan.