کار را که کرد، آنکه زخمی کرد

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

نگاهی به ارزشهای اسکرام

این پست بازنشری از یک پست قدیمی به همین عنوان است.

یکی از آخرین تغییراتی که در راهنمای اسکرام اضافه شده است بخشی است به نام ارزش های اسکرام. مطالعه این ارزش ها برای من خیلی جالب بود.

این ارزش ها به صورت زیر هستند:

  • تعهد (commitment)
  • تمرکز (focus)
  • بازبودن (openness)
  • احترام (respect)
  • جرات (courage)

ارزش چیست؟

در بررسی ارزش های اسکرام بهتر است ابتدا به واژه ارزش بپردازیم. به راستی ارزش چیست؟ به چه چیز می گوییم ارزش؟

به طور کلی به اموری که برای اعضاء گروه اهمیت دارند و آرمان مشترک اعضاء گروه تلقی می‌شوند، ارزش می گویند. (ویکی پدیا)

با فرض این که من و شما تعریف مشخصی از تیم اسکرام در ذهن داریم، در تعریف بالا کلمه “اعضای گروه” را با کلمه “تیم اسکرام” جایگزین می کنم و جمله به صورت زیر در می آید:

به طور کلی به اموری که برای تیم اسکرام اهمیت دارند و آرمان مشترک تیم اسکرام تلقی می‌شوند، ارزش می گویند.

نکته خیلی مهم در تعریف بالا کلمه آرمان است. کلمه آرمان در لغت به معنای آرزو، حسرت و امید است. (واژه یاب)

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

تعریف سختی بود؟

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

تعهد

در چارچوب اسکرام هر عضو تیم متعهد به موفقیت تیم و اهداف آن می شود. در تمامی مراحل تلاش خود را می کند که اهدافی واقع گرایانه در نظر بگیرد و به رسیدن به آن اهداف متعهد باشد. در اسکرام افراد متعهد می شوند در کنار یکدیگر و با یکدیگر کار کنند تا اهداف را به انجام برسانند.

تمرکز

یکی از بخش های مهم اسکرام تمرکز است. هر عضو تیم در هر بازه زمانی روی تعداد محدودی از مسائل و اهداف واضح تمرکز می کند و سعی دارد با توجه به نقش خود، همکاری لازم جهت رسیدن به اهداف یا حل مسائل را با تیم داشته باشد. (تاکید می کنم با همکاری)

باز بودن

این ارزش یکی از ساده ترین ارزش ها برای درک و در عین حال سخت ترین آنها برای اجراست. در بیشتر سازمان های سنتی بسته بودن اطلاعات و قدرت رابطه مستقیمی با یکدیگر دارند و اکثر پست های مدیریتی با بسته نگه داشتن گردش اطلاعات حفاظت می شوند! باز بودن به این معناست که تمامی اهداف، چالش ها، روش ها، نتایج و تمامی محصولات میانی آنها و فرایندهای تیم قابل رویت برای تمامی اعضای آن تیم باشد. یکی از دلایل این موضوع بیشتر شدن قابلیت بازرسی و تطبیق پذیری (inspect & adapt) در این چارچوب است. زمانی که سیستمی به صورت باز ندارید، از کنشگرهای آن سیستم نمی توان انتظار داشت قادر باشند با شرایط چالش برانگیز به خوبی تطبیق یابند. پیشنهاد می کنم برای مطالعه بیشتر در این زمینه به کتاب “گوگل چگونه کار می کند” مراجعه نمایید. این کتاب فصل فوق العاده مفیدی در این زمینه دارد.

احترام (یک ارزش طلایی)

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

شجاعت

تمامی فلسفه اسکرام روی پذیرش تغییرات استوار است. تغییرات در نیازمندی ها، تغییرات در متدهای تولید، تغییرات در فرآیندها. تیم اسکرام شجاعت پذیرش تغییرات را دارد و یک مسیر یا روش را تنها به دلیل این که از ابتدا اینگونه بوده یا فرد خاصی آن را ارائه کرده است، اجرا نمی کند. بلکه زمانی که تیم به این نتیجه رسید که تغییری برای تیم و محصول مفید خواهد بود با آغوش باز و شجاعت تمام آن تغییر را خواهد پذیرفت. (به استفاده از کلمه تیم توجه داشته باشید)

سخن پایانی

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

برای مطالعه بیشتر در این زمینه می توانید به اینجا مراجعه کنید.

