Vizör Çözümleri


Destek
Kaydol
Giriş Yap
Ücretsiz Deneme başlat
İpuçları Gereksinim yönetimi
Blog listesi

Daha iyi Gereksinim Yönetimi için ipuçları ve en iyi uygulamalar

Blog | 17 dakikalık okuma
Administrator tarafından yazıldı.

İçindekiler

Gereksinim Yönetimindeki "en iyi uygulamalar" ne anlama geliyor?

Bana o kadar ilginç geliyor ki, herkes eğitim istemekten bahsediyor “en iyi uygulamalar”. Bu terim genellikle aynı zamanda sağlayabileceğimiz danışmanlık türünü tanımlamak için de kullanılır. Bu gerçekten ne anlama geliyor? Hepimizin en iyi uygulamaların bireyleri eğitmek için temel olabileceği efsanesini beslediğimize inanıyorum. En iyi uygulamalar eğitilmez, deneyimlidir.

En iyi uygulama yaklaşımını doğayla karşılaştırırsak, yalnızca en güçlü değil aynı zamanda en üretken türlerin hayatta kaldığını biliriz. Bir organizasyondaki süreçleri değiştirmenin bu kadar zor olmasının nedenlerinden biri de budur. Bir an için bunu düşünün. En güçlü ve en üretken muhtemelen, kuruluşunuzdaki hemen hemen her grupta bulunan bireylerin çoğunu tanımlar. Bunu Sistem Mühendisliği alanında defalarca gördüm. En güçlü ve en üretken mühendisler genellikle uzun yıllardır işlerini yapıyorlar ve bu işi yapmak için belirli bir yöntemleri var. Onlardan yeni teknikler ve araçlar denemelerini istemek, yapmakta oldukları zaten harika olan işi nasıl geliştireceğini bilmedikleri için genellikle boşunadır. Onlara en iyi uygulama yaklaşımını dayatmaya devam edersek, uygulamaları hayatta kalacak.

Peki ne yapıyoruz? En iyi uygulamalar kendi kişisel deneyimimizle başlar. En iyi uygulamalar etrafında topladığınız ve okuduğunuz kitapların tümü, kullanım durumları, gereksinim belirleme, sistem mühendisliği, test etme vb. olsun, yazarın bazı alanlardaki kişisel deneyimiyle ilgilidir. Bir noktada bir kuruluş tutarlı bir sürece ihtiyaç duyduğuna karar verir. organizasyon genelinde. Bunu yapmak için birçok iyi neden var. Böylece, bu en iyi uygulamaları yansıtan bir süreç oluşturmak için bir grup oluşturulur. Grupta pek çok en iyi uygulama bulunduğundan, tahmin edin genellikle kim kazanır? En güçlü ve en üretken olan. Ve sonuçta ortaya çıkan en iyi uygulama, genellikle en iyi uygulama grubu ile kuruluşta bu rolü oynayanlar arasında bir uzlaşmayla sonuçlanır. Araştırmalar, bu süreci organizasyon genelinde gerçek anlamda ortaya koymanın yaklaşık beş yıl sürdüğünü gösteriyor. Ardından bu uygulamaları fark eden danışmanlar gelir. İş için bir fırsat görebilirler ve böylece kendileri için daha fazla iş yaratacak uygulamaların arkasına geçerler. Bu uygulamaları öne çıkaran ve kitaplar yazan konferanslarda ve ticari fuarlarda görünmeye başlarlar. (Düşün Çevik yaklaşım.) İş aradıkları için kendilerine en fazla işi sağlayacak uygulamalara odaklanırlar. Her zaman en iyi uygulamaları arıyoruz, bu yüzden ne sıklıkla çalıştığını bilmemize gerek yok, sadece CAN iş. Ve bu nedenle, yıllar boyunca konuşulan tüm faydaları gerçekleştirmeyi umarak, bu uygulamayı kuruluş genelinde zorlamaya devam ediyoruz.

