Numune üzerinde düzeltme için teknik görev. Araştırma Enstitülerinde Havalandırma Modernizasyonunda Teknik Görev TK

Pavel Molanov

Murphy yasasını hatırlıyor musun? Doğru şekilde anlaşılamayacaksanız, kesinlikle doğru anlaşılırsınız. Bu, yalnızca insanlar arasında iletişim kurmada değil, aynı zamanda sitelerin yaratılmasında da adil. Müşteri, ikinci "facebook" istedi ve genç köpek yetiştiricileri forumunu aldı. Geliştirici, müşterinin dilek listesini tahmin etmedi - zaman harcadı.

Bu rehberde size ne ve neden teknik başlatma konusunda yazmanız gerektiğini söyleyeceğim. Aynı zamanda, TK oluşturulmasının harcanan zamana sarılmamasını nasıl gerekli olmadığını göstereceğim.

Makale yararlı olacak:

• Sitelerin oluşturulmasıyla ilgili olan herkes: geliştiriciler, tasarımcılar, kameramen.
• Proje yöneticileri.
• Dodjital Studios'un başkanları.
• Sitenin gelişimini sipariş etmeyi planlayan girişimciler.

Malzemenin iyi olması için, çeşitli geliştiricilerin, tasarımcıların, proje yöneticilerinden ve Dijital Stüdyoların sahiplerinden oluşan yorumları topladım. Makalenin sonuna en değerli eklendi. Hadi anlayalım.

Toplu nedir ve neden gerekli

Teknik görev, sitenin gereksinimlerinin kaydedildiği bir belgedir. Daha net, bu gereklilikler daha ayrıntılı olarak boyanır, bu işlemdeki tüm katılımcıların ne olması gerektiğini anlar. Öyleyse, herkesin sonuçtan memnun kalması ihtimali büyür.

Teknik görevin temel amacı: Müşterinin ve yüklenicinin birbirlerini doğru bir şekilde anladığından emin olun.

Çok fazla teknik görev kullanımı. Her iki taraf için kendi.

Müşteri için kullanın:

• Ne para ödediğini anlayın ve site ne olacak. Yapıyı hemen görebilir, neyi ve nasıl çalışacağını anlayabilirsiniz. Frekans, her şeyin tatmin olsun. Değilse, gelişim başlamadan önce herhangi bir sorun olmadan değiştirin.
• Sanatçının yetkinliğine bakın. Teknik çerçeve açıksa açık ve açıksa - geliştiriciye güvenir. Yulaf lapası oraya yazılırsa - belki de koşmaya değer ve etrafa bakmamak.
• Sanatçının vızıldayanlığına karşı düzeltin. Site hazır olduğunda, teknik göreve göre kontrol edilebilir. Tutarsızlık var mı? Geliştirici onları düzeltmelidir. Resmi olarak işbirliği yaparsanız ve bir sözleşme yaptıysanız - Mahkemeyi bile zorlayabilirsiniz.
• Sanatçıların değiştirilmesini basitleştirin. Müşteri ve geliştirici olgunlaşmış ve kaçarsa, sitenin oluşturulması kuvvetli bir şekilde geciktirilebilir. Detaylı bir ekonomi olduğunda, yeni bir takıma devredilebilir - zaman daha hızlı çalışmaya başlayacaktır.
• Karmaşık bir ürün geliştirme maliyetini öğrenin. Kesin zamanı ve karmaşık bir web hizmeti geliştirmenin maliyetini değerlendirin. Öncelikle, hizmetin nasıl çalışacağını ve hangi işlevlerin içinde olacağını anlamanız gerekir. Bunu yapmak için ve vaka pazarını hazırlamanız gerekir.

Sanatçı için Fayda:

• Müşterinin ne istediğini anlayın. Müşteri, onlarca soru sorulur, örnekleri gösterin, çözümler sunar. Ardından her şeyi tek bir belgeye yazın ve koordinatı yazın. Eğer tamam tamam şerefe ise, doğru anlaşılırsınız.
• Müşterinin ani sularına karşı düzeltin.Bazen yarım görevi değiştirmek isteyen müşteriler var. TK'yi kabul ettiyseniz ve imzaladıysanız, çok benzer değilsiniz. Bu durumda, mahkeme bile yanınızda olacak.
• Yetkinliğini göster. Soğuk hazırlanan bakım, müşteriye geliştiricilerin pahasına gösterecektir. Şirket, sitenin gelişimine güvenip güvenmeyeceğinden şüphelenmişse, yüksek bir olasılıktan dolayı şüpheler.
• Para kazanmak. Bazı stüdyolar ve geliştiriciler, TK'nin ayrı bir hizmet olarak derlenmesini sunar.

• Geliştirme sürecini kolaylaştırmak ve hızlandırmak. İyi TK'de, site yapısı, her sayfadaki gerekli fonksiyonlar ve öğeler belirtilir. Tüm gereklilikler zaten gözlerimizden önce olduğunda - sadece paskalyaya gitmek ve kod yazmak için kalır.

Şimdi, tüm bu işlevleri yerine getiren iyi bir ekonomi nasıl yapacağınızı anlayalım.

Bakım bir sanatçıdır

Genel olarak, pazar kimseyi yapabilir. "Bir diş kliniği için bir kartvizit ihtiyacımız var" - bu zaten toplu. Ama işlevlerini yerine getirecek mi? Olası olmayan.

İyi tz her zaman sanatçıdır: Proje Yöneticisi veya Geliştirici. Açıkçası, Web geliştiricisi, bir kafe veya diş kliniğinin sahibinden daha fazla sitelerin oluşturulmasını anlar. Bu nedenle, projeyi tanımlayacak.

Bu, istemcinin ortadan kalkması ve "ZBS, onaylanması" için sonunda kaybolduğu ve göründüğü anlamına gelmez. Ayrıca sürece katılmalı:

Tabii ki, müşteri TK'nin kendi versiyonunu çizebilir. Belki de bu, final ekonomisini yaratma sürecini hızlandırır. Ve belki de sessizce çöp içine atılan çöpü ortaya çıkar.

Kesin ve doğru bir şekilde yazın

Bu tavsiye, dava pazarının ana hedefinden takip eder - "Müşterinin ve sanatçının birbirlerini doğru bir şekilde anladığından emin olun."

Teknik görevde yüksek kaliteli sıfatlar olmamalıdır: Güzel, güvenilir, modern. Kesin olarak anlaşılamazlar. Herkesin kendi güzellik ve modernlik kavramları vardır.

Bak. Sonuçta biri, bu tasarımın güzel olduğunu düşündü ve web sitesinde kullanmasına izin verildi:

Aynı şey - yalnız bir şey ifade etmeyen belirsiz formülasyonlarla:

• Site müşteri gibi olmalı. Ve eğer kötü bir ruh hali varsa?
• Site uygun olmalıdır. Bu ne anlama geliyor? Ne için uygun?
• Site ağır yüklere dayanmalıdır.10 bin ziyaretçi? Veya 10 milyon?
• Nitel uzman içeriği. İyi, anlaşıldı.

Metinde belirsizlik olup olmadığını kontrol edin. Varsa - yeniden yaz. İfadeniz açık ve doğru olmalıdır:

• Site hızlı bir şekilde indirilmeli → sitenin herhangi bir sayfasının Google PageSpeed \u200b\u200bInsights'ta 80'den fazla noktaya sahip olması gerekir.
• Büyük yükler → aynı anda 50 bin ziyaretçi.
• Ana sayfa bir makalenin listesini görüntüler. → Son sayfa, son 6 yayınlanmış makalenin bir listesini görüntüler.
• Minimalist kullanıcı dostu abonelik arayüzü → "E-posta bırak" alanını bırakın ve "abone olun" → * çizilmiş kroki *.

İfadeyi çözdük, yapıda koşalım.

Genel bilgileri belirtin

Tüm ekip üyeleri, şirketin ne yaptığını ve hedef kitlesinin kim olduğunu doğru bir şekilde anlamalıdır. Böylece hiç kimse kafası karışmaz, vaka pazarının başında kayıt olmak daha iyidir.

Ve yine de sitenin amacını belirlemelisiniz ve işlevselliğini bir blog yerine çevrimiçi bir mağaza alamamak gibi.

Karmaşık terimleri açıklar

Teknik tasarımın ilk kuralı - amaçlandığı herkes için net olmalıdır. Müşterinizi anlayamayan terimleri kullanacaksanız - bir çocuk oyuncak mağazasının sahibi - onları açıkladığınızdan emin olun. Anlaşılabilir dil, Wikipedia'dan bir kopyaya yapıştır.

Araçları ve barındırma gereksinimlerini tanımlayın

2 ay serin bir site yaptığınızı hayal edin. Her aşama müşteri ile koordine edildi - o memnun oldu. Ve şimdi iş çekme zamanı. Yönetici panelini gösterirsiniz ve müşteri bağırır: "Bu nedir? MODEX?! "WordPress" de yapacağınızı düşündüm! "

Böylece böyle bir problem olmaması, kullanılan araçları, motorları ve kütüphaneleri tanımlayın. Aynı zamanda, barındırma şartlarını belirtin. Asla bilemezsin, PHP'de yapacaksınız - ve sunucunun. NET'te.

Sitenin gereksinimlerini listeleyin

Site, tüm topikal sürüm tarayıcılarında ve her türlü cihazda çalışmalıdır. Evet, herhangi bir geliştirici ve herhangi bir müşteri için açıktır. Ancak, müşteriyi haksız yere tamamlanmış işten korumak için yazmak daha iyidir.

Ayrıca, sitenin indirme hızı, yüklere kararlılık, hacker saldırılarına karşı koruma ve benzeri şeyler için gereksinimleri de yazacaksınız.

Site yapısını belirtin

Tasarım ve düzen tasarlamanın başlamasından önce, site yapısının müşterisine katılmanız gerekir.

Müşteri ile iş, ne gerekiyorsa öğrenin. Geliştiricileri, Soshechnikov, pazarlamacılar, komutanları toplayın - ve sitede hangi sayfaların gerekli olduğuna karar verin. Hangisine gidebileceğinizi, nasıl birbirine bağlanacağını düşünün.

Yapı listesini gösterebilirsiniz, bir blok şeması çizebilirsiniz. Tercih ettiğiniz gibi.

Bu, sitede çalışmanın en önemli aşamalarından biridir. Yapı bir temeldir. Başarısız olsaydı - site bir eğri olarak ortaya çıkacak.

