Görev tanımının bileşimi ve içeriği. Kendiniz teknik bir görev nasıl yazılır?

Antitröst yasalarını ihlal etmeden ihtiyacınız olanı nasıl satın alabilirsiniz? Bu işte başarının anahtarı, iyi yazılmış bir teknik görevdir. Makalede, müşteriler tarafından hangi örtülü ihlallerin işlendiğini okuyun.

Genel durumda, bir satın alma şartnamesi hazırlarken, müşteri açıklanan nesnenin tamamen kişiliksizliğini izlemelidir, yani herhangi bir gereklilik içermemeli ve hatta belirli ticari markalar, üreticiler ve hatta menşe ülke hakkında ipuçları içermemelidir. mal.

Aslında, belirli bir alanda özel bilgi olmadan, tedarik nesnesinin bir tanımını, 44-FZ için görev tanımını doğru bir şekilde hazırlamak oldukça zordur. Hatta bazı müşteriler, görev tanımının hazırlanması için hizmetlerin sağlanması için bir satın alma oluşturur. Ancak, satın alma nesnelerinin gereksinimlerini dikkatlice incelerseniz, bunları kendi ihtiyaçlarınızla karşılaştırırsanız ve 44-FZ'ye göre satın alma nesnesini tanımlama kurallarına sıkı sıkıya uyarsanız, bunu kendi başınıza yapmak da oldukça gerçekçidir.

Ürünlerin etiketlenmesinde bazı özelliklerin şifrelendiği unutulmamalıdır. Örneğin, iş tanımı "Klasik 1KO.4" olarak işaretlenmiş "kaldırım levhaları" malzemesini sağlar, iş tanımı karonun kalınlığı için herhangi bir gereklilik belirlemez. İşaretin kod çözümüne göre kalınlığı 4 cm'dir (işaretin son rakamı cm cinsinden kalınlığı gösterir). Ancak temasın uygulanması sırasında 6 cm kalınlığında bir karo gerektiği ortaya çıktı, dayanabileceği yük karonun kalınlığına bağlıdır. Okuma yazma bilmeden hazırlanmış görev tanımı, gerekli gereksinimleri karşılamayan malzemelerin satın alınmasına yol açtı. Bu nedenle, referans açısından tüm malzemelerin etiketlerini dikkatlice kontrol etmek ve malzemeler için tüm temel, önemli gereklilikleri belirtmek gerekir.

Arzu edilen farklı sitelerden ürün açıklamalarını kopyalamayın. Açıklamadaki bilgiler güvenilir olmayabilir ve hiçbir ürünün belirtilen gereksinimleri karşılamadığı ortaya çıkar. Bu tanıma uyan tek bir ürünün olma ihtimali yüksektir. Bu, rekabetin kısıtlanması olarak değerlendirilebilir.

Tüm performans gereklilikleri belirsiz olmamalıdır. Aksi takdirde, açıklama için çok fazla talep olacaktır. Çoğu zaman, çok sayıda talep olduğunda, müşterinin bunlara zamanında yanıt vermek için zamanı olmayabilir ve referans şartlarını ayarlamak için zaman olmayabilir. Buna dayanarak, bazen açıklamadaki müşteri, materyalleri belirtmeden yalnızca onay vermenin yeterli olduğunu belirtir. Buna karşılık, işin yürütülmesinde hangi malzemelerin kullanılacağı uygulamadan net olmadığı için tam olarak ihtiyaç duyulanı satın alma şansını azaltır.

Teknik özellikler için gereklilikleri açıkladıktan sonra bir uygulama hazırlamak için talimatlar yazmak daha iyidir. Talimat, katılımcının kafasını karıştırmamalı, ancak katılımcılardan gelen birçok talebi önlemek için görev tanımının gerekliliklerini belirtmelidir. Başvurunun hazırlanmasına engel oluşturan görev tanımının talimatlarla tutarsızlığı, potansiyel ihale katılımcıları tarafından OFAS'a şikayet sunulmasına neden olabilir.

Referans şartlarında belirtmek için başka hangi gereklilikler önemlidir:

• Malların, işlerin, hizmetlerin garanti süresi ve (veya) kalite garantilerinin kapsamı. İş tanımındaki müşteri, üreticinin garanti süresinden daha az olmayan bir garanti süresi belirlemelidir.
• Malların garanti hizmetine.
• Ürünü çalıştırma maliyetine.
• Malların zorunlu montajı ve devreye alınması.
• Malların kullanımı ve bakımı ile ilgili kişilerin eğitimine.

Ana kurallar

