Program Studi Bisnis Digital • FEB

Manajemen Proyek Digital

Pertemuan 10 — Mengelola Tim Lintas Fungsi & Manajemen Konflik

Bagaimana desainer, developer, dan tim konten bekerja sebagai satu tim, serta cara Project Manager mendeteksi dan menyelesaikan konflik sebelum merusak jadwal proyek.

RPS MINGGU 11 • 2X50 MENIT

Selamat pagi/siang, Anda semua yang sedang belajar mengelola proyek digital. Minggu lalu kita membahas Agile, Scrum, dan Hybrid sebagai pendekatan kerja; hari ini kita masuk ke sisi yang lebih manusiawi dari sebuah proyek, yaitu bagaimana tim yang berisi orang-orang dengan keahlian sangat berbeda — desainer, programmer, penulis konten, sampai tim pemasaran — bisa bekerja rukun menuju satu tujuan yang sama. Bayangkan Anda memimpin proyek pembuatan aplikasi UMKM seperti yang dipakai warung-warung mitra GoFood: desainer ingin tampilan cantik, developer ingin kode yang stabil, dan tim konten ingin deadline realistis untuk menulis deskripsi produk. Ketiganya benar dari sudut pandang masing-masing, dan di situlah konflik lahir. Pertemuan ini akan membekali Anda dengan kerangka untuk memahami dinamika tim lintas fungsi dan lima gaya resolusi konflik yang bisa langsung Anda praktikkan.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu mengelola dinamika tim lintas fungsi (cross-functional team, tim berisi anggota dari berbagai keahlian) dan menerapkan strategi manajemen konflik dalam proyek digital.

CAPAIAN 1

DINAMIKA TIM

Menjelaskan tahapan perkembangan tim lintas fungsi dan peran Project Manager sebagai penghubung.

CAPAIAN 2

SUMBER KONFLIK

Mengidentifikasi sumber dan jenis konflik yang lazim muncul dalam proyek digital.

CAPAIAN 3

RESOLUSI

Menerapkan model Thomas-Kilmann untuk memilih gaya resolusi konflik yang tepat.

CAPAIAN 4

KOLABORASI

Merancang praktik retrospektif tim untuk mencegah konflik berulang di proyek berikutnya.

Empat capaian ini adalah peta perjalanan kita hari ini. Pertama, Anda akan memahami bagaimana sebuah tim — katakanlah tim yang dibentuk untuk membangun ulang situs e-commerce sebuah UMKM batik di Solo — berkembang dari kumpulan orang asing menjadi tim yang solid. Kedua, kita akan membedah dari mana konflik biasanya muncul dalam proyek digital, misalnya soal perbedaan prioritas antara tim desain dan tim teknis. Ketiga, Anda akan belajar lima gaya menyelesaikan konflik yang bisa dipilih sesuai situasi, bukan hanya satu cara yang itu-itu saja. Keempat, kita tutup dengan bagaimana tim yang matang justru menjadikan retrospektif sebagai kebiasaan agar konflik yang sama tidak terus berulang di proyek-proyek berikutnya. Simak baik-baik karena keempat hal ini akan langsung kita praktikkan lewat studi kasus dan role-play di akhir sesi.

Bagian 1 dari 3

Tim Lintas Fungsi dalam Proyek Digital

Siapa saja yang duduk di satu meja proyek, dan mengapa perbedaan keahlian mereka justru rawan menimbulkan gesekan.

Apa Itu Tim Lintas Fungsi?

Tim lintas fungsi (cross-functional team) adalah tim proyek yang anggotanya berasal dari disiplin keahlian berbeda, dikumpulkan untuk satu tujuan bersama — bukan dari satu departemen yang sama.

DESAIN (UI/UX)

Merancang tampilan & pengalaman pengguna. Ukuran sukses: kemudahan & keindahan.

TEKNIS (DEVELOPER)

Membangun & menguji sistem. Ukuran sukses: kestabilan & kecepatan kode.

KONTEN & PEMASARAN

Menulis copy, mengelola kampanye. Ukuran sukses: pesan yang tepat sasaran.