Her sayfada ne olacağını açıklayın

Müşteri, neden her sayfanın ihtiyaç duyduğu ve hangi öğelerin üzerinde olacağını anlamalıdır. Göstermenin iki yolu var.

Prototip - daha görsel ve açık bir şekilde. Sanatçı, her sayfanın eskizlerini çizer ve bunları teknik lansman yapmalarını sağlar. Müşteri, gelecekteki sitesinin arayüzünün nasıl görüneceğini ve hoşlanacağını ve değişmeye değer olduğunu söylüyor.

Elementlerin numaralanması - Prototipe tembel alternatif. Sadece hangi bloklar sayfada ve ne yaptıklarını yazın.

Kanalizasyon sitesi senaryoları kullanın

Bazı standart olmayan bir arayüz yaparsanız, sadece sayfaların yapısını ve eskizlerini yeterli değildir. Sanatçıların tamamının ve müşterinin tüm ekibinin ziyaretçilerin siteyi nasıl kullanacağını anlaması önemlidir. Bu amaçla, komut dosyaları harika. Komut Dosyası şeması çok basittir:

• Kullanıcı eylemi.
• Site yanıtı.
• Sonuç.

Tabii ki, standart bir kartvizit veya borç verme yaparsanız, komut dosyaları yazmanız gerekmez. Ancak sitede bazı etkileşimli hizmetler varsa - çok arzu edilir.

Wikipedia'daki senaryolarda daha fazla bilgi edinin.

İçerikten kimin sorumlu olduğunu belirlemek

Bazı geliştiriciler siteyi hemen içeriğe sahip hale getirir. Diğerleri balık koydu. Üçüncüsü, metinler yazabilir, ancak ek bir ücret karşılığında. Bunu kıyıda kabul edin ve teknik lansmanda düzelt, hangi içeriği hazırlamanız gerekir.

Metinlerin kalitesini değerlendirmek için objektif kriterler ile ortaya çıkın. "Hedef kitle için yararlı, yüksek kaliteli, ilginç ve satan içerikten" bir şey yazmamak daha iyidir. Bu çöp, kimseye ihtiyacı yok.

Tüm içeriğin benzersiz olması gerektiğini belirtin - faydalıdır. İcrüful olmayan sanatçılardan başka bir müşteri koruması.

Tasarımı tanımlayın (eğer yapabilirseniz)

Metin durumunda olduğu gibi, sitenin tasarımını tahmin etmek için nesnel kriterler zorlaşır. Eğer müşteri ile renk şeması hakkında kararlaştırdıysanız - yazın. Yazı tiplerinin reçete edildiği bir branş kitabı varsa - onları belirtin.

Güzel ve modern tasarım hakkında yazmak gerekli değildir. Hiçbir şey ifade etmiyor, gücü yok ve genel fu.

Çekilme yerine: dökme yapısı

Farklı görevler için TK yapısı kendi başına olacaktır. Yeni bir sosyal ağ için aynı teknik görevleri yapmak ve havuç toptana toptancılığı konusunda uyarıcıdır. Ancak genel olarak, bu bölümlere ihtiyacınız var:

• Şirket ve hedef kitlesi, hedeflerin hedefleri ve hedefleri hakkında bilgi.
• Müşteriye anlaşılmaz olabilecek terimlerin sözlüğü.
• Düzen ve çalışma alanı için teknik gereksinimler.
• Kullanılmış teknolojilerin tanımı ve barındırma gereksinimlerinin listesi.
• Sitenin ayrıntılı yapısı.
• Sayfaların prototipleri veya üzerinde olması gereken öğeleri tanımlamak.
• Standart olmayan bir arayüz kullanmanın senaryoları (isteğe bağlı).
• Geliştirici yapan içeriğin listesi.
• Tasarım gereksinimleri (isteğe bağlı).

• Yazılım gereksinimleri şartnamesini derleme kuralları. SRS, toplama evriminin bir sonraki adımıdır. Büyük ve karmaşık projelere ihtiyaç var.
• Yazılım geliştirme için TK standartları ve şablonları. Teknik görevler oluşturma için farklı misafirlerin ve metodolojilerin açıklamaları.

Bu, yazdığım kısmın sonu. Ancak, hyde yapmaya yardımcı olan uzmanlar tarafından başka bir yorum var. Oku, aynı zamanda ilginç.

Yorumlar geliştiricileri

Topluları nasıl oluşturduğunu bulmak için birkaç geliştiriciyle konuştum. Mikrofonu onlara iletiyorum.

Her şeyden önce, TK'nin müşteri olması gerekiyor - böylece sitesinin ne olacağını ve paranın ne geçeceğini anlayacak. Eğer bir şey yapılmazsa - TK'ye atıfta bulunabilir ve yeniden vermeyi isteyin.

TK, müşteri ile iletişim kurduktan ve görevi tasarımcı ile tartıştıktan sonra proje yöneticisidir.

Büyük müşteriler genellikle her bir düğmenin açıklandığı çok ayrıntılı TK'dir. Küçük şirketler, aksine, 100 sayfa için titiz belgeleri sevmiyorum. Uzun okumak ve kolayca önemli bir şeyi özlüyorum. Daha sık sık 10-15 sayfa için Laconic TK yaparız.

Belirtiyoruz:

• Şirket hakkında bilgi ve sitenin amacı.
• Tasarım gereksinimleri, renk gamı.
• İkinci el teknolojiler ve CMS.
• İçerikle ilgilenen - biz ya da müşteriyiz.
• Site yapısı her sayfaya kadardır.
• Her sayfanın açıklamaları. Prototip yok, ancak hangi öğelerin sayfada ve nasıl çalışmaları gerektiğini belirtiyoruz.

Son 2 bölüm en önemli olanıdır. Site olacak ve nasıl çalışacağı bir anlayış sağlayanlar.

Çok önemli bir nokta - teknik tasarımı geliştiricilere vermek imkansızdır ve her şeyi iyi yapacaklarını umuyorlar. TK, site için sitelerin bir listesidir, iletişimin yerini alamaz. Ekibin her bir üyesinin ortak bir hedefi anladığından emin olmak önemlidir ve sadece dere üzerinde görevleri gerçekleştirmez. Bir şey anlaşılmazsa - açıklamak, tartışmak, ayrıntılı yorumlar yapmak gerekir.

Eğer "Ürün Gereksinimleri Belgesi" isteğiyle yabancı sitelerden geçerseniz, teknik görevin (TK, PRD) öldüğü gerçeğiyle ilgili yaratıcı ve inandırıcı makaleler bulabilirsiniz. Kısmen, aynı fikirde olması gerekir - sıfırdan bir ürün geliştirirken, prototipleme, müşterinin kayıtlarının hacminden bazen çok profesyonelce olan daha ilginç ve daha verimli görünüyor. Ancak, baz sistemin iyileştirilmesi hakkında konuşursak, o zaman tamamen farklı bir dönüş alır. Biz iyileştirme ve ısmarlama gelişme ile yapılandırıldık, bu yüzden köpek bize yalan söylüyorsa köpek köpeği yedi. Genel olarak, bugün - satın alınan ve yüklü yazılımın iyileştirilmesine ilişkin en klasik teknik görevler hakkında. Kısacası, yarın hakkında.

Etkileşim Nedeni

Teknik bir ödev oluşturma sürecinin hazırlanmasına devam etmeden önce, sanatçının ve müşterinin projeye girdiği bir kuadricle hakkında konuşalım.

Gereksinimler- Sistemin istenen davranışının, müşteri tarafından açıklanan ve uygulanacak işlem sahibi tarafından açıklanan davranışı. Kural olarak, gereksinimler, iş deneyimi temelinde, programın uygun davranışının sunulması temelinde oluşturulur. Bunlar, geliştirici (satıcı) için kilit bilgilerdir, ancak, en fazla çarpışma sayısının ortaya çıktığı, hataların, gereksiz isteklerin ve benzeri olduğu şartların toplanması aşamasındadır.

Kaynaklar - İleri, makine, ekipman, geliştirme ortamı, zaman ve para gereksinimlerini uygulama sürecinde kullanılacak zaman ve para. Kaynaklar, teknik görevin onayı aşamasında net planlama ve değerlendirme gerektirir. Müşteriden önceliklerin yetkili yerleştirilmesi ve işçi kaynaklarının satıcı tarafından dağıtılması, zamanlamayı kırmamak ve diğer riskleri en aza indirmenize izin verir.

Yetenekleri - Kısaca ise, o zaman bu satıcının yapabileceği şeydir (sanatçı). Regionsoft CRM'lerimizin örneğini düşünün. İstemci sistemi satın alır ve iyileştirme çalışmalarını yapar: CRM'de Site ve Ciltleme olayları ile çevrimiçi mağaza sipariş numarasına entegrasyon oluşturmanız gerekir. Bu gerçekten gerçekleştirilen bir gerekliliktir, bir kaynağımız ve bunu yapma fırsatı var. Ve hala CRM CMS'ye, Site İçerik Yönetim Sistemi'ni geliştirmemiz ve sabitlememiz gerekir. Teorik olarak, biz yapabiliriz, ancak bunu ucuza yapma şansımız yok ve müşterinin bize insanı ve geçici kaynakları göreve atmak için bu kadar fazla ödeme yapma şansına sahip değil. Sonuç olarak, müşteri bu gereksinimi reddetmeyi reddediyor - ve CMS özellikle gerekli değil, her şey çok iyi. Ancak "açgözlülük" hakkında daha sonra.

Kısıtlamalar - TK'ten gelen görevleri zor veya imkansız hale getiren bir küme, bütçe, teknoloji yığını, lisanslı problemler, yasama yasakları, donanım yapılandırmaları vb.

Böylece, dört varlıkların hepsi kendileri arasında yakından iç içe geçmiştir ve projenin başarısını bir bütün olarak belirler. Her bir öğeyi düşünün ve teknik görev üzerinde çalışmaya devam etmeniz gereken kritik anları vurgulamaya çalışın.

Gereksinimlerin toplanması ve analizi

Bu, programdan istediklerini ortaya çıkardığı çok önemli bir içsel kurumsal süreçtir (burada ve sonra CRM alırız, ancak yöntemler diğer yazılım türleriyle çalışır) potansiyel kullanıcılar. Büyük bir satıcı tipi SAP veya sistem entegratörü, daha sonra yüksek olasılık olasılığıyla iletişim kurarsanız, bir iş danışmanının hizmetlerini kullanmanız için teklif edilecek (kişisel bir yönetici, o hesap yöneticisidir, o "şimdi Şirketimizde Temsilcisi "). Aslında, çoğu durumda, iki görevi olan sıradan bir satış pazarıdır: Projenin maliyetini açmak ve kancadan çıkmanıza izin vermeyin.

