Scope Creep Monster'ı Bir Kez Ve Herkes İçin Nasıl Yenebilirsiniz?

Uzak geliştiricilerle çalışmayı öğrenmek, işiniz ve cüzdanınız üzerinde olumlu bir etkisi olacak değerli bir beceridir. Geliştiricilerle çalışma serimizdeki önceki makalelerde ele aldık:

• Bir WordPress yüklenicisi tutarken yapmanız gereken her şey
• Bir WordPress proje özeti nasıl yazılır: The Blueprint
• WordPress Uzmanları ile nasıl verimli çalışılır

Şimdi oldukça yapışkan ama çok önemli bir konuyu ele alacağız. Bunu doğru yapmak, uzmanınızla banka bakiyenize bile fayda sağlayabilecek sürekli bir ilişki sağlayacaktır. Kapsam kayması hakkında konuşacağız.

Paranızdan daha fazlasını elde etmenin iyi bir şey olduğunu düşünebilirsiniz, değil mi? Hayır.

Bana sadık kalın, kapsam kaymasının neden sadece uzman için değil müşteri için de kötü bir şey olduğunu açıklayacağım. Ardından, kapsam kaymasının oluşmasını nasıl önleyeceğiniz konusunda size bazı ipuçları vereceğim.

Kapsam kayması nedir?

Proje kapsamı, uzmanın sizin için yapmayı kabul ettiği çalışmadır. Bu her zaman proje özetinizle aynı değildir. Özet, önemli ilk adımdır, ancak uzmanınızla görüştükten sonra, üzerinde anlaşmaya varılan iş değişmiş olabilir. Bu kararlaştırılan çalışma, burada Codeable'da yazılı olarak verilecektir, genellikle çalışma odasında listelenir.

Kapsam kayması, bütçede herhangi bir değişiklik olmaksızın projenin kapsamının büyüdüğü zamandır . "Sürünme" kısmı, işin genellikle "Bu hatayı düzeltirken lütfen web sitemi yeniden tasarlayın" gibi bariz şekillerde eklenmemesidir. Bu ekstra şeyler genellikle daha küçük, daha az belirgin yollarla bir projeye “sızar”.

En azından müşterinin bakış açısına göre, bunlar bir WordPress geliştiricisi veya tasarımcısı gibi bir uzman için sadece birkaç tıklama olan kolay ve hızlı şeylerdir. İşte 3 oldukça yaygın örnek:

Kapsam kayması – Örnek 1

Bir uzmandan size bir web sitesi kurmasını istediniz. Web sitesinin sahip olmasını istediğiniz her şeyi listelediniz. Sonuca baktığınızda “Başka bir sayfaya ihtiyacım var, gerçekten basit bir metin sayfası” diyorsunuz.

Kapsam kayması – Örnek 2

Biraz daha bakıyorsunuz ve “Oh, formun birkaç ekstra alana ihtiyacı var” diyorsunuz.

Kapsam kayması – Örnek 3

Bir kez daha bakıyorsunuz ve “Bu iletişim formunu yeni sayfanın en altına ekleyebilir miyiz?” diyorsunuz.

Bu öğelerden hiçbiri önceden kararlaştırılmadıysa, bu kapsam kaymasıdır : geliştiricinize asla iletmediğiniz şeyleri istiyorsunuz. Genellikle çok küçük şeylerdir ama birleşirler. Bazen saatlerce daha fazla çalışmaya – ödenmemiş işlere.

Bazen istenen değişiklikler küçük bile değildir. Bazen isteğin kendisi bir saat veya saatler, hatta günlerdir. Örneğin, uzmanınızdan bir eklenti yapmasını istiyorsunuz. Uzman, tüm gereksinimlerinizi karşılıyor, ancak tam olarak istediğiniz gibi değil. Yani uzmanınızdan eklentinin çalışma şeklini değiştirmesini istiyorsunuz.

Bir çizgi çizme: aslında kapsam kayması mı?

Kapsam kaymasının ne olmadığını not etmek önemlidir. Fazladan çalışma istenirse ve bütçe ayarlanırsa bu kapsam kayması değildir. Yeni özellik istekleri, aynı sorunun bir parçası gerçekten sürünmese de, belki de buna “kapsam doldurma” demeliyiz. Bu da kötü, ancak kapsam kayması çok daha karmaşık.

