Teknik olmayan bir kişi küçük projeler için bir spesifikasyon yazmayı nasıl öğrenebilir?

Teknik olmayan bir kişi küçük projeler için teknik özellikleri nasıl yazabilir?

Bir arkadaşım bir istatistik projesinde bazı gelişmeleri dış kaynak bulmaya çalışıyor.

Özellikle, çok iyi bir şekilde çalışmakta ve şu anda elle yaptığı şeyi yapmak için senaryoların oluşturulmasını dış kaynak olarak kullanmak istemektedir.

Ancak arkadaşım son derece teknik değil. Teknik şartname yazma konusunda yetersiz.

Spesifikasyon yazdığında, Excel'de bir şey yapmayı tanımladığınız şekilde yazılır (bu hücreye gidin ve değeri o hücreye kopyalayın). Ayrıca aşırı derecede ayrıntılı ve birkaç kez örnekler veriyor. Köşe davalarını doğru bir şekilde tarif ettiğinden emin değilim.

Dışarıdan tedarik ettiği ilk proje başarısızlıktı. Bence bazı detayları abartmış, ancak köşe davalarını tarif etmemiş. Bu ve / veya kiraladığı kodlayıcı köşe davalarında düşünmemiş ve uygun sorular sormamış. Emin değilim. Ben onunla IM aldım ve tanımlamak için beş dakika veya daha az sürmesi gereken bir açıklama kazmak için bana yarım saat sürdü. Sonunda onun için senaryoları yazdım, ancak kodlayıcı ile olan işleminin neden başarısız olduğunu incelemedim.

Benden yardım istedi. Bununla birlikte, katılmayı reddediyorum, çünkü şartnameyi almak ve net şartlara çevirmek, açıkça yazılı bir şartname üzerinde çalışmaktan 10 kat daha fazla iş.

Öğrenmesi için doğru yol nedir? Kullanabileceği kaynaklar var mı? Kodlayıcıları olan küçük, düşük basınçlı uygulama projelerinden öğrenebileceği yollar var mı?

Komut dosyalarının çoğu istatistiksel ve veri işleme odaklı. Örneğin, bu sütunu alın ve üzerinde bir ortalama çalıştırın. Bu koşullar altında bu satırları çıkarın. Bu yüzden zorluk, bir web uygulamasını belirtmekten farklı.

Bu soruna iki olası yaklaşım görüyorum. Ancak, iki şeyi gerçekleştirmek önemlidir. Birincisi, gereksinim mühendisliği zor bir iştir - bir fikri bir sistemi kurmaya yetecek resmi bir şartnameye dönüştürmek çok zaman, çaba ve pratik gerektirir. İkincisi, iyi gereksinimleriniz varsa (herhangi bir biçimde, resmi bir teknik özellikten daha az resmi kullanıcı öykülerine ve kullanım durumlarına kadar), yazılımı gerçekten geliştirmek (ve daha erken bir zamanda oluşturmak) çok daha kolay, daha ucuz ve daha hızlı olacaktır.

Eğer arkadaşınız kurulacak çok sayıda yazılım aracı isteyecekse ya da bunları yapma niyetindeyse, en azından iş hedefleri ve işlem kavramı düzeyinde yazılım gereksinimleri yazmayı öğrenmelidir. Yazılım gereksinimleri mühendisliği üzerine önde gelen iki kitap Karl Wiegers'e aittir - Yazılım Gereksinimleri (2. Baskı) ve Yazılım Gereksinimleri Hakkında Daha Fazla Bilgi: Dikenli Sorunlar ve Pratik Öneriler . Kiralayacağı kişilerin çoğunun, sistemi tanımlayan, en azından işletme hedefleri veya işlemler kavramı düzeyinde bir tür belge istemesini beklerdim ve bu kitaplar buna karışır. Ayrıca, iyi bir geliştiricinin projenin başlarında geçeceğinden şüphelendiğim gereksinim mühendisliğinin diğer yönlerinin neden ve nedenlerine giriyorlar.

