Bagaimana memimpin proyek pengembangan tanpa keahlian teknis


17

Saya telah menjadi pengembang langsung untuk seluruh karier dan suka bekerja dengan kode. Saya selalu membenci pemimpin tim yang memiliki sedikit atau tidak ada keahlian tentang teknologi tertentu dan bersikeras pada implementasi tertentu.

Sekarang saya menemukan diri saya di sisi lain dari kaca yang terlihat. Saya adalah pengembang utama dari klien besar yang akan diimplementasikan dalam C #, namun keahlian saya dalam membangun aplikasi web Java. Meskipun saya tahu bahwa saya dapat memanfaatkan pola desain dan paradigma OO dalam bahasa apa pun, saya bingung ketika berbicara tentang standar pengkodean, alat siklus hidup proyek dan prosedur rilis / distribusi. Saya tidak ragu bahwa saya dapat mengambil dasar-dasarnya dalam satu atau dua bulan, tetapi ada pengalaman tertentu yang hanya dapat dikumpulkan dengan waktu.

Apa yang harus saya lakukan, dan bagaimana saya menghindari menjadi pemimpin proyek yang saya benci ketika saya sedang berkembang?


12
untuk menghindari kebencian seperti itu, bicarakan saja dengan anggota tim Anda. Bicara secara teratur, sering berbicara, bicara 1: 1 "... Hadiahmu untuk budaya 1: 1 yang sehat adalah kurangnya drama."
nyamuk

1
Apa judul dan tanggung jawab Anda sebenarnya untuk promosi ini? Apakah Anda PM, Pengembang Senior, ...?
NoChance

Belajar dari yang terbaik ... youtube.com/watch?v=GjJCdCXFslY
jfrankcarr

1
Tapi serius, saya menulis seri artikel ini beberapa waktu lalu yang mungkin Anda temukan membantu: vbnotebookfor.net/2007/07/25/…
jfrankcarr

Jawaban:


19

Jujur, tidak masalah seberapa banyak pengalaman yang Anda miliki dengan teknologi, saran saya adalah sama: Jangan memaksakan keputusan teknologi pada mereka yang harus tinggal bersama mereka saat Anda sibuk mengelola.

Jujurlah pada dirimu sendiri. Saya berani bertaruh alasan Anda membenci para manajer sebelumnya itu bukan karena mereka tidak memiliki basis pengetahuan untuk membuat keputusan, itu karena mereka menegakkan keputusan dan tidak pernah berurusan dengan konsekuensinya.

Itu berlaku apakah Anda belum pernah menyentuh .NET sebelumnya atau Anda adalah pengembang paling ahli di tim. Tugas Anda sekarang adalah mengelola, bukan membuat keputusan teknis.

Mengelola mungkin, tergantung pada tingkat keahlian pengembang Anda, berarti menasihati mereka ketika mereka memintanya. "Apakah Anda sudah melihat ke Spring.NET?" (perhatikan kurangnya instruksi di sana) adalah hal yang sangat baik untuk dikatakan. Juga, "Google berkeliling, lihat apa yang dilakukan seluruh dunia, kami bukan yang pertama menghadapi masalah ini."

Dalam beberapa hal, sebagai pengembang Java yang berpengalaman, Anda mungkin berada dalam posisi yang lebih baik daripada kebanyakan untuk ini. Sebagian besar kerangka kerja Java dan teknologi memiliki analog yang setara dalam .NET. Jadi, Anda tidak perlu mengatakan "Ini yang terbaik untuk digunakan," Anda bisa mengatakan "Saya sudah menggunakan ini di Jawa, apakah Anda tahu tentang. NET yang setara?"

Juga dorong banyak percakapan dalam tim. Atur pertemuan diskusi teknis mingguan. Yang Anda butuhkan hanyalah informasi, pada akhirnya; Anda perlu tahu keputusan apa yang mereka buat dan mengapa. Anda tidak perlu membuat keputusan untuk tim.


2
Baik. Hal utama adalah bersedia membiarkan "bintang" teknis Anda membuat keputusan yang berbeda dari apa yang akan Anda buat. Jika Anda bisa melakukan itu maka semua orang (kecuali, tentu saja, manajemen atas) akan bahagia dan produktif.
Daniel R Hicks

'Jadi, Anda tidak perlu mengatakan, "Ini yang terbaik untuk digunakan," Anda bisa mengatakan, "Saya sudah menggunakan ini di Jawa, apakah Anda tahu tentang .NET yang setara?" Dalam kebanyakan kasus, jika alat yang setara ada, itu akan diawali dengan 'N', jadi Anda biasanya dapat menemukannya sendiri
Dan Neely

Perlu diingat, ia menandai dirinya sebagai "Pengembang Utama" dan bukan "Manajer Proyek". Dalam pengalaman saya, ini adalah dua hal yang sangat berbeda.
Wonko the Sane

@WonkotheSane: Memang benar bahwa OP merujuk pada Project Lead, Team Lead dan Lead Developer seolah-olah mereka semua adalah hal yang sama, dan itu membingungkan. Tapi saya mengambil isyarat dari konteks di mana mereka digunakan.
pdr

@ pdr - setuju, hampir. Bagian tentang "Saya dapat memanfaatkan pola desain dan paradigma OO" membuat saya sedikit heran.
Wonko the Sane

6

Saya memiliki beberapa manajer / pemimpin tim yang sangat baik yang tahu sedikit tentang teknologi, dan beberapa manajer terburuk saya adalah mereka yang berpikir mereka tahu segalanya.

Untuk menjadi seorang pemimpin, jika Anda memiliki orang-orang yang kompeten, hal utama adalah untuk dapat menilai kompetensi dan penilaian mereka, dan memberikan setiap kebebasan sebanyak yang dia bisa tangani, sambil menjaga "bebek liar" dalam tugas dan "hampir tidak" kompeten "sibuk dengan" aman "tetapi kegiatan produktif. Pastikan semua orang berbaris ke drum yang sama.

Tantangan Anda yang lebih besar cenderung menjaga manajemen tingkat atas. Mereka akan menginginkan laporan, jadwal, dan tanda centang, dan Anda perlu mencari tahu apa yang mereka inginkan dan bagaimana memalsukannya dengan cukup baik. (Yah, tidak sepenuhnya "palsu", tetapi menghasilkan dokumentasi yang memuaskan mereka tanpa menghabiskan waktu Anda atau waktu tim Anda.)


4

Anda tidak dipilih untuk keterampilan coding C # Anda, dan kecuali Anda akan menulis kode sejak awal, tidak masalah apakah Anda tahu C # atau tidak. Anda harus mulai berpikir di tingkat yang lebih tinggi:

  • Keterampilan apa yang dibawa oleh setiap orang dalam tim Anda ke meja?
  • Komponen mana yang sangat penting untuk keberhasilan proyek?
  • Apa yang harus Anda hasilkan selain kode yang sebenarnya? (Tes? Dokumentasi?)
  • Bagaimana Anda mengumpulkan persyaratan, jika Anda belum melakukannya?
  • Bagaimana Anda dan tim Anda akan mendekati proses desain?
  • Anda tahu bahwa memiliki standar pengkodean itu penting, tetapi Anda dapat mengandalkan tim Anda untuk mengetahui dengan tepat standar apa yang ingin mereka ikuti.
  • Bagaimana Anda bisa mendeteksi masalah sejak dini?

Beberapa dari hal-hal ini mungkin menyeberang ke wilayah manajemen proyek, tetapi sebagai pengembang utama Anda akan bekerja sama dengan manajer proyek dalam hal ini dan masalah lainnya.

Dengan segala cara, belajarlah untuk menjadi efektif bekerja dalam C # secepat mungkin. Ingatlah bahwa peran Anda adalah untuk melihat melewati sintaks dan rincian kerangka kerja dan melihat gambar yang lebih besar.


2

Ambil pendekatan langsung. Mulailah dengan mengambil primer C # sederhana dan tulis beberapa kode. Cobalah beberapa hal dasar yang Anda tahu cara melakukannya dengan mata tertutup dalam bahasa lain.

Baca tentang gaya dan konvensi pemrograman. Anda harus menemukan ini sebagian dalam primer Anda, tetapi Anda juga dapat menggunakan produk seperti StyleCop dan Resharper untuk menegakkan aturan gaya yang Anda tidak kenal. Ini secara efektif akan melatih Anda dengan sangat cepat untuk melakukan hal-hal dengan cara yang diterima secara umum untuk menghindari masalah dalam mengkompilasi perangkat lunak Anda.

Jadilah diri sendiri, dan terapkan pengetahuan desain yang sudah Anda miliki. Dasar-dasarnya pada dasarnya sama terlepas dari bahasa. Di mana akan ada perbedaan akan dalam bagaimana bahasa berbeda dalam hal struktur akan cukup minim, dan banyak dari itu akan menjadi sangat cepat ketika Anda mengumpulkan satu atau dua aplikasi uji.

Jika ada hal-hal yang jelas Anda tidak tahu, akan datang. Tim Anda akan menghormati kejujuran lebih dari sekadar menerobos tanpa petunjuk. Buatlah keputusan yang tepat dan beralasan, dan selalu luangkan beberapa menit untuk mempertimbangkan tanggapan Anda. Anda harus tegas tanpa berusaha untuk mendominasi, dan Anda tidak bisa membiarkan kurangnya pengetahuan Anda di satu bidang tampaknya merupakan refleksi pada kemampuan Anda untuk memimpin tim. Kepemimpinan berarti mentoring, namun mentoring tidak berarti Anda tidak bisa juga menunjukkan keinginan untuk mempelajari sesuatu yang baru.


3
Saya akan mengatakan ini adalah kebalikan dari apa yang harus dilakukan sebagai manajer. Mungkin tergoda untuk masuk dan membuang beberapa kode tetapi itu bukan pekerjaan Anda lagi ... tugas Anda adalah memungkinkan tim Anda untuk melakukan apa yang Anda sewa dan percaya pengalaman dan penilaian mereka. Mencoba untuk mempercepat pada platform yang berbeda adalah kontra-produktif.
Michael Brown

@MikeBrown Ini hanya berlaku jika posisi adalah posisi manajemen. Semua posisi kepemimpinan tim yang saya pegang memerlukan sejumlah besar kode waktu selain manajemen proyek, perencanaan, dan tanggung jawab lain yang Anda harapkan dari posisi ini. Jika OP mengatakan dia akan menjadi seorang Manajer , maka jawaban saya akan sangat berbeda.
S.Robins

Kamu benar. Saya mengasumsikan manajer dari fakta bahwa itu untuk teknologi yang tidak memiliki pengalaman. Buat edit dan saya akan membatalkan downvote saya :)
Michael Brown

@ MikeBrown Saya tidak yakin apa yang Anda rasakan perlu saya edit. Saya telah menjawab pertanyaan OP berdasarkan pernyataannya sendiri bahwa ia akan menjadi pemimpin proyek ... namun, saya akan sedikit memperluas jawabannya. :)
S.Robins

Oh, bukan karena saya merasa Anda perlu mengedit ... hanya saja SO tidak akan membiarkan saya mengubah suara saya tanpa edit :(
Michael Brown

1

Jika Anda berpikir seperti itu dan benar-benar khawatir tentang hal itu, Anda sudah menghindari risiko menjadi pemimpin proyek semacam ini. Jenis kepribadian yang sangat berbeda yang berani mengambil keputusan tanpa pengetahuan yang memadai. Tetaplah berpikiran terbuka terhadap apa yang dikatakan rekan kerja Anda dan ciptakan serta dorong budaya dialog dan pertukaran informasi dalam tim Anda.


1

Kedengarannya seperti itu adalah beberapa masalah yang dimainkan di sini.

Teknologi yang digunakan dalam proyek yang Anda pimpin dan proses yang mengatur pengembangan proyek itu.

Apakah Anda pemimpin tim, atau pengembang utama? Pengembang utama juga melakukan sedikit pekerjaan desain dan pengembangan. Jadi satu-satunya cara untuk mengatasi ini adalah dengan menyerah dan mempelajari teknologi baru .

Jika Anda benar-benar memimpin tim, Anda perlu mempercayai tim dan membiarkan mereka mengarahkan sebagian besar arahan teknis proyek. Tentu saja, secara konseptual, Anda akan dapat menjaga kemudi itu ke arah yang benar.

Proses yang mengatur pengembangan proyek sebagian besar harus ada . Ini hanya masalah membaca mereka, memahami mereka dan mengeksekusi mereka.

Jika tidak, bernegosiasi dengan bos Anda untuk mendapatkan mentor untuk membantu Anda menerapkan beberapa proses pengembangan. Ini sangat penting. Ini akan gagal dengan cepat jika prosesnya tidak di tempat, dan bersifat sementara.

Semoga berhasil!


0

Peluang datang sesekali .. Lakukan Ambil itu .. Saya akan mengatakan, cobalah untuk mempelajari dasar-dasar C #. Dapatkan beberapa tutorial dari online, coba kerjakan. awalnya akan sulit untuk mempelajari konsep baru, nanti ketika tugas pertama Anda selesai, Anda akan memiliki keyakinan di dalamnya.

Berpikir positif, Cobalah untuk mengambil tugas yang sulit, debug kode Anda sendiri dan yakin Anda akan menguasainya ..

Jangan kehilangan kesempatan Anda.


0

Saya pikir jika Anda memiliki banyak pengembang. Net, ada banyak pengetahuan di tim yang mungkin perlu Anda manfaatkan untuk memulai. Ada banyak kesamaan antara Java dan .Net bahwa apa yang sudah Anda ketahui sebenarnya benar-benar dapat diterapkan secara kurang langsung. Yang penting adalah mengetahui apa yang penting untuk mendapatkan yang tepat untuk proyek ini dan risiko yang terlibat. Berkomunikasi dengan tim Anda sesering yang diperlukan. Praktik rekayasa perangkat lunak berkembang di seluruh proyek sehingga mungkin sulit untuk memiliki "praktik terbaik" sejak awal dalam proyek.

Saya agak memiliki kebalikan dari pengalaman Anda di mana saya diberi tim lulusan yang sangat hijau yang tidak berasal dari bidang terkait perangkat lunak. Walaupun saya memiliki semua alasan untuk menetapkan apa yang perlu dilakukan (saya dipekerjakan untuk), saya malah mencari latihan untuk membuat kami bergerak dan banyak pelatihan dan diskusi untuk mengembangkan praktik rekayasa perangkat lunak kami. Saya belajar banyak dari tim di jalan dan kami hampir di sana dalam memberikan proyek rumah pertama kami setelah lebih dari satu tahun di pekerjaan!


-1

Saya tersesat ketika datang ke standar pengkodean, alat siklus hidup proyek dan prosedur rilis / distribusi.

Temukan produk sumber terbuka yang menggunakan teknologi yang sama yang akan Anda gunakan.

Jika memungkinkan, cari yang mirip dengan domain masalah. Ini tidak sepenting menemukan proyek dengan teknologi dan pembaruan aktif yang sama.

Unduh kode kerjanya. Membacanya.

Cari tahu alat apa yang mereka gunakan. Gunakan itu.

Cari tahu bagaimana membangun dan merilis proyek open source. Bangun dan lepaskan.

Proyek sumber terbuka (dengan sejumlah kontributor) akan menggambarkan praktik terbaik.

Saya tidak ragu bahwa saya dapat mengambil dasar-dasarnya dalam satu atau dua bulan, tetapi ada pengalaman tertentu yang hanya dapat dikumpulkan dengan waktu.

Benar.

Belajar dari komunitas open source.


2
Terkadang orang yang bekerja pada proyek sumber terbuka tidak menggunakan alat terbaik yang tersedia atau bahkan mengikuti standar (praktik yang baik). Saya tahu beberapa proyek open source (saya tidak ingin menyebutkannya) yang benar-benar buruk dalam hal menggunakan alat yang tepat atau bahkan mengikuti konvensi industri.
Christian P

@ChristianP: Walaupun ada beberapa proyek sumber terbuka yang kurang dari bintang, mudah untuk menemukan yang besar yang cukup bagus. Dan menemukan setiap proyek open source sebagai contoh adalah lebih baik daripada tidak sama sekali misalnya.
S.Lott

Saya setuju bahwa contoh apa pun lebih baik daripada tidak sama sekali. Tetapi ketika mencari praktik terbaik, alat, dll. Orang dapat belajar lebih banyak dari proyek sumber terbuka yang baik bahkan jika proyek tersebut tidak menyelesaikan masalah yang sama.
Christian P
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.