WordPress temanızla ilgili yardıma mı ihtiyacınız var? Bir sonraki projeniz için Zackary Allnutt'u işe alın!

Kapsam kayması neden oluyor?

Yaygın bir çalışma şekli, müşterinin X ödemesi ve uzmanın projeyi tamamlaması ve ardından müşterinin uzmana neyin değişmesi gerektiğini söylemesidir.

Gördüğüm ana sorunlardan biri, hem müşterilerin hem de uzmanların sabit teklif projelerine alışık olmaması. Açıklamama izin ver.

Bir çalışan olarak veya saatlik ücretle çalışıyorsanız, bunda başlı başına yanlış bir şey yok, uzman veya çalışan çalıştıkları saat için ödeme alıyor. Fikrinizi değiştirirseniz veya eklemek için başka bir şey düşünürseniz, sorun değil.

Ben bir çalışanken, işverenimin bana işi yaptırıp yarısını değiştirerek “zamanımı boşa harcaması” umrumda değildi. Kendi kaynaklarını boşa harcıyorlardı, yine de bana para ödeniyordu.

Ancak burada Codeable'da sabit fiyat teklifi için çalışıyoruz, bu yüzden farklı çalışmamız gerekiyor. Bu yüzden kapsam konusunda katı olmalıyız. Müşteri bu değişiklik için fazladan ödeme yapmaya istekliyse, o zaman harika! Ancak müşteri bu değişiklikleri orijinal alıntının bir parçası olarak beklediğinde, sorun burada yatmaktadır.

Kapsam sürünmesi müşteri için neden kötü?

Şimdi müşteri olarak bunun sizin için neden önemli olduğunu merak ediyor olabilirsiniz, değil mi? Herkesin parası için daha fazlasını istemesi doğaldır. Ancak bu, alışverişinizden %20 indirim almaktan farklıdır.

Aradaki fark, uzmanınızın ücretsiz olarak çalışmasını sağlamaya çalışıyor olmanızdır! Niye ya? Çünkü uzmanınız bu çalışmayı hiçbir zaman tekliflerine dahil etmedi. Yani sözleşmenizde yazılmayan her şey ücretsiz olarak yapılacak iş olacaktır.

Hangi işte olursanız olun, sizden ücretsiz çalışmanızı isteyen birini takdir eder misiniz? Doğru değil?. O zaman, ne de uzmanınız. Müşteri olarak kapsam kaymasını önemsemenizin ilk nedeni de budur. Uzmanınızla olan ilişkinizi zedeler ve aynı uzmanla çalışmanın maliyet tasarrufu sağlayan büyük faydaları vardır. Şu anda, tanımam zaman alan özel bir eklenti üzerinde çalışıyorum. Artık sonraki işler için teklifimi azaltabiliyorum çünkü artık çok iyi biliyorum. Müvekkilim işi başka bir uzmana götürürse, benim zaten yaptığım gibi eklentiyi tanıması için o uzmanın ücretini ödemek zorunda kalacaklar.

Proje kapsam kayması nedeniyle zamanla çalışmaya başlarsa, 30 saatlik bir iş artık 40 saatlik bir iş olacaktır. Olması çok muhtemel olan şey, işlerin aceleye gelmesidir. Bu değişiklikleri aranan duruma getirebilirsiniz, ancak büyük olasılıkla diğer önemli işler pahasına. Kod temizleme ve test etme için ayrılan süre artık sona ermiştir ve bu noktada uzmanınız muhtemelen projeniz konusunda pek hevesli değildir.

Sizi temin ederim ki, istediğiniz şey bu değil. Kalite kontrol aşaması, projenin hayati derecede önemli bir parçasıdır ve daha fazla özellik için feda edilmemelidir.

Proje özetlerinin kilit rolü

Peki proje sürünmesinin olmasını önlemek için ne yapılabilir? Eski çalışma şekline alışmış olan müşteriler ve uzmanların, her iki taraf için de başarılı olması için sabit fiyatlar için farklı bir çalışma şekli öğrenmeleri gerekir. Tecrübelerime göre, mutlu bir müşterinin ve mutlu bir uzmanın sırrı netliktir. Bu mutlu dinamik, Codeable değerlerinin önemli bir parçasıdır.

En iyi başarı için, bu netlik her iki taraftan da gelir.

