Joel on Software

Joel on Software   Pojok Software Joel

 

Artikel-artikel "Joel on Software" lain dalam bahasa Indonesia

Artikel-artikel "Joel on Software" lain dalam bahasa Inggris

Email pengarang (hanya dalam bahasa Inggris)

 

Functional Specifications yang Mudah - Bagian 3: Tetapi... Bagaimana?

 

 


Oleh Joel Spolsky
Diterjemahkan oleh Mas Agung Sachli
4 Oktober 2000

Sekarang anda telah membaca semua tentang mengapa anda memerlukan spec dan apa yang terdapat di dalam spec, sekarang mari kita bicarakan siapa yang harus menulis spec.

Siapa yang menulis spec?

Saya akan ceritakan sedikit sejarah Microsoft dulu. Ketika Microsoft mulai bertumbuh dengan serius di tahun 1980-an, setiap orang di sana telah membaca The Mythical Man-Month, salah satu buku klasik tentang software management. (Jika anda belum membacanya, saya sangat merekomendasikannya.) Inti utama dari buku tersebut adalah ketika anda menambahkan programmer pada sebuah project yang terlambat, ia akan bertambah terlambat. Hal itu karena saat anda mempunyai n programmer di suatu tim, jumlah jalur komunikasinya adalah n(n-1)/2, yang akan bertambah sebesar O(n2).

Jadi para programmer di Microsoft mempunyai kekhawatiran tentang bagaimana menulis program yang semakin besar, jika kebijakan yang berlaku saat itu adalah penambahan programmer hanya akan memperburuk keadaan.

Charles Simonyi, "kepala arsitek" senior Microsoft, menyarankan suatu konsep master programmers. Idenya adalah ada seorang master programmer yang bertanggung jawab untuk menulis semua kode, namun dia akan mengandalkan sebuah tim junior programmer sebagai "code slaves". Daripada mengkhawatirkan mendebug semua fungsi, master programmer tersebut hanya perlu membuat prototype setiap fungsi, menbuat kerangka besarnya, dan kemudian menyerahkannya ke salah satu junior programmer untuk diimplement.  (Tentu saja, Simonyi akan menjadi Master-nya Master Programmer.) Istilah "Master Programmer" sedikit berkesan jaman pertengahan, sehingga Microsoft menggantinya menjadi "Program Manager."

Secara teory, hal ini seharusnya bisa menyelesaikan masalah Mythical Man-Month, karena tidak ada orang yang perlu berbicara dengan yang lainnya lagi -- setiap junior programmer hanya berbicara ke satu program manager, dan sehingga komunikasi bertumbuh sebesar O(n), bukan O(n2).

Mungkin Simonyi menguasai Hungarian Notation, namun dia tidak mengetahui Peopleware. Tidak ada yang ingin menjadi pelayan kode. Sistem tersebut sama sekali tidak jalan. Akhirnya Microsoft menemukan bahwa tanpa ancaman Mitos Man Month, anda tetap bisa menambahkan orang yang pintar dan mendapatkan peningkatan keluaran, walaupun dengan penurunan margin keuntungan. Tim Excel mempunyai 50 programmer saat saya di situ, dan mereka secara marginal lebih produktif dari 25 orang -- namun tidak dua kali lebih produktif.

Ide tentang master/slave programming tidak dihargai lagi, namun di Microsoft masih berkeliaran orang yang bernamakan program managers. Seorang pintar yang bernama Jabe Blumenthal pada dasarnya menciptakan ulang posisi program manager ini. Sejak saat itu, program manager akan memiliki design dan spec untuk sebuah produk.

Sejak saat itu, program managers di Microsoft bertugas untuk mengumpulkan requirements, memikirkan bagaimana sebuah kode harus bekerja, dan menulis spec. Biasanya ada 5 programmer untuk setiap 1 program manager; programmer ini bertanggung jawab untuk mengimplementasikan apa yang telah diimplementasikan oleh program manager dalam bentuk spec. Seorang program manager juga perlu mengatur marketing, dokumentasi, testing, lokalisasi, dan semua hal detail kecil yang menyebalkan lainnya yang mana programmer tidak boleh menghabiskan waktunya di situ. Akhirnya, program manager di Microsoft harus memiliki "gambaran besar" dari perusahaan di dalam pikirannya, sementara programmer bebas berkonsentrasi membuat setiap bit kode mereka benar.

Program manager sangat berharga sekali. Jika anda pernah mengeluhkan tentang bagaimana programer lebih memikirkan masalah teknis dibandingkan masalah pemasaran, anda membutuhkan seorang program manager. Jika anda pernah mengeluh tentang bagaimana seorang yang bisa menulis kode yang bagus namun tidak bisa menulis bahasa Inggris yang bagus, anda butuh seorang program manager. Jika anda pernah mengeluh tentang bagaimana produk anda hanyut tanpa arah yang jelas, anda butuh seorang program manager.