En iyi uygulamaların geriye dönük görüşlere dayandığını unutmamalıyız. İşiniz için en iyi uygulamalar, o işi öğrendikçe geliştirilir. Elbette birbirimizden öğrenebiliriz. Bu tartışmanın amacı bu değil. Mesele şu ki, en iyi uygulamalarımızı öncelikle kendi pratik deneyimlerimize dayandırmalıyız. En iyi uygulamaları işlerimize ve organizasyonlarımıza nasıl uyguladığımız konusunda seçici olmalıyız. Birileri bu konuda bir kitap yazdı veya bir konferansta bu konuda konuştu diye en iyi uygulamaları kabul etmeyin. Uygulamayı araştırın ve teşvik edildikleri ortamı belirleyin. Bu ortam, bugün içinde bulunduğunuz ortamla karşılaştırılabilir mi? Genellikle çok az ortak nokta vardır. Size ve işinize uygun ve size gerçek fayda sağlayacak en iyi uygulamalardan küçük bilgileri seçin. Küçük değişikliklerle başlayın ve kuruluşunuzda uygulandığı şekliyle uygulamayı geliştirin. Nerede başarılı olduğunu ve nerede başarısız olduğunu bilin ve bundan ders çıkarın. Uygulamaya karşı güçlü ve üretken itirazlarınız varsa, itiraz edenlerin bu uygulamanın kendilerine nasıl yardımcı olabileceğini görmelerine yardımcı olmak için uygulamayı pratik olarak anlayan birine ihtiyacınız olacağını unutmayın. Onları dinleyin ve endişelerini giderin. Onları görmezden gelmeyin ve gideceklerini ummayın. Yapmazlar.

Başka bir deyişle, sadece “en iyi uygulama” kelimesini söylemek, sizin için en iyi uygulama olacağı anlamına gelmez.

Gereksinim Tanımınızı nasıl iyileştirebilirsiniz?

Bir süreçte veya araçlarda herhangi bir değişiklik yapıldığında süreci desteklemek için kullanılan, bu süreci gerçekleştirmek için gereken süreyi etkileyecek bir öğrenme eğrisi var. Gereksinim tanımlama sürecinizi iyileştirmeyi düşünmeye başladığınızda, bu değişiklikle ilgili çabalar olacağını unutmayın. Çoğu durumda, iş ilerlemeye başladığında üretkenlikte azalma olur. Bu azalmaya genellikle “J-eğrisi” denir. Kullanıcılar belirli bir görevi yapma şeklini değiştirmeye çalıştıkça, değişikliği yapmanın çok zor olduğunu düşündükleri bir noktaya ulaşırlar. Buradaki cezbedici şey, sadece görevi tamamlamak için eski iş yapma şekline geri dönmektir. Bu engelin üstesinden gelmek için bir planı olmayan birçok kuruluş, bu değişikliği yapma hedeflerinde başarısız olur. Bu zorluk hem süreçler hem de araçlar için geçerlidir. Becerileri veya araçların benimsenmesini hızlandırabilecek iki strateji vardır.

İlk olarak, var derinlik yaklaşımı. Derinlemesine yaklaşımda, çekirdek bir grup insan seçilir ve yeni süreç veya araç hakkında eğitilir ve eğitimden gerçek bir proje üzerinde çalışmaya kadar olan uçurumun çaprazında mentorluk almaya devam eder. Mentorlar genellikle belirli beceriler alanında uzmanlığa sahip dışarıdan danışmanlardır. Uygulayıcıların yeni becerilerini canlı bir projede kullanmaya başlamalarına yardımcı olacak uzmanların bulunması önemlidir. Bu çekirdek grup oldukça küçüktür ve amaç, onları yeni becerileri kullanacak olan yeni projeler için danışman olarak kullanmaktır. Bu bireylerin yeni becerilerini kullanmalarına yardımcı olmak için projeden projeye hareket eden uzmanlar olurlar.

The genişlik yaklaşımı zamanla geliştirilecek en iyi uygulama becerilerinin sağlam bir temeline odaklanır. Bu yaklaşımda, genellikle belirli beceriler alanında standart eğitim yoluyla, en iyi uygulama becerilerinin bu temelini sağlamak için mentorlar getirilir. Genellikle standart süreçler ve şablonlar, çeşitli proje ekipleri tarafından kullanılmak üzere tanımlanır ve belgelenir. Başlangıç ​​eğitimi, derinlik yaklaşımında bahsedilen daha küçük, odaklanmış gruba karşı büyük bir grup kişiye verilir. Projeler yeni becerileri kullanmaya başladıkça ve belirli görevlerinin nasıl etkilendiği hakkında daha fazla bilgi edindikçe, bu sonuçlar zaman içinde iyileştirilebilmesi için en iyi uygulama temeline geri beslenir.

