چگونه شرکت‌های بزرگ نرم‌افزاری مستندسازی میکنند؟ درس‌هایی از گوگل و گیتلب برای تیمهای ایرانی
نویسنده: علی محمدی (کارشناس دیجیتال مارکتینگ)
آخرین بروزرسانی: ۱۹ شهریور ۱۴۰۵
اگر فکر می‌کنید مستندسازی کاری است که فقط تیمهای کوچک و کم‌تجربه وقتش را ندارند انجام دهند، نگاهی به گوگل بیندازید. شرکتی با دهها هزار مهندس نرم‌افزار، رقابتی‌ترین بازار دنیا و فشار دائمی برای سرعت — و در عین حال یکی از رسمی‌ترین فرهنگ‌های مستندسازی نرم‌افزار در کل صنعت. این تناقض تصادفی نیست؛ نتیجه یک انتخاب آگاهانه است.
در این مقاله سراغ دو نمونه واقعی و کاملاً مستند می‌رویم: نحوه مستندسازی در گوگل از طریق Design Doc و فرهنگ Postmortem، و رویکرد گیتلب که تمام شرکت را حول یک Handbook عمومی می‌چرخاند. هدف این نیست که همه چیز را کپی کنید؛ هدف این است که ببینید این شرکت‌ها چرا این کار را میکنند، تا بتوانید نسخه کوچک و واقعی آن را برای تیم خودتان بسازید.
پاسخ سریع: چه چیزی مشترک بین این شرکت‌هاست؟
| شرکت | روش اصلی مستندسازی | هدف اصلی |
| گوگل | Design Doc قبل از کد + Postmortem بیسرزنش بعد از خطا | تصمیمگیری روی کاغذ، ارزان‌تر از تصمیمگیری در کد |
| گیتلب | Handbook-First — همه‌چیز اول نوشته می‌شود، بعد اجرا | کار آسنکرون بدون نیاز به جلسه یا توضیح شفاهی |
.حالا هر کدام را با جزئیات و مثال واقعی بررسی می‌کنیم
مطالعه موردی ۱: چطور گوگل مستندسازی میکند
Design Doc — سندی که قبل از هر پروژه بزرگ نوشته می‌شود
در گوگل، پیش از شروع هر پروژه مهم، مهندس مسئول یک Design Doc می‌نویسد — سندی نسبتاً غیررسمی که استراتژی سطح بالای پیاده‌سازی و تصمیم‌های کلیدی طراحی را مستند میکند، با تمرکز ویژه روی trade-offهایی که در نظر گرفته شده‌اند.
فلسفه پشت این کار ساده است: کار مهندس نرم‌افزار صرفاً تولید کد نیست، بلکه حل مسئله است. متن ساختارنیافته (مثل یک Design Doc) در مراحل اولیه پروژه ابزار بهتری برای حل مسئله است، چون فشرده‌تر، قابل‌فهم‌تر و در سطح بالاتری نسبت به کد، مسئله و راه‌حل را منتقل میکند.
یک Design Doc معمولی در گوگل شامل این بخش‌هاست:
- توضیح مسئله (نه راه‌حل) به زبان ساده
- گزینه‌های مختلف راه‌حل و مقایسه آن‌ها
- تصمیم نهایی و دلایل آن
- ریسک‌ها و پیامدهای هر تصمیم
- نحوه تست و ارزیابی موفقیت راه‌حل
این سند قبل از نوشتن کد، توسط مهندسان ارشد بازبینی می‌شود. کتاب Software Engineering at Google تأکید میکند که اکثر تیمهای گوگل، پیش از شروع هر پروژه بزرگ، تأیید یک Design Doc را الزامی می‌دانند.
چرا این کار مقرون‌به‌صرفه است؟ اصلاح یک مشکل در مرحله طراحی، دهها برابر ارزان‌تر از اصلاح همان مشکل در کدی است که هفته‌ها روی آن کار شده. Design Doc دقیقاً همین اصل «هزینه اصلاح زودهنگام» را عملی میکند.
Postmortem بیسرزنش — یادگیری مکتوب از هر خطای تولید
وقتی یک سرویس گوگل با خطا مواجه می‌شود، تیم مسئول یک Postmortem می‌نویسد. اصل بنیادین این سند، بیسرزنش بودن (Blameless) است: تمرکز کامل روی این است که چه اتفاقی افتاد، نه چه کسی مقصر بود.
طبق کتاب Site Reliability Engineering گوگل، یک postmortem بیسرزنش فرض میکند تمام افراد درگیر در حادثه، با اطلاعاتی که در آن لحظه داشتند، بهترین تصمیم ممکن را گرفته‌اند. تمرکز از «چه کسی اشتباه کرد» به «چرا سیستم اجازه این اشتباه را داد» منتقل می‌شود.
این تغییر نگاه پیامد عملی مهمی دارد: وقتی مهندسان بدانند صداقتشان مجازات نمی‌شود، جزئیات کامل حادثه را گزارش میکنند. نتیجه، postmortemهایی دقیق‌تر و پیشگیری واقعی‌تر از تکرار مشکل است.
مطالعه موردی ۲: فرهنگ Handbook-First در گیتلب
گیتلب یک شرکت کاملاً ریموت با کارمندانی در بیش از ۶۵ کشور است. بدون یک دفتر مرکزی، بدون گفت‌وگوهای غیررسمی کنار میز قهوه، این شرکت باید راهی پیدا می‌کرد تا هزاران نفر بدون نیاز به جلسه مداوم، هماهنگ کار کنند. پاسخ گیتلب: Handbook-First.
اصل ساده است: هر تغییری — چه در فرآیند، چه در سیاست، چه در تصمیم فنی — اول باید نوشته شود، بعد اعلام یا اجرا شود. Handbook عمومی گیتلب امروز بیش از ۲۷۰۰ صفحه دارد و شامل همه چیز از سیاست‌های منابع انسانی تا راهنمای مهندسی است.
این فرهنگ یک تفاوت مهم با روش سنتی مستندسازی دارد. در بیشتر شرکت‌ها، اول در جلسه یا اسلک تصمیم گرفته می‌شود، بعد (اگر وقت شد) مستند می‌شود. در گیتلب، ترتیب برعکس است: اول نوشته می‌شود، بعد ارتباط داده می‌شود. این یعنی هیچ‌وقت مرحله «مستندسازی بعد از تصمیم» فراموش نمی‌شود، چون اصلاً چنین مرحله جداگانه‌ای وجود ندارد.
نتیجه این رویکرد: Handbook گیتلب به یک منبع واحد حقیقت (Single Source of Truth) تبدیل شده که هر کارمند، پیش از پرسیدن سوال از همکار، ابتدا آن را جستجو میکند. این کاهش وابستگی به ارتباط لحظهای، دقیقاً همان چیزی است که یک تیم توزیع‌شده یا حتی یک تیم حضوری با اعضای پرمشغله به آن نیاز دارد.
⭐ نکته‌ای که دیگران نمی‌گویند: این شرکت‌ها مستندسازی را «هزینه» نمی‌بینند
اگر این دو مطالعه موردی را کنار هم بگذارید، یک نکته ظریف اما تعیین‌کننده آشکار می‌شود: هیچ‌کدام از این شرکت‌ها مستندسازی را کاری «جانبی» یا «اضافه بر کار اصلی» نمی‌بینند. برایشان مستندسازی بخشی از خود فرآیند مهندسی است، دقیقاً مثل نوشتن تست یا Code Review.
این تفاوت دیدگاه، سه پیامد عملی دارد که کمتر جایی درباره‌اش صحبت می‌شود:
- ۱. مستندسازی جایگزین جلسه است، نه اضافه بر آن. گیتلب با نوشتن Handbook، هزاران ساعت جلسه توضیحی را حذف کرده. این را نباید «کار اضافه» دید، بلکه «جابه‌جایی کار از جلسه به نوشتن» است.
- ۲. مستند بد از عدم مستند بدتر است. نکته‌ای که در بحث Design Doc کمتر گفته می‌شود این است که برخی مهندسان باتجربه گوگل هشدار می‌دهند وقتی Design Doc تبدیل به تشریفات صرف شود (نوشتن برای نوشتن)، ارزشش را از دست میدهد. گوگل هم در تیمهای کوچک‌تر، فقط برای پروژه‌های واقعاً پیچیده این سند را الزامی میکند، نه برای هر تغییر کوچک.
- ۳. بیسرزنش بودن باید واقعی باشد، نه شعاری. اگر یک تیم بگوید «postmortem ما بیسرزنش است» ولی در عمل مدیر بعد از جلسه به صورت خصوصی فرد را سرزنش کند، کل فرهنگ از بین می‌رود. صداقت گزارش‌دهی مستقیماً به این بستگی دارد که آیا واقعاً امنیت روانی وجود دارد یا نه.
چطور این الگوها را برای تیم ایرانی خودمان کوچک کنیم؟
نسخه گوگل و گیتلب برای تیم ۵ تا ۲۰ نفره ایرانی بیش از حد سنگین است. نسخه کوچک و واقعی این‌طور است:
نسخه کوچک Design Doc: یک صفحه، نه ده صفحه
برای هر feature بزرگ‌تر از یک اسپرینت، یک سند نیم تا یک صفحه‌ای با چهار بخش کافی است: مسئله چیست، چه گزینه‌هایی بررسی شد، چرا این یکی انتخاب شد، چه ریسکی دارد. این سند نیازی به فرمت رسمی یا ابزار خاص ندارد؛ یک فایل Markdown در همان مخزن کد کفایت میکند.
نسخه کوچک Handbook-First: شروع از یک صفحه در باسینرژی یا Confluence
نیازی نیست از روز اول ۲۷۰۰ صفحه بنویسید. با یک صفحه شروع کنید: «چطور در تیم ما کار می‌کنیم». هر بار که یک تصمیم یا فرآیند تکراری در اسلک توضیح داده شد، آن را در همین صفحه اضافه کنید. بعد از چند ماه، بدون تلاش آگاهانه، یک Handbook کوچک خواهید داشت.
نسخه کوچک Postmortem بیسرزنش: یک قالب ساده، یک قانون سفت
بعد از هر مشکل جدی در تولید، یک سند کوتاه بنویسید: چه اتفاقی افتاد، چه زمانی، چه تأثیری داشت، چرا اتفاق افتاد، چه اقدامی برای جلوگیری از تکرار انجام می‌شود. تنها قانون سفت: در این جلسه و سند، هیچ جمله‌ای که با «فلانی اشتباه کرد» شروع شود، مجاز نیست.
سوالات متداول درباره مستندسازی در شرکت‌های بزرگ
۱. آیا تیمهای کوچک هم به Design Doc نیاز دارند؟
بله، اما در مقیاس کوچک‌تر. حتی یک تیم دو‌نفره با نوشتن نیم صفحه قبل از شروع یک feature بزرگ، از دوباره‌کاری‌های پرهزینه جلوگیری میکند. تفاوت با گوگل فقط در طول و رسمیت سند است، نه در اصل کار.
۲. Handbook گیتلب برای عموم قابل مشاهده است؟
بله، بخش زیادی از Handbook گیتلب به صورت عمومی در سایت این شرکت در دسترس است و می‌توانید مستقیماً آن را برای الگوبرداری ساختاری مطالعه کنید.
۳. تفاوت Postmortem بیسرزنش با گزارش معمولی خطا چیست؟
گزارش معمولی معمولاً دنبال «مقصر» می‌گردد. Postmortem بیسرزنش دنبال «نقص در سیستم» می‌گردد — مثلاً به‌جای «مهندس X کد باگ‌دار دیپلوی کرد»، می‌نویسد «فرآیند CI/CD این باگ را قبل از تولید تشخیص نداد». این تفاوت زبانی، اقدام اصلاحی قابل‌اجرا تولید میکند، نه صرفاً مجازات فرد.
۴. آیا این روش‌ها فقط برای تیمهای ریموت کاربرد دارند؟
خیر. حتی تیمهای حضوری هم از نوشتن مستقیم سود می‌برند، چون حافظه جمعی تیم همیشه از مستند مکتوب ضعیف‌تر است. تیمهای ریموت مثل گیتلب فقط این نیاز را زودتر و شدیدتر احساس کردهاند.
۵. از کجا بفهمیم مستندسازی‌مان بیش از حد شده و به تشریفات تبدیل شده؟
نشانه اصلی: وقتی مستندی نوشته می‌شود ولی هیچ‌کس آن را نمی‌خواند یا استفاده نمی‌کند. اگر یک نوع مستند بارها این حالت را نشان داد، آن نوع مستند را حذف یا ساده‌تر کنید. قانون طلایی: هر مستندی باید مصرف‌کننده مشخص داشته باشد.
جمعبندی: کپی نکنید، الگو را بردارید
گوگل و گیتلب دو مسیر متفاوت به یک مقصد مشترک رفتهاند: تصمیمگیری و ارتباط را از حافظه و گفتوگوی لحظهای، به متن مکتوب و قابلجستجو منتقل کردهاند. Design Doc، Postmortem بیسرزنش و Handbook-First سه تکنیک متفاوت برای یک هدف واحدند: کاهش وابستگی تیم به حافظه چند نفر خاص.
نسخه تیم شما نیازی به ۲۷۰۰ صفحه یا فرآیند رسمی گوگل ندارد. نیاز واقعی شما یک جای مشخص برای نوشتن این تصمیمها، تسکها و پس از حوادث است — جایی که همه تیم بدون جستجوی طولانی، آن را پیدا کنند.
این دقیقاً کاری است که باسینرژی برای تیمهای ایرانی انجام میدهد: مستندات، تسکها و کد را در یک منبع واحد حقیقت به هم متصل میکند تا هر تصمیم فنی، هر Design Doc کوچک و هر Postmortem، دقیقاً کنار همان تسکی باشد که به آن مربوط است. با پلن پرو یا بیزینس باسینرژی، تیم خود را روی همان الگویی ببرید که تیمهای حرفهای دنیا سالهاست از آن استفاده میکنند.
📚 منابع:
- Design Docs at Google (Malte Ubl) — منبع اصلی و پراستنادترین مقاله درباره فرهنگ Design Doc گوگل
- Software Engineering at Google (کتاب رسمی، رایگان) — فصل مستندات و Design Doc
- Google SRE Book — Postmortem Culture — منبع اصلی مفهوم Postmortem بیسرزنش
- GitLab Handbook — Handbook-First Documentation — سند رسمی گیتلب درباره این فرهنگ