Zaten bir saat boyunca burada ve beyaz işaretçi panosuna bile dokunmadı. O gerçek bir sistem analisti değil

Sizden ve çalışanlarınızdan daha iyi, kimse şirketinizi tanımıyor. Bu nedenle, gereksinimlerin toplanması ve analizi, yalnızca satıcının yardımcı olabileceği görevinizdir, ancak hiçbir durumda işlemde müdahale edemez. Geliştiriciye benzer uygulamalar hakkında sorunuz, dikkat etmeyi ve devam etmeyi kontrol edin. Bu arada, iyi bir asistan, profil konularında iyi tanıyan ve yaklaşık olarak yazılımın mimarisini ve geliştirme sürecine işaret eden bir işareti temsil eden çalışanın olabilir - yaratma sürecini kapatmak için bir analist ve iç uzman olarak hareket edebilir. TK ve satıcı ile iletişim kurma.

Gereksinimleri toplamak için çok basit bir şema var.

1. CRM kullanacak birimlerin yöneticilerinden ve deneyimli uzman uzmanlardan bir çalışma grubu oluşturun. Bize seçmesi gereken çözümden bahsedin, demo sürümüne erişim sağlayın.
2. Çalışma grubunun üyeleri, çalışanlara bilgi aktarmalı ve isteklerini kesinlikle serbest formda yeni programa istemek zorundadır. Çalışanlardan biri böyle bir yazılımla karşılaşmadıysa ve gelecekteki kullanım yönünde konuşmaya hazır değilse, ona periyodik görevlerinizi tanımlamasını istemenize gerek yoktur, bu evrensel bir yaklaşımdır.
3. Ardından her birim setleri, CRM'de olmayan veya ne uyuşmadığını ve bilgiyi toplar.
4. Çalışma grubu, toplanan gereksinimleri analiz eder, kesişmeyi kontrol eder ve ortadan kaldırır. Örneğin, genellikle satış departmanı ve pazarlama departmanı aynı raporla sipariş edilir, ancak gereksinimlerde farklı şekillerde alanlar ve varlıklar olarak adlandırılabilir, ancak arkalarının arkasındaki veriler aynıdır. Buna göre, tek bir forma gelmeniz gerekir.
5. Çalışma grubu, gereksinimlerin bir listesini oluşturur ve öncelikleri belirler. Bu aşamada, satıcıyı bağlayabilirsiniz çünkü kaynaklardan sorumludur. Örneğin, size Regionsoft CRM için özel bir rapor oluşturmanızı isteyebilirsiniz ve site ile entegrasyon sipariş edebilirsiniz. Bu, görev açısından tamamen farklıdır, öncelik burada çok önemlidir.

Gereksinimler toplandıktan, analiz edildikten ve çalışanlarla ve yönetimle koordine edildikten sonra, teknik bir görev oluşturmaya başlayabilirsiniz. Satıcının şeklini sorabilir ya da kendiniz yapabilirsiniz - her durumda, baş ağrısından ve sizden tasarruf sağlayacak birkaç demir kuralları vardır ve CRM sağlayıcınız.

Teknik Görevin Anatomisi

Teknik bir görev oluşturma işlemi hakkında konuşursak, birkaç aşama vardır. Tutarlı geçişleri ve müşteriye istenen iyileştirmeye yol açar. İşte buradalar.

• Algılama - gereksinimlerin tanımı, çözülmesi gereken sorunları giderme.
• Analiz - gereksinimlerin analizi, anahtar ihtiyaçların tahsisi, genelleme.
• Adaptasyon, CRM yetenekleri ve mevcut iş süreçleri bağlamında gereksinimlerin değerlendirilmesidir.
• Belgeler - gereksinimlerin resmi ve ayrıntılı açıklaması, TK'nin koordinasyonu.
• Satıcı (Geliştirici) ile iletişim, Besten TK'ye göre yapılan iyileştirmeler hakkında satıcı ile yinelemeli bir etkileşimdir.
• Uygulama, satıcının gerekli işlevselliğin oluşturulması üzerindeki çalışmalarıdır. Satıcı müşteri ile sürekli olarak temasa geçerse daha iyidir - çıkıştaki ürün müşterinin vizyonuna en doğru şekilde uyacaktır.
• Test - Satıcı çalışanlarının işlevselliğini, müşterinin ve son kullanıcıların iç uzmanlarının, iyileştirme ve TK'nin uygunluğunu oluşturmak için, sistem performansını değiştirme sırasına göre kontrol etmek.

Genel olarak, teknik görev, bir proje oluştururken kesişebilecek ve işbirliği yapabilecek birkaç seviyenin gereksinimlerine dayanarak oluşturulabilir.

İş seviyesi- Hangi karmaşık ve öncelikli görevlerin çözüldüğü küresel seviye. Bu seviyeye, iş süreçlerinin entegrasyon, iyileştirilmesi ve modellenmesi, yeni fonksiyonel modüllerin geliştirilmesi ile ilişkilendirilebilir. Kural olarak, ciddi istişareler ve müşteri ile yakın işbirliği ile kaynak yoğun bir gelişmedir. Örneğin, bir seferde Regionsoft CRM'de, bu tür özelleştirilmiş revizyon depo, bilet ofisi ve üretimdi. Yavaş yavaş, değişiklikler serbest bırakıldı ve daha sonra toptan, perakende mağazaları ve hipermarketler için yeni bir ürün oluşturmasına izin verildi - Regionsoft Perakende.

Kullanıcı seviyesi veya kullanıcı grubu.Bu seviyede, mevcut arayüzün revizyonunda görevler uygulanır. Örneğin, kullanıcı bir imleci vurduğunuzda, son siparişin numarası ve durumuyla bir pencere görünmesini isteyebilir veya özel bir veri grubuna sahip özel bir rapor bulunur. Bu seviyede rafineri daha az zamandır işgal eder, ancak birçoğu olabilir - örneğin, pazarlama departmanından, lojistik ve teknik desteğin çeşitli gereksinimleri.

İşlevsellik seviyesi. Önceki kişiden ayırmak genellikle zordur, burada resmi bir kriter çalışması - iyileştirme, arayüzdeki herhangi bir şeyi görüntüleme düzeyinde değil, sistem mantığının iyileştirilmesi düzeyindedir. Bu, çeşitli sıralama, sohbet, telefon yetenekleriyle entegrasyonların gereksinimlerini içerir.

Servis seviyesi - Aslında, bu seviyenin gereksinimleri, düzeltmelerle yeni inşa eden ilke giren ilk olmalıdır. Bunlar, sistem yanıtının hızı için görevlerdir, yüksek yük altında, güvenlik. İdeal versiyonda Venndor bu tür iyileştirmelere sahip olmamalıdır - Kurumsal yazılım yavaşlamamalı, verileri kaybetmemeli, verileri kaybetmemeli, bir seviyenin izinlerini dağıtmak ve dağıtmak için formlar. Ancak gereksinim ortaya çıkıyorsa ve müşterinin kişisel oranı veya donanımın yanındaki sorunları ile ilgili değilse, ona yüksek ilgi göstermeye değer.

Teknoloji seviyesi - Listede sonuncusu, ancak önem ve zorluklar geri kalanın önündedir. Bunlar, platform, işletim sistemi veya cihazlarla ilişkili müşteri gereksinimleri olabilir. Örneğin, MacOS altında bir montaj koleksiyonu. Bu şartlar aşamalı olarak serbest bırakmaya devam ederse, çok havalıdır, ancak mutlaka düzeltmeler vardır. Bu seviyede müşteri isteklerindendir, MacOS altında bir Asoft CRM montajı yaptık ve TRM teknolojisini kullanarak Nadir, ancak mevcut bir mobil versiyon isteğinin geçici bir çözümü olarak TRM teknolojisini kullanarak silinmiş erişim ekledik.

Teknik görevin anatomisi, herhangi bir durumda iskelet biçiminde basittir. Teknik görevin zorunlu kısımları, müşterinin soruna odaklanmasına ve görevi doğru şekilde formüle etmesine ve yükleniciyi formüle etmesine yardımcı olur. Ondan ne istediklerini anlamak için. Bu arada, anlayış hakkında. Tabii ki, gönderinin başında biraz hayatta kaldık, iş danışmanlarını sınıf olarak inkar ediyoruz. Bu şöyle: Her satıcı, pazarda birkaç yıldır çalışır (biz birinci sınıf), aynı zamanda düzinen yıllardır, bu da hemen hemen her endüstride bir dizi vakanın olduğu anlamına gelir. Buna göre, mühendisler, programcılar ve satışlar, her şirkette uygulama özelliklerine aşina. Ama yine de, işinize odaklanmak önemlidir.

Kimin için?Bu bölümde, kimin sonlu bir iyileştirme kullanıcısı olacağını, hangi görevlerin ve hangi sıklığın çözülmesi planlanacağını tanımlamak gerekir.

Bir örnek vereceğim. Aynı şirkette CRM tanıttı, oldukça büyük bir veri dizisi üzerinde (ayda birkaç milyon rekor, günde birkaç yüz bin kayıt) çalıştığı kabul edildi. Satış Dairesi Başkanı, bu kayıtları "günlük" frekansı ile boşaltma hakkında bir rapor talep etti. Doğal olarak, eşzamanlı çalışmaya sahip böyle bir rapor, yüzlerce kullanıcıya yüklenen yüzlerce kullanıcıyı, işlemi optimize ettiği tespit edildi. Zaten iş sırasında, satışların yeniden inşa edildiği ve raporun yalnızca ayın sonuçları ile gerekli olduğu ortaya çıktı ve sonra geceleri bir programda başlatılabilir. Zamanın ve paranın boşuna harcandığını söylemeye değer mi?

Ne için?İş sürecinde iyileştirme ihtiyacının ve yeri gerekçesi. Bu ürün müşterinin kendisi için daha gereklidir, aynı zamanda diğer işlemlerin ne olduğunu bilmek için satıcıya da. Bazen alternatif bir çözüm bulmaya yardımcı olur.