Contoh nyata: proyek revamp aplikasi mitra Tokopedia melibatkan desainer UX, tim backend, tim QA (quality assurance, penguji kualitas), dan tim konten produk dalam satu proyek yang sama.

Tantangan Koordinasi Lintas Fungsi

Perbedaan keahlian membawa perbedaan prioritas, istilah kerja, dan ukuran keberhasilan — inilah akar tantangan koordinasi.

Tiga Sumber Miskomunikasi Paling Umum

Silo kerja (silo, bekerja terpisah tanpa saling tahu progres) — desainer menyelesaikan mockup tanpa mengecek batasan teknis developer.
Bahasa berbeda — "responsif" bagi desainer berarti tampilan indah di semua layar; bagi developer berarti waktu muat (loading) yang cepat.
Prioritas berbeda — tim konten ingin waktu lebih untuk riset kata kunci, tim teknis ingin segera rilis (deploy) sesuai target sprint.

Peran Project Manager di sini bukan menjadi ahli desain atau ahli kode, melainkan penerjemah kebutuhan antar-disiplin agar semua pihak paham batasan satu sama lain.

Project Manager sebagai Jembatan Tim

PM efektif menjalankan tiga peran sekaligus dalam mengelola tim lintas fungsi.

FASILITATOR

Memastikan setiap disiplin didengar dalam rapat — bukan hanya suara paling lantang yang menang.

PENERJEMAH

Mengubah istilah teknis developer menjadi bahasa yang dipahami tim konten & klien, dan sebaliknya.

PENJAGA BATAS

Menjaga agar diskusi tetap fokus pada tujuan proyek, bukan ego masing-masing disiplin.

Peran ini melanjutkan pembahasan matriks stakeholder di Pertemuan 9 — PM yang paham peta pemangku kepentingan lebih siap menengahi konflik antar mereka.

Tahapan Perkembangan Tim (Model Tuckman)

Setiap tim lintas fungsi baru melewati empat tahap sebelum benar-benar solid — gesekan di awal adalah hal normal, bukan kegagalan.

Tahap	Yang Terjadi	Peran PM
1. Forming (pembentukan)	Anggota baru saling kenal, sopan, belum terbuka soal kesulitan.	Kenalkan tujuan proyek & peran masing-masing dengan jelas.
2. Storming (gejolak)	Perbedaan pendapat & konflik mulai muncul, misalnya soal prioritas fitur.	Fasilitasi konflik secara terbuka, jangan dihindari.
3. Norming (penormaan)	Tim mulai sepakat cara kerja bersama & saling percaya.	Kukuhkan kesepakatan kerja (working agreement) tertulis.
4. Performing (berkinerja)	Tim bekerja produktif dengan sedikit pengawasan.	Beri otonomi, fokus pada hasil bukan proses.

Model ini punya nama Tuckman, dari peneliti Bruce Tuckman yang mengamati bagaimana tim-tim berkembang. Bayangkan tim proyek pembuatan aplikasi belajar daring untuk sebuah startup edtech di Bandung. Di minggu pertama, semua orang masih sopan dan hati-hati — itu tahap forming. Masuk minggu kedua atau ketiga, mulai muncul perdebatan soal siapa yang bertanggung jawab atas keterlambatan tertentu — itu tahap storming, dan ini WAJAR terjadi, bukan tanda proyek gagal. Kalau difasilitasi dengan baik, tim akan masuk tahap norming, menyepakati cara kerja bersama, misalnya jam stand-up harian dan cara memberi umpan balik. Barulah di tahap performing, tim benar-benar bergerak cepat tanpa banyak drama. Saya sengaja beri tanda "data-no-frag" pada tabel ini karena kita akan membahasnya baris demi baris secara berurutan sebagai alur cerita, bukan berdiri sendiri-sendiri.

Coba Sendiri: Jalankan Tim Anda Melalui Tahapan Tuckman

Geser tim melalui tahap forming-storming-norming-performing dan amati bagaimana risiko social loafing berubah di tiap tahap.

Indikator Tim Lintas Fungsi yang Sehat

Sebelum masuk ke konflik, kenali dulu tanda-tanda tim yang berjalan baik — supaya Anda tahu kapan harus khawatir.

