P6'da Constraint'ler: Ne Zaman Yardım Eder, Ne Zaman Yalan Söyler

Bir program bir modeldir. Onu model yapan şey mantıktır: baş tarafta bir şeyi değiştirirsiniz, sonuçları arka tarafa kendiliğinden ulaşır. Bir constraint ise bunu görmezden gelme talimatıdır — mantık ne derse desin, bir tarihi tutma emri.

Bazen bu talimat meşrudur. Denetlediğim programlarda çoğu zaman ise, yarının uyarısını susturarak bugünün sorununu çözen bir planlamacı vardır.

Constraint tipleri, iki grupta

P6 birkaç constraint tipi sunar; bunları sıralamanın işe yarar yolu alfabetik değil — verebilecekleri hasara göre sıralamaktır.

Soft constraint’ler tarihleri tek yönde kaydırır ve ağın tepki verme yeteneğini korur:

• Start On or After / Finish On or After — en erken tarihler. Aktivite belirli bir tarihten önce başlayamaz, ama mantık onu hâlâ ileri itebilir.
• Start On or Before / Finish On or Before — en geç tarihler. Erken tarihleri hiç oynatmazlar; tahmin o tarihi aştığı anda negative float üretirler. Bu bir kusur değil, bir özelliktir.
• As Late As Possible — aktiviteyi free float’ını tüketecek şekilde geri çeker.

Hard constraint’ler ağı ezer geçer:

• Start On / Finish On — tarihi iki yönde de sabitler.
• Mandatory Start / Mandatory Finish — en güçlü biçim. İlişki mantığını doğrudan çiğnerler. Öncül geç bitebilir; mandatory constraint’li aktivite yine de kendisine söylenen yerde, yukarıda hiçbir şey olmamış gibi oturmaya devam eder.

Bu son cümle, sorunun tamamıdır.

Constraint’in doğru cevap olduğu iki durum

Constraint karşıtı bir mutaassıp değilim. Constraint’e uzanmanın doğru mühendislik kararı olduğu iki durum var.

1. Kontrolünüzde olmayan gerçek bir dış kapı. Sabit tarihli şantiye erişimi, bilinen bir tarihten önce çıkamayacak bir izin, geldiği zaman gelen bir gemi. Start On or After bunu dürüstçe modeller: iş daha erken başlayamaz, ama proje kayarsa aktivite de diğer her şey gibi ileri kayar.

Burada bile önce tek bir soru sorun: bunu bir aktiviteyle modelleyebilir miyim? Gerçek öncülleri olan bir “İzin alındı” milestone’u, sonraki aktiviteye çakılmış bir tarihten daha zengin bir hikâye anlatır — çünkü gelecek ay izin geciktiğinde, program nedenini gösterir.

2. Karşısında ölçüm yapmak istediğiniz sözleşmesel bir termin. Kısmi teslim milestone’una konmuş bir Finish On or Before hiçbir şeyi oynatmaz. Sessizce oturur ve tahmininiz sözleşme tarihini aştığı anda negative float üretir. İstediğiniz alarm tam olarak budur — ve eklenmesini aktif olarak önerdiğim tek constraint tipi de bu.

Dikkat: ikisi de soft. İkisi de mantığı çiğnemez; ikisi de modelin size gerçeği söyleme yeteneğini korur.

Anti-pattern’ler

Eksik mantık yerine constraint. Aktivite martta başlamalı, ama bir öncül eksik olduğu için ağ mayıs diyor. Start On eklemek çubuk grafiği on saniyede düzeltir; eksik ilişkiyi eklemek on dakika alır ve programı düzeltir. Bir sonraki güncellemeden yalnızca biri sağ çıkar.

Toplantıda tarih savunmak için constraint. Program 3. çeyrekte bitiş göstermek zorunda; o hâlde bitiş sabitlenir. Sonraki her güncelleme “zamanında” raporlar — artık öyle olamayacağı bariz hâle gelen aya kadar. Hiç kötü haber göstermeyen programlar okunmaz olur; bu da planlamacı için kötü haberin kendisinden daha kötü bir sonuçtur.

Başkasından miras kalan mandatory constraint’ler. Alt yüklenicilerden gelen ya da şablondan kopyalanan programlarda çok yaygın. Onları kimse seçmedi; dosyayla birlikte geldiler ve ağın bazı parçalarını sessizce gerisinden koparıyorlar.

Her yerde As Late As Possible. Free float’ı sıfırlar; böylece her aktivite acil görünür, dolayısıyla hiçbir şey acil görünmez. Gerçek tam-zamanında işler için kullanın — sahada depolamak istemediğiniz teslimatlar gibi — başka hiçbir yerde değil.

Elinizde ne var, nasıl bulursunuz

İki alışkanlık, ikisi de ucuz:

1. Bir layout’a Constraint Type ve Primary Constraint Date kolonlarını ekleyin, sonra bunlara göre sıralayın. On saniye — ve projedeki her sabitlenmiş tarihi görürsünüz. Denetlediğim programların çoğunda planlamacı, listenin en az üçte birine şaşırıyor.
2. Her F9’dan sonra schedule log’u okuyun. P6 size kaç aktivitenin constraint taşıdığını, kaçında negative float olduğunu ve hangilerinin out-of-sequence hesaplandığını söyler. Üründeki en ucuz kalite raporudur ve neredeyse kimse açmaz.

Resmî bir eşik isterseniz: DCMA 14-Point Assessment sıfır hard constraint ve en fazla %5 soft constraint bekler. P6 Professional bu kontrolleri sizin yerinize çalıştırabilir — o da bir sonraki yazının konusu.

Denetimlerde uyguladığım test

Programdaki her constraint için tek soru: yukarıdaki iş bir ay kayarsa, bu tarih hâlâ anlamlı mı?

Cevap evetse — yerinden oynamaz bir dış kapı, karşısında ölçüm yaptığınız bir sözleşme tarihi — constraint işini yapıyordur. Cevap “şey, hayır, ama söz verdiğimiz tarih bu” ise, baktığınız şey bir constraint değildir. Bir temennidir; modele, modelin size itiraz etmesini engelleyecek biçimde yazılmış bir temenni.

Bunu koca bir programın genelinde ayıklamak, bir sistem ve program denetiminin gerçekte teslim ettiği şeyin büyük parçasıdır: bir ihlal listesi değil, gerçeğe yeniden tepki veren bir program.