Ne yapmalı?En bilgilendirici blok - sistemden gelen gereksinimleri, beklentilerini açıklar. Ve burada, BASHOMG'ye gelen ve hayattan çok karmaşık olan çok inciler, mucizeler ve çarpışmalar. Çünkü bir - kullanıcı ne yapmak istediğini bilmiyor. Hala küçük bir alt baskı var - kullanıcı gereksinimleri formüle edemez. Ve sonra geliştiricinin görevi (çalışma grubu, analitik, varsa) ihtiyacını doğru ifade etmeye yardımcı olur, uygun bir gereksinimi seçin, görevin bağlamında görevi girin. Aynı blokta, beklenen sonuçtan bahsetmeniz gerekir.

Teknik Görevin Parametreleri- Şartlar, uygulama aşamaları, her taraftan sorumlu, gerekli temaslar vb. Aslında, bu, teknik bir görevle bir belge yapan önemli resmi şeylerin bir birleşimidir. Teknik görev, gelişimin geliştirilmesinde sayısız değişikliği önlemek için taraflarca taraflarca koordine edilmeli ve imzalanmalıdır (hala, daha küçük bir hacimde).

İdeal versiyonda, teknik görev satıcının aktif katılımıyla derlenir ve toplamı yaklaşık olarak böyle bir yapıdır:

1. Her mekanizmanın gereksinimlerinin ve her işlevselliğin açıklaması
2. Bu işlevselliğin uygulanmasının açıklaması
3. Adımların her biri için çalışma maliyeti
4. Bu teknik ödevdeki toplam çalışma maliyeti
5. İşin yürütülmesi, sahnenin aşamalarının dağılımı ve gösterimi ile
6. Kurulum koşullarının ve testlerin açıklaması
7. Teknik görevin ve diğer koşulların ayrıntılı yapısı hakkında rezervasyonlar

Geliştiricinin gözyaşları tarafından yazılan 10 kural

Arıtma için teknik görev, TK'yı iyileştirmelidir., Müşteri için gerekli olan CRM'nin 300 sayfalık bir açıklaması değil. Gereksinimleri çözmeden önce, sistem arayüzünü, yeteneklerini, belgelerinin çoğunu dikkatlice okumalısınız, büyük olasılıkla, "İstek Listesinin" çoğu temel tedariktedir. Dahili arıtma araçlarına dikkat etmeyi tavsiye ederim (rapor tasarımcıları, yapılandırıcılar vb.) - Belki de gerekli değişiklikler düzenli bir programcı yapabilecek (birçok şirkette).

Teknik görev açgözlü olmamalıdır.Genellikle iş, yeteneklerini aşar ya da "hemen her şeyi" almak istiyor. Böyle bir yaklaşım, para açısından veya iş açısından haklı değildir. Satıcı, bir kural olarak, birkaç hafta yok (Regionsoft - 15 yaşında) yoktur ve ona başvurabilirsiniz ve bir süre sonra CRM'nin ne eksik olduğunu gerçekten anlayabilirsiniz.

Parlak bir yedeklilik örneği, tam anlamıyla dünden: Müşteri, ünlü bir Rus şirketinin ERP'sini satın aldı, muhasebe muhasebesinin, bu satıcının ERP'nin iyi olacağını düşünüyor. ERP kendi içinde çok değil, ama çok uygun bir iş olmadığı ortaya çıktı. Ancak depo muhasebesi ve üretimi olan Regionsoft CRM uygundur. Bir çözüm var: ERP'yi unutmak, ağlamak, 1C muhasebeyi yeni bir CRM ile entegre eder ve uygun bir uygulamada sevinir. Ancak taramasız para bir acıma! Ve müşteri, CRM'nin ERP ile entegrasyonunu gerektirir. Bunu yapmadık, ama neden böyle bir atık, neden iki nispeten benzer bir sistem?

Teknik görev gerçekçi ve yerine getirilmelidir - Her ikisi de gereksinimlere ve zamana göre. Bir veya başka bir göreve gittiğini tam olarak ne zaman geçtiğini bildiği için satıcının görüşünü dinlemek önemlidir. İnan bana, geliştirici zamanı çekmek ve terimi rüzgarlamak için karlı değil - bunun mümkün olduğu kadar çok projeyi tamamlaması ve bir üne bir darbe almamak için iyi yapması için karlı. Gerçekçiliğe gelince, CRM'yi basitçe çarpıcı yönetim sisteminin seviyesine bitirmek için taleplerden kaçının: şu anda ve öngörülebilir gelecekte neyin gerekli olanların gereklerine dahil edilmelidir.

Örneğin, Regionsoft CRM bir masaüstü programıdır, bir tarayıcı için bir istemcimiz yok. Bir şirket için bir web uygulaması oluşturmamızı istemek anlamsız, bu büyük bir gelişmedir, şimdi yapılmakta ve bir şirketin iyileştirilmesi mümkün değildir. Hayır, elbette, her şeyin fiyatı vardır, ancak tekrar - genel olarak, gereklilik zarar görmüştür.

Özel yapımsal gelişme söz konusu olduğunda durumla karıştırılmaya gerek yoktur ve uygulamanın fikri ve mantığı kökte, "kendiniz için" yeni bir yazılımın oluşturulması neredeyse yeni bir yazılımın oluşturulmasıdır. Ama bu başka bir hikaye.

Teknik görev ayrıntılı olmalıdır. Gelecekteki projenin tüm önemli ayrıntılarını belirlemeniz gerekir: Programı arayüzdeki isteklere kullanma sıklığından. Gereksinimler ne kadar çok belirlenirse, daha kolay ve daha hızlı uygulanacak ve test edilecektir. Özellikle belirli bir endüstride çalışıyorsanız (tıp, sigorta, bankalar) - iş etkileşimi nüanslarının ayrıntılı bir ifadesi ve programın satıcının görevini ve hızlı uyarlamanın anlaşılmasını sağlayacak olan ayrıntılara dikkat etmeye değerdir. sistemin şirketinize.

Sayıların formatlarına, alanların adlarına, açılır listelerin varlığı veya yokluğu, düğmelerin ve ipuçlarının davranışını, veri türlerine dikkat edin. Müşteri, CRM çalışmalarının mantığına atılması gereken kendi formüllerini kullanıyorsa ( Örneğin, bayilik bonuslarının hesaplanması) Bu formüller, tanımlarının tam kod çözülmesi ve hesaplama mantığı ile yazılmalıdır.

Evet, kurumsal yazılım böyle görünüyor ve içinde birçok önemli önemseme var.

Teknik görev açık ve doğru olmalıdır. Bulanıklık ifadeleri, uygulama seçenekleri, bulanık gereksinimler - ölü bir sonda tüm bu şekilde. İyi niyetlerden bir müşterinin sistemin davranışları için birkaç seçenek yazması, yakın, ancak TP'ye eşdeğer olmamasıdır. Bu durumda, size yardımcı olduğundan, programcıya söyler, ancak aslında, Cehennem'e giden yolun iyi niyetinin, geliştiricinin tam olarak ne gereksinimlerini anlamalıdır ve bunun nasıl yapılacağını, kendi özelliklerine dayanarak kendisini seçecektir. Sistem ve kullanılan teknolojilerin yığını.

Bu yıl tekrar bir arzu verebilirsin. Yalnızca, lütfen, anlaşılabilir iş gereksinimleri gibi, bile yerine getiremeyeceğim gerçeğini boşa harcamayın!

Teknik görev insan dilinde yazılmalıdır. Ve bu önemli, hayır, önemlidir. Dil ile ilgili sorunların projenin uygulanmasını sıkılmasına yol açtığında iki durumu tahsis edeceğim.

