درس آموخته‌های یک پروژه
درس آموخته‌های یک پروژه
این روزها همه جا پر شده از اسم استارت‌آپ و کارهای استارت‌آپی. این‌جا قصد دارم از شش سال تجربه‌ام درزورق بنویسم(علی دیشیدی). حدس می‌زنم به کار خوانندگان درگیر استارت‌آپ خواهد آمد. یا حداقل باعث می‌شه ذهن خودم خلوت بشه. این نوشته ترکیبی از تجربه فنی و سازمانی ساخت محصوله.
✅ نکات بدیهی که دیر فهمیدیم:
💬 تا زمانی که در روند توسعه زیرساخت مشکل جدی پیش نیاد و یا سرویس‌دهی به مشتری با تعداد بالا مختل نشه، هیچ اهمیتی نداره معماری یا ابزارهای فنی استفاده شده چیه. از روز اول نباید برای تعداد کاربر بالا کد زد یا حتی تیم تشکیل داد.
💬 همه‌ی افراد در تیم برابرند. اگر کسی خیلی بیشتر از بقیه می‌دونه یا حقوق خیلی بیشتری میگیره، قطعا بوی دردسر میاد.
💬 پیاده کردن محیط دوستانه همزمان با کار حرفه‌ای خیلی سخت‌تر از چیزیه که به نظر میاد. ولی ارزشمندترین کاری است که می‌شه در یک استارت‌آپ کرد.
💬 تمام اصول مانیفست اجایل ( و حتی اصول اخلاقی اسکرام مثل شفافیت) تزئینی نیستند. رعایت این‌ها حتی از پرداخت حقوق سر وقت هم مهم‌تره. و این اصول فقط برای برنامه‌نویس‌ها نیست. برای سازمانه.
💬 مهم نیست چه چارچوبی برای توسعه نرم‌افزار و تیم داریم. هر چیزی که بهتر می‌شه اجرا کرد باید انتخاب کرد و بعد از کسب تجربه، اگر نیاز بود، تغییرش داد.
💬 اگر خروجی هر تیمی با هر تخصصی تا حداکثر دو هفته قابل دیدن نیست به احتمال خیلی زیاد یعنی دردسر در انتظاره. یا کار با زمان و هزینه خیلی بیشتر جمع می‌شه. یا اصلا هیچ وقت تمام نمیشه
💬 مواردی که ازشان به عنوان بهترین پرکتیس‌های تیم‌های نرم افزاری نام برده می‌شه، مخصوص تیم‌های خارجی و یا تیم‌های بیکار نیست. یک وظیفه اصلی تیم‌ها به خصوص تیم‌های پروداکت، ایجاد و توسعه دانش و سرویس برای استفاده داخلی خود تیم است.
💬 دولوپر حرفه‌ای، به معنایی که در ایران جا افتاده، یعنی کسی با توانایی فنی بالا ولی معمولا بی‌اعصاب یا بی اعتماد به بقیه یا با اعتماد به نفس خیلی بالا، بدترین کاندید برای ورود به تیمه. محصول را برای پرزنت بعدی آماده خواهد کرد اما مثل بمب ساعتی بالاخره خواهد ترکید.
https://goo.gl/vZr6Eb
