Zaman izleme metodolojilerine alternatifler [kapalı]

Önce soru: Bir web / yazılım geliştirme şirketindeki çalışanlar için zaman izlemeye yönelik bazı alternatifler nelerdir ve neden daha iyi seçeneklerdir?

Açıklama:

Böyle çalıştığımız bir şirkette çalışıyorum. Herkese maaş ödenir. Sözleşme, Adhoc ve Dahili (faturalandırılamaz) olmak üzere 3 tür işimiz var. Adhoc, birkaç saat süren küçük değişikliklerdir ve ayın sonunda müşteriyi faturalandırırız. Sözleşmeler imzalanır ve bu büyük uzun süreç, olağan.

İlgili sürenin bir tahminini (tasarım ve geliştiricilerden) alarak, saat ücretimizle çarparak ne kadar ücretlendirileceğini anlıyoruz ve hepsi bu. Diyelim ki bir web sitesi için 50 saat tahmin ediyoruz. Zaman izleme yazılımımız var ve üzerinde harcadığımız 15 saati (örneğin 7:00 - 7:15), proje adını kaydetmeli ve bazı yorumlar yapmalıyız.

Şimdi 50 saati aşarsak, hem para kaybediyoruz hem de verimsiz oluyoruz.

Şimdi sistemin nasıl çalıştığını açıkladım, sorum daha iyi bir yöntem varsa başka nasıl yapılabilir (ki eminim bir zorunluluktur). Burada kimse şu anki sistemi sevmiyor, bir alternatif bulamıyoruz. Bir projede zaman içinde yapılması için saatlerce daha uzun saatler sonra çalışmaya istekli olmaktan daha fazlasını isterdim, ancak mevcut sistemle bunu yapmaya eğilimliyim. Yöneticimin bu sistem yerine neden abc sistemini kullanmamız gerektiğini göstermek için bu gönderiyi özetlemek (veya bağlantı oluşturmak) isterim.

Yazılım tahminleri her zaman zordur. Yazılım yaratıcı bir iş ve yaratıcılık cilalar ve azalır. Sadece bir haftalık şiddetli tükenmeden sonra geri dönmeye başlıyorum - geçen gece 15-30 dakika olması gereken bir işi yapmak saatler sürdü ...

Ayrıca her geliştiricinin farklı tahmin yeteneklerine sahip olduğunu düşünün. Daha disiplinli veya üst düzey geliştiriciler daha doğru olma eğilimindedir ve daha genç veya disiplinli geliştiriciler daha az doğrudur. Ayrıca, doğrulukları zamanla değişir (her zaman daha iyisi için değil).

Kişisel danışmanlık deneyimimde gerçekçi bir tahmini tavanla birleştirmeye çalışıyorum. Temel olarak "Bu özelliğin 7-10 saat sürmesini bekliyorum, ancak 18'e ulaşabilir - en fazla 40 saat sürse bile 18 yaşına kadar faturalandırılırsınız". Genellikle bu tür bir yaklaşım müşteriler için yenidir ve bazı düzenekler bunu "bana sağlam bir fiyat verin" ile reddeder - bu müşteriler tavan tahminini alır (ya da işlerini kibarca reddederim). Bu yaklaşımı kabul eden müşteriler için, dürüstçe zamanı izleyeceğimi anlıyorlar ve nihai faturaları harcanan zamanı yansıtacak (ancak tavanımı aşmayacak). Temelde bu bir garanti eklenmiş yalın bir yaklaşımdır; ve müşteri, gereksinimlerdeki herhangi bir değişikliğin tahminlere değişiklik getirdiğinin farkındadır.

Genel olarak bu yaklaşım, kabul etmek isteyen müşteriler için iyi sonuç verdi. Kişisel hedefim güvenlerini kazanmak ve işlerini tekrarlamaktır, bu yüzden dürüst olmak ve tavanın altına girmeye çalışmak benim çıkarımdır - ve beni tahminlerimin altında tutmaya yardımcı olmak onların yararınadır (belirsizlikten kaçınarak, geç değişiklikler, vb. - Değişikliklerin küçük değişikliklerin ötesinde bir şey olup olmadığını tahmin ediyorum).