1. Müşteri, teknik okuryazarlığını göstermeye çalışıyor ve türün türünü göstermeye çalışıyor: "Bir olayı çağrı yapma olasılığı ile takvimin gövdesine sahip bir pencereye sahip bir pencere uygulamak ..." yerine, "takvimde Görevi yaptığınız şekilde işaretleyebileceğiniz bir pencere açın. " Siz veya iç uzmanınız teknik metinler yazma becerisine sahip değilse, Google - Normal kelimeler olarak yazmayın, onları anlıyoruz.

   Teknik görev düzaretçi bir kitap olmamalıdır. Sorunu çözmek, tarif etmemek, yazı tiplerine dikkat etmek ve gereksinimlerin açıklamasını unutmak gerekir. TK, sadece sorunun kendisini değil, aynı zamanda anlama düzeyinde de çözümü içermelidir - geliştirici zaten kod seviyesinde karar verir. Karşılaştırmak "Satış departmanı kötü planlıyor, rakamları kaybetti, zaten bir yıl boyunca savaşıyor" ve "Planın değerlerini ve aylık satış gerçeğini, isimlendirmenin grupları bağlamında tutacak bir rapor oluşturmanız gerekir".

   Teknik görev geleceğe bakabilmelidir.Pekala, değil, ama onun arkasında duran insanlar. İş süreçlerinde değişikliklerin yapıldığı biliniyorsa, revizyon için iki kez ödeme yapmamak için dikkate almak gerekir.

   Teknik görev bürokratik olmamalıdır. En az bir kez bu belgeyi oluşturursanız, muhtemelen bürokrasiye girme, iç kelimelere kaymak, sıkı devrimler ve her bir maddeyi ceza kanununun bir makalesi olarak tanımlamak için muhtemelen ihlal için herkes). Bürokratik formülasyonlar, TK oluşturma hedeflerinin eksik bir şekilde anlaşılmasını sağlar. Satıcının sorumluluğu sözleşmeye kayıtlıdır, bütçe oraya yazılır. Bu noktaları teknik görevde taşımayın.

   Teknik görev bir teknik görev olmalıdır. Paradoksal geliyor, ancak genellikle TK yerine, CRM veya toplantının dakikaları için harfleri, şikayetleri, sözleşmeleri, yeniden yazılı talimatları okuduk. Tabii ki, böyle bir belge için çalışmak imkansızdır. Form ve içerikten uzaklaşmamak için, eski okul numarasını kullanın: Dönemi göre düşünün. Teknik - Arıtma'nın dikte olduğu anlamına gelir, tekniğin yazılımı değiştirerek sorunu çözmeyi amaçlar. Bu, yazılım bağlamındaki görevdir ve konuşmanız gerekir. Görev, sorunun, ipuçları, ipuçları ve ön tahminler olmadan sorunların, sorunların olduğu anlamına gelir. Sadece ifadeler.

   Emirler sona erdi, şimdi ödül

   Listelenen kurallara ek olarak, söylemeye değer birçoğu daha var. Hedefler, planlar ve beklentilerden bahsediyoruz - projeyi başarılı kılan, ve satıcının ve müşterinin ilişkisi neredeyse güler yüzlüdür.

   Hızlı bir şekilde yazmanız gereken teknik görevHücresel bir operatörün veya büyük bir hipermarketin işlemini otomatikleştirme görevine sahip olsanız bile. Bunun nedeni, teknolojilerin büyük bir hızda gelişmesi ve hatta uygulandığınız sistem bile, altı ay boyunca bir yıl boyunca büyük bir sürüm (ve bazen iki) hayatta kalabilir, yeni işlevsellik kazandırabilir. Belki de işlemi tekrar geliştirip başlatma ihtiyacını tekrar gözden geçirmelisiniz.

   

   
   Sonunda, TK'yi tamamlamak için zaman buldu. Fakat ne yazık ki, orada onu uygulamak için geliştirici yok.

   Müşteri yığın ve teknik sınırlamaları bilmiyor.Ve bilmemelisin - bu, satıcının görevidir, teknik bir iş çıkardıktan sonra çalışmayı değerlendiren kişidir. Müşteri teknolojide derinleşmemeli ve satıcı bir veya başka bir şeyi yapabilirse, her virgül sormamalıdır. Kapsamlı bir TK yapın ve geliştirici uygun bir mimari seçecektir - genellikle düşündüğünüzden daha iyidir.

   Bütçeyi değerlendirin ve tatsız sürprizlerden kaçının - neredeyse bir ortak görev numarası. Satıcıyı ve talebini, çalışmanın yaklaşık bir değerlendirmesini (iyi, en az yaklaşık olarak boşluk, gözlerde ve diğerleri gibi, bu tür projelerde ve deneyimlerle, iyi, hatanın sınırları). Tamamen bir bütçe değerlendirmesi, yalnızca teknik görevin okuması, analiz edilmesinden ve son onaylanmasından sonra mümkündür. Geliştiriciniz aksi halde gelirse - iyileştirmenin en az iki kat daha pahalı olması nedeniyle hazır olun.

   Değişiklik ve uzantılar için nesnel ihtiyaçtan devam edin - Geliştiricinin yok olmadığını ve gereksinimlerinize herhangi bir zamanda değişiklikler ve ilaveler yapmaya hazır olduğunu yazdım. Bu nedenle, derhal CRM / ERP hayallerini oluşturmaya çalışmayın, "her şey kahve içmeye kadar çalışır" - sistemde çalışın, sistemde çalışın, sizin için kritik yorumları belirleyin ve gereksinimlerin toplanmasına ve TK'nin derlemesine devam edin .

   Teknik görevler hakkında sonsuz bir şekilde yazabiliriz, bu sadece memler ve Beacks değil, aynı zamanda baş ağrısı da gerçek bir jeneratördür. TZ İnsani Hakkında Kayıt için öncelik ve kurallar hakkında konuşabilirsiniz, bu da TZ İnsanları, IEEE Standartları Hakkında, Prototipler ve Tamamlayıcı TK hakkında biraz daha iyidir. Ama sonunda kendimizi bir taneye, en önemli kuralla sınırlamak istiyorum: Teknik görev, GOST ve DOGMA'yı değil, DOGMA'yı olmayan, bu nedenle, iyileştirebiliyorsanız, basitleştirebilirseniz, siz basitleştirebilirsiniz. zarif bir şekilde yapabilir ve mümkün kılmak için. Eminim, bundan sonra hiç kimse burnu TK'de zorlamaz ve orada yazılmadığını söylemeyeceğim. Ya da neredeyse hiç kimse yok.

   Tüm Aralık, Regionsoft CRM'de ve kendi gelişimimizin tüm yazılımlarında indirimler veriyoruz. 1 ila 15 Aralık -% 15 ve taksit ve kiralama koşulları. % -70 ve -90'a sahip değiliz, çünkü ekonomik olarak makul fiyatı lisanslar için tutuyoruz ve tavandan almıyoruz.

   Peki, bir CRM sistemine ihtiyacınız varsa (arıtma veya olmadan), sonra hadi web sitemiz CRM, avantajları ve diğer kurumsal yazılım hakkında çok şey var.

   Ve evet, biz her zaman CRM ve diğer ürünleri satmaya, CRM'yi iyileştirmeye ve satmaya hazır olan ortakları arıyoruz, yazılımı satmak ve kullanıcılara öğretiyoruz. Gelir bölünmesi dürüst ve karlı bir ortaktır. Göstereceğiz, söyle bana, öğret. Üzerine yaz [E-posta Korumalı]

   Slaytlar, slaytlar. Http://www.modernanalyst.com/'den ve Pinterest'ten alınan çizgi romanlar. Daha iyi bir çeviri varsa - postada yapmak için mutlu olacağız.

Eğer "Ürün Gereksinimleri Belgesi" isteğiyle yabancı sitelerden geçerseniz, teknik görevin (TK, PRD) öldüğü gerçeğiyle ilgili yaratıcı ve inandırıcı makaleler bulabilirsiniz. Kısmen, aynı fikirde olması gerekir - sıfırdan bir ürün geliştirirken, prototipleme, müşterinin kayıtlarının hacminden bazen çok profesyonelce olan daha ilginç ve daha verimli görünüyor. Ancak, baz sistemin iyileştirilmesi hakkında konuşursak, o zaman tamamen farklı bir dönüş alır. Biz iyileştirme ve ısmarlama gelişme ile yapılandırıldık, bu yüzden köpek bize yalan söylüyorsa köpek köpeği yedi. Genel olarak, bugün - satın alınan ve yüklü yazılımın iyileştirilmesine ilişkin en klasik teknik görevler hakkında. Kısacası, yarın hakkında.

Etkileşim Nedeni

Teknik bir ödev oluşturma sürecinin hazırlanmasına devam etmeden önce, sanatçının ve müşterinin projeye girdiği bir kuadricle hakkında konuşalım.

Gereksinimler- Sistemin istenen davranışının, müşteri tarafından açıklanan ve uygulanacak işlem sahibi tarafından açıklanan davranışı. Kural olarak, gereksinimler, iş deneyimi temelinde, programın uygun davranışının sunulması temelinde oluşturulur. Bunlar, geliştirici (satıcı) için kilit bilgilerdir, ancak, en fazla çarpışma sayısının ortaya çıktığı, hataların, gereksiz isteklerin ve benzeri olduğu şartların toplanması aşamasındadır.

Kaynaklar - İleri, makine, ekipman, geliştirme ortamı, zaman ve para gereksinimlerini uygulama sürecinde kullanılacak zaman ve para. Kaynaklar, teknik görevin onayı aşamasında net planlama ve değerlendirme gerektirir. Müşteriden önceliklerin yetkili yerleştirilmesi ve işçi kaynaklarının satıcı tarafından dağıtılması, zamanlamayı kırmamak ve diğer riskleri en aza indirmenize izin verir.

Yetenekleri - Kısaca ise, o zaman bu satıcının yapabileceği şeydir (sanatçı). Regionsoft CRM'lerimizin örneğini düşünün. İstemci sistemi satın alır ve iyileştirme çalışmalarını yapar: CRM'de Site ve Ciltleme olayları ile çevrimiçi mağaza sipariş numarasına entegrasyon oluşturmanız gerekir. Bu gerçekten gerçekleştirilen bir gerekliliktir, bir kaynağımız ve bunu yapma fırsatı var. Ve hala CRM CMS'ye, Site İçerik Yönetim Sistemi'ni geliştirmemiz ve sabitlememiz gerekir. Teorik olarak, biz yapabiliriz, ancak bunu ucuza yapma şansımız yok ve müşterinin bize insanı ve geçici kaynakları göreve atmak için bu kadar fazla ödeme yapma şansına sahip değil. Sonuç olarak, müşteri bu gereksinimi reddetmeyi reddediyor - ve CMS özellikle gerekli değil, her şey çok iyi. Ancak "açgözlülük" hakkında daha sonra.

Kısıtlamalar - TK'ten gelen görevleri zor veya imkansız hale getiren bir küme, bütçe, teknoloji yığını, lisanslı problemler, yasama yasakları, donanım yapılandırmaları vb.

Böylece, dört varlıkların hepsi kendileri arasında yakından iç içe geçmiştir ve projenin başarısını bir bütün olarak belirler. Her bir öğeyi düşünün ve teknik görev üzerinde çalışmaya devam etmeniz gereken kritik anları vurgulamaya çalışın.

Gereksinimlerin toplanması ve analizi

Bu, programdan istediklerini ortaya çıkardığı çok önemli bir içsel kurumsal süreçtir (burada ve sonra CRM alırız, ancak yöntemler diğer yazılım türleriyle çalışır) potansiyel kullanıcılar. Büyük bir satıcı tipi SAP veya sistem entegratörü, daha sonra yüksek olasılık olasılığıyla iletişim kurarsanız, bir iş danışmanının hizmetlerini kullanmanız için teklif edilecek (kişisel bir yönetici, o hesap yöneticisidir, o "şimdi Şirketimizde Temsilcisi "). Aslında, çoğu durumda, iki görevi olan sıradan bir satış pazarıdır: Projenin maliyetini açmak ve kancadan çıkmanıza izin vermeyin.

Zaten bir saat boyunca burada ve beyaz işaretçi panosuna bile dokunmadı. O gerçek bir sistem analisti değil

Sizden ve çalışanlarınızdan daha iyi, kimse şirketinizi tanımıyor. Bu nedenle, gereksinimlerin toplanması ve analizi, yalnızca satıcının yardımcı olabileceği görevinizdir, ancak hiçbir durumda işlemde müdahale edemez. Geliştiriciye benzer uygulamalar hakkında sorunuz, dikkat etmeyi ve devam etmeyi kontrol edin. Bu arada, iyi bir asistan, profil konularında iyi tanıyan ve yaklaşık olarak yazılımın mimarisini ve geliştirme sürecine işaret eden bir işareti temsil eden çalışanın olabilir - yaratma sürecini kapatmak için bir analist ve iç uzman olarak hareket edebilir. TK ve satıcı ile iletişim kurma.

Gereksinimleri toplamak için çok basit bir şema var.

