چرا دیزاین سیستمها ساخته میشن ولی استفاده نمیشن
فرانتاندخلاصهٔ کاملتر
تو این مقاله تیم Sparkbox میگه همه برای سختبودنِ ساختِ یه دیزاین سیستمِ مقیاسپذیر برنامه میریزن، ولی تقریباً هیچکس برای سختترین بخش ماجرا برنامه نداره: اینکه آدمها واقعاً ازش استفاده کنن. به گفتهٔ اونها سازمانها معمولاً از دو نقطه شروع میکنن؛ یا سیستمی دارن که بودجه و آدم گرفته، کامپوننتها و مستنداتش هم اومده ولی تیمهای محصول همچنان راهحل یکبارمصرف خودشونو میسازن، یا هنوز رسماً شروع نکردن و یه طراح یا مهندس گوشهای دارن بیخبر از مدیرها چیزی میسازن.
جواب هر دو تا یه سؤاله: چطور مطمئن شیم این سیستم استفاده میشه؟ به تجربهٔ Sparkbox جواب همیشه سه تا عامله. سیستم باید به سازمان بخوره، به محصولهایی که قراره سرویس بده بخوره، و تیمی که نگهش میداره توانِ نگهداشتنش رو داشته باشه. تو مقاله اومده که «تحویلدادهشده» یه دستاورده ولی کافی نیست: سیستمی که فنی عالیه ولی با سازمان و محصول و تیم جور نیست بیاستفاده میمونه، و سیستمی که خوب جا افتاده ولی بد ساخته شده، لانچ میشه و بعد ازش متنفر میشن.
این اشتباه دو بار هزینه داره: یک بار برای ساختن سیستمی که کسی استفاده نکرد و یک بار برای ساختن جایگزینش. کنارش اعتماد هم میره، و اعتماد ذرهذره ساخته میشه ولی یکدفعه از دست میره. برای همین Sparkbox میگه دیزاین سیستمِ خوب بهشکل انتزاعی وجود نداره؛ فقط سیستمی وجود داره که به این سازمان، این محصولها و این تیم بخوره.
سمت سازمان، سؤالها خیلی عملیان: تصمیمها چطور و توسط کی گرفته میشن، حامی سیستم کیه و موفقیتش چطور تعریف شده، بودجه از کجا میآد و تا کی میمونه. جایی که یه VP میتونه استفاده از سیستم رو اجباری کنه، سیستم میتونه از همون اول نظر قاطع داشته باشه؛ ولی تو سازمان فدرالی که دهها تیم محصول رودمپ خودشونو دارن، سیستم باید کمکم جا باز کنه با یه مدل مشارکت که واقعاً مشارکت رو آسون کنه، نه فقط روی کاغذ ممکن.
سمت محصول، کار از چیزی که همین حالا هست شروع میشه: ابزارهای طراحی و مهندسی، تاکسونومی و معماری اطلاعات، و تصمیمهایی که قبلاً گرفته شدن. گاهی جواب درست یه سیستم کوچیک و خوشساخته که فقط پایههای پرکاربرد رو پوشش بده، گاهی یه مسیر مهاجرت تیکهتیکه، و گاهی فقط درستکردن مستندات. سمت تیم هم حرف اصلی اینه: مسئولیت بدون اختیار رایجترین و آسیبزنندهترین حالته، و سیستمی که برای تیم ششنفره طراحی شده، تیم دونفره رو زیر خودش دفن میکنه.
نکات کلیدی:
- سه عامل تعیینکنندهٔ استفادهشدن یه دیزاین سیستم: تناسب با سازمان، تناسب با محصولها، و توانِ تیم برای نگهداری.
- شکست سیستم دو بار هزینه داره: ساختِ سیستم بیاستفاده و بعد ساختِ جایگزینش.
- سازمان متمرکز میتونه زود قاطع باشه، سازمان فدرال باید مشارکت رو آسون کنه.
- مستنداتی که هم آدم میخونه هم AI میتونه ازش استفاده کنه، بخشی از کار فنیه.
- مسئولیت بدون اختیار رایجترین اشتباه تیم دیزاین سیستمه؛ سیستم باید برای اندازهٔ واقعی تیم ساخته شه.
