امپراطوری اپ (فصل پنجم/ بخش سوم/ پایانی)

در این مقاله از سایت آکاایران مطلبی در مورد امپراطوری اپ (فصل پنجم/ بخش سوم/ پایانی) ارائه شده است ، همچنین برای مشاهده مقالات بیشتر در دسته از سایت ترفند آکاایران مقالات بیشتری را مشاهده نمایید

امپراطوری اپ (فصل پنجم/ بخش سوم/ پایانی)
,[categoriy]

آکاایران: امپراطوری اپ (فصل پنجم/ بخش سوم/ پایانی)

آکاایران فصل پنجم – بخش سوم/ پایانی

به گزارش آکاایران آن ها کار هستند و شما اندیشه

چطور برنامه نویس های ماهر استخدام کنیم؟

چطور ایده تان را مطرح کنید

,[categoriy]
وقتی کار با برنامه نویس ها را شروع کردم، به آن ها توضیح می دادم که چطور اپلیکیشنی می خواهم و این اپ باید چگونه کار کند. فکر می کردم کاملا واضح صحبت کردم؛ اما در کمال تعجب محصولی که به من ارایه می دادند اصلا شبیه چیزی که می خواستم، نبود. برای اصلاح محصول بارها مسایل را بازگویی می کردم. کلی زمان صرف می شد و در نهایت خستگی نصیب مان می شد. حتی گاهی از برنامه نویس ها ناامید می شدم. اما مشخص شد که این تقصیر آن ها نیست. من به شیوه ی درستی با آن ها ارتباط برقرار نمی کردم و همین باعث می شد هردو طرف از این روند خسته شوند. به محض این که فهمیدم مشکل از کجاست، همه چیز تغییر کرد. سرعت تکمیل پروژه بیش تر و همه خوشحال تر شدند.

برای انتقال درست ایده ام، آن را روی یک کاغذ می کشیدم. شاید نتیجه شبیه نقاشی یک کودک سه ساله شود، اما قطعا بهترین راه برای انتقال آن چه تلاش می کنید انجام بدهید، است. بعضی ها دوست دارند آن را به شکل دیجیتال و در کامپیوترشان انجام دهند. هرطور که راحت تر هستید و می توانید جزییات مورد نیاز برنامه نویس ها را  به ایشان انتقال دهید، همان راه را انتخاب کنید.

برای آسان تر شدن شرایط، من نگاهی به اپ استور می اندازم و بعضی اپ ها را به برنامه نویس ام نشان می دهم تا بتوانم دقیق تر بگویم دنبال چه چیزی هستم. مثلا می گویم “اپ XYZ را دانلود کن. من می خواهم قابلیت ABC اپ ما مثل آن ها کار کند. نگاهی به اسکرین شات های فلان اپ بینداز و فلان تغییر را برای اپ خودمان اعمال کن.” هم چنین به قسمت هایی از اپ های دیگر که دوست دارم در اپ خودم بازآفرینی کنم هم نگاهی می اندازم و به برنامه نویسان هم نظرم را منتقل می کنم. به این صورت تا آن جایی که می توانیم اوضاع را واضح و شفاف می کنیم.

در ستایش امپراطوری اپ

“استراتژی های درآمدزایی از طریق اپلیکیشن ها که در این کتاب آمده اند ساده، موثر و ثابت شده هستند. در دنیای اپ تعداد کمی هستند که برای نوشتن چنین کتابی مناسب هستند و چاد، بر اساس موفقیت­ های پی در پی­ اش از ابتدا تا کنون یکی از آن­ هاست.”

– «آلن جانسون»، ناشر اپ، با 18 میلیون دانلود و 11 اپ در برترین ها