İkinci seçenek, sorun alanını anlamak ve yazılım çözümlerinin nerede gerekli olduğunu ve yazılım çözümlerinin nerede olmayacağını belirlemek için yazılım geliştirme ve gereksinim mühendisliği (ve hatta bazı sistem mühendisliği veya sistem mimarisi) konusunda tecrübeli birini işe almak olacaktır. yararlı, belgeleri yazın ve hatta geliştirme çabalarını denetleyebilir veya yürütebilir. Bununla birlikte, bu, muhtemelen yalnızca istenen sistemi geliştirmek için değil, aynı zamanda ihtiyaç duyulan gereksinimleri ve mimariyi geliştirmek için tam zamanlı bir yazılım geliştiricisini uzun süre işe almak için de daha pahalı ve tutar olacaktır.

Dürüst olmak gerekirse, arkadaşınızın yaşadığı şeyin yazılım geliştirme sürecini anlamayan biri için bu kadar nadir olduğunu düşünmüyorum. Ayrıca suçlamanın tamamen ona da dayandığını sanmıyorum. İlk yazılım projesinin iyi gereksinimleri olmadıysa, geliştiricinin / kaynakların gereksinimleri netleştirmesi, rafine etmesi ve belgelendirmesi gerekiyordu. Açıkçası, teknik olmayan kullanıcı / müşteri ile çalışmak ve iyi teknik özellikler geliştirmek için zaman veya çaba harcamak istemiyorsanız, katılmaya doğru kişi olduğunuzdan da emin değilim. herhangi bir mühendislik disiplinde gereksinim mühendisliği yapan herkesin kilit rolüdür).

Bence en uygun çözüm gerçekten iki seçeneğimin bir birleşimi. Arkadaşınızın (ve belki de siz) gereklilik mühendisliğine neyin dahil olduğunu ve sağlam gereksinimlere sahip olmanın bir projeye getireceği faydaları öğrenmesi gerektiğini düşünüyorum. Ayrıca, bir yazılım geliştiricisi olarak, gereksinim mühendisliği ve yazılım projeleri için uygun olan gereksinimleri nasıl belirleme, belgeleme, analiz etme ve yönetme konusunda daha fazla bilgi sahibi olmalısınız - yazılım yaşam döngüsünün herhangi bir bölümünde iş yapan herkes için gerçekten değerli bir beceri.

Teknik olmayan bir müşteriden teknik özelliklere ihtiyacım olduğunda, onlardan genellikle başarmak istedikleri şeyin ne olduğunu basit bir dilde yazmalarını isterim. "C tuşuna bastığımda uygulamanın A'dan B'ye yapması gerekir, ancak yalnızca D ise" gibi. "Çünkü D demek ki ..." için ekstra bonus.

Aslında "bu sütunu al ve ortalamasının üzerinden geç." doğru yönde bir adımdır. Daha iyi bir açıklama “Tablo bunu ve bunu içerir” olacaktır (eğer yapı önceden tanımlanmışsa); Msgstr "Ortalama X alın". Temel olarak, ayrıntıları kaybetmeden mümkün olan en az teknik yol.

Başka bir deyişle, uygulamayı değil, fikri tarif edin.

Öyleyse, özenli bir programcı ne yapması gerektiğini asıl amacını anlayabilmeli ve doğru olmayan adımları seçip, net olmayan herhangi bir şey için sorular sormalıdır.

Yeterince önemseyen ve süreci anlayan kimse yoksa, proje her durumda başarısız olacaktır.

Film şeridi yaklaşımını kullanmayı deneyebilir .

Uygulamanın yapmak zorunda kalacağı şeylerin ( hikayelerin ) bir listesini yazmasını ve bu listenin içinde yer almasını sağlayın, her hikayenin işlevselliği hakkında daha fazla bilgi verin.

Proje kapsamını ve işlevselliğini ortadan kaldırmak için Asana gibi bir araç kullanabilir ve hatta geliştiricisi ile etkileşime girebilir.

Net gereksinimlere dönüştürmek, açıkça yazılmış bir teknik üzerinde çalışmaktan 10 kat daha fazla iş.

Amin. Bu ayrıca nedenini açıklar:

Kiraladığı kodlayıcı köşe davalarında düşünmedi ve uygun sorular sordu.

Gereksinimleri anlamak çoğu programlama projesinin en zor (ve en pahalı) kısmıdır. Teknik olmayan bir kişi gereksinimleri yazdığında, genellikle yalnızca değiştirmek istedikleri işleri düzenler ("Excel'i aç, B3 hücresini ..." tıkla). Umut edebilecekleri en iyi şey, şu anki zorluklarının tam bir kopyası!

