Teknik olmayan bir kişiye, görevin neden düşündüğünden daha uzun sürdüğünü nasıl açıklayabilirim? [kapalı]

Hemen hemen her geliştirici, aşağıdaki gibi işletme tarafından soruları yanıtlamak zorundadır:
Bu basit iletişim formunu eklemek neden 2 gün sürecek?

Bir geliştirici bu görevi tahmin ettiğinde, onu adımlara bölebilir:

• Veritabanında bazı değişiklikler yapın
• DB değişikliklerini hız için optimize edin
• ön uç HTML ekle
• sunucu tarafı kodunu yaz
• doğrulama ekle
• istemci tarafı javascript ekle
• birim testlerini kullan
• SEO kurulumunun çalıştığından emin olun
• e-posta onayını uygulayın
• refactor ve hız için kodu optimize etmek
• ...

Bunları teknik olmayan bir kişiye açıklamak zor olabilir, temel olarak bütün görevi sadece bir HTML oluşturmak ve verileri depolamak için bir tablo oluşturmak olarak görür. Onlara 2 saat MAX olabilir.

Tahminin neden geliştirici olmayan biri için yüksek olduğunu açıklamanın daha iyi bir yolu var mı?

Sorunuzda az önce yaptınız.

Görevi bireysel adımlara bölün ve her biri için tahminler verin. Bu, tüm seçenekleri düşündüğünüzü ve (umarım) tüm olasılıkları kapsadığını gösterecektir.

Zaman ölçekleri çok büyükse, o zaman hangi parçaya (örn. E-posta onayı) ihtiyaç duyulmadığını tartışmak yerine, sadece bir litreyi bir tencereye koymaya çalışmak yerine somut verilerle tartışabilirsiniz.

Bunu sık sık yapın; umarım onlara, ilk bakışta gözle tanışmaktan daha fazla bir gelişim için genellikle daha fazla şey olduğunu öğretirsiniz.

Görevlerin listelenmesi tam anlamıyla mükemmel olmakla birlikte, bir mühendis için kusursuz olan görevlerin teknik olmayan bir kişi için çok az anlamlı olduğunu unutmayın. Örneğin, yukarıdaki listede "DB değişikliklerini hız için optimize et" in, kodu profillemeyi, yavaş noktalar aramayı, uzmanlarla gözden geçirmeyi ya da bir fırsata atmayı içeren bir veya birkaç zaman alan görev olabileceğini biliyorum. Ürüne özgü önceden tanımlanmış testler. Ve sonra, çok yavaş alanları düzeltmek için bir yol bulmaya çalışırken, başınızı masanıza vurma günleri değilse, muhtemelen birkaç saatiniz vardır.

Ancak "optimize" kelimesi olmasa da proje yönetiminizi "DB" kelimesi üzerinde kaybetmiş olabilirsiniz.

Bu işi genel olarak proje yönetimi için BÜYÜK adımlar açısından, işletme açısından risk tanımlayan kelimelerle ifade ediyorum. Listenizi alarak, proje yönetimim ile konuşabilseydim bu şekilde kaynatırdım:

1. İlk önce, bu şeyin iki bölümü var - kullanıcının gördüğü web sayfası ve ağır kaldırma yapan sunucu. Bu özelliğin çalışması için her iki parçanın da orada olması gerekir.
2. İlk bölüm, kullanıcıya anlamlı gelen bir web sayfası oluşturmaktır (ön uç HTML ekleyin, müşteri tarafı javascript ekleyin). Burada anahtar web sayfasının bu ürünün bir parçası gibi görünmesi, desteklediğimiz tüm tarayıcılarda çalışması ve kaygan olması gerektiğidir. Bu, kullanıcının gördüğü şey, bu yüzden eğer kötü görünüyorsa, kullanıcı, ürünümüzün kötü olduğunu düşünecektir. Bunu geliştirmek ve daha sonra test etmek X gün sürer.
3. Daha sonra, işi yapan web sayfasının altında bir şeyler olması gerekir. Bu durumda, buraya özelliğin tanımını eklemek anlamına gelir (haritalar - Veritabanında bazı değişiklikler yapar, sunucu yan kodunu yazar, e-posta onayını uygular, doğrulama ekler, birim testleri kullanır). Bunu bir araya getiremiyorum. Kod geliştirilip test edilirse, TÜM kullanıcıların verilerine zarar verebiliriz. Bu, basit ve yeni bir şeyin, ürünün bu özellik özelliğini kullanmayan kullanıcılar için bile, anakart üzerindeki itibarına zarar verebileceği anlamına gelir. Geliştirme uygulamalarımız bunu kapsar - bunun olmayacağından emin olmak için çok sayıda test yaparız - ancak bu, zamanı doğru bir şekilde test etmek için plan yapmam gerektiği anlamına gelir. Bu bana Y günlerini alacak.
4. Hız ürünümüzde çok önemli. İşler hızlı olmazsa, kullanıcılar ürünün iyi olmadığını düşüneceklerdir. Bu yüzden bütün bunları yazdıktan sonra, çalışmamdan geçmem ve performans açısından eşit olduğundan emin olmam gerekiyor. Bu web sayfalarında büyük bir sorun - eğer insanlar bir sitenin yavaşladığını görürse, aynı ihtiyacı karşılamak için hızlı bir şekilde farklı bir ürüne yönelecekler, çünkü yavaş ve kırılmış arasındaki farkı görmek gerçekten zor. Bu tür bir iş genellikle Z gün sürer (hız için DB değişikliklerini optimize eder, yeniden düzenler ve hız için kodu optimize eder)