هرچه بیش تر منظورتان را واضح بیان کنید، سوتفاهم و مشکلات کم تری خواهید داشت. منظور این است که بتوانید بگویید می خواهید اپ تان چه شکلی باشد. جای هرچیز کجاست و اگر دکمه های خاصی زده شد، چه اتفاقی بیافتد. این کمک می کند که برنامه نویس بداند شما چه می خواهید و برای طراحی اپ یک ابزار کارآمد است. به هیچ وجه مبهم و سر بسته صحبت نکنید. باید بدانید که هر قسمت از اپ تان چه کاری انجام خواهد داد. اگر در مورد چیزی که می خواهید مطمئن نباشید، برنامه نویس هم نمی تواند خواسته ی شما را اجرا کند.

وقتی طرح اولیه را برای برنامه نویس ام می فرستم، ترتیب یک جلسه را در اسکایپ می دهم. طرح  من هرچقدر هم که جزییات زیادی داشته باشد، اما حتما سوال ها یا نکات، مشکلات فنی یا ایراداتی وجود دارد که برنامه نویس بخواهد راجع به آن ها صحبت کند. ما راجع به همه چیز صحبت می کنیم و مطمئن می شویم که می دانیم هر صفحه، دکمه و گزینه قرار است چطور به نظر بیاید و چطور کار کند. ممکن است قبل از این تفاهم لازم باشد بارها جلسه بگذاریم. برنامه نویس ها قبل از این که طرح نهایی را نداشته باشند، حتی یک خط هم کد نمی نویسند.

این بخشی از روند درک پیچیدگی و عمل کرد اپ است. همین طور که برنامه نویس ها گزینه های بیش تری را به شما اعلام می کنند، ایده های جدیدی هم پیشنهاد می دهند که اپ شما را بهتر می کند. شاید در اوایل کار بخاطر هزینه ها نخواهید که گزینه های اضافی بیش تری به اپ اضافه کنید. اما هیچ وقت نمی دانید کی شرایط مالی برای گسترش اپ تان بهتر می شود. گاهی متوجه می شوید که اجرای ایده تان غیرممکن است و می توانید بدون تلف کردن وقت بیش تر از آن صرف نظر کنید.

به محض این که کد زدن شروع شد، باید طرح نهایی کار را در ذهن داشته باشید. همین که شروع به امتحان نمونه ی ابتدایی اپ خود کنید، پیشنهادهایی برای اضافه کردن گزینه های بیش تر از طرف برنامه نویس تان خواهید داشت. تغییر دادن چیزها بعد از این که بخشی از کار انجام شده، برنامه نویس را اذیت خواهد کرد. مثل این است که وقتی بنا شومینه را در خانه تان ساخت، به او بگویید که دل تان می خواهد جای آن را تغییر داده و یک سمت دیگر اتاق نشیمن بسازیدش. نتیجه این کار خیلی خوب از آب در نخواهد آمد. بسیاری متوجه نیستند که وقتی از برنامه نویس شان توقع تغییرات بزرگ و اساسی دارند دقیقا همین کار را انجام می دهند. به همین دلیل است که باید برای برنامه ریزی اپ در طول طراحی آن وقت بگذارید و هم چنین اهمیت روند تبادل اطلاعات با برنامه نویس تان اهمیت دارد.

از طرف دیگر، شما نمی توانید سوال هایی را که ممکن است در طول کامل کردن اپ برای تان پیش بیاید را پیش بینی کنید و ممکن است مجبور شوید طرح تان را عوض کنید. این کاملا طبیعی است و برنامه نویس ها تا حدودی انتظارش را دارند. با این حال، تغییراتی را که باعث می شود هفته ها یا روزها کار شما به باد برود و تیم تان اذیت شود را اعمال نکنید.

اگر مدام در حال اضافه کردن گزینه ها باشید، ناخواسته زمان و هزینه ی تولید را بالا می برید. باید اپ تان را ساده و سریع وارد بازار کنید تا واکنش ها را محک بزنید. فقط اگر حس کردید که یک دلیل منطقی برای این کار دارید، می توانید کارتان را مجددا طراحی کنید. در غیر این صورت، ایده تان را به لیست آپدیت ها اضافه کنید و به کارتان ادامه دهید. من یک لیست آپدیت دارم و هرگاه که می خواهم به یکی از اپ های ام چیزی اضافه کنم، به سراغ لیست ام می روم.

