ترکیب و محتوای شرایط مرجع. چگونه خودتان یک کار فنی بنویسید

چگونه بدون نقض قوانین ضد انحصار آنچه را که نیاز دارید خریداری کنید؟ کلید موفقیت در این کسب و کار یک کار فنی خوب نوشته شده است. در مقاله بخوانید چه تخلفات ضمنی توسط مشتریان انجام می شود.

در حالت کلی، هنگام تنظیم مشخصات تدارکات، مشتری باید بر غیرشخصی بودن کامل شیء توصیف شده نظارت داشته باشد، یعنی نباید دارای هیچ الزامی باشد و حتی اشاره ای به علائم تجاری خاص، تولید کنندگان یا حتی کشور مبدا داشته باشد. کالاها

در واقع، تهیه دقیق شرح موضوع خرید، شرایط مرجع برای 44-FZ، بدون دانش خاص در یک زمینه خاص، بسیار دشوار است. برخی از مشتریان حتی یک تدارکات برای ارائه خدمات برای تهیه شرایط مرجع ایجاد می کنند. اما اگر الزامات مربوط به اشیاء تهیه را به دقت مطالعه کنید، آنها را با نیازهای خود مقایسه کنید و قوانین توصیف موضوع تدارکات را طبق 44-FZ به شدت دنبال کنید، انجام این کار به تنهایی نیز کاملاً واقع بینانه است.

باید در نظر داشت که برخی از ویژگی ها در برچسب گذاری محصولات رمزگذاری شده است. به عنوان مثال، شرایط مرجع برای مواد "صفحه های سنگ فرش" با علامت "Classico 1KO.4" ارائه می شود، شرایط مرجع هیچ الزامی برای ضخامت کاشی تعیین نمی کند. با توجه به رمزگشایی علامت گذاری، ضخامت آن 4 سانتی متر است (آخرین رقم علامت گذاری ضخامت را بر حسب سانتی متر نشان می دهد). اما در حین اجرای کنتاکت مشخص شد که کاشی با ضخامت 6 سانتی متر مورد نیاز است، باری که می تواند تحمل کند بستگی به ضخامت کاشی دارد. شرایط پیش نویس بی سواد پیش نویس منجر به خرید موادی شد که شرایط لازم را برآورده نمی کند. بنابراین، لازم است که برچسب تمام مواد در شرایط مرجع به دقت بررسی شود و تمام الزامات اساسی و مهم برای مواد ذکر شود.

مطلوب توضیحات محصول را از سایت های مختلف کپی نکنید. اطلاعات موجود در توضیحات ممکن است قابل اعتماد نباشد و معلوم شود که هیچ یک از محصولات الزامات ذکر شده را برآورده نمی کند. شانس خوبی وجود دارد که فقط یک محصول با این توضیحات مطابقت داشته باشد. این را می توان به عنوان محدودیت رقابت در نظر گرفت.

همه الزامات عملکرد نباید مبهم باشند. در غیر این صورت درخواست های زیادی برای شفاف سازی وجود خواهد داشت. اغلب اتفاق می افتد که با درخواست های زیاد، مشتری نمی تواند به موقع به آنها پاسخ دهد و ممکن است زمانی برای تنظیم شرایط مرجع وجود نداشته باشد. بر این اساس، گاه مشتری در توضیحات اشاره می کند که فقط کافی است رضایت نامه را ارائه کند، بدون ذکر مواد. به نوبه خود، شانس خرید دقیقاً آنچه مورد نیاز است را کاهش می دهد، زیرا از برنامه مشخص نیست که از چه موادی در اجرای کار استفاده می شود.

بهتر است پس از تشریح الزامات مشخصات فنی، دستورالعمل هایی برای تهیه برنامه بنویسید. این دستورالعمل نباید شرکت کننده را سردرگم کند، بلکه الزامات شرایط مرجع را مشخص می کند تا از درخواست های زیاد شرکت کنندگان جلوگیری شود. مغایرت شرایط مرجع با دستورالعمل ها، که مانعی برای آماده سازی برنامه ایجاد می کند، ممکن است باعث ارسال شکایات به OFAS توسط شرکت کنندگان بالقوه تدارکات شود.

چه الزامات دیگری برای تعیین در شرایط مرجع مهم است:

• با دوره گارانتی کالاها، کارها، خدمات و (یا) محدوده ارائه تضمین کیفیت آنها. مشتری در شرایط مرجع باید یک دوره گارانتی نه کمتر از دوره گارانتی سازنده ایجاد کند.
• به خدمات گارانتی کالا.
• به هزینه بهره برداری محصول.
• نصب و راه اندازی اجباری کالا.
• به آموزش افراد درگیر در استفاده و نگهداری از کالا.

قوانین اصلی

1. هنگام تهیه اسناد تدارکات، به کدهای طبقه بندی کننده محصولات همه روسی (OKPD2) مربوط به موضوع خرید توجه کنید. ضروری است که کد مورد استفاده با شی خرید خاص مطابقت داشته باشد.
2. علاوه بر مفاد 44-FZ، هنگام تدوین شرایط مرجع، باید الزامات سایر قوانین قانونی، مقامات ضد انحصار، هنجارها و استانداردهای فنی (GOST، TU، SNiP و غیره) را نیز در نظر داشت.
3. کالاها و مواد درخواست شده توسط مشتری در شرایط مرجع باید با هدف خرید و اسناد برآورد (در صورت وجود) مطابقت داشته باشد.
4. در هنگام خرید برای قرارداد ساخت و ساز، ضمیمه اظهارنامه معیوب، برآورد و در مورد ساخت سرمایه (بازسازی، تعمیرات اساسی) نیز باید مستندات پروژه ضمیمه شود.
5. نشان دهید که می‌خواهید کالاها و مواد جدید بخرید (یعنی استفاده نشده، تعمیر نشده است، بازسازی نشده است، بازسازی نشده است). در غیر این صورت، مشتری ممکن است کالاهای مستعمل را دریافت کند.