TANDA SEHAT

Anggota berani mengajukan pertanyaan "bodoh" tanpa takut diejek.
Keterlambatan dilaporkan lebih awal, bukan disembunyikan.
Keputusan didasari data & kebutuhan pengguna, bukan senioritas.

TANDA BAHAYA

Rapat selalu didominasi 1–2 orang, yang lain diam.
Saling menyalahkan (blame) saat progres laporan mingguan dibahas.
Anggota mulai berkomunikasi lewat pesan pribadi, bukan kanal tim.

Bagian 2 dari 3

Sumber & Jenis Konflik Proyek

Mengenali akar masalah sebelum mencari solusi — tidak semua konflik butuh cara penanganan yang sama.

Sumber Konflik dalam Proyek Digital

Konflik jarang muncul karena "orangnya jahat" — hampir selalu ada sumber struktural di baliknya.

SUMBER 1 — SCOPE

Ruang lingkup proyek berubah (scope creep, lihat Pertemuan 7) tanpa penyesuaian waktu/anggaran, memicu tim merasa dibebani sepihak.

SUMBER 2 — JADWAL

Deadline yang ditentukan sepihak oleh klien tanpa konsultasi tim teknis, membuat developer merasa dipaksa.

SUMBER 3 — SUMBER DAYA

Satu developer dipakai di dua proyek sekaligus — tim proyek digital rebutan waktu & perhatian orang yang sama.

SUMBER 4 — NILAI KERJA

Perbedaan standar kualitas: desainer ingin sempurna secara visual, PM ingin cepat rilis sesuai target bisnis.

Tiga Jenis Konflik Tim Proyek

Robbins & Judge membagi konflik tim menjadi tiga jenis — hanya satu jenis yang benar-benar berbahaya bagi tim.

Jenis	Contoh	Dampak pada Tim
Task conflict (konflik tugas)	Beda pendapat soal fitur mana yang diprioritaskan sprint ini.	Sehat dalam kadar sedang — mendorong ide lebih baik.
Process conflict (konflik proses)	Beda pendapat soal siapa mengerjakan apa & lewat kanal mana.	Netral — perlu disepakati lewat working agreement.
Relationship conflict (konflik hubungan)	Ketegangan personal, saling tidak suka antar-anggota.	Selalu merusak — harus segera ditangani PM.

Kesalahan paling umum: membiarkan task conflict berlarut-larut hingga berubah menjadi relationship conflict — inilah titik paling mahal untuk diperbaiki.

Hitung dari Nol: Dampak Konflik ke Jadwal Proyek

Konflik yang tidak diselesaikan cepat memicu rework (pekerjaan ulang) berulang. Mari hitung dampaknya pada proyek 12 minggu.

Langkah	Perhitungan	Nilai
1. Durasi rencana proyek	diberikan	12 minggu
2. Delay tiap siklus rework akibat konflik tak terselesaikan	8% × 12 minggu	0,96 minggu
3. Jumlah siklus rework (konflik desain-teknis berulang)	diberikan	2 kali
4. Total keterlambatan	0,96 × 2	1,92 minggu
5. Durasi aktual proyek	12 + 1,92	≈14 minggu

PERSENTASE KETERLAMBATAN

16%

1,92 ÷ 12 × 100

Sekarang mari kita buktikan dengan angka mengapa konflik yang dibiarkan itu mahal. Misalkan proyek Anda direncanakan 12 minggu. Setiap kali konflik desain-teknis tidak selesai dan terjadi pekerjaan ulang atau rework, kita asumsikan menambah delay sebesar delapan persen dari total durasi rencana, yaitu 0,96 minggu. Kalau ini terjadi dua kali sepanjang proyek — misalnya karena tim tidak pernah benar-benar menyepakati definisi "selesai" di awal — total keterlambatannya menjadi 1,92 minggu, sehingga proyek yang seharusnya 12 minggu molor menjadi hampir 14 minggu, atau naik enam belas persen dari rencana semula. Angka ini adalah ilustrasi untuk melatih logika perhitungan, bukan data empiris tetap, tapi pola hubungannya nyata: makin lama konflik dibiarkan, makin besar rework, makin panjang keterlambatan proyek Anda.