1. Tedarik belgelerini hazırlarken, tedarik konusuyla ilgili Tüm Rusya Ürün Sınıflandırıcısının (OKPD2) kodlarına dikkat edin. Kullanılan kodun belirli tedarik nesnesiyle eşleşmesi gerekir.
2. 44-FZ hükümlerine ek olarak, görev tanımlarını geliştirirken, diğer yasal düzenlemelerin, tekel karşıtı makamların, teknik normların ve standartların (GOST, TU, SNiP, vb.) Gereksinimleri de akılda tutulmalıdır.
3. Müşteri tarafından referans şartlarında talep edilen mallar ve malzemeler, satın alma nesnesine ve (varsa) tahmini belgelere karşılık gelmelidir.
4. Bir inşaat sözleşmesi için satın alırken, kusurlu bir beyan, bir tahmin ve sermaye inşaatı durumunda (yeniden yapılanma, revizyon) proje belgelerinin de eklenmesi gerekir.
5. Yeni mal ve malzemeler satın almak istediğinizi belirtin (yani kullanılmamış, tamir edilmemiş, restore edilmemiş, restore edilmemiş). Aksi takdirde, müşteri kullanılmış mal alabilir.

Yaygın sorular

Soru: Yedek parça tedariği için "orijinal" ibaresi yazılabilir mi?
Cevap: Garanti kapsamındaki bir üründen bahsediyorsak veya bu tür malların müşteri tarafından kullanılan mallarla etkileşimini sağlamaya ihtiyaç duyulursa ve ayrıca makine yedek parça ve sarf malzemelerinin satın alınması durumunda mümkündür. ve ekipman.

Soru: Görev tanımında ihale kimlik kodunun belirtilmesi zorunlu mu?
Cevap: Tedarik tanımlama kodu, satın alma planında, programında, satın alma bildiriminde, kapalı bir yöntemle yürütülen tedarikçinin (yüklenici, yüklenici) belirlenmesine katılma davetinde, satın alma belgelerinde, sözleşmede ve diğerlerinde belirtilir. bu Federal Yasa tarafından sağlanan belgeler . İş Tanımı'nda belirtilmesi gerekli değildir.

Soru: Bir üreticiden 3 cihazlık mevcut sisteme bilimsel araştırma için bir cihaz satın alınması gerekmektedir. İşteki her şeyi tamamen birleştirmek gerekiyor. Bir eşdeğer arzu edilmez. Eşdeğerini yazıp üreticiyi belirtemez miyim? Sistem son derece özelleştirilebilir ve pahalıdır.
Cevap: Durumunuz "... diğer ticari markaların yerleştirildiği malların uyumsuzluğu ve bu tür malların müşteri tarafından kullanılan mallarla etkileşimini sağlama ihtiyacı durumları hariç ...)" kapsamına giriyorsa - diğer durumlarda yapabilirsiniz - yapamazsın.

Soru: Revizyon için referans açısından dar göstergeler belirtmek mümkün mü, örneğin, belirli bir renk şemasına sahip duvarların rengi, tavana bir alçıpan bileşimi örneği, eşdeğeri olmayan belirli bir karo koleksiyonu ekleyin, estetik tercihlerden mi bahsediyorsunuz?
Cevap: Görev tanımlarını oluştururken, müşterilere 44-FZ sayılı Kanun'un 33. Maddesinin gereklilikleri rehberlik etmelidir. Duvarların rengi müşterinin seçimidir, bu onun ihtiyacıdır, tedarikçi sayısını sınırlamaz. Tavanda bir alçıpan bileşiminin düzeni, taslağı da müşterinin ihtiyacıdır, tüm sanatçılar belgelerde verilen düzeni tekrarlayabilecektir. Eşdeğeri olmayan bir karo koleksiyonu, 44-FZ sayılı Kanunun 33. tedariki sözleşme konusu olmayan malları kullanmak. Aynı zamanda, bir ön koşul, satın alma nesnesinin tanımına "veya eşdeğeri" kelimelerinin dahil edilmesidir.

Görev tanımı hem yüklenici hem de müşteri için önemlidir. Yüklenicinin müşterinin ne istediğini daha iyi anlamasına, müşterinin ani "isteklerine" karşı sigorta yapmasına, görev üzerindeki çalışmayı hızlandırmasına yardımcı olur. Müşteriye - tam olarak ne istediğini söylemek, kalite kontrolünü basitleştirmek, hizmetin tam maliyetini almak. Size bir görev tanımını nasıl doğru bir şekilde hazırlayacağınızı ve bununla ne yapacağınızı daha sonra anlatacağız.

teknik görev nedir

Referans Şartları - gelecekteki bir ürün için tüm gereksinimleri yansıtan bir belge. Tüm teknik gereksinimleri açıklar. TK genellikle bir metin belgesi biçiminde derlenir, nadiren başka biçimlerde derlenir.

TK, tüm web sitesi geliştiricileri tarafından kullanılır. Dizgiciler, programcılar, tasarımcılar için müşterinin gereksinimlerini daha iyi anlamaya ve beklentilerini karşılayan bir kaynak oluşturmaya yardımcı olur. Ek olarak, TK diğer tüm alanlarda kullanılır, örneğin - içinde:

• uygulama geliştirme;
• ev tasarımı;
• metinler ve diğerleri yazmak.

Görev tanımına göre çalışırsanız, anlaşmazlık ve uzayan dava riski en aza indirilir.

