Agar siz "mahsulot talablari hujjati" so'rovi bilan xorijiy saytlarga kirsangiz, texnik topshiriq (TOR, PRD) o'lganligi haqida ijodiy va ishonchli maqolalarni topishingiz mumkin. Qisman, biz bunga rozi bo'lishimiz kerak - mahsulotni noldan ishlab chiqishda prototiplash mijozlarning ko'plab yozuvlari, ba'zan esa juda professional bo'lmagan narsalarga qaraganda ancha qiziqarli va samaraliroq ko'rinadi. Biroq, agar biz asosiy tizimni yakunlash haqida gapiradigan bo'lsak, unda ishlar butunlay boshqacha tus oladi. Biz qayta ko'rib chiqish va odatiy rivojlanishga duch keldik, shuning uchun oshpaz bizga yolg'on gapirmasa, itni TKda yeydi. Umuman olganda, bugungi kunda - sotib olingan va o'rnatilgan dasturiy ta'minotni yakunlash uchun yozilgan juda klassik texnik vazifalar haqida. Qisqasi, yara haqida.

O'zaro ta'sir tomonlari

Texnik vazifani yaratish jarayonini tayyorlashga o'tishdan oldin, keling, loyihani boshlashda pudratchi va buyurtmachi tushadigan to'rtburchaklar haqida gapiraylik.

Talablar- mijoz yoki jarayon egasi tomonidan ta'riflangan tizimning amalga oshirilishi kerak bo'lgan istalgan harakati. Qoida tariqasida, talablar tajriba, dasturning to'g'ri xatti-harakatini ifodalash asosida shakllanadi. Bu ishlab chiquvchi (sotuvchi) uchun asosiy ma'lumotdir, ammo talablarni yig'ish bosqichida eng ko'p to'qnashuvlar, xatolar, ortiqcha so'rovlar va hokazolar sodir bo'ladi.

Resurslar- talablarni amalga oshirish jarayonida foydalaniladigan odamlar, mashinalar, inventar, rivojlanish muhiti, vaqt va pul. Resurslar texnik topshiriqlarni tasdiqlash bosqichida aniq rejalashtirish va baholashni talab qiladi. Buyurtmachi tomonidan vakolatli ustuvorlik va sotuvchi tomonidan mehnat resurslarini taqsimlash o'tkazib yuborilgan muddatlarning oldini olish va boshqa xavflarni minimallashtirish imkonini beradi.

Imkoniyatlar- qisqasi, sotuvchi (ijrochi) aslida shunday qila oladi. Misol sifatida RegionSoft CRM-ni ko'rib chiqing. Mijoz tizimni sotib oladi va qayta ko'rib chiqish uchun texnik topshiriqni tuzadi: sayt bilan integratsiyani yaratish va CRM-dagi voqealarni onlayn-do'konning buyurtma raqamiga bog'lash kerak. Bu real talab, buni amalga oshirish uchun bizda resurs va imkoniyat bor. Shuningdek, siz CRM CMS, sayt mazmunini boshqarish tizimini ishlab chiqishingiz va unga ulanishingiz kerak. Nazariy jihatdan, biz buni qila olamiz, lekin bizda buni arzon qilish imkoniyati yo'q va mijozning bizga inson va vaqt resurslarini vazifaga o'tkazish uchun etarli miqdorda to'lash imkoniyati yo'q. Natijada, mijoz bu talabni rad etadi - va unga CMS kerak emas, baribir hammasi yaxshi. Ammo TKning "ochko'zligi" haqida - keyinroq.

Cheklovlar- TORdan vazifalarni bajarishni qiyinlashtiradigan yoki imkonsiz qiladigan to'siqlar to'plami: byudjet, texnologiya to'plami, litsenziyalash muammolari, qonuniy taqiqlar, apparat konfiguratsiyasi va boshqalar.

Shunday qilib, barcha to'rtta sub'ekt bir-biri bilan chambarchas bog'langan va umuman loyihaning muvaffaqiyatini belgilaydi. Keling, har bir elementni ko'rib chiqaylik va texnik topshiriq ustida ishlashda yodda tutish kerak bo'lgan muhim fikrlarni ajratib ko'rsatishga harakat qilaylik.

Talablarni yig'ish va tahlil qilish

Bu juda muhim ichki korporativ jarayon bo'lib, uning davomida potentsial foydalanuvchilar dasturdan nimani xohlashlarini aniqlaydi (bundan keyin biz CRM-ni olamiz, ammo usullar boshqa turdagi dasturiy ta'minot bilan ishlaydi). Agar siz SAP yoki tizim integratori kabi yirik sotuvchiga murojaat qilsangiz, sizga katta ehtimollik bilan biznes maslahatchisi xizmatlari taklif qilinadi (u ham shaxsiy menejer, u ham hisob menejeri, u ham " Endi sizning kompaniyamizdagi vakilingiz"). Aslida, ko'p hollarda, bu oddiy yaxshi o'qitilgan sotuvchi bo'lib, uning ikkita vazifasi bor: loyihaning narxini qoplash va sizni ilgakka yo'l qo'ymaslik.

U bir soatdan beri shu yerda, hatto doskaga ham tegmagan. U haqiqiy tizim tahlilchisi emas

Hech kim sizning kompaniyangizni sizdan va sizning xodimlaringizdan yaxshiroq bilmaydi. Bu shuni anglatadiki, talablarni to'plash va tahlil qilish faqat sizning vazifangiz bo'lib, unda sotuvchi yordam berishi va yo'naltirishi mumkin, lekin hech qanday holatda jarayonga aralashmaydi. Ishlab chiquvchidan bunday ilovalar haqida so'rang, nimani izlash kerakligini aniqlang va davom eting. Aytgancha, profil mavzusini yaxshi biladigan va dasturiy ta'minot arxitekturasini taxminan ifodalovchi va ishlab chiqish jarayoni bilan tanish bo'lgan xodimingiz yaxshi yordamchi bo'lishi mumkin - u tahlilchi va ichki ekspert sifatida harakat qilishi, texnik xususiyatlarni yaratish jarayonini yopishi mumkin. va sotuvchi bilan aloqa qilish.

Talablarni yig'ish uchun juda oddiy sxema mavjud.

1. CRM-dan foydalanadigan bo'limlarning menejerlari va tajribali mutaxassislaridan iborat ishchi guruhini tuzing. Siz tanlagan yechim haqida bizga xabar bering, demo versiyasiga kirishni ta'minlang.
2. Ishchi guruh a'zolari xodimlarga ma'lumotlarni etkazishlari va mutlaqo bepul shaklda yangi dastur bo'yicha tilaklarini so'rashlari kerak. Agar xodimlardan biri hech qachon bunday dasturiy ta'minotga duch kelmagan bo'lsa va kelajakda foydalanish haqida gapirishga tayyor bo'lmasa, siz uning davriy vazifalarini tavsiflashni so'rashingiz kerak, bu universal yondashuv.
3. Keyin har bir bo'linma CRM nimaga mos kelmasligini yoki mos kelmasligini aniqlaydi va ma'lumotlarni jamlaydi.
4. Ishchi guruh to'plangan talablarni tahlil qiladi, chorrahalarni tekshiradi va yo'q qiladi. Misol uchun, savdo bo'limi va marketing bo'limi bir xil hisobotga buyurtma berishlari odatiy hol emas, lekin ular ortidagi ma'lumotlar bir xil bo'lsa-da, talablarda sohalar va ob'ektlar boshqacha nomlanishi mumkin. Shunga ko'ra, yagona shaklga kelish kerak.
5. Ishchi guruh talablar ro'yxatini tuzadi va ustuvor vazifalarni belgilaydi. Ushbu bosqichda siz sotuvchini ulashingiz mumkin, chunki u resurslar uchun javobgardir. Masalan, siz RegionSoft CRM uchun maxsus hisobot yaratishni so'rashingiz yoki sayt bilan integratsiyaga buyurtma berishingiz mumkin. Bu vaqt jihatidan butunlay boshqacha bo'lgan vazifalar, bu erda ustuvorlik juda muhimdir.

Talablar yig'ilgandan, tahlil qilingandan va xodimlar va rahbariyat bilan kelishilgandan so'ng, siz texnik topshiriqlarni yaratishni boshlashingiz mumkin. Shaklni sotuvchidan so'rashingiz yoki uni o'zingiz yaratishingiz mumkin - har qanday holatda ham sizni ham, CRM provayderingizni ham bosh og'rig'idan qutqaradigan bir nechta temir bilan qoplangan qoidalar mavjud.

Texnik topshiriq anatomiyasi

Agar texnik vazifani yaratish jarayoni haqida gapiradigan bo'lsak, unda bir necha bosqichlar mavjud. Ularning izchil o'tishi mijozni kerakli yaxshilanishga olib keladi. Mana ular.

