یمین یزدان پناه | Yamin Yazdanpanah
یمین یزدان پناه | Yamin Yazdanpanah
خواندن ۸ دقیقه·۳ سال پیش

کالبدشکافی یک برنامه نویس

Photo by Dan-Cristian Paduret on unsplash
Photo by Dan-Cristian Paduret on unsplash

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

پایان قرن چهاردهم و سال ۱۴۰۰، زمانی بود که تصمیم گرفتم از شرکت کسرا بیام بیرون و محل‌کارم رو تغییر بدم. این اولین بار بود که بعد از مرداد ۱۳۹۵ که وارد کسرا شدم، نیاز به این تغییر رو حس‌ می کردم. این نوشته صرفا بخشی از برداشت من از اتفاقات و تجربه هایی بوده که در طی این سال ها با کار کردن در کنار آدم های مختلف بدست آوردم و نمیخوام وارد تمام جزئیات مسیری که توی کسرا طی کردم بشم.

شروع کنیم. توی سردخونه، جسد آماده است، بریم برای شکافتن مسیر پر پیچ و خم کاری…

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

Photo by Mahmud Ahsan  on unsplash
Photo by Mahmud Ahsan on unsplash

درس اول: زودتر وارد بازار کار بشو.

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



اولین پروژه ما در لوپرز، تولید نرم افزار موبایل سیستم حضور و غیاب شرکت کسرا بود، پس استارت برنامه نویسی من با کار با فریم ورک ionic زده شد. Ionic فریمورکی هست که می تونید با Html و Css و Angular js کد بزنین و خروجی نرم افزار رو روی موبایل های اندروید و iOS بگیرید و به اصطلاح به صورت Hybrid نرم افزار موبایل تولید کنین. میشه گفت اون زمان برنامه نویسی hybrid تازه مطرح شده بود و هنوز ionic و بقیه پلتفرم ها بلوغ لازم و community و پلاگین های مورد نیاز برای تولید برنامه موبایل رو نداشتند و ما سختی های زیادی برای تولید و نگهداری محصولاتمون کشیدیم، در کنار این مشکلات، نیاز به دسترسی بیشتر به امکانات سیستم عامل مثل پوش نوتیفیکیشن و کار با نقشه ما رو به سمت برنامه نویسی native کشوند و از سال 96 رفتیم سمت برنامه نویسی با java برای اندروید و swift برای iOS و برنامه های آینده خودمون رو با این زبان ها توسعه دادیم. جایی که من رسما وارد دنیای برنامه نویسی اندروید شدم.

Photo by Markus Spiske  on unsplash
Photo by Markus Spiske on unsplash

درس دوم: مهم ترین ویژگی تو باید آمادگی برای تغییر باشه.

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



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

Photo by Olga Guryanova  on unsplash
Photo by Olga Guryanova on unsplash

درس سوم: هیچ وقت بدون ساختار کار نکن.

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



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

Photo by Slidebean on unsplash
Photo by Slidebean on unsplash

درس چهارم: ورودی تیم برنامه نویسی دقیقا به اندازه خروجی تیم مهمه.

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



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

Photo by Tarryn Myburgh  on unsplash
Photo by Tarryn Myburgh on unsplash

درس پنجم: انگیزه است که تو رو زنده نگه میداره.

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

زمانی که من تصمیم گرفتم از ابتدای سال 1401، به شرکت باما برم.

برنامه نویسیتجربهdeveloperprogrammingتیم سازی
نوشته های یک برنامه نویس ...
شاید از این پست‌ها خوشتان بیاید