من بارها و زمانی از این روند طراحی استفاده کردم که اولین نسخه از اپلیکیشن ام حدود درصد تکمیل شده بود و برای نهایی کردن کار فقط به یک یا دو جلسه ی دیگر با برنامه نویس ام نیاز بود. بستگی به تجربه تان، ممکن است طرح اولیه تان کاملا دقیق نباشد. اما وقتی قلق کار دست تان بیاید و چند اپ را روانه ی بازار کردید، می توانید طرح های واضح تر و درست تری بسازید.

بهترین قسمت این است که اگر برنامه نویس ها کلیت ماجرای پرو ژه را کاملا بفهمند، می توانند اطلاعات صحیح به من بدهند. این به شما کمک خواهد کرد؛ خصوصا وقتی تازه کار باشید و بودجه تان هم محدود باشد.

محک زدن برنامه نویسان استخدام شده

خب، حالا وقت خوبی برای جمع کردن اطلاعات و محک زدن داوطلبان است. پیشنهاد من این است که سراغ سه برنامه نویس مختلف بروید و برای هر کدام از سه ایده ی خودتان از آن ها قیمت بگیرید. خیلی ها تصورشان این است که برای ساختن اپ های موفق و پول ساز باید سرمایه ی زیادی خرج کنند. برای این که بدانید من برای اولین اپ ام چقدر هزینه کردم، باید بگویم که به توسعه دهنده 1.800 دلار پرداختم و در عوض بازگشت پول ام یک عدد شش رقمی بود. قیمت ها بسته به نوع اپ متفاوت هستند. اما سعی کنید هزینه ی ابتدایی توسعه ی اپ را تا آن جا که ممکن است، پایین بیاورید. هرچه بیش تر تجربه و پول کسب کنید، می توانید با خیال راحت سراغ پروژه های گران تر بروید.

در این مرحله، برنامه نویسان را پیدا کرده اید، با آن ها مصاحبه کرده و سوابق شان را بررسی کرده اید. قرارداد عدم افشا امضا کرده اید، ایده تان را به آن ها منتقل کرده اید، چند لیست قیمت دارید و یکی را برای هم کاری انتخاب کرده اید. من در این مرحله، به جای این که بی مقدمه سر اصل مطلب بروم و کل پروژه را با آن ها شروع کنم، اول با چیزهای کوچک امتحان شان می کنم. هربار که با یک برنامه نویس جدید کار می کنم، حتما و غالبا این سه مورد را از او می خواهم:

1. آیکون: از برنامه نویس بخواهید که آیکون اپلیکیشن تان را بسازد و به شما بدهد. شکل 2-5 چیزی است که شما وقتی به آی تیونز یا گوشی خودتان نگاه می کنید، می بینید. این ها را به او نشان بدهید و از او بخواهید یک نمونه از آیکون مدل itunes artwork در ابعاد 512*512  به شما تحول بدهد. آ ن ها خودشان می دانند که منظور شما چیست.

,[categoriy]

شکل 2-5 آیکون اپ ها

2. یک اپ Hello World: از برنامه نویس تان یک اپ Hello World بخواهید. این فقط 10 دقیقه از وقت شان را می گیرد تا یک اپ ساده درست کنند که باز می شود و یک صفحه دارد که در آن نوشته  Hello World (شکل 3-5). برنامه نویس ها منظور شما را کاملا می دانند. در این جا هدف محک زدن مهارت برنامه نویسی آن ها نیست؛ بلکه نحوه ی تحویل اپ به شما برای امتحان کردن است. این اپ باید شامل آیکون هایی باشد تا شما ببینید روی گوشی شما چطور به نظر می آیند.

,[categoriy]

شکل 3-5 Hello, World