Bagian 3 dari 3

Strategi Resolusi & Kolaborasi Berkelanjutan

Lima gaya menyelesaikan konflik, studi kasus nyata, dan cara membuat tim tidak mengulang kesalahan yang sama.

Lima Gaya Resolusi Konflik (Model Thomas-Kilmann)

Model ini memetakan gaya resolusi berdasarkan dua sumbu: seberapa besar Anda mementingkan tujuan sendiri vs hubungan dengan pihak lain.

Gaya	Ciri	Kapan Dipakai
1. Competing (bersaing)	Mementingkan tujuan sendiri, kurang peduli hubungan.	Keputusan darurat, misal server down saat live.
2. Accommodating (mengalah)	Mengalah demi menjaga hubungan tim.	Isu kecil, bukan prinsip penting bagi Anda.
3. Avoiding (menghindar)	Menunda pembahasan konflik sepenuhnya.	Emosi sedang tinggi, butuh waktu mendinginkan diri.
4. Compromising (kompromi)	Kedua pihak sama-sama mengalah sebagian.	Waktu terbatas, solusi "cukup baik" diterima.
5. Collaborating (kolaborasi)	Mencari solusi menang-menang lewat diskusi mendalam.	Isu penting & ada cukup waktu — gaya paling ideal.

Model ini dikembangkan oleh Kenneth Thomas dan Ralph Kilmann, dan intinya sederhana: tidak ada satu gaya resolusi konflik yang selalu benar, semuanya tergantung situasi. Kalau server aplikasi tiba-tiba down saat jam sibuk pengguna, ini bukan saat untuk berdiskusi panjang — Anda perlu gaya competing, ambil keputusan cepat. Tapi kalau perdebatan soal warna tombol yang tidak terlalu krusial bagi Anda, mengalah saja (accommodating) lebih hemat energi. Kadang kita perlu avoiding sementara ketika emosi sedang panas, memberi jeda sebelum melanjutkan diskusi. Compromising cocok saat waktu mepet dan solusi "cukup baik" sudah memadai. Namun untuk isu besar yang berdampak jangka panjang pada proyek, gaya collaborating — duduk bersama mencari solusi menang-menang — adalah yang paling ideal, meski butuh waktu paling banyak. Tabel ini sengaja diberi data-no-frag karena kita akan membahas kelimanya sebagai satu kesatuan alur logika, bukan berdiri sendiri.

Coba Sendiri: Pilih Gaya Resolusi Konflik yang Tepat

Masukkan situasi konflik pada dua sumbu (kepentingan tujuan vs hubungan) dan lihat gaya Thomas-Kilmann mana yang paling cocok direkomendasikan.

Studi Kasus: Desainer vs Developer

Situasi

Proyek revamp aplikasi UMKM kuliner. Desainer merancang animasi transisi halaman yang halus untuk pengalaman pengguna premium. Developer menolak karena animasi ini memperlambat waktu muat aplikasi di ponsel entry-level yang dipakai mayoritas target pengguna. Deadline rilis tinggal 4 hari.

GAYA YANG DIPILIH

COLLABORATING

PM memfasilitasi sesi bersama data pengguna: 70% konsumen pakai HP entry-level.

SOLUSI MENANG-MENANG

ANIMASI RINGAN

Animasi disederhanakan (durasi lebih pendek) — desain tetap menarik, performa tetap cepat.

Mari kita lihat contoh konkret. Sebuah tim sedang merevamp aplikasi kasir untuk UMKM kuliner, dan desainer ingin animasi transisi halaman yang halus supaya terasa premium, sementara developer menolak karena animasi itu membuat aplikasi terasa berat di ponsel murah yang jadi perangkat mayoritas pengguna target. Deadline tinggal empat hari, tekanan tinggi. Project Manager di sini mengambil gaya collaborating: mengumpulkan kedua pihak, membawa data bahwa tujuh puluh persen konsumen memakai ponsel entry-level, lalu bersama-sama mencari jalan tengah. Hasilnya bukan kompromi setengah-setengah, melainkan solusi baru: animasi yang tetap ada tapi disederhanakan durasinya, sehingga desain tetap menarik dan performa tetap terjaga. Inilah kekuatan collaborating dibanding sekadar compromising — solusi yang muncul justru lebih baik dari usulan awal kedua pihak.

