همونطوری که می دونید در این سری پست های وبلاگ، در مورد یادگیری هایی که در ورود به یک تیم نرم افزاری داشتم صحبت می کنم.
به عنوان اولین پست این سری، میخوام در مورد دریافت و دانستن چیستی یک تیم صحبت کنم.
قبل از اینکه جلوتر بریم، باید بگم که مفهوم تیم که من در این مقاله بهش اشاره می کنم به معنی یک واحد خاص مثل تک یا پروداکت نیست.
شاید اولین درسمون این باشه که چیزی به اسم تک، پروداکت، بیزینس و … در مسیر موفقیت وجود نداره.
اجازه بدید که این مساله رو باز کنم.
سهیل مربی و استاد من،یک بار حرف بسیار زیبایی به من زد :
تا حالا دیدی دروازبان تیم ملی برنده بشه ؟
سهیل صمدزاده
واقعا تا حالا شده شما همچین چیزی بشنوید ؟ معلومه که نه !
ما برای موفقیت به کل تیم نیاز داریم نه فقط یک بخش خاص مثل تک یا پروداکت یا بیزینس و … .
اون باهوش ها الان می پرسن که پس چرا تیم بندی می کنیم ؟
سوال خوبیه ! جوابش هم قشنگه.
ماهیت تیم سازی بر میگرده به حوزه عملکرد و مسئولیت.
این یعنی اینکه ما تیم سازی می کنیم و روی تیم هامون اسم می زاریم تا بتونیم بفهمیم، چه کسی، تا کجا باید پیش بره.
یا واضح تر با مثال عینی میشه اینکه :
اگر فرض کنیم شما یک مهندس نرم افزار با تخصص فرانت هستید در گروه Frontend قرار می گیرید.
این معنیش این نیست که شما در موفقیت تیم نقشی ندارید یا مسئولیتی ندارید، بلکه معنیش اینه که شما برای موفقیت وظایف مشخصی دارید که در زمینه ای هست که توش تخصص دارید.
حالا برگردیم سر موضوع این پست، چیستی تیم !
چرا چیستی تیم مهم شد برای من ؟
من در اوایل بازه کاریم خیلی تمرکز روی مباحث فنی داشتم، کتاب های فنی(و در اون زمان MSDN روی ۷ تا CD) مرجع یادگیری من بود.
ورودی یک تسک بود و خروجی یک تیکه کد.
بعد از سال ها کسب تجربه و ترند شدن مفاهیم اجایل درک بیشتر من از مهندسی نرم افزار و تفکیک قائل شدن بین برنامه نویسی و مهندسی نرم افزار، به اینجا رسیدم که باید غیر از مباحث فنی درک کنم که چی مهمه و چی کار می کنه.
اینجا بود که من شروع به مطالعه مباحث محصولی و تحصیل در رشته مدیریت در دانشگاه شدم.
کسب این دانش های جدید منو به این سمت برد که نگاه جدیدی برام به وجود اومد.این نگاه به من کمک کرد که به نرم افزار به چشم یک محصول نگاه نکنم.
نرم افزار یکی از بخش های یک کسب و کار بزرگتره.
بیایم صادق باشیم، ما به عنوان مهندسین نرم افزار مرکز دنیا نیستم. ما هم بخشی از یک اکو سیستم هستیم. نباید این طوری فکر کرد که اونی که ما فکر می کنیم درسته، در حقیقت ما باید چگونگی رو از متخصصش بگیریم.
اینجا همونجایی بود که من فهمیدم که باید محصول رو در راستای بیزینس و کسب سود توسعه داد نه مباحث صرف مهندسی نرم افزار.
اگر نگاهی به مباحث مهندسی نرم افزار و ترند هاش در دنیا بندازیم می تونیم اینو ببینیم که ما همیشه به خاطر یه ضعف داریم مباحث جدیدی خلق می کنیم.
پروژه هامون شکست می خورن چون به درد کاربر نمی خورن، میریم اجایل رو توسعه میدیم.
پروژه هامون دیر میرسن میریم مدیریت پروژه رو میاریم و سعی می کنیم بیاریمش توی مهندسی نرم افزر و ….
کلی درس های تخصصی هم توی مهندسی نرم افزار هست که در همین راستاس و سعی می کنه به ما بگه آقا کد مهمه، معماری مهم و هزار تا چیز دیگه، ولی یه چیز دیکه هم مهمه و اونم بیزینس و در نهایت مشتریه !
در عمق مهندسی نرم افزار ما این حقیقت رو داریم که همه چیز بیزینس هست !
حالا که فهمیدیم بیزینس مهمه باید بتونیم درکش کنیم،چیستی اینجا مهم میشه.
وقتی وارد یک تیم میشیم باید بدونیم که چیستی این بیزینس برای چیه ؟ منظورم این نیست که بریم ببینیم کدهاش چطوری کار می کنن(که اونم خیلی مهمه البته). منظورم دقیقا اینه که بدونیم اون بیزینس چطوری کار می کنه، چطوری پول در میاره و شاید مهمتر برای کشور ما اینکه هزینه هاش چی هستند !
حالا که این ها رو درک کردیم بیایم در مورد مشکلی که به وجود اومده بود که من تصمیم گرفتم در مورد چیستی بنویسم صحبت کنیم.
1. شرایط مشکل
با ورود من به سازمان جدید، عمده دانسته های من در مورد تکنولوژی در سازمان های قبلی و بیزینس اونها بود.
من در حوزه های مختلفی از جمله سلامت،بهداشت، آموش آنلاین، نرم افزار های اداری و مالی، گردشگری و … تجربه داشتم، ولی بیزینس جدیدی که درگیرش شده بودم تبلیغات بود ! بیزینسی که علاوه بر High Tech بودن بسیار پیچیده هم هست.
تصمیم های اولیه من در بدو ورود به دلیل عدم تسلط بر چیستی این تیم، به سمتی رفت که از نکاتی استفاده کنه که من دیده بودم، نقاط مشترک هر بیزینسی با بقیه بیزینس ها هم مباحث فنی هست !
2. مشکل به وجود آمده چی بود ؟
اولین مشکل به وجود آمده این بود که گرفتن تصمیم در زمانی که چرایی تصمیم مشخص نیست باعث میشه شما تصمیمات اشتباه بگیرید ! بله به همین راحتی ممکنه تصمیم بگیرید که مثلا ساختار یک کد رو از یک اسپاگتی کد شروع به ریفکتور کنید، در صورتی که اون تکه کد سالهاست که کارایی نداره و کسی ازش استفاده نمی کنه ! منم هم در بدو ورود سعی در تغییر در مدل هایی داشتم که تیم اونها رو در 3 ماه گذشته برای یکی از محصولات دیزاین کرده بود. من از Eventual Consistency می گفتم که با اینکه درست بود ولی راه حل بهتری براش وجود نداشت و من سعی می کردم پرکتیس های معماری و اصول معماری رو رعایت کنم. حرف اشتباه نبود ولی وقتش نبود !
3. چه راه هایی داشتم ؟
بیاید صادق باشیم، من خیلی سریع فهمیدم که نمی فهمم ولی این کمکی بهم نمی کرد ! من باید کاری می کردم که تیم به من اعتماد کنه و بتونم کارم رو پیش ببرم ! پس لزوما تصمیمات فنی گرفتن بد نبود.
بعد از درک موقعیت به این راه حل ها رسیدم :
- روی مباحث فنی برای موفقیت های سریع تمرکز کنم
- توسعه در تیم رو تا حد امکان کند کنم تا به بیزینس و چیستی تیم مسلط تر بشم
- کار های توسعه رو به افراد با تجربه تیم بسپرم و روی بیزینس و چیستی خودم تمرکز کنم
طبق تجربه و پیشنهاد هایی که گرفتم تصمیم گرفتم مورد اول و سوم رو همزمان استفاده کنم. یعنی پروژه های کوچک و دست یابی به Low Hanging Fruits و همزمان سپردن کار های مهم به افرادی که در تیم قبلا مسئولیت داشتند و می شد بازم بهشون اعتماد کرد.
4. چه شکست هایی داشتم ؟
یک مشکل بزرگ وجود داشت، وقتی مسئول یک تیم هستی تصمیمات گردن توست و اگر نتونی تصمیم بگیری کار خراب میشه.
اشتباه اول اینجا بود، زود تصمیم گرفتم.
برای نشون دادن قدرت و توان تصمیم گیری هام، توی روز های اول چندین تصمیم فنی، بیزینسی و کارکردی گرفتم.
زود تصمیم گرفتن خوب نیست، نشون میده که شما در تصمیم گیری خام هستید. تصمیماتی که سریع گرفته بشن احتمالا به همه جوانب نپرداختند و نشونه خوبی برای یک مدیر نیست !
تصمیم گرفتن تجربه لذت بخشیه ولی اگر زیاده روی کنی توش می کشتت پایین. یه حس قدرت خاصی داره که هم جذابه هم ترسناک.
بهترین مدیر ها تصمیم های به اندازه میگیرند
نه کم و نه زیاد، نه زود و نه دیر
تصمیمات اولیه من با ترس گرفته شد و باعث هدر رفت زمان در تیم شد.
این هدررفت در خیلی از سازمان ها به حساب زمان آنبوردینگ گذاشته میشه که به نظرم مدیر پخته کمترین میزانش رو باید داشته باشه.
5. چه راه حلی در نهایت جواب داد ؟
من بعد از تجربه دو هفته ای، طبق روتین خودم فیدبک لوپ رو کوتاه کردم. یعنی چی ؟ یعنی برگشتم دیدم تصمیمات داره چه تاثیراتی می گذاره، دیدم که عدم تسلط من به چرایی تیم داره هدر رفت ایجاد می کنه، برای همین چند تصمیم با همراهی پروداکت لید تیم گرفتیم :
اول :سعی کردم با اجرای یک نسخه ساده از اسکرام، به سمت این بریم که ورود های با کیفیت تری به تیم بدیم.
دوم : رود مپ تیم و تاثیرشون بر درامد تیم رو مجددا مطالعه کردم. تونستم به این درک برسم که روی کجا تمرکز کنم می تونم به آورده بالاتری برای تیم برسم.
سوم : تصمیم گرفتم از یک متخصص تبلیغات بیشتر در مورد دامین این بیزینس بفهمم. مطالعم رو روی مفاهیم پایه ای از روی سورس های معبتر شروع شد و در یک بازه 2 روزه فقط یک کتاب آنلاین رو کامل خوندنم.
چهارم : با مدیران ارشد دیگه تیم جلسه گذاشتم و ازشون پرسیدم چطوری کار می کنن، نه با نرم افزاری که تک و پروداکت می سازن، خود بیزینس این صنعت رو از متخصص صنعت که برای این شرکت شخصی سازی شده بود یاد گرفتم.
پنجم : دانسته های خودم رو با تیم و دیگر افراد سازمان چک کردم، مطمعن شدم که ترمینولوژی هامون هم یکسانه و هم هم معنی ! این طوری می تونستم توی ubiquitous language یا زبان جهان شمول بیزینس با هاشون هم صحبت بشم.
ششم : تصمیماتم رو کند کردم و مشورت گرفتم ! بله تصمیم گیری رو تا آخرین زمان ممکن به تعویق انداختم تا اول از کیفیت درکم از کار، چیستی تیم و چیستی خود تصمیمم آگاه بشم !