قبل از اینکه Justin.tv به Twitch و Socialcam تبدیل شود، سال ها درک اشتباهی از نحوه ساخت محصول داشتیم. جلسات محصول ما بی‌هدف بودند و تصمیماتمان را یادداشت نمی‌کردیم.
محصولات جدید را با دقت مشخص نمی‌کردیم، بنابراین اعضای تیم اغلب ایده های کمی متفاوتی در مورد چیزی که می‌ساختیم داشتند. همیشه می‌خواستیم محصولات کاملاً آماده بسازیم، به جای MVP ها (حداقل محصول قابل قبول) به ندرت آمار و تحلیلی برای محصولات جدید مشخص می‌کردیم، بنابراین اغلب نمی‌دانستیم عملکرد آن ها پس از عرضه چگونه است.
چرخه های توسعه ما اغلب ماه ها طول می‌کشید. وقتی محصول را عرضه می‌کردیم، از ویژگی جدید خسته شده بودیم، بنابراین آن را تکرار و بهبود نمی‌دادیم.
نقشه راه محصول ما آنقدر طولانی بود که اعضای تیم برای ایده‌پردازی محصولات جدید هیجان نداشتند، چون مشخص نبود که آیا اصلاً ساخته خواهند شد یا نه و از همه بدتر، تصمیمات محصول فقط توسط بنیان‌گذاران و به صورت غیرشفاف گرفته می‌شد. همه چیز آشفته بود.
در این پست، قصد دارم اصول چرخه توسعه محصول را که برای حل تمام مشکلات بالا یاد گرفتم، پوشش دهم. این اصول به شما کمک می‌کند تا به سرعت محصول خود را تکرار، اندازه‌گیری، آزمایش و بهبود دهید، در حالی که تیم خود را کاملاً درگیر می‌کنید.
این کار با عرضه MVP متفاوت است. من فرض می‌کنم که شما یک MVP را عرضه کرده‌اید و در حال فهمیدن این هستید که قدم بعدی چیست، که بیشتر استارتاپ ها اکثر زمان خود را صرف همین مرحله می‌کنند.
طول چرخه توسعه خود را مشخص کنید
طول چرخه توسعه شما باید توسط محصولتان تعیین شود. در Socialcam، ما برای iOS محصول می‌ساختیم، بنابراین یک چرخه دو هفته‌ای را انتخاب کردیم که به ما اجازه می‌داد قبل از انتشار در اپ استور، به طور کامل آزمایش کنیم.
اگر اپلیکیشن تحت وب می‌سازید، چرخه شما می‌تواند کوتاه‌تر باشد، و اگر سخت‌افزار است، ممکن است طولانی‌تر باشد. نکته کلیدی این است که چرخه را طوری تنظیم کنید که اعضای تیم هیجان‌زده بمانند و همچنان احساس کنند که می‌توانند ایده های جدیدی را ارائه دهند.
هدف(ها)ی خود را تعیین کنید و مسئول محصول را مشخص کنید
ما فقط یک جلسه تیمی داشتیم. آن جلسه، جلسه محصول بود و در روز اول چرخه توسعه برگزار می‌شد. گاهی اوقات این جلسه تا پنج ساعت طول می‌کشید (ببخشید).
هر جلسه محصول بر روی یکی از سه هدف زیر متمرکز بود:
- افزایش تولید محتوا
- افزایش کاربران جدید
- افزایش حفظ کاربر (Retention)
هر هدفی که انتخاب می‌کردیم، تمرکز جلسه و به تبع آن، دو هفته آینده بود.
به عنوان مسئول محصول در تیم، نقش من این بود که از چرخه توسعه محافظت و آن را بهبود بخشم و جلسات محصول را مدیریت کنم تا همه اعضای تیم برای مشارکت احساس راحتی کنند. اغلب اوقات، فقط داشتن فرصت برای بیان ایده و نوشته شدن آن روی تخته، حتی اگر ساخته نشود، تعهد به فرآیند را به شدت افزایش می‌دهد.
طوفان فکری سازمان‌یافته و فراگیر
در حین طوفان فکری، ایده ها روی تخته وایت‌برد در یکی از دسته‌بندی های زیر نوشته می‌شدند:
قابلیت های جدید/بهبود قابلیت ها، نگهداری (maintenance) و تست های A/B.
انتظار می‌رفت که همه مشارکت کنند. بحث و جدل یا تحقیر ایده های دیگران مجاز نبود. این زمانی بود که همه بدون ترس از قضاوت، در مشارکت آزاد بودند. مسئول محصول مسئول ایجاد و حفظ این محیط است.
سپس هر آیتم طوفان فکری شده توسط مهندس حاضر در جلسه به سه دسته آسان (چند مورد در یک روز قابل انجام است)، متوسط (نصف روز برای یک نفر) و سخت (بیشتر چرخه توسعه) درجه‌بندی می‌شد.
هیچ آیتمی نباید آنقدر سخت باشد که به چرخه بعدی کشیده شود، و اگر بود، آن را به بخش های کوچک‌تر تقسیم می‌کردیم.
معمولاً این درجه‌بندی به صورت آیتم به آیتم توسط مهندسی انجام می‌شد که بیشترین تجربه را در آن حوزه خاص داشت. قابلیت های iOS توسط توسعه‌دهنده iOS رتبه‌بندی می‌شدند و به همین ترتیب. این کار واقعاً به افراد غیرفنی کمک می‌کرد تا بفهمند کدام یک از ایده هایشان ساختنش آسان و کدام سخت است.
با این درک، آن‌ها اغلب در فکر کردن به MVPهای آسان‌تر برای ایده هایشان بهتر می‌شدند. این ایده های آسان سپس ساخته می‌شدند و اگر کار می‌کردند، بهبود می‌یافتند.
ایجاد اجماع
بعد از اینکه ایده هایمان را نوشتیم، شروع به انتخاب مواردی کردیم که می‌خواستیم با اجماع روی آن‌ها کار کنیم. با ایده های سخت شروع می‌کردیم؛ ایجاد اجماع آسان بود چون می‌دانستیم فقط می‌توانیم یک مورد را انجام دهیم و چون می‌دانستیم دو هفته دیگر یک چرخه توسعه جدید را شروع می‌کنیم.
سپس ایده های متوسط و بعد آسان را انتخاب می‌کردیم. ایجاد این اجماع خیلی سخت نبود، چون هر کسی فرصت داشت ایده های خود را پیشنهاد دهد و چون یک هدف و اندازه‌گیری عینی و مشخص از اینکه هر ایده چقدر زمان می‌برد تا ساخته شود، وجود داشت.
این فرآیند به شما اجازه می‌داد کیفیت ایده خود را بسنجید و به شخصیت ها اجازه نمی‌داد ایده های مورد علاقه خود را به زور به بقیه تحمیل کنند.
مشخصات و معیارهای موفقیت شفاف
پس از آن، هر یک از آیتم های لیستمان را به صورت جزئی مشخص (spec) می‌کردیم و هر آیتم را به یک یا چند عضو تیم اختصاص می‌دادیم. همچنین آمار هایی را که باید دنبال می‌کردیم تا میزان اثربخشی قابلیت را بسنجیم، مشخص می‌کردیم.
ما هرگز یک قابلیت را بدون انتشار آمار های مربوط به آن و درک اینکه چه نتیجه قابل اندازه‌گیری خاصی می‌خواهیم ایجاد کنیم، عرضه نمی‌کردیم. در نهایت، موارد لازم (need to haves) را از موارد خوب (nice to haves) در لیست جدا می‌کردیم.
اگر زمان نبود، موارد خوب ساخته نمی‌شدند. پس از اتمام این کار، از تخته وایت‌برد عکس می‌گرفتیم و آن را پاک می‌کردیم. ما به جز این دو هفته، نقشه راه محصول دیگری نداشتیم و هر جلسه محصول را از ابتدا با هدف جدید، داده های آماری جدید از دو هفته گذشته و اغلب با بینش های جدید از تست های حضوری با کاربران، که سعی می‌کردیم ماهی یک بار انجام دهیم، شروع می‌کردیم.
کار در طول چرخه توسعه
برای من، کار پس از اولین دوشنبه چرخه توسعه، یک کار بی‌سر و صدا بود. وظیفه من این بود که تمام کار های مربوط به کسب‌وکار و عملیات را انجام دهم. سپس در Mixpanel به دنبال بینش های جالب محصول یا باگ های احتمالی می‌گشتم. در نهایت، من جلسات ماهانه تست کاربر را در دفترمان برگزار می‌کردم.
اعضای تیمم مهندسان و یک طراح با آرامش و سرعت کار می‌کردند، چون می‌دانستند پروژه هایی با دامنه محدود دارند که به خوبی مشخص شده‌اند.
در نهایت، در طول سه روز آخر هر چرخه توسعه، همه دست از ساختن می‌کشیدیم و تست می‌کردیم. ما یک لیست تست در اکسل داشتیم که شامل تست های دستی برای تمام عملکرد های اساسی ما بود. در هر چرخه، تست هایی برای قابلیت های جدید ساخته شده در آن چرخه اضافه می‌کردیم و تمام آیتم های لیست تستمان را دو بار آزمایش می‌کردیم.
همه اعضای تیم تست می‌کردند و اغلب برای اینکه چه کسی سریع‌تر تست می‌کند و چه کسی بیشترین باگ را پیدا می‌کند، مسابقه می‌گذاشتیم. تست کردن کار خسته‌کننده‌ای است، بنابراین مهم است که این بار به اشتراک گذاشته شود.
نتایج
در پایان، Socialcam به رویای ما یعنی تبدیل شدن به «اینستاگرام برای ویدئو» نرسید. در واقع، چیزی که باید می‌ساختیم، خیلی شبیه به اسنپ‌چت است. اما این فرآیند به ما اجازه داد تا با سرعت بسیار زیادی محصول را تکرار کنیم. در نتیجه، توانستیم به سرعت فهرست بلندبالایی از قابلیت های جذاب را تولید کنیم:
فیلتر های ویدئویی، حاشیه های ویدئویی، عناوین ویدئویی، موسیقی متن ویدئویی، بهینه‌سازی های فید ویدئویی، چندین بازطراحی بصری، پروفایل های کاربری، کانال های پیشنهادی، تغییر دوربین جلو به عقب در حین فیلمبرداری و خیلی چیز های دیگر. همچنین به ما اجازه داد تا ویژگی های رشدی را آزمایش کنیم که در حدود ۳ ماه ۱۶ میلیون دانلود و در همین مدت بیش از ۱۰۰ میلیون نفر بازدیدکننده ویدئو در وب‌سایت ما ایجاد کرد.
با این حال، مهم‌تر از همه، ما تمام این کار ها را به سرعت، به طور کارآمد، بدون بحث های بزرگ، مشکلات در تعهد بنیان‌گذاران، یا در واقع هرگونه مشکل تیمی انجام دادیم. گاهی اوقات از خودم می‌پرسم اگر به جای فروش شرکت، یک سال دیگر به ساخت ادامه می‌دادیم، چه اتفاقی می‌افتاد… اما آن داستان دیگری است.
با تشکر از جارد، جف و کریگ برای کمک به من در این پست، آمون و گیوم، هم‌بنیان‌گذارانم در Socialcam، و جاستین، امت و کایل برای تحمل تمام درد و رنج آن روز های خوب در Justin.tv.
منبع: استارتاپ لب
جهت مطالعه مقالات بیشتر به قسمت مقالات استارتاپ همیارهاب مراجعه کنید.