3. تحویل اپ: وقتی که برنامه نویس ها آمادگی این را دارند که نسخه ی آزمایشی اپلیکیشن تان را به شما نشان بدهند، باید چیزی به اسم ad hoc بسازند. این نسخه ی ad hoc اپ تان ابتدا باید روی گوشی شما نصب شود تا بتوانید امتحان اش کنید. قبلا نصب کردن این نسخه مایه ی زحمت بود؛ اما یک سرویس جدیدی به اسم TestFlight این روند را آسان کرده است(شکل 4-5). من از همه ی برنامه نویس های ام می خواهم که از این سرویس استفاده کنند. حتی اگر قبلا امتحان ا ش نکرده اند. آن ها بالاخره یاد خواهند گرفت که با آن کار کنند و شما هم می توانید اپ تان را به سادگی نصب کنید.

,[categoriy]

شکل 4-5 سرویس TestFlight

من هیچ وقت بیش تر از چند صد دلار برای این اپ خرج نکردم؛ اما در عوض این تست به من کمک می کند که گرافیک، سرعت و قابلیت های حرکتی اپ را بسنجم ( مثل ارتباطات و فاصله ی زمانی). شما یا باید کارتان را از جای درستی شروع کنید یا باید به سرعت تغییر مسیر دهید و این بهترین راه انجام این کار است.

حتما در مصاحبه تان ذکر کنید که دوست دارید از طریق این تست کارتان را شروع کنید. حتما این کار را بکنید تا برنامه نویس های تان بعد از انجام مرحله ی قیمت گذاری، غافلگیر نشوند. گاهی آن ها حاضرند این تست را به طور رایگان برای تان انجام بدهند؛ اما گاهی هم پول کمی برای ا ش می گیرند. در هرصورت، حتما در مورد این قضیه رک و صریح باشید و حتما از آن ها بخواهید که در لیست قیمت های شان، آن را هم بیاورند.

روند پیدا کردن برنامه نویس ها ممکن است وقت گیر باشد. اما این زمانی است که دارد مفید می گذرد. از هیچ بخش آن سرسری نگذرید. این باعث خواهد شد که درگیر تاخیرها، هزینه ها و گرفتاری های بی جهت نشوید. همیشه دنبال این باشید که استعدادهای جدید به تیم تان وارد کنید. پس یکی از مهارت های مهمی که باید داشته باشید این است که یاد بگیرید سریع و درست برنامه نویس ها را ارزیابی کنید.

چطور برنامه نویس ها را مدیریت کنیم

پیدا کردن برنامه نویس های خوب، انرژی زیادی لازم دارد. برای این که آن ها را خوش حال و کسب و کار تان را پررونق نگه دارید، باید فوت و فن مدیریت آن ها را یاد بگیرید. در ادامه نکاتی را که در رابطه با مدیریت برنامه نویس ها یاد گرفتم به شما می گویم.

همیشه از آن چه در حال انجام شدن در پروژه تان است با خبر باشید

ممکن است روزی تصمیم بگیرید که برنامه نویس های تمام وقت استخدام کنید. اما تا آن موقع، شما با شرکت ها و برنامه نویس های مستقلی کار خواهید کرد که چندین پروژه ی هم زمان را باهم انجام می دهند. همین ممکن است باعث شود تبادل اطلاعات بین شما و آن ها در حد مطلوب نباشد.  همچنین ممکن است حواس شان نباشد که باید شما را مدام در جریان روند کارتان قرار دهند. اگر آن ها را مدام چک نکنید، باعث می شود زمان اتمام پروژه به تاخیر بیافتد یا محصول نهایی با آن چه در ذهن شماست، متفاوت باشد. شما مدیر پروژه و صاحب این کسب و کار هستید و این شمایید که باید همه چیز را هدایت کنید و در مسیر درست نگه دارید؛ نه برنامه نویس ها.