Bu çabayı yönetmek için hangi yöntemi seçerseniz seçin, gerekli değişiklikleri başarılı bir şekilde yapmak çok önemlidir. Bir plan olmadan, bu değişiklikler genellikle program ve bütçe sıkıntısı hissedildiğinde başarısız olur. Bu tür değişiklikleri yapmak disiplin, destek ve kararlılık gerektirir. Yeni becerilerin kullanıldığından emin olmak için her proje sürekli olarak değerlendirilmelidir.

Gereksinim tanımlama sürecinizde basit bir değişiklik düşünün. Dahili olarak güvenebileceğiniz uzmanlar kimlerdir? Eğitim ve/veya mentorluk için dışarıdan yardıma mı ihtiyacınız var? Bu eğitim ve mentorluk için nereye gideceksiniz? Süreciniz bugün iyi belgelenmiş mi yoksa sıfırdan mı başlıyorsunuz? Başarılı olduğunuzdan emin olmak için planınız nedir (derinlik, genişlik, her ikisi)? Değişiklik için zaman çerçevesi nedir?

"Delilik, aynı şeyi tekrar tekrar yapıp farklı bir sonuç beklemektir." (Albert Einstein) Böyle hissediyorsanız, size istediğiniz sonuçları verecek değişiklikler yapmaya başlayın.

Daha iyi Gereksinim Toplama için ipuçları

Kullanıcılarla röportaj yapıyorsanız ve temel olarak “Şeker mi Şaka mı – bana bazı iyi şartlar verin” diyorsanız, tahmin edin ne alacaksınız? Kullanıcıların görmek isteyeceği şeylerin bir karışımını elde edeceksiniz. Bazıları sizin için önemli olacak ve bazıları olmayacak. Tüm bu ihtiyaçları sıralamanız ve kategorilere ayırmanız gerekecektir. Bu kategorilere genellikle özellikler diyoruz. Bu özelliklerden bazıları projeyle ilgili olacak, bazıları ise olmayacak. Öyleyse, gereksinimleri toplamaya başlıyorsanız, neden sorduğunuz sorulara daha fazla odaklanmıyorsunuz? Biraz araştırma yapın ve sistemle ilgili mevcut herhangi bir bilgiye bakın. Son kullanıcıları tanımlayın (tüm alt bölümde kandırmak veya tedavi etmek zorunda değilsiniz, gerçekten iyi ikramların verildiği birkaç sokağa odaklanın) ve onlarla toplantılar ayarlayın. 

Projeden etkilenen süreçleri belirleyin – hangileri değişiyor, hangileri yeni, artık ihtiyaç yok mu? Kullanıcılara hangi süreçlerin onlar için iyi çalıştığını sorun. Bugün işlerini nasıl yaptıklarını anlamaya çalışın.

İkincisi, gereksinimleri özelliklere göre sıraladıktan sonra önceliklendirmeniz gerekecek. bu özellikler. İlk önce yapılması için müşterinin “favorileri” nelerdir?Bazen, sistemin yüksek riskli veya iyi anlaşılmayan kısımlarına odaklanmak yerine, gerçekten öncelik vermeyi ve sistemin kolay kısımları üzerinde çalışmayı bitirmeyi başaramayız.

Projenin sonunda, ne olduğunu tekrar gözden geçirin. sorabiliriz doğru sokaklarda ilerlesek, süreci takip etsek ya da bir sebepten sapsaydık beklediğimiz kadar şeker elde edebildik mi? Ne işe yaradı? Süreci iyileştirmek için ne gibi değişiklikler yapılabilir? Beklenen sonuçları aldık mı? Kullanıcılar üründen memnun kaldı mı?

Ekibinizi Gereksinim Yönetimi konusunda eğitmek için 3 ipucu

Hiçbir zaman gereksinimleri yazmamış veya yönetmemiş birinden sağlam ve karmaşık bir gereksinim sürecini izlemesini istemek, o beş yaşındaki çocuktan Beethoven'ın Ayışığı Sonatı'nı çalmasını istemek gibidir. Ve genellikle herhangi bir eğitim veya rehberlik sağlamadığımız için, onlardan bu parçayı kendi başlarına çalmayı öğrenmelerini isteyelim. Analistlerimizi karmaşık bir gereksinim sürecine soktuğumuzda yaptığımız şey budur.