1. CRM kullanacak birimlerin yöneticilerinden ve deneyimli uzman uzmanlardan bir çalışma grubu oluşturun. Bize seçmesi gereken çözümden bahsedin, demo sürümüne erişim sağlayın.
2. Çalışma grubunun üyeleri, çalışanlara bilgi aktarmalı ve isteklerini kesinlikle serbest formda yeni programa istemek zorundadır. Çalışanlardan biri böyle bir yazılımla karşılaşmadıysa ve gelecekteki kullanım yönünde konuşmaya hazır değilse, ona periyodik görevlerinizi tanımlamasını istemenize gerek yoktur, bu evrensel bir yaklaşımdır.
3. Ardından her birim setleri, CRM'de olmayan veya ne uyuşmadığını ve bilgiyi toplar.
4. Çalışma grubu, toplanan gereksinimleri analiz eder, kesişmeyi kontrol eder ve ortadan kaldırır. Örneğin, genellikle satış departmanı ve pazarlama departmanı aynı raporla sipariş edilir, ancak gereksinimlerde farklı şekillerde alanlar ve varlıklar olarak adlandırılabilir, ancak arkalarının arkasındaki veriler aynıdır. Buna göre, tek bir forma gelmeniz gerekir.
5. Çalışma grubu, gereksinimlerin bir listesini oluşturur ve öncelikleri belirler. Bu aşamada, satıcıyı bağlayabilirsiniz çünkü kaynaklardan sorumludur. Örneğin, size Regionsoft CRM için özel bir rapor oluşturmanızı isteyebilirsiniz ve site ile entegrasyon sipariş edebilirsiniz. Bu, görev açısından tamamen farklıdır, öncelik burada çok önemlidir.

Gereksinimler toplandıktan, analiz edildikten ve çalışanlarla ve yönetimle koordine edildikten sonra, teknik bir görev oluşturmaya başlayabilirsiniz. Satıcının şeklini sorabilir ya da kendiniz yapabilirsiniz - her durumda, baş ağrısından ve sizden tasarruf sağlayacak birkaç demir kuralları vardır ve CRM sağlayıcınız.

Teknik Görevin Anatomisi

Teknik bir görev oluşturma işlemi hakkında konuşursak, birkaç aşama vardır. Tutarlı geçişleri ve müşteriye istenen iyileştirmeye yol açar. İşte buradalar.

• Algılama - gereksinimlerin tanımı, çözülmesi gereken sorunları giderme.
• Analiz - gereksinimlerin analizi, anahtar ihtiyaçların tahsisi, genelleme.
• Adaptasyon, CRM yetenekleri ve mevcut iş süreçleri bağlamında gereksinimlerin değerlendirilmesidir.
• Belgeler - gereksinimlerin resmi ve ayrıntılı açıklaması, TK'nin koordinasyonu.
• Satıcı (Geliştirici) ile iletişim, Besten TK'ye göre yapılan iyileştirmeler hakkında satıcı ile yinelemeli bir etkileşimdir.
• Uygulama, satıcının gerekli işlevselliğin oluşturulması üzerindeki çalışmalarıdır. Satıcı müşteri ile sürekli olarak temasa geçerse daha iyidir - çıkıştaki ürün müşterinin vizyonuna en doğru şekilde uyacaktır.
• Test - Satıcı çalışanlarının işlevselliğini, müşterinin ve son kullanıcıların iç uzmanlarının, iyileştirme ve TK'nin uygunluğunu oluşturmak için, sistem performansını değiştirme sırasına göre kontrol etmek.

Genel olarak, teknik görev, bir proje oluştururken kesişebilecek ve işbirliği yapabilecek birkaç seviyenin gereksinimlerine dayanarak oluşturulabilir.

İş seviyesi- Hangi karmaşık ve öncelikli görevlerin çözüldüğü küresel seviye. Bu seviyeye, iş süreçlerinin entegrasyon, iyileştirilmesi ve modellenmesi, yeni fonksiyonel modüllerin geliştirilmesi ile ilişkilendirilebilir. Kural olarak, ciddi istişareler ve müşteri ile yakın işbirliği ile kaynak yoğun bir gelişmedir. Örneğin, bir seferde Regionsoft CRM'de, bu tür özelleştirilmiş revizyon depo, bilet ofisi ve üretimdi. Yavaş yavaş, değişiklikler serbest bırakıldı ve daha sonra toptan, perakende mağazaları ve hipermarketler için yeni bir ürün oluşturmasına izin verildi - Regionsoft Perakende.

Kullanıcı seviyesi veya kullanıcı grubu.Bu seviyede, mevcut arayüzün revizyonunda görevler uygulanır. Örneğin, kullanıcı bir imleci vurduğunuzda, son siparişin numarası ve durumuyla bir pencere görünmesini isteyebilir veya özel bir veri grubuna sahip özel bir rapor bulunur. Bu seviyede rafineri daha az zamandır işgal eder, ancak birçoğu olabilir - örneğin, pazarlama departmanından, lojistik ve teknik desteğin çeşitli gereksinimleri.

İşlevsellik seviyesi. Önceki kişiden ayırmak genellikle zordur, burada resmi bir kriter çalışması - iyileştirme, arayüzdeki herhangi bir şeyi görüntüleme düzeyinde değil, sistem mantığının iyileştirilmesi düzeyindedir. Bu, çeşitli sıralama, sohbet, telefon yetenekleriyle entegrasyonların gereksinimlerini içerir.

Servis seviyesi - Aslında, bu seviyenin gereksinimleri, düzeltmelerle yeni inşa eden ilke giren ilk olmalıdır. Bunlar, sistem yanıtının hızı için görevlerdir, yüksek yük altında, güvenlik. İdeal versiyonda Venndor bu tür iyileştirmelere sahip olmamalıdır - Kurumsal yazılım yavaşlamamalı, verileri kaybetmemeli, verileri kaybetmemeli, bir seviyenin izinlerini dağıtmak ve dağıtmak için formlar. Ancak gereksinim ortaya çıkıyorsa ve müşterinin kişisel oranı veya donanımın yanındaki sorunları ile ilgili değilse, ona yüksek ilgi göstermeye değer.

Teknoloji seviyesi - Listede sonuncusu, ancak önem ve zorluklar geri kalanın önündedir. Bunlar, platform, işletim sistemi veya cihazlarla ilişkili müşteri gereksinimleri olabilir. Örneğin, MacOS altında bir montaj koleksiyonu. Bu şartlar aşamalı olarak serbest bırakmaya devam ederse, çok havalıdır, ancak mutlaka düzeltmeler vardır. Bu seviyede müşteri isteklerindendir, MacOS altında bir Asoft CRM montajı yaptık ve TRM teknolojisini kullanarak Nadir, ancak mevcut bir mobil versiyon isteğinin geçici bir çözümü olarak TRM teknolojisini kullanarak silinmiş erişim ekledik.

Teknik görevin anatomisi, herhangi bir durumda iskelet biçiminde basittir. Teknik görevin zorunlu kısımları, müşterinin soruna odaklanmasına ve görevi doğru şekilde formüle etmesine ve yükleniciyi formüle etmesine yardımcı olur. Ondan ne istediklerini anlamak için. Bu arada, anlayış hakkında. Tabii ki, gönderinin başında biraz hayatta kaldık, iş danışmanlarını sınıf olarak inkar ediyoruz. Bu şöyle: Her satıcı, pazarda birkaç yıldır çalışır (biz birinci sınıf), aynı zamanda düzinen yıllardır, bu da hemen hemen her endüstride bir dizi vakanın olduğu anlamına gelir. Buna göre, mühendisler, programcılar ve satışlar, her şirkette uygulama özelliklerine aşina. Ama yine de, işinize odaklanmak önemlidir.

Kimin için?Bu bölümde, kimin sonlu bir iyileştirme kullanıcısı olacağını, hangi görevlerin ve hangi sıklığın çözülmesi planlanacağını tanımlamak gerekir.

Bir örnek vereceğim. Aynı şirkette CRM tanıttı, oldukça büyük bir veri dizisi üzerinde (ayda birkaç milyon rekor, günde birkaç yüz bin kayıt) çalıştığı kabul edildi. Satış Dairesi Başkanı, bu kayıtları "günlük" frekansı ile boşaltma hakkında bir rapor talep etti. Doğal olarak, eşzamanlı çalışmaya sahip böyle bir rapor, yüzlerce kullanıcıya yüklenen yüzlerce kullanıcıyı, işlemi optimize ettiği tespit edildi. Zaten iş sırasında, satışların yeniden inşa edildiği ve raporun yalnızca ayın sonuçları ile gerekli olduğu ortaya çıktı ve sonra geceleri bir programda başlatılabilir. Zamanın ve paranın boşuna harcandığını söylemeye değer mi?

Ne için?İş sürecinde iyileştirme ihtiyacının ve yeri gerekçesi. Bu ürün müşterinin kendisi için daha gereklidir, aynı zamanda diğer işlemlerin ne olduğunu bilmek için satıcıya da. Bazen alternatif bir çözüm bulmaya yardımcı olur.

Ne yapmalı?En bilgilendirici blok - sistemden gelen gereksinimleri, beklentilerini açıklar. Ve burada, BASHOMG'ye gelen ve hayattan çok karmaşık olan çok inciler, mucizeler ve çarpışmalar. Çünkü bir - kullanıcı ne yapmak istediğini bilmiyor. Hala küçük bir alt baskı var - kullanıcı gereksinimleri formüle edemez. Ve sonra geliştiricinin görevi (çalışma grubu, analitik, varsa) ihtiyacını doğru ifade etmeye yardımcı olur, uygun bir gereksinimi seçin, görevin bağlamında görevi girin. Aynı blokta, beklenen sonuçtan bahsetmeniz gerekir.

Teknik Görevin Parametreleri- Şartlar, uygulama aşamaları, her taraftan sorumlu, gerekli temaslar vb. Aslında, bu, teknik bir görevle bir belge yapan önemli resmi şeylerin bir birleşimidir. Teknik görev, gelişimin geliştirilmesinde sayısız değişikliği önlemek için taraflarca taraflarca koordine edilmeli ve imzalanmalıdır (hala, daha küçük bir hacimde).

İdeal versiyonda, teknik görev satıcının aktif katılımıyla derlenir ve toplamı yaklaşık olarak böyle bir yapıdır:

1. Her mekanizmanın gereksinimlerinin ve her işlevselliğin açıklaması
2. Bu işlevselliğin uygulanmasının açıklaması
3. Adımların her biri için çalışma maliyeti
4. Bu teknik ödevdeki toplam çalışma maliyeti
5. İşin yürütülmesi, sahnenin aşamalarının dağılımı ve gösterimi ile
6. Kurulum koşullarının ve testlerin açıklaması
7. Teknik görevin ve diğer koşulların ayrıntılı yapısı hakkında rezervasyonlar