Yarım günden az olan herhangi bir tahminde bulunmaktan kaçınırdım. Bir seviyede, neden bahsettiğini bildiğine güvenmek zorunda kalacaklar. Ve eğer gerçekten sadece 2 saat olacağını düşünüyorlarsa, o zaman onları bir SW geliştiricisinin hayatında tam olarak 2 saatin nasıl göründüğüne bakarken, 2 saat boyunca sizinle yanlarına oturmaya davet edin. yaklaşık 2 saat, tam olarak neyin sorunu çözmek için başlaması gerektiğini düşünmek zorunda olduğunu göstermek için.

En önemlisi aşağıdaki şeylerdir:

• Müşteri algısı ve ürün kullanımı hakkında en fazla konuşarak satın alın, onların dilini konuşmanın bir parçası olursunuz - $$ dili - mesele, eğer kod bir arada kesilirse, sonunda kaybolacaksınız - Bu özellik, daha sonra, bazı zayıf geliştirme uygulamalarının kodu genişletmeyi imkansız hale getirdiği bazı sonraki özelliklerde.
• Bir dizi olay hazırla. Bir sonraki teknik olmayan soru, "sizden daha fazla geliştiricimiz varsa, bu daha hızlı olur mu? Öyleyse, bunu yapmak 40 saat alacaksa, 40 kişi bu öğleden sonra gerçekleşebilir mi?" Tabii ki cevabı, "HAYIR! Ama bu en iyisi değil. En iyisi, burada mantıklı bir adımlar dizisi olmasıdır. B olayı gerçekleşene kadar B işlemi yapılamaz (herhangi bir kod yazmadıysanız, gerçekten optimize edemez veya test edemezsiniz ...). Şey A ve A 'birlikte yapılabilir, eğer oradaki o akıllı adamı koruyabilirlerse, bir haftadan 4 güne kadar olan süreyi kısaltabilir ve harika test desteğini garanti edebilirlerse, muhtemelen 3 gün. Orada'
• Riske odaklanın ve şu anda bazı risklerin buna değdiğini söylemeye hazır olun. İş adamlarına bunun için büyük paralar ödendi - bu ne risk almaya değeceğini bulmakta. Örneğin, piyasaya sürülme hızı düşük performans gösteriyorsa, şirketiniz kısa vadede çok sayıda sunucuya el atmaya yetecek kadar paraya sahipse, 4. adımda bunların hepsini atlamanız istenebilir (kod / veritabanı optimizasyonu) ). Bu onların hakkı - bu kararda var olan riskleri açıklamak sadece sizin işiniz.
• Bununla birlikte, eğer bu insanlara güvenmiyorsanız, yazılı bir onay alın - yüzleşmek zorunda değil, sadece hızlıca bir e-posta göndererek "işte tartıştığımızı düşündüğüm, işte yapmadığım şey, şimdi bunu yapacağım, o zaman bana katılmıyorsan bana haber ver ... haber alamazsam, bunun doğru bir yol olduğunu varsayacağım ". Ürün yönetiminin kısa süreli hafıza kaybının merkezi olabileceği göz önüne alındığında, bu herkes için oldukça faydalıdır.