Teknik bir görev nasıl hazırlanır: sitenin teknik özelliklerinin yapısı

İşe başlamadan önce:

• Referans şartlarını kimin yazacağına karar verin
• Terimleri açıklayın
• Sübjektif terimlerden kaçının

İlk bakışta sitenin teknik şartnamesinin müşteri tarafından yapılması gerektiği görülüyor., çünkü bir kaynak sipariş ediyor ve ondan taleplerde bulunuyor. Aslında, her ikisi de sürece katılmalıdır: müşteri gereksinimleri dile getirir ve icracı bunları özel, doğru ve net bir şekilde yazar. Örneğin, müşteri, tüm kullanıcılara uyarlanmış bir site istediğini söylüyor ve geliştirici, kullanılabilir 4 boyut için uyarlanabilirlik gereksinimleri öngörüyor - PC'ler, dizüstü bilgisayarlar, tabletler, akıllı telefonlar.

Terimlerin tanımı çok önemlidir. Tüm son derece özel terimlerin en başta açıklanması tavsiye edilir - müşteriler her zaman bir bodrumun (altbilgi), CMS'nin, balığın ne olduğunu bilmezler. Açıklamalar ne kadar basit ve net olursa Görev Tanımı her iki taraf için de o kadar net olacaktır.

Sübjektif terimler gereksiz tartışmalara neden olabilir. "Tasarım güzel olmalı" yazmayın - güzellik kavramı herkes için farklıdır. Aynı durum “uygun”, “kullanımı kolay”, “büyük” kalite sıfatları için de geçerlidir. Belirli sayılar ve parametreler kullanın: örneğin, renk düzenini veya öğelerin düzenini tanımlayın.

Teknik görevin yapısı herhangi biri olabilir. Örnek olarak, site için basit bir TOR yapısı sunuyoruz.

siteyi tanımla

Bize ne tür bir siteye ihtiyacınız olduğunu, onu kimin kullanacağını, ne için oluşturulduğunu söyleyin. Örneğin, bir çevrimiçi mağazaya, bir ürün satmak için bir açılış sayfasına veya 10 sayfalık bir kartvizit sitesine ihtiyacınız olduğunu yazın. Tam sayıyı bilmiyorsanız, yaklaşık sayfa sayısını belirtiniz.

Projenin belirli bir hedef kitlesi varsa, onu açıklayın. Bu, müşterilere hitap edecek bir kaynak yaratılmasına yardımcı olacaktır - örneğin, gençlere veya yaşlılara hitap eden makalelerde veya tasarımda uygun dili kullanmak.

Bana yapısından bahset

Yapıyı anlamadan normal bir site geliştirmek imkansızdır. Sitede hangi sayfaların olacağını açıklayın ve iç içe geçme düzeylerini gösterin. Bunu farklı şekillerde yapabilirsiniz:

• plan
• masa
• liste

Asıl mesele, sonunda menüde hangi sayfaların yer alacağı, nereye gidecekleri, her bölümün hangi ana sayfaya sahip olacağı bellidir. Akış şemalarını kullanmanızı öneririz - listelerden ve tablolardan daha basit ve okunması daha kolaydır, sitenin tüm yapısını birkaç saniye içinde değerlendirmeye yardımcı olurlar.

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

Bize sitenin sayfalarını nasıl gördüğünüzü söyleyin. Her bir elemanın yerini açıkça göstermek için bunun bir prototip formatında yapılması arzu edilir. Gereksinimleri bir liste ile de tanımlayabilirsiniz, örneğin sitenin başlığında ne olacağını, geri bildirim formunun nerede olduğunu, boş taraftaki sütunda ne olacağını söyleyin.

Sitenin tüm sayfaları yaklaşık olarak benzerse - örneğin, bir kartvizit sitesi oluşturmayı planlıyorsanız, iki prototiple idare edebilirsiniz: ana sayfa ve diğer bölümler için. Birkaç benzer sayfa grubu varsa - örneğin, bir çevrimiçi mağazanın kataloğundaki bölümler, makaleler içeren bir blog ve teslimat / montaj / kurulum hizmetlerinin açıklaması, her grup için kendi prototipinizi oluşturmak daha iyidir.

Tasarım taleplerinde bulunun

Geliştirilmiş bir düzen varsa, harika - bunu sadece görev tanımına ekleyebilirsiniz. Değilse, renkler, kullanılan görseller, logolar için gereklilikleri açıklamanız gerekir. Örneğin:

• Tasarımda hangi kurumsal renklerin kullanılabileceğini, hangi gölgelerin kesinlikle kullanılmayacağını belirleyin.
• Sitenin başlığında bulunması gereken bir logo sağlayın
• Sayfaların, menülerin, altbilgilerin, içeriğin tasarımı için kullanmak istediğiniz yazı tiplerini belirtin.

