امپراطوری اپ (فصل پنجم/ بخش سوم/ پایانی)
فصل پنجم – بخش سوم/ پایانی
آنها کار هستند و شما اندیشه
چطور برای اپ , برنامه‌نویس‌های ماهر استخدام کنیم؟
چطور ایده‌تان را مطرح کنید
وقتی کار با برنامه‌نویس‌ها را شروع کردم، به آنها توضیح می‌دادم که چطور اپلیکیشنی می‌خواهم و این اپ باید چگونه کار کند. فکر می‌کردم کاملا واضح صحبت کردم؛ اما در کمال تعجب محصولی که به من ارایه می‌دادند اصلا شبیه چیزی که می‌خواستم، نبود. برای اصلاح محصول بارها مسایل را بازگویی می‌کردم. کلی زمان صرف می‌شد و در نهایت خستگی نصیب‌مان می‌شد. حتی گاهی از برنامه‌نویس‌ها ناامید می‌شدم. اما مشخص شد که این تقصیر آنها نیست. من به شیوه‌ی درستی با آنها ارتباط برقرار نمی‌کردم و همین باعث می‌شد هردو طرف از این روند خسته شوند. به محض این‌که فهمیدم مشکل از کجاست، همه چیز تغییر کرد. سرعت تکمیل پروژه بیش‌تر و همه خوشحال‌تر شدند.
برای انتقال درست ایده‌ام، آن را روی یک کاغذ می‌کشیدم. شاید نتیجه شبیه نقاشی یک کودک سه ساله شود، اما قطعا بهترین راه برای انتقال آن‌چه تلاش می‌کنید انجام بدهید، است. بعضی‌ها دوست دارند آن را به شکل دیجیتال و در کامپیوترشان انجام دهند. هرطور که راحت‌تر هستید و می‌توانید جزییات مورد نیاز برنامه‌نویس‌ها را به ایشان انتقال دهید، همان راه را انتخاب کنید.
برای آسان‌تر شدن شرایط، من نگاهی به اپ‌استور می‌اندازم و بعضی اپ‌ها را به برنامه‌نویس‌‌ام نشان می‌دهم تا بتوانم دقیق‌تر بگویم دنبال چه چیزی هستم. مثلا می‌گویم “اپ XYZ را دانلود کن. من می‌خواهم قابلیت ABC اپ ما مثل آنها کار کند. نگاهی به اسکرین‌شات‌های فلان اپ بینداز و فلان تغییر را برای اپ خودمان اعمال کن.” همچنین به قسمت‌هایی از اپ‌های دیگر که دوست دارم در اپ خودم بازآفرینی کنم هم نگاهی می‌اندازم و به برنامه‌نویسان هم نظرم را منتقل می‌کنم. به این صورت تا آن‌جایی که می‌توانیم اوضاع را واضح و شفاف می‌کنیم.
در ستایش امپراطوری اپ“استراتژی‌های درآمدزایی از طریق اپلیکیشن‌ها که در این کتاب آمده‌اند ساده، موثر و ثابت شده هستند. در دنیای اپ تعداد کمی هستند که برای نوشتن چنین کتابی مناسب هستند و چاد، بر اساس موفقیت‌های پی در پی‌اش از ابتدا تا کنون یکی از آن‌هاست.”
– «آلن جانسون»، ناشر اپ، با ۱۸ میلیون دانلود و ۱۱ اپ در برترین‌ها
هرچه بیش‌تر منظورتان را واضح بیان کنید، سوتفاهم و مشکلات کم‌تری خواهید داشت. منظور این است که بتوانید بگویید می‌خواهید اپ‌تان چه شکلی باشد. جای هرچیز کجاست و اگر دکمه‌های خاصی زده شد، چه اتفاقی بیافتد. این کمک می‌کند که برنامه‌نویس بداند شما چه می‌خواهید و برای طراحی اپ یک ابزار کارآمد است. به هیچ وجه مبهم و سر بسته صحبت نکنید. باید بدانید که هر قسمت از اپ‌تان چه کاری انجام خواهد داد. اگر در مورد چیزی که می‌خواهید مطمئن نباشید، برنامه‌نویس هم نمی‌تواند خواسته‌ی شما را اجرا کند.
وقتی طرح اولیه را برای برنامه‌نویس‌‌ام می‌فرستم، ترتیب یک جلسه را در اسکایپ می‌دهم. طرح من هرچقدر هم که جزییات زیادی داشته باشد، اما حتما سوال‌ها یا نکات، مشکلات فنی یا ایراداتی وجود دارد که برنامه‌نویس بخواهد راجع به آنها صحبت کند. ما راجع به همه چیز صحبت می‌کنیم و مطمئن می‌شویم که می‌دانیم هر صفحه، دکمه و گزینه قرار است چطور به نظر بیاید و چطور کار کند. ممکن است قبل از این تفاهم لازم باشد بارها جلسه بگذاریم. برنامه‌نویس‌ها قبل از این‌که طرح نهایی را نداشته باشند، حتی یک خط هم کد نمی‌نویسند.
این بخشی از روند درک پیچیدگی و عمل‌کرد اپ است. همین‌طور که برنامه‌نویس‌ها گزینه‌های بیش‌تری را به شما اعلام میکنند، ایده‌های جدیدی هم پیشنهاد می‌دهند که اپ شما را بهتر می‌کند. شاید در اوایل کار بخاطر هزینه‌ها نخواهید که گزینه‌های اضافی بیش‌تری به اپ اضافه کنید. اما هیچ وقت نمی‌دانید کی شرایط مالی برای گسترش اپ‌تان بهتر می‌شود. گاهی متوجه می‌شوید که اجرای ایده‌تان غیرممکن است و می‌توانید بدون تلف کردن وقت بیش‌تر از آن صرف‌نظر کنید.
به محض این‌که کد زدن شروع شد، باید طرح نهایی کار را در ذهن داشته باشید. همین‌که شروع به امتحان نمونه‌ی ابتدایی اپ خود کنید، پیشنهادهایی برای اضافه کردن گزینه‌های بیش‌تر از طرف برنامه‌نویس‌تان خواهید داشت. تغییر دادن چیزها بعد از این‌که بخشی از کار انجام شده، برنامه‌نویس را اذیت خواهد کرد. مثل این است که وقتی بنا شومینه را در خانه‌تان ساخت، به او بگویید که دل‌تان می‌خواهد جای آن را تغییر داده و یک سمت دیگر اتاق نشیمن بسازیدش. نتیجه این کار خیلی خوب از آب در نخواهد آمد. بسیاری متوجه نیستند که وقتی از برنامه‌نویس‌شان توقع تغییرات بزرگ و اساسی دارند دقیقا همین کار را انجام می‌دهند. به همین دلیل است که باید برای برنامه‌ریزی اپ در طول طراحی آن وقت بگذارید و همچنین اهمیت روند تبادل اطلاعات با برنامه‌نویس‌تان اهمیت دارد.
از طرف دیگر، شما نمی‌توانید سوال‌هایی را که ممکن است در طول کامل کردن اپ برای‌تان پیش بیاید را پیش‌بینی کنید و ممکن است مجبور شوید طرح‌تان را عوض کنید. این کاملا طبیعی است و برنامه‌نویس‌ها تا حدودی انتظارش را دارند. با این‌حال، تغییراتی را که باعث می‌شود هفته‌ها یا روزها کار شما به باد برود و تیم‌تان اذیت شود را اعمال نکنید.
اگر مدام در حال اضافه کردن گزینه‌‌ها باشید، ناخواسته زمان و هزینه‌ی تولید را بالا می‌برید. باید اپ‌تان را ساده و سریع وارد بازار کنید تا واکنش‌ها را محک بزنید. فقط اگر حس کردید که یک دلیل منطقی برای این کار دارید، می‌توانید کارتان را مجددا طراحی کنید. در غیر این صورت، ایده‌تان را به لیست آپدیت‌ها اضافه کنید و به کارتان ادامه دهید. من یک لیست آپدیت دارم و هرگاه که می‌خواهم به یکی از اپ‌های‌ام چیزی اضافه کنم، به سراغ لیست‌ام می‌روم.
من بارها و زمانی از این روند طراحی استفاده کردم که اولین نسخه از اپلیکیشن‌‌ام حدود ۹۰ درصد تکمیل شده بود و برای نهایی کردن کار فقط به یک یا دو جلسه‌ی دیگر با برنامه‌نویس‌‌ام نیاز بود. بستگی به تجربه‌تان، ممکن است طرح اولیه‌تان کاملا دقیق نباشد. اما وقتی قلق کار دست‌تان بیاید و چند اپ را روانه ی بازار کردید، می‌توانید طرح‌های واضح‌تر و درست‌تری بسازید.
بهترین قسمت این است که اگر برنامه نویس‌ها کلیت ماجرای پروژه را کاملا بفهمند، می‌توانند اطلاعات صحیح به من بدهند. این به شما کمک خواهد کرد؛ خصوصا وقتی تازه‌کار باشید و بودجه‌تان هم محدود باشد.
محک زدن برنامه‌نویسان استخدام شده
خب، حالا وقت خوبی برای جمع کردن اطلاعات و محک زدن داوطلبان است. پیشنهاد من این است که سراغ سه برنامه‌نویس مختلف بروید و برای هر کدام از سه ایده‌ی خودتان از آنها قیمت بگیرید. خیلی‌ها تصورشان این است که برای ساختن اپ‌های موفق و پول‌ساز باید سرمایه‌ی زیادی خرج کنند. برای این‌که بدانید من برای اولین اپ‌‌ام چقدر هزینه کردم، باید بگویم که به توسعه دهنده ۱.۸۰۰ دلار پرداختم و در عوض بازگشت پول‌ام یک عدد شش رقمی بود. قیمت‌ها بسته به نوع اپ متفاوت هستند. اما سعی کنید هزینه‌ی ابتدایی توسعه‌ی اپ را تا آن‌جا که ممکن است، پایین بیاورید. هرچه بیش‌تر تجربه و پول کسب کنید، می‌توانید با خیال راحت سراغ پروژه‌های گران‌تر بروید.
در این مرحله، برنامه‌نویسان را پیدا کرده‌اید، با آنها مصاحبه کرده و سوابق‌شان را بررسی کرده‌اید. قرارداد عدم افشا امضا کرده‌اید، ایده‌تان را به آنها منتقل کرده‌اید، چند لیست قیمت دارید و یکی را برای هم‌کاری انتخاب کرده‌اید. من در این مرحله، به‌جای این‌که بی‌مقدمه سر اصل مطلب بروم و کل پروژه را با آنها شروع کنم، اول با چیزهای کوچک امتحان‌شان می‌کنم. هربار که با یک برنامه‌نویس جدید کار می‌کنم، حتما و غالبا این سه مورد را از او می‌خواهم:
۱. آیکون: از برنامه‌نویس بخواهید که آیکون اپلیکیشن‌تان را بسازد و به شما بدهد. شکل ۲-۵ چیزی است که شما وقتی به آی‌تیونز یا گوشی خودتان نگاه می‌کنید، می‌بینید. این‌ها را به او نشان بدهید و از او بخواهید یک نمونه از آیکون مدل itunes artwork در ابعاد ۵۱۲*۵۱۲ به شما تحول بدهد. آنها خودشان می‌دانند که منظور شما چیست.
شکل ۲-۵ آیکون اپ‌ها
۲. یک اپ Hello World: از برنامه‌نویس‌تان یک اپ Hello World بخواهید. این فقط ۱۰ دقیقه از وقت‌شان را می‌گیرد تا یک اپ ساده درست کنند که باز می‌شود و یک صفحه دارد که در آن نوشته Hello World (شکل ۳-۵). برنامه‌نویس‌ها منظور شما را کاملا می‌دانند. در این‌جا هدف محک زدن مهارت برنامه‌نویسی آنها نیست؛ بلکه نحوه‌ی تحویل اپ به شما برای امتحان کردن است. این اپ باید شامل آیکون‌هایی باشد تا شما ببینید روی گوشی شما چطور به نظر می‌آیند.
شکل ۳-۵ Hello, World
۳. تحویل اپ: وقتی که برنامه‌نویس‌ها آمادگی این را دارند که نسخه‌ی آزمایشی اپلیکیشن‌تان را به شما نشان بدهند، باید چیزی به اسم ad hoc بسازند. این نسخه‌ی ad hoc اپ‌تان ابتدا باید روی گوشی شما نصب شود تا بتوانید امتحاناش کنید. قبلا نصب کردن این نسخه مایه‌ی زحمت بود؛ اما یک سرویس جدیدی به اسم TestFlight این روند را آسان کرده است(شکل ۴-۵). من از همه‌ی برنامه‌نویس‌های‌ام می‌خواهم که از این سرویس استفاده کنند. حتی اگر قبلا امتحاناش نکرده‌اند. آنها بالاخره یاد خواهند گرفت که با آن کار کنند و شما هم می‌توانید اپ‌تان را به سادگی نصب کنید.
شکل ۴-۵ سرویس TestFlight
من هیچ‌وقت بیش‌تر از چند صد دلار برای این اپ خرج نکردم؛ اما در عوض این تست به من کمک می‌کند که گرافیک، سرعت و قابلیت‌های حرکتی اپ را بسنجم ( مثل ارتباطات و فاصله‌ی زمانی). شما یا باید کارتان را از جای درستی شروع کنید یا باید به سرعت تغییر مسیر دهید و این بهترین راه انجام این کار است.
حتما در مصاحبه‌تان ذکر کنید که دوست دارید از طریق این تست کارتان را شروع کنید. حتما این کار را بکنید تا برنامهنویسهایتان بعد از انجام مرحله‌ی قیمت‌گذاری، غافلگیر نشوند. گاهی آنها حاضرند این تست را به طور رایگان برای‌تان انجام بدهند؛ اما گاهی هم پول کمی برای‌ا‌ش می‌گیرند. در هرصورت، حتما در مورد این قضیه رک و صریح باشید و حتما از آنها بخواهید که در لیست قیمت‌های‌شان، آن را هم بیاورند.
روند پیدا کردن برنامه‌نویس‌ها ممکن است وقت‌گیر باشد. اما این زمانی است که دارد مفید می‌گذرد. از هیچ بخش آن سرسری نگذرید. این باعث خواهد شد که درگیر تاخیرها، هزینه‌ها و گرفتاری‌های بی‌جهت نشوید. همیشه دنبال این باشید که استعدادهای جدید به تیم‌تان وارد کنید. پس یکی از مهارت‌های مهمی که باید داشته باشید این است که یاد بگیرید سریع و درست برنامه‌نویس‌ها را ارزیابی کنید.
چطور برنامه‌نویس‌ها را مدیریت کنیم
پیدا کردن برنامه‌نویس‌های خوب، انرژی زیادی لازم دارد. برای این‌که آنها را خوش‌حال و کسب و کارتان را پررونق نگه دارید، باید فوت و فن مدیریت آنها را یاد بگیرید. در ادامه نکاتی را که در رابطه با مدیریت برنامه نویس‌ها یاد گرفتم به شما می‌گویم.
همیشه از آن‌چه در حال انجام شدن در پروژه‌تان است با خبر باشید
ممکن است روزی تصمیم بگیرید که برنامه‌نویس‌های تمام وقت استخدام کنید. اما تا آن موقع، شما با شرکت‌ها و برنامه‌نویس‌های مستقلی کار خواهید کرد که چندین پروژهی هم‌زمان را باهم انجام می‌دهند. همین ممکن است باعث شود تبادل اطلاعات بین شما و آنها در حد مطلوب نباشد. همچنین ممکن است حواس‌شان نباشد که باید شما را مدام در جریان روند کارتان قرار دهند. اگر آنها را مدام چک نکنید، باعث می‌شود زمان اتمام پروژه به تاخیر بیافتد یا محصول نهایی با آن‌چه در ذهن شماست، متفاوت باشد. شما مدیر پروژه و صاحب این کسب و کار هستید و این شمایید که باید همه چیز را هدایت کنید و در مسیر درست نگه دارید؛ نه برنامه‌نویس‌ها.
من در گذشته در انجام این کار ضعیف عمل کردم. بدون این‌که توسعه‌دهندگان‌ام را مرتب چک کنم، اجازه دادم هرچقدر زمان لازم دارند برای انجام کار من صرف کنند. بعدها یاد گرفتم که در طول روند قیمت‌گیری از آنها بخواهم زمان و مراحل انجام کار را مشخص کنند. این کار کمک می‌کرد قبل از این‌که کار شروع شود و حتی یک خط کد نوشته شود، بدانم در هر مرحله، اپ من چه شکلی خواهد بود و چطور کار خواهد کرد. من در فواصل زمانی معین کار آنها را چک می‌کنم تا ببینم کجای کار هستند و کدام قسمت‌ها احتیاج به بهینه‌سازی دارند. سپس به عقب برمی‌گردیم و تمام مراحل را دوباره چک می‌کنیم. اکثر برنامه‌نویس‌ها در طول طراحی و توسعه به جلسات تکرار و بازگویی مطالب نیاز دارند و من تا وقتی که از هر مرحله‌ی کار کاملا راضی نباشم، پولی بابت‌ا‌ش پرداخت نمی‌کنم. نگذارید هواپیمای‌تان برای مدت زیادی از مسیر خارج شود؛ وگرنه ممکن است عاقبت سر از قطب جنوب و آب یخ در بیاورید!
به آهستگی استخدام و به سرعت اخراج کنید
همین که تجربه‌ی انتشار چند اپ را کسب کردید و شرایط با برنامه‌نویس یا گروه توسعه دهنده‌تان بر وفق مراد بود، شاید تصمیم گرفتید که یک نفر را به‌طور تمام وقت استخدام کنید. از طرفی انعطافی که در قراردادهای مقاطعه کاری دیده می‌شود، فوق‌العاده است. از طرف دیگر، ریسک این‌که مشتریان دیگر آنها را استخدام کنند و برای چند ماه آنها را به‌طور تمام وقت درگیر پروژهی خودشان کنند، هم زیاد است.
به محض این‌که حس کردید از کار برنامه‌نویس خاصی راضی هستید و اوضاع مالی هم روبه‌راه است، جذب‌ا‌ش کنید. من چند نفر را دارم که در بازبینی‌های ماهیانه‌ام، همیشه نگه‌شان می‌دارم. آنها می‌دانند که من هرماه با آنها حداقل پول ممکن را خرج می‌کنم و در عوض، آنها پروژه‌ام را در اولویت می‌گذارند.
اگر متوجه مشکلاتی از قبیل بی مسوولیتی، شلخته کاری و بی‌برنامگی شدید، سریعا جلوی ضرر را بگیرید و اخراج‌شان کنید. وگرنه، باری به دوش شرکت‌تان می‌شوند. مثل هر تمام شدن دیگری، شما باید دوستانه برخورد کنید. این فقط تجارت است و شما قطعا نمی‌خواهید، کسانی که سرمایه‌تان دست آن‌هاست را عصبانی کنید.
بهترین راه برای بیرون کردن برنامه‌نویس‌ها این است که برای‌شان توضیح بدهید که آنها توقعات شما را برآورده نکردند و شما می‌خواهید به همکاری‌تان با ایشان خاتمه دهید. هرقدر از کارتان را که ممکن است نجات بدهید. این کار را بکنید، و دست‌مزد برنامه‌نویس را عادلانه محاسبه کنید. اما روند حرکت‌تان کند نشود و از این جریان درس بگیرید.
چطور اپلیکیشن‌های‌تان را امتحان کنید
تبریک می‌گویم. شما تمام مراحل توسعه را پشت سر گذاشتید و حالا اپ‌تان آماده است. قبل از این‌که این موفقیت را جشن بگیرید، باید چند کار مهم و اساسی انجام دهید. اگر یک خانه ساخته بودید، قبل از امضای تحویل کار، همه چیز را سر جای خودشان و کامل شده می‌خواستید. حتما قسمت‌های اساسی خانه را کنترل می‌کردید. مثل سقف و همه‌ی ریز و درشت خانه را چک می‌کردید. درست مثل یک شی فاخر و ارزشمند یا تزیینی. همین کار را هم باید با اپ‌تان هم انجام بدهید.
برای شروع، اپ شما باید همان‌طور که انتظارش را دارید اجرا بشود. پوشه‌ی طراحی اولیه‌تان را دم دست بگذارید و تمام جزییات را چک کنید. هیچ وقت کنترل قسمتی را فقط به این خاطر که دفعه‌ی قبل چک‌ا‌ش کردید و کار می‌کرده است، از قلم نیاندازید. هر قسمت را چند بار چک کنید؛ خصوصا قبل از انتشار اپ. در این مرحله زیاد مکث نکنید؛ چرا که به عنوان سازنده‌ی اپ خودتان، خوب می‌دانید که هر چیز چطور باید کار کند. این ممکن است برای دیگران معنایی نداشته باشد؛ اما برای خودتان چرا.
اگر برای یک شرکت بزرگ توسعه‌گر کار کرده باشید، پس یک تیم از مهندسان با درآمد بالا در اختیار داشته‌اید که اپ شما را حسابی زیر و رو کنند. اما به‌عنوان یک اپ‌آفرین تنهای مستقل، احتمالا چنین منابعی در اختیار ندارید. اما، می‌توانید همین کار را از طریق منابعی که همه‌ی ما داریم انجام دهید: طرح دوستان و خانواده. کار شما این است که هرکسی را که می‌شناسید، از مادر بزرگ ۷۵ ساله تا خواهرزاده‌ی ۱۲ ساله‌تان بخواهید، اپ شما را امتحان کنند.
زمانی که صرف تست کردن اپ‌تان می‌کنید بسیار مهم است؛ زیرا شما خواهید دید که مشتریان چطور از آن استفاده میکنند، چه چیز برای‌شان آسان و کدام قسمت برای‌شان گنگ است. آنها سوال‌هایی خواهند داشت که برای خودتان پیش نیامده؛ چون شما اپ را طراحی کرده‌اید و همه چیز برای‌تان واضح و شفاف است.
بی مقدمه اپ را به آنها نشان بدهید و چیزی شبیه “هی، این را امتحان کن!” به آنها بگویید. اصلا نگویید که آن اپ شماست، چطور کار می‌کند یا کارش چیست. همان‌طور که آنها را زیر نظر دارید که دارند اپ شما را امتحان میکنند، کم‌ترین اطلاعات ممکن را به آنها بدهید. این تجربه شبیه همانی است که مشتری واقعی شما خواهد داشت؛ چرا که شما آن‌جا نخواهید بود تا مسایل را به آنها توضیح دهید. آنها را هنگامی که دارند با اپ شما کار میکنندT نگاه کنید و از خودتان این سوال‌ها را بپرسید:
۱. آیا گیج شدند؟
۲. آیا در مرحله‌ای گیر کردند؟
۳. آیا غرغر میکنند؟
۴. آیا از اپ همان‌طور که شما می‌خواهید استفاده میکنند؟
۵. آیا به دلیل این‌که به طور متفاوتی از اپ استفاده کردند، ایرادی از کارتان پیدا کردند؟ (اصطلاحا باگ هم گفته می‌شود)
۶. آیا سرگرم شده‌اند؟
۷. آیا برای بهتر شدن اپ پیشنهاداتی دارند؟ اگر بله، چه پیشنهادی؟
از آنها بخواهید در مورد تجربه‌ی کار کردن‌شان با اپ شما صحبت کنند. اگر ندانند که اپ شماست حتما بیش‌تر صادق خواهند بود. اگر چیزی شنیدید که دوست نداشتید، به‌تان بر نخورد. این بازخوردها فوق‌العاده با ارزش هستند. هر پاسخ و عکس‌العمل را به دقت ارزیابی کنید تا بفهمید آیا اپ‌تان مشکلی دارد یا نه. از خودتان این سوال‌ها را بپرسید:
۱. آیا کاربرهای دیگر هم مشکلات مشابهی دارند؟ اگر بله، چطور می‌توانید آنها را برطرف کنید؟
۲. آیا بهتر است جای بعضی چیزها را در اپ تغییر دهید؟
۳. آیا برای بهتر دیده شدن باید بعضی از رنگ‌ها را تغییر دهید؟
۴. آیا اضافه کردن “راهنمای استفاده” مفید است؟
۵. آیا باید جهت‌یابی را اصلاح کنید؟
من یکی از اپ‌های اخیرم را به دوست‌ام جیسون نشان دادم. تمام مدتی که با اپ کار می‌کرد یک مشکل کوچک داشت: “چاد، این خیلی خوب و جالب است؛ اما من چطور می‌توانم به منوی اصلی برگردم؟”
من گفتم: “همان‌جاست”. و او پرسید ” کجا؟”. و آن‌جا بود که فهمیدم دکمه‌ی بازگشت هم‌رنگ زمینه و کوچک است. به همین خاطر او متوجه نمی‌شد که یک دکمه آن‌جاست و من فهمیدم که بقیه هم همین مشکل را خواهند داشت. همان ۱۰ دقیقه که من اپ را به او نشان دادم کافی بود تا من این نکته را بفهمم.
بعد از این‌که بازخوردهای مختلف را یادداشت کردید، از برنامهنویسهایتان بخواهید این مشکلات را برطرف یا تغییرات لازم را اعمال کنند. شما باید مطمئن باشید که اپ شما روی همه‌ی مدل‌های آیفون، آیپاد تاچ و شاید هم آیپد کار کند. اپل به نوآوری‌ها و تولید محصولات جدید سالانه‌اش، ادامه خواهد داد. اپ شما هرچه روی دستگاه‌های بیش‌تری کار کند، بهتر است. این چیزی است که شما باید اول کار با برنامهنویسهایتان در میان بگذارید. مطمئن شوید آنها اپ را برای دستگاه‌های مختلف می‌سازند.
بازهم، شما باید اپ‌تان را روی تمام دستگاه‌ها امتحان کنید؛ اما وقتی شکارتان را شروع کرده باشید، این غیرممکن است. در ابتدا این وظیفه برنامهنویسهایتان است که اپلیکیشن‌تان را روی تمام دستگاه‌ها امتحان کنند. من از برنامه‌نویس‌های‌ام می‌خواهم لیستی از ویژگی‌ها و جزییاتی که باید کنترل کنم و در صورت نیاز اصلاح شوند را به من بدهند. من هر کدام از آنها را مدام چک می‌کنم تا وقتی که همه چیز همان‌طور که باید، کار کند.
تست کردن و برطرف کردن باگ‌ها هم مثل مراحل طراحی و توسعه، چندین جلسه کار خواهند برد. این همه‌ی قسمت‌های روند تولید بود. از اپ TestFlight استفاده کنید تا برای نصب ورژن امتحانی اپ‌تان زمان زیادی از دست ندهید. بالاخره شما تغییرات را انجام می‌دهید و اپ را برای انتشار به اپ‌استور می‌فرستید.
برای انتشار اولین اپ‌های‌تان در اپ‌استور، اگر برنامه‌نویس‌تان یا کس دیگری از اعضا گروه، باشد که کمک کند، ایده‌ی خوبی است. هیچ وقت اطلاعات‌تان برای ورود به پورتال توسعه دهنده‌ی آنلاین را به برنامه‌نویس‌تان یا هیچ‌کس دیگری ندهید. بهترین راه برای کمک گرفتن استفاده از اسکایپ یا GoToMeeting است تا ضمن این‌که صفحه‌ی مانیتورتان را به آنها نشان می‌دهید، به شما کمک کنند تا این فرآیند انجام شود. همان‌طور که کسب و کارتان بزرگ‌تر می‌شود، ممکن است بخواهید یک نفر از اعضای گروه‌تان را به عنوان نماینده‌ی خودتان انتخاب کنید.
به‌خاطر داشته باشید، همه‌ی این‌ها خیلی آسان‌تر از چیزی است که به‌نظر می‌رسد. حالا که اهمیت و روند تشکیل دادن یک گروه توسعه دهنده را متوجه شدید، وقت آن است که همین‌جا این فصل را تمام کنم تا کمی استراحت کنید. در فصل بعد، درباره‌ی مهم‌ترین کارتان، یعنی بازاریابی برای اپ‌های‌تان صحبت خواهیم کرد.
سلام
واقعا عالی هست !
یه پیشنهاد داشتم ، لطفا کتاب “” ۴ساعت کار در هفته “” رو هم ترجمه کنید .
خیلی تعریفش رو شنیدم اما ترجمه ای ازش موجود نیست .
خیلی عالی
واقعا ممنون