Destek konularını açıklarken projeleri gerçekçi bir şekilde nasıl planlayabiliriz?

İş yerinde bir sorun yaşıyoruz: zaman ölçeklerini değerlendirebilmemiz ve son tarihler alabilmemiz için işi planlamaya çalışıyoruz.

Sorun şu ki, gerçekleşecek her şeyi bilmeden bir proje planlamak zor.

Örneğin, şu anda tüm projelerimizi Aralık ayı başlarında planladık, ancak o zaman kurum içi ve şirket dışı toplantılar, telekonferanslar ve ekstra işler yapacağız. Bir projenin üç hafta süreceğini söylemek iyi ve iyidir, ancak o zaman bir hafta kesinti varsa, tamamlanma tarihi bir hafta geri itilecektir.

Sorun 3 kattır:

1. Projeleri planladığımızda zaman ölçekleri tam anlamıyla alınır. Üç haftayı tahmin edersek, son tarih üç haftanın süresi için belirlenir, müşteriye söylenir ve uzatma için yer yoktur.

2. Ara çalışma ve bu şekilde proje üzerinde çalışırken verimli zaman kaybettiğimiz anlamına gelir.

3. Bazen müşteriler işi yapmak için ihtiyacımız olan zamana sahip değildir, bu yüzden bazen bize gelirler ve işin iki ay süreceğini düşündüğümüzde bile ay sonuna kadar yapılan bir projeye ihtiyaçları olduğunu söylerler - Yapmamız gereken çok işimiz olduğundan bahsetmiyorum bile.

Sahip olduğumuz tüm projelerle doldurmaya çalıştığımız bir Gantt şemamız var ve zaman çizelgelerini dolduruyoruz, ancak bunlar Gantt şemasıyla karşılaştırılmıyor. Bu, "Peki, bu proje için 3 hafta planladık, ancak burada bir hafta kaybettik, bu yüzden son tarih bir hafta geri gitmeli."

Ayrıca, istemciye ilettiğimiz son tarihleri ​​kaçırmamak da profesyonel değil.

Diğer insanlar bu tür bir durumla nasıl başa çıkıyor? Proje planlamasını nasıl yönetiyorsunuz? Bir proje sırasında meydana gelen proje dışı işleri hesaba katmak için bir projeye ne kadar "ekstra" zaman planlıyorsunuz? Destek sorunları, hatalar ve diğer şeylerle nasıl başa çıkıyorsunuz? Planlama sırasında açıklayamayacağınız şeyler?

GÜNCELLEME

Çok iyi cevaplar teşekkür ederim.

Sorun şu ki, gerçekleşecek her şeyi bilmeden bir proje planlamak zor.

Risk yönetiminin konusu budur. Her şeyi bilemezsiniz, böylece bildiklerinize dayanarak plan yaparsınız ve planınız üzerinde neyin en fazla etkisi olabileceğini ve bunların ne kadar olası olduğunu tanımlarsınız. Potansiyel program etkisini de X'in gerçekleşmesi durumunda programın tahmini (anahtar kelime - tahmini) Y gün veya hafta kadar kaymasına neden olacağını söyleyerek değerlendirin.

Bir projenin 3 hafta alacağını söylemek iyi,

Asla böyle bir tahminde bulunmayın. Bir aralık verin veya bu tahminde bulunma olasılığını ölçün. Örneğin, "bu proje 2-5 hafta sürecek" veya "bu projenin 3 haftada% 85, 4 haftada% 95 şansı var" deyin.

Ayrıca son teslim tarihini kaçırdığımızı söylemeye devam etmek müşteriye profesyonel değil.

Doğru. Ancak, "tahmin", "zamanlama" ve "son tarih" kavramlarını karıştırıyorsunuz. Tahmininiz, belirli bir görevi veya projeyi bitirmenin ne kadar süreceği ve bunu yerine getirme olasılığının yaklaşık bir tahminidir. Son tarih, değer katmak için projenin yapılması gereken müşteri tarafından belirlenen bir tarihtir. Program, son teslim tarihinizi karşılamak için mevcut kaynaklarınızı nasıl kullandığınızdır.

