“Ürün gereksinimleri belgesi” talebi ile yabancı sitelere girerseniz, teknik görevin (TOR, PRD) bittiği konusunda yaratıcı ve inandırıcı makaleler bulabilirsiniz. Kısmen, bununla hemfikir olmalıyız - sıfırdan bir ürün geliştirirken, prototipleme, bazen çok profesyonel olmayan müşteri kayıtlarından çok daha ilginç ve verimli görünüyor. Ancak, temel sistemi sonlandırmaktan bahsediyorsak, işler tamamen farklı bir hal alıyor. Hem revizyon hem de özel geliştirme ile karşı karşıyayız, bu yüzden aşçı bize yalan söylemezse köpek TK'de yendi. Genel olarak, bugün - satın alınan ve kurulan yazılımı sonlandırmak için yazılan çok klasik teknik görevler hakkında. Kısacası, ağrı hakkında.

Etkileşimin Yönleri

Teknik bir görev oluşturma sürecinin hazırlanmasına geçmeden önce müteahhit ve müşterinin projeye başlarken içine düştükleri dörtgenden bahsedelim.

Gereksinimler- Müşteri veya süreç sahibi tarafından açıklandığı gibi, sistemin istenen davranışı, uygulanacak. Kural olarak, gereksinimler, programın doğru davranışının temsili olan deneyim temelinde oluşturulur. Bu geliştirici (satıcı) için önemli bir bilgidir, ancak en fazla sayıda çakışma, hata, gereksiz istek vb. meydana geldiği gereksinimler toplama aşamasındadır.

Kaynaklar- Gereksinimlerin uygulanması sürecinde kullanılacak insan, makine, envanter, geliştirme ortamı, zaman ve para. Kaynaklar, görev tanımlarının onaylanması aşamasında net bir planlama ve değerlendirme gerektirir. Müşteri tarafında yetkin önceliklendirme ve satıcı tarafında işgücü kaynaklarının dağıtımı, kaçırılan teslim tarihlerini önlemeyi ve diğer riskleri en aza indirmeyi mümkün kılar.

Fırsatlar- kısacası, bir satıcının (icracı) gerçekten yapabileceği şey budur. Örnek olarak RegionSoft CRM'imizi düşünün. Müşteri sistemi satın alır ve revizyon için teknik bir görev hazırlar: site ile bir entegrasyon oluşturmak ve CRM'deki olayları çevrimiçi mağazanın sipariş numarasına bağlamak gerekir. Bu gerçekçi bir gereklilik, bunu yapacak kaynağa ve yeteneğe sahibiz. Ayrıca bir site içerik yönetim sistemi olan CRM CMS'yi geliştirmeniz ve bağlamanız gerekir. Teorik olarak bunu yapabiliriz, ancak bunu ucuza yapma imkanımız yok ve müşterinin bize insan ve zaman kaynaklarını göreve aktaracak kadar ödeme yapma şansı yok. Sonuç olarak, müşteri bu şartı reddediyor - ve gerçekten bir CMS'ye ihtiyacı yok, zaten her şey yolunda. Ancak TK'nin "açgözlülüğü" hakkında - daha sonra.

Kısıtlamalar- Görev Tanımındaki görevleri tamamlamayı zorlaştıran veya imkansız kılan bir dizi engel: bütçe, teknoloji yığını, lisanslama sorunları, yasal yasaklar, donanım yapılandırmaları vb.

Böylece, dört varlığın tümü iç içedir ve bir bütün olarak projenin başarısını belirler. Her bir unsuru ele alalım ve görev tanımları üzerinde çalışırken akılda tutulması gereken kritik noktaları vurgulamaya çalışalım.

İhtiyaçların toplanması ve analizi

Bu, potansiyel kullanıcıların programdan ne istediğinin ortaya çıktığı çok önemli bir şirket içi süreçtir (bundan sonra CRM alacağız, ancak yöntemler diğer yazılım türleriyle çalışır). SAP veya sistem entegratörü gibi büyük bir satıcıyla iletişim kurarsanız, yüksek bir olasılıkla size bir iş danışmanının hizmetleri sunulacaktır (o aynı zamanda kişisel bir yöneticidir, aynı zamanda bir hesap yöneticisidir, aynı zamanda “ şimdi şirketimizdeki temsilciniz”). Aslında, çoğu durumda, bu, iki görevi olan sıradan, iyi eğitimli bir satıcıdır: projenin maliyetini ortadan kaldırmak ve sizi serbest bırakmamak.

Bir saattir burada ve beyaz tahtaya dokunmadı bile. O gerçek bir sistem analisti değil

Şirketinizi sizden ve çalışanlarınızdan daha iyi kimse bilemez. Bu, gereksinimlerin toplanması ve analizinin yalnızca sizin göreviniz olduğu ve satıcının yardımcı olabileceği ve rehberlik edebileceği, ancak hiçbir durumda sürece müdahale edebileceği anlamına gelir. Geliştiriciye bu tür uygulamaları sorun, ne arayacağınızı belirtin ve devam edin. Bu arada, profil konusuna hakim, kabaca yazılım mimarisini temsil eden ve geliştirme sürecine aşina olan çalışanınız iyi bir yardımcı olabilir - analist ve iç uzman olarak hareket edebilir, teknik şartname oluşturma sürecini kapatabilir. ve satıcı ile iletişim.

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

1. CRM kullanacak yönetici ve deneyimli departman uzmanlarından oluşan bir çalışma grubu oluşturun. Bize seçeceğiniz çözümü anlatın, demo versiyonuna erişim sağlayın.
2. Çalışma grubu üyeleri, çalışanlara bilgi aktarmalı ve tamamen ücretsiz bir biçimde yeni bir program için dileklerini sormalıdır. Çalışanlardan biri böyle bir yazılımla hiç karşılaşmadıysa ve gelecekteki kullanım hakkında konuşmaya hazır değilse, periyodik görevlerini açıklamasını istemeniz gerekir, bu evrensel bir yaklaşımdır.
3. Daha sonra her bölüm, CRM'nin neyin eşleşmediğini veya eşleşmediğini belirler ve bilgileri toplar.
4. Çalışma grubu toplanan gereksinimleri analiz eder, kavşakları kontrol eder ve ortadan kaldırır. Örneğin, bir satış departmanının ve bir pazarlama departmanının aynı raporu sipariş etmesi nadir değildir, ancak alanlar ve varlıklar, arkalarındaki veriler aynı olmasına rağmen gereksinimlerde farklı şekilde adlandırılabilir. Buna göre tek bir şekle gelmek gerekir.
5. Çalışma grubu bir gereksinimler listesi oluşturur ve öncelikleri belirler. Bu aşamada, kaynaklardan sorumlu olduğu için satıcıyı bağlayabilirsiniz. Örneğin, RegionSoft CRM için özel bir rapor oluşturulmasını isteyebilir veya site ile entegrasyon siparişi verebilirsiniz. Bunlar zaman açısından tamamen farklı işler, burada öncelik çok önemli.

Gereksinimler toplandıktan, analiz edildikten ve çalışanlar ve yönetimle kararlaştırıldıktan sonra, görev tanımlarını oluşturmaya başlayabilirsiniz. Satıcıdan formu isteyebilir veya kendiniz oluşturabilirsiniz - her durumda, hem sizi hem de CRM sağlayıcınızı baş ağrısından kurtaracak birkaç katı kural vardır.

Bir Görev Tanımının Anatomisi

Teknik bir görev oluşturma sürecinden bahsedersek, birkaç aşama vardır. Tutarlı geçişleri, müşteriyi istenen iyileştirmeye götürür. İşte buradalar.

• Tanımlama - gereksinimlerin tanımı, çözülmesi gereken sorunları arayın.
• Analiz - gereksinimlerin analizi, temel ihtiyaçların belirlenmesi, genelleme.
• Adaptasyon - CRM yetenekleri ve mevcut iş süreçleri bağlamında gereksinimlerin değerlendirilmesi.
• Dokümantasyon - gereksinimlerin resmi ve ayrıntılı bir açıklaması, teknik şartnamelerin onayı.
• Satıcıyla iletişim (geliştirici) - derlenen TOR'a göre iyileştirmelerle ilgili olarak satıcıyla yinelenen etkileşim.
• Uygulama - satıcının gerekli işlevselliği yaratma işi. Satıcının müşteriyle sürekli iletişim halinde olması daha iyidir - bu nedenle çıktı ürünü müşterinin vizyonuna en yakın şekilde uyacaktır.
• Test etme - revizyonun TOR ile uyumluluğunu, sistemin değişikliklerle işlerliğini belirlemek için satıcının çalışanları, müşterinin dahili uzmanları ve son kullanıcılar tarafından işlevselliğin kontrol edilmesi.