Ekibimizi eğitmeyi düşünmemizi öneriyorum. Hepimizin “işimizi nasıl yapacağımızı bildiğimizi” düşünmeyi bırakalım. Bu doğru değil. O parçayı kendi başımıza çalmayı öğrenebiliriz. Beş yıl almak yerine, kendi başıma on yılımı almamı öneririm. İhtiyaç mühendislerimiz ve analistlerimiz için de durum böyledir. Kendi başlarına öğrenmelerine izin verebiliriz. Ya da onlara biraz eğitim, rehberlik ve pratik yapmaları için zaman verebiliriz.

Tabii ki, bu işi yapmanın anahtarı (punto amaçlanmamıştır), analistlerimizi eğitmek için kullandığımız bir tür sürecin tanımlanmasıdır. Bu "süreç" kelimesinden nefret ederdim ama bu önemli. Yeni gereksinim analistlerinizi hızlı bir şekilde uzman gereksinim analistlerine dönüştürmek için bazı öneriler.

  1. Analistlerinize özel süreciniz hakkında eğitim sağlayın, gereksinimlerinizi ve çıktılarınızı kullanarak, böylece eğitim daha gerçek olur. Gereksinim tanımı ve yönetimiyle ilgili genel sınıflar harikadır, ancak kuruluşunuzda izlediğiniz süreçlerle uyumlu olmaları gerekir. Dışarıdan bir danışmanla çalışıyorsanız, eğitimi sizin için özelleştirmek için biraz çaba sarf edeceğinizi bekleyin, ancak bu yatırıma değecektir.
  2. Yeni analistlerinize bir akıl hocası atayın. “Orada bunu yapan” ve bunu kanıtlayacak yaraları ve yaraları olan birinin yeni analiste yardım etmesine ve ona ipleri göstermesine izin verin. Bu, “kabile bilgisi” düşüncesini ortadan kaldırmaya yardımcı olacaktır. Teşhis oturumlarında yardımcı olmalarına, gereksinim belgelerini analistle birlikte incelemelerine ve onlar için bir kaynak olmalarına izin verin. 
  3. Analistin pratik yapmasına izin verin. Bu çok pratik görünmeyebilir, ancak şirket için kritik olan veya ilerlemenin zor olacağı çok fazla geçmişi ve tartışması olan bir projede yeni bir analist başlatmayın. Ayaklarını ıslatmak için basit ve iyi anlaşılmış bir proje üzerinde “pratik yapmalarına” izin verin.
Ekibinizi Gereksinim Yönetimi konusunda eğitmek için 3 ipucu

Daha İyi Gereksinimler Yazmak için 7 İpucu

Yazma gereksinimleri, onlarca yıldır bizim için bir meydan okuma olmuştur. Neden bu kadar zor? Sebeplerden biri, gereksinim dilinin zorluğudur. Gereksinimleri okuyucunun okuyup anlayabileceği şekilde yazmamız gerektiğini biliyoruz. Kullanıcı gereksinimlerini yazıyorsak, okuyucu bir işletme sahibi, son kullanıcı veya paydaştır ve “doğal” bir dilde yazmaya odaklanır. Bununla birlikte, “doğal” bir dille ilgili sorun, bunun çok belirsiz olması ve yanlış anlaşılması veya yanlış anlaşılması muhtemel olmasıdır. Bu açığı nasıl kapatacağız?

Gereksinimlerini yazarken her türlü yapıya direnen konuştuğum analistlerin sayısına hayret ediyorum. Genellikle açıklayıcı paragraflardan ve birçok ek gereksinimi ima eden cümlelerden oluşan yapılandırılmamış yaklaşımlarından oldukça memnun görünüyorlar. Okurları bu yöntemi beğendiklerini iddia ediyorlar. Sorun şu ki, bu "gereksinimler" geliştiricilere veya sistem analistlerine teslim edildiğinde, bu gereksinimlerin gerçekten ne anlama geldiğini netleştirmek için genellikle çok fazla tartışma oluyor.

Burada yapılması gereken bir uzlaşma olduğuna inanıyorum. 