Eğer yapmadıysanız, Efsanevi Adam Ayını okumanızı öneririm.

Kanıta dayalı programlamaya bir göz atın . Tahminlerinizin ne kadar doğru olabileceğini görmenize gerçekten yardımcı olabilir.

Geçtiğimiz yıl boyunca Fog Creek'te en güzel geliştiricilerimiz bile onunla birlikte gitmek isteyen çok kolay bir sistem geliştiriyoruz. Ve anlayabildiğimiz kadarıyla, son derece güvenilir programlar üretir. Buna Kanıta Dayalı Zamanlama veya EBS denir. Sen toplamak kanıt size programları içine geri besleme olduğunu, çoğunlukla tarihsel zaman çizelgesi verilerinden,. Elde ettiğiniz tek bir gemi tarihi değil: belirli bir tarihte gönderim yapma olasılığınızı gösteren bir güven dağıtım eğrisi elde edersiniz. Şöyle görünüyor:

Eğri ne kadar dik olursa, gemi tarihinin gerçek olduğundan o kadar emin olursunuz.

İşte böyle yapıyorsun ...

Bu yöntemin sorunu, tahminlerdeki doğal riski dikkate almamasıdır. Herhangi bir tahmin için en iyi uygulama, bunu bir dizi kez, örneğin 50 saat ± 15 saat veya benzer bir şey olarak ifade etmektir. Hata terimi bulmak zordur, ancak hiç kimse bunun tam olarak 50 saat süreceğini düşünmüyor.

Sabit fiyat modelinin dışında başka yaklaşımlar da vardır; daha düşük bir oran kullanabilir ve düz saatleri faturalandırabilirsiniz, ancak bu günlerde müşterileriniz muhtemelen riski size aktarmak isteyecektir. Bu iyi, ancak ortaya çıkardığınız zaman tahminlerine dayanarak makul bir risk primi talep etmeniz gerektiği anlamına gelir.

"+/-" faktörleri ile tahmin etmeye çalışmak yerine, "belirsizlik" faktörü ile tahminler yapıyoruz. Programcılar bir şeyin "hiçbir şeyin yanlış gitmediğini varsayarak" ne kadar süreceğini kolayca söyleyebilir. Kolayca söyleyemedikleri şey, bir şeyler ters giderse ne kadar zaman alacağıdır. Bu yüzden bir belirsizlik faktörü ekliyoruz - "L", "% 25 ekle" anlamına geliyor - "M", "% 50 ekle" ve "H", "% 100 ekle - iki katına çıkabiliyor" anlamına geliyor. Gerçek zaman, tahmini süre ile tahmin artı belirsizlik süresi arasında olma eğilimindedir.

Zamanınızı TAKİP ETMEDEĞİNİZDE, en doğru yöntem, her dakika bir iletişim kutusu açan ve olası görevlerin bir açılan liste kutusuyla "ne yapıyorsunuz?" Diye soran bir program yazmaktır. Bu açılır liste kutusunda gerçekten ihtiyacınız olan tek giriş "izleme süresi" dir, çünkü her dakika kesintiye uğrarsanız, hiçbir zaman başka bir şey yapamazsınız. Aynı ilke 15 dakikalık aralıklar için de geçerlidir, o kadar da kötü değil.

Yaptığımız şey, bir listeye görev eklememize ve üzerinde çalıştığımız zamanı seçmemize izin veren küçük bir program çalıştırmak. Seçiciyi doğru işe taşımayı unutursak, toplamlar düzenlenebilir. Satırlardan birinde olmayan herhangi bir şey "misc" e gider. Tamamen doğru değil, ancak toplam doğruluk, akış süresi elde etmekten daha az önemlidir.