Geliştiricinin gözyaşları tarafından yazılan 10 kural

Arıtma için teknik görev, TK'yı iyileştirmelidir., Müşteri için gerekli olan CRM'nin 300 sayfalık bir açıklaması değil. Gereksinimleri çözmeden önce, sistem arayüzünü, yeteneklerini, belgelerinin çoğunu dikkatlice okumalısınız, büyük olasılıkla, "İstek Listesinin" çoğu temel tedariktedir. Dahili arıtma araçlarına dikkat etmeyi tavsiye ederim (rapor tasarımcıları, yapılandırıcılar vb.) - Belki de gerekli değişiklikler düzenli bir programcı yapabilecek (birçok şirkette).

Teknik görev açgözlü olmamalıdır.Genellikle iş, yeteneklerini aşar ya da "hemen her şeyi" almak istiyor. Böyle bir yaklaşım, para açısından veya iş açısından haklı değildir. Satıcı, bir kural olarak, birkaç hafta yok (Regionsoft - 15 yaşında) yoktur ve ona başvurabilirsiniz ve bir süre sonra CRM'nin ne eksik olduğunu gerçekten anlayabilirsiniz.

Parlak bir yedeklilik örneği, tam anlamıyla dünden: Müşteri, ünlü bir Rus şirketinin ERP'sini satın aldı, muhasebe muhasebesinin, bu satıcının ERP'nin iyi olacağını düşünüyor. ERP kendi içinde çok değil, ama çok uygun bir iş olmadığı ortaya çıktı. Ancak depo muhasebesi ve üretimi olan Regionsoft CRM uygundur. Bir çözüm var: ERP'yi unutmak, ağlamak, 1C muhasebeyi yeni bir CRM ile entegre eder ve uygun bir uygulamada sevinir. Ancak taramasız para bir acıma! Ve müşteri, CRM'nin ERP ile entegrasyonunu gerektirir. Bunu yapmadık, ama neden böyle bir atık, neden iki nispeten benzer bir sistem?

Teknik görev gerçekçi ve yerine getirilmelidir - Her ikisi de gereksinimlere ve zamana göre. Bir veya başka bir göreve gittiğini tam olarak ne zaman geçtiğini bildiği için satıcının görüşünü dinlemek önemlidir. İnan bana, geliştirici zamanı çekmek ve terimi rüzgarlamak için karlı değil - bunun mümkün olduğu kadar çok projeyi tamamlaması ve bir üne bir darbe almamak için iyi yapması için karlı. Gerçekçiliğe gelince, CRM'yi basitçe çarpıcı yönetim sisteminin seviyesine bitirmek için taleplerden kaçının: şu anda ve öngörülebilir gelecekte neyin gerekli olanların gereklerine dahil edilmelidir.

Örneğin, Regionsoft CRM bir masaüstü programıdır, bir tarayıcı için bir istemcimiz yok. Bir şirket için bir web uygulaması oluşturmamızı istemek anlamsız, bu büyük bir gelişmedir, şimdi yapılmakta ve bir şirketin iyileştirilmesi mümkün değildir. Hayır, elbette, her şeyin fiyatı vardır, ancak tekrar - genel olarak, gereklilik zarar görmüştür.

Özel yapımsal gelişme söz konusu olduğunda durumla karıştırılmaya gerek yoktur ve uygulamanın fikri ve mantığı kökte, "kendiniz için" yeni bir yazılımın oluşturulması neredeyse yeni bir yazılımın oluşturulmasıdır. Ama bu başka bir hikaye.

Teknik görev ayrıntılı olmalıdır. Gelecekteki projenin tüm önemli ayrıntılarını belirlemeniz gerekir: Programı arayüzdeki isteklere kullanma sıklığından. Gereksinimler ne kadar çok belirlenirse, daha kolay ve daha hızlı uygulanacak ve test edilecektir. Özellikle belirli bir endüstride çalışıyorsanız (tıp, sigorta, bankalar) - iş etkileşimi nüanslarının ayrıntılı bir ifadesi ve programın satıcının görevini ve hızlı uyarlamanın anlaşılmasını sağlayacak olan ayrıntılara dikkat etmeye değerdir. sistemin şirketinize.

Sayıların formatlarına, alanların adlarına, açılır listelerin varlığı veya yokluğu, düğmelerin ve ipuçlarının davranışını, veri türlerine dikkat edin. Müşteri, CRM çalışmalarının mantığına atılması gereken kendi formüllerini kullanıyorsa ( Örneğin, bayilik bonuslarının hesaplanması) Bu formüller, tanımlarının tam kod çözülmesi ve hesaplama mantığı ile yazılmalıdır.

Evet, kurumsal yazılım böyle görünüyor ve içinde birçok önemli önemseme var.

Teknik görev açık ve doğru olmalıdır. Bulanıklık ifadeleri, uygulama seçenekleri, bulanık gereksinimler - ölü bir sonda tüm bu şekilde. İyi niyetlerden bir müşterinin sistemin davranışları için birkaç seçenek yazması, yakın, ancak TP'ye eşdeğer olmamasıdır. Bu durumda, size yardımcı olduğundan, programcıya söyler, ancak aslında, Cehennem'e giden yolun iyi niyetinin, geliştiricinin tam olarak ne gereksinimlerini anlamalıdır ve bunun nasıl yapılacağını, kendi özelliklerine dayanarak kendisini seçecektir. Sistem ve kullanılan teknolojilerin yığını.

Bu yıl tekrar bir arzu verebilirsin. Yalnızca, lütfen, anlaşılabilir iş gereksinimleri gibi, bile yerine getiremeyeceğim gerçeğini boşa harcamayın!

Teknik görev insan dilinde yazılmalıdır. Ve bu önemli, hayır, önemlidir. Dil ile ilgili sorunların projenin uygulanmasını sıkılmasına yol açtığında iki durumu tahsis edeceğim.

1. Müşteri, teknik okuryazarlığını göstermeye çalışıyor ve türün türünü göstermeye çalışıyor: "Bir olayı çağrı yapma olasılığı ile takvimin gövdesine sahip bir pencereye sahip bir pencere uygulamak ..." yerine, "takvimde Görevi yaptığınız şekilde işaretleyebileceğiniz bir pencere açın. " Siz veya iç uzmanınız teknik metinler yazma becerisine sahip değilse, Google - Normal kelimeler olarak yazmayın, onları anlıyoruz.

   Teknik görev düzaretçi bir kitap olmamalıdır. Sorunu çözmek, tarif etmemek, yazı tiplerine dikkat etmek ve gereksinimlerin açıklamasını unutmak gerekir. TK, sadece sorunun kendisini değil, aynı zamanda anlama düzeyinde de çözümü içermelidir - geliştirici zaten kod seviyesinde karar verir. Karşılaştırmak "Satış departmanı kötü planlıyor, rakamları kaybetti, zaten bir yıl boyunca savaşıyor" ve "Planın değerlerini ve aylık satış gerçeğini, isimlendirmenin grupları bağlamında tutacak bir rapor oluşturmanız gerekir".

   Teknik görev geleceğe bakabilmelidir.Pekala, değil, ama onun arkasında duran insanlar. İş süreçlerinde değişikliklerin yapıldığı biliniyorsa, revizyon için iki kez ödeme yapmamak için dikkate almak gerekir.

   Teknik görev bürokratik olmamalıdır. En az bir kez bu belgeyi oluşturursanız, muhtemelen bürokrasiye girme, iç kelimelere kaymak, sıkı devrimler ve her bir maddeyi ceza kanununun bir makalesi olarak tanımlamak için muhtemelen ihlal için herkes). Bürokratik formülasyonlar, TK oluşturma hedeflerinin eksik bir şekilde anlaşılmasını sağlar. Satıcının sorumluluğu sözleşmeye kayıtlıdır, bütçe oraya yazılır. Bu noktaları teknik görevde taşımayın.

   Teknik görev bir teknik görev olmalıdır. Paradoksal geliyor, ancak genellikle TK yerine, CRM veya toplantının dakikaları için harfleri, şikayetleri, sözleşmeleri, yeniden yazılı talimatları okuduk. Tabii ki, böyle bir belge için çalışmak imkansızdır. Form ve içerikten uzaklaşmamak için, eski okul numarasını kullanın: Dönemi göre düşünün. Teknik - Arıtma'nın dikte olduğu anlamına gelir, tekniğin yazılımı değiştirerek sorunu çözmeyi amaçlar. Bu, yazılım bağlamındaki görevdir ve konuşmanız gerekir. Görev, sorunun, ipuçları, ipuçları ve ön tahminler olmadan sorunların, sorunların olduğu anlamına gelir. Sadece ifadeler.

   Emirler sona erdi, şimdi ödül

   Listelenen kurallara ek olarak, söylemeye değer birçoğu daha var. Hedefler, planlar ve beklentilerden bahsediyoruz - projeyi başarılı kılan, ve satıcının ve müşterinin ilişkisi neredeyse güler yüzlüdür.

   Hızlı bir şekilde yazmanız gereken teknik görevHücresel bir operatörün veya büyük bir hipermarketin işlemini otomatikleştirme görevine sahip olsanız bile. Bunun nedeni, teknolojilerin büyük bir hızda gelişmesi ve hatta uygulandığınız sistem bile, altı ay boyunca bir yıl boyunca büyük bir sürüm (ve bazen iki) hayatta kalabilir, yeni işlevsellik kazandırabilir. Belki de işlemi tekrar geliştirip başlatma ihtiyacını tekrar gözden geçirmelisiniz.

   

   
   Sonunda, TK'yi tamamlamak için zaman buldu. Fakat ne yazık ki, orada onu uygulamak için geliştirici yok.

   Müşteri yığın ve teknik sınırlamaları bilmiyor.Ve bilmemelisin - bu, satıcının görevidir, teknik bir iş çıkardıktan sonra çalışmayı değerlendiren kişidir. Müşteri teknolojide derinleşmemeli ve satıcı bir veya başka bir şeyi yapabilirse, her virgül sormamalıdır. Kapsamlı bir TK yapın ve geliştirici uygun bir mimari seçecektir - genellikle düşündüğünüzden daha iyidir.

   Bütçeyi değerlendirin ve tatsız sürprizlerden kaçının - neredeyse bir ortak görev numarası. Satıcıyı ve talebini, çalışmanın yaklaşık bir değerlendirmesini (iyi, en az yaklaşık olarak boşluk, gözlerde ve diğerleri gibi, bu tür projelerde ve deneyimlerle, iyi, hatanın sınırları). Tamamen bir bütçe değerlendirmesi, yalnızca teknik görevin okuması, analiz edilmesinden ve son onaylanmasından sonra mümkündür. Geliştiriciniz aksi halde gelirse - iyileştirmenin en az iki kat daha pahalı olması nedeniyle hazır olun.

   Değişiklik ve uzantılar için nesnel ihtiyaçtan devam edin - Geliştiricinin yok olmadığını ve gereksinimlerinize herhangi bir zamanda değişiklikler ve ilaveler yapmaya hazır olduğunu yazdım. Bu nedenle, derhal CRM / ERP hayallerini oluşturmaya çalışmayın, "her şey kahve içmeye kadar çalışır" - sistemde çalışın, sistemde çalışın, sizin için kritik yorumları belirleyin ve gereksinimlerin toplanmasına ve TK'nin derlemesine devam edin .

   Teknik görevler hakkında sonsuz bir şekilde yazabiliriz, bu sadece memler ve Beacks değil, aynı zamanda baş ağrısı da gerçek bir jeneratördür. TZ İnsani Hakkında Kayıt için öncelik ve kurallar hakkında konuşabilirsiniz, bu da TZ İnsanları, IEEE Standartları Hakkında, Prototipler ve Tamamlayıcı TK hakkında biraz daha iyidir. Ama sonunda kendimizi bir taneye, en önemli kuralla sınırlamak istiyorum: Teknik görev, GOST ve DOGMA'yı değil, DOGMA'yı olmayan, bu nedenle, iyileştirebiliyorsanız, basitleştirebilirseniz, siz basitleştirebilirsiniz. zarif bir şekilde yapabilir ve mümkün kılmak için. Eminim, bundan sonra hiç kimse burnu TK'de zorlamaz ve orada yazılmadığını söylemeyeceğim. Ya da neredeyse hiç kimse yok.

   Tüm Aralık, Regionsoft CRM'de ve kendi gelişimimizin tüm yazılımlarında indirimler veriyoruz. 1 ila 15 Aralık -% 15 ve taksit ve kiralama koşulları. % -70 ve -90'a sahip değiliz, çünkü ekonomik olarak makul fiyatı lisanslar için tutuyoruz ve tavandan almıyoruz.

   Peki, bir CRM sistemine ihtiyacınız varsa (arıtma veya olmadan), sonra hadi web sitemiz CRM, avantajları ve diğer kurumsal yazılım hakkında çok şey var.

   Ve evet, biz her zaman CRM ve diğer ürünleri satmaya, CRM'yi iyileştirmeye ve satmaya hazır olan ortakları arıyoruz, yazılımı satmak ve kullanıcılara öğretiyoruz. Gelir bölünmesi dürüst ve karlı bir ortaktır. Göstereceğiz, söyle bana, öğret. Üzerine yaz [E-posta Korumalı]

   Slaytlar, slaytlar. Http://www.modernanalyst.com/'den ve Pinterest'ten alınan çizgi romanlar. Daha iyi bir çeviri varsa - postada yapmak için mutlu olacağız.