سوالات رایج

سوال:آیا می توان علامت "اورجینال" را برای تامین قطعات یدکی تجویز کرد؟
پاسخ:اگر ما در مورد محصولی صحبت می کنیم که تحت گارانتی است یا نیاز به اطمینان از تعامل چنین کالاهایی با کالاهای مورد استفاده مشتری و همچنین در مورد خرید قطعات یدکی و مواد مصرفی برای ماشین آلات وجود دارد، ممکن است. و تجهیزات

سوال:آیا ذکر کد شناسایی خرید در شرح وظایف الزامی است؟
پاسخ:کد شناسایی تدارکات در طرح تدارکات، برنامه زمانبندی، آگهی تدارکات، دعوت به مشارکت در تعیین تامین کننده (پیمانکار، مجری) که به روش بسته انجام شده است، اسناد تدارکات، در قرارداد و همچنین سایر موارد ذکر شده است. اسناد ارائه شده توسط این قانون فدرال. لازم نیست آن را در TOR مشخص کنید.

سوال:خرید یک دستگاه برای تحقیقات علمی به سیستم موجود 3 دستگاه از یک سازنده ضروری است. لازم است همه چیز را در کار به طور کامل ترکیب کنید. معادل آن مطلوب نیست. آیا نمی توانم معادل آن را بنویسم و ​​سازنده را نشان دهم؟ این سیستم بسیار قابل تنظیم و گران است.
پاسخ:اگر مورد شما تحت عنوان "... به جز در موارد ناسازگاری کالاهایی که علائم تجاری دیگری روی آنها قرار داده شده است، و نیاز به اطمینان از تعامل چنین کالاهایی با کالاهای مورد استفاده مشتری ...) - می توانید در موارد دیگر - نمی تونی

سوال:آیا می توان شاخص های باریکی را در شرایط مرجع برای تعمیر اساسی نشان داد، به عنوان مثال، رنگ دیوارها با یک طرح رنگی خاص، یک نمونه از ترکیب دیوار خشک را روی سقف، مجموعه خاصی از کاشی ها بدون معادل، وصل کنید. اشاره به ترجیحات زیبایی شناختی؟
پاسخ:هنگام تشکیل شرایط مرجع، مشتریان باید با الزامات ماده 33 قانون شماره 44-FZ هدایت شوند. رنگ دیوارها انتخاب مشتری است، این نیاز اوست، نه محدود کردن تعداد تامین کنندگان. یک طرح، طرحی از ترکیب تخته گچ بر روی سقف نیز نیاز مشتری است، همه اجراکنندگان می توانند طرح ارائه شده در اسناد را تکرار کنند. مجموعه ای از کاشی های بدون معادل، نقض بند 1 ماده 33 قانون شماره 44-FZ است: "اسناد تدارکات ممکن است حاوی نشانه ای از علائم تجاری باشد، اگر در اجرای کار، ارائه خدمات، فرض شود. استفاده از کالاهایی که عرضه آن موضوع قرارداد نیست. در عین حال، پیش نیاز درج کلمات "یا معادل" در شرح موضوع تدارکات است.

شرایط مرجع هم برای پیمانکار و هم برای کارفرما مهم است. این به پیمانکار کمک می کند تا درک بهتری از خواسته های مشتری داشته باشد، در برابر "خواسته" های ناگهانی مشتری بیمه شود، تا کار روی کار را سرعت بخشد. به مشتری - دقیقاً آنچه را که می خواهد بگوید، کنترل کیفیت را ساده می کند، تا هزینه دقیق خدمات را دریافت کند. ما به شما خواهیم گفت که چگونه یک TOR را به درستی ترسیم کنید و بعداً با آن چه کاری انجام دهید.

کار فنی چیست

شرایط مرجع - سندی که تمام الزامات یک محصول آینده را منعکس می کند. تمام الزامات فنی را شرح می دهد. معمولاً TK در قالب یک سند متنی و به ندرت در قالب های دیگر کامپایل می شود.

TK توسط همه توسعه دهندگان وب سایت استفاده می شود. برای حروفچین ها، برنامه نویسان، طراحان، به درک بهتر نیازهای مشتری و ایجاد منبعی که انتظارات او را برآورده می کند کمک می کند. علاوه بر این، TK در تمام مناطق دیگر استفاده می شود، به عنوان مثال - در:

• توسعه اپلیکیشن؛
• طراحی خانه؛
• نوشتن متون و دیگران

اگر طبق شرایط مرجع کار کنید، خطر اختلاف و طولانی شدن دعاوی به حداقل می رسد.

نحوه ترسیم یک کار فنی: ساختار مشخصات فنی سایت

قبل از شروع کار:

• تصمیم بگیرید که چه کسی شرایط مرجع را بنویسد
• اصطلاحات را توضیح دهید
• از اصطلاحات ذهنی خودداری کنید

در نگاه اول به نظر می رسد که مشخصات فنی سایت باید توسط مشتری انجام شود، زیرا او منبعی را سفارش می دهد و از آن مطالبات می کند. در واقع، هر دو باید در فرآیند شرکت کنند: مشتری الزامات را بیان می کند، و مجری آنها را به طور خاص، دقیق و واضح می نویسد. به عنوان مثال، مشتری می‌گوید که می‌خواهد سایتی مناسب برای همه کاربران باشد و توسعه‌دهنده الزامات سازگاری را برای 4 اندازه موجود - رایانه‌های شخصی، لپ‌تاپ، تبلت، تلفن‌های هوشمند تجویز می‌کند.

تعریف اصطلاحات بسیار مهم است. توصیه می شود در همان ابتدا تمام اصطلاحات بسیار تخصصی را توضیح دهید - مشتریان همیشه نمی دانند زیرزمین (پانویس)، CMS، ماهی چیست. هر چه توضیحات ساده تر و واضح تر باشد، TOR برای هر دو طرف واضح تر خواهد بود.

اصطلاحات ذهنی می توانند باعث ایجاد اختلافات غیر ضروری شوند. "طراحی باید زیبا باشد" ننویسید - مفهوم زیبایی برای هر کسی متفاوت است. همین امر در مورد صفت های با کیفیت "مناسب"، "استفاده آسان"، "بزرگ" صدق می کند. از اعداد و پارامترهای خاص استفاده کنید: به عنوان مثال، طرح رنگ یا ترتیب عناصر را توصیف کنید.

ساختار کار فنی می تواند هر کدام باشد. به عنوان مثال، ما یک ساختار ساده از TOR برای سایت ارائه می دهیم.

سایت را توصیف کنید

به ما بگویید به چه نوع سایتی نیاز دارید، چه کسی از آن استفاده خواهد کرد، برای چه چیزی ایجاد شده است. برای مثال بنویسید که به یک فروشگاه اینترنتی، یک صفحه فرود برای فروش یک محصول یا یک سایت کارت ویزیت با 10 صفحه نیاز دارید. اگر تعداد صفحات را دقیق نمی دانید، تعداد تقریبی صفحات را ذکر کنید.

اگر پروژه مخاطب هدف خاصی دارد، آن را توصیف کنید. این به ایجاد منبعی کمک می کند که برای مشتریان جذاب باشد - به عنوان مثال، استفاده از زبان مناسب در مقالات یا طراحی که برای جوانان یا افراد مسن تر جذاب باشد.

در مورد ساختار به من بگویید

بدون درک ساختار، ایجاد یک سایت عادی غیرممکن است. توصیف کنید که چه صفحاتی در سایت خواهند بود و سطوح تودرتو آنها را نشان دهید. شما می توانید این کار را به روش های مختلف انجام دهید:

• طرح
• جدول
• فهرست

نکته اصلی این است که در پایان مشخص است که کدام صفحات در منو قرار می گیرند، کجا هدایت می شوند، هر بخش دارای کدام صفحه اصلی است. ما توصیه می کنیم از فلوچارت ها استفاده کنید - آنها ساده تر و راحت تر از لیست ها و جداول خوانده می شوند، آنها به ارزیابی کل ساختار سایت در چند ثانیه کمک می کنند.

توضیح دهید که در هر صفحه چه خواهد بود

به ما بگویید چگونه صفحات سایت را می بینید. مطلوب است که این کار را در قالب نمونه اولیه انجام دهید تا مکان هر عنصر به وضوح نشان داده شود. شما همچنین می توانید الزامات را با یک لیست توصیف کنید، به عنوان مثال - بگویید چه چیزی در سربرگ سایت، جایی که فرم بازخورد قرار دارد، چه چیزی در ستون سمت آزاد وجود دارد.

اگر تمام صفحات سایت تقریباً مشابه هستند - به عنوان مثال، شما قصد دارید یک سایت کارت ویزیت ایجاد کنید، می توانید با دو نمونه اولیه: برای صفحه اصلی و بخش های دیگر، از پس آن برآیید. اگر چندین گروه از صفحات مشابه وجود دارد - به عنوان مثال، بخش هایی در کاتالوگ یک فروشگاه آنلاین، وبلاگی با مقالات و شرح خدمات تحویل / مونتاژ / نصب، بهتر است برای هر گروه نمونه اولیه خود را بسازید.

خواسته های طراحی را ایجاد کنید

اگر یک طرح توسعه یافته وجود دارد، عالی است - می توانید به سادگی آن را در شرایط مرجع قرار دهید. اگر نه، باید الزامات رنگ ها، تصاویر استفاده شده، آرم ها را شرح دهید. مثلا:

• مشخص کنید که کدام رنگ های شرکتی را می توان در طراحی استفاده کرد و کدام سایه ها مطلقاً نیستند
• ارائه یک لوگو، که باید در هدر سایت وجود داشته باشد
• فونت هایی را که می خواهید برای طراحی صفحات، منوها، فوترها، محتوا استفاده کنید، مشخص کنید