اولویت و شدت باگ


حدود سه سال پیش مطلبی تحت عنوان “خوب باگ بزنیم” در وبلاگم منتشر کردم. موضوع گزارش خطای کارآمد یکی از موضوعاتی هست که به طور روزمره تیم های تولید و تحلیل را درگیر خود خواهد کرد.
در آن مطلب به خصوصیات مختلف یک گزارش خطای خوب پرداختم. اما در تیمی که مشغول کار هستم یکی از چالش های پیش روی ما وارد کردن صحیح و دقیق دو فاکتور Priority و Severity برای باگ ها است. یکی از بهترین توضیحاتی که در رابطه با این دو فاکتور مشاهده کرده ام، توضیحات خود مایکروسافت برای این دو مورد است.

اولویت (Priority)

معیار درجه بندی به باگ ها از زاویه کسب و کار و نیازهای مشتری. اولویت یک باگ ترتیب رفع باگ ها را نشان می دهد. مقادیری مناسبی که برای اولویت وجود دارد را می توان به صورت زیر توضیح داد.
اولویت ۱: باگ هایی با این اولویت نشان دهنده این هستند که محصول بدون رفع آنها قابل ارائه نیست و باید در اسرع وقت حل شوند.
اولویت ۲: باگ هایی با این اولویت نشان دهنده این هستند که محصول بدون رفع آنها قابل ارائه نیست ولی نیاز به رفع فوری آنها نیست.
اولویت ۳: رفع باگ اختیاری است و بر اساس منابع و زمان و ریسک می توان برای رفع آن برنامه ریزی کرد.

شدت (Severity)

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

موارد بالا از اینجا نقل قول شده است. برای مطالعه بیشتر در مورد مدیریت باگ ها می توانید به لینک مذکور مراجعه نمایید.

 

لطفا بدون خطا چک-این (check-in) کنید

تا به حال شده که کدی را get latest کنید. و پروژه شما دیگر build نشود؟ تا به حال شده کسی کاری در سیستم انجام داده باشد. و بعد از آن خطاهای منطقی یا تحلیلی عجیب و غریبی مشاهده شود؟

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

زمان ایجاد تغییرات

هر روز ممکن است تغییراتی را مشاهده کنیم که با بی دقتی در source control وارد شده اند و مشکلات زیادی را به بار آورنده اند. متاسفانه یا خوشبختانه بهترین فرد برای بررسی عوارض یک تغییر همان فردی است که تغییرات را ایجاد کرده. این که شما انتظار داشته باشید بقیه تیم برنامه نویسی مشکلات ناشی از تغییراتتان را در کمترین زمان ممکن رفع کنند انتظاری نابجا است. زیرا تنها کسی که از عمق تغییرات ایجاد شده اطلاع دارد خود شما هستید.

پس خواهش می کنم بدون خطا چک-این کنید. این که پروژه شما build می شود هم کافی نیست. ممکن تغییرات یا کدهای شما مشکلات منطقی در دیگر جاهای سیستم ایجاد کرده باشد. رفع این تغییرات ممکن است برای شما ۱ ساعت زمان ببرد. ولی برای کس دیگری ممکن است خیلی بیشتر از این مقدار زمان بر باشد.

خطاهای شما به نام کس دیگری خواهد خورد

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

ابزار زیادی لازم ندارد

وقتی کاری تست نشده وارد source control می شود و مشکل اساسی پیش می آید، اولین قدم همه ما پیدا کردن مقصر است. معمولا حتی بعد از یافتن مقصر واقعی یا ظاهری موضوع پایان نمی یابد. ممکن است این مشکلات  یک سلسله از تصمیمات فلسفی و مدیریتی در پی داشته باشد. از این که مثلا باید TDD کار کنیم. یا چرا موتور تست اتوماتیک UI نداریم یا هزار موضوع دیگر. وجود همه موارد ذکر شده در یک پروژه و سازمان خیلی خوب است. ولی واقعیت امر این است که برای چک-این کردن کد بدون خطا و عوارض جانبی، تنها امکانی که باید وجود داشته باشد حوصله و تعهد است. بقیه موارد خیلی موارد الزامی ای نیستند.

سعی کنیم با دقت چک-این کنیم.

راهکارهایی برای مشتری، یا رزومه

مواقع زیادی راهکارهایی را می بینیم که دلایل منطقی برایشان پیدا نمی کنیم. تصمیمات و راهکارهایی که یک برنامه نویس ارائه می دهد به طور منطقی باید با توجه به شرایط پروژه امکانات فنی و مالی پروژه و فرهنگ سازمانی و نیازهای مشتری ارائه شده باشد.

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

وقتی یک برنامه نویس هنگام ارائه راهکار در چنین مواقعی منافع  و آینده سازمان و مشتری را مد نظر قرار دهد، قطعا تصمیمات مناسبتری خواهد گرفت.

متاسفانه در دنیای واقعی خیلی این اتفاق نمی افتد. تصمیمات برنامه نویس ها ممکن است بیشتر بر مبنای اثر آن موضوع خاص روی رزومه شخص گرفته شود. مثلا در انتخاب این که یک پروژه تحت وب single page باشد یا نه، قبل از این که به نیاز مشتری توجه شود ممکن است به سابقه کاری و فرصت کسب تجربه شخصی و اثر موضوع sinple page application روی روزمه شخص توجه شود.

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

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

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

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

*ایده اصلی این مطلب از یکی از بخش های کتاب ۹۷Things Every Software Architect Should Know گرفته شده است.


تصمیمات اقتصادی تصمیمات احساسی

درسی از یک نرم افزار ۱۵ دقیقه ای

تصمیمات اقتصادی تصمیمات احساسی

همه ما در پروژه های مهندسی نرم افزاری بودیم و هستیم که هر روز هر فرد تصمیماتی می گیرد. این تصمیمات شاید در کوتاه مدت نتایج خود را نمایان نکنند. ولی بخشی از روند کلی یک پروژه را همین تصمیمات مشخص می کنند.

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

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

  1. عدم شناخت دقیق نیازمندی ها
  2. تغییرات همیشگی و عدم قطعیت در نیازمندی ها
  3. تغییرات ساختاری زیاد در فناوری ها

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

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

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

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

سبگ و سنگین کردن (trade off) در هر تصمیم روزمره هریک از نیروهای فنی و غیر فنی شاغل در یک پروژه نرم افزاری دخالت دارد.

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

  1. قابل بررسی و اندازه گیری از نظر نتایج نیستند. (چون دلایلی و اهداف ملموسی پشت آن ها نبوده است)
  2. فرد تصمیم گیرنده موضع شخصی در قبال آن تصمیم خواهد گرفت

این موارد بحث و تبادل نظر در مورد تصمیمات اتخاد شده را بسیار مشکل می کنند.

هزینه دیرکرد

یکی از فاکتورهایی که در زمان تصمیم گیری باید به آن دقت کرد هزینه دیرکرد است. هزینه دیرکرد در زبان ساده هزینه ای است که سازمان از دیر رسیدن محصول به دست مشتری متحمل خواهد شد.

این هزینه به صورت دقیق قابل اندازه گیری نیست و الزاما هزینه های مادی را شامل نمی شود. ولی همین که به صورت نسبی به این موضوع دقت شود تاثیر بسیار زیادی در تصمیم گیری ها خواهد داشت.

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

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

بهتر است در اتخاذ تصمیمات به بار مالی آن نیز توجه کنیم.  اکثر مواقع نتیجه تصمیمات بر اساس نتایج مالی آنها سنجیده می شوند. یکی از هنرهای مدیران و مهندسین نر م افزار ایجاد توازن در رسیدن به اهداف کوتاه مدت (مانند ارائه نسخه های مورد نظر جهت جذب سرمایه گذاری و یا قرارداد) و اهداف بلند مدت (قابلیت نگهداشت نرم افزار، هزینه های نگهداشت و …) است. اگر تصمیمات در رده های مختلف سازمانی بدور از احساسات و برداشت های غیر مهندسی باشند این امر به راحتی اتفاق خواهد افتاد.

مقدمه ای بر کانبان – Kanban

Kanban یک روش مدیریتی کارا و موثر در مدیریت فرایند تولید نرم افزار است. این روش، یک روش اقتباس شده از روش مدیریت تولید شرکت Toyota است که در اواسط قرن بیستم توسط مهندسین این شرکت ابدا شده.

واژه  Kanban در زبان ژاپنی به معنای کارتهای بصری یا visual card است. در این روش تمامی فرایند تولید نرم افزار به صورت بصری در یک تخته بزرگ نمایش داده می شوند.

به طور کلی می توان فرایند تولید نرم افزار را به صورت یک pipeline دید. که از یک سر آن درخواست ها وارد می شوند. و از سر دیگر آن نرم افزار بهبود یافته خارج می شود.

تنگناها – Bottleneck

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

ظرفیت هر یک از این گروه ها به صورت زیر است:

  • تحلیلگرها: ۱۰ آیتم در هفته
  • برنامه نویس ها: ۱۰ آیتم در هفته
  • تسترها: ۵ آیتم در هفته

همان طور که در شکل بالا مشاهده می کنید. در صورتی که برنامه نویس ها و تحلیلگرها با تمام ظرفیت خود مشغول به کار باشند بعد از دو هفته تعداد زیادی آیتم در صف تست خواهند بود. به این دلیل که گروه تسترها ظرفیت تست کافی برای آیتم های تولید شده ندارند. این انباشت کار در مرحله تست از چند زاویه مضر خواهد بود:

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

اگر شما زودتر متوجه انباشت کار در بخش تست می شدید ممکن بود تصمیمات مختلفی جهت بهبود فرایند تولید و ارائه محصول اتخاذ کنید. به طور مثال:

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

اصول اولیه Kanban

۱) تجسم یا بصری سازی کارها – Visualize the work 

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

۲) محدود کردن کار در فرآیند – Limit the work in process 

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

۳) تمرکز بر جریان – Focus on flow 

با محدود کردن کارها در فرایند (ٌWIP) و اعمال سیاست های تیم محور می توان کنترل مناسبی روی اجرای منظم و مداوم مراحل فرایند و نرمی آن داشت. این کنترل کمک خواهد کرد که تصمیمات مورد نیاز جهت کارایی بهتر فرایند زودتر و تاثیرگذارتر گرفته شوند.

۴) پیشرفت مداوم – Continuous Improvement 

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

 نکته مهم: در Kanban قواعد و مقررات زیادی وجود ندارد و شما می توانید با استفاده از فرایند فعلی سازمان شروع به استفاده از این مدل مدیریتی کنید. به طور مثال نمونه ای از تخته های Kanban که به صورت الکترونیکی است را در زیر مشاهده می کنید:

برای مشاهده کامل تخته Kanban به اینجا  مراجعه کنید.

در این تخته ستون های زیر وجود دارند:

  • Todo: لیست همه کارهای قابل انجام و تمامی سفارشات در این ستون می آیند.
  • Analysis: این اولین مرحله از فرایند است و لیست همه کارهای در حال تحلیل در این ستون آورده می شوند. عدد یک در کنار نام این ستون نشان دهنده محدودیت کارهای ناتمام در این مرحله است. به عنوان مثال در این فرایند گروه تحلیل تنها می تواند یک آیتم در حال تحلیل داشته باشد. و فقط در صورتی می تواند کار جدید از ستون Todo بردارد که تحلیل آیتم فعلی به پایان رسیده باشد. از این جهت Kanban را یک Pull system یا سیستم مدیریت کششی می نامند. یعنی گروه ها هستند که کارها را جهت انجام بر می دارند.
  • Analysis Done: همه آیتم های تحلیل شده به این ستون منتقل می شوند.
  • Development: وفتی گروه برنامه نویسی جایی برای کار جدید داشت (یعنی کمتر از ۱۰ عدد کار موازی در حال انجام بود) می تواند از لیست Analysis done آیتمی را برای برنامه نویسی انتخاب نماید.
  • Development Done: وقتی گروه برنامه نویسی کار آیتمی را به اتمام رسید می تواند آن را به این ستون منتقل نماید.
  • Test: تیم تست نیز کارهای در حال انجام خود را در این ستون وارد می کنند. قراعد مراحل قبلی در این مرحله نیز صادق است.
  • Test Done
  • Publish
  • Publish Done: این مرحله نماینده اتمام آیتم مورد درخواست است. الان وقت این است که پول دریافت شود!!!

در این تخته نمونه از مفاهیمی مانند Queuing (تمامی ستون هایی که با کلمه Done به پایان می رسند) نیز استفاده شده که در محدوده این مطلب نیستند.  همچنین موضوعات مربوط به اولویت بندی در فرصت مناسبتری بررسی خواهد شد.

نکته مهم در مورد Kanban

زمانی که تصمیم به استفاده از روش Kanban گرفته می شود. نیازی نیست تمام فرایندهای فعلی موجود در سازمان دور ریخته شود. در واقع Kanban از فلسفه ژاپنی Kaizen استفاده میکند. که به معنای بهبود مداوم است. به این صورت که فرایندهای مورد استفاده در سازمان به صورت انقلابی کنار گذاشته نشود. و به مرور به نقطه بهبود و کارایی مناسب برسد و همیشه در حال بهبود باشد.

برای مطالعه بیشتر در این زمینه می توانید از منابغ زیر استفاده نمایید.

Kanban: Successful Evolutionary Change for Your Technology Business

Personal Kanban: Mapping Work | Navigating Life

مهارت های غیر فنی یک برنامه نویس

به عنوان برنامه نویس همه ما به دنبال بهتر شدن در زمینه فنی هستیم. همه ما تصور می کنیم دانش فنی بالاتر مساوی است با درآمد بیشتر.

تا به حال افرادی را دیده اید که علارغم دانش فنی پایین تر از شما، موقعیت و پست بالاتری دارند؟ البته ممکن است خیلی از این افراد ارتباط هایی داشته باشند که شما ندارید! ولی در اصل قضیه به این اندازه سیاه نیست.

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

۱) شرکت در جلسات و مدیریت آنها

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

۲) برقراری ارتباط

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

۳) قابلیت تحلیل انتظار مشتریان

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

۴) کار تیمی فوق العاده

برنامه نویسی و تولید نرم افزار به شدت کار تیمی ای است. شما نمی توانید به صورت انفرادی پیشرفت کنید. پیشرفت شما در گرو مهارت شما در انجام تیمی کارهاست.

۵) آموزش

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

موارد فوق چند مورد از مهارت هایی بود که می توان برای یک برنامه نویس در نظر گرفت. موارد پیشنهادی دیگری را در نظر دارید؟

چرا برنامه نویس ها چند شغله هستند؟

این موضوع را که بیشتر برنامه نویس ها چند شغله هستند نمی توان انکار کرد. در واقع این موضوع که اکثر ایرانی ها چند شغله هستند را نمی شود انکار کرد. حتی اگر کسی بتواند با شگردهای خلاقانه این موضوع را پنهان کند.

شاید بعضی مواردی که در این مطلب مطالعه خواهید کرد در مورد مشاغل غیر از برنامه نویسی نیز صحت داشته باشد.

چرا برنامه نویس ها چند شغله می شوند؟

۱) عدم امنیت شغلی

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

۲) پرداختی نامناسب

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

۳) یادگیری

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

۴) کسب تجربه

وقتی شما با مشکل فنی یا غیر فنی ای بارها و بارها بر می خورید طبیعتا مهارت حل مسائل مرتبط در شما ایجاد خواهد شد. این موضوع با دانش فنی فرق اساسی دارد.

۵) پیشرفت

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

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

موارد ذکر شده از نظر اهمیت مرتب شده بودند. به طوری که موارد بالاتر از نظر بنده اهمیت بیشتری داشته اند.

آیا سابقه کاری در درآمد برنامه نویسی نقش مهمی دارد؟

title

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

جواب ساده به این سوال خیر است.

در طول دوران کاری برنامه نویس هایی را دیده ام که با تعداد سال های سابقه کاری بالا درآمد هایی به مراتب پایین به نسبت آن سابقه داشته اند.

دلیل این امر چیست؟ چرا در شغل برنامه نویسی، همانند خیلی از مشاغل دیگر با افزایش تجربه یا سابقه کاری الزاما درآمد فرد افزایش نمی یابد؟

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

پس یک برنامه نویس می تواند سابقه کاری زیادی داشته باشد. ولی در تمام این مدت کار مهم و با ارزشی انجام نداده باشد.

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

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

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

البته نکته مهم که دوست دارم در این جا ذکر کنم این است که منظور از دانش، دانش برنامه نویسی است نه یادگیری کتابخانه های مختلف. دانش کد نویسی خوب، معماری نرم افزار، شی گرایی، اطلاعات پایه زبان های برنامه نویسی و …

با افزایش دانش برنامه نویسی فعال در برنامه نویس ها، می توان امیدوار بود که بدهی فنی موجود در کارهای آنها هر روز کاهش یابد.

ولی همین تعداد سال های زیاد فعالیت در حوزه برنامه نویسی در چه مواردی به کمک یک برنامه نویس خواهد آمد؟

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


بروزرسانی ۱۳۹۴/۱۰/۱:

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