✨ خلاصه هوش مصنوعی
- انتخاب یک شرکت توسعه بلاکچین قابل اعتماد، چیزی بیش از بررسی پروژههای موفق یا یک وب‌سایت چشمگیر است.
- این امر مستلزم درک چگونگی تصمیم‌گیری‌های معماری توسط تیم، مدیریت یکپارچه‌سازی‌ها، مدیریت امنیت و پاسخگویی به مشکلات پس از استقرار است.
- یک شرکت معتبر نه تنها باید نشان دهد که چه چیزی می‌تواند بسازد، بلکه باید توضیح دهد که چرا یک رویکرد خاص برای کسب و کار شما مناسب است.
- تفکیک تجربه تحویل واقعی از بازاریابی سبد کالا بسیار مهم است.
- یک نمونه کار چشمگیر تضمین نمی‌کند که شرکت بتواند آنچه را که کسب و کار شما نیاز دارد، ارائه دهد.
یک شرکت توسعه بلاکچین می‌تواند یک وب‌سایت چشمگیر، نمونه‌کاری پر از پروژههای موفق و فهرستی از شبکه‌های پشتیبانی‌شده ارائه دهد. اما چه مقدار از این موارد، توانایی آن را در ساخت سیستمی که کسب‌وکار شما واقعاً بتواند به آن متکی باشد، نشان می‌دهد؟
آزمون واقعی زمانی آغاز میشود که از مرحله‌ی فروش فراتر می‌روید. آیا تیم می‌تواند تصمیمات معماری خود را توجیه کند؟ آیا می‌تواند تجربه‌ی تولید مرتبط را نشان دهد؟ چگونه قراردادهای هوشمند را ایمن می‌کند، یکپارچه‌سازی‌ها را مدیریت می‌کند و در صورت بروز مشکل پس از استقرار، چگونه واکنش نشان می‌دهد؟
این سوالات مهم هستند زیرا تصمیمات مهندسی بلاکچین می‌تواند بر امنیت، مقیاسپذیری، هزینه‌های عملیاتی و قابلیت نگهداری طولانی‌مدت محصول شما تأثیر بگذارد. اشتباهی که پس از راه‌اندازی کشف شود می‌تواند بسیار گران‌تر از اشتباهی باشد که در طول معماری و آزمایش کشف شود.
درک چگونگی انتخاب یک شرکت توسعه بلاکچین به معنای یادگیری تمایز قائل شدن بین توانایی فنی و ادعاهای بازاریابی است. هدف، یافتن فروشنده‌ای نیست که همه چیز را وعده می‌دهد. هدف، شناسایی شریکی است که بتواند تخصص خود را اثبات کند، تصمیمات خود را توضیح دهد و نشان دهد که چگونه ریسک‌های تحویل را مدیریت خواهد کرد.
در اینجا هفت بررسی حیاتی وجود دارد که باید قبل از سپردن پروژه خود به یک شریک توسعه انجام دهید.
فراتر از لوگوهای فناوری را ببینید: تخصص مهندسی تیم را تأیید کنید
تقریباً هر شرکت توسعه بلاکچین ادعا می‌کند که در قراردادهای هوشمند، برنامه‌های غیرمتمرکز، بلاکچین سازمانی و شبکه‌های بلاکچین چندگانه تخصص دارد. با این حال، فهرستی از فناوری‌ها مشخص نمی‌کند که مهندسان آن چقدر عمیق آنها را درک می‌کنند.
ساخت یک برنامه غیرمتمرکز روی یک شبکه مستقر، تفاوت قابل توجهی با توسعه یک بلاکچین لایه ۱، مهندسی یک پیاده‌سازی لایه ۲ یا طراحی یک شبکه سازمانی دارای مجوز دارد. هر کدام شامل تصمیمات معماری، فرضیات امنیتی، محدودیت‌های عملکرد و مسئولیت‌های عملیاتی متفاوتی هستند.
یک تیم معتبر از نظر فنی نه تنها باید توضیح دهد که چه چیزی می‌تواند بسازد، بلکه باید توضیح دهد که چرا یک رویکرد خاص برای کسب و کار شما منطقی است.
چه چیزی تخصص فنی را از لیست خدمات متمایز می‌کند؟
- تصمیمات معماری: آیا تیم می‌تواند رویکرد خود را در مورد اجماع، اجرا، قابلیت همکاری و در صورت لزوم، در مورد دسترسی به داده‌ها توضیح دهد؟
- تسلط بر چارچوب: آیا با استفاده از چارچوبهای مورد نیاز پروژه شما، کار را تحویل داده است یا تخصص آن فقط در صفحه قابلیت‌ها وجود دارد؟
- برنامهریزی مقیاسپذیری: آیا می‌تواند توان عملیاتی تراکنش‌ها، تأخیر، الزامات زیرساختی و هزینه‌های عملیاتی پیش‌بینی‌شده را ارزیابی کند؟
- بده بستان‌های فنی: آیا مهندسان می‌توانند توضیح دهند که چرا یک معماری را به دیگری ترجیح می‌دهند و هر گزینه چه محدودیت‌هایی را ایجاد می‌کند؟
- پاسخگویی مهندسی: آیا معماران باتجربه و رهبران فنی در طول پیاده‌سازی و استقرار همچنان درگیر خواهند بود؟
از تیم پیشنهادی بخواهید که شما را در یک پروژه مشابه پروژه شما راهنمایی کند. روی محدودیت‌های اولیه، گزینه‌های در نظر گرفته شده، تصمیمات گرفته شده و درس‌های آموخته شده تمرکز کنید.
یک شرکت توسعه بلاکچین قابل اعتماد ، برای هر مشکل تجاری، فناوری یکسانی را توصیه نمی‌کند. این شرکت قبل از ارائه راه‌حل، نیازهای شما را ارزیابی می‌کند.
چه مواردی را باید بررسی کنید: درخواست یک گفتگوی فنی با مهندسانی که روی پروژه شما کار می‌کنند، داشته باشید. توانایی آنها در توضیح بده بستان‌ها، وابستگی‌ها و محدودیت‌های معماری، اطلاعات بیشتری نسبت به یک ارائه قابلیتهای بی‌نقص به شما خواهد داد.
شریک مهندسی مناسب برای پروژه بلاکچین خود را پیدا کنید.
تجربه تحویل واقعی را از بازاریابی سبد سهام جدا کنید
یک نمونه کار می‌تواند بدون اثبات اینکه یک شرکت، نوع سیستمی را که کسب و کار شما نیاز دارد، ارائه داده است، چشمگیر به نظر برسد.
اسکرین‌شات‌ها، نمایش‌های محصول و خلاصه‌های کوتاه پروژه می‌توانند نشان دهند که یک راه‌حل چگونه است. اما لزوماً مشخص نمی‌کنند که آیا به مرحله تولید رسیده، حجم کار واقعی را مدیریت کرده یا نتیجه تجاری اعلام شده را ارائه داده است یا خیر.
هنگام ارزیابی یک شرکت توسعه بلاکچین ، بین اثبات مفهوم، استقرار شبکه آزمایشی و سیستم تولید تمایز قائل شوید. هر کدام نشان دهنده مرحله متفاوتی از بلوغ مهندسی هستند.
اثبات مفهوم، امکان‌سنجی را نشان می‌دهد. یک شبکه آزمایشی به اعتبارسنجی عملکرد در شرایط کنترل‌شده کمک می‌کند. استقرار در مرحله تولید، الزامات اضافی شامل امنیت، نظارت، ادغام، ارتقاء و نگهداری مداوم را معرفی می‌کند.
این نقاط عطف هرگز نباید معادل یکدیگر در نظر گرفته شوند.
چگونه یک مطالعه موردی بلاکچین را بررسی کنیم؟
با مشکل اصلی شروع کنید. مشتری در تلاش برای حل چه چالش تجاری یا فنی بود؟ یک مطالعه موردی معنادار، قبل از ارائه راه حل، مشکل را توضیح می‌دهد.
رویکرد مهندسی را بررسی کنید. کدام شبکه، چارچوب، معماری و یکپارچه‌سازی‌ها انتخاب شده‌اند؟ چه محدودیت‌هایی بر این انتخاب‌ها تأثیر گذاشته‌اند؟
نتایج واقعی را مشخص کنید. آیا شرکت قراردادهای هوشمند توسعه داده، زیرساخت بلاکچین را مهندسی کرده، سیستم‌های سازمانی را ادغام کرده یا کل پیاده‌سازی را مدیریت کرده است؟
نتیجه را اعتبارسنجی کنید. آیا راه حل به کار گرفته شد؟ پس از اجرا چه چیزی تغییر کرد؟ آیا بهبود عملکرد، نقاط عطف تحویل یا سایر نتایج توسط شواهد پشتیبانی می‌شوند؟
درخواست مدرک اضافی. بسته به محدودیت‌های محرمانگی، درخواست مستندات فنی، شرح پروژه، استقرارهای عمومی مرتبط یا معرفی‌نامه از مشتری را داشته باشید.
برای پروژههای محرمانه، یک مطالعه موردی ناشناس همچنان می‌تواند مفید باشد. این مطالعه باید به وضوح صنعت، چالش، راه‌حل، مرحله تحویل و نتیجه را بدون جعل نام مشتری یا ارقام عملکردی بدون پشتوانه توصیف کند.
مطالعات موردی بلاک چین و نمونه کارهای پروژه Antier نقطه شروعی برای بررسی نمونه‌های مرتبط فراهم می‌کند. مانند هر شریک احتمالی، به جای اینکه اندازه یک نمونه کار را به عنوان مدرکی برای مناسب بودن در نظر بگیرید، پروژههای فردی را در برابر نیازهای خود ارزیابی کنید.
چه مواردی را باید بررسی کرد: فقط نپرسید که یک شرکت چند پروژه را تکمیل کرده است. بپرسید که واقعاً چه چیزی تحویل داده است، آیا سیستم به مرحله تولید رسیده است و چگونه می‌توان ادعاهای آن را بررسی کرد.
امنیت قرارداد هوشمند را زیر ذره‌بین قرار دهید
امنیت باید از ابتدا معماری یک پروژه بلاکچین را شکل دهد. نباید به یک نقطه کنترل دقیقه نودی قبل از راه‌اندازی تبدیل شود.
قراردادهای هوشمند ممکن است دارایی‌ها، مجوزها، قوانین کسب‌وکار و عملکردهای حیاتی برنامه را کنترل کنند. بسته به طراحی، آسیب‌پذیری‌ها می‌توانند منجر به تراکنش‌های غیرمجاز، اختلال در عملیات یا ضررهایی شوند که جبران آنها دشوار است.
راهنمای امنیتی رسمی اتریوم، آزمایش دقیق، بررسی کد، کنترل‌های دسترسی مناسب و آمادگی برای شکست‌های احتمالی را توصیه می‌کند. ممیزی می‌تواند به شناسایی آسیب‌پذیری‌ها کمک کند، اما نمی‌تواند تضمین کند که یک قرارداد کاملاً ایمن است.
به همین دلیل است که انتخاب یک شرکت توسعه بلاکچین مورد اعتماد ، مستلزم بررسی فرآیند امنیتی آن است، نه پذیرش ادعای کلی مبنی بر حسابرسی کد آن.
یک فرآیند امنیتی معتبر باید شامل چه مواردی باشد؟
- معماری امن: فرضیات اعتماد، نقش‌های ممتاز، وابستگی‌های خارجی و سطوح حمله بالقوه را قبل از پیاده‌سازی شناسایی کنید.
- بررسی کد: از شیوه‌های توسعه مستند و بررسیهای همتا برای شناسایی زودهنگام نقص‌ها استفاده کنید.
- تست خودکار و دستی: تحلیل استاتیک، تست واحد، تست یکپارچه‌سازی و تست تخاصمی مناسب را اعمال کنید.
- ارزیابی امنیتی مستقل: در صورت لزوم، با توجه به مشخصات ریسک و الزامات پروژه، یک ممیزی خارجی ترتیب دهید.
- رفع آسیب‌پذیری: یافته‌ها، شدت، اقدامات اصلاحی و آزمایش مجدد را مستند کنید.
- حفاظت پس از استقرار: در صورت لزوم، نظارت، رویه‌های مربوط به حوادث، کنترل‌های دسترسی و مکانیسم‌های ارتقا یا بازیابی را ایجاد کنید.
ده مورد برتر قراردادهای هوشمند OWASP برای سال ۲۰۲۵، دسته‌بندی‌های آسیب‌پذیری مانند خرابی‌های کنترل دسترسی، دستکاری اوراکل، خطاهای منطقی و ورود مجدد را برجسته می‌کند. این موارد، نقاط شروع مفیدی برای بحث‌های فنی در هنگام اعمال به پروژه شما هستند.
قبل از امضا کردن، این سوالات را بپرسید
- الزامات امنیتی چگونه در معماری و توسعه گنجانده می‌شوند؟
- از چه روش‌های آزمایشی استفاده میشود و چه مواردی را پوشش می‌دهند؟
- چه کسی ممیزی را انجام می‌دهد و دامنه آن چیست؟
- یافته‌های بحرانی و با شدت بالا چگونه حل می‌شوند؟
- اگر یک آسیب‌پذیری پس از استقرار کشف شود، چه اتفاقی می‌افتد؟
- چه کسی مسئول نظارت مداوم و حفظ امنیت است؟
نسبت به ضمانت‌های امنیت کامل یا ادعاهایی مبنی بر اینکه ممیزی به تنهایی ریسک را از بین می‌برد، محتاط باشید.
چه مواردی را باید تأیید کرد: یک شریک مهندسی معتبر باید توضیح دهد که چگونه خطرات امنیتی را شناسایی، کاهش، آزمایش و نظارت می‌کند، از جمله اینکه هنگام کشف مشکلات چگونه واکنش نشان می‌دهد.
قبل از اعتماد به جدول زمانی راه‌اندازی، آمادگی تولید را آزمایش کنید
یک برنامه بلاک چین می‌تواند در طول یک نمایش کاملاً خوب کار کند و همچنان در شرایط عملیاتی واقعی با مشکل مواجه شود.
آمادگی برای تولید، چیزی بیش از موفقیت یک تراکنش در یک شبکه آزمایشی است. این آمادگی مستلزم آن است که سیستم تحت بارهای کاری مورد انتظار، رفتاری قابل پیش‌بینی داشته باشد، با زیرساخت‌های اطراف ادغام شود، از خرابی‌ها بهبود یابد و با تغییر الزامات، قابل نگهداری باقی بماند.
برای برنامه‌های کاربردی سازمانی، شبکه‌های بلاکچین و سیستم‌های متصل به نرم‌افزارهای تجاری موجود، این ملاحظات عملیاتی می‌توانند به اندازه پیاده‌سازی اولیه مهم باشند.
یک شرکت توسعه بلاکچین قابل اعتماد باید بتواند توضیح دهد که چگونه آمادگی تولید را تأیید می‌کند و چه شواهدی از ادعاهای آن پشتیبانی می‌کند.
هفت حوزه برای بررسی
| حوزه ارزیابی | چه بپرسیم؟ |
|---|---|
| عملکرد | آیا سیستم در برابر حجم کار مورد انتظار، حجم تراکنش‌ها و الزامات تأخیر آزمایش شده است؟ |
| قابلیت اطمینان | چگونه خرابی گره‌ها، وقفه‌های شبکه و سرویس‌های با کیفیت پایین مدیریت می‌شوند؟ |
| یکپارچگی | چگونه بلاکچین با APIها، پایگاه‌های داده، سیستم‌های هویتی یا برنامه‌های سازمانی ارتباط برقرار خواهد کرد؟ |
| نظارت | چه معیارها، گزارش‌ها، هشدارها و داشبوردهای عملیاتی در دسترس هستند؟ |
| به روز رسانی | تغییرات پروتکل، ارتقاء قرارداد و به‌روزرسانی‌های وابستگی چگونه آزمایش می‌شوند؟ |
| بهبود | چه رویه‌های پشتیبان‌گیری، پاسخ به حوادث و بازیابی مستند شده‌اند؟ |
| تعمیر و نگهداری | چه کسی به‌روزرسانی‌های زیرساخت، رفع نقص‌ها و پشتیبانی عملیاتی مداوم را مدیریت می‌کند؟ |
کنترل‌های مناسب به پیچیدگی و ریسک سیستم بستگی دارند. یک برنامه غیرمتمرکز کوچک به معماری عملیاتی مشابه یک شبکه بلاکچین با توان عملیاتی بالا نیاز ندارد، اما هر دو به طرحی متناسب با کاربرد مورد نظر خود نیاز دارند.
شواهد مرتبط، مانند گزارش‌های تست عملکرد، اسناد معماری، رویه‌های استقرار یا نمونه‌هایی از شیوه‌های نظارت را درخواست کنید. جزئیات محرمانه را می‌توان حذف کرد.
یک فروشنده همچنین باید در مورد آنچه که هنوز آزمایش نشده است، شفاف باشد. رقم تخمینی توان عملیاتی نباید به عنوان یک نتیجه تولید اثبات شده ارائه شود.
چه چیزی را باید بررسی کرد: بپرسید وقتی سیستم با اولین خرابی قابل توجه در تولید خود مواجه میشود چه اتفاقی می‌افتد. یک پاسخ واضح باید شامل تشخیص، بررسی، بازیابی، مسئولیت‌پذیری و ارتباطات باشد.
افراد پشت این پیشنهاد را ارزیابی کنید، نه فقط برند را
اعتبار یک شرکت می‌تواند به شما در ایجاد یک لیست کوتاه کمک کند، اما افرادی که به پروژه شما اختصاص داده شده‌اند، نتیجه واقعی آن را شکل می‌دهند.
یک سازمان بزرگ ممکن است بدون اختصاص متخصصان مناسب برای پروژه، برند قوی و طیف گسترده‌ای از خدمات داشته باشد. یک تیم کوچک‌تر ممکن است دقیقاً تجربه مورد نیاز برای یک پروتکل، یکپارچه‌سازی یا برنامه خاص را داشته باشد.
سوال مهم این است که آیا تیم پیشنهادی مهارت، تداوم و پاسخگویی مورد نیاز پروژه شما را دارد یا خیر.
چه چیزهایی را باید در مورد تیم بررسی کنید؟
تجربه مرتبط: کدام یک از اعضای تیم روی سیستم‌هایی با الزامات فنی و عملیاتی مشابه کار کرده‌اند؟
مالکیت واضح: چه کسی مسئول معماری، توسعه، آزمایش، هماهنگی امنیتی، استقرار و مدیریت پروژه است؟
مشارکت مهندسی ارشد: آیا معماران و مدیران فنی پس از فرآیند فروش همچنان درگیر خواهند ماند؟
تداوم تیم: شرکت چگونه تغییرات منابع، واگذاری‌ها و خروج پرسنل کلیدی را مدیریت خواهد کرد؟
مستندسازی و انتقال دانش: آیا سازمان شما کد منبع توافق‌شده، مستندات فنی، دستورالعمل‌های استقرار و دفترچه‌های راهنمای عملیاتی را دریافت خواهد کرد؟
ارتباطات و پاسخگویی: پیشرفت، ریسک‌ها، موانع و تغییرات در محدوده چگونه گزارش خواهد شد؟
یک شرکت توسعه بلاکچین مورد اعتماد باید بتواند توضیح دهد که چه کسی سیستم شما را خواهد ساخت، تصمیمات فنی چگونه گرفته خواهد شد و چگونه مسئولیت در طول تحویل حفظ خواهد شد.
از سرپرست فنی پیشنهادی بپرسید:
«درباره یک تصمیم مهندسی بلاکچین که امروز رویکرد متفاوتی به آن داشتید، برایم بگویید. چه چیزی یاد گرفتید و آن تجربه چگونه بر پروژه ما تأثیر می‌گذارد؟»
ارزش این موضوع در این است که آیا فرد می‌تواند در مورد بده‌بستان‌ها بحث کند، محدودیت‌ها را بپذیرد و استدلال پشت یک تصمیم فنی را توضیح دهد یا خیر.
چه مواردی را باید بررسی کرد: تیمی را که قرار است پروژه شما را ارائه دهد، ارزیابی کنید، نه فقط مدیران ارشد یا نمایندگان فروشی که پیشنهاد را ارائه می‌دهند.
برنامهریزی یک پروژه بلاکچین؟ با شریک مناسب شروع کنید.
نتایج مشتری را از طریق شواهدی که می‌توانید به طور مستقل بررسی کنید، تأیید کنید
وب‌سایت فروشنده نقطه شروع مفیدی برای تحقیق است، اما نباید تنها منبعی باشد که به آن مراجعه می‌کنید.
یک شرکت توسعه بلاکچین معتبر باید شواهد کافی برای ارزیابی ادعاهای مهم به مشتریان بالقوه ارائه دهد. این شواهد می‌تواند شامل مطالعات موردی دقیق، بررسیهای مستقل، مراجع مجاز مشتری، مصنوعات فنی عمومی و اعتبارنامه‌های تجاری قابل تأیید باشد.
نمی‌توان نام تک تک مشتریان را علناً فاش کرد و نمی‌توان همه پروژه‌ها را آشکارا به اشتراک گذاشت. محرمانگی و محدودیت‌های مالکیت معنوی ملاحظات مشروعی هستند. نکته کلیدی این است که آیا شواهد موجود، خاص، سازگار و متناسب با ادعاهای مطرح شده هستند یا خیر.
یک فرآیند تأیید عملی
- مطالعه موردی کامل را بخوانید. بررسی کنید که آیا مشکل اصلی، نتایج واقعی، مرحله پروژه و نتیجه را توضیح می‌دهد یا خیر.
- بازخوردهای مستقل مشتریان را بررسی کنید. در صورت امکان، پلتفرم‌های شخص ثالث را بررسی کنید. فراتر از امتیازدهی ستاره‌ای، به نظرات مربوط به کیفیت فنی، ارتباطات، مدیریت پروژه و پشتیبانی پس از راه‌اندازی نیز توجه کنید.
- درخواست مرجع مربوطه. وقتی مشتری اجازه داد، درباره عملکرد فروشنده در پروژه‌ای مشابه پروژه خودتان سوال کنید.
- اعتبارسنجی شواهد فنی عمومی. در صورت لزوم، مخازن عمومی، کد منبع قرارداد تأیید شده، استقرار شبکه یا اسناد فنی را بررسی کنید.
- اعتبارنامه‌های تجاری را تأیید کنید. به جای تکیه صرف بر نشان وب‌سایت، سازمان صادرکننده، دامنه صدور گواهینامه، اعتبار و نهاد تحت پوشش را بررسی کنید.
- حقایق را از ادعاهای تبلیغاتی تشخیص دهید. یک استقرار کامل با یک پروژه برنامه‌ریزی‌شده یکسان نیست. ادغام فناوری به‌طور خودکار یک مشارکت رسمی نیست. یک گواهینامه لزوماً یک نتیجه تجاری اندازه‌گیری‌شده مستقل نیست.
مستندات تأیید قرارداد اتریوم نشان می‌دهد که چگونه می‌توان کد منبع منتشر شده را با کدی که در آدرس قرارداد مستقر شده است، مقایسه کرد. در صورت لزوم، این یکی از نمونه‌های ادعاهای فنی است که می‌تواند به طور مستقل بررسی شود.
اگر فروشنده نتواند نام مشتریان را فاش کند، چه میشود؟
درخواست یک مطالعه موردی ناشناس که صنعت، چالش، راه‌حل، مرحله تحویل و نتیجه را مشخص کند. در صورت مجاز بودن، ارجاع به توافق محرمانه بودن می‌تواند اطمینان بیشتری را فراهم کند.
یک توافقنامه عدم افشای اطلاعات می‌تواند توضیح دهد که چرا اطلاعات خاصی محدود شده‌اند. اما نباید به طور خودکار فقدان شواهد معنادار را توجیه کند.
چه مواردی را باید بررسی کرد: هرچه یک ادعا برای تصمیم شما مهم‌تر باشد، شواهد پشتیبان آن باید قوی‌تر باشد.
قبل از امضای قرارداد، منافع بلندمدت خود را تضمین کنید
راه‌اندازی یک پروژه بلاکچین یک نقطه عطف است، نه پایان چرخه عمر مهندسی آن.
پس از راه‌اندازی سیستم، ممکن است به به‌روزرسانی‌های نرم‌افزاری، ارتقاء پروتکل، تغییرات زیرساختی، بهینه‌سازی عملکرد، اصلاح امنیتی و نگهداری یکپارچه‌سازی نیاز داشته باشد. سازمان شما همچنین به شفافیت در مورد مالکیت کد، دسترسی مدیریتی و توانایی نگهداری سیستم در صورت پایان رابطه با فروشنده اصلی نیاز دارد.
وقتی بحث‌ها روی بودجه، محدوده و تاریخ‌های راه‌اندازی متمرکز می‌شوند، نادیده گرفتن این سوالات آسان است. با این حال، این سوالات می‌توانند هزینه مالکیت و استقلال عملیاتی بلندمدت شما را تعیین کنند.
این هفت نکته را در توافقنامه خود روشن کنید
- مالکیت کد منبع: چه کسی مالک نتایج است و سازمان شما تحت قرارداد چه حقوقی دریافت می‌کند؟
- دسترسی به مخزن: آیا تیم شما به کدبیس و تاریخچه نسخه‌ها دسترسی مناسب خواهد داشت؟
- مستندات: آیا مشخصات معماری، مستندات API، دستورالعمل‌های استقرار و دفترچه‌های راهنمای عملیاتی را دریافت خواهید کرد؟
- کنترل زیرساخت: چه کسی حساب‌های ابری، زیرساخت گره، اعتبارنامه‌های استقرار و مجوزهای ممتاز را کنترل می‌کند؟
- مسئولیت‌های نگهداری: چه پشتیبانی، برای چه مدت و تحت چه تعهدات سطح خدماتی ارائه میشود؟
- پاسخ حادثه: چه کسی مشکلات تولید را بررسی می‌کند، چگونه حوادث را گزارش می‌دهد و چه زمان‌هایی برای پاسخگویی توافق شده است؟
- انتقال فروشنده: آیا در صورت پایان همکاری، تیم واجد شرایط دیگری می‌تواند سیستم را نگهداری کند؟
برای پروژههای بزرگ‌تر، بین پوشش گارانتی، تعمیر و نگهداری مداوم و توافقنامه رسمی سطح خدمات تمایز قائل شوید. این ترتیبات اهداف متفاوتی را دنبال می‌کنند و باید به وضوح تعریف شوند.
یک شرکت توسعه بلاکچین قابل اعتماد باید قبل از شروع توسعه، آماده بحث در مورد این مسئولیت‌ها باشد. کسب و کار شما نباید به دانش مستند نشده، زیرساخت‌های غیرقابل دسترس یا حقوق قراردادی نامشخص وابسته باشد.
نشانه‌های خطری که باید شما را به فکر تجدیدنظر در مورد شریک توسعه بلاکچین بیندازد
حتی پس از انجام هفت بررسی، علائم هشدار دهنده خاصی شایسته بررسی دقیق تر هستند.
| پرچم قرمز | چرا از آن مهم |
|---|---|
| تضمین امنیت کامل | هیچ فرآیند مهندسیِ مسئولانه‌ای نمی‌تواند عدم وجود هرگونه آسیب‌پذیری را تضمین کند. |
| مطالعات موردی مبهم یا غیرقابل تأیید | شما نمی‌توانید مشخص کنید که چه چیزی تحویل داده شده است یا اینکه آیا نتیجه ادعا شده حاصل شده است یا خیر. |
| وعده‌های تحویل غیرواقعی | جدول‌های زمانی ممکن است معماری، یکپارچه‌سازی‌ها، آزمایش‌ها و الزامات امنیتی را نادیده بگیرند. |
| توصیه‌هایی بدون توجیه فنی | فناوری پیشنهادی ممکن است به جای نیازهای شما، منعکس کننده ترجیحات فروشنده باشد. |
| هیچ فرآیند تست یا امنیتی تعریف‌شده‌ای وجود ندارد | ممکن است نقص‌ها تا زمان استقرار یا استفاده در مرحله تولید، کشف نشده باقی بمانند. |
| مالکیت کد یا دسترسی به مخزن نامشخص است | سازمان شما ممکن است با وابستگی‌های عملیاتی و قراردادی قابل اجتنابی مواجه شود. |
| هیچ برنامه پشتیبانی پس از راه‌اندازی وجود ندارد | مسئولیت‌های مربوط به نگهداری و حوادث ممکن است پس از تحویل مورد اختلاف قرار گیرند. |
| فشار برای امضا قبل از کشف فنی | ممکن است دامنه، فرضیات و خطرات به درستی ارزیابی نشده باشند. |
یک علامت هشدار به طور خودکار ثابت نمی‌کند که یک شرکت ناتوان است. سوالات تکمیلی بپرسید و درخواست مدرک کنید. تمایز مهم این است که آیا فروشنده به طور شفاف به نگرانی‌ها رسیدگی می‌کند یا از ارائه پاسخهای واضح خودداری می‌کند.
چگونه شرکت‌های توسعه بلاکچین را بدون تحت تأثیر قرار گرفتن توسط تبلیغات فروش، مقایسه کنیم؟
وقتی شرکای بالقوه را در فهرست نهایی قرار دادید، هر شرکت را با معیارهای یکسان ارزیابی کنید. این به شما کمک می‌کند تا پیشنهادها را بدون اینکه اجازه دهید یک ارائه چشمگیر یا قیمت پایین بر تصمیم‌گیری تأثیر بگذارد، مقایسه کنید. از کارت امتیازی زیر به عنوان نقطه شروع استفاده کنید و وزن‌ها را متناسب با پیچیدگی و مشخصات ریسک پروژه خود تنظیم کنید.
| معیار ارزیابی | وزن پیشنهادی |
|---|---|
| تخصص فنی مرتبط | ٪۱۰۰ |
| تجربه پروژه قابل اثبات | ٪۱۰۰ |
| شیوه‌های امنیتی و آزمایش | ٪۱۰۰ |
| آمادگی تولید و قابلیت اطمینان | ٪۱۰۰ |
| تیم تعیین‌شده و پاسخگویی | ٪۱۰۰ |
| شواهد و منابع مستقل | ٪۱۰۰ |
| مالکیت و پشتیبانی پس از راه‌اندازی | ٪۱۰۰ |
| جمع | ٪۱۰۰ |
بر اساس شواهدی که بررسی کرده‌اید، به هر شرکت از ۱ تا ۵ امتیاز دهید.
امتیاز وزنی را با ضرب کردن وزن هر معیار در امتیاز آن، جمع کردن نتایج و تقسیم بر پنج محاسبه کنید. امتیاز حاصل از ۱۰۰ است.
برای مثال، فروشنده‌ای که قابلیتهای امنیتی قوی را توصیف می‌کند اما نمی‌تواند فرآیند آزمایش خود را توضیح دهد، نباید همان امتیاز فروشنده‌ای را دریافت کند که مستندات مربوطه را ارائه می‌دهد و رویکرد خود را به وضوح توضیح می‌دهد.
نگذارید عدد نهایی، یک نگرانی اساسی را نادیده بگیرد. امتیاز کلی بالا نمی‌تواند رویه‌های امنیتی غیرقابل قبول، حقوق مالکیت معنوی نامشخص یا فقدان تخصص فنی را جبران کند.
هدف، شناسایی بهترین شرکت توسعه بلاکچین در سطح جهانی نیست . بلکه یافتن شریکی است که قابلیت‌ها، مدل تحویل و شیوه‌های مدیریت ریسک اثبات‌شده‌اش به بهترین وجه با نیازهای شما مطابقت داشته باشد.
شریک بلاکچینی را انتخاب کنید که بتواند قابلیتهای خود را اثبات کند
انتخاب یک شرکت توسعه بلاکچین معتبر در نهایت به کاهش عدم قطعیت قبل از اختصاص بودجه، زمان و اهداف تجاری شما به یک پروژه فنی مربوط میشود.
یک نمونه کار بی‌نقص نمی‌تواند ثابت کند که یک تیم می‌تواند چالش مهندسی خاص شما را حل کند. یک نشان امنیتی نمی‌تواند تضمین کند که یک برنامه کاربردی ایمن است. فهرستی از شبکه‌های پشتیبانی‌شده نمی‌تواند ثابت کند که یک فروشنده، معماری مورد نیاز کسب‌وکار شما را ارائه داده است.
اعتماد از شواهد ناشی میشود: تجربه مهندسی مرتبط، تصمیمات معماری قابل دفاع، رویه‌های امنیتی شفاف، نتایج قابل تأیید مشتری، تیم‌های تحویل توانمند و پاسخگویی شفاف پس از استقرار.
قبل از امضای قرارداد، سوالاتی بپرسید که نشان می‌دهد یک شرکت چگونه فکر می‌کند، می‌سازد، آزمایش می‌کند و از آنچه ارائه می‌دهد پشتیبانی می‌کند. پاسخ‌ها را با نیازهای خود مقایسه کنید و هرگونه ادعایی را که قابل اثبات نیست، بررسی کنید.
بهترین شرکت توسعه بلاکچین برای پروژه شما لزوماً بزرگترین، ارزان‌ترین یا قابل مشاهده‌ترین شرکت نیست. بلکه شریکی است که بتواند تخصص مناسب را نشان دهد، رویکرد خود را توضیح دهد و مسئولیت ارائه سیستمی را که مطابق با نیازهای شما باشد، بر عهده بگیرد.
آیا در حال برنامهریزی برای یک پروژه بلاکچین هستید؟ با Antier ارتباط برقرار کنید تا در مورد نیازهای فنی خود صحبت کنید، گزینه‌های معماری را ارزیابی کنید و قابلیتهای مهندسی مورد نیاز برای تبدیل پروژه خود از مفهوم به محصول را شناسایی کنید.
پرسش و پاسخهای متداول
01. برای اطمینان از داشتن تخصص لازم، باید در یک شرکت توسعه بلاکچین به دنبال چه ویژگی‌هایی باشم؟
به دنبال شرکتی باشید که بتواند تصمیمات معماری خود را توضیح دهد، تجربه تولید مرتبط را نشان دهد و بینش‌هایی در مورد چگونگی ایمن‌سازی قراردادهای هوشمند و مدیریت ادغام‌ها ارائه دهد.
02. چرا بررسی تخصص مهندسی یک شرکت توسعه بلاکچین فراتر از ادعاهای فناوری آنها مهم است؟
تأیید تخصص مهندسی بسیار مهم است زیرا پروژههای مختلف بلاکچین نیاز به تصمیمات معماری و ملاحظات امنیتی متمایزی دارند. یک تیم معتبر باید بتواند بیان کند که چرا رویکرد آنها برای نیازهای خاص کسب و کار شما مناسب است.
03. قبل از انتخاب شریک توسعه بلاکچین، چه بررسیهای مهمی باید انجام شود؟
بررسیهای حیاتی شامل ارزیابی توانایی تیم در توضیح تصمیمات معماری خود، تأیید تجربه آنها با چارچوبهای مرتبط و ارزیابی قابلیتهای برنامهریزی مقیاسپذیری آنها میشود.