Atanan işi bir son tarihte bitirmenin mümkün olmadığı zamanlar vardır ve dünyadaki tüm tahmin ve çizelgeleme bir fark yaratmayacaktır.

Peki sorum ... diğer insanlar bunu nasıl yapıyor? Proje planlamasını nasıl yönetiyorsunuz? Bu süre zarfında meydana gelen her şeyi hesaba katmak için bir projeye ne kadar "ekstra" zaman planlıyorsunuz?

Steve McConnell'in iki kitap okumasını öneriyorum: Yazılım Tahmini: Siyah Sanatın Demststifiye Edilmesi ve Hızlı Gelişim: Vahşi Yazılım Programlarını Taming . Yazılım Tahmini, tahminlerinizi bulmak, müşterilere sunmak ve pazarlığın bazı yönlerini ve gerçekçi olmayan beklentilerle uğraşmakla ilgilidir. Rapid Development genel yaşam yönetimi, geliştirme yaşam döngüleri, zamanlama, kaynak tahsisi ve tahminlerinize ve son teslim tarihlerinize ulaşmak için projelerin en iyi şekilde nasıl planlanacağı ve bütçeleneceği ile ilgilenir.

Scrum geliştirme süreci ayrıntılarını incelemenizi öneririm . focus factorMetriğin bu gibi yan izleme faaliyetlerini kapsar . Temel olarak 2-3 sprint / iterasyon çalışması yapmalı ve daha sonra ekibinizin odak faktörünü ölçmelisiniz (ve her üye için de yararlı olacaktır). Bundan sonra günlük aktiviteyi kapsayan daha doğru tahminler sağlayabileceksiniz.

Bu makaleye bir göz atın - "Odak faktörü"

Herhangi biriniz Agile gelişimine aşina iseniz, muhtemelen odak faktörünü (veya verimlilik faktörünü) duymuşsunuzdur. Bir şey üzerinde kaç “gerçek saat” çalışması gerektiğini belirlemenize yardımcı olmak için kullanılır. “Gerçek saatler” ile “ideal saatler” arasındaki farktır.

Kesintilerle ilgili şey, belirli kişiler veya takımlar için nispeten küçük bir olasılık aralığında olma eğilimindedir. Örneğin, her hafta yaklaşık aynı sayıda toplantınız veya her ay acil hata düzeltmeleri için harcanan aynı saat sayısı veya masanızdan ayrılan kişiler için, özellikle de ortalamanın üzerinde olduğunda, soruları cevaplamak için harcadığınız süre kadar uzun bir süre.

Birçok modern zamanlama tekniği bunu dikkate alır. Scrum onu ​​hıza çarpar. Kanıta dayalı çizelgeleme, belirli bir tahmin için güven aralığı olan bir hız kullanır. Pomodoro, herhangi bir haftada ne kadar "pomodoros" tamamlayacağınıza karar verdiğinizde kesintileri dikkate alır. Bütün bunlar kesintilerinizin tarihsel ölçümlerini izlemeye ve bunları bir şekilde tahminlerinize katmaya bağlıdır. Hepsine bir göz atmanızı ve ekibiniz için işe yarayacak bir teknik geliştirmenizi tavsiye ederim.

Her yerde iyi tavsiye.

Destek sorunlarıyla başa çıkmada yardımcı olabilecek bir diğer şey de, insanları sabit bir "round-robin" temelinde desteklemeye adamaktır.

Örneğin, haftanın her gününe bir tane atayan 5 geliştiriciniz varsa. O gün geldiğinde, atanan geliştirici SADECE destek için o gün çalışır. Ertesi gün başka bir geliştirici destek alıyor. Bu şekilde herkesin "akışında" kalma şansı olur, herkes test ürünlerinin tadını alır.

