در ستایش سندسازی
کی قراره این داکیومنتا رو بخونه؟ چرا وقت تلف می‌کنی؟
اینها و امثالشون رو تو کار زیاد شنیدم اما از نظر من هر کاری می‌تونه نوعی وقت تلف کردن باشه، به‌جز داکیومنتیشن یا سندسازی.
این جمله رو از عزیزی در یکی از جلسات ریترو بعد از لانچ محصولی در نوبیتکس به یاد دارم که می‌گفت: هر اتفاقی که افتاد؛ مهم اینه که ما الان داکیومنت داریم و می‌تونیم دفعه بعد خیلی از راه‌ها رو نریم و خیلی از راه‌ها رو سریع‌تر بریم.
دارایی‌های یک شرکت شاید از نگاه بعضی زمین و ساختمون، از نگاه بعضی گردش مالی، از نگاه بعضی برند و از نگاه بعضی افراد اون شرکت باشن اما اون دارایی که همیشه ماندگاره، داکیومنت‌هایی هستن که در جایی گوشه یک فولدر درایو ذخیره شدن. تمام اون دارایی‌ها ممکنه یک روز از بین برن. ممکنه اون شرکت زمیناش بی‌قیمت شه، برندش بدنام شه، آدم‌های متخصصش مهاجرت کنن اما داکیومنت خوب همیشه یک داکیومنت خوب باقی می‌مونه.
از نظر من آدم‌های حرفه‌ای نه کسانی هستن که بیشترین و بهترین پرمورمنس رو از خودشون نشون می‌دن، بلکه کسانی هستن که با داکیومنت کردن باعث می‌شن تجربه‌هاشون از شکست‌ها و پیروزی‌ها نه‌تنها برای خودشون بلکه برای کسانی که در آینده قراره در اون جایگاه قرار بگیرن، به یادگار بمونه.
حالتی رو در نظر بگیرید که در موقعیت شغلی جدید مشغول به کار شدید که نفر قبلی چه‌بسا بسیار کاربلد بوده و نتایج خوبی از کارهاش گرفته اما دست برقضا مهاجرت کرده و حالا شما جایگزین اون شخص هستین. قراره بهترین عملکرد رو از خودتون نشون بدین اما هیچ‌چیز از تجربیات قبلی نمی‌دونین. خبر ندارین سر لانچ محصول قبلی چه پروموشن پلنی در نظر گرفته شده؟ نمی‌دونین گزارش سال قبل طی چه مراحلی منتشر شده؟ نمی‌دونین اصولا نرخ کلیک لینک‌های آگهی‌های قبلی چقدر بوده و حتی نمی‌دونین با کدوم رسانه‌ها ارتباط دارین؟ اینجاست که سندسازی رو باید ستایش کرد.
در بهترین حالت من دیدم داکیومنت‌هایی به‌عنوان پروپوزال و لسن‌لرن آماده می‌شن که البته دومی عموما فیدبک‌های افراد درگیر پروژه‌ست که همینطور پشت سر هم ردیف شده.
ولی من به شخصه داکیومنت‌ها رو به چهار دسته تقسیم می‌کنم:
۱- سند پیشنهاد طرح
هیچ ایده‌ای تا قبل از نوشته شدن ارزش مطرح کردن نداره. چیزی که به تجربه ناچیزم یاد گرفتم، اینه که تا قبل از نوشتن سند پیشنهاد طرح هیچکس نمی‌تونه جواب خوب و مناسبی به سوال «که چی؟» بده. سوالی که ممکنه درباره تمام ایده‌ها، از بدترین تا بهترین، مطرح بشه. وقتی در سند پیشنهاد طرح موارد کلیدی مثل اهداف، فرایندها، ذینفعان، مخاطبان، بودجه مورد نیاز، نفرساعت مورد نیاز، نتایج کلیدی، سناریوهای شکست مشخص بشن، انگار که خود ما قبل از هرکس دیگه‌ای از خودمون پرسیدیم: که چی؟
۲- سند آنبوردینگ
گیرم که قرار شد طرحی در تیمی اجرایی بشه؛ آیا شما تنها کسی هستین که قراره اون رو انجام بده؟ به کمک هیچکس احتیاج ندارین؟ قطعا انجام هر طرحی نیاز به همراهی افراد با تخصص‌های مختلف داره. آیا قراره برای هر کدوم به صورت جداگانه ساعت‌ها وویس بفرستین؟ شاید اولین راه حل برای آنبورد ماندن همه افراد درگیر پروژه این باشه که از همه بخوایم در تمام جلسات شرکت کنن تا در جریان ریز جزییات قرار بگیرن، اما چرا یک فرانت‌اند دولپر که قراره لندینگ کمپین رو طراحی کنه باید تو جلسه انتخاب تگ‌لاین حضور داشته باشه؟ یا چرا یک کارشناس سوشال مدیا باید در جلسه‌ای حضور داشته باشه که قراره در اون راجع به پلن پروموشن رسانه‌ای صحبت کنیم؟
(داخل پرانتز؛ از نظر من اگر در جلسات تخصصی احتمال داره صحبت‌هایی بشه که بهتره بقیه هم در جریان باشن، بهتره کلا اون جلسات رو برگزار نکنیم چون قطعا قرار نیست چیزی به نام دستورجلسه در اون رعایت شه و با یک جلسه «از هر دری سخنی» و در حالت بدتر با یک جلسه «ایده از ۱۰ نفر، اجرا از ۲ نفر» روبرو خواهیم شد.)
اون‌چه که برای آنبوردینگ لازمه، یک داکیومنت صریح با یک فهرست بلند اما توضیحات کوتاهه. ممکنه بعضی از میان‌تیتر‌ها کلا سه کلمه توضیح داشته باشن. چراکه داکیومنت آنبوردینگ اگر طولانی و بی‌نظم باشه ممکنه کلا خونده نشه. در طرف مقابل داکیومنت آنبوردینگ لازمه همه موارد رو ریز کرده باشه تا هرکس بتونه سریع بخش‌هایی که بهش مربوطه رو پیدا کنه و بره سراغش.
در داکیومنت آنبوردینگ لازمه به صورت کوتاه درباره هدف، پیام‌ها، مخاطبان، kpiها، ذینفعان سازمانی صحبت شه. بعضا to do list یا گانت‌چارت جای داکیومنت آنبوردینگ رو میگیره در حالیکه اینها جزوی از اون داکیومنت اصلی هستن. در داکیومنت آنبوردینگ بعد از تشریح کلیات اهداف و برنامه‌ریزی‌های انجام شده برای پروژه، تازه پای تودو لیست وسط میاد. این تودو لیست رو درسته که بک نفر قراره بنویسه، اما اگر به تایید تمام ذینفعان نرسه، باید انداختش دور. مواردی مثل ترلو و اسلک و امثالهم هیچموقع نمی‌تونه جای تودولیستی که توی یه فایل اکسل یا نهایت گوگل شیت آماده شده رو بگیره. بعدا در ستایش گوگل شیت هم خواهم نوشت.
۳- گزارش عملکرد
ایولا، خداقوت، خسته نباشین، خیلی خوب بود. اینها برای شما نه آب می‌شه، نه نون. باید بعد از انجام هر پروژه‌ای که یکم بزرگ باشه، گزارش عملکرد بنویسین. اون فهرست بلندبالای kpiها که تو داکیومنت پروپوزال گذاشته بودیم برای قشنگی نبود، بلکه پیشنیازی برای آماده‌سازی گزارش عملکرد بود. در گزارش عملکرد هیچ‌چیز یه جز kpiها و بررسی دقیقشون نباید وجود داشته باشه. اینکه ما هدفمون افزایش فالوور پیج اینستاگرام بوده، کاملا صریح و روشنه. لازم نیست در گزارش عملکرد درباره افزایش ایمپرشن پیج و نرخ مشارکت فالوورها صحبت کنیم.
فقط و فقط در یک گزارش عملکرد می‌شه موفقیت یا شکست پروژه رو ارزیابی کرد. اگر مدیری گفت مرسی که فالوورای اینستا زیاد شد ولی چرا یوزر نیاوردین؟ بپرسین اونموقع که در داکیومنت پروپوزال kpi تعریف می‌شد حواستون کجا بود؟
این داکیومنته که باعث می‌شه بتونید دربرابر رفتارهای سلیقه‌ای حرفی برای گفتن داشته باشید. اگر عملکردتون خوب بوده، داده‌محور تقاضای پاداش کنید و اگر عملکرد خوبی نداشتید، تعارف رو کنار بگذارین.
۴- گزارش تجربه‌محور
هیچکدوم از سه داکیومنت قبلی نمی‌تونه جای یک گزارش تجربه محور رو بگیره. کمتر جایی رو دیدم و از کمتر کسی شنیدم که چنین داکیومنتی مگر در کلان پروژه‌های عظیم برتر مثل ورود استارتاپ به بورس آماده شده باشه. چه‌بسا هرمرتبه که چنین گزارشی رو آماده کردم، به وقت‌تلف‌کردن متهم شدم. به ازای هر ماه زمانی که درگیر یک پروژه هستید، ممکنه یک هفته زمان برای نوشتن گزارش تجربه محور لازم داشته باشید. مثلا اگر چهار ماه برای برگزاری یک رویداد زمان صرف شده، اختصاص دادن یک ماه زمان یکی از اعضای تیم به نوشتن گزارش تجربه محور، همچنان وقت‌تلف‌کردن نیست.
در یک گزارش تجربه محور، تمام آنچه که یک نفر برای انجام دوباره اون پروژه نیاز داره آورده می‌شه. این یعنی در ابتدا باید فازهای مختلف پروژه به عنوان فصول مختلف در نظر گرفته بشن و گفته بشه در هر بخش تصمیم اولیه چی بوده، چه چالش‌هایی به وجود اومده،چطور از چالش‌ها عبور کردیم، کجا شکست خوردیم، کجا هوش و ذکاوتمون باعث پیروزی شد و...
در این سند لازمه کانتکت‌پوینت تمام افراد بیرون و درون سازمان که در این پروژه حتی کوچکترین اپروچی بهشون انجام شده هم اورده شه.
برای مثال در گزارش تجربه‌محور یک رویداد لازمه مذاکراتی که با وندور‌های مختلف انجام شده بوده و نتیجه‌شون و حتی توصیف شخصیت افرادی که باهاشون ارتباط گرفتیم باید وجود داشته باشه. خود من در یکی از گزارش‌های تجربه محور درباره فرآیند دریافت مجوز از تمام سرگرد و سرهنگ‌هایی که ملاقات کردم و تجربه‌م از تعامل باهاشون نوشتم. شاید نفر بعدی که بخواد این مسیر رو بره، کاری که من ۱۰روز طول کشید تا از این اتاق به اون اتاق برم رو در یک نصفه‌روز انجام بده.
در یک گزارش تجربه‌محور تمام داکیومنت‌های متفرقه، طرح‌های پوستر، ویدیو‌ها، لیست افراد، فاکتورها، عکس‌ها، گزارش عملکرد واحدهای مختلف و... همه و همه در یک فولدر جمع‌آوری می‌شه و به گزارش پیوست می‌شه.
شاید همچنان فکر کنید اینکه برای یک پروژه چهار ماهه، یک ماه زمان بذاریم و گزارش تجربه‌محور بنویسیم، وقت تلف کردنه، اما مطمئن باشید با این کار، سال بعد به جای چهارماه شاید یک ماه برای انجام دوباره اون پروژه زمان لازم داشته باشید.
احتمالا تا صبح می‌تونم #در_ستایش داکیومنتیشن و #سندسازی صحبت کنم، حتی با اینکه می‌دونم مستندسازی ترجمه بهتریه. اگر به این موضوع علاقه دارید، احتمالا این مقاله به دردتون می‌خوره:
https://www.egnyte.com/guides/life-sciences/good-documentation-practice
من، احمدرضا نجفی، تلاش می‌کنم تا هرچند وقت یکبار در قالب مجموعه پست‌های #در_ستایش راجع به مواردی که در کار بهشون علاقه دارم صحبت کنم.