• Identifikatsiya - talablarni aniqlash, hal qilinishi kerak bo'lgan muammolarni izlash.
• Tahlil - talablarni tahlil qilish, asosiy ehtiyojlarni aniqlash, umumlashtirish.
• Moslashuv - CRM imkoniyatlari va mavjud biznes jarayonlari kontekstida talablarni baholash.
• Hujjatlar - talablarning rasmiy va batafsil tavsifi, texnik shartlarni tasdiqlash.
• Sotuvchi (ishlab chiquvchi) bilan aloqa - tuzilgan TORga muvofiq takomillashtirish bo'yicha sotuvchi bilan iterativ o'zaro hamkorlik.
• Amalga oshirish - sotuvchining kerakli funksionallikni yaratish bo'yicha ishi. Agar sotuvchi doimiy ravishda mijoz bilan aloqada bo'lsa yaxshi bo'ladi - shuning uchun ishlab chiqarilgan mahsulot mijozning qarashlariga eng mos keladi.
• Sinov - qayta ko'rib chiqishning TORga muvofiqligini, tizimning o'zgarishlar bilan ishlashini aniqlash uchun sotuvchining xodimlari, mijozning ichki ekspertlari va oxirgi foydalanuvchilar tomonidan funksionallikni tekshirish.

Umuman olganda, texnik topshiriqlar loyihani yaratishda bir-biriga mos kelishi va hamkorlik qilishi yoki umuman o'zaro ta'sir qilmasligi mumkin bo'lgan bir nechta darajadagi talablar asosida tuzilishi mumkin.

Biznes darajasi- murakkab va ustuvor vazifalar hal qilinadigan eng global daraja. Ushbu daraja biznes jarayonlarini integratsiyalash, takomillashtirish va modellashtirish, yangi funktsional modullarni ishlab chiqishni o'z ichiga oladi. Qoida tariqasida, bu jiddiy maslahatlashuvlar va mijoz bilan yaqin hamkorlik bilan resurs talab qiladigan rivojlanishdir. Misol uchun, bir vaqtlar RegionSoft CRM-da ombor hisobi, kassa va ishlab chiqarish shunday maxsus modifikatsiyalar edi. Asta-sekin, o'zgarishlar relizga kirdi va keyinchalik ulgurji, chakana savdo do'konlari va gipermarketlar uchun yangi mahsulotni - RegionSoft Retailni yaratishga imkon berdi.

Foydalanuvchi yoki foydalanuvchilar guruhi darajasi. Ushbu darajada mavjud interfeysni takomillashtirish bo'yicha vazifalar amalga oshiriladi. Masalan, foydalanuvchi kursorni mijoz ustiga olib borganida oxirgi buyurtmaning raqami va holati ko'rsatilgan oyna yoki ma'lumotlarning maxsus guruhiga ega bo'lgan maxsus hisobot paydo bo'lishini xohlashi mumkin. Ushbu darajadagi takomillashtirish kamroq vaqt talab etadi, lekin ular juda ko'p bo'lishi mumkin - masalan, marketing, logistika va texnik yordam bo'limlarining bir nechta talablari.

funksionallik darajasi. Ko'pincha uni avvalgisidan ajratish qiyin, bu erda rasmiy mezon ishlaydi - tozalash interfeysda biror narsani ko'rsatish darajasida emas, balki tizim mantig'ini takomillashtirish darajasida. Bularga turli xil saralash, chat integratsiyasi va telefoniya imkoniyatlariga qo'yiladigan talablar kiradi.

Xizmat darajasi- aslida, ushbu darajadagi talablar tuzatilgan yangi tuzilmalarga birinchi bo'lib kirishi kerak. Bu tizim javob tezligi, yuqori yuk ostida ishlash va xavfsizlik nuqtai nazaridan vazifalardir. Ideal holda, sotuvchida bunday yaxshilanishlar bo'lmasligi kerak - korporativ dasturiy ta'minot sekinlashmasligi, ma'lumotlarni yo'qotmasligi, shakllarni yiqitmasligi va bir xil darajadagi kirish huquqlarini tarqatmasligi kerak. Ammo agar talab paydo bo'lsa va u mijozning shaxsiy paranoyasi yoki apparat tomonidagi muammolar bilan bog'liq bo'lmasa, unga alohida e'tibor qaratish lozim.

Texnologiya darajasi- ro'yxatda oxirgi, ammo ahamiyati va murakkabligi bo'yicha qolganlardan oldinda. Bu platforma, operatsion tizim yoki qurilmalar bilan bog'liq mijoz talablari bo'lishi mumkin. Masalan, MacOS uchun qurish so'rovi. Agar bunday talablar asta-sekin relizlarga aylansa, juda yaxshi, lekin ularni tuzatish kerak. Aynan shu darajadagi mijozlarning so'rovlariga ko'ra, biz MacOS uchun RegionSoft CRM-ni yig'dik va kamdan-kam uchraydigan, ammo mobil versiya uchun mavjud so'rovga vaqtinchalik yechim sifatida TRM texnologiyasidan foydalangan holda masofaviy kirishni qo'shdik.

Texnik topshiriqning anatomiyasi oddiy, hech bo'lmaganda skelet shaklida. Texnik topshiriqning majburiy qismlari mijozga muammoga e'tibor qaratish va vazifani to'g'ri shakllantirishga yordam beradi va ijrochi undan nimani xohlashini tushunishga yordam beradi. Aytgancha, tushunish haqida. Albatta, biz post boshida biznes maslahatchilarni sinf sifatida inkor etib, biroz ayyor edik. Gap shundaki: har bir sotuvchi bozorda bir necha yillardan beri ishlaydi (biz hozir bir kunlik CRMlar haqida gapirmayapmiz), hatto o'nlab yillar davomida, bu deyarli har bir sohada bir qator holatlarga ega ekanligini anglatadi. Shunga ko'ra, muhandislar ham, dasturchilar ham, sotuvchilar ham har bir turdagi kompaniyada amalga oshirishning o'ziga xos xususiyatlari bilan tanish. Ammo yana bir bor o'z ishingizga e'tibor qaratish muhim.

Kimdan? Ushbu bo'limda siz qayta ko'rib chiqishning oxirgi foydalanuvchisi kim bo'lishini, qanday vazifalarni va qanchalik tez-tez hal qilish rejalashtirilganligini tavsiflashingiz kerak.

Men sizga bir misol keltiraman. Bitta kompaniya CRM-ni joriy qildi, u juda katta miqdordagi ma'lumotlar (oyiga bir necha o'n million yozuvlar, kuniga bir necha yuz ming yozuvlar) ustida ishlashi kerak edi. Savdo bo'limi boshlig'i ushbu yozuvlarni "kunlik" chastotasi bilan yuklash bo'yicha hisobotni so'radi. Tabiiyki, bunday hisobot, yuzlab foydalanuvchilar bir vaqtning o'zida ishlayotgan paytda, tizimni yukladi - jarayonni optimallashtirish uchun echimlar topildi. Ish paytida, sotuvchi uni xavfsiz o'ynaganligi va unga hisobot faqat oy oxirida kerak bo'lganligi ma'lum bo'ldi, keyin uni tunda jadvalga muvofiq ishga tushirish mumkin edi. Aytishga hojat yo'q, vaqt va pul behuda ketdi.

Nima uchun? Takomillashtirish zaruriyatini asoslash va uning biznes jarayonidagi o'rni. Ushbu element mijozning o'ziga ko'proq kerak, ammo sotuvchiga boshqa qanday jarayonlar ta'sir qilishini bilish ham foydalidir. Ba'zan bu muqobil yechim topishga yordam beradi.

Nima qilish kerak? Eng ma'lumotli blok - bu tizimdan talablarni, kutishlarni tavsiflaydi. Va bu erda marvaridlar, mo''jizalar va to'qnashuvlar sodir bo'ladi, ular boshorgga jo'natish uchun to'g'ri bo'ladi va bu hayotni juda qiyinlashtiradi. Faqat bitta sabab bor - foydalanuvchi nima istayotganini, nima qilish kerakligini bilmaydi. Yana bir kichik sabab bor - foydalanuvchi talablarni shakllantira olmaydi. Va bu erda ishlab chiquvchining vazifasi (ishchi guruh, tahlilchi, agar mavjud bo'lsa) ehtiyojni to'g'ri shakllantirishga yordam berish, tegishli talabni tanlash va vazifani tizim kontekstiga moslashtirishdir. Xuddi shu blokda siz kutilgan natijani eslatib o'tishingiz kerak.