Genel olarak, görev tanımları, projenin oluşturulmasında örtüşen ve işbirliği yapan veya hiç etkileşime girmeyen çeşitli seviyelerin gereksinimlerine dayalı olarak oluşturulabilir.

İş seviyesi- karmaşık ve öncelikli görevlerin çözüldüğü en küresel düzey. Bu seviye, iş süreçlerinin entegrasyonunu, iyileştirilmesini ve modellenmesini, yeni fonksiyonel modüllerin geliştirilmesini içerir. Kural olarak, bu, ciddi istişareler ve müşteri ile yakın işbirliği ile kaynak yoğun bir gelişmedir. Örneğin, bir zamanlar RegionSoft CRM'de depo muhasebesi, yazar kasa ve üretim bu tür özel değişikliklerdi. Yavaş yavaş, değişiklikler sürüme girdi ve daha sonra toptan, perakende mağazalar ve hipermarketler için yeni bir ürün oluşturulmasına izin verdi - RegionSoft Retail.

Kullanıcı veya kullanıcı grubu düzeyi. Bu seviyede, mevcut arayüzü iyileştirmek için görevler uygulanır. Örneğin, bir kullanıcı, bir müşterinin üzerine geldiğinde son siparişin numarasını ve durumunu gösteren bir pencerenin veya özel bir veri gruplaması içeren özel bir raporun görünmesini isteyebilir. Bu düzeydeki iyileştirmeler daha az zaman alır, ancak birçoğu olabilir - örneğin, pazarlama, lojistik ve teknik destek departmanlarından gelen çeşitli gereksinimler.

işlevsellik seviyesi. Bunu öncekinden ayırmak genellikle zordur, burada resmi bir kriter işe yarar - iyileştirme, arayüzde bir şey gösterme düzeyinde değil, sistem mantığının iyileştirilmesi düzeyindedir. Bunlar, çeşitli sıralama, sohbet entegrasyonu ve telefon yetenekleri için gereksinimleri içerir.

Servis seviyesi- aslında, bu seviyenin gereksinimleri, düzeltmelerle yeni yapılara ilk girenler olmalıdır. Bunlar sistem yanıt hızı, yüksek yük altında çalışma ve güvenlik açısından görevlerdir. İdeal olarak, satıcı bu tür iyileştirmelere sahip olmamalıdır - kurumsal yazılım yavaşlamamalı, veri kaybetmemeli, formları daraltmamalı ve aynı düzeyde erişim haklarını dağıtmamalıdır. Ancak bir gereksinim ortaya çıktıysa ve müşterinin kişisel paranoyasıyla veya donanım tarafındaki sorunlarla ilgili değilse, buna özellikle dikkat etmeye değer.

Teknoloji seviyesi- listenin sonuncusu, ancak önem ve karmaşıklık açısından diğerlerinden önde. Bunlar platform, işletim sistemi veya cihazlarla ilgili müşteri gereksinimleri olabilir. Örneğin, MacOS için bir derleme isteği. Bu tür gereksinimlerin kademeli olarak sürümlere dönüşmesi harika, ancak düzeltmelerinin yapılması gerekiyor. MacOS için RegionSoft CRM'nin montajını bu düzeydeki müşterilerin istekleri doğrultusunda gerçekleştirdik ve mobil sürüm için nadir, ancak mevcut bir isteğe geçici bir çözüm olarak TRM teknolojisini kullanarak uzaktan erişim ekledik.