Hitung dari Nol: Skor Prioritas Penyelesaian Konflik

Saat PM menghadapi beberapa konflik sekaligus, gunakan matriks urgency (urgensi) × impact (dampak), skala 1–5, untuk menentukan mana yang ditangani lebih dulu.

Langkah	Perhitungan	Nilai
1. Skor Konflik A (desainer vs developer, animasi)	Urgensi 4 × Dampak 5	20
2. Skor Konflik B (developer vs konten, data API)	Urgensi 3 × Dampak 4	12
3. Skor Konflik C (marketing vs PM, jadwal peluncuran)	Urgensi 5 × Dampak 2	10
4. Total skor ketiga konflik	20 + 12 + 10	42
5. Bobot Konflik A terhadap total	20 ÷ 42 × 100	≈48%

DITANGANI LEBIH DULU

KONFLIK A

Skor tertinggi = 20 dari 3 konflik aktif

Dalam praktik nyata, seorang Project Manager jarang menghadapi satu konflik dalam satu waktu — bisa jadi ada tiga konflik berjalan bersamaan. Untuk menentukan mana yang ditangani lebih dulu, kita bisa memakai matriks urgensi kali dampak, masing-masing diberi skala satu sampai lima. Konflik A soal animasi antara desainer dan developer kita beri urgensi empat dan dampak lima, karena langsung memengaruhi tanggal rilis, sehingga skornya dua puluh. Konflik B soal data API antara developer dan tim konten mendapat skor dua belas, dan konflik C soal jadwal peluncuran antara marketing dan PM mendapat skor sepuluh. Total ketiga skor adalah empat puluh dua, dan konflik A menyumbang hampir empat puluh delapan persen dari total urgensi-dampak keseluruhan. Artinya, secara matematis, konflik A itulah yang harus Anda tangani lebih dulu sebelum yang lain, karena dampaknya paling besar terhadap keberhasilan proyek.

Teknik Komunikasi untuk Meredam Konflik

Gaya resolusi butuh keterampilan komunikasi yang tepat agar tidak terasa memihak atau menggurui.

ACTIVE LISTENING

Mendengar aktif: ulangi inti keluhan lawan bicara sebelum menanggapi, agar mereka merasa didengar.

FEEDBACK SANDWICH

Umpan balik "roti lapis": mulai dari hal positif, sampaikan kritik, tutup dengan dukungan & harapan.

1-ON-1 PRIVAT

Konflik personal dibicarakan empat mata dulu, bukan langsung di rapat tim terbuka.

Prinsip dasar: pisahkan orang dari masalah — kritik ide atau pendekatan kerja, jangan mengkritik pribadi seseorang.

Memilih gaya resolusi yang tepat saja tidak cukup kalau cara menyampaikannya kasar. Active listening berarti sebelum Anda menanggapi keluhan seseorang, ulangi dulu inti yang mereka sampaikan — misalnya, "jadi menurut Anda, masalah utamanya adalah developer tidak dilibatkan sejak awal desain, betul begitu?" Ini membuat orang merasa benar-benar didengar sebelum solusi dibahas. Feedback sandwich berguna saat Anda perlu menyampaikan kritik ke anggota tim, misalnya kepada developer yang terlambat melapor masalah: mulai dengan apresiasi atas kerja kerasnya, sampaikan area yang perlu diperbaiki, lalu tutup dengan dukungan agar dia tidak mengulanginya. Dan untuk konflik yang sifatnya personal, selalu bicarakan empat mata dulu, jangan mempermalukan seseorang di depan seluruh tim dalam rapat terbuka. Prinsip emasnya: kritik masalahnya, bukan orangnya.

Retrospektif & Psychological Safety

Tim matang tidak hanya menyelesaikan konflik, tapi belajar darinya lewat retrospektif (retrospective, evaluasi rutin akhir sprint/proyek) rutin.