"Beş kiloluk poşetlere 10 kilo poşet koyamazsın" der. Göreviniz, görevin on pound olduğunu ve beş poundluk bir zaman diliminde olmasını istiyorlar.

Kaçırdığın tek şey zaman tahmini. Her görev için bir zaman tahmini yapın ve tüm bunların, verdiğiniz tahminde nasıl bir araya geldiğini gösterin. Hiçbir tahminin 4 saatten daha büyük olmasına izin vermeyin. "Bir gün" veya "10 saat" derken herhangi bir işiniz varsa, o zaman daha küçük alt görevlere bölün.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

Şimdi maliyetlerin ayrıntılı bir faturasını aldınız. Hepsi söylendi, bu iş 27 saate kadar çıkıyor.

Şimdi bunu müşterinize gösterip "Her birinin maliyeti ile yapılması gerekenler" diyebilirsiniz. "Maliyet" kelimesini kullanın, çünkü zaman bir maliyettir ve yönetim maliyetleri anlar. İki optimizasyon görevini muhtemelen sona erdirebileceğinizi açıklayın, ancak yol üzerinde olumsuz bir etkisi olacaklarını ve toplam tahminin yalnızca% 15'ini oluşturacaklarını açıklayın.

Ayrıca saat / günün ne olduğunu gerçekçi bir şekilde açıkladığından emin ol. Örneğin, teknik destek yapmaya ya da veritabanlarını korumaya çağrıldıysanız ya da her neyse, tahmininizde bunu yapın. "Pekala, günde 7,5 saat iyi kodlama yapabilirim" deme, çünkü muhtemelen yapamazsın. Muhtemelen 5 ya da 6 gibi.

Ardından, en önemlisi, ilerlemenizi takip edin. Günde 5 saat kodlama yapabileceğinizi söyleyin. Öyleyse Pazartesi günü ilk iki görevi (benim örneğimde) kaldırabilmeli, üçüncüyü bitirip dördüncü Salı günü başlayabilmelisiniz. Bunu gösteren bir kontrol listesi hazırlayın, böylece onlara Çarşamba günü geldiklerinde gösterip "Nasıl gidiyorsunuz, cuma nasıl bitecek?" Diyebilirsiniz.

Konuşmam için slaytlarıma bakın Birkaç yıl önce OSCON'da verdiğim Krizin Önlenmesi: Proje Tahmini ve Takibi . 21 no'lu slayta bakınız, "Haftanın planlanması". Ayrıca örnek bir hız çizelgesi var .

Onlara sor:

Nasıl yapardın? Hangi modülleri değiştirirsiniz? Kaç tane kod satırı var? Güvenlik uygulamaları nelerdir? Veritabanı şemasında herhangi bir değişiklik var mı? DB'de herhangi bir değişiklik yaparsanız kaç dosya etkilenir? Son formun eklenmesi ne kadar sürdü? Form eklemek için ortalama (aritmetik ortalama) nedir? En uzun olan neydi? En uzun zamandan bir dakika daha az süreceğini tahmin edeceğim. Son N formlarını eklemenin ne kadar sürdüğünü bilmiyorsanız, bu tahminin yalnızca bir büyüklük sırasına göre kesin olması garanti edilir.

Onlara, yazılımlarının, çoğu karmaşık yöntemlerle bağlanmış, 10.000 farklı parçalı 100 tonluk bir makine gibi olduğunu açıklamanızı söyleyebilirim. Bu makineye 1 inçlik bir parça yerleştirmek biraz mühendislik gerektirir, böylece makineyi kırmaz, ancak daha iyi cevap:

Daha iyi kod mimarisine sahip olsaydınız, bunun gibi işleri kolaylaştırır mıydı? Cevap, çoğu yazılım ekibinin iyi mimarlar olmadığıdır (çünkü tonlarca genel, mimari şablonun bir araya gelmediğinden veya her problemi önceden tahmin etmek için yeterince etki alanı ustaları olmadığı için) ve her zaman iyi mühendis değillerdir. Bu yüzden, tahminlerde bulunmak veya söz vermek konusunda kendilerini güvende hissetmiyorlar.

Tıpkı 20. yüzyılın, iyi mimariyi ve büyük binalar inşa etmeyi bir araya getirmesi gibi, yazılım mühendisliği araçları da ana akıma gelmedi. Geliştiriliyorlar: yeni bir zihniyet alıyor. Wiki.hackerspaces.org/Hacking_with_the_Tao adresindeki Zen Koduna bakınız.