اگر الزامات واضحی وجود نداشته باشد - یعنی مشتری خودش نمی تواند دیدگاه خود را از سایت فرموله کند، می توانید چندین طرح بندی استاندارد را برای انتخاب یا توسعه یک طرح بندی فردی به او پیشنهاد دهید و سپس روی آن توافق کنید. این کار باید قبل از تایید TOR انجام شود، در غیر این صورت تفاوت سلیقه ها می تواند پروژه را به طور قابل توجهی به تاخیر بیندازد.

الزامات ابزار، کد، هاست، دامنه را شرح دهید

این برای اینکه از قبل بدانید با چه ابزارهایی می توانید کار کنید و چه ابزارهایی را نمی توانید کار کنید، ضروری است. در یک بلوک جداگانه توضیح دهید:

• کدام سایت باید در آن باشد - وردپرس، جوملا، مدکس و غیره
• از چه زبان برنامه نویسی می توان استفاده کرد - PHP، جاوا اسکریپت، HTML و دیگران
• سایت در چه میزبانی و در چه دامنه ای باید قرار گیرد، از چه نام دامنه ای می توان استفاده کرد
• از چه پلتفرم نرم افزاری می توان استفاده کرد - .NET، OpenGL، DirectX
• و غیره

اگر کلاینت از عبارات استفاده شده چیزی نمی فهمد، توضیح دهید که چگونه وردپرس با Modex، PHP با HTML، دامنه در منطقه .ru از دامنه در منطقه .com متفاوت است. با هم، الزامات را طوری تنظیم کنید که برای مشتری مناسب باشد.

الزامات سایت را مشخص کنید

به طور پیش فرض، سایت باید برای کاربران همه دستگاه ها، در مرورگرهای مختلف کار کند، در برابر حملات هکرها مقاومت کند و زمانی که 1000 کاربر همزمان از آن بازدید می کنند، بیدار بماند. اما بهتر است آن را در یک بلوک جداگانه بنویسید. مشخص كردن:

• سرعت بارگیری سایت قابل قبول برای شما یا یک مقدار استاندارد - 1-5 ثانیه
• سازگاری بین مرورگرها - توضیح دهید که سایت باید در کدام مرورگر باز شود
• پاسخگویی - اندازه صفحه نمایشی که طراحی باید با آن سازگار باشد و دستگاه های مورد استفاده را مشخص کنید
• مقاومت بار - چند نفر باید همزمان در سایت باشند تا "دراز نکشند"
• مقاومت در برابر حملات هکر و dDos: سایت باید در برابر حملات کوچک مقاومت کند

سناریوهای سایت را بنویسید

توضیح دهید که کاربر چگونه باید با سایت تعامل داشته باشد و چه اقداماتی باید در پاسخ روی منبع انجام شود. این را می توان در قالب یک لیست شماره گذاری شده ساده یا یک الگوریتم شاخه ای انجام داد اگر کاربران بین اقدامات انتخابی داشته باشند. اگر خدمات تعاملی زیادی وجود دارد، برای هر یک از آنها یک اسکریپت بنویسید.

ببینید چه کسی محتوا را انجام می دهد.

برخی از توسعه دهندگان خود متن می نویسند، کسی آنها را به کپی رایترها سفارش می دهد، شخصی از ماهی استفاده می کند. فوراً مشخص کنید که آیا ارائه محتوا در سرویس توسعه گنجانده شده است یا خیر. اگر چنین است، می توانید بلافاصله شرایط اضافی را تجویز کنید، به عنوان مثال، برای:

• - طبق Advego، Text.ru، Content.Watch، نه کمتر از 95٪
• تهوع (هرزنامه) - طبق Advego بیش از 10٪ یا طبق Text.ru 65٪
• امتیاز برای Glavred - حداقل 6.5 یا 7 امتیاز

البته، خدمات مختلف نوشدارویی نیستند، اما خطر «آبی» یا اسپم شدن آن را به حداقل می‌رسانند. علاوه بر این، معیارهای دقیقی برای ارزیابی کیفیت متون به این صورت ظاهر می شود.

شرایط را مشخص کنید

این اغلب فراموش می شود. بیشتر شرایط مرجع باید شرایط را مشخص کنند، در غیر این صورت توسعه ممکن است چندین ماه، نیم سال، سال به طول انجامد. از عبارت نادرست استفاده نکنید - به عنوان مثال، "در یک ماه". تاریخ دقیق را بنویسید: مثلا 1 دسامبر 2018.

هک زندگی:بهتر است شرایط کار به عنوان ضمیمه توافقنامه همکاری تنظیم شود. بنابراین شما تمام الزامات توسعه سایت را برطرف می کنید و در صورت اختلاف می توانید پرونده را در دادگاه برنده شوید.

به یاد داشته باشید: در هر TK باید چندین بلوک اصلی وجود داشته باشد:

• اهداف و اهداف - در مورد اینکه چرا به طور کلی TK را ایجاد کردید، چه کاری می خواهید با محصول انجام دهید
• محصول چه چیزی باید باشد - یک توضیح در شرایط کلی
• الزامات فنی - مساحت خانه، مقدار متن، عملکرد برنامه، و غیره
• مهلت ها - آنها برای از بین بردن اختلافات مهم هستند.

نمونه ای از تهیه مشخصات فنی نرم افزار

باید نرم افزار بسازیم. الزامات فنی - زیر.

شرح: برنامه ای برای جستجوی مقالات بر اساس کلمه کلیدی در تمامی سایت های معتبر، باید آدرس سایت های معتبر را به صورت دستی وارد کنید.