Açık gereksinimler yoksa - yani, müşterinin kendisi site vizyonunu formüle edemezse, ona aralarından seçim yapması veya bireysel bir düzen geliştirmesi için birkaç standart düzen sunabilir ve ardından üzerinde anlaşabilirsiniz. Bu, İş Tanımı onayından önce yapılmalıdır, aksi takdirde zevklerdeki farklılık projeyi önemli ölçüde geciktirebilir.

Araçlar, kod, barındırma, etki alanı için gereksinimleri açıklayın

Bu, hangi araçlarla çalışabileceğinizi ve hangileriyle çalışamayacağınızı önceden bilmek için gereklidir. Ayrı bir blokta açıklayın:

• Hangi sitede olmalı - WordPress, Joomla, Modex vb.
• Hangi programlama dili kullanılabilir - PHP, JavaScript, HTML, diğerleri
• Sitenin hangi hosting üzerinde ve hangi domain zone'da bulunması gerektiği, hangi domain adı kullanılabilir?
• Hangi yazılım platformu kullanılabilir - .NET, OpenGL, DirectX
• Ve benzeri

Müşteri kullanılan terimlerden hiçbir şey anlamıyorsa, WordPress'in Modex'ten, PHP'nin HTML'den, .ru bölgesindeki bir alandan .com bölgesindeki bir alandan nasıl farklı olduğunu açıklayın. Birlikte, gereksinimleri müşteriye uyacak şekilde belirleyin.

Site gereksinimlerini belirtin

Varsayılan olarak, site tüm cihazların kullanıcıları için farklı tarayıcılarda çalışmalı, bilgisayar korsanlarının saldırılarına karşı dayanıklı olmalı ve aynı anda 1000 kullanıcı ziyaret ettiğinde ayakta kalmalıdır. Ancak ayrı bir blokta yazmak daha iyidir. Belirtin:

• Sizin için kabul edilebilir site yükleme hızı veya standart bir değer - 1–5 saniye
• Tarayıcılar arası uyumluluk - sitenin hangi tarayıcılarda açılması gerektiğini açıklayın
• Duyarlılık - tasarımın uyması gereken ekran boyutlarını ve kullanılan cihazları belirtin
• Yük direnci - "uzanmaması" için sitede aynı anda kaç kişinin olması gerekir
• Bilgisayar korsanı ve dDos saldırılarına karşı dayanıklılık: site küçük saldırılara dayanmalıdır

Site için senaryolar yazın

Kullanıcının siteyle nasıl etkileşime girmesi gerektiğini ve yanıt olarak kaynakta hangi eylemlerin gerçekleşmesi gerektiğini açıklayın. Kullanıcıların eylemler arasında seçim yapması durumunda bu, basit bir numaralı liste veya dallanmış bir algoritma şeklinde yapılabilir. Çok sayıda etkileşimli hizmet varsa, her biri için bir komut dosyası yazın.

İçeriği kimin yaptığını öğrenin.

Bazı geliştiriciler metinleri kendileri yazar, biri bunları metin yazarlarından sipariş eder, biri balık kullanır. İçeriğin sağlanmasının geliştirme hizmetine dahil olup olmadığını hemen netleştirin. Öyleyse, örneğin aşağıdakiler için hemen ek gereksinimler belirleyebilirsiniz:

• - Advego, Text.ru, Content.Watch'a göre en az %95
• Mide bulantısı (spam) - Advego'ya göre %10'dan veya Text.ru'ya göre %65'ten fazla değil
• Glavred için puanlar - en az 6,5 veya 7 puan

Elbette, farklı hizmetler her derde deva değildir, ancak "sulu" veya spam olma riskini en aza indirirler. Ek olarak, metinlerin kalitesini değerlendirmek için bu kadar doğru kriterler ortaya çıkıyor.

Terimleri belirtin

Bu genellikle unutulur. Görev tanımının çoğu terimleri belirtmelidir, aksi takdirde geliştirme birkaç ay, altı ay, yıl sürebilir. Yanlış ifadeler kullanmayın - örneğin, "bir ay içinde". Tam tarihi yazın: örneğin 1 Aralık 2018.

Hayat kesmek: görev tanımının işbirliği anlaşmasına ek olarak hazırlanması daha iyidir. Böylece sitenin geliştirilmesi için tüm gereklilikleri yerine getirirsiniz ve anlaşmazlık durumunda mahkemede davayı kazanabilirsiniz.

Unutmayın: her TK'de birkaç ana blok bulunmalıdır:

• Amaçlar ve hedefler - genel olarak TK'yı neden oluşturduğunuz, ürünle ne yapmak istediğiniz hakkında
• Ürün ne olmalı - genel terimlerle bir açıklama
• Teknik gereksinimler - evin alanı, metin miktarı, uygulamanın işlevselliği vb.
• Son tarihler - anlaşmazlıkları ortadan kaldırmak için önemlidirler.

Yazılım için teknik şartname hazırlama örneği

Yazılım oluşturmamız gerekiyor. Teknik gereksinimler - aşağıda.

Tanım: tüm yetkili sitelerdeki makaleleri anahtar kelimeye göre aramak için bir program, yetkili sitelerin adreslerini manuel olarak girmeniz gerekir.