Referans terimlerinin anatomisi basittir, en azından bir iskelet şeklinde. Görev tanımının zorunlu bölümleri, müşterinin soruna odaklanmasına ve görevi doğru formüle etmesine ve icracının ondan ne istediğini anlamasına yardımcı olur. Bu arada, anlayışla ilgili. Tabii yazının başında biraz kurnazdık, iş danışmanlarını sınıf olarak reddediyorduk. Buradaki nokta şudur: her satıcı piyasada birkaç yıldır faaliyet göstermektedir (şu anda bir günlük CRM'lerden bahsetmiyoruz), hatta onlarca yıldır, bu da hemen hemen her sektörde bir dizi vakaya sahip olduğu anlamına gelir. Buna göre, hem mühendisler, hem programcılar hem de satış görevlileri, her tür şirketteki uygulamanın özelliklerine aşinadır. Ancak yine de işinize odaklanmanız önemlidir.

Kimin için? Bu bölümde, revizyonun son kullanıcısının kim olacağını, hangi görevleri ve ne sıklıkla çözmesi planlandığını açıklamanız gerekir.

Sana bir örnek vereceğim. Bir şirket CRM uyguladı, oldukça geniş bir veri dizisi üzerinde çalışması gerekiyordu (ayda birkaç on milyonlarca kayıt, günde birkaç yüz bin kayıt). Satış departmanı başkanı bu kayıtların "günlük" sıklıkta yüklenmesiyle ilgili bir rapor istedi. Doğal olarak böyle bir rapor, yüzlerce kullanıcı aynı anda çalışırken sisteme yüklendi - süreci optimize edecek çözümler bulundu. Zaten çalışma sırasında, satıcının güvenli oynadığı ve rapora yalnızca ayın sonunda ihtiyacı olduğu ve daha sonra programa göre gece başlatılabileceği ortaya çıktı. Söylemeye gerek yok, zaman ve para boşa gitti.

Ne için?İyileştirme ihtiyacının gerekçesi ve iş sürecindeki yeri. Bu öğeye müşterinin kendisi daha çok ihtiyaç duyar, ancak satıcının diğer hangi süreçlerin etkileneceğini bilmesi de yararlıdır. Bazen alternatif bir çözüm bulmaya yardımcı olur.

Ne yapılmalı? En bilgilendirici blok - sistemden gereksinimleri, beklentileri açıklar. Ve burada, tam da bashorg'a göndermek için doğru olan ve hayatı çok zorlaştıran inciler, mucizeler ve çarpışmalar meydana gelir. Tek bir sebep var - kullanıcı ne istediğini, ne yapılması gerektiğini bilmiyor. Başka bir küçük alt neden daha var - kullanıcı gereksinimleri formüle edemiyor. Ve burada geliştiricinin (çalışma grubu, varsa analist) görevi, ihtiyacı doğru formüle etmeye, uygun bir gereksinim seçmeye ve görevi sistem bağlamına uydurmaya yardımcı olmaktır. Aynı blokta, beklenen sonucu belirtmeniz gerekir.

Referans parametrelerinin şartları- son tarihler, uygulama aşamaları, tüm taraflardan sorumlu, gerekli irtibatlar vb. Aslında bu, belgeyi teknik bir görev haline getiren bir dizi önemli resmi şeydir. Geliştirme sırasında çok sayıda değişiklikten kaçınmak için görev tanımları üzerinde anlaşmaya varılmalı ve taraflarca imzalanmalıdır (bunlar yine de olacaktır, ancak daha küçük bir hacimde olacaktır).

İdeal olarak, referans şartları satıcının aktif katılımıyla hazırlanır ve sonucu yaklaşık olarak aşağıdaki yapıdır:

1. Her mekanizmanın ve her bir işlevselliğin gereksiniminin açıklaması
2. Bu işlevin uygulanmasının açıklaması
3. Aşamaların her biri için ayrı ayrı işin maliyeti
4. Bu teknik görevdeki toplam çalışma maliyeti
5. Aşamalara göre bir döküm ile işin yürütülmesi için son tarihler ve öncelik sırasının bir göstergesi
6. Kurulum ve test koşullarının açıklaması
7. Görev tanımının ve diğer koşulların kapsamlı doğasına ilişkin çekinceler

Geliştiricinin Gözyaşlarıyla Yazılan 10 Kural

Revizyon için görev tanımları, revizyon için TOR olmalıdır ve müşterinin ihtiyaç duyduğu CRM'nin 300 sayfalık bir açıklaması değil. Gereksinimleri belirlemeden önce, sistem arayüzünü, yeteneklerini, belgelerini dikkatlice öğrenmelisiniz - büyük olasılıkla, "İstek Listesinin" çoğu zaten temel pakettedir. İkinci adım olarak, yerleşik iyileştirme araçlarına (rapor tasarımcıları, yapılandırıcılar, vb.) dikkat etmenizi öneririm - belki tam zamanlı bir programcı gerekli değişiklikleri yapabilir (birçok şirkette vardır).

Teknik görev açgözlü olmamalıdır.Çoğu zaman, bir işletme yeteneklerini abartır veya "her şeyi aynı anda" elde etmek ister. Bu yaklaşım, ne para açısından ne de iş açısından haklı değildir. Bir satıcı, kural olarak, birkaç hafta boyunca mevcut değildir (RegionSoft - 15 yıl durumunda) ve bir süre sonra, CRM'de neyin eksik olduğunu gerçekten anladığınızda, onunla iletişime geçebilirsiniz.

Kelimenin tam anlamıyla dünden canlı bir fazlalık örneği: bir müşteri, muhasebe çalıştığı için bu satıcının ERP'sinin iyi olacağını düşünerek tanınmış bir Rus şirketinin ERP'sini satın aldı. ERP'nin kendi içinde çok iyi olmadığı, ancak iş için çok uygun olmadığı ortaya çıktı. Ancak depo muhasebesi ve üretimi ile RegionSoft CRM uygundur. Bir çözüm var: ERP'yi unutun, ağlayın, 1C muhasebesini yeni CRM ile entegre edin ve uygun uygulamanın keyfini çıkarın. Ama şişmiş para üzücü! Ve müşteri, CRM'yi ERP ile entegre etmeyi talep ediyor. Bunu yapmadık, ama neden böyle bir israf, neden iki nispeten benzer sistem?

Görev tanımı gerçekçi ve ulaşılabilir olmalıdır- hem gereksinimler hem de son tarihler açısından. Burada, belirli bir görevin ne kadar zaman alacağını tam olarak bildiğinden, satıcının görüşünü dinlemek önemlidir. İnanın bana, bir geliştiricinin zamana karşı oynaması ve son teslim tarihini tamamlaması karlı değildir - itibarına bir darbe almamak için mümkün olduğu kadar çok projeyi tamamlaması ve iyi yapması onun için faydalıdır. Gerçekçiliğe gelince, CRM'yi bir çarpıştırıcı kontrol sistemi düzeyinde tamamlama taleplerinden kaçınmak basittir: Şu anda ve öngörülebilir gelecekte gerçekten ihtiyaç duyulanları gereksinimlere dahil etmelisiniz.

Örneğin, RegionSoft CRM bir masaüstü programıdır, tarayıcı istemcimiz yoktur. Bizden bir şirket için bir web uygulaması oluşturmamızı istemek anlamsız, bu büyük bir gelişme, şu anda devam ediyor ve bir şirket için olası bir iyileştirme değil. Hayır, elbette, her şeyin bir fiyatı vardır, ancak yine - genel durumda, gereklilik imkansızdır.

Özel geliştirme söz konusu olduğunda ve uygulamanın fikir ve mantığının kökten değiştiği durumla karıştırılmamalıdır, aslında “kendisi için” yeni yazılımların oluşturulması sponsorluktur. Ama bu başka bir hikaye.

Spesifikasyon ayrıntılı olmalıdır. Gelecekteki projenin tüm önemli ayrıntılarını belirtmek gerekir: programı kullanma sıklığından arayüz isteklerine kadar. Gereksinimler ne kadar ayrıntılı olursa, uygulama ve test etme o kadar kolay ve hızlı olacaktır. Belirli bir sektörde (tıp, sigorta, bankalar) çalışıyorsanız, ayrıntılara özellikle dikkat etmeye değer - işletme ve program arasındaki etkileşimin nüanslarının ayrıntılı bir sunumu, satıcının görevi anlamasını ve hızlı bir şekilde uyarlamasını sağlayacaktır. şirketinize sistem.

Sayı biçimlerine, alan adlarına, açılır listelerin varlığına veya yokluğuna, düğmelerin ve ipuçlarının davranışına ve veri türlerine dikkat ettiğinizden emin olun. Müşteri, CRM mantığına dahil edilmesi gereken kendi formüllerini kullanıyorsa ( örneğin, bayi ikramiyelerinin hesaplanması), bu formüller, tanımlarının tam açıklaması ve hesaplama mantığı ile yazılmalıdır.

Evet, kurumsal yazılım buna benziyor ve içinde birçok önemli küçük şey var.

Referans şartları açık ve net olmalıdır. Belirsiz ifadeler, uygulama seçenekleri, belirsiz gereksinimler - tüm bunlar bir çıkmaza giden yoldur. Bir müşteri, iyi niyet dışında, sistemin davranışı için yakın ancak eşdeğer olmayan birkaç seçenek TOR'a yazar. Bu durumda, yardım ettiğinden emindir, programcıyı yönlendirir, ancak aslında cehenneme giden yol iyi niyetlerle döşenmiştir; geliştirici tam olarak neye ihtiyaç olduğunu anlamalı ve bunu nasıl yapacağını kendi seçecektir. sistemin özellikleri ve kullanılan teknolojiler yığını.

Bu yıl yine bir dilek tutabilirsiniz. Sadece lütfen net iş gereksinimleri gibi benim bile karşılayamayacağım bir şey için boşa harcamayın!

Referans şartları insan dilinde yazılmalıdır. Ve bu önemli, hayır, ÖNEMLİ. Dille ilgili sorunların projenin uygulanmasında gecikmeye yol açtığı iki durumu seçeceğim.

1. Müşteri teknik okuryazarlığını göstermeye çalışır ve "takvimde bir pencere açılmalı" yerine "bir olay çağrısına tepki verebilen bir ipucu içeren bir pencereyi takvimin gövdesine uygulayın..." gibi yapıları çitler. görevi tamamlandı olarak işaretleyebileceğiniz yer”. Siz veya dahili uzmanınız teknik metinler yazma becerisine sahip değilseniz, google'a gitmeyin - sıradan kelimelerle yazın, onları anlıyoruz.

   Referans şartları bir şikayet kitabı olmamalıdır. Problemi çözmemiz gerekiyor, tarif etmemeliyiz, yazı tiplerine dikkat etmemiz ve gereksinimlerin açıklamasını unutmamız gerekiyor. TOR yalnızca sorunun kendisini değil, aynı zamanda anlama düzeyindeki çözümünü de içermelidir - o zaman geliştirici bunu zaten kod düzeyinde çözecektir. Karşılaştırmak “satış departmanı kötü plan yapıyor, sayıları kaybediyor, bir yıldır savaşıyoruz” Ve “Ürün grupları bağlamında aylık bazda planın değerlerini ve satış olgusunu kaydedecek bir rapor oluşturmak gerekiyor”.

   Referans şartları geleceğe bakabilmelidir. Tam olarak değil, ama arkasındaki insanlar. Yakın zamanda iş süreçlerinde değişikliklerin olacağı biliniyorsa, iki kez revizyon ücreti ödememek için bu dikkate alınmalıdır.

   Görev tanımları bürokratik olmamalıdır. Bu belgeyi daha önce hazırladıysanız, bürokrasiye kaymanın, giriş kelimeleri eklemenin, katı dönüşler eklemenin ve her bir maddeyi Ceza Kanununun bir maddesi olarak tanımlamanın (tercihen herkes için ceza ile) ne kadar zor olduğunu hissetmiş olmalısınız. ihlal). Bürokratik ifadeler, TK yaratma hedeflerinin eksik bir şekilde anlaşılmasını maskeler. Satıcının sorumluluğu sözleşmede yazılıdır, bütçesi de orada yazılıdır. Bu noktaları teknik göreve aktarmamalısınız.

   Referans şartları, referans şartları olmalıdır. Kulağa çelişkili gelebilir, ancak genellikle teknik şartnameler yerine mektupları, şikayetleri, sözleşmeleri, CRM için yeni yazılmış talimatları veya toplantı tutanaklarını okuruz. Tabii ki, böyle bir belge üzerinde çalışmak imkansız. Biçimden ve içerikten uzaklaşmamak için eski usül bir numarayı kullanın: terime kelimesi kelimesine bakın. Teknik, iyileştirmeyi dikte ettiği anlamına gelir, teknik, yazılımı değiştirerek sorunu çözmeyi amaçlar. Yazılım bağlamındaki görev budur ve konuşmanız gerekir. Bir görev, tavsiye, ipucu ve ön tahminler olmaksızın bir soru, bir problem ortaya koymak anlamına gelir. Sadece sorunun bir ifadesi.

   Emirler bitti, şimdi azar

   Yukarıdaki kurallara ek olarak, bahsetmeye değer birkaç şey daha var. Hedefler, planlar ve beklentilerden bahsediyoruz - projeyi başarılı kılan tüm ayrılanlar ve satıcı ile müşteri arasındaki ilişki neredeyse arkadaşça.

   Görev tanımlarının hızlı bir şekilde yazılması gerekiyor, bir mobil operatörün veya büyük bir hipermarketin süreçlerini otomatikleştirme görevi ile karşı karşıya kalsanız bile. Bunun nedeni, teknolojilerin muazzam bir hızla gelişmesi ve uyguladığınız sistemin bile altı ay veya bir yıl içinde büyük bir sürümde (ve bazen iki) hayatta kalabilmesi, yeni işlevler kazanmasıdır. İyileştirme ihtiyacını yeniden gözden geçirmek ve süreci yeniden başlatmak gerekebilir.

   

   
   Sonunda TK'yi bitirmek için zaman buldu. Ama ne yazık ki, onu uygulayacak geliştirici kalmadı.

   İstemci yığından ve teknik sınırlamalardan habersizdir. Ve bilmemeli - bu satıcının görevidir, referans şartlarını hazırladıktan sonra işi değerlendiren kişidir. Müşteri, teknolojiyi araştırmamalı ve her virgülle satıcının şunu veya bunu yapıp yapamayacağını sormamalıdır. Kapsamlı bir TOR hazırlayın ve geliştirici uygun mimariyi seçecektir - genellikle düşündüğünüzden daha iyi.

   Bütçenizi tahmin edin ve hoş olmayan sürprizlerden kaçının- neredeyse bir numaralı ortak görev. Satıcıyı çekmemeli ve ondan işin yaklaşık bir değerlendirmesini talep etmemelisiniz (en azından yaklaşık olarak, hazırlıksız, gözle, ancak diğerleri gibi, bu tür projelerde, ancak deneyimden, iyi, iyi, hata payı). Tam bir bütçe tahmini, ancak görev tanımlarının okunması, analizi ve nihai onayından sonra mümkündür. Geliştiriciniz aksini yaparsa, revizyonun en az iki katına mal olacağı gerçeğine hazır olun.

   Değişiklikler ve genişlemeler için nesnel ihtiyaçtan ilerleyin- Geliştiricinin kaybolmadığını ve her an ihtiyaçlarınıza göre değişiklik ve eklemeler yapmaya hazır olduğunu yukarıda yazdım. Bu nedenle hemen CRM/ERP hayalleri oluşturmaya çalışmayın, satıcıdan “Ben kahve içerken her şey çalışıyor” butonunu talep etmeyin - sistemde çalışın, sizin için kritik yorumları belirleyin ve gereksinimleri toplamaya ve teknik şartnameleri oluşturmaya başlayın. .

   Teknik görevler hakkında durmadan yazabilirsiniz, bu sadece mem ve masalların değil, aynı zamanda baş ağrısının da gerçek bir üreticisidir. Öncelikler ve tasarım kuralları hakkında, TK'yi insanlık dışı yapan GOST 1989 hakkında, biraz daha iyi olan IEEE standartları hakkında, prototipler ve bunları tamamlayan TK hakkında konuşabilirsiniz. Ama sonunda, kendimi en önemli kuralla sınırlamak istiyorum: görev tanımı bir hukuk kuralı, GOST veya dogma değildir, bu nedenle, iyileştirebilirseniz - iyileştirebilir, basitleştirebilirsiniz - basitleştirin, zarafetle yapabilirsiniz ve böylece herkes onu sever - yapın. Bundan sonra kimsenin TK'ye burnunu sokmayacağına ve bunun orada yazılmadığına eminim. Ya da neredeyse hiç kimse.

   Aralık ayı boyunca RegionSoft CRM ve kendi geliştirdiğimiz tüm yazılımlar için indirimler yapıyoruz. 1 Aralık - 15 Aralık - %15 ve serin taksit ve kiralama koşulları. Lisanslar için ekonomik olarak haklı bir fiyat tuttuğumuz ve tavandan almadığımız için -%70 ve -%90'ımız yok.

   Pekala, bir CRM sistemine ihtiyacınız varsa (değişiklik olsun veya olmasın), o zaman şuraya gidin: web sitemiz, CRM, faydaları ve diğer kurumsal yazılımlar hakkında çok şey var.

   Ve evet, her zaman CRM ve diğer ürünleri satmaya, CRM'yi geliştirmeye ve satmaya, yazılım satmaya ve kullanıcıları eğitmeye hazır ortaklar arıyoruz. Gelir dağılımı adil ve ortak için faydalıdır. Göster, anlat, öğret. yaz [e-posta korumalı]

   Slaytlar, slaytlar. http://www.modernanalyst.com/ ve Pinterest'ten alınan çizgi romanlar. Daha iyi bir çeviri varsa, gönderiye eklemekten memnuniyet duyarız.