İşte bu boşluğu doldurmaya yardımcı olacak bazı ipuçları.

  1. Aktif sesle yaz, oyunculardan birinin her cümlenin öznesi olduğundan emin olmak.
  2. Her cümlenin özne, fiil ve yüklem içeren tam ve dilbilgisi açısından doğru bir cümle olduğundan emin olun..
  3. Aktörler arasında hangi bilgilerin iletildiğini açıkça belirtin.
  4. Tutarlı bir ayrıntı düzeyini koruyun. Örneğin, kullanıcı gereksinimleri için her cümlenin öznesi bir son kullanıcı olmalıdır. Sistem gereksinimleri için her cümlenin konusu bir sistem olmalıdır.
  5. Her gereksinim, net başarı kriterlerini tanımlamalıdır. Örneğin, “Kullanıcı Denetim Günlüğü Raporunu görüntüleyebilir”.
  6. Her gereklilik tek bir eylem ve hedef belirtmelidir. “Ve” ve “veya” kelimelerinin aşırı kullanımına dikkat edin.. Örneğin, "Ayın son Cuma günü ve ödemenin 31'inde yapılması gerekiyorsa ve 31'i ayın son Cuma günü ise, ödemeyi o gün doğu saatiyle 6:XNUMX'den sonra göndermek ödemenin gecikmesine neden olacaktır" . Bunu anlaman için sana meydan okuyorum!
  7. Bir gereksinim bir kaçış maddesi içermemelidir. Örneğin, “Sistem, kullanıcının açıkça yanlış bir kullanıcı adı girdiği durumlar dışında, oturum açma denemelerinin sayısını belirleyecektir”.

Karmaşık Müşteri Gereksinimlerini yönetmenize yardımcı olacak 4 ipucu

Bu senaryoyu nasıl ele alırdınız? Bir müşteri, sistemin kullanıcı dostu olmasını istediğini belirtti. Buna karmaşık bir gereksinim diyorum çünkü etkili bir şekilde birçok benzersiz gereksinimin bir koleksiyonudur. Ortaya çıkan gereksinimler atomik düzeyde olmalıdır. Başka bir deyişle, her gereksinim benzersiz ve eksiksiz bir düşünce olmalıdır. Ancak müşteri ile bu seviyeye ulaşmanın en iyi yolu nedir? Gerçeklik (ve deneyim), birçok gereksinimin aslında belirtilenden çok daha karmaşık olduğunu söylüyor.  

Müşterinin bize iyi şartlar vermesini beklemememiz gerektiğini unutmayın. Çözülmesini istedikleri sorunu bize sağlamaları gerekiyor. Bu açık değilse, onlara sormamız gerekir! Onlar sorunun uzmanlarıdır. Bu ifadeyi biraz daha takip edersek, Müşterinin yeni sistemi kullanmak için üç ayda 500 kişiyi eğitmesi gerektiğini görebiliriz. Elbette kullanıcı dostu olmalıdır. Ancak Müşterinin gerçekten ihtiyaç duyduğu şey, yeni kullanıcıların hızlı bir şekilde eğitilmesini sağlamanın bir yoludur. Bu, çözümün odağını değiştirebilir – kullanım kılavuzları, çevrimiçi eğitim, öğreticiler vb.  

Kullanıcı dostu bir sistem için bu basit isteği alalım. İşte sorunlardan bazıları.

  • Bir Müşteri, bir atölyenin kullanıcı dostunun ne anlama geldiğini belirleyin. Müşteri onlar için düşünmemizi istiyor. Ne de olsa biz onların “danışmanı”yız.
  • Müşteri ne istediğini tam olarak bilmiyor. Kullanıcı dostu olmanın onlar için ne anlama geldiğini tam olarak düşünmediler. Bunu eklemiş olabilirler çünkü bu iyi bir fikir ve herkes yapıyor. 
  • Müşteri bize kaliteli girdi sağlamak için çok meşgul. Kullanıcı dostu olmanın onlar için ne anlama geldiği hakkında yarım saat konuşmalarını isteyin ve zaman harcamayı reddedebilirler.
  • Müşteri, kullanıcı dostu bir sistem arayan tüm kullanıcıları belirlememiş olabilir. Diğer bir deyişle, sistemin kullanıcı dostu olup olmadığını belirlemek isteyebilecek herkesi tanımlamamış olabilir. (ör. kurumsal müşteriler, kurumsal olmayan, deneyimli kullanıcılar vs. deneyimsiz kullanıcılar, yabancı müşteriler vb.).

Bu tür bir gereksinimle ilişkili riski azaltmak için yapılabilecek bazı şeyler vardır.  

  1.  Bazı yapmak ekranların prototiplenmesi ve kullanıcıya gösterilmesi. Onlara özellikle bunların kullanıcı dostu olup olmadığını sorun. Ardından, ekranların özelliklerini bir dizi kullanıcı arabirimi gereksiniminde yakalayın.
  2. Kendi kullanıcı dostu tanımınızı oluşturun. Kriterleri tanımlayın ve bunları kullanıcı kabul testlerinizi tanımlamak için kullanın. Bunları gözden geçirmesi için müşteriye sağlayın.
  3. Sorunu anlama çabanızı sürdürmeye devam edin.  Soru sormaya devam etmekten korkma ve müşterinin ihtiyacının arkasındaki gerçek nedeni araştırın.
  4. Gereksinimi ölçmek için net kriterleriniz olduğundan emin olun. Onsuz, Müşterinin gözündeki gereksinimi asla geçemezsiniz. Ve onsuz, gereksinim hiçbir şekilde işe yaramaz.
Visure'ın Veri Modelleri sayesinde karmaşık gereksinimleri yönetin

Gereksinim Yönetiminde Kullanım Örnekleri

Kullanım senaryoları, kullanıcının işini nasıl yaptığını belgelemede etkili bir araçtır. Genellikle "olduğu gibi" ve "olmak" olarak adlandırılan bu anlatılar, kullanıcının işini bugün (olduğu gibi) nasıl yaptığını ve yarın (olmak) işini nasıl yapmayı tasavvur edebileceğini anlamamıza yardımcı olur. Analistler gereksinimler ilişkisine ilişkin sorunlarla mücadele etmeye devam ettikçe, kullanım senaryoları giderek daha popüler hale geliyor.

Bununla birlikte, bazen kullanım durumları, sırasında etkili bir şekilde kullanılır. gereksinimlerin ortaya çıkarılması ve tanımı, ancak gereksinim yönetimine geçiş yapıldığında kaybolun. Bir kullanım durumundaki adımları düşünürseniz, her adım, kullanıcı veya sistem tarafından yapılan bir eylemi tanımlar. Gereksinimlerinizde istediğiniz ayrıntı düzeyine ve izlenebilirliğe bağlı olarak, kullanım durumundaki her adımı bir gereksinim bildirimi yapmayı düşünün. Örnek olarak aşağıdaki basit kullanım durumunu alın.

Sistem, Müşteriye hesap bilgilerini görüntüler.

Müşteri, hesap bilgilerini inceler.

Müşteri, Ödeme Seçeneğini seçer.

Sistem, Müşteriye ödeme seçeneklerini görüntüler.

Bu kullanım durumundan, iki Sistem adımı ve iki Müşteri (yani Kullanıcı) adımı olduğu oldukça açıktır. İki Sistem deyimini çıkarırsak ve gerekirse onlara "olur" eklersek, aşağıdaki iki sistem gereksinimini elde ederiz:

Sistem, Müşteri'ye hesap bilgilerini gösterecektir.

Sistem, Müşteri'ye ödeme seçeneklerini gösterecektir.

Bu iki gereksinim, sistem gereksinimlerinin temelini oluşturmaya başlar. Bu sistem gereksinimleri büyük olasılıkla birçok sistem gereksinimine ayrılacaktır, ancak bunları doğrudan kullanım durumundaki sistem adımlarına kadar takip edebiliriz.

Kullanım senaryolarının sistem analizi ve geliştirme için çok değerli bilgiler içerdiğini unutmayın. Ürünün teslim edildiğinde nasıl davrandığını doğru bir şekilde yansıttığından emin olmak için geliştirme boyunca sürekli olarak gözden geçirilmesi gerektiğinden kullanım durumları hiçbir zaman gerçekten bitmez. Kullanım senaryolarının rafa kaldırılmadığından, hem testlere hem de sistem gereksinimlerine göre izlendiğinden emin olun.


Bu gönderiyi paylaşmayı unutmayın!

Iyi