من در گذشته در انجام این کار ضعیف عمل کردم. بدون این که توسعه دهندگان ام را مرتب چک کنم، اجازه دادم هرچقدر زمان لازم دارند برای انجام کار من صرف کنند. بعدها یاد گرفتم که در طول روند قیمت گیری از آن ها بخواهم زمان و مراحل انجام کار را مشخص کنند. این کار کمک می کرد قبل از این که کار شروع شود و حتی یک خط کد نوشته شود،  بدانم در هر مرحله، اپ من چه شکلی خواهد بود و چطور کار خواهد کرد. من در فواصل زمانی معین کار آن ها را چک می کنم تا ببینم کجای کار هستند و کدام قسمت ها احتیاج به بهینه سازی دارند. سپس به عقب برمی گردیم و تمام مراحل را دوباره چک می کنیم. اکثر برنامه نویس ها در طول طراحی و توسعه به جلسات تکرار و بازگویی مطالب نیاز دارند و من تا وقتی که از هر مرحله ی کار کاملا راضی نباشم، پولی بابت ا ش پرداخت نمی کنم. نگذارید هواپیمای تان برای مدت زیادی از مسیر خارج شود؛ وگرنه ممکن است عاقبت سر از قطب جنوب و آب یخ در بیاورید!

به آهستگی استخدام و به سرعت اخراج کنید

همین که تجربه ی انتشار چند اپ را کسب کردید و شرایط با برنامه نویس یا گروه توسعه دهنده تان بر وفق مراد بود، شاید تصمیم گرفتید که یک نفر را به طور تمام وقت استخدام کنید. از طرفی انعطافی که در قراردادهای مقاطعه کاری دیده می شود، فوق العاده است. از طرف دیگر، ریسک این که مشتریان دیگر آن ها را استخدام کنند و برای چند ماه آن ها را به طور تمام وقت درگیر پرو ژه ی خودشان کنند، هم زیاد است.

به محض این که حس کردید از کار برنامه نویس خاصی راضی هستید و اوضاع مالی هم روبه راه است، جذب ا ش کنید. من چند نفر را دارم که در بازبینی های ماهیانه ام، همیشه نگه شان می دارم. آن ها می دانند که من هرماه با آن ها حداقل پول ممکن را خرج می کنم و در عوض، آن ها پروژه ام را در اولویت می گذارند.

اگر متوجه مشکلاتی از قبیل بی مسوولیتی، شلخته کاری و بی برنامگی شدید، سریعا جلوی ضرر را بگیرید و اخراج شان کنید. وگرنه، باری به دوش شرکت تان می شوند. مثل هر تمام شدن دیگری، شما باید دوستانه برخورد کنید. این فقط تجارت است و شما قطعا نمی خواهید، کسانی که سرمایه تان دست آن هاست را عصبانی کنید.

بهترین راه برای بیرون کردن برنامه نویس ها این است که برای شان توضیح بدهید که آن ها توقعات شما را برآورده نکردند و شما می خواهید به همکاری تان با ایشان خاتمه دهید. هرقدر از کارتان را که ممکن است نجات بدهید. این کار را بکنید، و دست مزد برنامه نویس را عادلانه محاسبه کنید. اما روند حرکت تان کند نشود و از این جریان درس بگیرید.

چطور اپلیکیشن های تان را امتحان کنید

تبریک می گویم. شما تمام مراحل توسعه را پشت سر گذاشتید و حالا اپ تان آماده است. قبل از این که این موفقیت را جشن بگیرید، باید چند کار مهم و اساسی انجام دهید. اگر یک خانه ساخته بودید، قبل از امضای تحویل کار، همه چیز  را سر جای خودشان و کامل شده می خواستید. حتما قسمت های اساسی خانه را کنترل می کردید. مثل سقف و همه ی ریز و درشت خانه را چک می کردید. درست مثل یک شی فاخر و ارزشمند یا تزیینی. همین کار را هم باید با اپ تان هم انجام بدهید.

برای شروع، اپ شما باید همان طور که انتظارش را دارید اجرا بشود. پوشه ی طراحی اولیه تان را دم دست بگذارید و تمام جزییات را چک کنید. هیچ وقت کنترل قسمتی را فقط به این خاطر که دفعه ی قبل چک ا ش کردید و کار می کرده است، از قلم نیاندازید. هر قسمت را چند بار چک کنید؛ خصوصا قبل از انتشار اپ. در این مرحله زیاد مکث نکنید؛ چرا که به عنوان سازنده ی اپ خودتان، خوب می دانید که هر چیز چطور باید کار کند. این ممکن است برای دیگران معنایی نداشته باشد؛ اما برای خودتان چرا.