Uzmanlarımız, müşterinin Havalandırma sisteminin modernizasyonu için referans şartları.

Daha fazla detay kesimin altında..

teknik görev

451.452 numaralı laboratuvar binasının havalandırma sistemleri için teknolojik ekipmanların modernizasyonu için şu adreste bina 17: Moskova

1. Genel Hükümler

1.1. Bu görev tanımı, teknolojik ekipmanın modernizasyonu, binanın havalandırma ünitelerinin kontrol sistemleri ve otomasyonu, 17 numaralı binanın 451.452 numaralı laboratuvarları ile ilgili çalışmaların uygulanmasını sağlar.

1.2. İş yapmak için, öngörülen şekilde üzerinde anlaşmaya varılması gereken AOV, EM, KhS, AHS, AK markalarının bölümleri için çalışma belgeleri geliştirin.

1.3. Çalışmaları düzenleyici ve teknik belgelerin gerekliliklerine uygun olarak gerçekleştirin.

1.4. İşin tamamlanmasından sonra, GOST ve SNiP gereksinimlerine uygun olarak hazırlanmış belgeleri gönderin.

1.5. Tamamlanan çalışmayı müşteriye gönderin.

1.6. Bu İş Tanımının belirli hükümleri, Müşteri ile mutabık kalınan çalışma sürecinde belirtilebilir.

2. Teknik gereksinimler

2.1. Havalandırma ünitelerinin ısı ve soğuk beslemesi için kontrol ünitelerinin modernizasyonu.

2.1.1. Isı kaynağı düzenleme düğümleri.

Modernizasyon şunlara tabidir:

· Laboratuvarın MIK-V, P2, P6 binalarının havalandırma ünitelerinin K1, K2, K2a, K4 ilk ısıtması için ısı kaynağı kontrol üniteleri, laboratuvarın 452, P1 numaralı laboratuvarı.

· MIK-V binasının K1, K2, K2a havalandırma ünitelerinin ikinci ısıtması için ısı besleme kontrol üniteleri.

Mevcut ısı beslemesi kontrol üniteleri sökülmeye tabidir ve kontrol ünitelerinin ekipmanının (sirkülasyon pompaları, kapatma vanaları), durum ve teknik özelliklere karşılık gelen bir kısmı monte edilmiş kontrol ünitelerinde kullanılacaktır.

Monte edilmiş kontrol ünitelerinin ekipmanının yanı sıra kullanılan ekipmanın bileşimi Ek No. 1'de belirtilmiştir.

Hidrolik test raporunun yürütülmesi ile havalandırma ünitelerinin ısıtma devrelerinin ve ısıtıcılarının hidrolik testlerini gerçekleştirin.