Yazılımın yapması gerekenler:bir anahtar kelime girdikten sonra, önceden yetkili kaynaklar olarak girilen sitelerdeki makaleleri bulur, şu formatta bir eşleşme listesi görüntüler:

• Bağlantı
• Makale başlığı
• Giriş paragrafı

10'dan fazla eşleşme varsa, her birini 10'ar sayfaya ayırmanız gerekir.

Teknik gereksinimler:programlama dili - herhangi biri, önemli değil. Önemli olan, programın daha sonra sonlandırılabilmesi ve çevrimiçi bir hizmet olarak sunulabilmesidir. İdeal olarak, hizmet 10 saniye aramalıdır.

Zamanlama: 15.09.2018 tarihine kadar.

Doğal olarak, bu Görev Tanımı geliştirilebilir - bunu bir örnek olarak sağladık. Ve sizce, referans şartları nasıl daha net, daha basit, daha uygun hale gelecek şekilde geliştirilebilir?

Hayatta, bir kişinin günlük işlerde bile ne istediğini açıklayamadığı sık sık olur. Bir programcıya "isteklerinizi" açıklamaya gelince, kişi basitçe bir sersemlik içine düşer.

İdeal olarak, TK müşteri tarafından hazırlanmalıdır - neye ihtiyacı olduğunu yalnızca o bilir. Ancak uygulamada, müşterinin 1C alanındaki yeterliliğinin düşük olması nedeniyle, bunun genellikle yüklenici tarafından yapılması gerekir. Müşteri ihtiyaçlarını sözlü olarak dile getirir ve programcı (danışman) bunu yazılı olarak resmileştirir.

Spesifikasyona neden ihtiyaç duyulur?

Herhangi birine ideal olarak teknik bir görev eşlik etmelidir. Bu, ilk olarak, görevin, son teslim tarihlerinin ve uygulama yönteminin net bir tanımıdır. İkincisi, gelecekte tüm anlaşmazlıkların çözüldüğü bir belgedir. Teknik şartname yazıp yazmamak elbette size kalmış, şahsen benim için teknik şartname bir müşteri ile çalışmayı ve iletişim kurmayı kolaylaştırır.

267 1C video dersini ücretsiz alın:

Görev tanımı neleri içermelidir?

Onlar. Ödev şunları içermelidir:

• hedef- bu görev tanımını uygulayarak çözeceğimiz görev;
• Tanım- yaklaşan iyileştirmelerin bir özeti;
• uygulama yöntemi- hedefi çözme yöntemlerinin ayrıntılı bir açıklaması. Bu noktada, görevin tüm nüanslarını programlama dilinde açıklamak gerekir: ne, yaratırız / düzenleriz, arayüzün nasıl görünmesi gerektiği vb. "Programlama dilini" bilmiyorsanız, ancak "bir şeyler duyduysanız", teknik bir dilde yazmaya çalışmamak daha iyidir - oldukça eğlenceli olduğu ortaya çıkıyor. Açıklama net olmalı ve sorulara neden olmamalıdır. Benzer bir çözümün başka bir alanda uygulanmasına ilişkin bir örnek de içerebilir;
• performans değerlendirme- çok önemli bir nokta, işçilik maliyetlerinin açıklaması.

Teknik özellikleri yazmak için devlet standartları da vardır - GOST'ler. Uygulamada, nadiren herhangi bir yerde kullanılırlar, ancak müşteri bu konuda ısrar eder.

Deneyimden, işi teslim ederken, "size o zaman söylemiştik ..." gibi durumlar çok sık ortaya çıkar, bu pek hoş değildir ve çoğu zaman işi tamamen yeniden yapmanız gerekir. Bu nedenle, iyi yazılmış bir Görev Tanımı her iki tarafın da hayatını büyük ölçüde kolaylaştırır.

1C için TK örnekleri ve örnekleri

İnternette ücretsiz olarak bulduğum küçük bir seçim. En basit ve en erişilebilir olandan başlayıp, oldukça karmaşık belgelerle biten.

Pek çok şirket, her yüklenicinin yalnızca çalışanlarının anlayabileceği bir belge yazacağına inanarak, aslında rekabette/ihalede kendisine ayrıcalıklı bir konum garanti ederek, görev tanımlarını yazma aşamasında yüklenicileri dahil etmeye hazır değildir.

Bu kısmen doğrudur, ancak çoğu durumda bu fenomen, yüklenicilerin ticari çıkarlarından çok, bu belgenin uygulanmasına yönelik yaklaşımdaki farklılıklarla bağlantılıdır.

Özellikle Wikipedia'daki görev tanımının tanımı, bunun “müşterinin satın alma nesnesi için gereksinimlerini içeren, eyalet veya belediye ihtiyaçlarını karşılamak için uygulanmasına ilişkin koşulları ve prosedürü tanımlayan bir belge olduğunu belirtir. malların teslimi, işin yapılması, hizmetlerin sağlanması ve bunların kabulü.