کاری که نرم افزار باید انجام دهد:پس از وارد کردن یک کلمه کلیدی، مقالاتی را در سایت هایی پیدا می کند که از قبل به عنوان منابع معتبر وارد شده اند، لیستی از موارد مشابه را در این قالب نمایش می دهد:

• ارتباط دادن
• عنوان مقاله
• پاراگراف اصلی

اگر بیش از 10 مورد منطبق وجود دارد، باید به صفحات تقسیم کنید - 10 صفحه در هر کدام.

الزامات فنی:زبان برنامه نویسی - هر چه باشد، مهم نیست. نکته اصلی این است که برنامه می تواند نهایی شود و به عنوان یک سرویس آنلاین ارائه شود. در حالت ایده آل، سرویس باید 10 ثانیه جستجو کند.

زمان سنجی: تا تاریخ 1397/09/15.

به طور طبیعی، این TOR را می توان بهبود بخشید - ما آن را به عنوان مثال ارائه کردیم. و به نظر شما چگونه می توان شرایط مرجع را بهبود بخشید تا حتی واضح تر، ساده تر و راحت تر شود؟

در زندگی، اغلب اتفاق می افتد که یک فرد نمی تواند آنچه را که می خواهد، حتی در امور روزمره توضیح دهد. وقتی صحبت از توضیح «خواسته‌های» خود به یک برنامه‌نویس می‌شود، یک فرد به سادگی دچار بی‌حوصلگی می‌شود.

در حالت ایده آل، TK باید توسط مشتری تهیه شود - فقط او می داند که به چه چیزی نیاز دارد. اما در عمل، به دلیل صلاحیت کم مشتری در زمینه 1C، اغلب این کار باید توسط پیمانکار انجام شود. مشتری نیازهای خود را به صورت شفاهی بیان می کند و برنامه نویس (مشاور) این موضوع را به صورت کتبی رسمی می کند.

چرا یک مشخصات مورد نیاز است؟

در حالت ایده آل، هر یک باید با یک کار فنی همراه باشد. این اولاً تعریف روشنی از وظیفه، مهلت‌ها و روش اجراست. ثانیاً سندی است که با کمک آن تمام اختلافات در آینده حل می شود. البته این به شما بستگی دارد که مشخصات فنی بنویسید یا نه؛ برای من شخصاً مشخصات فنی کار و ارتباط با مشتری را آسان می کند.

267 درس ویدیویی 1C را به صورت رایگان دریافت کنید:

شرایط مرجع باید شامل چه مواردی باشد؟

آن ها تکلیف باید شامل موارد زیر باشد:

• هدف- وظیفه ای که با اجرای این TOR حل خواهیم کرد.
• شرح- خلاصه ای از پیشرفت های آینده؛
• روش پیاده سازی- شرح مفصلی از روش های حل هدف. در این مرحله، لازم است تمام تفاوت های ظریف کار را در زبان برنامه نویسی شرح دهیم: چه چیزی، ما ایجاد / ویرایش می کنیم، رابط چگونه باید به نظر برسد و غیره. اگر "زبان برنامه نویسی" را نمی دانید، اما "چیزی شنیده اید"، بهتر است سعی نکنید به زبان فنی بنویسید - معلوم می شود که بسیار سرگرم کننده است. توضیحات باید بدون ابهام باشد و باعث سوال نشود. همچنین ممکن است شامل نمونه ای از اجرای یک راه حل مشابه در منطقه دیگری باشد.
• ارزیابی عملکرد- یک نکته بسیار مهم، شرح هزینه های نیروی کار.

همچنین استانداردهای دولتی برای نوشتن مشخصات فنی - GOST ها وجود دارد. در عمل، آنها به ندرت در جایی استفاده می شوند، اما اتفاق می افتد که مشتری بر این امر اصرار می کند.

بر اساس تجربه، هنگام واگذاری کار، موقعیت‌هایی مانند «آن موقع به شما گفتیم…» اغلب پیش می‌آید که خیلی خوشایند نیست، و اغلب مجبور می‌شوید کار را دوباره انجام دهید. بنابراین، یک TOR خوب نوشته شده تا حد زیادی زندگی هر دو طرف را تسهیل می کند.

نمونه ها و نمونه های TK برای 1C

مجموعه کوچکی که به صورت رایگان در شبکه موجود است. شروع از ساده ترین و در دسترس ترین، پایان دادن به اسناد نسبتاً پیچیده.

بسیاری از شرکت ها حاضر نیستند در مرحله نوشتن شرایط مرجع، پیمانکاران را درگیر کنند و معتقدند که هر پیمانکار سندی را می نویسد که فقط برای کارمندان خود قابل درک باشد و در واقع موقعیت ممتاز خود را در رقابت/مناقصه تضمین می کند.

این تا حدی درست است، اما در بسیاری از موارد این پدیده نه چندان با منافع تجاری پیمانکاران، بلکه با تفاوت در رویکرد اجرای این سند مرتبط است.

تعریف شرایط مرجع در ویکی‌پدیا، به ویژه، بیان می‌کند که این «سندی است که شامل الزامات مشتری برای موضوع خرید، تعریف شرایط و روش اجرای آن برای رفع نیازهای ایالتی یا شهرداری است، که مطابق با آن تحویل کالا، انجام کار، ارائه خدمات و پذیرش آنها.

علاوه بر این، تعدادی GOST وجود دارد، به عنوان مثال، 19.201-78، که توضیح می دهد که چه چیزی و به چه شکل باید در چنین سندی باشد.

با این حال، همانطور که تمرین نشان می دهد، مخفف مورد علاقه "TK" به اسنادی اشاره دارد که در ماهیت، محتوا، طراحی و جزئیات کاملاً متفاوت هستند. متأسفانه، بسیاری از مشتریان مطمئن هستند که پس از نوشتن چند صفحه از الزامات یک سیستم آینده، یک برآورد دقیق (با حداکثر دلتا 10-20٪) با یک برنامه کاری از ما دریافت خواهند کرد. بار دیگر، هنگامی که در نامه ای "TK، که طبق آن تا فردا باید CP را ارزیابی و ارسال کنید" دریافت می کنم، همیشه ذهنی آماده می کنم تا خلق بعدی را به سبک "سیستم باید تمام اطلاعات لازم را مبادله کند" را ببینم. با سایت».

زمانی، در بخشی که من کار می کردم، بخش زیر به تصویب رسید: شرایط مرجع سندی بود که الزامات سیستم را به زبانی قابل فهم برای کاربران تجاری توصیف می کرد، و طراحی فنی سندی بود که بر اساس آن تنظیم شده بود. از شرایط مرجع، با جزئیات بیشتر، همه عملکردها را با جزئیات توصیف می کند، اما در حال حاضر به زبانی قابل درک عمدتاً برای توسعه دهندگان است.

به نظر من، این توصیف، اگرچه از نظر رسمی درست نیست، اما برای شرکت های کوچکی که بودجه اضافی ندارند، بسیار منصفانه به نظر می رسد، اما وظایفی وجود دارد که نیاز به راه حل های فوری دارد. نکته اصلی برای آنها تدوین مشخصات فنی توسط کارمندان و توزیع آن به عنوان مثال در چندین شرکت صاحب امتیاز است. و طبیعی است که هیچ کس یک برگه عظیم حاوی حجم باورنکردنی اطلاعات فنی نخواهد نوشت.

بنابراین چگونه می توان یک مشخصات فنی ایجاد کرد که بر اساس آن در پایان دقیقاً مشخص شود که توسط نویسنده (های) آن تعیین شده است و نه آنچه "عملکرد پیکربندی معمولی می تواند انجام دهد"؟

من الزامات اساسی برای ساختار سند را شرح نمی دهم، مانند: اهداف پروژه باید در TOR توضیح داده شود، الزامات عملکردی باید شامل شود، باید فهرستی از اختصارات و فهرست مطالب وجود داشته باشد، همه چیز باید وجود داشته باشد. با ساده ترین و کوتاه ترین عبارات و غیره نوشته شود. فکر می کنم همه کسانی که حداقل چند بار مشخصات فنی را خوانده اند این را می دانند.

اسنادی که باید با آنها سر و کار داشتم و بر اساس آنها نتایج تا حد امکان نزدیک به ایده به دست آمد، دارای ویژگی های زیر بود:

1. TK به عنوان یک دستورالعمل. سند در ساختار خود شبیه یک کتابچه راهنمای کاربر است که در آن مرحله به مرحله نوشته می شود که در این صورت کاربر باید چه اقداماتی را انجام دهد تا به نتیجه مطلوب برسد. آن ها اینها اسنادی بودند که لیست مستمری از عملکردهای مورد نیاز را نداشتند، اما با یک تفکیک منطقی به فرآیندهای جداگانه همراه با شرح مشخصات آنها.

2. تجسم بیشتر. هرچه طرح‌بندی/عکس‌ها/مکاپ‌ها/فلوچارت‌های یک سند بیشتر باشد، احتمال کمتری برای دریافت سیستمی وجود دارد که به نظر می‌رسد عملکردهای لازم را انجام می‌دهد، اما منطق/طراحی/رابط کاملاً متفاوتی دارد.

3. قابلیت استفادهاز دو نکته قبلی، یک نتیجه ساده وجود دارد - منطق روشن کار و حداکثر تجسم سیستم آینده در نهایت به قرار دادن تعداد مورد نیاز یادداشت ها / نکات در مورد قابلیت استفاده سیستم در TOR کمک می کند. برای سیستم هایی که کارکنان کم مهارت با آنها کار می کنند، این می تواند یک عامل تعیین کننده در موفقیت پروژه باشد (البته، این پارامتر برای مدیریت ارشد که نمی خواهد با "این برنامه های حسابداری" سر و کار داشته باشد نیز بسیار مهم است). به عنوان مثال، TOR برای یک سیستم خرده فروشی مشخص نکرده است که جستجو برای یک مقاله نباید بیش از سه ثانیه طول بکشد. اگر سیستم از طریق یک جستجوی پیکربندی معمولی پیاده‌سازی شود، می‌تواند به موقعیت‌های بحرانی در عملیات واقعی منجر شود، زیرا با در نظر گرفتن تعداد موارد، این جستجو تا 30 ثانیه طول کشید، که در هنگام کار با مشتریان خرده‌فروش غیرقابل قبول است، جایی که هر ثانیه مهم است.