Boru hatlarının boyanması ve ısı yalıtım işlerinin yapılması.

2.1.2 Havalandırma ünitelerinin soğutma beslemesini düzenlemek için düğümler.

MIK-V'nin K1, K2, K2a, K4 havalandırma üniteleri için soğutma üniteleri, 451 No'lu laboratuvarın “452, P1” laboratuvarının binaları modernizasyona tabidir.

İşin kapsamı:

· soğutma kontrol ünitelerinin termostatik vanalarının değiştirilmesi;

Kompresör yoğuşmalı ünite K1 fanının sökülmesi/kurulması;

· kompresör-yoğuşmalı blokların K1, K2 filtre-kurutucularının sökülmesi/kurulması;

K4 havalandırma ünitesinin evaporatörünün sökülmesi/kurulması;

· İnert gaz ortamında basınç testi, vakumlama, freon ile soğutma devrelerinin yeniden doldurulması;

Boru hatlarının ısı yalıtımının restorasyonu.

2.1.3. Nemlendirme devreleri için besleme üniteleri.

K1, K2, K2a klimalarının sulama odalarının besleme ünitelerine soğuk su arıtma filtreleri takın.

2.2. Havalandırma tesisatlarının kontrolü ve otomasyonu için dolaplar.

451, P1 numaralı laboratuvarın MIK-V, P2, P6, V1, V2, V3 binalarının havalandırma üniteleri K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8 için kontrol kabinleri 452 numaralı laboratuvarın V1'i.

Yeni kurulan kontrol panellerinin yerleşimi:

SHUA K1 - klima K1'in (MIK-V) havalandırma ünitesinin ve kompresör ve kondenser ünitesinin (KKB) kontrol kabini ve otomasyonu;

SHUA K2 - havalandırma ünitesinin kontrol kabini ve otomasyonu ve KKB klima K2 (MIK-V);

SHUA K2 - havalandırma ünitesinin kontrol kabini ve otomasyonu ve KKB klima K2a (MIK-V);

SHUA K4 - havalandırma ünitesinin kontrol kabini ve otomasyonu ve KKB klima K4 (MIK-V);

SHUV - RU3, V1, V2, V3, V6, V7, V8 (MIK-V) egzoz üniteleri için kontrol kabini;

ShUA P2, P6 - havalandırma ünitelerinin ve kompresör ve kondenser ünitelerinin P2, P6 (laboratuvar No. 452) kontrol kabini ve otomasyonu;

SHUV - V1, V2, V3 egzoz üniteleri için kontrol kabini (laboratuvar No. 452);

SHUA P1, V1 - P1, V1 (laboratuvar No. 451) havalandırma ünitelerinin kontrol panosu ve otomasyonu.

Modernize edilmiş kontrol kabinleri şunları sağlamalıdır:

kabinin ön panelinden havalandırma ünitesi kontrol modunun seçimi (manuel/otomatik);

· Havalandırma ünitelerinin teknolojik ekipmanlarının (çalışma/kaza) düzenli ve acil durum çalışma modlarının ışıklı sinyalizasyonu;

yangın durumunda havalandırma sistemlerinin kapatılması;

acil durumlarda korumaların otomatik çalışması ve ekipman çalışmasının engellenmesi.

Fanların ve pompaların elektrik motorlarını kontrol etmek için frekans dönüştürücüler ayrıca kullanılacaktır.

2.3. Otomasyon ve sevk sistemi

Otomasyon ve sevk sistemi, havalandırma ünitelerinin çalışmasını yönetmek ve kontrol etmek ve ayrıca gelen bilgileri toplamak, işlemek, sunmak ve depolamak için tasarlanmıştır.

2.3.1. Otomasyon sistemi.

Otomasyon sistemi genel olarak havalandırma ünitelerinin bakım personelinin müdahalesini gerektirmeyen otonom çalışmasını ve gerekirse manuel kontrol moduna geçişi sağlamalıdır. Herhangi bir kontrol seçeneği ile ve yerel kontrolörün durumundan bağımsız olarak, yangın durumunda genel havalandırma sisteminin otomatik olarak kapatılması koşulu sağlanmalıdır. Kapatma, donma önleyici devrelere giden güç kaynağı korunurken her sistem için ayrı ayrı gerçekleştirilmelidir.

Havalandırma sistemlerinin yerel otomasyonu şunları içermelidir:

havalandırma ünitesinin çıkışındaki besleme havasının sıcaklığının veya gerekirse servis verilen binadan çıkan egzoz havasının sıcaklığının düzenlenmesi;

besleme havası neminin düzenlenmesi;

bir yangın alarmı tetiklendiğinde fanları durdurun ve hava valflerini kapatın;

Fanı durduğunda klimanın nemlendirmesini kapatmak;

Fanı çalıştırırken ve durdururken sırasıyla hava valfinin açılması ve kapanması;

· Kış modunda sistemlerin çalıştırılmasından önce ısıtıcıların otomatik olarak ısıtılması;

· Isıtıcıların hava ve su ile donmasına karşı koruma (fanı kapatma, hava damperini kapatma, ısıtma vanasını %100 açma);

basınç farkı olmadığında fanın kapatılması;

· Tesislerin filtrelerinin kirliliğinin kontrolü.

İş istasyonları ile yerel otomasyon üzerindeki uzaktan etki, aşağıdaki hacimde belirlenir:

· sıcaklık ve nem kontrolörlerinin ayarlarının değiştirilmesi;

· ayarları etkinleştir/devre dışı bırak.

Otomasyon sisteminin mevcut çevresel ekipmanı, aşağıdaki sırayla doğrulama, temizleme ve daha fazla kullanıma tabidir:

· Havalandırma ünitelerinin sıcaklık ve nem sensörleri doğrulamaya tabidir;

· Fark basınç anahtarı sensörleri kontrol edilmeli, temizlenmeli;

· Hava ısıtıcılarını donmaya karşı koruyan termostatlar değiştirilmelidir.

· Kontrol ünitelerinin kontrol vanalarının aktüatörleri madde 2.1.1'e göre değiştirilmelidir.

hava valfi aktüatörleri incelemeye ve daha fazla kullanıma tabidir;

K1 klimasının devridaimini kontrol etmek için hava valflerinin açma-kapama aktüatörlerini 0..10V kontrol sinyaline sahip valflerle değiştirin.

2.3.2. sevk sistemi.

Aşağıdaki bileşenleri sevk sistemine dahil edin:

"Honeywell" yazılım ve donanım araçlarına dayalı bir ölçüm cihazları, aktüatörler ve otomasyon araçları kompleksi;

· çok işlevli kablo sistemi;

· kontrol odasının bir yazılım ve donanım araçları kompleksi.

Havalandırma sistemlerini kontrol etmek için aşağıdaki bilgilerin görüntülenmesini, arşivlenmesini ve günlüğe kaydedilmesini sağlayın:

· sıcaklık ve nem sensörleri, donma önleyici termostatlar, diferansiyel basınç anahtarları, kontrol valfleri, hava nemlendiriciler, hava valfleri içeren tesisatların grafik gösterimi;

kurulum numaraları;

sıcaklık ve nem sensörlerinin okumaları;

fark basınç rölesi sensörlerinin okumaları;

kontrol valflerinin konumunun göstergeleri %0,.100;

fan çalışması/durdurma modu;

· pompaların "çalışma / durdurma" modu;

hava valflerinin "açık / kapalı" konumu;

bir yangın alarmı tetiklendiğinde sistemleri durdurun;

ısıtıcının donma tehdidi olduğunda sistemlerin kapatılması;

fan boyunca basınç düşüşü olmadığında ünitenin kapatılması;

Klima fanı durduğunda hava nemlendiricinin kapatılması;

Sistemlerin belirli bir zaman çizelgesine göre veya onsuz çalışması;

· Ekipman arızası durumunda kazaların ve acil durumların bildirilmesi ve ayrıca - belirtilen aralıkların dışındaki proses parametreleri değerlerinin çıkışı;

kazaların ve acil durumların mesaj günlüğüne kaydedilmesi;

