کتاب «یک دست صدا ندارد؛ راهنمایی برای کار گروهی بهتر» ترجمه شده توسط روژین بابایان و صبا جمالیان ، ویراستار: مونا اصفهانی
«مهندسی آسونه. این آدمها هستند که سخت اند.»
بیل کاوگرن، معاون سابق کل شاخۀ مهندسی در گوگل
زندگی پر از اتفاقات پیشبینی نشده است. هیچکدام از ما دو نفر هیچوقت فکرش را هم نمیکردیم که یک روز کتابی در مورد کار تیمی و همکاری در مهندسی نرم افزار بنویسیم.
مثل خیلی از خوره های کامپیوتر، ما هم دائماً خودمان را با کامپیوتر مشغول میکردیم و تصمیم گرفتیم از این علاقه راهی برای کسب درآمد برای زندگی بعد از دانشگاه پیدا کنیم. مثل خیلی از هکرهای دوره و زمانۀ خودمان در سال های دهۀ 90، وقتمان را برای ساختن کامپیوتر با قطعات استفاده شده، نصب نسخه های لینوکس از روی تعداد زیادی فلاپی دیسک و یاد گرفتن سیستم های یونیکس صرف میکردیم. ابتدا به عنوان ادمین سیستم عامل ها کارمان را شروع کردیم و با شروع دوران طلایی، اما حباب گونۀ عصر داتکام برنامه نویس شرکت های کوچک شدیم. وقتی این حباب ترکید، وارد شرکت هایی شدیم که از سقوط، جان سالم به در برده بودند و بعد از طی این مراحل در یک شرکت استارت آپ استخدام شدیم تا به صورت تمام وقت روی طراحی و برنامه نویسی یک پروژۀ کاملاً متن باز بر اساس سیستم ورژن کنترل و به اسم ساب ورژن کار کنیم.
اما بین سال های 2000 و 2005، اتفاقی غیرمنتظره برای ما رخ داد. زمانی که روی عملیات ساب ورژن کار میکردیم، وظایف و مسئولیت های ما به آرامی تغییر کردند. ما دیگر در خلوت خود و به تنهایی مشغول کدنویسی نبودیم، بلکه در حال مدیریت و رهبری یک پروژۀ بزرگ بودیم. این به این معنی بود که باید کل روز در چندین چَت روم مختلف با گروه های متفاوت برنامه نویسی صحبت میکردیم که به صورت داوطلبانه روی پروژه کار میکردند. و این به معنی آن بود که تقریباً تمام امکانات و توسعۀ نرم افزار را باید از طریق ایمیل هماهنگ میکردیم. در طول این مسیر متوجه شدیم که کلید موفقیت یک پروژۀ برنامه نویسی فقط در یک کدنویسی فوق العاده خلاصه نمیشود، بلکه نحوۀ همکاری و ارتباطات افراد دخیل در پروژه هم به همین میزان حائز اهمیت است.
سال 2005، شعبۀ دفتر مهندسی گوگل در شیکاگو را تأسیس کردیم و زندگی کاریمان را به عنوان دو برنامه نویس ادامه دادیم. در این نقطه از زندگی، ما هر دو غرق در دنیای متن باز شده بودیم و نه تنها پروژۀ ساب ورژن را اداره میکردیم، بلکه مالک بنیاد نرم افزاری آپاچی هم شده بودیم. ما پروژه مان را به زیرساخت های گوگل منتقل کردیم و یک سرویس جدید برای میزبانی پروژه های متنباز که مشابه سرویس ردیابی منابع بود، ارائه دادیم. سپس به مرور در همایش ها و کنفرانس هایی که برای مهندسین نرم افزار برگزار میشد، مثل پایکان و آپاچی کان و اُ. اس. کان و در نهایت گوگل آی. اُ. سخنرانی کردیم. اینجا بود که متوجه شدیم به دلیل تجربه هایی که هم در محیط های شرکتی بزرگ و هم در کار با پروژه های متن باز به دست آورده بودیم، مهارت و دانش و کارایی تیم های نرم افزاری را یاد گرفته بودیم. سخنرانی های طنزآمیز ما در مورد روش های ناکارآمد و اشتباه توسعۀ نرم افزار، مثل ارائۀ «عادت های بد در ساب ورژن» کم کم به سخنرانی در مورد روش های محافظت تیم ها از چنگال آدم های احمق تبدیل شدند. به عنوان نمونه، سخنرانی «چطور پروژه های متن باز از دست انسان های سمی نجات پیدا میکنند؟» باعث شد تا کم کم افراد بیشتری وارد بحث های ما شوند، تا آنجایی که میشد به این گردهمایی ها یک جور هایی درمان گروهی هم گفت! همه با مشکلاتی که ما در موردشان صحبت میکردیم به نحوی احساس نزدیکی میکردند و میخواستند این مسائل را به صورت گروهی ریشه کن کنند.
حالا ما اینجا هستیم! شش سال بعد، با مقادیر زیادی سخنرانی در مورد مشکلات کارِ گروهی و تیمی در برنامه نویسی و مهندسی نرم افزار. ویرایشگر ما در انتشارات O’Reilly Media به ما پیشنهاد داد که این صحبت ها را به صورت یک کتاب دربیاوریم. بقیۀ داستان که دیگر مثل روز روشن است.
این کتاب برای چه کسانی است؟
این کتاب در ابتدا برای برنامه نویسان نوشته شده بود. برای کسانی که در تلاش هستند تا در مقام و حرفۀ خودشان پیشرفت کنند و نرم افزارهای فوق العاده تولید کنند. ولی در دومین نسخه ای که از کتاب منتشر میکنیم، برای ما کاملاً مشخص شده است که مطالب این کتاب برای گروه وسیع تری از آدمها قابل استفاده است. اگر شما مشغول کاری هستید که نیازمند همکاری با افراد دیگر روی یک موضوع خلاقانه است، این کتاب برای شما مناسب است. ممکن است شما عضو یک گروه محلی، مذهبی یا گروه دوستی یا عضو یک کمیته یا تیمی از معمارها باشید. در هر صورت، ما دو نکته را در مورد شمای خواننده مد نظر قرار میدهیم:
- شما در یک تیم هستید و با یک سری افراد خلاق دیگر همکاری میکنید. احتمالاً عضو یک شرکت بزرگ یا محیط ساختار یافته مشابه دیگری هستید.
- شما از ساختن، لذت میبرید و اعتقاد دارید که ساختن چیزها باید لذت بخش باشد و پاداشی همراه خود داشته باشد. اگر هدف شما از تولید محصول، صرفاً کسب درآمد برای امرار معاش باشد، احتمالاً خیلی علاقه ای به خودسازی و رضایت شغلی نداشته باشید.
تجربۀ شخصی ما از مهندسی نرم افزار می آید. به همین دلیل بیشتر مثال هایی که ما در این کتاب می آوریم، از همین دنیای نرم افزار است. ولی تقریباً تمام فرایندها و استراتژی هایی که در این کتاب مطرح میکنیم قابل تعمیم به سایر رشته های خلاقانه نیز هستند.
حین بررسی اینکه مهندسین چطور میتوانند با دیگران همکاری خوبی داشته باشند، به موضوعاتی برخورد میکنیم که در نگاه اول، به نظر نمی آیند بخشی از شرح مسئولیت های یک مهندس باشند. در بعضی صفحات این کتاب در مورد این صحبت خواهیم کرد که چطور یک تیم را رهبری کنیم یا یک سازمان را هدایت کنیم یا حتی با کاربران نرم افزار خود یک رابطۀ صمیمانه و سالم را برقرار کنیم. با یک نگاه کلی، به نظر میرسد که بخش های این کتاب برای مدیران تیم ها نوشته شدند، ولی ما به شما اطمینان میدهیم که بالاخره روزی خواهد رسید تا شما هم خودتان را در جایگاهی ببینید که این مهارت ها را به کار گرفته اید. ناباوری را کنار گذاشته و ادامۀ این کتاب را بخوانید. هرچه که در این کتاب نوشته شده، به کسانی که سازندۀ یک محصول هستند، ارتباط دارد.
نویسندگان کتاب، Brian Fitzpatrick و Ben Collins-Sussman توسعه دهندگان اصلی نرم افزار کنترل نسخۀ ساب ورژن و از مهندسین ارشد روزهای اول شرکت گوگل هستند. آنها شعبۀ گوگل در شهر شیکاگو را تأسیس کرده و تیم ها و مهندسین زیادی را هم در شرکت های تجاری و هم در پروژه های متن باز، هدایت و رهبری کرده اند. Brian در حال حاضر مدیرعامل و مؤسس یک شرکت نرم افزاری تحت عنوان Tock است و Ben مدیر ارشد شرکت گوگل در شیکاگوست. سالهاست که هر دو سمینارها و سخنرانی های زیادی را در نقاط مختلف دنیا در زمینۀ توسعۀ تیمی نرم افزار برای مهندسین کامپیوتر برگزار میکنند.
نقد و بررسی‌ها
هیچ دیدگاهی برای این محصول نوشته نشده است.