Texnik shartlar parametrlari- muddatlar, amalga oshirish bosqichlari, barcha tomonlarning javobgarligi, zarur aloqalar va boshqalar. Aslida, bu hujjatni texnik vazifaga aylantiradigan muhim rasmiy narsalar to'plami. Ishlab chiqish jarayonida ko'plab o'zgarishlarga yo'l qo'ymaslik uchun texnik topshiriq tomonlar tomonidan kelishilgan va imzolangan bo'lishi kerak (ular hali ham bo'ladi, lekin kichikroq hajmda).

Ideal holda, texnik topshiriq sotuvchining faol ishtirokida tuziladi va uning natijasi taxminan quyidagi tuzilmadir:

1. Har bir mexanizm va har bir funksionallik talabining tavsifi
2. Ushbu funktsiyani amalga oshirish tavsifi
3. Har bir bosqich uchun ishning narxi alohida
4. Ushbu texnik vazifa bo'yicha ishlarning umumiy qiymati
5. Bosqichlar bo'yicha va ustuvorlik tartibini ko'rsatgan holda ishlarni bajarish muddatlari
6. O'rnatish va sinov shartlarining tavsifi
7. Texnik topshiriqning to'liqligi va boshqa shartlar bo'yicha izohlar

Ishlab chiquvchining ko'z yoshlari bilan yozilgan 10 ta qoida

Qayta ko'rib chiqish uchun texnik topshiriq qayta ko'rib chiqish uchun TOR bo'lishi kerak, va mijozga kerak bo'lgan CRMning 300 sahifali tavsifi emas. Talablarni tuzishdan oldin siz tizim interfeysi, uning imkoniyatlari, hujjatlari bilan diqqat bilan tanishib chiqishingiz kerak - ehtimol "Istaklar ro'yxati" ning aksariyati asosiy paketda mavjud. Ikkinchi qadam sifatida, men o'rnatilgan takomillashtirish vositalariga (hisobot dizaynerlari, konfiguratorlar va boshqalar) e'tibor berishni tavsiya qilaman - ehtimol to'liq vaqtli dasturchi kerakli o'zgarishlarni amalga oshirishi mumkin (ko'p kompaniyalarda ular mavjud).

Texnik vazifa ochko'z bo'lmasligi kerak. Ko'pincha, biznes o'z imkoniyatlarini ortiqcha baholaydi yoki "hamma narsani bir vaqtning o'zida" olishni xohlaydi. Bunday yondashuv pul nuqtai nazaridan ham, biznes nuqtai nazaridan ham oqlanmaydi. Sotuvchi, qoida tariqasida, bir necha hafta davomida mavjud emas (RegionSoft misolida - 15 yil) va siz CRM-da nima etishmayotganini haqiqatan ham tushunganingizda, bir muncha vaqt o'tgach, u bilan bog'lanishingiz mumkin.

Kecha tom ma'noda ishdan bo'shatishning yorqin misoli: mijoz taniqli rus kompaniyasining ERP-ni sotib oldi, chunki buxgalteriya hisobi ishlagandan so'ng, ushbu sotuvchining ERP yaxshi bo'ladi deb o'yladi. ERP o'z-o'zidan unchalik yaxshi emas, balki biznes uchun juda mos emas edi. Ammo ombor hisobi va ishlab chiqarish bilan RegionSoft CRM mos keladi. Yechim bor: ERP haqida unuting, yig'lang, 1C buxgalteriya hisobini yangi CRM bilan birlashtiring va qulay dasturdan zavqlaning. Ammo shishgan pul juda achinarli! Va mijoz CRMni ERP bilan integratsiya qilishni talab qiladi. Biz buni qilmadik, lekin nima uchun bunday chiqindilar, nega ikkita nisbatan o'xshash tizim?

Texnik topshiriqlar real va erishish mumkin bo'lishi kerak- talablar va muddatlar bo'yicha ham. Bu erda sotuvchining fikrini tinglash juda muhim, chunki u ma'lum bir ish uchun qancha vaqt ketishini aniq biladi. Menga ishoning, ishlab chiquvchi uchun vaqt o'ynash va belgilangan muddatni tugatish foydali emas - uning obro'siga zarba bermaslik uchun iloji boricha ko'proq loyihalarni bajarish va buni yaxshi bajarish foydalidir. Realizmga kelsak, CRM-ni kollayderni boshqarish tizimi darajasida tugatish so'rovlaridan qochish juda oddiy: talablarga hozirgi paytda va yaqin kelajakda haqiqatan ham zarur bo'lgan narsalarni kiritish kerak.

Masalan, RegionSoft CRM ish stoli dasturi bo'lib, bizda brauzer mijozi yo'q. Bizdan bitta kompaniya uchun veb-ilovani yaratishni so'rash befoyda, bu katta ishlanma, u hozirda davom etmoqda va bitta kompaniya uchun mumkin bo'lgan takomillashtirish emas. Yo'q, albatta, hamma narsa o'z narxiga ega, lekin yana - umumiy holatda, talab mumkin emas.

Buni maxsus ishlab chiqish haqida gap ketganda va dasturning g'oyasi va mantig'i tubdan o'zgarganda, vaziyat bilan aralashmaslik kerak, aslida "o'zi uchun" yangi dasturiy ta'minotni yaratish homiylik qiladi. Lekin bu boshqa hikoya.

Spetsifikatsiya batafsil bo'lishi kerak. Kelajakdagi loyihaning barcha muhim tafsilotlarini ko'rsatish kerak: dasturdan foydalanish chastotasidan interfeysga bo'lgan istaklargacha. Talablar qanchalik batafsil bo'lsa, amalga oshirish va sinovdan o'tkazish shunchalik oson va tezroq bo'ladi. Ayniqsa, ma'lum bir sohada (tibbiyot, sug'urta, banklar) ishlayotgan bo'lsangiz, tafsilotlarga e'tibor qaratish lozim - biznes va dastur o'rtasidagi o'zaro ta'sirning nuanslarini batafsil taqdim etish sotuvchining vazifani tushunishini va tez moslashishini ta'minlaydi. kompaniyangizga tizim.

Raqam formatlari, maydon nomlari, ochiladigan ro'yxatlarning mavjudligi yoki yo'qligi, tugmalar va maslahatlarning harakati va ma'lumotlar turlariga e'tibor berishni unutmang. Agar mijoz CRM mantig'iga kiritilishi kerak bo'lgan o'z formulalaridan foydalansa ( masalan, dilerlik bonuslarini hisoblash), bu formulalar ularning belgilanishi va hisoblash mantig'i to'liq tushuntirilgan holda yozilishi kerak.

Ha, korporativ dasturiy ta'minot shunga o'xshash narsaga o'xshaydi va unda juda ko'p muhim kichik narsalar mavjud.

Texnik topshiriq aniq va aniq bo'lishi kerak. Noaniq so'zlar, amalga oshirish variantlari, noaniq talablar - bularning barchasi boshi berk ko'chaga olib boradigan yo'ldir. Shunday bo'ladiki, mijoz yaxshi niyat bilan TOR-ga tizim xatti-harakatlari uchun yaqin, ammo ekvivalent bo'lmagan bir nechta variantni yozadi. Bunday holda, u yordam berishiga ishonch hosil qiladi, dasturchini taklif qiladi, lekin aslida do'zaxga yo'l yaxshi niyatlar bilan qoplangan; ishlab chiquvchi aniq nima kerakligini tushunishi kerak va u buni qanday qilishni o'zi tanlaydi. tizimning xususiyatlari va foydalaniladigan texnologiyalar to'plami.

Bu yil siz yana bitta tilak qilishingiz mumkin. Iltimos, buni hatto men ham bajara olmaydigan narsaga, masalan, aniq biznes talablariga sarflamang!

Texnik topshiriq inson tilida yozilishi kerak. Va bu muhim, yo'q, MUHIM. Til bilan bog'liq muammolar loyihani amalga oshirishning kechikishiga olib keladigan ikkita vaziyatni ajratib ko'rsataman.

1. Mijoz o'zining texnik savodxonligini va panjara konstruksiyalarini namoyish etishga harakat qiladi, masalan: "taqvimda oyna paydo bo'lishi kerak" o'rniga "taqvimning tanasida voqea qo'ng'irog'iga munosabat bildirish qobiliyatiga ega bo'lgan oynani amalga oshirish ..." unda siz vazifani bajarilgan deb belgilashingiz mumkin." Agar siz yoki sizning ichki mutaxassisingiz texnik matnlarni yozish ko'nikmalariga ega bo'lmasangiz, google-ga murojaat qilmang - oddiy so'zlar bilan yozing, biz ularni tushunamiz.

   Texnik topshiriq shikoyat kitobi bo'lmasligi kerak. Biz shriftlarga e'tibor berib, talablarning tavsifini unutib, uni tasvirlamasdan, muammoni hal qilishimiz kerak. TOR nafaqat muammoning o'zini, balki uni tushunish darajasida hal qilishni ham o'z ichiga olishi kerak - shunda ishlab chiquvchi uni allaqachon kod darajasida hal qiladi. Taqqoslash "Savdo bo'limi yomon rejalashtiradi, raqamlarni yo'qotadi, biz bir yildan beri kurashamiz" Va "mahsulot guruhlari kontekstida har oyda rejaning qiymatlarini va sotish faktini saqlaydigan hisobot yaratish kerak".

   Texnik topshiriq kelajakka qarash imkoniyatiga ega bo'lishi kerak. Xo'sh, aniq emas, balki uning ortida turgan odamlar. Tez orada biznes jarayonlarida o'zgarishlar ro'y berishi ma'lum bo'lsa, qayta ko'rib chiqish uchun ikki marta to'lamaslik uchun buni hisobga olish kerak.

   Texnik topshiriq byurokratik bo'lmasligi kerak. Agar siz ushbu hujjat loyihasini ilgari ishlab chiqqan bo'lsangiz, byurokratiyaga o'tish vasvasasidan qochish, kirish so'zlari, qat'iy burilishlar qo'shish va har bir bandni Jinoyat kodeksining moddasi sifatida tavsiflash qanchalik qiyinligini his qilgan bo'lsangiz kerak (yaxshisi hamma uchun jazo bilan). buzilishi). Byurokratik so'zlar TKni yaratish maqsadlarini to'liq tushunmaslikni niqoblaydi. Sotuvchining javobgarligi shartnomada ko'rsatilgan, byudjet ham u erda yozilgan. Ushbu nuqtalarni texnik vazifaga o'tkazmasligingiz kerak.

   Texnik topshiriq texnik topshiriq bo'lishi kerak. Bu paradoksal tuyuladi, lekin ko'pincha texnik xususiyatlar o'rniga biz xatlar, shikoyatlar, shartnomalar, CRM uchun yangi yozilgan ko'rsatmalar yoki yig'ilish protokollarini o'qiymiz. Albatta, bunday hujjat ustida ishlash mumkin emas. Shakl va mazmundan uzoqlashmaslik uchun eski maktab hiylasidan foydalaning: atamani so'zma-so'z ko'rib chiqing. Texnik vositalar - bu aniqlashtirishni, texnikani talab qiladi, dasturiy ta'minotni o'zgartirish orqali muammoni hal qilishga qaratilgan. Bu dasturiy ta'minot kontekstidagi vazifa va siz gaplashishingiz kerak. Vazifa deganda maslahat, maslahat va dastlabki baholarsiz savol, muammo qo'yish tushuniladi. Muammoning faqat bayonoti.

   Amrlar tugadi, endi tanbeh

   Yuqoridagi qoidalarga qo'shimcha ravishda, gapirishga arziydigan yana bir nechta narsalar mavjud. Biz maqsadlar, rejalar va umidlar haqida gapiramiz - loyihani muvaffaqiyatli qiladigan barcha tark etuvchilar va sotuvchi va mijoz o'rtasidagi munosabatlar deyarli do'stona.

   Texnik topshiriq tezda yozilishi kerak, agar siz uyali aloqa operatori yoki yirik gipermarket jarayonlarini avtomatlashtirish vazifasiga duch kelsangiz ham. Buning sababi shundaki, texnologiyalar juda katta tezlikda rivojlanmoqda va hatto siz amalga oshirayotgan tizim ham olti oy yoki bir yil ichida katta nashrdan (va ba'zan ikkitadan) omon qolishi va yangi funksiyalarga ega bo'lishi mumkin. Yaxshilashlar zarurligini qayta ko'rib chiqish va jarayonni qayta boshlash kerak bo'lishi mumkin.

   

   
   Nihoyat, u TKni tugatishga vaqt topdi. Ammo, afsuski, uni amalga oshirish uchun ishlab chiquvchilar qolmadi.

   Mijoz stek va texnik cheklovlardan bexabar. Va u bilmasligi kerak - bu sotuvchining vazifasi, u texnik topshiriqni tuzgandan keyin ishni baholaydi. Xaridor texnologiyani chuqur o'rganmasligi va sotuvchi u yoki bu narsani qila oladimi, har bir verguldan so'rashi kerak. Keng qamrovli TORni tuzing va ishlab chiquvchi mos arxitekturani tanlaydi - ko'pincha siz o'ylagandan ham yaxshiroq.

   Byudjetingizni hisoblang va yoqimsiz kutilmagan hodisalardan qoching- deyarli birinchi raqamli qo'shma vazifa. Siz sotuvchini tortib olmaysiz va undan ishning taxminiy bahosini talab qilishingiz kerak (yaxshi, hech bo'lmaganda, o'z-o'zidan, ko'z bilan, lekin boshqalar kabi, bu turdagi loyihalarda, lekin tajribadan, yaxshi, yaxshi, doirasida. xato chegarasi). To'liq byudjet smetasini faqat texnik topshiriqlarni o'qib chiqish, tahlil qilish va yakuniy tasdiqlashdan keyin amalga oshirish mumkin. Agar ishlab chiquvchingiz boshqacha qilsa, qayta ko'rib chiqish kamida ikki baravar qimmatga tushishiga tayyor bo'ling.

   O'zgarishlar va kengayishlarning ob'ektiv ehtiyojidan kelib chiqing- Men yuqorida ishlab chiquvchi yo'qolib ketmasligi va istalgan vaqtda sizning talablaringiz bo'yicha o'zgartirish va qo'shimchalar kiritishga tayyor ekanligini yozgan edim. Shuning uchun, darhol CRM / ERP orzularini yaratishga urinmang, sotuvchidan "Men qahva ichganimda hamma narsa ishlaydi" tugmachasini talab qilmang - tizimda ishlang, siz uchun tanqidiy sharhlarni aniqlang va talablarni to'plashni va texnik shartlarni tuzishni boshlang. .

   Siz texnik vazifalar haqida cheksiz yozishingiz mumkin, bu nafaqat memlar va ertaklarning, balki bosh og'rig'ining haqiqiy generatoridir. Siz ustuvorliklar va dizayn qoidalari haqida, TKni g'ayriinsoniy qiladigan GOST 1989 haqida, biroz yaxshiroq bo'lgan IEEE standartlari haqida, ularni to'ldiradigan prototiplar va TK haqida gapirishingiz mumkin. Ammo, oxir-oqibat, men o'zimni bitta, eng muhim qoida bilan cheklab qo'ymoqchiman: texnik topshiriqlar qonun normasi emas, GOST emas va dogma emas, shuning uchun agar siz yaxshilashingiz mumkin bo'lsa - yaxshilaysiz, soddalashtirasiz - soddalashtiring, siz buni chiroyli tarzda qilishingiz mumkin va hamma buni yoqtirishi uchun - buni qiling. Ishonchim komilki, bundan keyin hech kim TKga burnini tiqmaydi va u erda bu yozilmagan deb aytmaydi. Yoki deyarli hech kim.

   Dekabr oyi davomida biz RegionSoft CRM va o'zimiz ishlab chiqqan barcha dasturlar uchun chegirmalar beramiz. 1 dekabrdan 15 dekabrgacha - 15% va salqin to'lov va ijara shartlari. Bizda -70% va -90% yo'q, chunki biz litsenziyalar uchun iqtisodiy jihatdan asoslangan narxni ushlab turamiz va uni shiftdan olmaymiz.

   Xo'sh, agar sizga CRM tizimi kerak bo'lsa (o'zgartirish bilan yoki o'zgartirmasdan), u holda o'ting bizning veb-saytimiz, CRM, uning afzalliklari va boshqa korporativ dasturlar haqida ko'p narsa bor.

   Va ha, biz har doim CRM va boshqa mahsulotlarni sotishga, CRMni yaxshilashga va sotishga, dasturiy ta'minotni sotishga va foydalanuvchilarni o'qitishga tayyor bo'lgan hamkorlarni qidiramiz. Daromad taqsimoti sherik uchun adolatli va foydalidir. Ko'rsating, ayting, o'rgating. ga yozing [elektron pochta himoyalangan]

   Slaydlar, slaydlar. Komikslar http://www.modernanalyst.com/ va Pinterestdan olingan. Agar yaxshiroq tarjimasi bo'lsa, uni postga qo'shishdan mamnun bo'lamiz.

Bizning mutaxassislarimiz mijozga yaratishda yordam berishdi Shamollatish tizimini modernizatsiya qilish bo'yicha texnik topshiriqlar.

Batafsil ma'lumot kesish ostida..

Texnik vazifa

451,452-sonli laboratoriya binosining ventilyatsiya tizimlari uchun texnologik uskunalarni modernizatsiya qilish uchun, Moskva sh.

1. Umumiy qoidalar

1.1. Ushbu texnik topshiriq binoning ventilyatsiya agregatlarini, 17-binoning 451,452-sonli laboratoriyalarini texnologik jihozlar, boshqaruv tizimlari va avtomatlashtirishni modernizatsiya qilish bo'yicha ishlarni amalga oshirishni nazarda tutadi.

1.2. Ishlarni bajarish uchun AOV, EM, KhS, AHS, AK markalari bo'limlari uchun ishchi hujjatlarni ishlab chiqing, ular belgilangan tartibda kelishilishi kerak.

1.3. Ishlarni me'yoriy-texnik hujjatlar talablariga muvofiq bajarish.

1.4. Ish tugagandan so'ng, GOST va SNiP talablariga muvofiq tuzilgan hujjatlarni taqdim eting.

1.5. Tugallangan ishni mijozga topshiring.

1.6. Ushbu texnik topshiriqning ayrim qoidalari Buyurtmachi bilan kelishilgan holda ish jarayonida belgilanishi mumkin.

2. Texnik talablar

2.1. Shamollatish moslamalarini issiqlik va sovuq bilan ta'minlash uchun boshqaruv bloklarini modernizatsiya qilish.

2.1.1. Issiqlik ta'minotini tartibga solish tugunlari.

Modernizatsiya quyidagilarga bog'liq:

· MIK-V ning K1, K2, K2a, K4, 452-sonli laboratoriya, P1 laboratoriyasining P2, P6 binolarining K1, K2, K2a, K4 ventilyatsiya agregatlarini birinchi isitish uchun issiqlik ta'minoti boshqaruv bloklari.

· MIK-V binosining K1, K2, K2a shamollatish moslamalarini ikkinchi isitish uchun issiqlik ta'minotini boshqarish bloklari.

Mavjud issiqlik ta'minoti boshqaruv bloklari demontaj qilinishi kerak, o'rnatilgan boshqaruv bloklarida esa holati va texnik xususiyatlariga mos keladigan boshqaruv bloklari jihozlarining bir qismi (aylanma nasoslar, o'chirish klapanlari) qo'llanilishi kerak.

O'rnatilgan boshqaruv bloklari jihozlarining tarkibi, shuningdek ishlatiladigan uskunalar 1-ilovada ko'rsatilgan.

Shlangi sinov hisobotini rasmiylashtirish bilan shamollatish moslamalarining isitish davrlari va isitgichlarining gidravlik sinovlarini o'tkazing.

Quvurlarni bo'yash va issiqlik izolyatsiyalash ishlarini bajarish.

2.1.2 Shamollatish moslamalarini sovutgich bilan ta'minlashni tartibga soluvchi tugunlar.

MIK-Vning K1, K2, K2a, K4, “452, 451-sonli laboratoriya P1” laboratoriyasining P2, P6 binolari ventilyatsiya agregatlari uchun sovutish moslamalari modernizatsiya qilinishi kerak.

Ish hajmi:

· sovutish boshqaruv bloklarining termostatik klapanlarini almashtirish;

K1 kompressor-kondensator blokining fanini demontaj qilish/o'rnatish;

· K1, K2 kompressor-kondensator bloklarining filtr-quritgichlarini demontaj qilish/o'rnatish;

K4 shamollatish moslamasining evaporatatorini demontaj qilish / o'rnatish;

· inert gaz muhitida bosimni sinash, changni yutish, sovutish sxemalarini freon bilan to'ldirish;

Quvurlarning issiqlik izolatsiyasini tiklash.

2.1.3. Namlash davrlari uchun besleme birliklari.

K1, K2, K2a konditsionerlarining sug'orish kameralarining ozuqa birliklariga sovuq suvni tozalash filtrlarini o'rnating.

2.2. Shamollatish moslamalarini boshqarish va avtomatlashtirish uchun shkaflar.

MIK-V, P2, P6, V1, V2, V3 laboratoriyasining № 451, P1, V1 laboratoriyasining K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8 ventilyatsiya agregatlari uchun boshqaruv shkaflari № 452.

Yangi o'rnatilgan boshqaruv panellarining joylashuvi:

SHUA K1 - shamollatish blokining boshqaruv kabinasi va avtomatizatsiyasi va K1 (MIK-V) konditsionerining kompressor va kondensator bloki (KKB);

SHUA K2 - boshqaruv kabinasi va shamollatish moslamasini avtomatlashtirish va KKB konditsioneri K2 (MIK-V);

SHUA K2 - boshqaruv kabinasi va shamollatish moslamasini avtomatlashtirish va KKB konditsioneri K2a (MIK-V);

SHUA K4 - boshqaruv kabinasi va shamollatish moslamasini avtomatlashtirish va KKB konditsioneri K4 (MIK-V);

SHUV - RU3, V1, V2, V3, V6, V7, V8 (MIK-V) egzoz bloklari uchun boshqaruv shkafi;

ShUA P2, P6 - ventilyatsiya agregatlari va P2, P6 kompressor va kondensator bloklarini boshqarish kabinasi va avtomatlashtirish (laboratoriya No 452);

SHUV - V1, V2, V3 egzoz bloklari uchun boshqaruv kabinasi (laboratoriya No 452);

SHUA P1, V1 - P1, V1 ventilyatsiya birliklarining boshqaruv kabinasi va avtomatizatsiyasi (laboratoriya No 451).

Modernizatsiya qilingan boshqaruv kabinetlari quyidagilarni ta'minlashi kerak:

shkafning old panelidan shamollatish moslamasini boshqarish rejimini tanlash (qo'lda / avtomatik);

· ventilyatsiya agregatlarining texnologik jihozlarining muntazam va favqulodda ishlash rejimlarining yorug'lik signalizatsiyasi (ishlash / avariya);

yong'in sodir bo'lganda shamollatish tizimlarini o'chirish;

himoya vositalarining avtomatik ishlashi va favqulodda vaziyatlarda uskunaning ishlashini blokirovka qilish.

Fanlar va nasoslarning elektr motorlarini boshqarish uchun chastota konvertorlari bundan keyin ham qo'llanilishi kerak.

2.3. Avtomatlashtirish va dispetcherlik tizimi

Avtomatlashtirish va dispetcherlik tizimi shamollatish moslamalarining ishlashini boshqarish va nazorat qilish, shuningdek, kiruvchi ma'lumotlarni yig'ish, qayta ishlash, taqdim etish va saqlash uchun mo'ljallangan.

2.3.1. Avtomatlashtirish tizimi.

Avtomatlashtirish tizimi, umuman olganda, shamollatish moslamalarining avtonom ishlashini ta'minlashi kerak, bu esa texnik xodimlarning aralashuvini va kerak bo'lganda qo'lda boshqarish rejimiga o'tishni talab qilmaydi. Har qanday boshqaruv variantlari bilan va mahalliy nazoratchining holatidan qat'i nazar, yong'in sodir bo'lganda umumiy shamollatish tizimini avtomatik ravishda o'chirish sharti saqlanishi kerak. O'chirish har bir tizim uchun alohida-alohida amalga oshirilishi kerak, shu bilan birga muzlashdan himoya qilish davrlarini quvvat bilan ta'minlash kerak.

Ventilyatsiya tizimlarini mahalliy avtomatlashtirish quyidagilarni o'z ichiga olishi kerak:

ventilyatsiya moslamasining chiqish joyidagi etkazib berish havosining haroratini yoki kerak bo'lganda, xizmat ko'rsatiladigan binolardan chiqadigan havo haroratini tartibga solish;

etkazib berish havosining namligini tartibga solish;

yong'in signalizatsiyasi ishga tushirilganda fanatlarni to'xtating va havo klapanlarini yoping;

Konditsionerning ventilyatori to'xtaganida uni namlashni o'chirish;

Fanni ishga tushirish va to'xtatishda navbati bilan havo klapanini ochish va yopish;

· qish rejimida tizimlarni ishga tushirishdan oldin isitgichlarni avtomatik isitish;

· isitgichlarni havo va suv bilan muzlashdan himoya qilish (ventilatorni o'chirish, havo damperini yopish, isitish klapanini 100% gacha ochish);

bosim farqi bo'lmaganda fanni o'chirish;

· inshootlar filtrlarining ifloslanishini nazorat qilish.

Ish stantsiyalari bilan mahalliy avtomatlashtirishga masofaviy ta'sir quyidagi hajmda aniqlanadi:

· harorat va namlik regulyatorlarining sozlamalarini o'zgartirish;

· sozlamalarni yoqish/o‘chirish.

Avtomatlashtirish tizimining mavjud periferik uskunalari quyidagi tartibda tekshirilishi, tozalanishi va keyingi foydalanishga topshirilishi kerak:

· ventilyatsiya agregatlarining harorat va namlik sensorlari tekshirilishi kerak;

· Differensial bosim o'tkazgich sensorlari tekshirilishi, tozalanishi;

· Havo isitgichlarini muzlashdan himoya qiluvchi termostatlarni almashtirish kerak.

· Boshqaruv bloklarining boshqaruv klapanlarining aktuatorlari 2.1.1-bandga muvofiq almashtirilishi kerak.

havo klapanining aktuatorlari tekshiruvdan o'tishi va undan keyingi foydalanishi kerak;

K1 konditsionerining sirkulyatsiyasini nazorat qilish uchun havo klapanlarining yoqish-o'chirish moslamalarini 0..10V nazorat signaliga ega klapanlar bilan almashtiring.

2.3.2. dispetcherlik tizimi.

Dispetcherlik tizimiga quyidagi komponentlarni kiriting:

"Honeywell" dasturiy-apparat vositalariga asoslangan o'lchash asboblari, aktuatorlar va avtomatlashtirish vositalari majmuasi;

· ko'p funktsiyali kabel tizimi;

· boshqaruv xonasining dasturiy-texnik vositalari majmuasi.

Ventilyatsiya tizimlarini jo'natish uchun quyidagi ma'lumotlarni ko'rsatish, arxivlash va jurnalga yozishni ta'minlang:

· harorat va namlik sensorlari, muzlashdan himoya qiluvchi termostatlar, differensial bosim o'tkazgichlari, nazorat klapanlari, havo namlagichlari, havo klapanlari bo'lgan qurilmalarning grafik tasviri;

o'rnatish raqamlari;

harorat va namlik sensorlarining ko'rsatkichlari;

differensial bosim rölesi sensorlarining o'qishlari;

nazorat klapanlarining joylashuvi ko'rsatkichlari 0..100%;

fanning ishlashi/to'xtatish rejimi;

· nasoslarning "ish / to'xtatish" rejimi;

havo klapanlarining holati "ochiq / yopiq";

yong'in signalizatsiyasi ishga tushirilganda tizimlarni to'xtatish;

isitgichni muzlatish xavfi mavjud bo'lganda tizimlarni o'chirish;

fan bo'ylab bosimning pasayishi bo'lmaganda jihozni o'chirish;

Konditsioner foniy to'xtaganida havo namlagichini o'chirish;

Tizimlarning ma'lum vaqt jadvaliga muvofiq yoki unsiz ishlashi;

· uskunaning noto'g'ri ishlashida avariyalar va favqulodda vaziyatlar to'g'risida signal berish, shuningdek - belgilangan diapazondan tashqarida texnologik parametrlarning qiymatlarini chiqarish;

baxtsiz hodisalar va favqulodda vaziyatlarni xabarlar jurnalida qayd etish;

· boshqariladigan parametrlar nomi, o'lchov birliklari, kontroller raqami va kirish/chiqish kanali ko'rsatilgan joriy vaqt uchun parametrlarni ro'yxatga olish jurnali.

2.3.3. Avtomatlashtirish va dispetcherlik tizimining elektr ta'minoti batareyalarda uzluksiz quvvat manbalaridan foydalangan holda 380/220 V kuchlanishli, 50 Gts chastotali o'zgaruvchan tok tarmog'idan ta'minlanishi va birinchi toifadagi energiya iste'molchilari uchun quvvat manbai sifatida ta'minlanishi kerak.

Bu to'g'ridan-to'g'ri 1C ni yakunlash bo'yicha texnik topshiriqlar qanchalik aniq tuzilganiga, ishlab chiquvchilarga yuklangan vazifalar hal qilinadimi-yo'qligiga bog'liq. Biroq, bunday hujjat bilan ishlashda ba'zi qiyinchiliklar mavjud. Keng ma'noda, TOR avtomatlashtirilgan tizimni (AS) yaratish va modernizatsiya qilish normalarini, shuningdek ish tartibini belgilaydi. Bunga loyihani ishga tushirish standartlari ham kiradi. Texnik topshiriqning rolini tushunish GOST 19.201-78 va 34.602-89 talablari bilan belgilanadi, unga ko'ra 1C uchun TOR ishlab chiqilmoqda. Ushbu hujjatning ma'nosini amaliyotga yaqinroq bo'lgan yana bir talqini bor.

Boshqa ta'rifga ko'ra, 1C ni yakunlash bo'yicha texnik topshiriq kelajakdagi tizimning maqsadi va parametrlarini, shuningdek hujjatlarni ishlab chiqish jarayonini va uning ro'yxatini tartibga soluvchi hujjatdir. Ushbu talqin dasturchilar va mijozning manfaatlarini hisobga olishga imkon beradi.

TK qanday bo'lishi kerak?

1C dasturini ishlab chiqish uchun har qanday texnik topshiriq pudratchi tomonidan yaratiladi. Lekin bu dasturchi emas, balki tahlilchi. Bu muhim nuqta, chunki hujjat mijoz tushunadigan tilda, yuqori ixtisoslashgan texnik shartlarsiz yozilishi kerak. Loyihaning barcha nuanslari hisobga olinsa va ma'lumotlar to'g'ri tuzilgan bo'lsa, TOR barcha mijozlar bilan kelishilgan. Agar u qabul qilinsa, dasturchilar ishga jalb qilinadi. Shu bilan birga, kerakli natija hujjatda aniq ko'rsatilishi kerak. Bu ishlab chiquvchilarga to'g'ri maqsadni qo'yishga va turli bosqichlarda uni tekshirishga yordam beradi. Shuningdek, 1C ni yakunlash bo'yicha texnik topshiriqlarni tuzishda so'zlarga katta e'tibor berish kerak. Ular etarlicha aniq bo'lishi va boshqa talqinlarni nazarda tutmasligi uchun ehtiyot bo'lish kerak. Bu TK bilan ishlashda eslash kerak bo'lgan birinchi narsa. Bundan tashqari, dizaynga mas'uliyat bilan yondashishingiz kerak. Bu hujjatning sarlavha sahifasiga ham tegishli.

1C ni ishlab chiqish bo'yicha texnik topshiriqdagi asosiy xatolar

Texnik topshiriqning tuzilishi GOST 34.602-89 tomonidan tartibga solinadi. Ushbu hujjat TORdagi ma'lumotlar bloklari soni va ketma-ketligiga aniq talablarni o'z ichiga oladi. Shu bilan birga, taqdimot usullari uchun qat'iy standartlar mavjud emas. Bu holat murakkab muammolarni hal qilish uchun katta imkoniyatlarni o'z ichiga oladi va shu bilan birga hujjatni tayyorlashda ko'plab xatolarga olib kelishi mumkin. Eng keng tarqalgan noaniqliklar:

1. Ba'zi bo'limlarni turli talqinlarda takrorlash.
2. Ma'lumotlar tasodifiy ravishda beriladi. Ideal holda, u biznes jarayonlari yoki tizim modullari kabi ma'lum bir tuzilmaga murojaat qilishi kerak.
3. Turli bo'limlardagi ma'lumotlar turli darajadagi tafsilotlar bilan taqdim etiladi.

Bularning barchasi mijozga TORda ko'rsatilgan ma'lumotlarni tushunishga to'sqinlik qiladi. Bu hamkorlik jarayonini murakkablashtirib, uni ko‘proq vaqt talab etadi.

Xaridor tomonidan ko'rib chiqilgandan so'ng, 1C ni qayta ko'rib chiqish uchun TOR namunasi o'zgarishi mumkin va har doim ham yaxshi tomonga emas. Bu, o'z navbatida, odatda dasturchilarga ma'lumotni to'g'ri qabul qilishiga to'sqinlik qiladi. Bu, ayniqsa, tajribasiz mutaxassislar uchun to'g'ri keladi. Ushbu bosqichda ko'pincha quyidagi xatolar yuzaga keladi:

1. Turli bo'limlarning talablari bir-biriga zid.
2. Formulalar noto'g'ri.
3. Ba'zi joylarda ma'lumotlar juda batafsil.

Bu xatolarning barchasidan xalos bo'lish juda oson. Ehtiyotkorlik bilan formulalarni yozishga emas, balki, birinchi navbatda, natijaga e'tibor qaratish lozim. Shuni esda tutish kerakki, TOR loyihaning funksionalligini, uning asosiy parametrlarini va maqsadini tavsiflaydi.

Texnik spetsifikatsiyalarni ishlab chiqishda qanday xatolardan qochish kerak?

Barcha keyingi tavsiyalarga taalluqli bo'lgan asosiy qoida shundan iboratki, so'zlar aniq bo'lishi kerak. Buning uchun siz GOSTlarga, boshqa me'yoriy hujjatlarga havolalardan foydalanishingiz kerak. Bu pudratchi va mijozga ma'lumotni bir xil tarzda qabul qilish imkonini beradi.

1C ni yakunlash bo'yicha texnik topshiriqning namunasi loyiha amalga oshirilayotgan biznes sohasi tilidan foydalanishni o'z ichiga oladi. Bu, birinchi navbatda, mijoz uchun kerak. Shu bilan birga, matnda taqqoslashlardan foydalanmaslik kerak, chunki ular turli yo'llar bilan talqin qilinishi mumkin.

Hisobot va 1C ning boshqa elementlarini ishlab chiqish uchun texnik topshiriqlarni tuzishda asosiy qoidalar:

1. TK pudratchi va buyurtmachi tomonidan birgalikda tuziladi.
2. Dasturchilar ishiga faqat ob'ektiv talablar qo'yilishi kerak. Loyihani muvaffaqiyatli ishlab chiqish uchun mijozning sub'ektiv qarashlari minimal bo'lishi kerak.
3. Xaridorga kerak bo'lgan natijani batafsil tavsiflash kerak. Shu bilan birga, 1C konfiguratsiyasini ishlab chiqish bo'yicha texnik topshiriqlar misolida element ishlashi kerak bo'lgan barcha parametrlarni belgilash kerak. Aks holda, natija istalganidan juda farq qilishi mumkin.
4. Pudratchi va mijozning risklari taxminan teng bo'lishi va minimallashtirilishi kerak.
5. Ishbilarmonlik aloqalarida qo'llaniladigan va ma'lum bir sohada ishlatilmaydigan atamalardan foydalana olmaysiz.

1C yoki boshqa elementda hisobotni ishlab chiqish uchun TORni yaratish uchun tahlilchi mijozning faoliyat sohasining barcha xususiyatlarini bilishi kerak. Talablarda siz faqat ijrochiga foydali bo'lgan foydali ma'lumotlarni berishingiz kerak. Bu erda dasturiy ta'minot hal qilishi kerak bo'lgan yakuniy vazifalarga alohida e'tibor qaratilishi hisobga olinsa, texnik topshiriqning yagona misoli yo'q.

TORni noto'g'ri tayyorlash xavfi

Yuqorida sanab o'tilgan xatolar tizimni yaratish uchun zarur bo'lgan vaqtni ko'paytirishga olib kelishi mumkin. Bu keraksiz xarajatlar va norozilikni keltirib chiqaradi. Ma'lumotlar bazasini yoki boshqa 1C konfiguratsiyasini ishlab chiqish bo'yicha texnik topshiriq tajribali mutaxassislar tomonidan tuzilishi kerak. Barcha ishtirokchilarning foydasi ushbu hujjatning tushunarliligiga bog'liq. Mijoz biznes muammolarini hal qilish uchun samarali avtomatlashtirilgan tizimni oladi. Shu bilan birga, pudratchining yana bir qoniqarli mijozi bor. Biznes egalari 1C hamkor kompaniyalarni tanlashda iloji boricha ehtiyot bo'lishlari kerak, chunki tashkilotning samaradorligi ko'p jihatdan qayta ko'rib chiqish uchun texnik topshiriqlar qanchalik to'g'ri tuzilganiga bog'liq.

Pavel Molyanov

Merfi qonunini eslaysizmi? Agar sizni noto'g'ri tushunishingiz mumkin bo'lsa, siz noto'g'ri tushunasiz. Bu nafaqat odamlar o'rtasidagi muloqotda, balki saytlarni yaratishda ham amal qiladi. Mijoz ikkinchi Facebookni xohladi, lekin yosh it yetishtiruvchilar uchun forum oldi. Ishlab chiquvchi mijozning istaklar ro'yxatini taxmin qilmadi - u vaqtini behuda o'tkazdi.

Ushbu qo'llanmada men sizga texnik topshiriqda nima va nima uchun yozishingiz kerakligini aytib beraman. Shu bilan birga, men sizga texnik xususiyatlarni yaratish behuda vaqtga aylanmasligi uchun qanday yozmaslik kerakligini ko'rsataman.

Maqola foydali bo'ladi:

• Saytlarni yaratish bilan bog'liq bo'lgan har bir kishi: ishlab chiquvchilar, dizaynerlar, maket dizaynerlari.
• Loyiha menejerlari.
• Raqamli studiyalar rahbarlari.
• Saytni ishlab chiqishga buyurtma berishni rejalashtirgan tadbirkorlar.

Materialni amaliy qilish uchun men bir nechta ishlab chiquvchilar, dizaynerlar, loyiha menejerlari va raqamli studiyalar egalarining sharhlarini to'pladim. Eng qimmatlilari maqolaning oxiriga qo'shiladi. Keling, buni aniqlaylik.

Spetsifikatsiya nima va u nima uchun kerak

Texnik topshiriq - bu saytga qo'yiladigan talablar belgilangan hujjat. Ushbu talablar qanchalik aniq va batafsil bo'lsa, jarayonning barcha ishtirokchilari bu qanday bo'lishi kerakligini tushunishadi. Bu shuni anglatadiki, hamma natijadan mamnun bo'lish imkoniyati ortib bormoqda.

Texnik topshiriqning asosiy maqsadi mijoz va ijrochi bir-birini to'g'ri tushunishiga ishonch hosil qilishdir.

Texnik xususiyatlarning ko'p afzalliklari bor. Har bir tomonning o'ziga xosligi bor.

Mijoz uchun foyda:

• U nima uchun pul to'layotganini va sayt qanday bo'lishini tushuning. Siz darhol tuzilmani ko'rishingiz, nima va qanday ishlashini tushunishingiz mumkin. Hamma narsa sizga mos keladimi yoki yo'qligini aniqlang. Agar yo'q bo'lsa - rivojlanish boshlanishidan oldin o'zgartirish uchun hech qanday muammo yo'q.
• Ijrochining malakasini ko'ring. Agar texnik topshiriq tushunarli va tushunarli bo'lsa, ishlab chiquvchiga bo'lgan ishonch ortadi. Agar u erda bo'tqa yozilgan bo'lsa, orqaga qaramaslik uchun yugurishga arziydi.
• Ijrochining insofsizligidan sug'urta qilish. Sayt tayyor bo'lgach, uni texnik topshiriqlarga muvofiq tekshirish mumkin. Qarama-qarshiliklar bormi? Ishlab chiquvchi ularni tuzatishi kerak. Agar siz rasman hamkorlik qilsangiz va shartnoma tuzsangiz, sizni sud orqali ham majburlash mumkin.
• Ijrochilarni almashtirishni soddalashtiring. Agar mijoz va ishlab chiquvchi janjallashib qochib ketgan bo'lsa, saytni yaratish uzoq vaqt talab qilishi mumkin. Batafsil texnik topshiriq mavjud bo'lganda, uni yangi jamoaga o'tkazish mumkin - u ishga bir necha barobar tezroq aralashadi.
• Murakkab mahsulotni ishlab chiqish xarajatlarini aniqlang. Murakkab veb-xizmatni yaratishning aniq vaqti va narxini darhol taxmin qilish mumkin emas. Avval siz xizmat qanday ishlashini va qanday funktsiyalarga ega bo'lishini tushunishingiz kerak. Buning uchun siz texnik topshiriqni tayyorlashingiz kerak.

Ijrochi uchun imtiyozlar:

• Mijoz nimani xohlashini tushuning. Mijozga o'nlab savollar beriladi, misollar ko'rsatiladi, echimlar taklif etiladi. Keyin hamma narsa bitta hujjatga yoziladi va muvofiqlashtiriladi. Agar hamma narsa yaxshi bo'lsa - tabriklar, siz to'g'ri tushundingiz.
• Mijozning kutilmagan istaklari ro'yxatidan sug'urta qilish. Ba'zida vazifani yarmigacha o'zgartirmoqchi bo'lgan mijozlar bor. Agar siz TORga rozi bo'lsangiz va imzolagan bo'lsangiz, bundan qo'rqmaysiz. Bunday holda, hatto sud ham siz tomonda bo'ladi.
• O'z qobiliyatingizni ko'rsating. Yaxshi tayyorlangan texnik topshiriq mijozga ishlab chiquvchilarning tajribasini ko'rsatadi. Agar kompaniya saytni ishlab chiqishda sizga ishonish yoki ishonmasligiga shubha qilsa, shubhalar yo'qolishi mumkin.
• Pul topish uchun. Ba'zi studiyalar va ishlab chiquvchilar texnik xususiyatlarni alohida xizmat sifatida tayyorlashni taklif qilishadi.

• Rivojlanish jarayonini osonlashtirish va tezlashtirish. Yaxshi TOR saytning tuzilishini, har bir sahifadagi kerakli funktsiyalarni va elementlarni ko'rsatadi. Barcha talablar allaqachon sizning ko'zingiz oldida bo'lsa, faqat kodni loyihalash va yozish qoladi.

Keling, ushbu funktsiyalarning barchasini bajaradigan yaxshi TORni qanday yozishni aniqlaylik.

Texnik topshiriqlar ijrochi tomonidan tuziladi

Umuman olganda, har kim texnik vazifani bajarishi mumkin. "Bizga stomatologiya klinikasi uchun tashrif qog'ozi veb-sayti kerak" - bu allaqachon texnik vazifa. Ammo u o'z ishini qiladimi? Qiyin.

Yaxshi TOR har doim ijrochi tomonidan amalga oshiriladi: loyiha menejeri yoki ishlab chiquvchi. Shubhasiz, veb-ishlab chiquvchi veb-saytlar yaratishni kafe yoki stomatologiya klinikasi egasidan ko'ra ko'proq tushunadi. Shuning uchun u loyihani tasvirlashi kerak bo'ladi.

Bu mijoz yo'qoladi degani emas va yozish uchun eng oxirida paydo bo'ladi: "Zbs, men ma'qullayman". Shuningdek, u jarayonda ishtirok etishi kerak:

Albatta, mijoz TK ning o'z versiyasini chizishi mumkin. Ehtimol, bu yakuniy texnik topshiriqni yaratish jarayonini tezlashtiradi. Va, ehtimol, u jimgina axlatga tashlanadigan axlatga aylanadi.

Aniq va aniq yozing

Ushbu maslahat texnik topshiriqning asosiy maqsadi - "Mijoz va pudratchi bir-birini to'g'ri tushunganligiga ishonch hosil qiling" dan kelib chiqadi.

Texnik topshiriqda yuqori sifatli sifatlar bo'lmasligi kerak: chiroyli, ishonchli, zamonaviy. Ularni aniq tushunish mumkin emas. Har bir insonning o'ziga xos go'zallik va zamonaviylik tushunchalari bor.

Qarang. Axir, kimdir bu dizaynni chiroyli deb hisobladi va uni o'z veb-saytida ishlatishga ruxsat berdi:

Xuddi shu narsa - o'z-o'zidan hech narsani anglatmaydigan noto'g'ri so'zlar bilan:

• Sayt mijozga yoqqan bo'lishi kerak. Agar uning kayfiyati yomon bo'lsa-chi?
• Sayt foydalanuvchilarga qulay bo'lishi kerak. Bu nimani anglatadi? Nima uchun qulay?
• Sayt og'ir yuklarga bardosh berishi kerak. 10 ming mehmon? Yoki 10 millionmi?
• Sifatli ekspert kontenti. Xo'sh, siz fikrni tushundingiz.

Matndagi noaniqliklarni tekshiring. Agar mavjud bo'lsa - qayta yozing. Sizning so'zlaringiz aniq va aniq bo'lishi kerak:

• Sayt tezda yuklanishi kerak → Saytning istalgan sahifasi Google PageSpeed ​​​​Insights-da 80 dan ortiq ballga ega bo'lishi kerak.
• Katta yuklar → bir vaqtning o'zida 50 ming mehmon.
• Asosiy sahifada maqolalar ro'yxati ko'rsatiladi → Asosiy sahifada oxirgi 6 ta nashr etilgan maqolalar roʻyxati koʻrsatiladi.
• Minimalistik foydalanuvchi uchun qulay obuna interfeysi → Elektron pochta maydonini qoldiring va Obuna bo'lish tugmasi → *chizilgan eskiz*.

Biz so'zni aniqladik, keling, tuzilmani ko'rib chiqaylik.

Umumiy ma'lumotlarni kiriting

Jamoaning barcha a'zolari kompaniya nima qilayotganini va uning maqsadli auditoriyasi kimligini to'g'ri tushunishlari kerak. Hech kim chalkashmasligi uchun uni texnik topshiriqning boshida belgilash yaxshiroqdir.

Shuningdek, blog o'rniga onlayn-do'konni olmaslik uchun saytning maqsadini ko'rsatish va uning funksionalligini qisqacha tavsiflash kerak.

Qiyin shartlarni tushuntiring

Texnik topshiriqning birinchi qoidasi shundaki, u kim uchun mo'ljallanganligi hamma uchun tushunarli bo'lishi kerak. Agar siz mijozingiz - bolalar o'yinchoqlari do'konining egasi tushunmasligi mumkin bo'lgan atamalardan foydalanmoqchi bo'lsangiz, ularni tushuntirib bering. Oddiy tilda, Vikipediyadan nusxa ko'chirish va joylashtirish emas.

Asboblar va hosting talablarini tavsiflang

Tasavvur qiling-a, siz 2 oy davomida ajoyib veb-sayt yaratyapsiz. Har bir bosqich mijoz bilan kelishilgan - u xursand. Va endi ishni topshirish vaqti keldi. Siz administrator panelini ko'rsatasiz va mijoz baqiradi: “Bu nima? Modex?! Men buni WordPressda qilasiz deb o'yladim!”

Bunday muammolarni oldini olish uchun ishlatiladigan asboblar, dvigatellar va kutubxonalarni tasvirlab bering. Shu bilan birga, hosting uchun talablarni belgilang. Siz buni hech qachon bilmaysiz, siz buni PHP da qilasiz - va mijoz .NETda serverga ega.

Saytga qo'yiladigan talablarni sanab o'ting

Sayt joriy versiyalarning barcha brauzerlarida va barcha turdagi qurilmalarda ishlashi kerak. Ha, bu har qanday ishlab chiquvchi va har qanday mijoz uchun aniq. Ammo mijozni insofsiz bajarilgan ishlardan himoya qilish uchun yozish yaxshidir.

Bu yerda talablarni yozing. saytni yuklash tezligi, yuklarga qarshilik, xakerlik hujumlaridan himoya qilish va shunga o'xshash narsalar.

Sayt tuzilishini belgilang

Dizayn va tartibni chizishdan oldin siz mijoz bilan saytning tuzilishini kelishib olishingiz kerak.

Mijoz bilan suhbatlashing, unga nima kerakligini bilib oling. Ishlab chiquvchilar, SEO mutaxassislari, marketologlar, bosh muharrirlarni to'plang va saytda qaysi sahifalar kerakligini hal qiling. Ular bir-biriga qanday bog'lanishini o'ylab ko'ring, qaysi biriga o'tishingiz mumkin.

Strukturani ro'yxat sifatida ko'rsatishingiz mumkin, blok diagramma chizishingiz mumkin. Istaganingizdek.

Bu saytdagi ishning eng muhim bosqichlaridan biridir. Struktura - bu asos. Agar u muvaffaqiyatsiz bo'lsa, sayt egri bo'lib chiqadi.

Har bir sahifada nima bo'lishini tushuntiring

Mijoz har bir sahifa nima uchun kerakligini va unda qanday elementlar bo'lishini tushunishi kerak. Buni ko'rsatishning ikki yo'li mavjud.

Prototip- ko'proq vizual va aniq yo'l. Pudratchi har bir varaqning eskizlarini chizadi va ularni texnik topshiriqlarga ilova qiladi. Mijoz o'zining bo'lajak saytining interfeysi qanday ko'rinishini ko'radi va u nimani yoqtirishini va nimani o'zgartirish kerakligini aytadi.

Elementlarni sanab o'tish prototipga dangasa muqobildir. Faqat sahifada qanday bloklar bo'lishi kerakligini va ular nima qilishini yozing.

Saytdan foydalanish uchun stsenariylarni yozing

Agar siz biron bir nostandart interfeys yaratayotgan bo'lsangiz, shunchaki struktura va sahifa eskizlarini ko'rsatishning o'zi etarli emas. Butun dastur jamoasi va mijoz tashrif buyuruvchilar saytdan qanday foydalanishini tushunishi muhimdir. Buning uchun skriptlar juda yaxshi. Skript sxemasi juda oddiy:

• Foydalanuvchi harakati.
• Veb-sayt javobi.
• Natija.

Albatta, agar siz standart tashrif qog'ozi yoki ochilish sahifasini yaratayotgan bo'lsangiz, skriptlarni yozishingiz shart emas. Ammo saytda ba'zi interaktiv xizmatlar mavjud bo'lsa, bu juda ma'qul.

Vikipediyada foydalanish holatlari haqida ko'proq o'qing.

Tarkib uchun kim javobgar ekanligini aniqlang

Ba'zi ishlab chiquvchilar darhol kontent bilan sayt yaratadilar. Boshqalar baliqni qo'yishdi. Yana boshqalar matn yozishi mumkin, ammo qo'shimcha haq evaziga. Buni qirg'oqda kelishib oling va texnik topshiriqda qanday tarkibni tayyorlashingiz kerakligini belgilang.

Matnlarning sifatini baholashning ob'ektiv mezonlarini topish juda qiyin. "Maqsadli auditoriya uchun foydali bo'lgan yuqori sifatli, qiziqarli va sotiladigan kontent" dan boshqa hech narsa yozmaslik yaxshiroqdir. Bu axlat, hech kimga kerak emas.

Barcha tarkib noyob bo'lishi kerakligini belgilash foydalidir. Mijozni vijdonsiz ijrochilardan yana bir himoya qilish.

Dizaynni tavsiflang (agar iloji bo'lsa)

Matndagi kabi ob'ektiv baholash mezonlari sayt dizayni o'ylab topish qiyin. Agar siz va mijoz rang sxemasi bo'yicha kelishib olgan bo'lsangiz, uni yozib qo'ying. Agar uning shriftlar ro'yxatdan o'tgan brend kitobi bo'lsa, ularni ham ko'rsating.

Chiroyli va zamonaviy dizayn haqida yozish shart emas. Bu hech narsani anglatmaydi, hech qanday kuchga ega emas va odatda fu.

Xulosa o'rniga: texnik topshiriqning tuzilishi

Turli xil vazifalar uchun TOR tuzilishi boshqacha bo'ladi. Yangi ijtimoiy tarmoq va ulgurji sabzi uchun ochilish sahifasi uchun bir xil texnik xususiyatlarni qilish ahmoqlik. Ammo umuman olganda, sizga shunday bo'limlar kerak:

• Kompaniya va maqsadli auditoriya, saytning maqsad va vazifalari haqida ma'lumot.
• Mijoz tomonidan tushunilmasligi mumkin bo'lgan atamalar lug'ati.
• Saytning joylashuvi va ishlashiga qo'yiladigan texnik talablar.
• Amaldagi texnologiyalar tavsifi va hosting talablari ro'yxati.
• Saytning batafsil tuzilishi.
• Sahifalar prototiplari yoki ularda bo'lishi kerak bo'lgan elementlarning tavsiflari.
• Nostandart interfeysdan foydalanish stsenariylari (ixtiyoriy).
• Ishlab chiquvchi tuzadigan kontent roʻyxati.
• Dizayn talablari (ixtiyoriy).

• Dasturiy ta'minot talablari spetsifikatsiyasini tuzish qoidalari. SRS texnik topshiriqlar evolyutsiyasining navbatdagi bosqichidir. Katta va murakkab loyihalar uchun kerak.
• Dasturiy ta'minotni ishlab chiqish uchun TOR standartlari va shablonlari. Turli GOSTlarning tavsiflari va texnik shartlarni yaratish metodologiyasi.

Bu men yozgan qismning oxiri. Ammo yana bir narsa bor - qo'llanmani yaratishda yordam bergan mutaxassislarning sharhlari. O'qing, bu ham qiziq.

Dasturchilar sharhlari

Men spetsifikatsiyalarni qanday yozishni bilish uchun bir nechta ishlab chiquvchilar bilan gaplashdim. Men mikrofonni ularga uzataman.

Avvalo, mijozga TK kerak - u o'z sayti qanday bo'lishini va pul nimaga sarflanishini tushunishi uchun. Agar biror narsa noto'g'ri qilingan bo'lsa, u TKga murojaat qilishi va uni qayta bajarishni so'rashi mumkin.

TOR mijoz bilan aloqa o'rnatgandan va loyihani dizayner bilan muhokama qilgandan so'ng loyiha menejeri tomonidan tuziladi.

Katta mijozlar ko'pincha har bir tugmani tavsiflovchi juda batafsil texnik xususiyatlarni so'rashadi. Kichik kompaniyalar, aksincha, 100 sahifalik puxta hujjatlarni yoqtirmaydi. Bu uzoq o'qish va muhim narsani o'tkazib yuborish oson. Ko'pincha biz 10-15 sahifa uchun qisqacha texnik tavsiflarni qilamiz.

Biz ko'rsatamiz:

• Kompaniya haqida ma'lumot va saytning maqsadi.
• Dizayn talablari, ranglari.
• Ishlatilgan texnologiyalar va CMS.
• Kontent bilan kim shug'ullanadi - biz yoki mijoz.
• Har bir sahifagacha sayt tuzilishi.
• Har bir sahifaning tavsifi. Biz prototiplar yaratmaymiz, lekin biz sahifada qanday elementlar bo'lishi kerakligini va ular qanday ishlashini aniqlaymiz.

Oxirgi 2 bo'lim eng muhim hisoblanadi. Ular sayt qanday bo'lishi va u qanday ishlashi haqida tushuncha beradi.

Juda muhim nuqta - siz ishlab chiquvchilarga faqat texnik shartlarni berishingiz va ular hamma narsani yaxshi qilishiga umid qilishingiz mumkin emas. TK - bu saytga qo'yiladigan talablar ro'yxati, u aloqa o'rnini bosa olmaydi. Har bir jamoa a'zosi umumiy maqsadni tushunishiga ishonch hosil qilish kerak, va faqat oqim bo'yicha vazifalarni bajarmaydi. Agar biror narsa aniq bo'lmasa - tushuntirish, muhokama qilish, batafsil sharhlar berish kerak.