FORMAT RETROSPEKTIF

What went well — apa yang berjalan baik.
What went wrong — apa yang bermasalah.
Action items — tindakan konkret minggu depan.

PSYCHOLOGICAL SAFETY

Rasa aman psikologis (psychological safety): anggota tim berani mengakui kesalahan atau ketidaktahuan tanpa takut dihukum atau diejek — syarat utama retrospektif jujur.

Latihan Kelas: Role-Play Resolusi Konflik

Berkelompok 4 orang. Setiap kelompok memerankan skenario berikut selama 10 menit, lalu presentasikan gaya Thomas-Kilmann yang dipilih dan alasannya.

Skenario

Tim proyek membangun fitur pembayaran digital untuk aplikasi ojek daring lokal. Tim keamanan (security) ingin proses verifikasi berlapis demi mencegah penipuan; tim produk ingin proses sesingkat mungkin agar pengguna tidak batal transaksi. Peluncuran tinggal 1 minggu lagi.

Tugas tiap kelompok: (1) identifikasi jenis konflik (task/process/relationship), (2) pilih gaya Thomas-Kilmann yang paling tepat, (3) rumuskan satu solusi konkret.

Sekarang giliran Anda mempraktikkan langsung apa yang sudah kita pelajari. Bentuk kelompok berisi empat orang, dan bayangkan Anda sedang menangani konflik nyata antara tim keamanan yang ingin verifikasi berlapis untuk mencegah penipuan pada fitur pembayaran digital ala aplikasi ojek online, melawan tim produk yang khawatir proses berlapis membuat pengguna batal bertransaksi karena terlalu ribet. Waktu peluncuran tinggal satu minggu, jadi tekanannya nyata. Diskusikan dulu jenis konfliknya termasuk task, process, atau relationship, lalu tentukan gaya Thomas-Kilmann mana yang paling masuk akal dipakai di sini, dan rumuskan satu solusi konkret seperti yang tadi kita lihat di studi kasus animasi. Saya beri sepuluh menit, lalu setiap kelompok mempresentasikan pilihannya secara singkat di depan kelas.

Rangkuman & Persiapan Minggu Depan

Cheat Sheet Hari Ini

Tim lintas fungsi melewati 4 tahap Tuckman: forming, storming, norming, performing.
Konflik bersumber dari scope, jadwal, sumber daya, & nilai kerja.
3 jenis konflik: task, process (netral/sehat), relationship (selalu merusak).
5 gaya Thomas-Kilmann: competing, accommodating, avoiding, compromising, collaborating.
Retrospektif rutin + psychological safety mencegah konflik berulang.

MINGGU DEPAN — PERTEMUAN 11

RISIKO PROYEK

Identifikasi risiko proyek digital & strategi mitigasi.

Tugas: tuliskan 1 konflik nyata (dari organisasi/magang/kelompok tugas Anda) & analisis pakai matriks Thomas-Kilmann, kumpulkan sebelum pertemuan berikutnya.

Mari kita tutup dengan merangkum lima hal penting hari ini: tim lintas fungsi berkembang lewat empat tahap Tuckman, konflik biasanya bersumber dari perubahan ruang lingkup, jadwal, rebutan sumber daya, atau perbedaan standar kerja, ada tiga jenis konflik dengan tingkat bahaya berbeda, ada lima gaya Thomas-Kilmann yang bisa Anda pilih sesuai situasi, dan tim yang matang menjaga rasa aman psikologis lewat retrospektif rutin. Minggu depan, di pertemuan sebelas, kita akan bergeser membahas identifikasi risiko proyek digital dan strategi mitigasinya — topik yang sebenarnya berkaitan erat dengan hari ini, karena konflik yang tidak dikelola juga merupakan salah satu jenis risiko proyek. Sebagai tugas, silakan tuliskan satu konflik nyata yang pernah Anda alami, baik dari organisasi kampus, magang, atau kerja kelompok, lalu analisis menggunakan matriks Thomas-Kilmann seperti yang baru kita praktikkan. Sampai jumpa minggu depan.