Bu sorunu çözmenin en verimli yolu, bu kişiyi Kullanım Vakaları ("gevşek" ile "tekerlemeler" kullanmak) yazmaya teşvik etmektir . Yazma gereksinimleri yerine, sistemin nasıl kullanılacağını açıklayın. Bu, geliştiriciye, kullanıcının şu anda yaptıklarından daha iyi bir çözüm önermek için bir kıkırdak odası bırakıyor.

Bu problem arkadaşınızın zayıf yazılı iletişim becerileri tarafından daha da kötüleşiyor gibi geliyor. Çalışmayı fikirlerini etkili bir şekilde iletmek için ya da programcıya, onlardan bilgi elde etmek için para ödemek zorundadır. Her iki işlem de acı verici ve zaman alıcıdır, ancak bunu kendiniz yapmak, birisine sizinle birlikte yapması için ödeme yapmaktan daha ucuzdur.

Her durumda, bu yaratıcı insanların eksik bir fikre sahip oldukları veya bunu bir milyon kelimeden daha az açıklayamadıkları ortak ve sinir bozucu bir zorluktur. Bu kişi, gerçekten yapmaya çalıştığı şeyin ne olduğunu anlamaya ve bunu gerçekleştirmeye istekli, son derece sabırlı ve anlayışlı bir programcı bulmaya çalışmalıdır.

İşe aldığı kodlayıcı uygun sorular sormadı.

Bu felaket için bir reçete. Yani, hem de beklenti kodlayıcı olduğunu edecektir sorun. Kodlayıcılar kodlama yapmak, iletişim kurmamak, alışkanlıklarını teşvik etmeden kırmalarını beklemek oldukça gerçekçi değildir.

Eğer arkadaşınız iş yapmak istiyorsa, kodlayıcı ile sürekli iletişim içeren bir süreç daha iyi kurarlar - kodlayıcıyla değil, aktif bir rol oynamak zorunda olan arkadaşınızdır. "Bana her pazartesi ne yapıldığını göster ve bunu her salı günü görüşmek için iki saat ayarla" gibi şeyler.

• Bir giriş için, yinelemeli ve Çevik geliştirme metodolojilerinin (Wikipedia makalelerinin yapacağı gibi) bazı hafif genel bakışlarını sağlayın, böylece nasıl olması gerektiği hakkında bir fikir edinir.
   
• Geçmişte başarısız olmalarını anlamalarına yardımcı olmak için, onlara Waterfall / Big Design Up Front’un bazı hafif özetlerini sunun (eleştirileri içerenler - yine Vikipedi’nin makaleleri) - bunlar genellikle doğru olanı belirlemenin ne kadar zor olduğunu açıklayan oldukça iyi bir iş çıkarıyor ön.

Tecrübelerime göre, teknik olmayan müşterilerle istenildiği gibi yazılım çalışması yapmanın en güvenilir yolu, bir kerede ölümü belirtmeye çalışmak yerine, özellik açıklamalarını kalıcı olarak iletmek ve yinelemekti.

Komut dosyalarının çoğu istatistiksel ve veri işleme odaklı. Örneğin, bu sütunu alın ve üzerinde bir ortalama çalıştırın. Bu koşullar altında bu satırları çıkarın. Bu yüzden zorluk, bir web uygulamasını belirtmekten farklı.

Farklı - bir web uygulaması belirtmekten çok daha basit görünüyor. Bu mantıklı bir süreç. Bu kolay şeyler.

Arkadaşınız bu işlemi yaparken attığı adımları not etmeli. İstediği halde yapabilir, ancak odaklanması gereken önemli şeyler doğruluk, özlülük ve açıklıktır. Tamamen metin olarak bir el yazması gibi yapılamamasının bir nedeni yoktur; bileşenlerin veya görevlerin bazı mantıksal bölümlerinden faydalanacak ve muhtemelen bir akış şeması veya şeması olarak iyi çalışacaktır.

Artık arkadaşınız yetkili bir analist / geliştirici bulmalı ve hizmetlerini parça parça birleştirmelidir. Beklentilerini ortaya koyması gerekiyor - arkadaşınızın geliştirici ile buluşması ve en az haftada en az birkaç kez geliştiriciyle görüşmesi ve ilerlemenin bir göstergesi olduğunu görmesi gerekiyor. Arkadaşınız geliştiriciye bu gösteriler sırasında harcadığı zaman ödeyecek, ancak projenin spesifikasyona uygun olmasını sağlamak için buna değer. Şartnamede yapılacak herhangi bir değişiklik - yani arkadaşınızın ihmal ettiği şeyler - müzakere edilmesi ve muhtemelen teklif edilen fiyata eklenmesi gerekir.