GERÇEKTEN düzenli destek işini bölmeyi nasıl seçtiğiniz gerçekten önemli değil (haftanın günleri olan robin sadece bir örnektir). Önemli olan, destek süresini sabit düzenli aralıklarla sınırlamaktır. Bu, destek sorunlarıyla başa çıkmak için "herkesin her şeyi bırakması" ile değiştirilemediği değiş tokuş ile kalkınma süresini daha öngörülebilir kılar.

Bu gerçekten deneyimle gelen bir beceridir ve çoğu zaman insanlara böyle bir şeyi doğru bir şekilde yargılayabilmeleri için sorulur. Her zaman gayri resmi bir tarza sahip oldukça sıkı sıkıya bağlı bir grupta çalıştım, ancak iyi dayanıyor gibi görünen birkaç kural geliştirdik.

İlk olarak, hiçbir görev bir haftadan az sürmez. Bir görevin tamamlanması birkaç gün sürecek gibi görünse bile, her zaman hafta olarak tahmin edin. Hafta sonundan önce yapılmamasının bir nedeni olacak.

İkincisi, kesintiler, müşteri destek sorunları, testten geçirme vb. Dahil olmak üzere görevin ne kadar zaman alacağını tahmin etmek için elinizden geleni yapın. Şimdi, bu sayıyı iki katına çıkarın. Bu sizin tahmininiz (hafta olarak).

Üçüncü olarak, yöneticinizin tahminlerinize zaten bir miktar dolgu eklemediğinden emin olun. Ekibimizin tahminlerimizden şikayet eden bir yöneticisi vardı. Zaten 2.1 ile (ampirik olarak türetilen dolgu tahmini) çarpacağı ortaya çıktı ve ona söylemeden önce ikiye katlamıştık.

Süslü bir araç değildir ve mükemmel bir yöntem olmayabilir, ancak şaşırtıcı derecede iyi çalışır.

Tahmin ihtiyacını yapıyor insanlar hiçbir takım olduğunu anlamak için hiç bir proje üzerinde% 100. Hastalık izni, tatil, jüri görevi, yas izni, gerekli İK toplantıları (faydalar zamanı!), Proje ile ilgili olmayan ekip toplantıları, kaçınılmaz gecikme, banyo molaları, zaten üretimde olan ürünlerle ilgili destek çalışmaları, e-postalarla uğraşmak, , eski bilgisayarı öldükten sonra yapılandırmak, gelecekteki işlerle ilgili soruları yanıtlamak ve o iş için tahminler yapmak, hesaba katılması gereken gençlere rehberlik etmek vb.. Bir tahmincinin 8 saatin 6'sından fazlasını alması sorumsuzdur. günlük kullanılabilir. Bu, son teslim tarihinin karşılanamayacağının garantisidir. Son teslim tarihinin karşılanamayacağını garanti ediyorsanız, mutsuz bir müşteriyi garanti ediyorsunuz.

Kesinlikle haklısın - olacak her şeyi bilmeden bir proje planlamak zor. Ancak, norm olan şeylerin yanı sıra önünüze çıkan görevleri takip etmek çok önemlidir. Zamanlama yönetiminin bir rol oynadığı yer burasıdır . Microsoft proje yönetimini (standart sürüm) de kullanıyorum, bunun için proje yönetimi planlama yazılımının bir parçası olan özellikler de var.

Daha fazla bilgi için http://www.microsoft.com/project/en/us/schedule-management.aspx adresini ziyaret edebilirsiniz .

Odak ve hızınızı kaybettiğiniz proje ekiplerinizden alınan çok fazla gizli çaba var gibi görünüyor. Başa çıkmak için görevi gerçekten ayırmak yararlı olabilir

..sorunlar ve böcek ve şeyler destek?

diğer ekip üyelerinin yeni geliştirme görevlerine odaklanabilmesi için belirli bir grup insana Bu sayede toplam üretimleri biraz düşebilir, ancak daha az dikkat dağıtıcı olduğu için kalite artacaktır. Bu da hata sayısını azaltacak, dolayısıyla projelerinize girmesini sağlayan a-hoc çalışma olacaktır.

Planlama kısmına gelince, Thomas Owens'ın cevabına tamamen katılıyorum.