آنچه می‌خواهید انباره‌ها درباره پروژه‌تان بازگو کنند

از قدیم گفته‌اند که برای اثرگذاری مثبت در نخستین رویارویی تنها یک فرصت خواهید داشت. این امر اندکی کلیشه‌ای به نظر می‌رسد ولی هرطور که آن را در نظر بگیریم بازهم نصیحتی عملی به‌حساب می‌آید.

این امر در قلمرو متن‌باز می‌تواند تفاوت میان‌پروژه‌ای که موفق می‌شود و پروژه‌ای را رقم بزند که شکست می‌خورد. به همین دلیل نیز ایجاد‌ یک اثرگذاری مثبت در نخستین رویارویی در زمانی که یک مخزن را به جهانیان عرضه‌می‌کنید، بسیار مهم و ضروری خواهد‌بود. حداقل اگر انگیزه‌های شما شامل کسب کاربران، ساختن یک جامعه از مشارکت‌کنندگان و جذب بازخورد باشد به این موضوع توجه خواهید‌داشت.

برداشت‌های اولیه

وقتی‌که در ژانویه سال 2016 به‌عنوان یک تبلیغ‌کننده و ترویج‌دهنده سیستم‌های متن‌باز در Zalando آغاز به کار کردم در حقیقت وارث نمونه کاری از سازمان GitHub شده‌بودم که سه سازمان مختلف و بیش از 360 مخزن را به یکدیگر مرتبط می‌ساخت. بررسی‌های دقیق‌تر من نشان داد که بسیاری از این مخازن در زمینه ارائه اسناد کاری، کاربردی بودن (بیشتر به‌دلیل اینکه به‌صورت سفت‌وسخت با سیستم داخلی ما هماهنگ شده‌بودند) و یا راهنمایی آن‌برد برای کاربران و شرکت‌کنندگان جدید، خروجی چندانی ارائه‌نمی‌کردند. پروژه‌های اندکی راهنماهای مشارکت‌کنندگان و راهکارهای نصب و تنظیمات را ارائه کرده‌بودند و یا چشم‌اندازی واضح از هدف پروژه ارائه کرده‌بودند.

نخستین اثرگذاری دریافتی از انباره‌هایمان کاملاً مثبت بود. از آن به بعد بود که تیم ما شروع به پیشرفتی فراوان کرد. ما یک واحد پرورش جدید در سازمان GitHub ایجاد کردیم که به پروژه‌های آزمایش‌نشده اختصاص داشت (همچنین به‌عنوان یک آرشیو عمل می‌کرد) و اسنادمان را نیز بازبینی کردیم و بهبود بخشیدیم و فایل‌هایی را که کم بودند به آن اضافه کردیم. این کار برای نام‌بردن از برخی تلاش‌های جمعی برای روایت‌کردن داستان‌های متقاعدکننده‌تر و درنتیجه اثرگذاری مثبت‌تر در نخستین رویارویی انجام شد. این کار همچنان ادامه دارد و ما این فرایند را تکرار کرده و به ویرایش مشغول می‌شویم.

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

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

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

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

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

از سوی دیگر نیز اگر انباره‌های شما با کمبود برخی از این موارد ضروری روبرو باشند آنگاه یک بازدیدکننده که در اطراف GitHub org می‌گردد (خواه می‌خواهد درخواست شغلی بدهد و یا اینکه دلایل دیگر برای خود داشته‌باشد) ممکن است به جمع‌بندی‌های منفی دست پیدا کند. این جمع‌بندی ممکن است این باشد که سازمان شما برای نگارش اسناد اهمیت بالایی قائل نیست و این امر می‌تواند موجب شود که سؤال‌های بیشتری برای توسعه‌دهندگان پیش بیاید؛ سوال‌هایی مانند اینکه آیا می‌توان به‌صورت موثرتری مشکل اسناد را حل کرد (اینکه شما چرا به این موضوع مهم مربوط به بهره‌وری رسیدگی نکرده‌اید؟) شاید تیم شما قانون عدم‌مداخله در زمینه بخش تست را اجرایی می‌کند یا (در شرایط جدی‌تر) حتی به تولید یک نرم‌افزار باکیفیت اهمیتی نمی‌دهد. درهرحال امیدواریم در استفاده از روایت داستان برای جذب همکارانی در خارج از محیط کاری عادی خود و سایر شرکت‌ها و پذیرندگان و بهترین متقاضیان کار برای پیوستن به جامعه خودتان موفق باشید.

داستان‌هایی که می‌گویید

روایت داستانی به‌صورت طبیعی از روشی که شما نرم‌افزار متن‌باز خود را تولید می‌کنید نشأت می‌گیرد. اگر پروژه تیم شما رویکردی را دنبال می‌کند که من آن را دنبال‌کردن تکه‌های نان می‌نامم (نخست A را نصب کنید تا از B استفاده کنید سپس با استفاده از A و B می‌توانید C را نصب کنید و غیره) آنگاه ممکن است تمامی موارد موردنیاز برای یک پروژه متقاعدکننده را در اختیار داشته‌باشید. بااین‌وجود شما دنبال‌کردن این فرایند برای افراد مختلف را دشوار می‌کنید. در بخش‌های مربوط به بسته‌بندی و ذخیره‌سازی فایل‌ها برای جابه‌جایی نیز می‌توان انتظار داشت که شرکت‌های مشابه حجم بالایی از فعالیت را تنها برای نصب و استفاده از تجهیزات شما متحمل شوند که انتظار انجام این کار تا حدی یک انتظار غیرواقعی به نظر می‌رسد. آیا هدف شما گمراه کردن یا درهم شکستن مردم است یا اینکه می‌خواهید با ارائه یک تجربه کاربری عالی آنها را با خود همراه سازید؟

هدف چیست؟ این نخستین سوالی است که باید پیش از شروع نگارش کدها از خود و تیم‌تان بپرسید. این امر در حقیقت زمینه اصلی برای توسعه پروژه در مسیری که وضوح و تمرکز پروژه را بالا می‌برد شکل می‌دهد. در زمینه توسعه سریع نیز ما محصولات بزرگ و مزایای مربوط به آ‌نها را در قالب داستان‌های قابل‌درک و کوتاه برای کاربران تقسیم‌بندی می‌کنیم. این امر موجب می‌شود تا محصول و مهندس‌تان بتوانند به‌صورت موثری با هم ارتباط برقرار کنند. همچنین مهندسان می‌توانند فعالیت‌های فنی‌ را که برای ارائه تجربه کاربری مناسب به آن نیاز دارند به کمک این روش به‌خوبی انجام بدهند. فرمت استاندارد یک داستان برای کاربران به‌این‌ترتیب است:

• به‌عنوان (چه کسی) ...
• می‌خواهم (کاری را انجام بدهم) ...
• تا بتوانم (ایجاد یک نتیجه) ...

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

داستان خود را سبک‌سنگین کنید

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

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