زمانی تو شرکتی مدیر فنی تیم بودم. پروژه حیاتی شرکت نوشتن فروشگاه یکی از بزرگترین ارگان‌های ارتباطی ایران بود. پروژه رو باید از PHP به Java تغییر میدادیم و کل محصول رو از اول مینوشتیم. فشار پروژه بسیار زیاد بود.
روزی که باید دمو میدادیم، صبح، تو جلسه standup شرکت از سینیور فرانت پرسیدم فلان تسک رو گفته بودی دیروز تموم میشه، تموم کردی؟ گفت نه! تسک در حد اضافه کردن یک کتابخونه ساده و صدا زدن یک فانکشن ساده بود. خیلی تعجب کردم که چرا سینیور تیم این رو تموم نکرده. وقتی علت رو پرسیدم گفت کتابخونه‌اش ۱۴۰ کیلوبایت بود خودم میتونم تو ۳۰ کیلوبایت همونو بنویسم. میتونید تصور کنید حال من رو.
داستان بعدیم واسه زمانی بود که پروژه‌ای داشتیم برای یک سازمان دولتی و به شدت روابط پیچیده شده بود. پروژه بسیار پیچیده بود و هیچ کس نمیدونست دقیقا باید چه اتفاقی بیفته. صفر و تا صد پروژه رو داده بودن به ما چهار تا جوون (که سرباز هم بودیم) و ما هر هفته میریم جلسات ارائه. کار به جایی رسیده بود که دیگه دو طرف میز حرف هم رو نمیفهمیدن. ما براشون یک سیستم کاملا Dynamic با قابلیت تغییر workflow و چیزهایی باورنکردنی (به نظر خودمون) درست کرده بودیم. طرف دولتی ماجرا داشت در مورد اینکه اصلا چطوری ازش استفاده کنه صحبت میکرد. کار به جایی رسید که برگشتن گفتن شما جوونا رنگ سبز تو این استفاده کردید، منظوری داشتید؟ رنگ بعدی بنفش بود اما خب میدونیم که بنفش واسه یک رییس جمهور خاص بود. در نتیجه مدیر استقلالی پیشنهاد رنگ آبی رو داد. (این تیکه ربطی به حرفم نداره اما محض تموم شدن ماجرا).
اکثر ما توسعه دهنده‌ها (هنوز نفهمیدم علتش چیه)، تا یه جایی کمال‌گرا هستیم. بعضیامون زیاد بعضیامون کم. گروهی از ماها حتی فکر میکنن که بیشتر از بقیه میدونن (به لحاظ روانشناسی خیلی هم اذیت میشن. اما اینجا جاش نیست.)
بزرگترین ترس بعضی از ماها اینه که چیزی که خلق کردیم رو نشون بدیم و کامل نباشه. دوست داریم نسخه کامل کارمون رو همه ببینن. ما تو تنهایی خودمون میشینیم و نقشه‌های جاه طلبانه‌ای برای تولید بهترین نرم افزار میکشیم. شروع میکنیم به کار کردن. اما زمان همیشه دشمن ماست.(در مورد این نحوه کار کردن یک پست دیگه باید بنویسم)
اتفاقی هم که در نهایت این پروسه تکراری می‌افته اینه که یک محصول نصفه و نیمه داریم یا اینقدر زمانش طول میکشه که دیگه به قول معروف از دهن می‌افته.
در این فواصل هست که stakeholder ها و افرادی که مخاطب هستن شروع به گرفتن تصمیمات جدید میکنن.
در مقابل تیم‌های فنی هم گاها با لمس کردن این موضوع یا تغییر مسیر میدن و به سمت تولید نرم افزار اشتباه میرن تا فقط تموم کنن یا با همون سرعت و تفکر ادامه میدن تا تمومش کنن. اما همه میدونیم نهایت ماجرا اینه که دیگه اون محصول پذیرشی براش وجود نداره. تیم‌های فنی از تیم‌های بیزینس بیشترین فاصله رو پیدا میکنن و در نهایت یا پروژه شکست میخوره یا بخش خوبی از time to market رو از دست میده. نتیجه پایانی موضوع تغییر استراتژی یک سازمان، مشتری، استارتاپ و... هست که گاها منجر به دور ریختن تمام خروجی (هرچند ناقص و یا حتی در آخرین مراحل) تیمها یا افراد میشه. (البته همیشه هم علت این نیست)
این اتفاق چیزی جز سرخوردگی و از هم پاشیدن نداره. تعریف حس واقعی شکست!
چیزی که من از راه سخت یاد گرفتم این بود که باید align شد. هر دو طرف باید نسبت به progress و پیشرفت کار ادبیات و context یکسانی داشته باشن. از همه مهمتر ارزش‌هایی که تسک/پروژه/کار/خروجی قابلیت ارزشیابی داره (acceptance criteria) مشخص بشه.
همچنین افرادی که مخاطب این تغییرات هستن، مثل stakeholder ها، سفارش دهنده یک پروژه، تیم بیزینس و یا هرچیزی که میخواید اسمش رو بذارید، باید بتونن تغییرات رو لمس کنن. لمس کردن تغییرات توسط این افراد غیر فنی راحت نیست. شما باید بهشون نشون بدید که کارتون در مدت قبلی چطوری روی اونها تاثیر (impact) میذاره. چه چیزی رو بهتر کردید و مسیر آینده کجاست.
بسیاری از برنامهنویسهای کم تجربه رو دیدم که قبل از جلسات Demo خیلی با انرژی هستن برای اینکه خروجی کار خودشون رو نشون بدن اما بعد از این جلسه تقریبا تمام انرژیشون برای کار رو از دست دادن.
حتی برنامهنویسهای خیلی خوب و با تجربه رو دیدم که تو جلسات Demo بسیار برافروخته شدن از اینکه کسی متوجه حجم تغییرات نشده یا کاری که کردن رو درک نکردن.
اما وقتی تو این جلسات حاضر میشدم، به عنوان یه فرد فنی متوجه میشدم که چه اتفاقاتی داره می‌افته اما وقتی از بقیه میپرسیدم که آیا شما هم همین حس رو دارید؟ یا آیا شما متوجه میشید که این تغییرات چه تاثیری روی شما داره؟ جوابی نمیگرفتم.
علت اینجا بود که اغلب اوقات این افراد در مورد یک چیز صحبت نمیکردن یا اگر میکردن ادبیات یکسان نداشتن.
اما از همه مهمتر این بود که تیم/فرد فنی زمان بسیار زیادی رو برای ایجاد یک خروجی صرف کرده بود. به عنوان مثال بعد از چند هفته از شروع پروژه یا زمان خوبی از یک اسپرینت، هنوز چیزی برای بررسی وجود نداشت. این خروجی لزوما یک interface نبود اما اون واحد فنی تصور متفاوتی داشت.
بعد از صرف شدن این زمان اغلب حس طرف غیر فنی این هست که خیلی خب ببینیم بعد از این همه زمان چه چیزی نصیبمون میشه. اما وقتی ارائه شروع میشه اتفاق عجیبی می‌افته. تیم فنی شروع به تغییرات فنی بسیار خفنی که در پروژه انجام داده میکنه و افراد حاضر در جلسه از یک قسمت به بعد عملا context و فضای بحث رو از دست دادن. دیگه نمیدونن آیا چیزهایی که میخواستن رو گرفتن و انجام شده یا اینها پیش مقدمه کار هست؟
تازه اگر خیلی با تجربه باشن سوال میپرسن و از جواب این سوالات به نتیجه میرسن که خروجیشون درست هست یا نه.
من هم جزو همین افراد فنی بودم. اوایل کار همیشه از اینکه در جلسات demo باشم میترسیدم. خروجی کاملی نداشتم. بعد از مدتی یاد گرفتم که اگر تعداد جلسات بیشتر بشه و نوع کار کردن من در اوایل کار خروجی محور باشه. تاثیر بسیار مثبتی روی مخاطبم خواهم داشت. اعتمادشون رو جذب میکنم. از همه مهمتر، مهم نیست اگر کار نکنه. اونها درک میکنن که زمان کافی برای انجام همه چیز نیست. از طرف دیگه اونها تغییرات رو میتونن لمس کنن. میتونن تشخیص بدن که progress داریم یا نه. در عین حال اگر جایی رو اشتباه رفتم قبل از اینکه کل پروژه رو به فنا بدم ازشون تایید بگیرم. اونها رو onboard بکنم و ازشون کمک بخوام. یاد گرفتم که تیمها بیزینس/مشتری/کاربر در طرف من هستن. اونها به عنوان مخاطب نهایی محصول همیشه میخوان بهترین محصول رو تولید کنن و من مشاور فنی اونها هستم. اگر جایی مسیر فنی درست نیست بهشون میگم اما این مسولیت رو تا جایی پیش میبرم که اونها راضی باشن. در غیر اینصورت خروجی بیشتر از یک conflict نیست. به کسی هم کمک نمیکنه.
امروز در نقطه‌ای هستم که میدونم بهترین برنامه نویس نیستم و حتی اصلا برنامه نویس خوبی نیستم. اما میدونم که باید با افراد ارتباط برقرار کرد. اگر این ارتباط وجود نداشته باشه من به تنهایی نمیتونم تصمیمات درست رو بگیرم. بار کل پروژه/تسک/شرکت نباید روی دوش من باشه و مشکلات من مشکلات همه است. باید کمک بگیرم و از اینکه به بقیه بگم که در حل یک مشکل ناتوان بودم یا نتونستم ایده درست رو داشته باشم نترسم.
اگر روزی فرق بین دو تا فایل ۱۴۰ یا ۳۰ کیلوبایتی رو ندونستم به جای اینکه وارد چرخه بی پایان بهبود بخشیدن بشم، اول کاری که ازم خواسته شده رو انجام میدم.
اگر روزی وارد فضایی شدم که حرف افراد رو متوجه نمیشم، اول ادبیات مشترک رو در یک فضای مشترک پیدا کنم.
کلام آخر اینکه کد نوشتن آسونترین کار برای منه اما ارتباط گرفتن و حل مشکلات این چنینی سخت‌ترین چیزی بود که باهاش تو شغلم مواجه شدم. من تونستم قسمت سختش رو رد کنم و الان از چیزی نمیترسم اما میبینم خیلی از برنامهنویسهای دیگه حتی با تجربه رو که این قسمت رو حل نکردن و هنوز که هنوزه در هر ارتباطی اصصلاحا درمانده میشن. راه خروجی رو پیدا نمیکنن و در نهایت کارشون هم کیفیتی که باید داشته باشه رو نداره.
این مطلب از یک توییت شروع شد. اما بهتر دیدم یک پست بنویسم. به نظرم میشه تو پست‌های بعدی به جنبه‌های بهتری ازش رسید. لطفا بهم بگید که کدوم بخش‌ها جذاب‌تره تا بیشتر بنویسم در موردشون.
تو مطالب بعدی به این میپردازم که چطوری میشه بهتر کار کرد که وارد این loop های شکست نشیم. بعد به این میپردازم که چطوری میشه با سوال پرسیدن کار رو راحت‌تر کرد.