,[categoriy]

اگر برای یک شرکت بزرگ توسعه گر کار کرده باشید، پس یک تیم از مهندسان با درآمد بالا در اختیار داشته اید که اپ شما را حسابی زیر و رو کنند. اما به عنوان یک اپ آفرین تنهای مستقل، احتمالا چنین منابعی در اختیار ندارید. اما، می توانید همین کار را از طریق منابعی که همه ی ما داریم انجام دهید: طرح دوستان و خانواده. کار شما این است که هرکسی را که می شناسید، از مادر بزرگ 75 ساله تا خواهرزاده ی 12 ساله تان بخواهید، اپ شما را امتحان کنند.

زمانی که صرف تست کردن اپ تان می کنید بسیار مهم است؛ زیرا شما خواهید دید که مشتریان چطور از آن استفاده می کنند، چه چیز برای شان آسان و کدام قسمت برای شان گنگ است. آن ها سوال هایی خواهند داشت که برای خودتان پیش نیامده؛ چون شما اپ را طراحی کرده اید و همه چیز برای تان واضح و شفاف است.

بی مقدمه اپ را به آن ها نشان بدهید و چیزی شبیه “هی، این را امتحان کن!” به آن ها بگویید. اصلا نگویید که آن اپ شماست، چطور کار می کند یا کارش چیست. همان طور که آن ها را زیر نظر دارید که دارند اپ شما را امتحان می کنند، کم ترین اطلاعات ممکن را به آن ها بدهید. این تجربه شبیه همانی است که مشتری واقعی شما خواهد داشت؛ چرا که شما آن جا نخواهید بود تا مسایل را به آن ها توضیح دهید. آن ها را هنگامی که دارند با اپ شما کار می کنندT نگاه کنید و از خودتان این سوال ها را بپرسید:

1. آیا گیج شدند؟

2. آیا در مرحله ای گیر کردند؟

3. آیا غرغر میکنند؟

4. آیا از اپ همان طور که شما می خواهید استفاده می کنند؟

5. آیا به دلیل این که به طور متفاوتی از اپ استفاده کردند، ایرادی از کارتان پیدا کردند؟ (اصطلاحا باگ هم گفته می شود)

6. آیا سرگرم شده اند؟

7. آیا برای بهتر شدن اپ پیشنهاداتی دارند؟ اگر بله، چه پیشنهادی؟

از آن ها بخواهید در مورد تجربه ی کار کردن شان با اپ شما صحبت کنند. اگر ندانند که اپ شماست حتما بیش تر صادق خواهند بود. اگر چیزی شنیدید که دوست نداشتید، به تان بر نخورد. این بازخوردها فوق العاده با ارزش هستند. هر پاسخ و عکس العمل را به دقت ارزیابی کنید تا بفهمید آیا اپ تان مشکلی دارد یا نه. از خودتان این سوال ها را بپرسید:

1. آیا کاربرهای دیگر هم مشکلات مشابهی دارند؟ اگر بله، چطور می توانید آن ها را برطرف کنید؟

2. آیا بهتر است جای بعضی چیزها را در اپ تغییر دهید؟

3. آیا برای بهتر دیده شدن باید بعضی از رنگ ها را تغییر دهید؟

4. آیا اضافه کردن “راهنمای استفاده” مفید است؟

5. آیا باید جهت یابی را اصلاح کنید؟

من یکی از اپ های اخیرم را به دوست ام جیسون نشان دادم. تمام مدتی که با اپ کار می کرد یک مشکل کوچک داشت: “چاد، این خیلی خوب و جالب است؛ اما من چطور می توانم به منوی اصلی برگردم؟”

من گفتم: “همان جاست”. و او پرسید ” کجا؟”. و آن جا بود که فهمیدم دکمه ی بازگشت هم رنگ زمینه و کوچک است. به همین خاطر او متوجه نمی شد که یک دکمه آن جاست و من فهمیدم که بقیه هم همین مشکل را خواهند داشت. همان 10 دقیقه که من اپ را به او نشان دادم کافی بود تا من این نکته را بفهمم.

