Staged Delivery

[Angga Hantara]

Hi All,

Ada yang sudah pernah menerapkan konsep staged delivery(Steve Mcconel) dalam Project ?

Saya ada beberaa pertnaya mengenai model staged ini, 

Apakah staged di sini sama dengan milestone/delivery ? Atau staged seperti sub project dari project yang kita kerjakan.

  Jika staged ini milestone sepertinya waktu penagihan(Milestone terkait dengna penagihan) akan lama ke customer, dan untuk update kemajuan progress juga lama 

  Atau bisakah kita buat milestone di dalam stage seperti ini,   :

1. Stage 1 : Module Pembelian & Penerimaan Barang (Estimasi waktu : 4 Bulan)
   
1. Planning Pembelian Barang(Milestone 1)
2. Requirement(Milestone 2)
3. Coding & Testing (Milestone 3)
4. Implementasi (Milestone 4)
5. CLosing (Milestone 5)
   
   
2. Stage 2 : Module Stok Barang (Estimasi waktu 5 Bulan)
   
1. Planning Stok Barang(Milestone 6)
2. Requirement(Milestone 7)
3. Coding & Testing (Milestone 8)
4. Implementasi (Milestone 9)
5. CLosing (Milestone 10)

Atau ada rekomendasi / Golden rule waktu yang ideal untuk masing-masing task.

B. Apakah jumlah stage di define di depan atau akan di define ketika berjalan ? Misal kitad di stage 1 apakah kita sudah bisa me-define sampe stage terakhir atau hanya stage yang sudah dekat

Regards

                

[Andri Yudiamardana]

Kalau u soal ini, sepertinya yg jago itu spt Mas Endy.  Dari tulisannya ini : http://software.endy.muhardin.com/manajemen/manajemen-proyek-sederhana/ , beliau sudah melakukan di perusahaannya.

btw : untuk stage yg dibuat Angga, apakah tidak bisa di pecah lagi... menjadi 2 stage misalnya, menjadi stage yg bisa diselesaikan dalam 2 bulan.  Sehingga acceptancenya bisa dilakukan per 2 bulan.. :) 

Nego juga dgn customer, lingkup stage spt apa yg bisa diterima... mereka dpt value, angga dpt value jg. 

Maaf blm bisa banyak bantu. Cuma sedikit menghubungkan saja.

--
Anda menerima pesan ini karena berlangganan grup "Manajemen Proyek IT" di Google Grup.
Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk mengeposkan ke grup ini, kirim email ke it-project...@googlegroups.com.
Kunjungi grup ini di http://groups.google.com/group/it-project-indonesia.
Untuk opsi lebih lanjut, kunjungi https://groups.google.com/d/optout.

[Angga Hantara]

Thanks mas Andri buat artikelnya, saya coba baca-baca dulu artikel Mas Endy :D

Hmm untuk di pecah mungkin bisa jadi 2 Bulan , cuma kadang untuk user dia mau secepatnya kalo bisa 2 minggu. Tapi kalo dengan waktu pendek tersebut lingkupnya bisa tidak per modul lagi 

Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indonesia+unsub...@googlegroups.com.

[Endy Muhardin]

Staged Delivery itu seperti ini:

Tahap pertama : Requirement global dulu. diikuti dengan desain global. Memetakan big picture, menentukan modul2nya apa saja, integrasinya seperti apa. Ini untuk memastikan antar modul nantinya nyambung.

Kalau full iteratif, artinya requirement detail di masing-masing modul tanpa ada big picture, nanti takutnya pas implement modul ketiga/kelima-belas ternyata ada kesalahan fundamental di modul pertama karena tidak mempertimbangkan integrasi dengan modul-modul selanjutnya.

Penentuan fitur-fitur di tiap modul juga dilakukan di tahap ini.

Tentang integrasi bisa dibaca di sini:

http://software.endy.muhardin.com/java/prasyarat-integrasi-aplikasi/

Tahap kedua dst : 

- Requirement detail

- Desain detail

- Coding

- UAT

- Go Live

- Nagih invoice ;)

Dari sudut pandang cashflow dan penagihan, bisa diseimbangkan antara :

- kekuatan vendor nalangin gaji, dan

- usability aplikasi

Makanya pada waktu menentukan stage, fiturnya dipilih2 dengan pertimbangan:

- modulnya harus bisa go live dan dipakai user. Akan lebih mudah nagih kalau aplikasi udah siap pakai, dibandingkan cuma sekedar lulus tes aja.