"Yetkili" dediğimi unutmayın - bu "ortalama" ile aynı değildir, çünkü yetkin olmayan birçok "ortalama" geliştirici vardır. Arkadaşınız etrafındaki en ucuz kodlayıcıyı alır veya çevrimiçi birini bulursa, sorun beklemesi gerekir. Çevrimiçi olarak iş bulan insanların iyi olmadığını öne sürmemek, ancak hiçbir öneride bulunmadan birisini işe almazsınız.

Arkadaşınız sadece doğru kişiyi bulmalı. Herhangi bir yazılım projesinde analistlere, programcılara, sistem yöneticilerine, test uzmanlarına ve proje yöneticilerine ihtiyaç vardır. Arkadaşınız bu rollerden ne kadarını 'dış kaynak kullanmak' ister, sağlayıcı ne kadar yetenekli olursa ve arkadaşınız o kadar fazla ödeme yapmayı beklemelidir.

Bunu kıran kişi olduğum için özür dilerim, ancak resmi özellikleri nasıl yazacağını öğrenmek teknik olmayan bir kişinin işi değil. Teknik olmayan kişiyle röportaj yapmak, kişinin neyin peşinde olduklarını size söylediklerini damıtmaya çalışmak, müşterinin gerçekte ne istediğini belirlemek (ne istediklerini düşündüğünün aksine) her zaman aynı şey değildir), göreceli olarak gayrı resmi bir gereklilikler belgesi (iyi yapılandırılmış ancak müşterinin anlayamayacağı bir jargondan kaçınmaya çalışan) bir belge oluşturun ve bu belgeyi müşteriyle birlikte gözden geçirin.

Müşteri gayrı resmi gereksinimler belgesinden memnun olduğunda, neyin gerekli olduğu konusunda daha fazla teknik ayrıntıya girmeye başlayan daha resmi bir gereksinim belirtimi hazırlamak için bunu kullanabilirsiniz.

Tüm bu süreç "gereksinimler yakalama" olarak bilinir ve yazılım mühendisliği sürecinde ilk adımı oluşturur. Aslında yazılımı yazmak, yazılım mühendisliğinin sadece nispeten küçük bir parçasıdır, ne yazık ki birçok yazılım geliştiricisinin unuttuğu bir gerçektir. Unutmuş gibi gözüktüğü diğer bir şey de, müşterileri ile iletişim kurmaya ve olayların devam etmesini sağlamak için tüm süreç boyunca onlarla diyaloğu yerinde tutmaya ihtiyaç duyulmasıdır.

Teknik olmayan insanlarla iletişim kurmaya gelince, onlarla konuşurken bilgisayar jargonunu ve yazılım geliştirmeyi kullanmaktan kaçınmaya çalışmanız çok önemlidir. Eğer kendi alanlarından jargon terimleri kullanıyorlarsa, bu terimlerin ne anlama geldiğini anlamak önemlidir, bu nedenle bu terimler için resmi tanımlar almak üzere bir proje sözlüğü hazırlamak isteyebilirsiniz. Sonuçta onlar için çalışıyorsunuz, bu yüzden nereden geldiklerini anlamak önemlidir.

jargon yerine, korkutucu olmayan iletişim kurma yollarını kullanmayı denemelisiniz, müşterinizle iletişim kurmaya çalışın, düz İngilizce olarak yazılmış belgeler bir yardımcıdır, ancak yazılım işinde çalışan birçok kişi insanlar yerine bilgisayarlara yazmak için kullanılır ve bu yüzden bunu bulabilir. zor. Ek olarak, müşteriler dilleri ne kadar sade olursa olsun, büyük kağıt yığınlarını okumaktan hoşlanmazlar; bu nedenle görsel yardımlara başvurmak isteyebilirsiniz. Diyagramlar, tel kafesler ve storyboardlar burada yararlı araçlardır.

Fakat kısaca, asıl mesele, dilinizi öğrenmek müşterinizin işi değil, dilini öğrenmek sizindir.