· Kontrol edilen parametrelerin adını, ölçü birimlerini, kontrolör numarasını ve giriş/çıkış kanalını gösteren geçerli zaman için parametre kayıt günlüğü.

2.3.3. Otomasyon ve sevk sisteminin güç kaynağı, 380/220 V gerilimli, 50 Hz frekanslı AC şebekeden, akülerde kesintisiz güç kaynakları kullanılarak ve birinci kategorideki güç tüketicileri için güç kaynağı olarak sağlanmalıdır.

Geliştiricilere verilen görevlerin çözülüp çözülmeyeceği, 1C'yi sonlandırmak için referans şartlarının ne kadar doğru bir şekilde hazırlandığına doğrudan bağlıdır. Ancak, böyle bir belgeyle çalışırken bazı zorluklar vardır. Geniş anlamda, TOR, otomatik bir sistemin (AS) oluşturulması ve modernizasyonu için normların yanı sıra çalışma prosedürünü de belirler. Bu aynı zamanda bir dizi proje başlatma standardını da içerir. Referans şartlarının rolüne ilişkin bu anlayış, 1C için TOR'un geliştirildiği GOST 19.201-78 ve 34.602-89 gereklilikleri tarafından belirlenir. Bu belgenin anlamının uygulamaya daha yakın başka bir yorumu var.

Başka bir tanıma göre, 1C'yi sonuçlandırmak için referans şartları, gelecekteki sistemin amacını ve parametrelerini, ayrıca dokümantasyon geliştirme sürecini ve listesini düzenleyen bir belgedir. Bu yorum, programcıların ve müşterinin çıkarlarının dikkate alınmasını sağlar.

TK ne olmalı?

1C programının geliştirilmesi için herhangi bir teknik görev, yüklenici tarafından oluşturulur. Ancak bu bir programcı değil, bir analisttir. Bu önemli bir noktadır, çünkü belge, çok özel teknik terimler olmaksızın müşterinin anlayacağı bir dilde yazılmalıdır. Projenin tüm nüansları dikkate alındığında ve bilgiler doğru formüle edildiğinde, tüm müşterilerle TOR üzerinde anlaşmaya varılır. Kabul edilirse programcılar işin içinde yer alır. Aynı zamanda, istenen sonuç belgede açıkça belirtilmelidir. Bu, geliştiricilerin doğru hedefi belirlemesine ve farklı aşamalarda bunu kontrol etmesine yardımcı olur. Ayrıca, 1C'yi sonuçlandırmak için görev tanımlarını hazırlarken, ifadelere çok dikkat edilmelidir. Yeterince spesifik olduklarından ve başka yorumlar içermediğinden emin olmak için özen gösterilmelidir. TK ile çalışırken hatırlanması gereken ilk şey budur. Ayrıca tasarıma sorumlu bir yaklaşım sergilemeniz gerekir. Bu, belgenin başlık sayfası için de geçerlidir.

1C'nin geliştirilmesi için referans şartlarındaki ana hatalar

Referans şartlarının yapısı GOST 34.602-89 tarafından düzenlenir. Bu belge, TOR'daki bilgi bloklarının sayısı ve sırası için açık gereksinimleri içerir. Aynı zamanda, sunum yöntemleri için katı standartlar yoktur. Bu durum, karmaşık problemlerin çözümü için büyük bir potansiyel barındırmakta ve aynı zamanda belgenin hazırlanmasında birçok hataya yol açabilmektedir. En yaygın yanlışlıklar şunlardır:

1. Bazı bölümlerin farklı yorumlarda tekrarı.
2. Bilgiler rastgele verilir. İ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, değişen derecelerde ayrıntıyla sunulur.

Bütün bunlar müşterinin TOR'da belirtilen bilgileri anlamasını engeller. Bu, işbirliği sürecini karmaşıklaştırarak daha fazla zaman alıcı hale getirir.

Müşteri tarafından görüntülendikten sonra, 1C revizyonu için örnek TOR değişebilir ve her zaman daha iyisi için olmayabilir. Bu da genellikle programcıların bilgileri doğru algılamasını engeller. Bu özellikle az deneyime sahip uzmanlar için geçerlidir. Bu aşamada, genellikle aşağıdaki hatalar oluşur:

1. Farklı bölümlerin gereksinimleri birbiriyle çelişir.
2. Formüller hatalı.
3. Bazı yerlerde bilgiler çok ayrıntılı.

Tüm bu hatalardan kurtulmak kolaydır. Her şeyden önce, dikkatli bir şekilde reçete edilen formülasyonlara değil, sonuca odaklanmak gerekir. TOR'un projenin işlevselliğini, ana parametrelerini ve amacını tanımladığını hatırlamakta fayda var.

Teknik şartnamelerin geliştirilmesinde hatalardan nasıl kaçınılır?

Sonraki tüm öneriler için geçerli olan ana kural, ifadenin spesifik olması gerektiğidir. Bunu yapmak için, GOST'lere, diğer düzenleyici belgelere bağlantılar kullanmanız gerekir. Bu, yüklenici ve müşterinin bilgileri aynı şekilde algılamasını sağlar.

1C'yi sonuçlandırmak için teknik bir görevin bir örneği, projenin uygulandığı iş endüstrisinin dilinin kullanımını içerir. Bu, her şeyden önce müşteri için gereklidir. Aynı zamanda, farklı şekillerde yorumlanabilecekleri için metinde herhangi bir karşılaştırma kullanmamalısınız.

Bir raporun ve 1C'nin diğer unsurlarının geliştirilmesi için referans şartları hazırlarken temel kurallar:

1. TK, yüklenici ve müşteri tarafından ortaklaşa oluşturulur.
2. Programcıların çalışmalarına yalnızca nesnel gereksinimler sunulmalıdır. Başarılı proje geliştirme için müşterinin öznel vizyonu minimumda tutulmalıdır.
3. Müşterinin ihtiyaç duyduğu sonucu ayrıntılı olarak açıklamak gerekir. Aynı zamanda, 1C konfigürasyonunun geliştirilmesi için referans şartları örneğinde, elemanın çalışması gereken tüm parametreleri belirtmek gerekir. Aksi takdirde, sonuç istenenden çok farklı olabilir.
4. Yüklenici ve müşterinin riskleri yaklaşık olarak eşit olmalı ve minimuma indirilmelidir.
5. İş iletişiminde kullanılan ve belirli bir sektörde kullanılmayan terimleri kullanamazsınız.

1C'de veya başka bir öğede bir raporun geliştirilmesi için bir TOR oluşturmak için analist, müşterinin faaliyet alanının tüm özelliklerini bilmelidir. Gereksinimlerde, yalnızca sanatçı için yararlı olan yararlı bilgiler vermeniz gerekir. Burada yazılımın çözmesi gereken son görevlere özel bir dikkat gösterildiği göz önüne alındığında, teknik bir görevin tek bir örneği yoktur.

TOR'un yanlış hazırlanması tehlikesi

Yukarıda listelenen hatalar, bir sistem oluşturmak için gereken sürenin artmasına neden olabilir. Bu gereksiz maliyetler ve memnuniyetsizliği beraberinde getirir. Bir veritabanının veya diğer 1C konfigürasyonunun geliştirilmesi için referans şartları deneyimli uzmanlar tarafından hazırlanmalıdır. Tüm katılımcıların yararı, bu belgenin ne kadar anlaşılır olduğuna bağlıdır. Müşteri, iş sorunlarını çözmek için etkili bir otomatik sistem alır. Aynı zamanda, yüklenicinin başka bir memnun müşterisi var. 1C ortak şirketlerini seçerken işletme sahiplerinin mümkün olduğunca dikkatli olmaları gerekir, çünkü organizasyonun etkinliği büyük ölçüde revizyon için referans şartlarının ne kadar iyi hazırlandığına bağlıdır.

Pavel Molyanov

Murphy yasasını hatırlıyor musun? Yanlış anlaşılabiliyorsanız, yanlış anlaşılmaya mahkumsunuz. Bu sadece insanlar arasındaki iletişimde değil, sitelerin oluşturulmasında da geçerlidir. Müşteri ikinci bir Facebook istedi, ancak genç köpek yetiştiricileri için bir forum buldu. Geliştirici, müşterinin İstek Listesini tahmin etmedi - zamanını boşa harcadı.