Daha iyi proje anlaşmaları nasıl yazılır

Temel kural, eğer yazılı değilse, anlaşmanın bir parçası değildir ve bu nedenle, uzman, onu dahil etmek için zamanı hesaba katmamıştır.

1. Özetiniz, hedeflerinizin ne olduğu ve ne beklediğiniz konusunda olabildiğince açık olun. İhtiyacınız olan her şeyi, küçük şeyleri bile kapsadığınızdan emin olmaya çalışın.
2. Emin değilseniz sorular sorun. Bir uzman olarak, anlaşmayla ilgili sorular sorulduğunda gerçekten mutlu oluyorum: bu, müşterinin anlaşmaya anında dikkat ettiği anlamına geliyor ve harika bir çalışma ilişkisi öngörebiliyorum. Bu noktada ihtiyacınız olan her şeyi bilmiyorsanız, uzmanınızdan bir danışma veya keşif projesi istemeyi düşünün. Bu ön çalışma projeleri, harika bir özet yazmak ve projeden ihtiyacınız olan her şeyi aldığınızdan emin olmak için bir geliştiriciyle çalışmanın harika bir yoludur.
3. Sözleşmenizde yazılı olmayan bir işin yapılacağını asla varsaymayın – bariz olduğunu düşünseniz bile. Bu bir hatadır, çünkü her müşteri ve uzmanın farklı bir "bariz" fikri vardır. Stilin dahil edileceğini varsayabilirsiniz, ancak diğer müşteriler bunu kendileri yapmayı bekliyor.
4. Anlaşmanın sizin özetiniz değil, kapsamı olduğunu unutmayın. Bunun nedeni, özetteki şeylerin herhangi bir nedenle yapılmayacağı zamanlar olmasıdır. Görevler arasında bölünürler, bütçeyle her şey yapılamaz veya listedeki her şey yapılabilir değildir. Yani kapsam hakkında konuştuğumuzda, her iki tarafın da kabul ettiği şey budur.
5. Kapsam dışında bir talepte bulunursanız, lütfen "X'i ek bir görev olarak ekleyebilir miyim?" müşterinin bu ek çalışmanın uzman için gerçekten yararlı olduğunun farkında olduğunu bilmek – artık kapsam hakkında konuşmamız gerekmediğini biliyoruz.

Proje özetinizdeki revizyonların kilit rolü

İş bitti ve projenize bir göz atın. Sonuçlardan oldukça memnunsunuz (umarım!), ancak burada ve orada değiştirmek istediğiniz birkaç ince ayar var. Tecrübelerime göre sorun burada başlıyor.

Şunu bilmelisiniz ki, bu noktada uzman projeyi tamamlanmış olarak değerlendirir ve gelecek değişikliklerin listesini beklemez. Diğer taraftan, istemcinin “bu yazı tipini biraz artırabilir misin?” gibi iki / üç küçük isteği olabilir. Önemli değil.

Ama size şunu söylememe izin verin: revizyonlar ve kapsam kayması en iyi arkadaşlardır . Niye ya? Eh, çünkü neyin revizyon sayıldığına ve kaç tane revizyon talep etmenin makul olduğuna dair ortak bir cevap yok. Ve inanın bana, “revizyon” adı altında her türlü şey talep ediliyor. Düzeltmelerin listesi, bazen geliştiricinin iş yükünü ikiye, hatta üçe katlayabilir.

Siz – müşteri – bunun cebinizi de etkilediğini düşünmüyor musunuz?

Sektörümüzde revizyonlar verilmiş gibi görünüyor ve ücretsiz çalışmalarını önlemek için uzmanlar, iş tamamlandıktan sonra neredeyse kaçınılmaz olan bu değişiklik talebi akışını karşılamak için bir proje teklifine çok büyük miktarlar ekleyebilir. Müşterilerin ve uzmanların alıştığı (ve sorunun bir parçası) ortak iş akışı, projenin tamamlanması, sunulması ve ardından müşterinin değiştirilmesini istediği her şeyi listelemesidir. Bu, ilgili herkes için çok kötü.

Revizyon istekleriyle başa çıkmak için fiyat tekliflerini ikiye katlayan geliştiriciler duydum. İşte tam da bu noktada müşteriler, bir şeyleri değiştirmek isteyebilecekleri fikri için fazladan ücret alıyorlar.

