اغلب اوقات، اول باید نویسنده رو بشناسم و دوست داشته باشم و سپس به دنبال کتابهای نویسندهی مورد نظر میرم و شروع به خوندنشون میکنم. این موضوع دربارهی کتاب «Rework» هم برای من مصداق داشت. دیوید هاینمیر هانسن (مشهور به DHH در جامعهی روبی)، یکی از نویسندههای این کتاب با فاصله یکی از مورد علاقهترین شخصیتهای من هست. DHH برنامهنویس مشهور دانمارکی، سازندهی فریمورک Ruby on Rails، و رانندهی مسابقات ماشینسواری هست.
کتاب «Rework» رو که DHH با همکاری Jason Fried (یکی از پایهگذارهای شرکت 37Signals) نوشته، مجموعهای از راهنماها برای افرادی هست که قصد آغاز کسب و کار خودشون در حوزهی تکنولوژی رو دارند. برخلاف بسیاری از کتابهای حوزهی بیزینس که درگیر مسائل مختلف مدیریتی و تئوری و بررسی رقبا و... هستند، این کتاب کاملا صادقانه و متمرکز بر مسائل اساسی یک کسب و کار هست. کتاب کوتاه و مستقیما دربارهی اصل مطلب هست و شما رو در مثالهای بینهایت که تنها برای طولانیتر کردن کتاب اضافه شده و ارزشی به کتاب اضافه نمیکنند غرق نمیکنه.
یکی از مواردی که این کتاب دربارش صحبت میکنه، موضوعی هست که قبلا هم دربارهاش در کتاب Deep Work کال نیوپورت خونده بودم و همیشه ارزش یادآوری دائمی داره. خیلی از ما ممکن هست ساعتها به اصطلاح کار کنیم و مشغول به نظر برسیم اما کیفیت و خروجی کار ما اگر واقعا صادقانه قضاوت بشه، بسیار کوچک و خندهدار هست. یکی از دلایل اصلی این موضوع عدم وجود کار متمرکز و حواسپرتیهای دائمی در طول کار و پریدن از یک تسک به تسک دیگر هست. اگرچه از دور به نظر میرسه که غرق در کار هستیم اما در عمل خروجی ما در طول کار واقعا ناچیز هست. جلسههای متعدد در طول کار، تماسهای تلفنی، پیامهایی که ریاکشن لحظهی نیاز دارند و... همگی باعث یک ذهن پراکنده خواهند شد که توانایی تمرکز و حل مشکلات اساسی و ساخت یک محصول با ارزش رو نداره. مخصوصا در حوزهی برنامهنویسی یا طراحی، تمرکز مطلق شرط اساسی ساخت یک محصول باارزش هست.
طبق تجربهی شخصیم، یکی از اشتباهات اساسی شرکتهایی که درونشون مشغول بودم انجام میدادند این بود که سعی داشتند محصول اولیهای که قصد انتشارش رو داشتند، تمام عملکردها و ویژگیهای مورد نظرشون رو به صورت کامل در بر بگیره. یک محصول بزرگ با دهها عملکرد و ویژگی توسعه میدادیم و منتشر میکردیم اما هیچ کدام از این عملکردها و ویژگیها به دلیل زمان توسعهی محدود و عدم فیدبک یوزر و... واقعا به خوبی عمل نمیکردند. اما با نامیدن این فاز از توسعه Minimum Viable Product، خودمون رو گول میزدیم که این محصول پر از باگ و زجردهنده برای کاربر قدم اساسی در آغاز بوده و قابل پذیرش هست. کاربرهای اولیهی محصول، با یک کوه عظیم از باگ و رابط کاربری کشنده و... روبرو میشدند و تا آخر عمر از این محصول یک خاطره بد داشته و حتی اگر محصول به حد قابل قبولی از کیفیت در آینده برسه، این کاربر اولیه غیر ممکن هست به سراغش بره. از طرف دیگر افراد توسعهدهندهی محصول هم شرایط چندان دلچسبی نداشتند، فایلهای طراحی فیگما به دلیل پراکنده بودن و وسیع بودن ایدهها و عدم وجود زمان توسعهی کافی مثل کشتی گیر کرده در طوفان با یک دکل شکسته بود. Componentها مثل ملوانهای نیمه مست که نیمهشب با صدای رعد و برق بیدار شدند در حال دویدن دیوانهوار به اطراف کشتی بوده و دقیقا نمیدونند دارند چه کار میکنند و طراح بیچاره هم مثل ناخدای کشتی در حال فریاد زدنهایی هست که کسی بهش گوش نمیده. متنهای محصول هر قسمتش یک لحن دارند و در بسیاری از موارد حتی خود تیم توسعه دهنده هم نمیدونه بعضی از ارورهایی که برای کاربر نوشته شده دقیقا منظورش چی بوده. جالبتر اینکه اغلب اوقات وقتی قصد بر عبور از این فاز رو داشتیم، تقریبا هیچ کدوم از این فایلهای طراحی ارزش وقت صرف کردن برای بهبود رو نداشتند و در نهایت اکثرشون از اول بازطراحی شدند. تصور میکنم قسمت کدبیس محصول هم یک جنگل آمازون یا شاید بدتر مثل قسمت طراحی بوده باشه.
اگر هدف از Minimum Viable Product تست کردن یک ایده از دید کاربرها در مراحل اولیهی توسعهی محصول باشه، ساخت محصول به این شکل، بدون توجه به تجربهی کاربرها و صرفا بر اساس ویژگیها و عملکردهایی که مدیران شرکت قصد پیادهسازیاش رو داشتند نمیتونه میزان خوبی برای تست محصول باشه. دلیل این موضوع آن هست که این عملکردها و ویژگیها چنان سریع و نیمهکاره ساخته شدهاند که کاربر تجربهی دلچسبی از آنها نداشته و قطعا نظری منفی نسبت به موضوع خواهد داشت. از طرف دیگر طراحی و کدبیس محصول هم احتمالا اینقدر سریع و پراکنده و بدون تمرکز و تفکر انجام شده که بخش زیادیش در آینده باید کنار گذاشته بشه و از نو انجام بشه. عملا کل موضوع یک وقتتلفی بزرگ بدون رسیدن به هیچ نتیجهی مشخصی هست.
البته که تلاش برای ساخت یک محصول بینقص در همان ابتدای کار یک هدف غیر قابل دسترسی هست و چنین رویکرد کمالگرایی باعث میشه هیچ وقت محصولی به وجود نیاد. اما موضوع این هست که دوری از کمالگرایی نباید به معنی این باشه که یک محصول خیلی بزرگ اما بیمصرف درست کنیم. شاید بهتر هست به جای درست کردن یک محصول با تمام ویژگیها و عملکردها پیادهسازی شده به صورت نصف کاره، محصولی درست کنیم که تنها چند عملکرد و ویژگی انگشت شمار رو درون خودش جا داده اما این چندین عملکرد انگشتشمار به شکلی قابل پذیرش و مناسب توسعه داده شده و تجربهی کاربر در این توسعه به صورت کامل مورد نظر قرار گرفته شده باشه. قطعا هر محصولی در روز اول باگها و اشتباهات مختلفی دارند اما این موارد نباید در حدی آزاردهنده باشند که محصول به صورت کلی قابل استفاده نباشه. در آغاز کار توسعهی محصول با توجه به محدودیتهای مالی، زمانی و...، به جای ساخت یک محصول بزرگ پر از ایراد، بهتر هست یک محصول کوچک نسبتا بینقص درست کنیم. به قول DHH در این کتاب:
Build half a product,
Not a half assed product.
کتاب «Rework» پر از توصیههای واقعگرایانه مشابه مواردی هست که در بالا بهشون اشاره شد. اگر در فکر ایجاد کسب و کار جدید در حوزهی تکنولوژی هستید، خوندن این کتاب رو قویا بهتون پیشنهاد میکنم. کتاب برگرفته از سالها تجربهی نویسندهها در حوزهی کسب و کار بوده و صرفا توصیههایی تئوریک دانشگاهی بیمصرف در دنیای واقعی نیست.