Bu kılavuzda, referans şartlarında neyi ve neden yazmanız gerektiğini size anlatacağım. Aynı zamanda teknik şartname oluşturmanın zaman kaybına dönüşmemesi için nasıl yazılmaması gerektiğini de göstereceğim.

Makale faydalı olacaktır:

• Sitelerin oluşturulmasıyla ilgili herkes: geliştiriciler, tasarımcılar, düzen tasarımcıları.
• Proje yöneticileri.
• Dijital stüdyoların başkanları.
• Sitenin geliştirilmesini sipariş etmeyi planlayan girişimciler.

Malzemeyi uygulanabilir kılmak için çeşitli geliştiricilerden, tasarımcılardan, proje yöneticilerinden ve dijital stüdyo sahiplerinden yorumlar topladım. En değerlileri yazının sonuna eklenmiştir. Hadi çözelim.

Spesifikasyon nedir ve neden gereklidir?

Referans şartları, site gereksinimlerinin sabitlendiği bir belgedir. Bu gereksinimler ne kadar net ve ayrıntılı olursa, süreçteki tüm katılımcılar nasıl olması gerektiğini o kadar iyi anlar. Bu, sonuçtan herkesin memnun kalma şansının arttığı anlamına gelir.

Görev tanımının temel amacı, müşteri ve icracının birbirini doğru anlamasını sağlamaktır.

Teknik özelliklerin birçok faydası vardır. Her tarafın kendi vardır.

Müşteri için fayda:

• Ne için para ödediğini ve sitenin nasıl olacağını anlayın. Yapıyı hemen görebilir, neyin nasıl çalışacağını anlayabilirsiniz. Her şeyin size uygun olup olmadığını anlayın. Değilse - geliştirme başlamadan önce değiştirmek sorun değil.
• Sanatçının yetkinliğine bakın. Başvuru şartları anlaşılır ve net ise geliştiriciye olan güven artar. Orada yulaf lapası yazıyorsa, koşmaya ve geriye bakmamaya değer olabilir.
• Sanatçının sahtekârlığına karşı sigortalamak. Site hazır olduğunda referans şartlarına göre kontrol edilebilir. tutarsızlıklar var mı? Geliştirici bunları düzeltmelidir. Resmi olarak işbirliği yaparsanız ve bir anlaşmaya girerseniz, mahkemelerde bile zorlanabilirsiniz.
• Oyuncuların değiştirilmesini basitleştirin. Müşteri ve geliştirici tartışıp kaçtıysa, sitenin oluşturulması uzun zaman alabilir. Ayrıntılı bir görev tanımı olduğunda, yeni bir ekibe aktarılabilir - işe birçok kez daha hızlı dahil olur.
• Karmaşık bir ürün geliştirmenin maliyetini öğrenin. Karmaşık bir web hizmeti geliştirmenin tam zamanlamasını ve maliyetini hemen tahmin etmek imkansızdır. Öncelikle hizmetin nasıl çalışacağını ve hangi işlevlere sahip olacağını anlamanız gerekir. Bunu yapmak için teknik bir görev hazırlamanız gerekir.

Sanatçı için faydaları:

• Müşterinin ne istediğini anlayın. Müşteriye onlarca soru sorulur, örnekler gösterilir, çözümler sunulur. Sonra her şey tek bir belgeye yazılır ve koordine edilir. Her şey yolundaysa - şerefe, doğru anladınız.
• Müşterinin ani İstek Listesine karşı sigorta yapmak. Bazen işi yarıda bırakmak isteyen müşteriler vardır. TOR'u kabul edip imzaladıysanız, bundan korkmuyorsunuz. Bu durumda mahkeme bile sizin tarafınızda olacaktır.
• Yetkinliğini göster.İyi hazırlanmış bir iş tanımı, müşteriye geliştiricilerin uzmanlığını gösterecektir. Şirket, sitenin geliştirilmesi konusunda size güvenip güvenmeyeceğinden şüphe ederse, şüphelerin ortadan kalkması muhtemeldir.
• Para kazanmak. Bazı stüdyolar ve geliştiriciler, teknik özelliklerin hazırlanmasını ayrı bir hizmet olarak sunar.

• Geliştirme sürecini kolaylaştırın ve hızlandırın. İyi bir TOR, sitenin yapısını, her sayfada gerekli işlevleri ve öğeleri gösterir. Tüm gereksinimler gözünüzün önündeyken, geriye sadece kodu tasarlamak ve yazmak kalıyor.

Şimdi tüm bu işlevleri yerine getiren iyi bir TOR nasıl yazılır çözelim.

Görev tanımı icracı tarafından yapılır

Genel olarak, herkes teknik bir görev yapabilir. “Diş kliniği için bir kartvizit web sitesine ihtiyacımız var” - bu zaten teknik bir görevdir. Ama görevini yapacak mı? Zorlukla.

İyi bir TOR her zaman bir oyuncu tarafından yapılır: bir proje yöneticisi veya bir geliştirici. Açıkçası, bir web geliştiricisi, bir kafe veya diş kliniğinin sahibinden daha web siteleri oluşturma hakkında daha fazla bilgi sahibidir. Bu nedenle, projeyi açıklamak zorunda kalacak.

Bu, müşterinin ortadan kaybolduğu ve en sonunda "Zbs, onaylıyorum" yazmak için göründüğü anlamına gelmez. Ayrıca sürece katılmalıdır:

Elbette müşteri kendi TK versiyonunu çizebilir. Belki de bu, nihai görev tanımının oluşturulması sürecini hızlandıracaktır. Ve belki de sessizce çöp kutusuna atılan çöp olduğu ortaya çıkacaktır.

Açık ve net yazın

Bu tavsiye, referans şartlarının ana hedefinden kaynaklanmaktadır - "Müşteri ve yüklenicinin birbirini doğru anladığından emin olun."

Referans şartları yüksek kaliteli sıfatlar içermemelidir: güzel, güvenilir, modern. Açıkça anlaşılamazlar. Herkesin kendi güzellik ve modernlik kavramları vardır.

Bakmak. Sonuçta birisi bu tasarımın güzel olduğunu düşündü ve web sitesinde kullanılmasına izin verdi:

Aynı şey - kendi başına hiçbir şey ifade etmeyen geveze ifadelerle:

• Site müşteri tarafından beğenilmelidir. Ya kötü bir ruh halindeyse?
• Site kullanıcı dostu olmalıdır. Bunun anlamı ne? Ne için uygun?
• Site ağır yüklere dayanmalıdır. 10 bin ziyaretçi? Yoksa 10 milyon mu?
• Kaliteli uzman içerik. Pekala, fikri anladın.

Metindeki belirsizlikleri kontrol edin. Varsa - yeniden yazın. İfadeleriniz açık ve kesin olmalıdır:

• Site hızlı yüklenmeli → Sitenin herhangi bir sayfasında Google PageSpeed ​​Insights'ta 80'den fazla nokta bulunmalıdır.
• Büyük yükler → aynı anda 50 bin ziyaretçi.
• Ana sayfa makalelerin bir listesini görüntüler → Ana sayfa, yayınlanan son 6 makalenin bir listesini görüntüler.
• Minimalist kullanıcı dostu abonelik arayüzü → Bir e-posta alanı bırakın ve Abone ol düğmesi → *çizimli kroki*.

İfadeyi çözdük, yapıyı gözden geçirelim.

Genel bilgileri girin

Tüm ekip üyeleri, şirketin ne yaptığını ve hedef kitlesinin kim olduğunu doğru bir şekilde anlamalıdır. Kimsenin kafasını karıştırmamak için, onu referans şartlarının en başında yazmak daha iyidir.

Ayrıca, blog yerine çevrimiçi mağaza almamak için sitenin amacını belirtmeye ve işlevselliğini kısaca açıklamaya değer.

Zor terimleri açıklayın

Görev tanımının ilk kuralı, amaçlanan herkes için açık olması gerektiğidir. Bir çocuk oyuncak mağazası sahibi olan müşterinizin anlamayabileceği terimler kullanacaksanız, bunları açıkladığınızdan emin olun. Düz bir dilde, Wikipedia'dan kopyala-yapıştır değil.

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

