Apa itu Manajer Proyek Teknis?

Apa itu Manajer Proyek Teknis (TPM)? Jawabannya tergantung pada siapa Anda bertanya, kata Andi Blackwell, konsultan IT veteran dan pakar operasi bisnis. Sebagai Direktur Utama Manajemen Proyek dan Produk Toptal, Blackwell mengepalai tim yang bertanggung jawab untuk mencocokkan manajer proyek yang sangat terampil dalam jaringan lepas Toptal dengan organisasi yang mencari bakat terbaik untuk inisiatif tertentu. Dalam beberapa tahun terakhir, dia telah melihat lonjakan permintaan untuk TPM.

“Pasti ada beberapa perdebatan di industri teknologi tentang apa arti sebenarnya dari istilah itu,” kata Blackwell. “Ada banyak orang yang menyebut diri mereka Manajer Proyek Teknis karena mereka telah bekerja sangat erat dengan tim teknik atau memimpin tim teknis dari perspektif manajemen proyek, tetapi bukan itu yang kami cari.”

Definisi Toptal lebih spesifik. Semua manajer proyek di jaringan Toptal ahli dalam keterampilan manajemen proyek tradisional seperti pelingkupan, penganggaran, dan pengelolaan jadwal, serta praktik pengembangan perangkat lunak Agile yang terkait dengan pengiriman berulang dan peningkatan berkelanjutan. Mereka selalu bekerja sama dengan para insinyur dan dapat, jika dipanggil, melatih dan membimbing tim Scrum.

Namun, untuk memenuhi syarat sebagai TPM, mereka harus memiliki lapisan pengalaman tambahan selain mengelola proses Agile dan berkolaborasi dengan pengembang: Mereka harus menjadi pengembang itu sendiri.

Kombinasi yang Berharga

Organisasi besar dan kecil semakin tertarik pada kombinasi keterampilan khusus ini. “Kebanyakan startup tidak dapat mempekerjakan orang yang hanya dapat melakukan satu hal,” kata Blackwell, dan perusahaan besar ingin melihat “pengembang” atau “arsitek” di profil kandidat jika mereka merekrut untuk proyek rekayasa.

Bahkan dalam kasus di mana klien tidak secara khusus membutuhkan manajer proyek dengan latar belakang teknis, mencentang kotak "pengembang" adalah nilai jual utama. Seseorang yang dapat merencanakan dan menjalankan proyek perangkat lunak, mengimplementasikan dan mengoptimalkan proses Agile, dan kode? Itu anugerah besar.

Namun, pada kenyataannya, TPM tidak diharapkan untuk membuat kode—banyak yang belum membuat kode selama bertahun-tahun. Lalu, mengapa perlu pengalaman pemrograman?

TPM diperlukan untuk membuat keputusan teknis, kata Blackwell: “Jika Anda tidak memiliki setidaknya beberapa pengalaman langsung yang relatif baru dengan tumpukan teknologi modern, SDK (perangkat pengembangan perangkat lunak), arsitektur, atau platform otomatisasi pengujian, maka Anda' kembali berpotensi tidak akan membuat keputusan yang tepat. Anda tidak akan memiliki kredibilitas dengan klien karena Anda belum pernah menggunakan hal-hal itu sebelumnya.”

Bekerja Dengan Tim

Menunjukkan kredibilitas kepada calon klien merupakan faktor penting dalam mengamankan keterlibatan, tetapi itu hanya rintangan pertama. Setelah ditugaskan ke sebuah proyek, TPM harus segera mendapatkan kepercayaan dan rasa hormat dari tim teknis.

Michael Poythress mengambil pemrograman saat remaja. Pada usia 16, dia membangun situs web komersial untuk bisnis periklanan real estat yang dia mulai bersama ayahnya. Dia telah menjadi CEO dan pendiri beberapa perusahaan rintisan sejak itu. Pada tahun 2018, ia bergabung dengan jaringan Toptal sebagai TPM dan sekarang bekerja sama dengan tim teknik. “Jika saya tidak memiliki pengalaman dengan pengkodean, para programmer akan memahaminya,” katanya. “Mereka tidak akan menembak langsung dengan saya. Tetapi jika saya menantang mereka dan berbicara kepada mereka sebagai rekan, ada rasa hormat dan hubungan baik.”

Dan pengalaman teknologilah yang lebih penting daripada judulnya, kata Allen Takatsuka, seorang Toptal TPM yang berbasis di Orange County, California: “Dari apa yang saya lihat, 'T' di TPM tidak benar-benar membawa bobot bagi para insinyur. Mereka pikir itu hanya manajer proyek lain yang akan mengatur pertemuan mereka dan meminta mereka untuk mengisi spreadsheet.”

Namun, begitu landasan bersama terbentuk, “rasa interaksinya sangat berbeda. Ini lebih merupakan kemitraan dengan teknik, ”katanya.

Takatsuka menghabiskan beberapa dekade memimpin tim teknik di awal kehidupan profesionalnya. Dia memuji pengalaman itu karena telah meningkatkan soft skill-nya. "Ini sedikit keterampilan empati yang berbeda," katanya. “Anda harus menunjukkan bahwa Anda bisa berbicara bahasa itu. Anda dapat mengatakan, 'Saya mengerti mengapa Anda menghadapi tantangan ini berdasarkan hal-hal teknis yang sedang terjadi.'”

Dan Allen, seorang konsultan teknologi dari Wina, Virginia, menggambarkan kemajuan karirnya sebagai "programmer pria-in-the-cubicle untuk memimpin teknis untuk arsitek, direktur, VP, CTO, CIO." Sejak bergabung dengan jaringan Toptal sebagai TPM pada tahun 2019, dia sibuk, mengerjakan 14 keterlibatan klien.

“Saya jarang membaca kode. Saya hampir tidak pernah menulis kode,” katanya. “Tetapi ada situasi di mana pengembang macet. Mereka dapat memandu saya melalui arsitektur dan saya dapat melihat dengan tepat apa yang mereka coba lakukan dan logikanya.”

Dia menemukan dinamika berguna tidak hanya dalam kasus tepi tetapi lebih luas. “Tim Anda tahu bahwa mereka dapat datang kepada Anda dan berbicara, dan Anda benar-benar memahami apa yang mereka katakan,” katanya. “Anda dapat membantu mereka mempertimbangkan semua kerumitan jika mereka melewatkan sesuatu. Anda bisa menjadi papan suara dan memberikan umpan balik.”

Efek Pengganda

Umpan balik dan wawasan semacam itu penting untuk lebih dari sekadar membangun hubungan. TPM menawarkan proposisi nilai yang berbeda untuk sebuah organisasi. Mereka kurang berfungsi sebagai saluran informasi dan lebih sebagai sumber pengetahuan. Ya, mereka merencanakan, mengoordinasikan, dan berkomunikasi, tetapi mereka juga membantu klien dan tim bekerja melalui keputusan teknologi yang kompleks.

“Anda memiliki kemampuan untuk secara teknis berpendirian,” kata Takatsuka. “Dan itu menambah nilai bagi organisasi karena sekarang Anda memiliki lebih banyak efek pengganda, bukan hanya mengatur dan berkolaborasi.”

Takatsuka mencatat bahwa TPM harus melewati lebih sedikit rintangan untuk memecahkan masalah. Di organisasi yang lebih besar khususnya, program non-teknis atau manajer proyek mungkin mendekati tantangan teknis dengan mengidentifikasi pemain dan pemangku kepentingan yang relevan, menawarkan konteks, mengumpulkan informasi, dan kemudian menyaring hasil untuk membuat keputusan. TPM dapat membawa pengetahuan mereka sendiri untuk ditanggung.

“Anda dapat mengatasi risiko dengan jauh lebih efisien,” kata Oana Ciherean, TPM yang berbasis di Tokyo. “Dan risiko itu bisa datang dari banyak tempat. Mereka bisa datang dari perkiraan yang salah dari tim. Jadi Anda bisa berkata, 'Oke, saya yakin bahwa bagian kode ini tidak akan memakan waktu seminggu untuk ditulis' karena ini sebenarnya dua hari. Jadi Anda benar-benar dapat membuka blokir orang. Karena Anda telah mengetahui bahwa mereka macet dan itulah mengapa mereka membutuhkan waktu lima hari. Anda tahu itu karena Anda pernah ke sana dan Anda sendiri terjebak.”

Menemukan Keseimbangan