1C'nin sonlandırılması için teknik görevin ne kadar doğru bir şekilde sonuçlanması, geliştiricilerden önce belirlenen görevlerin çözülüp çözülmeyeceği ölçüde bağlıdır. Aynı zamanda, böyle bir belgeyle çalışırken bazı zorluklar vardır. TK'nin geniş bir anlayışında, bir otomatik sistem (AC) ve iş emri oluştururken ve yükseltilirken normlar öngörülmektedir. Bu aynı zamanda bir dizi Proje Başlatma Standartları içerir. Teknik görevin rolünün bu anlayışı, TK'ün gelişiminin geliştirildiğine göre, 19.201-78 ve 34.602-89 olan GOST gereklilikleri ile belirlenir. Bu belgenin değerinin başka bir yorumu var, uygulamaya daha yakın.

Başka bir tanıma göre, 1C'yi tamamlamak için teknik görev, gelecekteki sistemin amacını ve parametrelerini ve ayrıca belgeleri ve listesini geliştirme sürecini düzenleyen bir belgedir. Böyle bir yorumlama programcıların ve müşterinin çıkarlarını dikkate almamızı sağlar.

Tk ne olmalı?

Programın geliştirilmesi için herhangi bir teknik görev, Yüklenici tarafından oluşturulur. Ancak bu bir programcı yapmaz, bir analist. Bu önemli bir nokta, çünkü belge dilde yapılması gerektiğinden, müşteri için oldukça özel teknik terimler olmadan anlaşılır. Tüm proje nüansları dikkate alındığında ve bilgi doğru şekilde tanımlandığında, TK tüm müşterilerle koordine edilir. Kabul edilmesi durumunda, programcılar bağlanır. Aynı zamanda, istenen sonuç belgede açıkça belirtilmelidir. Geliştiricilerin hedefi doğru bir şekilde koymasına ve farklı aşamalarda kontrol etmenize yardımcı olur. Ayrıca, 1C'nin tamamlanmasında teknik görevin hazırlanmasında da çok dikkat, formülasyonları ödemeye değer. Yeterince spesifik olacak ve başka yorumlamalar yapmadıkları için izlenmelidir. TK ile çalışırken hatırlamanız gereken ilk şey budur. Tasarıma yaklaşmak da gereklidir. Bu, belgenin başlık sayfası için geçerlidir.

1C'nin gelişimi için teknik görevdeki ana hatalar

Dava piyasasının yapısı GOST 34.602-89 ile düzenlenir. Bu belge, TK'deki bilgi bloklarının sayısı ve sırası için net gereksinimleri içerir. Aynı zamanda, sunum yöntemleri için katı standartlar yoktur. Bu durum, karmaşık görevleri çözmek için büyük bir potansiyele sahiptir ve aynı zamanda belgenin hazırlanmasında birçok hatayı içerebilir. En sık aşağıdaki yanlışlıklardır:

1. Bazı bölümlerin farklı yorumlarda tekrarlanması.
2. Bilgi rastgele tabidir. İdeal olarak, iş süreçleri veya sistem modülleri gibi belirli bir yapıya atıfta bulunmalıdır.
3. Farklı bölümlerdeki bilgiler farklı derecelerde ayrıntılı olarak servis edilir.

Tüm bunlar, TK'de belirtilen müşterinin bilgilerinin anlaşılmasını önler. Bu, işbirliği sürecini daha fazla zaman alıcı hale getirir.

Müşteriyi izledikten sonra, 1C'nin sonlandırılmasına ilişkin TK numunesi değişebilir ve her zaman daha iyi değildir. Bu sırayla, genellikle programcıların bilgileri doğru algılamasını önler. Bu, özellikle küçük deneyime sahip uzmanlar için geçerlidir. Bu aşamada, aşağıdaki hatalar sıklıkla ortaya çıkar:

1. Farklı bölümlerin gereksinimleri birbirlerine çelişir.
2. Formülasyonlar yanlış.
3. Yer bilgileri gereksiz ayrıntılı.

Bütün listelenen hatalardan kurtulun. Her şeyden önce, sonuçta, dikkatlice ifade edilmemesi için gezinmek gerekir. TK'nin proje işlevselliğini, ana parametrelerini ve amacını açıkladığını hatırlamaya değer.

TK geliştirmedeki hatalar nasıl önlenir?

Sonraki tüm öneriler için geçerli olan ana kural, formülasyonun spesifik olmasıdır. Bunu yapmak için, GOST, diğer düzenleyici belgelere bağlantılar kullanmanız gerekir. Bu, yüklenicinin ve müşterinin bilgileri bir şekilde algılamasını sağlar.

1C'yi iyileştirmek için teknik bir görevin bir örneği, projenin yapıldığı sektörün dilinin kullanımını ifade eder. Her şeyden önce müşteri için gereklidir. Aynı zamanda, metinde, farklı şekillerde yorumlanabildikleri için herhangi bir karşılaştırma kullanmaya değer değildir.

Bir raporun geliştirilmesine ve diğer unsurların 1C'nin geliştirilmesine teknik bir atama yapımında ana kurallar:

1. TK, müteahhit ve müşteri tarafından ortaklaşa oluşturulur.
2. Programcıların çalışmasına sadece nesnel gereksinimler yerleştirilmelidir. Projenin başarılı gelişimi için, müşterinin öznel vizyonu en aza indirilmelidir.
3. Sonucu müşterinin ihtiyaç duyduğu ayrıntılı olarak tanımlamanız gerekir. Aynı zamanda, 1C yapılandırmasının geliştirilmesi için teknik bir görev örneğinde, öğenin çalışması gereken tüm parametreleri reçete etmelisiniz. Aksi takdirde, sonuç istenenden büyük ölçüde farklılık gösterebilir.
4. Sanatçının ve müşterinin riskleri yaklaşık olarak eşit ve en aza indirilmelidir.
5. İşletme iletişiminde kullanılan ve belirli bir endüstride uygulanmayan terimleri kullanmak imkansızdır.

1C veya başka bir öğede bir raporun geliştirilmesinde bir TK oluşturmak için, analist müşterinin faaliyetlerinin tüm özelliklerini bilmelidir. Gereksinimler içinde, müteahhit için yararlı olan sadece faydalı bilgiler vermeniz gerekir. Buradaki son görevlere özel dikkat gösterileceği göz önüne alındığında, yazılımı çözmeli, teknik görevin tek tip örneği yoktur.

TK'nin yanlış derlenmesi tehlikesi

Yukarıda listelenen hatalar, sistemin oluşturulmasına harcanan zamanda bir artışa yol açabilir. Ekstra giderler ve hoşnutsuzluk gerektirir. Veritabanı geliştirme veya diğer konfigürasyon 1c için teknik görev deneyimli uzmanlar olmalıdır. Bu belgenin anlayış için ne kadar mevcut olduğundan, tüm katılımcıların yararına bağlıdır. Müşteri, iş görevlerini çözmek için etkili bir otomatik sistem alır. Aynı zamanda, yüklenici başka bir memnun müşteridir. İşletme sahiplerinin, 1C ortak şirketlerinin seçimine mümkün olduğunca yakın olmaları gerekir, çünkü kuruluşun etkinliği, kuruluşun etkinliğinin ne kadar nitelikli olduğuna bağlıdır.