2 aydır harika bir web sitesi yaptığınızı hayal edin. Her aşama müşteri ile koordine edildi - çok memnun. Ve şimdi işi teslim etme zamanı. Yönetici panelini gösteriyorsunuz ve müşteri bağırıyor: “Bu nedir? Modeks?! WordPress'te yapacağını düşünmüştüm!”

Bu tür sorunlardan kaçınmak için kullanılan araçları, motorları ve kitaplıkları tanımlayın. Aynı zamanda, barındırma için gereksinimleri belirtin. Bunu asla bilemezsiniz, PHP'de yapacaksınız - ve istemcinin .NET'te bir sunucusu var.

Site için gereksinimleri listeleyin

Site, güncel sürümlerin tüm tarayıcılarında ve her tür cihazda çalışmalıdır. Evet, bu herhangi bir geliştirici ve herhangi bir müşteri için açıktır. Ancak müşteriyi dürüst olmayan bir şekilde yapılan işlerden korumak için yazmak daha iyidir.

Gereksinimleri buraya yazın. site yükleme hızı, yüklere karşı direnç, hacker saldırılarına karşı koruma ve benzeri şeyler.

Site yapısını belirtin

Tasarım ve yerleşimi çizmeden önce, müşteri ile sitenin yapısı üzerinde anlaşmanız gerekir.

Müşteriyle sohbet edin, neye ihtiyacı olduğunu öğrenin. Geliştiricileri, SEO'ları, pazarlamacıları, baş editörleri toplayın ve sitede hangi sayfaların gerekli olduğuna karar verin. Nasıl birbirine bağlanacaklarını, hangisinden geçiş yapabileceğinizi düşünün.

Yapıyı liste halinde gösterebilir, blok diyagram çizebilirsiniz. Tercih ettiğiniz gibi.

Bu, sitedeki çalışmanın en önemli aşamalarından biridir. Yapı temeldir. Başarısız olursa, sitenin çarpık olduğu ortaya çıkacaktır.

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

Müşteri, her sayfanın neden gerekli olduğunu ve üzerinde hangi öğelerin olacağını anlamalıdır. Bunu göstermenin iki yolu vardır.

Prototip- daha görsel ve net bir yol. Yüklenici, her sayfanın eskizlerini çizer ve bunları iş tanımına ekler. Müşteri, gelecekteki sitesinin arayüzünün nasıl görüneceğini görür ve neyi beğendiğini ve nelerin değiştirilmesi gerektiğini söyler.

elemanların numaralandırılması prototipe tembel bir alternatiftir. Sayfada hangi blokların olması gerektiğini ve ne yaptıklarını yazmanız yeterlidir.

Siteyi kullanmak için senaryolar yazın

Bir tür standart dışı arayüz yapıyorsanız, sadece yapıyı ve sayfa küçük resimlerini göstermek yeterli değildir. Tüm uygulama ekibinin ve müşterinin, ziyaretçilerin siteyi nasıl kullanacağını anlaması önemlidir. Senaryolar bunun için harika. Komut dosyası taslağı çok basittir:

• Kullanıcı eylemi.
• Web sitesi yanıtı.
• Sonuç.

Elbette standart bir kartvizit veya açılış sayfası yapıyorsanız script yazmanıza gerek yoktur. Ancak sitede bazı etkileşimli hizmetler varsa, bu çok arzu edilir.

Vikipedi'de kullanım örnekleri hakkında daha fazla bilgi edinin.

İçerikten kimin sorumlu olduğunu belirleyin

Bazı geliştiriciler hemen içerikle bir site yaparlar. Balıkları başkaları koyar. Yine de diğerleri metin yazabilir, ancak ek bir ücret karşılığında. Bu konuda kıyıda anlaşın ve referans şartlarında hangi içeriği hazırlamanız gerektiğini belirleyin.

Metinlerin kalitesini değerlendirmek için nesnel kriterler bulmak oldukça zordur. "Hedef kitle için yararlı olan yüksek kaliteli, ilginç ve satan içerik" dışında bir şey yazmamak daha iyidir. Çöp, kimsenin ihtiyacı yok.

Tüm içeriğin benzersiz olması gerektiğini belirtmek faydalıdır. Müşterinin vicdansız sanatçılardan başka bir koruması.

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

Metinde olduğu gibi, objektif değerlendirme kriterleri site tasarımı bulmak zor. Siz ve müşteri bir renk şeması üzerinde anlaştıysanız, bunu bir yere yazın. Yazı tiplerinin kayıtlı olduğu bir marka kitabı varsa, bunları da belirtin.

Güzel ve modern tasarım hakkında yazmaya gerek yok. Hiçbir anlamı yok, gücü yok ve genelde fu.

Sonuç yerine: görev tanımının yapısı

Farklı görevler için TOR'un yapısı farklı olacaktır. Yeni bir sosyal ağ için aynı teknik özellikleri ve toptan havuç için bir açılış sayfası yapmak aptalca. Ancak genel olarak, bunun gibi bölümlere ihtiyacınız var:

• Şirket ve hedef kitle hakkında bilgiler, sitenin amaç ve hedefleri.
• Müşteri tarafından anlaşılmayabilecek terimler sözlüğü.
• Sitenin düzeni ve çalışması için teknik gereksinimler.
• Kullanılan teknolojilerin tanımı ve barındırma gereksinimleri listesi.
• Ayrıntılı site yapısı.
• Sayfaların prototipleri veya üzerlerinde olması gereken öğelerin açıklamaları.
• Standart olmayan bir arabirim (isteğe bağlı) kullanma senaryoları.
• Geliştiricinin yaptığı içeriğin listesi.
• Tasarım gereksinimleri (isteğe bağlı).

• Yazılım Gereksinimleri Belirtimini derleme kuralları. SRS, görev tanımlarının gelişimindeki bir sonraki adımdır. Büyük ve karmaşık projeler için gereklidir.
• Yazılım geliştirme için TOR standartları ve şablonları. Teknik şartname oluşturmak için çeşitli GOST'lerin ve metodolojilerin açıklamaları.

Bu yazdığım bölümün sonu. Ancak bir tane daha var - kılavuzun hazırlanmasına yardımcı olan uzmanların yorumları. Okuyun, ayrıca ilginç.

Geliştirici Yorumları

Özellikleri nasıl yazdıklarını öğrenmek için birkaç geliştiriciyle konuştum. Mikrofonu onlara veriyorum.

Her şeyden önce, müşterinin TK'ye ihtiyacı var - böylece sitesinin nasıl olacağını ve paranın neye harcandığını anlıyor. Bir şey yanlış yapılırsa, TK'ye başvurabilir ve yeniden yapılmasını isteyebilir.

TOR, müşteri ile iletişim kurduktan ve görevi tasarımcıyla tartıştıktan sonra proje yöneticisi tarafından derlenir.

Büyük müşteriler genellikle her bir düğmeyi açıklayan çok ayrıntılı özellikler ister. Küçük şirketler ise tam tersine 100 sayfalık titiz belgeleri sevmezler. Uzun bir okuma ve önemli bir şeyi kaçırmak kolay. Daha sık olarak, 10-15 sayfalık kısa teknik spesifikasyonlar yaparız.

Belirtiyoruz:

• Şirket ve sitenin amacı hakkında bilgiler.
• Tasarım gereksinimleri, renkler.
• Kullanılan teknolojiler ve CMS.
• İçerikle kim ilgileniyor - biz veya müşteri.
• Her sayfaya kadar site yapısı.
• Her sayfanın açıklamaları. Prototip yapmıyoruz ama sayfada hangi elemanların olması gerektiğini ve nasıl çalışması gerektiğini belirliyoruz.

Son 2 bölüm en önemlisidir. Sitenin nasıl olacağına ve nasıl çalışacağına dair bir anlayış sağlarlar.

Çok önemli bir nokta - geliştiricilere sadece referans şartlarını veremez ve her şeyi iyi yapacaklarını umamazsınız. TK, site için bir gereksinimler listesidir, iletişimin yerini alamaz. Her ekip üyesinin ortak hedefi anladığından ve yalnızca akışta görevleri yerine getirmediğinden emin olmak önemlidir. Bir şey net değilse - açıklamak, tartışmak, ayrıntılı yorumlar vermek gerekir.