بعد از این که بازخوردهای مختلف را یادداشت کردید، از برنامه نویس های تان بخواهید این مشکلات را برطرف یا تغییرات لازم را اعمال کنند. شما باید مطمئن باشید که اپ شما روی همه ی مدل های آیفون، آیپاد تاچ و شاید هم آیپد کار کند. اپل به نوآوری ها و تولید محصولات جدید سالانه اش، ادامه خواهد داد. اپ شما هرچه روی دستگاه های بیش تری کار کند، بهتر است. این چیزی است که شما باید اول کار با برنامه نویس های تان در میان بگذارید. مطمئن شوید آن ها اپ را برای دستگاه های مختلف می سازند.

بازهم، شما باید اپ تان را روی تمام دستگاه ها امتحان کنید؛ اما وقتی شکارتان را شروع کرده باشید، این غیرممکن است. در ابتدا این وظیفه برنامه نویس های تان است که اپلیکیشن تان را روی تمام دستگاه ها امتحان کنند. من از برنامه نویس های ام می خواهم لیستی از ویژگی ها و جزییاتی که باید کنترل کنم و در صورت نیاز اصلاح شوند را به من بدهند. من هر کدام از آن ها را مدام چک می کنم تا وقتی که همه چیز همان طور که باید، کار کند.

تست کردن و برطرف کردن باگ ها هم مثل مراحل طراحی و توسعه، چندین جلسه کار خواهند برد. این همه ی قسمت های روند تولید بود. از اپ TestFlight استفاده کنید تا برای نصب ورژن امتحانی اپ تان زمان زیادی از دست ندهید. بالاخره شما تغییرات را انجام می دهید و اپ را برای انتشار به اپ استور می فرستید.

برای انتشار اولین اپ های تان در اپ استور، اگر برنامه نویس تان یا کس دیگری از اعضا گروه، باشد که کمک کند، ایده ی خوبی ا ست. هیچ وقت اطلاعات تان برای ورود به پورتال توسعه دهنده ی آنلاین را به برنامه نویس تان یا هیچ کس دیگری ندهید. بهترین راه برای کمک گرفتن استفاده از اسکایپ یا GoToMeeting است تا ضمن این که صفحه ی مانیتورتان را به آن ها نشان می دهید، به شما کمک کنند تا این فرآیند انجام شود. همان طور که کسب و کارتان بزرگ تر می شود، ممکن است بخواهید یک نفر از اعضای گروه تان را به عنوان نماینده ی خودتان انتخاب کنید.

به خاطر داشته باشید، همه ی این ها خیلی آسان تر از چیزی است که به نظر می رسد. حالا که اهمیت و روند تشکیل دادن یک گروه توسعه دهنده را متوجه شدید، وقت آن است که همین جا این فصل را تمام کنم تا کمی استراحت کنید. در فصل بعد، درباره ی مهم ترین کارتان، یعنی بازاریابی برای اپ های تان صحبت خواهیم کرد.

,[categoriy]

مطالب مرتبط:

– مقدمه

– فصل اول/بخش اول

– فصل اول/بخش دوم

– فصل اول/بخش سوم

– فصل دوم/بخش اول

– فصل دوم/بخش دوم

– فصل دوم/بخش سوم

– فصل سوم/ بخش اول

– فصل سوم/ بخش دوم

– فصل سوم/ بخش سوم

– فصل چهارم/ بخش اول

– فصل چهارم/ بخش دوم

– فصل چهارم/ بخش سوم

– فصل پنجم/ بخش اول

– فصل پنجم/ بخش دوم

منبع :

امپراطوری اپ (فصل پنجم/ بخش سوم/ پایانی) گردآوری توسط بخش ترفند نرم افزار، آموزش نرم افزار، ترفندهای نرم افزار سایت آکاایران

اخبار اکاایران

تبلیغات