4. پیوند به راه حل های محبوب. اغلب برای همه، مثلاً مدیران فروش شرکت، عبارت «عملکرد معاملاتی» تقریباً به همین معنی است، اما برای کارمندان پیمانکار این عبارت مطلقاً معنی ندارد. اما چند کلمه به این عبارت اضافه کنید و از گزینه "کارت معامله مشابه آن در Bitrix24 (یا 1C: CRM)"، از قبل مشخص است که مشتری از همین کارت چه انتظاری دارد.

5. بازخورد اولیه. یک بار دیگر تکرار می کنم - برای اجرای موفقیت آمیز TK، لازم نیست آن را مطابق با GOST بنویسید. نیازی به نوشتن سندی نیست که فقط برای متخصصان فنی در نظر گرفته شده است. شرح وظایف ابتدا باید برای همکاران سازنده آن و سپس برای کسانی که آن را اجرا می کنند روشن باشد. دریافت بازخورد مثبت از کاربران تجاری قبل از ارسال سند به پیمانکاران بالقوه یا توسعه داخلی بسیار مهم است. سندی که برای یک نفر بسیار واضح است، اما حتی برای نزدیکترین محیط قابل درک نیست، هیچ شانسی برای اجرای موفقیت آمیز ندارد.

البته در مورد الزامات تهیه TOR دیدگاه های مختلفی وجود دارد. با این حال، در غیاب زمان، منابع و شایستگی های مناسب، این شرایط مرجعی است که با قابل فهم ترین زبان برای کاربران تجاری نوشته شده است که دارای ویژگی های فوق است که حداکثر شانس را برای اجرای موفقیت آمیز خواهد داشت.

آیا نمی خواهید هنگام پذیرش یک سایت از یک توسعه دهنده کاملاً ناامید شوید؟ سپس این مقاله را با دقت بخوانید!

اما شاید این تقصیر او نیست؟ از این گذشته، نه تنها مجری، بلکه مشتری نیز مسئول نتیجه هر تفویض است.

برای به دست آوردن حداکثر نتیجه مطلوب، باید بدانید که چگونه یک کار فنی برای ایجاد یک وب سایت به درستی ترسیم کنید.

چرا به وظیفه نیاز دارید؟

• پیمانکارمشخصات فنی مناسب برای توسعه سایت به تخمین میزان کار، پیچیدگی و هزینه آن کمک می کند. برای درک اینکه آیا او به تنهایی از عهده چنین کاری بر می آید یا ارزش گرفتن دستیار را دارد. و سپس دقیقاً همان چیزی را انجام دهید که مشتری از او انتظار دارد.
• مشتریشرایط مرجع اطمینان می دهد که او خواسته های خود را برای سایت آینده مستند کرده است، مهلت هایی را که پیمانکار باید رعایت کند، به وضوح مشخص کرده است، الزامات سایت را تجویز می کند. و اگر نتیجه رضایت بخش نبود، می توانید یک ادعای معتبر داشته باشید: "با TOR ملاقات نمی کند!"

آنها در شرایط مرجع چه می نویسند؟

تکلیف به سوالات زیر می پردازد:

• چرا و برای چه کسی سایت ایجاد شده است؟
• با چه چیزی پر خواهد شد؟
• این همه چگونه عمل خواهد کرد؟
• چه کسی و چگونه روی پروژه کار خواهد کرد، چه کسی مسئول چه چیزی است؟
• خروجی چه خواهد بود؟

بخش های اصلی شرایط مرجع برای توسعه سایت

1. اطلاعات در مورد مشتری، یعنی در مورد شما

تا حد امکان جزئیات را ارائه دهید. همه منابعی را که توسعه‌دهنده می‌تواند داده‌های از دست رفته را دریافت کند، مشخص کنید. اینها می توانند جزوات، پوسترها، مواد الکترونیکی، پیوندها، مخاطبین افرادی باشند که می توان از آنها سؤال کرد.

2. اطلاعات در مورد پروژه

چه خواهد بود: یک سایت کارت ویزیت، یک وبلاگ، یک فروشگاه آنلاین، یک پورتال شرکتی، یک کتابخانه الکترونیکی؟

3. مخاطبان هدف سایت

مخاطبان هدف خود را توصیف کنید، بگویید به چه چیزی نیاز دارند و چگونه می توانند علاقه مند شوند.

4. اهداف و وظایفی که سایت باید برای مشتری و برای مخاطب حل کند

شما باید به وضوح درک کنید که چرا به یک وب سایت نیاز دارید. برای تقویت تصویر؟ برای فروش مستقیم؟ برای خبر؟ آیا می خواهید بازدیدکنندگان را با وب سایت خود به مشترک تبدیل کنید؟ آیا می خواهید منبعی برای جذب شرکای بالقوه ایجاد کنید؟

هدف مستقیم سایت خود را مشخص کنید.

در مورد وظایف فردی یک منبع وب با دقت فکر کنید. به عنوان مثال، باید اطلاعات به روز در مورد اخبار بازار ارائه دهد، محصولات شما را به نمایش بگذارد، به بازدیدکنندگان اجازه دهد مستقیماً از صفحات سایت با شما تماس بگیرند و غیره.

5. چارچوب پروژه (عملکرد اصلی)

این سایت می تواند تعداد زیادی کارکرد داشته باشد: فرم ثبت نام کاربر، بازخورد، دکمه های سفارش، تقویم تحویل، فید اخبار، کاتالوگ محصول با قابلیت رفتن به سبد خرید، اسکریپت پستی داخلی، بخش های بسته برای مشتریان - هر چه باشد! هر یک از این توابع در شرایط مرجع برای توسعه سایت شما باید به دقیق ترین شکل بیان شود.

بنابراین، بخش "حوزه پروژه" چیزی شبیه به فهرست مطالب است که توابع را بدون شرح دقیق آنها فهرست می کند. در مرحله جستجوی هنرمند به این بخش نیاز خواهید داشت. این به خالق بالقوه سایت شما اجازه می دهد تا تصویر بزرگ را ببیند و قیمت تقریبی را ارائه دهد، در حالی که شما خواسته های خود را برای عملکرد سیستماتیک می کنید.

6. ساختار (نقشه) سایت

پاراگراف بعدی TOR برای سایت به پیمانکار می گوید که کدام صفحات در سایت شما، کدام بخش ها و زیربخش ها، چگونه به یکدیگر متصل می شوند، چگونه در منوی سایت نمایش داده می شوند.

ترسیم ساختار آسان تر از توصیف است. در شکل گرافیکی، فکر کردن به رابطه بین مناطق سایت آسانتر است.

7. صفحات مجزا

در حالی که نقشه سایت را ترسیم می کنید، هر صفحه فقط یک مربع است. اما مجری باید بداند که چه چیزی و به چه ترتیبی در این مربع قرار می گیرد (نمونه هایی از جداول را در ابتدای مقاله به یاد بیاورید). چه بلوک های اطلاعاتی وجود خواهد داشت؟ آیا منوها، نوارهای کناری در هر صفحه وجود خواهد داشت؟ (بلوک جداگانه با ناوبری)، پاورقی (بلوک پایین)? آیا می خواهید بنرها، تصاویر را در صفحه ببینید؟ آیا آنها ثابت خواهند بود یا متحرک؟

هرچه جزئیات هر عنصر از هر صفحه از منبع آینده را توصیف کنید، نتیجه خروجی به ایده های شما در مورد سایت نزدیک تر خواهد بود.

8. الزامات طراحی سایت

در مورد طرح رنگ تصمیم بگیرید، به ما بگویید چه رنگ هایی را ترجیح می دهید. مواد موجود را در اختیار توسعه‌دهنده قرار دهید: لوگو، بنرها، کدهای رنگ... نمونه‌هایی از سایت‌های فعال در اینترنت را به او نشان دهید که دوست دارید و چیزی مشابه می‌خواهید. به ما بگویید چه رنگ هایی را ترجیح می دهید. به عنوان مثال، شما می خواهید یک وب سایت اختصاصی برای آموزش بانوان بسازید، طراح آن را صورتی می کند، اما شما نارنجی را دوست دارید. شرح کلی خواسته ها به شما کمک می کند بین دیدگاه خود و ظاهر حرفه ای طراح سازش پیدا کنید.

9. عملکرد کاری سایت

با جزئیات توضیح دهید که چه عملکردی را می خواهید در سایت مشاهده کنید. تا حد امکان به مجری اطلاعات بدهید. به یاد داشته باشید که او استعداد تله پاتی را ندارد و ممکن است زمانی که در شرایط مرجع سایت می نویسید، حدس نزند که می خواهید چه چیزی به دست آورید. "فرم اشتراک"یا "تقویم".

چه فرمی؟ برای چی؟ چه اقلامی باید در آن باشد؟ او چطور به نظر می رسد؟ ممکن است مجری این تفاوت های ظریف را حدس نزند، در نهایت چیزی کاملا متفاوت از آنچه می خواستید دریافت خواهید کرد. پول پرداخت شده است، پروژه با TOR مطابقت دارد (شما نوشتید "تقویم"- اینجاست) و باید از اتفاقی که افتاده راضی باشید، اگرچه این اصلاً آن چیزی نیست که می خواستید یا برای تغییرات بیش از حد پرداخت کنید.

10. شرح محتوا

اگر همزمان با ایجاد سایت، محتوا را سفارش می دهید و یک پیمانکار (مثلاً یک آژانس) دارید، توضیحات محتوا یک TOR جداگانه برای کپی رایتر است. اگر می‌خواهید خودتان محتوا ایجاد کنید یا از هنرمند دیگری سفارش دهید، توسعه‌دهنده سایت هنوز باید ایده داشته باشد که در کدام بخش قرار می‌گیرد و چگونه به نظر می‌رسد. متن کجاست، ویدیو کجاست، تصاویر چگونه طراحی می‌شوند، آیا پیش‌نمایش مقالات مورد نیاز است و چه خواهد بود و غیره.

11. الزامات فنی

یک نکته دشوار برای کسانی که در سایت سازی کم می فهمند.

اگر متوجه نشدید منطق را روشن کنید.

به عنوان مثال، سایت شما باید:

• در نمایشگرهایی با عرض های مختلف به همان اندازه خوب به نظر می رسند (طراحی پاسخگو).
• سئو برای ارتقاء بهینه سازی شده باشد.
• قادر به مقاومت در برابر ویروس ها باشد.
• دارای قابلیت سئو داخلی و غیره هستند.

فقط در مورد آنچه مطمئن هستید بنویسید یا با یک متخصص مشورت کنید. بهتر است از قبل مشورت کنید تا اینکه بعداً برای بهبودها هزینه اضافی پرداخت کنید.

اگر تصمیم دارید با ما تماس بگیرید و شرایط مرجع خود را ندارید، می توانید شرایط ما را دانلود و پر کنید.