Ek olarak, böyle bir belgede neyin ve hangi biçimde yer alması gerektiğini açıklayan bir dizi GOST vardır, örneğin 19.201-78.

Bununla birlikte, uygulamada görüldüğü gibi, gıpta ile bakılan "TK" kısaltması, özü, içeriği, tasarımı ve detayı tamamen farklı olan belgeleri ifade eder. Ne yazık ki, birçok müşteri, gelecekteki bir sistem için birkaç sayfalık gereksinimler yazdıktan sonra, bizden bir çalışma programıyla birlikte doğru bir tahmin (maksimum %10-20 delta ile) alacaklarından emindir. Bir kez daha, "TK, buna göre yarına kadar CP'yi değerlendirmek ve göndermek gerekli" postasını aldığımda, "sistem gerekli tüm bilgileri değiş tokuş etmeli" tarzında bir sonraki yaratımı görmeye her zaman zihinsel olarak hazırlanırım. sitesi ile”.

Bir zamanlar çalıştığım departmanda şu bölümleme benimsenmişti: İş Tanımı, sistem gereksinimlerini iş kullanıcılarının anlayabileceği bir dilde açıklayan bir belge ve Teknik Tasarım, temel alınarak hazırlanan bir belgeydi. Görev Tanımı, daha ayrıntılı, tüm işlevleri ayrıntılı olarak açıklayan, ancak zaten esas olarak geliştiricilerin anlayabileceği bir dilde.

Bana göre bu nitelendirme, biçimsel açıdan doğru olmasa da, fazladan bütçesi olmayan ancak acil çözüm gerektiren işleri olan küçük şirketler için çok adil görünüyor. Onlar için asıl mesele, teknik şartnamelerin çalışanları tarafından derlenmesi ve örneğin birkaç franchisee firmaya dağıtılmasıdır. Ve hiç kimsenin inanılmaz miktarda teknik bilgi içeren devasa bir sayfa yazmaması doğaldır.

Peki, sonunda "tipik yapılandırma işlevselliğinin yapabileceği" değil, yazar(lar)ı tarafından ortaya konan şeyin tam olarak ortaya çıkacağı bir teknik şartname nasıl yapılır?

Belgenin yapısı için temel gereksinimleri açıklamayacağım, örneğin: görev tanımında projenin hedefleri açıklanmalı, işlevsel gereksinimler yer almalı, bir kısaltmalar listesi ve bir içindekiler tablosu olmalı, her şey en basit ve kısa ifadelerle yazılmalıdır, vb. Teknik özellikleri en az birkaç kez okuyan herkes bunu biliyor sanırım.

Uğraşmam gereken ve fikre mümkün olduğunca yakın sonuçların elde edildiği belgeler aşağıdaki özelliklere sahipti:

1. talimat olarak TK. Belge yapısı itibariyle bir kullanım kılavuzuna benzer, burada adım adım yazılır, bu durumda kullanıcının istenen sonucu elde etmesi için hangi işlemleri yapması gerekir. Onlar. bunlar, gerekli işlevlerin sürekli bir listesi olmayan, ancak özelliklerinin bir açıklamasıyla ayrı süreçlere mantıksal bir dökümü olan belgelerdi.

2. Daha fazla görselleştirme. Bir belge ne kadar çok düzen/ekran görüntüsü/model/akış şeması içerirse, gerekli işlevleri yerine getiriyor gibi görünen ancak tamamen farklı bir mantık/tasarım/arayüze sahip bir sistem elde etme olasılığı o kadar düşüktür.

3. kullanılabilirlikÖnceki iki noktadan basit bir sonuç var - net çalışma mantığı ve gelecekteki sistemin maksimum görselleştirmesi, sonunda, sistemin kullanılabilirliği ile ilgili gerekli sayıda notun / noktanın Görev Tanımına eklenmesine yardımcı olacaktır. Düşük vasıflı çalışanların çalıştığı sistemler için bu, projenin başarısında belirleyici bir faktör olabilir (ancak bu parametre, "bu muhasebe programları" ile uğraşmak istemeyen üst yönetim için de son derece önemlidir). Örneğin, bir perakende satış sistemi için Görev Tanımı, bir makalenin aranmasının üç saniyeden fazla sürmemesi gerektiğini belirtmemiştir. Sistem, tipik bir yapılandırma araması yoluyla uygulandıysa, bu, gerçek operasyonda kritik durumlara yol açabilir, çünkü öğe sayısı dikkate alındığında, bu arama 30 saniyeye kadar sürdü ve bu, her saniyenin önemli olduğu perakende müşterilerle çalışırken kabul edilemez.

4. Popüler çözümlere bağlantılar. Çoğu zaman, örneğin şirketin satış müdürleri gibi herkes için "işlemsel işlevsellik" ifadesi yaklaşık olarak aynı anlama gelir, ancak yüklenicinin çalışanları için bu ifade kesinlikle hiçbir şey ifade etmez. Ancak bu cümleye birkaç kelime ekleyin ve "Bitrix24'teki (veya 1C: CRM) benzeri anlaşma kartı" seçeneğinden, Müşterinin bu karttan ne beklediği zaten açıktır.