Bagaimana anda memilih seorang program manager?

Kebanyakan perusahaan tidak memiliki konsep program manager. Saya pikir hal itu sangat buruk sekali. Pada masa saya, kelompok di Microsoft dengan program manager yang bagus menghasilkan produk yang berhasil: Excel, Windows 95, dan Access beberapa diantaranya. Namun kelompok yang lain (seperti MSN 1.0 dan Windows NT 1.0) dikerjakan oleh developers yang secara umum mengabaikan program managers (yang tidak terlalu bagus juga, dan mungkin layak diabaikan), dan produk mereka tidak begitu sukses.

Berikut 3 hal yang harus dihindari.

1. Jangan mengangkat programer menjadi seorang program manager.  Keahlian untuk menjadi seorang program manager yang baik (menulis dengan jelas, diplomasi, perhatian pasar, empati user, dan desai UI yang baik) merupakan keahliah yang sangat jarang dimiliki oleh seorang programer yang baik. Memang beberapa orang dapat melakukan keduanya, namun sangat jarang. Memberi penghargaan pada pemrogram yang baik dengan mempromosikan mereka ke posisi yang berbeda, yang menharuskan menulis dokumen, bukan C++, merupakan kasus klasik dari Peter Principle: orang cenderung dipromosikan ke tingkat inkompetensian mereka.

2. Jangan membiarkan orang marketing menjadi program managers. Jangan tersinggung, namun saya pikir pembaca saya akan setuju bahwa orang marketing yang bagus jarang sekali mempunyai pemahaman yang baik tentang teknologi untuk mendesain produk.

Pada dasarnya, program management merupakan sebuah jalur karir yang terpisah. Semua program manager harus sangat teknis, namun mereka tidak harus seorang programer yang baik.  Program manager belajar tentang UI, bertemu pelanggan, dan menulis specs. Mereka perlu bergaul dengan beragam orang -- dari pelanggan yang "bodoh", sampai programer yang mirip pertapa yang masuk kerja dengan seragam Star Trek, sampai ke salesman yang angkuh yang mengenakan pakaian seharga $2000. Dengan kata lain, program manager adalah perekat dari tim software. Kharisma merupakan hal yang krusial.

3. Jangan menyuruh programer melapor ke program manager. Ini merupakan kesalahan yang mendasar. Sebagai seorang program manager di Microsoft, saya mendesain strategi Visual Basic (VBA) untuk Excel dan membuat spek yang lengkap, sampai ke detail terkecil, bagaimana VBA harus diimplementasikan di Excel. Spec saya mencapai 500-an halaman. Pada saat mengembangkan Excel 5.0, saya memperkirakan setiap pagi ada 250 orang masuk kerja dan mengerjakan spec tebal yang saya tulis itu. Saya tidak tahu siapa saja mereka, namun di sana ada sekitar selusin orang di tim Visual Basic hanya menulis dokumentasi tentang hal ini (belum menyebutkan tim yang menulis dokumentasi dari sisi Excel, atau karyawan full time yang bertanggung jawab atas hyperlink di help file.) Yang anehnya adalah saya berada di 'bawah' stuktur pelaporan. Betul. TIDAK ADA yang melapor ke saya. Jika saya ingin seseorang melakukan sesuatu, saya harus meyakinkan mereka bahwa itu merupakan hal yang benar untuk dilakukan. Saat Ben Waldman, pemimpin developer, tidak mau melakukan apa yang telah saya tulis di spec, dia tidak akan lakukan itu. Saat para tester mengeluh tentang hal yang saya tulis di spec tidak mungkin bisa di-test secara menyeluruh, saya harus menyederhanakannya. Jika orang-orang tersebut ada yang melapor ke saya, produk tersebut tidak akan sedemikian bagusnya. Mungkin beberapa dari mereka ada yang berpikir bahwa tidaklah tepat mempunyai dua atasan. Beberapa kejadian, saya harus turun tangan dan memerintahkan mereka untuk melakukannya dengan cara saya, menjelaskan tujuan yang sebenarnya. Seperti yang telah terjadi, saya tidak punya pilihan kecuali membuat sebuah konsensus. Bentuk pengambilan keputusan seperti ini merupakan hal yang terbaik untuk menyelesaikan hal yang benar.

Artikel terakhir dalam seri tentang spec akan menceritakan tentang bagaimana menulis spec yang bagus yang orang lain mau membacanya.



Artikel ini aslinya bahasa Inggris dengan judul Painless Functional Specifications Part 3  

Joel Spolsky adalah pendiri Fog Creek Software, sebuah perusahaan software kecil di New York City. Dia lulus dari Yale University, dan pernah bekerja sebagai programer dan manajer di Microsoft, Viacom, dan Juno.


Isi halaman-halaman ini mewakili opini dari satu orang.
Semua isi Hak Cipta ©1999-2005  dari Joel Spolsky. Hak Cipta dilindungi Undang-undang

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky