نکاتی درباره تحویل دادن پروژه‌های نرم‌افزاری

در سراسر اینترنت کلی نوشته و مطلب پیدا می‌کنید که به شما یاد می‌دن چطور با هر زبان و تکنولوژی که نیاز دارین یک نرم‌افزار بنویسید ولی کمتر آموزشی پیدا می‌کنید که درباره تحویل دادن پروژه‌های نرم‌افزاری به شما چیزی یاد بده.

به طور کلی شرکت‌ها و تیم‌های نرم‌افزاری دو نوع پروژه نرم‌افزاری کلی به عنوان خروجی می‌تونن ارائه بدن: پکیج‌های نرم‌افزاری که معمولاً مشتری خاصی نداره و برای عموم مشتریان (چه در یک حوزه اختصاصی و چه در یک حوزه عمومی) تولید می‌شن. نمونه پکیج‌های نرم‌افزاری می‌شه مثلاً به نرم‌افزارهایی مثل AutoCad یا Photoshop‌ که در حوزه اختصاصی تولید شدند یا نرم‌افزاری مثل KMPlayer که در حوزه عمومی‌تری تولید شده اشاره کرد.

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

وقتی شما دارین یک پکیج نرم‌افزاری تولید می‌کنین، بر حسب روشی که برای نیازسنجی و دریافت نیازهای عموم مشتریانتون استفاده کردید یک feature set دارید که به شما می‌گه این نسخه از نرم‌افزارتون چه قابلیت‌هایی باید داشته باشه. تیم برنامه‌نویسی شما این قابلیت‌ها رو به نرم‌افزارتون اضافه می‌کنه و بالاخره بعد از یک پروسه تست‌های مختلف شما یک نسخه جدید رو release‌ می‌کنین.

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

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

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

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

نکاتی درباره تحویل دادن نرم‌افزار

  • سعی کنید کلیه توافقاتی که با مشتری بر سر اجزای مختلف نرم‌افزار دارید رو مکتوب کنید. این کار هم به شما کمک می‌کنه که بدونید چی دارید تولید می‌کنید و هم به مشتری که بدونه در نهایت چی می‌خواد تحویل بگیره. وقتی یک مجموعه قابلیت مکتوب به صورت یک چک لیست داشته باشید خیلی راحت‌تر و سریع‌تر می‌تونید نرم‌افزارتون رو تحویل بدید.
  • پیرو مورد بالا، توافقات و صورتجلسات کارهایی که بر عهده شما یا مشتری هست رو به صورت ریز بنویسید. مثلاً اگر قرار هست نرم‌افزار شما بخشی به نام گزارشات داشته باشه، به جای اینکه فقط بنویسید گزارشات مدیریتی، دقیقاً نام و نوع گزارشات و فیلدهایی که در اون‌ها استفاده می‌شه رو مستند کنید. در واقع یک سند نیازمندی‌های نرم‌افزار باید تولید کنید که در موردش در نوشته دیگه‌ای توضیح خواهم داد.
  • برای کارهای خودتون و مشتری deadline‌ بگذارید. بدون تاریخ مشخص، هیچ کاری در هیچ زمانی به اتمام نخواهد رسید.
  • اگر نرم‌افزارتون امکان ورود اطلاعات داره، قبل از اینکه به مشتری تحویل بدید، چند تا داده sample وارد کنید. دقت کنید که این داده‌ها به صورت متون غیرقابل فهم نباشند (مثلاً ترتیب کلیدهای کیبورد مثل asd 123123 نباشه!) و ترجیحاً با معنی باشند. این‌طوری مشتری اطمینان پیدا می‌کنه که نرم‌افزار براش قابل استفاده هست.
  • برای اینکه موقع تحویل سرخ و سفید نشید، قبل از تحویل، حتماً کارتون رو خوب تست کنید! این مساله بدیهی به نظر می‌رسه ولی خب خیلی وقت‌ها ازش غفلت می‌شه. این مورد به خصوص اگر کار شما یک کار دیزاین در وب هست، خیلی خیلی مهم می‌شه که مثلاً سازگاری خروجی کارتون رو در مرورگرهای مختلف چک کنید.
  • بعد از نصب و تنظیم اولیه نرم‌افزار در محیط مشتری، یک صورتجلسه تحویل موقت یا تحویل اولیه امضاء کنید. به مشتری اطمینان بدید که این صورتجلسه به معنی تحویل نهایی کار نیست و فقط به این خاطر هست که مشخص بشه کار انجام و نصب شده.
  • در صورتجلسه تحویل موقت، یک مهلت مشخص به مشتری بدید تا نرم‌افزار شما رو بررسی و تایید کنه.
  • درخواست‌هایی که بعد از تحویل موقت، از طرف مشتری برای شما ارسال می‌شه رو به سه دسته تقسیم کنید: درخواست‌های (نیازمندی‌ها) جدید، باگ، سوالات. باگ‌ها رو برطرف کنید و به سوالات مشتری پاسخ بدید، اما نیازمندی‌ها و قابلیت‌های جدید درخواستی توسط مشتری رو به ارائه نسخه بعدی از نرم‌افزار (که بر حسب نوع قرارداد شما با مشتری می‌تونید به خاطرش از مشتری پول هم دریافت کنید) منوط کنید.
  • درخواست‌های بعد از تحویل موقت رو فقط تا زمان مشخصی قبول کنید. درخواست‌هایی که بعد از اون زمان ارسال می‌شوند رو برای اجرای در قالب گارانتی یا پشتیبانی (که می‌تونه قراردادهای جداگانه‌ای هم داشته باشه) برنامه‌ریزی کنید. البته باگ‌های critical از این قاعده مستثنا هستند.
  • برای رفع درخواست‌های مطرح شده بعد از تحویل موقت یک زمان‌بندی به مشتری ارائه کنید. این به معنی تحویل دو مرحله‌ای کل کار هست. با رفع موارد مطرح شده در تحویل موقت، شما عملاً وارد فاز تحویل دائم می‌شوید. مجدداً تاکید می‌کنم که درخواست‌های مشتری بعد از تحویل موقت رو فقط تا تاریخ خاصی (که در صورتجلسه تحویل موقت مشخص می‌شه) قبول کنید.
  • بعد از تحویل دادن نرم‌افزار به مشتری، صورتجلسه تحویل ایجاد و امضا کنید و حتماً‌ مشخص کنید که چه کسی مسئول backup‌گیری از نرم‌افزار و داده‌هاش هست: شما یا مشتری؟
  • به مشتری اطمینان بدید که تحویل دائم نرم‌افزار به این معنی نیست که به امان خدا رهاش می‌کنید! بلکه می‌تونه در قالب قرارداد خدمات پشتیبانی، اگر مایل باشه مجدداً از خدمات شما استفاده کنه.

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

درس‌هایی از استیو جابز و اپل برای کسب و کار نرم‌افزار قسمت ششم: چه کار نکنیم؟

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

تصمیم‌گیری درباره کارهایی که نباید بکنیم!

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

"... یکی از توانایی‌های بی‌بدیل جابز، قدرت تمرکزش بود. خودش می‌گفت: «تصمیم‌گیری راجع به اینکه چه کاری نکنی، به اندازه تصمیم‌گیری راجع به کارهایی که باید بکنی مهم است. این در مورد شرکت‌ها صدق می‌کند، در مورد محصولات هم همین‌طور.»"

استراتژی جابز هم برای بازنگری در روند محصولاتی که فیل شیلر درباره آن گفته بود "دیوانگی بود، هزاران تن محصول افتضاح توسط گروه‌های کاری سر در گم تولید می‌شدند" هم به نوبه خود جالب است:

"... جابز بالاخره بعد از چند هفته رضایت داد. «بس است!» این فریادی بود که در یکی از جلسات راهبردی تولید زد و گفت: «این دیوانگی است.» یک ماژیک برداشت و جلوی تخته سفید ایستاد. با یک خط افقی و یک خط عمودی، نموداری چهاربخشی درست کرد. سپس گفت: «این چیزی است که احتیاج داریم» بالای دو ستون نوشت 'مصرفی' و 'حرفه‌ای'. در کنار دو ردیف نوشت 'رومیزی' و 'قابل حمل' سپس گفت که کار اصلی این است: تولید چهار محصول عالی، یکی برای هر بخش نمودار. شیلر می‌گفت: «کل اتاق در سکوت محض بود.»"

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


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

محصولاتی که نباید تولید کنیم

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

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

نتیجه: به جای چهار محصول عالی (رجوع کنید به استراتژی جابز که در بالا به عنوان مثال توضیح داده شد)، چهل محصول متوسط یا ضعیف تولید می‌کنیم و مجبور می‌شویم برای جبران ضعف محصولات که منجر به عدم رضایت مشتریان می‌شود، زمان و نیروی زیادی بر روی بازاریابی و یافتن مشتریان جدید صرف کنیم. چرا؟ چون مشتریان وفادار نساخته‌ایم.

چطور تصمیم بگیریم که چه کارهایی را انجام ندهیم؟

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

شما از چه روشی برای مشخص شدن کارهایی که نباید انجام دهید استفاده می‌کنید؟

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

تست جوئل قسمت هشتم: محیط آرام برای کار کردن

قبل از شروع مطالعه این نوشته، لازم است بدانید این مطلب بخشی از سری "تست جوئل، 12 گام برای کد برتر" است. دیگر نوشته‌های این سری را از این آدرس می‌توانید مطالعه کنید.

تست جوئل قسمت هشتم: آیا برنامه‌نویسان شما محیط آرامی برای کار کردن دارند؟

پیش‌تر در نوشته‌ای که درباره اهمیت احترام به وقت دیگران نوشته بودم به موضوع وقفه‌های کاری اشاره کردم.

واقعیت اینه که یک برنامه‌نویس هر روز می‌تونه درگیر تعداد زیادی وقفه (interrupt) باشه: از پاسخ به ایمیل‌های شخصی و کاری گرفته تا راهنمایی به همکاران یا صحبت با تلفن و ...

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

جوئل در این مورد به درستی اشاره می‌کنه که متمرکز شدن روی یک کار ممکنه حتی تا 15 دقیقه طول بکشه اما از دست دادن تمرکز کار بسیار ساده‌ای هستش.

محیط آرام کار چه مزیتی برای تیم دارد؟

مثالی که جوئل در این مورد می‌زنه خیلی جالب و گویاست:

"فرض کنید (که شواهد هم این فرض را تأیید می‌کنند) که اگر برای یک دقیقه هم یک برنامه‌نویس را متوقف کنید، پانزده دقیقه از بهره‌وریش کم می‌کنید. برای مثال، Jeff‌ و Mutt (که هر دو برنامه‌نویس هستند) را در دو پارتیشن کنار هم قرار می‌دهیم (در یک فضای کاملاً Dilbert ای). مات، نام تابع کپی رشته در یونیکد را به خاطر نمی‌آورد. می‌تواند جواب آن را جستجو کند - که ۳۰ ثانیه طول می‌کشد، و یا این که از جف بپرسد - که ۱۵ ثانیه طول خواهد کشید. خوب، چون جف در کنارش نشسته است ترجیح می‌دهد که از او بپرسد. حواس جف پرت می‌شود و ۱۵ دقیقه را از دست می‌دهد (برای این که مات ۱۵ ثانیه صرفه‌جویی کرده باشد.)

حالا اجازه دهید که جف و مات را در دو اتاق (با در و دیوار)‌ جدا بگذاریم. اکنون وقتی که مات اسم تابع را به خاطر نمی‌آورد، می‌تواند جواب آن را جستجو کند (که همان ۳۰ ثانیه طول می‌کشد)‌ و یا این که از جف بپرسد که ۴۵ ثانیه طول می‌کشد و شامل از جای خود بلند شدن هم می‌شود (که با توجه به وضعیت جسمی معمول برنامه‌نویسان و مسایل ديگر ‌، کار ساده‌ای نیست!). بنابر این ترجیح می‌دهد که جوابش را جستجو کند. ۳۰ ثانیه وقتش تلف می‌شود اما ۱۵ دقیقه به نفع جف است!"

خب با همین مثال مشخص می‌شه که چطور با یک کار ساده مثل جدا کردن برنامه‌نویس‌ها می‌تونیم به بهره‌وری بیشتر خودشون و در نتیجه کل تیم کمک کنیم. اما موضوع در ایران کمی متفاوت هست.

چه کار کنیم که یک محیط کار آرام داشته باشیم؟

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

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

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


اگر کمک می‌کنه می‌تونید فرض کنید که محیط کار شما مثل یک فیلم صامت می‌مونه
و تنها کاری که شما باید بکنید اینه که توی این فیلم صحبت نکنید!

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

بعدش چه کار می‌شه کرد؟ با الکترونیکی کردن پروسه‌ها (از جمله پروسه ارائه خدمات پشتیبانی یا پاسخ به سوالات مشتریان) تعداد و مدت تماس‌های تلفنی رو کم کنید. مثلاً بخش بازرگانی شرکت می‌تونه بیاد و کاتالوگ‌های الکترونیکی از محصولات درست کنه، یا برای ارائه خدمات پشتیبانی به مشتریانتون می‌تونید از یک سیستم تیکت استفاده کنید. یا مثلاً اطلاعات مشتریان رو در یک نرم‌افزار مدیریت ارتباط با مشتریان (CRM) وارد کنید تا لازم نباشه هر دفعه اون‌ها رو از یک نفر (مثلاً منشی شرکت) بپرسید. این اطلاعات می‌تونه شامل اطلاعات تماس یا حتی اطلاعات لازم برای ریموت زدن به سرورهای مشتری باشه

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

و دیگه؟ تذکر.
درسته، تذکر بدید. توی یک کتابخونه اگر بلند صحبت کنید دیگران با گفتن هیس به شما تذکر می‌دن که اینجا کتابخونه هست. شما هم به دوستان و همکارانتون که آرامش محیط کار رو خواسته یا ناخواسته بهم می‌زنند تذکر بدید.

شما چه راهکارهایی برای افزایش آرامش محیط کار می‌شناسید؟

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

ساختار تیم‌های مدرن نرم‌افزاری قسمت سوم: ساعات کار دلخواه!

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

ساعات کار دلخواه در برابر ساعت کار مشخص

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

یکی از درخشان‌ترین و نوآورترین تیم‌های نرم‌افزاری تیم شرکت github‌ هست. در چند نوشته آینده این سری نوشته‌ها مثال‌هایی از این شرکت و فرهنگ کار در اون رو برای شما خواهم گفت.

خب برسیم به اصل مطلب یعنی ساعات کار دلخواه. در روش موجود و البته پذیرفته شده، ساعات کاری یک تعریف مشخص داره: شما جزئی از فرهنگ 9 تا 5 هستید. یعنی 8 ساعت کار که در اون تایمی برای استراحت و ناهار هم در نظر گرفته شده. 

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

خب همین‌جا نگه دارید، همین‌جا اعضای تیم مدرن نرم‌افزاری ما پیاده می‌شوند. چرا؟ قبلاً اشاره کردم که رابطه بین کار و پول از حالت پول به ازای ساعت زدن (حضور در ساعاتی مشخص) به حالت pay per task (پرداخت به ازای انجام کار مشخص) تبدیل شده.

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

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

 
در مجموعه ویدئوها و نوشته‌هایی که از فرهنگ کار در گیت‌هاب منتشر شده نکات جالبی می‌توان پیدا کرد 

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

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