5. Birincil Geri Bildirim. Bir kez daha tekrar ediyorum - TK'nın başarılı bir şekilde uygulanması için GOST'a göre yazılmasına gerek yok. Yalnızca teknik uzmanlara yönelik bir belge yazmaya gerek yoktur. Görev tanımı, her şeyden önce, yaratıcısının meslektaşları ve ardından onu uygulayacak olanlar için açık olmalıdır. Bir belgeyi potansiyel yüklenicilere veya dahili geliştirmeye iletmeden önce diğer iş kullanıcılarından olumlu geri bildirimler almak çok önemlidir. Bir kişi için son derece açık olan ancak en yakın çevre tarafından bile anlaşılamayan bir belgenin başarılı bir şekilde uygulanma şansı yoktur.

İş Tanımının hazırlanması için gereklilikler konusunda elbette farklı bakış açıları vardır. Ancak, uygun zaman, kaynak ve yetkinliklerin yokluğunda, başarılı bir uygulama için maksimum şansa sahip olacak, yukarıdaki özelliklere sahip olan iş kullanıcıları için en anlaşılır dilde yazılmış görev tanımlarıdır.

Bir geliştiriciden site alırken tamamen hayal kırıklığına uğramak istemiyor musunuz? O zaman bu makaleyi dikkatlice okuyun!

Ama belki de onun hatası değil? Sonuçta, herhangi bir delegasyonun sonucundan yalnızca icracı değil, müşteri de sorumludur.

İstenilen maksimum sonucu elde etmek için, bir web sitesi oluşturmak için teknik bir görevi nasıl doğru bir şekilde hazırlayacağınızı bilmeniz gerekir.

GÖREVE NEDEN İHTİYACINIZ VAR?

• Müteahhit sitenin geliştirilmesi için yetkin bir teknik şartname, işin miktarını, karmaşıklığını ve maliyetini önceden tahmin etmeye yardımcı olacaktır. Böyle bir görevle kendi başına başa çıkıp çıkamayacağını veya asistan almaya değip değmeyeceğini anlamak için. Ve sonra müşterinin ondan ne beklediğini tam olarak yapın.
• Müşteri görev tanımı, gelecekteki site için isteklerini belgelediğine, yüklenicinin yerine getirmesi gereken son teslim tarihlerini açıkça belirttiğine, site için gereklilikleri belirlediğine dair güven verir. Sonuç tatmin edici değilse, geçerli bir talepte bulunabilirsiniz: "GK'ya uymuyor!"

GÖREV ŞARTLARINA NE YAZIYORLAR?

Ödev aşağıdaki soruları ele alır:

• Site neden ve kimin için oluşturuldu?
• Ne ile doldurulacak?
• Bütün bunlar nasıl işleyecek?
• Projede kim, nasıl çalışacak, kim neyden sorumlu olacak?
• Çıktı ne olacak?

SİTENİN GELİŞTİRİLMESİ İÇİN GÖREV ŞARTLARININ ANA BÖLÜMLERİ

1. Müşteri, yani sizinle ilgili bilgiler

Mümkün olduğunca çok ayrıntı sağlayın. Geliştiricinin eksik verileri alabileceği tüm kaynakları belirtin. Bunlar broşürler, posterler, elektronik materyaller, bağlantılar, soru sorulabilecek kişilerin iletişim bilgileri olabilir.

2. Proje hakkında bilgi

Ne olacak: bir kartvizit sitesi, bir blog, bir çevrimiçi mağaza, bir kurumsal portal, bir elektronik kütüphane?

3. Sitenin hedef kitlesi

Hedef kitlenizi tanımlayın, neye ihtiyaçları olduğunu ve nasıl ilgilenebileceklerini söyleyin.

4. Sitenin müşteri ve hedef kitle için çözmesi gereken hedefler ve görevler

Neden bir web sitesine ihtiyacınız olduğunu açıkça anlamalısınız. Görüntüyü geliştirmek için mi? Doğrudan satış için mi? Haber için mi? Web siteniz ile ziyaretçileri abonelere dönüştürmek ister misiniz? Potansiyel ortakları çekmek için bir kaynak oluşturmak ister misiniz?

Sitenizin doğrudan amacını belirtin.

Bir web kaynağının bireysel görevleri hakkında dikkatlice düşünün. Örneğin, piyasa haberleri hakkında güncel bilgiler vermeli, ürünlerinizi sergilemeli, ziyaretçilerin doğrudan sitenin sayfalarından sizinle iletişime geçmesine izin vermeli vb.

5. Proje çerçevesi (ana işlevsellik)

Site çok sayıda işleve sahip olabilir: bir kullanıcı kayıt formu, geri bildirim, sipariş düğmeleri, bir teslimat takvimi, bir haber akışı, sepete gitme özelliğine sahip bir ürün kataloğu, yerleşik bir posta komut dosyası, kapalı bölümler için müşteriler - her neyse! Bu işlevlerin her biri, sitenizin geliştirilmesi için görev tanımında en ayrıntılı şekilde açıklanmalıdır.

Bu nedenle, "Proje Kapsamı" bölümü, içindekiler tablosu gibi bir şeydir, işlevleri ayrıntılı açıklamaları olmadan listeler. Bir sanatçı arama aşamasında bu bölüme ihtiyacınız olacak. Siz işlevsellik isteklerinizi sistematize ederken, sitenizin potansiyel yaratıcısının büyük resmi görmesine ve yaklaşık bir fiyat vermesine olanak tanır.

6. Sitenin yapısı (haritası)

Site için TOR'un bir sonraki paragrafı, yükleniciye sitenizde hangi sayfaların olacağını, hangi bölümlerin ve alt bölümlerin birbirine nasıl bağlanacağını, site menüsünde nasıl görüntüleneceğini söyleyecektir.

Yapıyı çizmek tarif etmekten daha kolaydır. Grafik formda, sitenin alanları arasındaki ilişkiyi düşünmek daha kolaydır.

7. Bireysel sayfalar

Site haritasını çizerken her sayfa sadece bir karedir. Ancak sanatçının bu karede neyin ve hangi sırayla yer alacağını anlaması gerekiyor (makalenin başındaki tablo örneklerini hatırlayın). Hangi bilgi blokları olacak? Her sayfada menüler, kenar çubukları olacak mı? (navigasyonlu ayrı blok), altbilgi (alt blok)? Sayfada afişler, resimler görmek ister misiniz? Statik mi yoksa hareketli mi olacaklar?

Gelecekteki kaynağın her sayfasının her bir öğesini ne kadar ayrıntılı tanımlarsanız, çıktı sonucu site hakkındaki fikirlerinize o kadar yakın olacaktır.

8. Saha tasarımı gereksinimleri

Renk şemasına karar verin, bize hangi renkleri tercih ettiğinizi söyleyin. Geliştiriciye mevcut malzemeleri sağlayın: logo, afişler, renk kodları… Ona, beğendiğiniz ve benzer bir şey istediğiniz İnternet'teki çalışma sitelerinden örnekler gösterin. Bize hangi renkleri tercih ettiğinizi söyleyin. Örneğin, kadın eğitimine yönelik bir web sitesi yapmak istiyorsunuz, tasarımcı pembe yapacak ama siz turuncuyu seviyorsunuz. İsteklerin genel bir açıklaması, vizyonunuz ile tasarımcının profesyonel görünümü arasında bir uzlaşma bulmanıza yardımcı olacaktır.

9. Sitenin çalışma işlevselliği

Sitede hangi işlevleri görmek istediğinizi ayrıntılı olarak açıklayın. Sanatçıya mümkün olduğunca fazla bilgi verin. Onun telepati yeteneğine sahip olmadığını ve sitenin kullanım şartlarını yazdığınızda ne elde etmek istediğinizi tahmin edemeyebileceğini unutmayın. "Abonelik formu" veya "takvim".

Ne formu? Ne için? İçinde hangi öğeler olmalı? O nasıl görünüyor? Oyuncu bu nüansları tahmin edemeyebilir, sonunda istediğinizden tamamen farklı bir şey elde edeceksiniz. Para ödendi, proje görev tanımına uygun (siz yazdınız) "takvim"- işte burada) ve istediğiniz bu olmasa da olanlardan memnun olmanız veya değişiklikler için fazla ödeme yapmanız gerekecek.

10. İçeriğin açıklaması

İçeriği sitenin oluşturulmasıyla aynı anda sipariş ederseniz ve bir yükleniciniz varsa (örneğin, bir ajans), içeriğin açıklaması, metin yazarı için ayrı bir Görev Tanımıdır. İçeriği kendiniz oluşturacaksanız veya başka bir sanatçıdan sipariş verecekseniz, site geliştiricisinin yine de hangi bölüme neyin yerleştirileceği ve nasıl görüneceği konusunda bir fikri olması gerekir. Metin nerede, video nerede, resimler nasıl tasarlanacak, yazıların önizlemesine ihtiyaç var mı, ne olacak vs.

11. Teknik gereksinimler

Site yapımından az anlayanlar için zor bir nokta.

Anlamıyorsanız, mantığı açın.

Örneğin, siteniz:

• farklı genişlikteki monitörlerde eşit derecede iyi görünün (duyarlı tasarım);
• tanıtım için optimize edilmiş SEO;
• virüslere direnebilmek;
• yerleşik seo işlevselliğine sahip olmak vb.

Yalnızca emin olduğunuz şeyler hakkında yazın veya bir uzmana danışın. Daha sonra iyileştirmeler için fazla ödeme yapmaktansa önceden danışmak daha iyidir.

Bizimle iletişime geçmeye karar verirseniz ve kendi görev tanımınız yoksa, bizimkini indirip doldurabilirsiniz.