Aristoteles'in dediği gibi, gerçek ortada bir yerde yatıyor. Aslında, geliştiriciler projeye başlamadan önce durum tespiti yapmıyorlar ve müşteriler ne istediklerini açıklamakta kötü bir iş çıkarıyorlar. Burada her iki tarafın da aynı sayfada olması önemlidir.

Peki revizyonlar dahil mi (veya değil mi)?

Bir proje sırasında hemen hemen her zaman bir şeyler ortaya çıkar, bahsetmeyi unuttuğunuz şeyler veya ilk etapta ihtiyaç duyduğunuzu fark etmediğiniz şeyler. Buradaki klasik hata, bu şeyler için bütçe ayırmamaktır. Onlar için bir kenara para ayırır ve ortaya çıkmalarını beklerseniz, yaptıklarında şok olmazsınız ve bu sürprizleri açıklamak için kapsamı zorlamaya çalışmazsınız.

Unutmamanız gereken anahtar kavram şudur: Sözleşmenizde revizyonlardan bahsedilmiyorsa, bunların dahil edilmediğini varsaymalısınız. Popüler görüşe rağmen, revizyonların orijinal finansmanın bir parçası olması için hiçbir neden yoktur.

Şahsen, gerçekten değişken ve hesaba katılması zor olduğu için orijinal projenin parçası olan revizyonların hayranı değilim. Ayrıca tanımlamaları gerçekten zor, bu da bir sözleşmede sayfalarca tanımla sonuçlanıyor. Ayrıca, istemeyecekleri revizyonlar için müşterilerden ücret almak istemiyorum.

Büyük bir tehlike (en azından sınırsız revizyonla), proje planlama aşamasında dikkatsizliği teşvik etmesidir, çünkü müşteri, istediği şey değilse, işi bittikten sonra değiştirebileceğinin farkındadır. Umarım kötü planlamanın işiniz için neden iyi olmadığını açıklamama gerek yoktur.

Bunun yerine, yapmak isteyebileceğiniz değişiklikleri hesaba katmak için bütçenize %30'luk bir tampon bırakmayı düşünün. Orijinal finansmanınıza revizyonları dahil etmek isterseniz, uzmanınıza bunlar hakkında danışın. Görebileceğiniz bazı revizyon anlaşmaları türleri şunlardır:

• “Revizyonlar teklife dahil değildir ve talep edilmesi halinde alıntı yapılır”
• "Fiyat teklifine 2 tur revizyon dahildir – bu, kapsam dışındaki ekstraları içermez ve küçük tasarım ve işlevsellik değişiklikleriyle sınırlıdır"
• "Fiyat teklifine 20 küçük tek eylem revizyonu dahildir – bu, kapsam dışındaki ekstraları içermez ve küçük tasarım ve işlevsellik değişiklikleriyle sınırlıdır"

Sarmalamak

Kapsam kayması, yalnızca uzmanların endişelenmesi gereken bir şey değildir. Müşterilerin de buna kanmamayı öğrenmeleri gerekir çünkü bu, uzmanlardan daha yüksek teklifler alarak genel bütçelerini doğrudan etkileyebilir. Bir geliştirici, tasarımcı, güvenlik uzmanı veya başka bir profesyoneli işe aldığınızda, bir iş ilişkisi kuruyorsunuz. Ne kadar sürerse sürsün.

Bu nedenle, kapsam kaymasını önlemek istiyorsanız, daha sonra eklemeniz gerekebilecek şeyleri düşünürseniz, bütçenizde bir tampon bırakarak (~%30 yararlı referans olarak) kendi tarafınızda iyi bir planlama ile başlamanızı öneririm. Ardından, tüm bu bilgileri harika bir proje özetine çevirmeye devam edin ve tüm proje boyunca iletişiminizi açık tutun.

Ve asla unutmayın: Onlardan alıntı yapmadan önce yapmadığınız şeyleri yapmalarını istemeyerek uzmanınıza karşı adil olun. Sana bunu yapan biri için çalışmaktan ne kadar mutlu olursun? Uzmanınızın projeniz üzerinde çalıştığı için ne kadar mutlu. Sence tekrar senin için çalışmak isteyecekler mi?

WordPress ile ilgili yardıma mı ihtiyacınız var? Zackary Allnutt'u işe alın ve sihrini sizin için yapmasını sağlayın!