Ciherean memulai karirnya sebagai pengembang tetapi segera pindah ke manajemen proyek karena keinginan untuk terlibat dengan gambaran yang lebih besar. Namun, dalam peran itu, dia menemukan bahwa dia melewatkan pengkodean. Dia mengatakan Manajemen Proyek Teknis menawarkan yang terbaik dari kedua dunia: "Ini memungkinkan saya untuk benar-benar terlibat dalam teknologi tetapi juga tingkat tinggi dengan memahami bisnis dan pelanggan dan apa yang mereka inginkan dalam fitur."

Poythress juga merasa telah menemukan sweet spot-nya. “Saya seorang penerjemah atau penghubung antara visioner yang memiliki ide dan talenta teknis yang tahu bagaimana membangun dan mewujudkannya,” katanya. “Saya berbicara kedua bahasa dengan lancar. Saya berbicara 'orang normal' dan saya berbicara 'teknis.'”

CTO Mini

TPM yang bekerja untuk perusahaan rintisan dan usaha kecil menempati kursi utama di persimpangan bisnis dan teknologi. Pada keterlibatan ini, TPM sering kali merupakan karyawan pertama yang bergabung di awal proyek. Dia kemudian bertanggung jawab untuk menilai kelayakan produk, mendefinisikan ruang lingkup dan persyaratan teknis, dan membantu klien (terkadang seorang pendiri tunggal dengan bibit ide) memilih tumpukan teknologi, mengevaluasi vendor untuk pengiriman layanan, menerapkan praktik terbaik DevOps, dan membentuk tim yang tepat.

Takatsuka menganggap keterlibatan ini sebagai peran "mini CTO", di mana TPM menjembatani bidang bisnis dan teknis untuk menyelesaikan berbagai hal. Beberapa klien hampir tidak tahu apa-apa tentang mengembangkan perangkat lunak, katanya: “Bagaimana cara saya mendirikan toko? Saya sudah membaca tentang Agile. Bagaimana aku melakukan itu?"

Poythress melihat kedua peran itu tumpang tindih, bahkan tidak bisa dibedakan satu sama lain dalam kasus-kasus tertentu. "Ada banyak penyerbukan silang," katanya. “CTO untuk organisasi yang lebih kecil dapat dengan mudah pindah ke peran PM teknis senior di organisasi yang lebih besar dan merasa seperti di rumah sendiri.”

Mengaktifkan Kelincahan

Sementara mekanisme Agile berada di ruang kemudi hampir semua manajer proyek dengan pengalaman pengembangan perangkat lunak, seseorang dengan bakat teknis dapat membawa perspektif yang lebih bernuansa untuk mengelola proses.

Ciherean menemukan bahwa metodologi Agile tidak pernah diterapkan secara ketat oleh buku; mereka harus disesuaikan, dicampur, dan disesuaikan untuk kebutuhan spesifik tim dan proyek.

“Anda harus memastikan bahwa apa yang Anda rancang sebagai suatu proses tidak mengganggu pekerjaan pengembang dan benar-benar membuatnya lebih efisien atau produktif,” katanya. “Terkadang itu berarti masuk jauh ke dalam alur kerja GitHub, misalnya, untuk melihat bagaimana mereka melakukan komitmen mereka, melihat bagaimana mereka membuat cabang untuk kode mereka, dan melihat apakah proses Anda cocok dengan alur kerja mereka. Dan kemudian Anda memperbaiki proses Anda atau memperbaiki alur kerja mereka.”

Keahlian TPM juga dapat menginformasikan artefak dan praktik Agile tertentu, seperti jaminan simpanan produk dan estimasi ukuran relatif.

“Jika Anda memahami teknisnya, Anda tahu kerumitan kasar dari berbagai hal yang menumpuk,” kata Takatsuka. “Jika tidak, yang Anda miliki hanyalah daftar ini dan akan sulit bagi Anda untuk mengetahui apakah nomor satu adalah ukuran T-shirt Besar dibandingkan dengan nomor dua. Anda mungkin memiliki gagasan bahwa yang satu lebih sulit, tetapi Anda tidak benar-benar tahu apa yang ada di balik layar. TPM "ekstrim", katanya, "dapat mengukur sesuatu sendiri, dengan peringatan bahwa ketika tim bergabung, mereka akan memiliki kecepatan mereka sendiri."

Poythress menggunakan pemahamannya tentang estimasi ukuran sebagai ukuran untuk mengevaluasi pemimpin teknologi dan insinyur yang dia pertimbangkan untuk sebuah proyek. Jika dia mengharapkan sesuatu menjadi tugas kecil tetapi orang lain menganggapnya besar, itu adalah tanda bahaya: “Saya akan mendengarkan mereka untuk melihat apakah ada kerumitan yang tidak saya ketahui, tetapi jika itu tidak tahan air, Saya seperti, 'Oke, well, itu tidak cocok.' Kami membutuhkan seseorang yang memahami hal ini dengan sangat baik dan tidak terintimidasi oleh fitur yang seharusnya sederhana.”

TPM juga membantu mendidik klien tentang persyaratan non-fungsional. Bagaimana Anda menangani ketersediaan tinggi? Bagaimana Anda menangani pemulihan bencana? “Tanpa pemahaman teknis, saya tidak tahu bagaimana Anda melakukan diskusi itu,” kata Takatsuka. “Anda mungkin akan berhenti di level persyaratan Scrum dan berhenti sejenak sampai orang teknis datang. Nah, kalau begitu Anda punya jurang besar ini. ”

Menjaga Saat Ini

Meskipun waktu mereka di keyboard memainkan peran mendasar dalam apa yang mereka lakukan hari ini, TPM tidak dapat mengandalkan pengalaman masa lalu untuk tetap relevan. Mengingat tingkat di mana teknologi berubah dan berkembang, mudah untuk tertinggal.

Poythress mempelajari hal ini dengan susah payah, selama periode lima tahun sebelum bergabung dengan Toptal, ketika dia secara eksklusif fokus menjalankan perusahaannya sendiri. “Saya pasti mengalami stagnasi,” katanya. “Banyak bahasa yang berbeda datang dan memecahkan masalah dalam periode waktu yang saya tidak tahu apa-apa karena kami memiliki tumpukan teknologi kami dan hanya itu yang kami butuhkan.”

Hari ini dia menghabiskan hingga 10 persen waktunya untuk membaca dokumentasi, menonton YouTube, dan sandbox "untuk mempelajari hal-hal terbaru dan terhebat."

“Saya hampir selalu mencoba-coba bahasa atau teknologi baru, agar saya tetap tajam,” katanya. “Karena kalau tidak, industri akan terus berjalan. Saya pernah mengalami itu sebelumnya. Dan jauh lebih sulit untuk menjejalkan daripada tetap up to date.”

Takatsuka juga proaktif dalam mengisi kesenjangan pengetahuannya: “Google sangat hebat akhir-akhir ini. YouTube luar biasa. Anda harus melakukan pekerjaan rumah Anda. Tapi pekerjaan itu dibangun dengan sendirinya.”

Dia juga mengandalkan jaringan luas rekan konsultan untuk dukungan dan berbagi pengetahuan. “Saya pernah berada dalam situasi di mana klien ingin menggunakan Google, tetapi kebetulan saya tahu platform AWS lebih baik,” katanya. “Saya dapat menelepon teman dan berkata, 'Hei, kita akan menggunakan Firebase. Apakah Anda memiliki klien yang melakukan ini? Bagaimana dengan skalabilitas?'”

Bahkan setelah lebih dari 30 tahun berkecimpung dalam bisnis dan berbagai peran tingkat eksekutif, Dan Allen tidak takut untuk mengotori tangannya. Dalam tiga tahun terakhir, dia belajar sendiri untuk menyebarkan sendirian di Amazon dan Google Cloud. “Saya melakukannya agar saya bisa memahaminya dan membantu klien Toptal,” katanya. “Mereka tidak memiliki tim teknologi. Yang mereka miliki hanyalah aku. Jadi saya pergi ke Universitas YouTube dan saya menyelesaikannya.”

Begitu banyak yang telah berubah sejak Allen memulai sebagai pengembang pada tahun 1985. Namun dia menyukai tantangan yang datang dengan setiap peluang baru. "Itu bagian dari apa yang saya sukai dari pekerjaan itu," katanya. “Selalu ada sesuatu yang belum Anda lakukan, sesuatu yang baru. Dan Anda selalu pergi dengan bulu tambahan di topi Anda yang dapat Anda manfaatkan pada pertunangan berikutnya.