- inter-dependensi antar modul. Jangan sampai misalnya modul sales udah dibikin, tapi gak bisa dipakai user karena modul inventory belum jadi. Akibatnya tidak bisa memenuhi poin sebelumnya.

Nah, PRnya PM untuk bisa merancang stage yang seimbang antara kemampuan finansial dan kepuasan customer. Jangan sampai terlalu besar sehingga lama selesai dan gak kunjung nagih, sebelum sempat selesai keburu kena change request.

Tapi jangan sampai terlalu kecil juga sehingga gak bermanfaat buat user dan gak bisa go live.

Idealnya, modul itu cepat selesai, segera go live, nagih, dibayar. Nah abis itu kalo ada change request tinggal dikasi penawaran lagi.

Yang cilaka itu kalau belum selesai, belum bisa ditagih, udah kena CR. Ini alamat never ending project dan never paid :((

Endy Muhardin
http://software.endy.muhardin.com

2014-12-18 13:05 GMT+07:00 Angga Hantara <angga....@gmail.com>:

--
Anda menerima pesan ini karena berlangganan grup "Manajemen Proyek IT" di Google Grup.

Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indon...@googlegroups.com.

[Sukma Wardana]

Endy Muhardin
http://software.endy.muhardin.com

Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indonesia+unsub...@googlegroups.com.

Untuk mengeposkan ke grup ini, kirim email ke it-project...@googlegroups.com.
Kunjungi grup ini di http://groups.google.com/group/it-project-indonesia.
Untuk opsi lebih lanjut, kunjungi https://groups.google.com/d/optout.

Mas endy boleh ikut tanya, itu semua fase dimana software bisa go live kan ya?

nah misal selang beberapa waktu klien minta ada perubahan pada software tersebut yang ingin saya tahu ketika programmer yang membuat software tersebut telah resign atau sedang dalam pengerjaan software besar lainnya sehinga mau tidak mau perubahan tersebut diserahkan kepada programmer lain. Nah agar programmer baru tersebut yang memang buta dengan software tersebut dapat segera paham dan dapat segera melakukan perubahan kira-kira dokumentasi atau desain software yang seperti bagaimana ya mas?

atau ada cara lain sehingga sebuah software dapat segera dimengerti oleh programmer yang memang belum pernah pegang software tersebut dalam waktu singkat?

terima kasih 

[Angga Hantara]

Pada Kamis, 18 Desember 2014 19:30:25 UTC+7, Endy Muhardin menulis:

Makanya pada waktu menentukan stage, fiturnya dipilih2 dengan pertimbangan:

- modulnya harus bisa go live dan dipakai user. Akan lebih mudah nagih kalau aplikasi udah siap pakai, dibandingkan cuma sekedar lulus tes aja.

- inter-dependensi antar modul. Jangan sampai misalnya modul sales udah dibikin, tapi gak bisa dipakai user karena modul inventory belum jadi. Akibatnya tidak bisa memenuhi poin sebelumnya.

 Berati untuk satu stage bisa beberapa Modul yah ? Misal Stage 1 Module Sales ,Modul Inventory, dan Module Resources yah . atau bisa tidak kalau cuma sebagian fitur module. Karena kalo untuk siap pakai aplikasinya kan depedensi bisa-bisa untuk satu stage 2-3 module. 

 

                

--
Anda menerima pesan ini karena berlangganan grup "Manajemen Proyek IT" di Google Grup.

Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indonesia+unsub...@googlegroups.com.

[Endy Muhardin]

2014-12-19 7:53 GMT+07:00 Sukma Wardana <sukmawa...@gmail.com>:

Mas endy boleh ikut tanya, itu semua fase dimana software bisa go live kan ya?

nah misal selang beberapa waktu klien minta ada perubahan pada software tersebut yang ingin saya tahu ketika programmer yang membuat software tersebut telah resign atau sedang dalam pengerjaan software besar lainnya sehinga mau tidak mau perubahan tersebut diserahkan kepada programmer lain. Nah agar programmer baru tersebut yang memang buta dengan software tersebut dapat segera paham dan dapat segera melakukan perubahan kira-kira dokumentasi atau desain software yang seperti bagaimana ya mas?

Kalo di ArtiVisi, orang keluar masuk project itu biasa banget.

Bisa aja hari ini di project A, besok ke project B.

Supaya bisa cepat pindah2 project, kuncinya ada di standarisasi.

Kita seragamkan framework, library, struktur folder, workflow, cara kerja, dsb.

Sehingga mau pindah project ya sesederhana close project lama, open project yang baru.

Untuk lebih jelasnya tentang standarisasi ini bisa dibaca di 

http://software.endy.muhardin.com/java/development-stack-2014/

 

atau ada cara lain sehingga sebuah software dapat segera dimengerti oleh programmer yang memang belum pernah pegang software tersebut dalam waktu singkat?

Di kita, kalau ada programmer baru masuk ke project, paling cuma dijelaskan aja proses bisnis yang harus dia implement codingnya. Udah gak ada pertanyaan lagi harus pakai Java atau PHP, Java-nya Spring atau EJB, bikin template Jasper Report harus ditaruh di folder mana, dan hal-hal teknis lainnya.

Endy Muhardin
http://software.endy.muhardin.com

[Endy Muhardin]

2014-12-19 9:25 GMT+07:00 Angga Hantara <angga....@gmail.com>:

Pada Kamis, 18 Desember 2014 19:30:25 UTC+7, Endy Muhardin menulis:

Makanya pada waktu menentukan stage, fiturnya dipilih2 dengan pertimbangan:

- modulnya harus bisa go live dan dipakai user. Akan lebih mudah nagih kalau aplikasi udah siap pakai, dibandingkan cuma sekedar lulus tes aja.

- inter-dependensi antar modul. Jangan sampai misalnya modul sales udah dibikin, tapi gak bisa dipakai user karena modul inventory belum jadi. Akibatnya tidak bisa memenuhi poin sebelumnya.

 Berati untuk satu stage bisa beberapa Modul yah ? Misal Stage 1 Module Sales ,Modul Inventory, dan Module Resources yah . atau bisa tidak kalau cuma sebagian fitur module. Karena kalo untuk siap pakai aplikasinya kan depedensi bisa-bisa untuk satu stage 2-3 module. 

Iya begitu. Diusahakan tiap selesai stage go live dan nagih invoice. 

Jadinya win-win.

Satu stage isinya berapa modul ya sesuai situasi aja.

Misalnya stage 1 isinya Modul User Management dan Modul Sales.

Karena untuk bisa running Sales, ya tentu harus bisa login dulu.

Nanti stage 2 cuma Modul Inventory. Stage 3 dst masing-masing stage satu modul.

Bisa juga implement parsial.

Misalnya supaya bisa go live, yang dikerjain transaksi pembelian barang sampai masuk gudang dulu.

Itu kan lintas modul fungsional.

Jadi paling enak baginya jangan stage X modulnya apa.

Tapi stage X deliver fitur apa aja.

Endy Muhardin
http://software.endy.muhardin.com

[adama...@gmail.com]

Tahap pertama : Requirement global dulu. diikuti dengan desain global. Memetakan big picture, menentukan modul2nya apa saja, integrasinya seperti apa. Ini untuk memastikan antar modul nantinya nyambung.

Kalau full iteratif, artinya requirement detail di masing-masing modul tanpa ada big picture, nanti takutnya pas implement modul ketiga/kelima-belas ternyata ada kesalahan fundamental di modul pertama karena tidak mempertimbangkan integrasi dengan modul-modul selanjutnya.

Penentuan fitur-fitur di tiap modul juga dilakukan di tahap ini.

Tentang integrasi bisa dibaca di sini:

http://software.endy.muhardin.com/java/prasyarat-integrasi-aplikasi/

Tahap kedua dst : 

- Requirement detail

1. Kalo beda Requirement global dan requirement detail bagaimana Pak Endy ? Kalo template user story yang pak endy di artiviss gunakan itu selesai di tahap requirement global atau detail.
   
   
2. Kesepakatan berapa stage yang ada dalam suatu project akan di bahas di requirement global atau setelah selesai setiap stage Pak ? Karena kalau di waterfall waktu KICK OFF meeting sudah kita jabarkan project planningnya sampai selesai, kalo di staged delivery untuk me-break down stage berikutnya saja masih belum jelas .
   

[Angga Hantara]

1. Kalo beda Requirement global dan requirement detail bagaimana Pak Endy ? Kalo template user story yang pak endy di artiviss gunakan itu selesai di tahap requirement global atau detail.
   

Kalo di saya requirement global itu modul apa saja yang akan di bangun, requirement detail itu ada fitur apa saja .

Contoh :               - Modul User Management

                                  a. Fitur Add User

                                  b. Fitur Edit User

                                  c. Fitur Delete User

                                   ..... dan seterusnya

 

1. 
   
2. Kesepakatan berapa stage yang ada dalam suatu project akan di bahas di requirement global atau setelah selesai setiap stage Pak ? Karena kalau di waterfall waktu KICK OFF meeting sudah kita jabarkan project planningnya sampai selesai, kalo di staged delivery untuk me-break down stage berikutnya saja masih belum jelas .
   

Untuk yang no 2 memang waktu kick off meeting itu project planning  awal sebagai baseline, tapiselama proyek berjalan kan akan terus kita update. Setelah requirement global kalo fitur sudah terkumpul harusnya sudah tahu ada berapa stage tahap pertama.

Yang saya bingung bagaiman me-break down fitur-fitur tersebut menjadi task , karena kalo di tentuin di awal agak susah karena masih sangat rancu  

[adama...@gmail.com]

Kalo di saya requirement global itu modul apa saja yang akan di bangun, requirement detail itu ada fitur apa saja .

Contoh :               - Modul User Management

                                  a. Fitur Add User

                                  b. Fitur Edit User

                                  c. Fitur Delete User

                                   ..... dan seterusnya

Maksudnya bgmn mas Angga ?
Req Global itu menentukan modul dan req detail menentukan fitur ?

Untuk yang no 2 memang waktu kick off meeting itu project planning  awal sebagai baseline, tapiselama proyek berjalan kan akan terus kita update. Setelah requirement global kalo fitur sudah terkumpul harusnya sudah tahu ada berapa stage tahap pertama.

Yang saya bingung bagaiman me-break down fitur-fitur tersebut menjadi task , karena kalo di tentuin di awal agak susah karena masih sangat rancu  

Waduh bingung jadinya , kalau kita kasih waktu pekerjaan di kick off meeting bukannya komitmen harus selesai  di tanggal yang di kasih ? klo tdk akan kena penalti

[adama...@gmail.com]

Apakah kita bisa merubah durasi proyek yg ada di kontrak kerja ? Misal kerja 1 tahun dan proyek akan telat karena bukan kesalahan customer apa bisa kita rubah project plan ?

[Endy Muhardin]

2014-12-22 9:47 GMT+07:00 <adama...@gmail.com>:

1. Kalo beda Requirement global dan requirement detail bagaimana Pak Endy ? Kalo template user story yang pak endy di artiviss gunakan itu selesai di tahap requirement global atau detail.
   

Template User Story itu requirement detail.

Requirement global itu daftar fitur di tiap modulnya apa saja, dan bagaimana integrasi antar modul.

Lebih jauh tentang integrasi bisa dibaca di sini:

http://software.endy.muhardin.com/java/integrasi-aplikasi/

Requirement detail berisi detail proses bisnis, screen, tipe data, validasi, dsb, untuk masing-masing fitur.

Sebagai contoh, requirement global seperti ini

Modul Sales

* Master Customer

* Transaksi Penjualan

* Transaksi Retur

* Transaksi Pengiriman Barang

* Pembayaran

Sedangkan requirement detail isinya user story transaksi penjualan. Field apa saja yang ada di transaksi penjualan, tipe datanya apa, sistem approvalnya seperti apa.

 

1. 
   
2. Kesepakatan berapa stage yang ada dalam suatu project akan di bahas di requirement global atau setelah selesai setiap stage Pak ? Karena kalau di waterfall waktu KICK OFF meeting sudah kita jabarkan project planningnya sampai selesai, kalo di staged delivery untuk me-break down stage berikutnya saja masih belum jelas .
   

Berapa stage dibahas sebelum projectnya mulai, yaitu di tahap penawaran. Di situ kan nanti disepakati projectnya akan di-deliver dalam berapa tahap.

Endy Muhardin
http://software.endy.muhardin.com

[Endy Muhardin]

2014-12-22 17:20 GMT+07:00 <adama...@gmail.com>:

Apakah kita bisa merubah durasi proyek yg ada di kontrak kerja ? Misal kerja 1 tahun dan proyek akan telat karena bukan kesalahan customer apa bisa kita rubah project plan ?

Coba baca http://software.endy.muhardin.com/manajemen/fase-requirement/

Khususnya bagian Change Management.

Yang namanya project plan itu ya sekedar rencana.

Kalau ada yang tidak sesuai dengan rencana, ya tentunya sisa rencananya harus diupdate dan dilaporkan ke manajemen kita dan manajemen client.

Tiap satu bulan update project plan juga gpp.

Endy Muhardin
http://software.endy.muhardin.com

[adama...@gmail.com]

Jadi kalau bisa berubah gitu akan tidak sama dengan kontrak yah ? Msal di kontrak proyek di tuliskan jangka waktu POS selama "6 Bulan" . Jika durasi proyek bertambah kontrak di awal kerja harus di update dong. Karena di penulisan kontrak awal kerja kan biasanya komitmen pekerjaan kita tidak estimasi

Maaf yah pertanyaan masih newbie banget

[Angga Hantara]

Jadi kalau bisa berubah gitu akan tidak sama dengan kontrak yah ? Msal di kontrak proyek di tuliskan jangka waktu POS selama "6 Bulan" . Jika durasi proyek bertambah kontrak di awal kerja harus di update dong. Karena di penulisan kontrak awal kerja kan biasanya komitmen pekerjaan kita tidak estimasi

manajemen perubahan di masukkan ke dalam Kontrak kerja aja. Jadi kalo ada perubahan waktu tinggal di update sesaui prosedur perubaha.

@Mas Endy,

Untuk buffer time di staged delivery di tambah ke setiap stage atau di akhir aja Mas endy ?

Biasanya kalo di Waterfall saya tambahkan di paling akhir task dengan nama buffered time

Contoh di waterfall

Design

  task 1

  task 2

  task 3

Coding & Testing

  task 1

  task 2

  task 3

Implementation & Closing

  task 1

  task 2

  task 3

BUFFERED TIME

[Endy Muhardin]

On Dec 23, 2014 3:49 PM, "Angga Hantara" <angga....@gmail.com> wrote:
>>
>> Jadi kalau bisa berubah gitu akan tidak sama dengan kontrak yah ? Msal di kontrak proyek di tuliskan jangka waktu POS selama "6 Bulan" . Jika durasi proyek bertambah kontrak di awal kerja harus di update dong. Karena di penulisan kontrak awal kerja kan biasanya komitmen pekerjaan kita tidak estimasi

Di kontrak kerja dikasi klausul, durasi pekerjaan bersifat estimasi dan bisa berubah sesuai perkembangan di lapangan.

Tambahkan juga klausul prosedur change request.

> @Mas Endy,
> Untuk buffer time di staged delivery di tambah ke setiap stage atau di akhir aja Mas endy ?

Kalo saya prefer gak pake buffer.
Tapi update schedule tiap minggu.
Di progress review mingguan dibahas asumsi/estimasi yang ternyata gak sesuai, dan perubahan (kalau ada) terhadap schedule dan cost.

-
Endy Muhardin
http://software.endy.muhardin.com/about

[Sukma Wardana]

Buat semua yang menggunakan staged delivery setelah saya baca-baca terutama dari situsnya pak endy saya jadi tertarik untuk ikut menggunakannya dalam pengembangan software. Tapi jujur selama ini saya bekerja di kantor tidak ada yang seperti ini, ada project masuk, dianalisa kebutuhannya lalu langsung kerjakan. Padahal dulu di bangku kuliah saya mendapatkan ilmu mengenai development software, namun yang saya dapat adalah metode waterfall. Jadi saya ingin tahu untuk staged delivery dokumen yang dihasilkan apa saja dan seperti bagaimana bentuknya ya? lalu untuk diagram yang perlu dibuat selama pengerjaan apa saja ya? Soalnya dulu yang saya tahu dokumen dan diagram berfungsi penting ketika akan deployment, revisi dan ketika terjadi maintenance

terima kasih 

 

[Endy Muhardin]

2015-01-23 5:06 GMT+07:00 Sukma Wardana <sukmawa...@gmail.com>:

Buat semua yang menggunakan staged delivery setelah saya baca-baca terutama dari situsnya pak endy saya jadi tertarik untuk ikut menggunakannya dalam pengembangan software. Tapi jujur selama ini saya bekerja di kantor tidak ada yang seperti ini, ada project masuk, dianalisa kebutuhannya lalu langsung kerjakan. Padahal dulu di bangku kuliah saya mendapatkan ilmu mengenai development software, namun yang saya dapat adalah metode waterfall.

Di kuliah : teori

Di kantor : praktek

Teori dan praktek biasanya beda, karena di lapangan banyak faktor2 kompromi sesuai keadaan.

Sebagai contoh, emang di kuliah dibahas gimana kalau subject matter expert nya cuti, resign, sakit, dsb?

 

Jadi saya ingin tahu untuk staged delivery dokumen yang dihasilkan apa saja dan seperti bagaimana bentuknya ya? lalu untuk diagram yang perlu dibuat selama pengerjaan apa saja ya? Soalnya dulu yang saya tahu dokumen dan diagram berfungsi penting ketika akan deployment, revisi dan ketika terjadi maintenance

Coba baca ini
http://software.endy.muhardin.com/manajemen/dokumentasi-project/

Mengenai dokumentasi, gak ada yang baku. 

Tergantung kondisi tim, permintaan client, jenis project, dan lain sebagainya.

Endy Muhardin
http://software.endy.muhardin.com

[Sukma Wardana]

On Sunday, January 25, 2015 at 9:51:57 AM UTC+7, Endy Muhardin wrote:

Di kuliah : teori

Di kantor : praktek

Teori dan praktek biasanya beda, karena di lapangan banyak faktor2 kompromi sesuai keadaan.

Sebagai contoh, emang di kuliah dibahas gimana kalau subject matter expert nya cuti, resign, sakit, dsb?

Coba baca ini
http://software.endy.muhardin.com/manajemen/dokumentasi-project/

Mengenai dokumentasi, gak ada yang baku. 

Tergantung kondisi tim, permintaan client, jenis project, dan lain sebagainya.

Endy Muhardin
http://software.endy.muhardin.com

Terima kasih buat penjelasannya pak endy, ini saya lagi baca-baca semua artikel bapak yang kategori manajemen, sepertinya banyak yang bisa di aplikasikan untuk membangun sebuah aplikasi. Tapi pak endy saya masih belum menemukan sebuah kasus yang misal bagaimana ketika sebuah aplikasi sudah go live dan serah terima tapi selang beberapa bulan minta ada perubahaan.

apakah itu masuk dalam membuat aplikasi baru? atau masuk dalam revisi project? nah kalau masuk dalam revisi project bagaimana ya untuk mentrace sebuah project yang memang sudah di serah terima (istilahnya sudah jarang di pegang oleh programmer)?

terima kasih 

[Endy Muhardin]

2015-01-26 21:35 GMT+07:00 Sukma Wardana <sukmawa...@gmail.com>:

 

Tapi pak endy saya masih belum menemukan sebuah kasus yang misal bagaimana ketika sebuah aplikasi sudah go live dan serah terima tapi selang beberapa bulan minta ada perubahaan.

apakah itu masuk dalam membuat aplikasi baru? atau masuk dalam revisi project? nah kalau masuk dalam revisi project bagaimana ya untuk mentrace sebuah project yang memang sudah di serah terima (istilahnya sudah jarang di pegang oleh programmer)?

Intinya sih begini : kalau kita diminta mengerjakan sesuatu, maka kita idealnya dibayar untuk itu.

Misalnya kita sudah sepakat dengan client, mengerjakan sesuatu (misalnya 10 fitur) dibayar 100 juta.

Kalau di tengah jalan clientnya minta tambah 2 fitur, ya tentu harus ada tambahan biaya untuk 2 fitur tersebut.

Demikian juga kalau sudah selesai 10 fitur, kemudian clientnya minta tambah 3 fitur atau ubah 4 fitur, ya tentu kita masukkan penawaran harga dan schedule seperti biasanya.

Mentrace project maksudnya gimana ya? Saya gak paham pertanyaannya.

Di ArtiVisi, semua source code tersimpan di version control. Di situ tercatat siapa saja yang berkontribusi, baris mana yang dia edit, kapan diedit, kenapa diedit, dan sebagainya.

Contohnya bisa dilihat di sini:

https://github.com/endymuhardin/belajar-restful/commits/master

Kita juga usahakan menyeragamkan teknologi yang digunakan, seperti sudah saya jelaskan di sini:

http://software.endy.muhardin.com/java/development-stack-2014/

Dengan demikian, mau diterjunkan di project manapun, semua programmer tidak kesulitan beradaptasi, karena semuanya konsisten:

- struktur foldernya

- cara compilenya

- library yang digunakan

- arsitekturnya

Endy Muhardin
http://software.endy.muhardin.com

 

[adama...@gmail.com]

Makasih buat sharenya Om Endy,

Tapi di proyek selalu terjadi kita sampaikan perkiraan tetapi customer me-anggap sebagai target/komitmen yang harus di capai Pak . Apakah ada tips untuk bilang ke customer ?

beberapa customer ketika melihat kebanyakan anti melihat kata 'estimasi', 'prakiraan'.

[Endy Muhardin]

Untuk lebih lengkapnya bisa baca buku estimasi karangan Steve McConnell, judulnya Software Estimation, Demystifying the Black Art

Beberapa poin dari buku itu:

- bedakan antara estimasi (perkiraan selesai), target (keinginan kita), dan komitmen (janji kita). Ketiga hal ini tidak harus selalu sama.

- estimasi itu tidak cukup hanya dihitung, tapi juga harus dipresentasikan dengan benar

Endy Muhardin
http://software.endy.muhardin.com

--

[adama...@gmail.com]

Maksh Om Endy untuk referensi bukunya :d.

Kemarin sudah aku baca Om beberapa chapter awal belum semua.

Dari buku berati kita diharuskan membagi 3 hal tersbut(estimasi, target, komitmen).

Berarti ketika memulai proyek sebelum membuat kontrak kita harus  :
a. pertama kita menentukan target dari proyek ini, Contoh : Proyek harus selesai sebelum idul fitri,
b. Selanjutnya kita gunakan estimasi untuk menentukan apakah target tersebut layak dan dapat dikerjakan.
c. Tearkhir dari data estimasi dan target kita membuat komitmen ,

Jadi Perjanjian yang ada di kontrak kerja ini berdasarkan komitmen/promised date yah Pak Endy.

On Monday, February 2, 2015 at 12:11:24 PM UTC+7, Endy Muhardin wrote:

Untuk lebih lengkapnya bisa baca buku estimasi karangan Steve McConnell, judulnya Software Estimation, Demystifying the Black Art

Beberapa poin dari buku itu:

- bedakan antara estimasi (perkiraan selesai), target (keinginan kita), dan komitmen (janji kita). Ketiga hal ini tidak harus selalu sama.

- estimasi itu tidak cukup hanya dihitung, tapi juga harus dipresentasikan dengan benar

Endy Muhardin
http://software.endy.muhardin.com

--

Anda menerima pesan ini karena berlangganan grup "Manajemen Proyek IT" di Google Grup.

Untuk berhenti berlangganan dan berhenti menerima email dari grup ini, kirim email ke it-project-indonesia+unsub...@googlegroups.com.

[Endy Muhardin]

2015-02-03 9:54 GMT+07:00 <adama...@gmail.com>:

Maksh Om Endy untuk referensi bukunya :d.

Kemarin sudah aku baca Om beberapa chapter awal belum semua.

Dari buku berati kita diharuskan membagi 3 hal tersbut(estimasi, target, komitmen).

Sebenarnya bukan harus membagi 3, tapi cukup disadari aja.

Pada waktu kita dapat angka (misalnya) 6 bulan, kita harus pahami dulu angka itu apa.

Apakah estimasi, target, atau komitmen?

Jangan sampai kita anggap estimasi, tapi karena salah menyampaikan lalu dianggap komitmen sama client.

 

Berarti ketika memulai proyek sebelum membuat kontrak kita harus  :
a. pertama kita menentukan target dari proyek ini, Contoh : Proyek harus selesai sebelum idul fitri,
b. Selanjutnya kita gunakan estimasi untuk menentukan apakah target tersebut layak dan dapat dikerjakan.
c. Tearkhir dari data estimasi dan target kita membuat komitmen ,

Jadi Perjanjian yang ada di kontrak kerja ini berdasarkan komitmen/promised date yah Pak Endy.

Nah iya bener seperti itu.

Diterusin ya baca bukunya, di bagian selanjutnya ada cara-cara menyampaikan estimasi supaya gak salah paham dan bisa diterima client.

Endy Muhardin
http://software.endy.muhardin.com

[Angga Hantara]

Kadang juga suka ada hidden effort ketika sudah kita berikan komitmen.

PM A : Berapa lama untuk fitur X ?

Developer : 3 hari (setelah di hitung waktu untuk rapat, ngoding dll)

Besoknya ,secara mendadak ada PM lain yang minta tolong atau di suruh ikut meeting mendadak.

[Endy Muhardin]

2015-02-06 16:50 GMT+07:00 Angga Hantara <angga....@gmail.com>:

Nah tugasnya PM itu kan gak cuma bikin plan. 

Tapi juga memastikan plan berjalan sesuai harapan.

Antar PM bertengkar rebutan orang itu perkara biasa.

Soalnya tiap PM kan pengen projectnya berjalan sesuai plan.

Kalo orangnya ditarik PM lain ya dipertahankan lah, masa dibiarin aja ;)

Endy Muhardin
http://software.endy.muhardin.com

[Angga Hantara]

waduh kalo di tempat saya sudah di buat priorrity customer dan issue oleh program manager jadi kalo ada issue dari customer dengan priorty tertinggi kita gag bsa defend :(

di post sebelumnya pak Endy bilang kalau tidak menggunakan buffer , kalau tidak menggunakan buffer bagaimana memassukan waktu holiday,sakit,izin,cuti,dan hal2 tak twrduga lainnya seperti kata om joel[1] pak Endy ?


[1]http://www.joelonsoftware.com/articles/fog0000000245.html

[Endy Muhardin]

2015-04-12 8:57 GMT+07:00 Angga Hantara <angga....@gmail.com>:

waduh kalo di tempat saya sudah di buat priorrity customer dan issue oleh program manager jadi kalo ada issue dari customer dengan priorty tertinggi kita gag bsa defend :(

Gak paham maksud pernyataan di atas.

 

di post sebelumnya pak Endy bilang kalau tidak menggunakan buffer , kalau tidak menggunakan buffer bagaimana memassukan waktu holiday,sakit,izin,cuti,dan hal2 tak twrduga lainnya seperti kata om joel[1] pak Endy ?

Holiday kan bukan sesuatu yang mendadak ya?

Misalnya lebaran atau tahun baru, itu kan dari jauh2 hari udah bisa diketahui, sehingga bisa diplanning sejak awal.

Tingga PMnya aja yang harus waras, kalo pas jatuh bulan puasa, hari kerja dalam sebulan jangan dihitung 20, tapi ya hitung 10.

Cuti juga sebetulnya sesuatu yang terencana. Di banyak perusahaan, pengajuan cuti gak boleh mendadak, harus 2 minggu sebelumnya minimal. Nah begitu ada yang mengajukan cuti, ya PMnya udah siap2 cadangan siapa yang bakalan gantiin. Karena waktunya 2 minggu, ya siap2 dulu lah.

Gimana kalo hal tidak terduga? Ini merupakan resiko project. Yang namanya resiko harus ada risk management. Yang namanya project plan itu bukan cuma schedule dan estimasi. Ada juga risk planning. PM harus mengidentifikasi potensi masalah di kemudian hari. Dari potensi masalah tersebut, harus ada mitigation plan dan contigency plan.

Mitigation : usaha preventif supaya risk tidak terjadi

Contigency : action yang dilakukan pada waktu risk benar-benar terjadi.

Menurut saya sih, orang sakit dan cuti itu bukan sesuatu yang tidak terduga. Mesin aja bisa rusak, apalagi manusia.

Jadi PM ya harusnya udah menyiapkan budget orang sakit sekian mandays per bulan. Budget di sini maksudnya, orang sakit itu udah dianggap kepastian aja, sehingga disiapkan backup programmernya.

IMHO, di sinilah bedanya PM pengalaman dan PM pemula. PM pemula biasanya naif, mengasumsikan semua berjalan sesuai plan. PM pengalaman biasanya skeptis, sehingga punya backup plan untuk semua kondisi.

Kalo mau jadi PM handal, saya sarankan kamu banyak-banyak nonton serial Hustler, Leverage, Burn Notice, dan Prison Break. Film bioskopnya bisa nonton Ocean Eleven dan sekuel-sekuelnya.

--

Endy Muhardin
http://software.endy.muhardin.com

[Angga Hantara]

maksudnya begini Pak Endy , kalo di company saya sudah di atur mengenai prioritas customer. Jadi customer dengan prioritas tertinggi akan mendapatkan service yang lebih utama.

Jadi jika developer kita di butuhkan untuk mengatasi issue dari project yang customernya nya memiliki prioritas tertinggi yah harus rela untuk terganggu jadwalnya,

karena itu biasanya saya pake buffer :( untuk handle masalah ini.

Thank Pak Endy masukkannnya , memang masih pemul banget pak dalam PM saya. dari film yang di sebutin diatas yang sudah saya tonton baru Prison Break doang sama Ocean Eleven :D

[Endy Muhardin]

2015-04-13 10:59 GMT+07:00 Angga Hantara <angga....@gmail.com>:

maksudnya begini Pak Endy , kalo di company saya sudah di atur mengenai prioritas customer. Jadi customer dengan prioritas tertinggi akan mendapatkan service yang lebih utama.

Jadi jika developer kita di butuhkan untuk mengatasi issue dari project yang customernya nya memiliki prioritas tertinggi yah harus rela untuk terganggu jadwalnya,

karena itu biasanya saya pake buffer :( untuk handle masalah ini.

Ya maksud saya, secara umum, s**t happens.

Jadi ya tinggal dilist apa saja kemungkinan s**t yang mungkin terjadi, trus bikin mitigation dan contigency nya.

 

Thank Pak Endy masukkannnya , memang masih pemul banget pak dalam PM saya. dari film yang di sebutin diatas yang sudah saya tonton baru Prison Break doang sama Ocean Eleven :D

Dari semua film di atas, pesan moralnya cuma satu, yaitu s**t happens ;)

Coba googling apa itu Murphy Law

Endy Muhardin
http://software.endy.muhardin.com