توسعه دهنده؟ این را برای مدیر محصول خود بفرستید (اگر جرات دارید)

Summarize this content to 400 words in Persian Lang
یک الگوی ضد متداول در سازمان های نرم افزاری مدرن وجود دارد. چندین بار دیده ام که منجر به نتایج فاجعه آمیز شده است. این از ساختار ذاتی این سازمان‌ها و مجموعه مهارت‌ها، عادات و انگیزه‌های متفاوت بازیگران کلیدی، به‌ویژه آنهایی که در نقش‌های محصول و مهندسی هستند، ناشی می‌شود. من آن را “جزئیات پیاده سازی مغالطه است”.

جزئیات پیاده سازی چیست؟

در نرم‌افزار، جزئیات پیاده‌سازی، اسم رمز «چیزی که نباید نگران آن باشید یا به آن اهمیت می‌دهید» یا «چیزهای بی‌اهمیت» است.به عنوان مثال، اگر می خواهید مقدار X را 1 افزایش دهید، چند راه برای پیاده سازی آن در یک خط کد وجود دارد:

x = x + 1
x = 1 + x
x += 1
x++
++x

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

با این حال، آنچه ممکن است شما را شگفت زده کند، این است که ارائه نمونه های واضح از انتخاب هایی که واقعاً مهم نیستند، بسیار سخت است. «اشتباه جزئیات پیاده‌سازی» با انتخاب‌های حیاتی (معروف به «انتخاب‌های طراحی» یا «انتخاب‌های معماری») به‌گونه‌ای برخورد می‌کند که گویی جزئیات اجرایی هستند.

زمان امتحان

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

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

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

آنها فکر می کنند که ارسال چیزهایی که بخش های حیاتی یک ماشین واقعی هستند، مانند چرخ ها یا پیشرانه، ایده بدی است. در ذهن آنها، این چیزها به هیچ وجه مفید نیستند زیرا نمی توانند کاربر را به تنهایی از A به B منتقل کنند. به عبارت دیگر، ما نمی‌توانیم کاربران را با فروش لاستیک‌های واقعا خوب خوشحال کنیم (برای شرکت‌هایی مانند بریجستون خیلی بد).
جنایی تر، آنها فکر می کنند که شما می توانید راه خود را از یک اسکیت بورد به یک ماشین تکرار کنید. این از نظر مهندسی و تجاری کاملاً بی معنی است. فقط سعی کنید اسپیس ایکس را در حال توسعه و فروش گلایدرها قبل از چرخش به سمت بالون های هوای گرم، سپس هلیکوپترها، سپس هواپیماها و در نهایت Starship تصور کنید 🤦🏻‍♂️.

فقط برای رسیدن به هدف، هیچ شرکت خودروسازی موفقی در تاریخ تا به حال خودرویی را به این شکل توسعه نداده است. روند واقعی آنها به طرز مشکوکی شبیه به ردیف “مثل این نیست” در بالا است، چیزی شبیه به:

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

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

ماشین هایی با چرخ های اسکیت برد

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

دستور العمل برای فاجعه

در اینجا نحوه کار آن آمده است:

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

می توان انتظار داشت که مهندسی به کمک بیاید. متأسفانه چند عامل وجود دارد که از وقوع آن جلوگیری می کند:

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

اگر این کافی نیست، عوامل محیطی نیز وجود دارد:

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

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

“جزئیات پیاده سازی” همه چیز است

چه چیزی باعث شد کروم، زمانی که عرضه شد، با اینترنت اکسپلورر متفاوت باشد؟ “جزئیات پیاده سازی”.
چه چیزی git را ممکن کرد؟ “جزئیات پیاده سازی”.
چه چیزی صفحه نمایش لمسی آیفون را از صفحات لمسی قبلی متمایز کرد؟ “جزئیات پیاده سازی”.

به هر محصول نرم افزاری موفقی که به صورت روزانه استفاده می کنید نگاه کنید، و در 9.5 مورد از 10 مورد، نوعی موتور “شاهکار مهندسی” را پیدا خواهید کرد که محصول را ممکن می کند. یک «موتور ماشین» که از روز اول آنجا بود. البته نه در شکل نهایی اش، اما آنجا بود. این سیستم هرگز یک اسکیت برد یا یک اسکوتر نبود. این یک هسته منسجم دارد که مجموعه ای واضح و منسجم از ویژگی ها و رفتارهای فنی را تعریف می کند که به طور منحصر به فرد برای آنچه سیستم انجام می دهد طراحی شده است.

نمونه های بی شماری وجود دارد. در اینجا برخی از:

این مقاله نه ساله توضیح می‌دهد که چگونه Figma از اسمبلی وب و پیاده‌سازی موتور رندر خود (به‌جای استفاده از موارد اولیه مرورگر) برای امکان‌پذیر کردن محصول خود استفاده می‌کند. آنها همچنین موتور همگام سازی خود را پیاده سازی کردند (که در پست قبلی بیشتر در مورد آن صحبت کردم).
نقشه های گوگل (از جمله جنون که نمای خیابان است) و Waze.
واتساپ
اسکایپ، زوم.
اسناد / برگه های Google.
نتفلیکس، یوتیوب و اسپاتیفای.
ChatGPT، Suno، MidJourney.

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

اما همه امیدها از بین نمی رود. به نظر من قابل تعمیر است، اما خود به خود درست نمی شود.

پادزهر – یادگیری استدلال در سطح سیستم

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

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

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

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

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

بدانید که سیستم شما باید چه ویژگی هایی داشته باشد تا به “هدف نهایی” خود برسد، آنها را از همان ابتدا به درستی دریافت کنید، و مطمئن شوید که هرگز در طول مسیر گم نمی شوند. تست استرس و تست آشوب از مراحل اولیه در موقعیت هایی که استفاده همزمان در یک محیط واقعی را تقلید می کند. خود را مانند همتایان خود در سایر رشته های مهندسی در نظر بگیرید – آنهایی که ماشین ها و سفینه های فضایی می سازند و خود را مطابق با استانداردهای مشابه نگه می دارند. نوار شما باید بسیار بالاتر از “نرم افزار کار” باشد. اگر سازمان شما جاه طلبی های یکسانی برای برتری ندارد، آن را ترک کنید.

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

افکار نهایی

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