خب تا اینجا همه چیز به نظر گل و بلبل اومد. اما مشکلات این روش چی هست؟ چند تا سوالی که احتمالاً ذهن شما رو هم قلقلک می‌ده اینا هستند:

  • وقتی ساعات کار دلخواه باشند چطوری می‌فهمیم که یک پروژه کی تمام می‌شه؟
  • چطور بفهمیم که یک نفر کلک نمی‌زنه؟ و مثلاً الکی نمی‌ره خوش‌گذرونی؟ توضیح اینکه github سیاست مرخصی نامحدود هم داره‌، البته سیاست کار بدون رئیس هم داره و کلی چیز دیگه که باید درباره‌شون صحبت کنیم ;)
  • وقتی ساعات کار افراد دلخواه و مختلف هست چطوری جلسات کاری رو هماهنگ کنیم؟
  • چطوری محاسبه کنیم که یک نفر چقدر کار انجام داده و چقدر از کارش مونده؟

درباره این سوالات و سوالات مشابه دیگر درباره این مدل کاری در نوشته دیگری صحبت می‌کنم.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

رزومه ارزش محور به جای رزومه کار محور برای توسعه دهندگان نرم‌افزار

یکی از کارهایی که ما به عنوان Software Developer توی زندگی حرفه‌ای باهاش روبرو هستیم نوشتن رزومه هستش. نوشتن رزومه کار مشکلی نیست و حتی اگر ندونید که چطور میشه رزومه نوشت، ده‌ها مطلب توی اینترنت می‌تونید پیدا کنید که به شما می‌گن که چه چیزهایی رو با چه فرمتی باید توی رزومه‌تون بنویسید.

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


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

قبلاً وقتی درباره مزیت رقابتی در نرم‌افزار نوشتم به نقل از کتاب Code Leader گفتم که پیش از آنکه حتی یک خط کد بنویسید باید از خودتان بپرسید که آیا این نرم‌افزار ارزش تجاری برای مشتریان ایجاد می‌کند؟

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

حالا به نظرم همین مساله ارزش محوری رو میشه در رزومه نوشتن هم استفاده کرد، یعنی به جای اینکه صرفاً بنویسیم که فلان کار رو انجام دادیم یا فلان نرم‌افزار رو تولید کردیم، درباره ارزشی که کارمون ایجاد کرده بنویسیم.

مثلاً من یک سرویس خبرخوان الکترونیکی برای شیرپوینت نوشتم (که البته توی رزومه‌ام هم نیست!) وقتی بخوام درباره‌اش توی رزومه صحبت کنم می‌تونم به جای اینکه بنویسم: "تولید سرویس خبرخوان الکترونیکی برای شیرپوینت 2007 و 2010" می‌تونم از این بگم که چطور این سرویس باعث شده که سازمان‌های مشتری دیگه نیازی به اشتراک کاغذی روزنامه نداشته باشند یا برای جمع آوری خبرهای مرتبط به سازمان از منابع مختلف به روابط عمومی‌ها کمک کرده و باعث صرفه‌جویی در وقتشون شده.

یک دستی به سر و گوش رزومه‌تون بکشید و درباره ارزش‌هایی که با کارتون ایجاد کردید بیشتر و بهتر (و البته مختصر) بنویسید.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

20 نکته برای اینکه برنامه‌نویس بهتری بشوید

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

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

1- همیشه باید فقط یک راه و نقطه خروج در کد هر متد وجود داشته باشد (از if else فقط هنگامی که لازم است استفاده کنید)

2- وقتی از if else استفاده می‌کنید مطمئن شوید که کد کوتاهتر را در بخش if قرار می‌دهید و کد طولانی‌تر را در بخش else

if (cond) {
   //only a few lines of code
}
else {
   //here you should write the "bigger" case
   //many many lines
}

3- اگر می‌توانید از throw کردن execption ها اجتناب کنید، این کار را بکنید. throw کردن execption (به صورت عمدی) باعث کند شدن کد شما می‌شود. اگر حس این رو دارید که یک چیزی رو throw‌ کنید و بعد catch کنید (کنایه به throw کردن و catch کردن exception ها) با سگ‌تون توپ بازی کنید! اگر سگ ندارید یکی بگیرید، فوق‌العاده هستند!

4- کارهای زیادی رو در یک خط کد انجام ندهید، وقتی که به خطا برخورد کنید debug کردن مشکل‌تر می‌شه. به عنوان مثال کدی مشابه کد زیر ننویسید:

String result = hasInformation()? getState() : (hasMoreInformation() ? getOtherState() : getState());

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

5- به قطعه کدهایی که مشابه هم به نظر می‌رسند نگاه کنید و اگر چیزی پیدا کردید: refactor کنید!

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

7- هر جا که می‌توانید از hashmap (یا همان hash table) به جای list و صف استفاده کنید این کار را بکنید.

8- اگر می‌توانید به جای I/O (معمولاً کار با دیتابیس) از مکانیزم‌های کش استفاده کنید، از کش استفاده کنید.

9- اگر یک regex ساده و زیبا می‌تونه کار رو انجام بده ازش استفاده کنید.

10- از regex برای parse کردن (مثلاً HTML/XML/json) استفاده نکنید، در هر زبانی کتابخانه‌های خاصی برای این کار وجود دارد. 

11- log‌ کنید. حداقل باید دو سطح لاگ برای debug و error داشته باشید.

توضیح مترجم: درباره logging به نظرم ایده‌های بهتری وجود دارد، درباره‌شان در نوشته دیگری خواهم نوشت.

12- از stackoverflow استفاده کنید، نه فقط برای سوال پرسیدن. روزی چند دقیقه به پاسخ به سوالات دیگران اختصاص بدید، از اینکه اینطوری چقدر چیزی یاد می‌گیرید شگفت زده خواهید شد!

13- قانون انگشت: اگر متد شما بیشتر از 50 خط است، بشکنیدش. اگر کلاس شما بیشتر از 500 خط است، بشکنیدش. اگر فکر می‌کنید که کدتون رو نمی‌تونید به قطعات کوچکتر بشکنید، یک کاری رو اشتباه انجام دادید. این توصیه بسته به زبان برنامه‌نویسی فرق می‌کنه. مثلاً در جاوا یا سی شارپ 50 خط کد قابل قبول هست ولی مثلاً برای زبان‌هایی مثل Ruby یا Python خیلی زیاد محسوب می‌شه.

14- کدی که فقط برای خودتان قابل توضیح هست خوبه ولی مشکل هم ایجاد می‌کنه. اگر مطمئن نیستید که کدتون چقدر "واضح" هست کامنت بنویسید.

15- وقتی برای کد کامنت می‌نویسید همیشه فرض کنید که خواننده کامنت اصلاً خبر نداره که شما سعی دارید چه کار کنید. با حوصله توضیح بدید. کسی به خاطر اینکه کامنت‌های شما طولانی هست به شما ایراد نخواهد گرفت.

16- می‌خواهید پیشرفت کنید و مهارت‌هاتون رو بهبود بدید؟ کتاب و وبلاگ و مقاله بخونید، در گروه‌های مناسب و مرتبط در linkedin‌ عضو بشید. خودتون رو با آخرین فناوری‌ها به روز کنید. به کنفرانس‌ها برید. 

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

17- تمرین کنید که باعث کامل و بی‌نقص شدن می‌شه: به hackathon‌ها بپیوندید. code-challenge ها رو حل کنید. 

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

18- با IDE های مختلفی کار کنید تا اونی که براتون راحت تر هست رو پیدا کنید.

توضیح مترجم: این مورد درباره برنامه‌نویسان مایکروسافتی صدق نمی‌کنه، در واقع بهتر از Visual Studio هنوز خلق نشده!

با تشکر از نکته‌سنجی و پیشنهاد درست dotErfan@ عبارت بالا رو این‌طور اصلاح می‌کنم: برای برنامه‌نویسان مایکروسافتی در حوزه IDE انتخاب‌های زیادی وجود ندارد، حتی اگر سوار قایق IDE هایی نظیر SharpDevelop یا MonoDevelop بشوید احتمالاً بعد از مدت کوتاهی شما را بر عرشه کشتی Visual Studio خواهم دید!

19- هر وقتی باگی پیدا می‌کنید قبل از رفع کردنش، یک unit test بنویسید که بتونه این باگ رو بگیره و مطمئن بشید که کار می‌کنه.

20- تنبل نشید RFTM

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی