کارکنان خلاق بسیاری در LANIT-Integration وجود دارد. ایده های محصولات و پروژه های جدید به معنای واقعی کلمه در هوا معلق هستند. گاهی اوقات تشخیص جالب ترین آنها می تواند بسیار دشوار باشد. بنابراین، ما با هم روش خود را توسعه دادیم. این مقاله را در مورد نحوه انتخاب بهترین پروژه ها و اجرای آنها بخوانید.
در روسیه و در کل جهان، تعدادی از فرآیندها در حال انجام است که منجر به دگرگونی بازار فناوری اطلاعات می شود. به لطف افزایش قدرت محاسباتی و ظهور سرور، شبکه و سایر فناوری های مجازی سازی، بازار دیگر نیازی به مقدار زیادی سخت افزار ندارد. فروشندگان به طور فزاینده ای ترجیح می دهند مستقیماً با مشتریان کار کنند. بازار فناوری اطلاعات در حال تجربه رونق برون سپاری در تمام اشکال آن است، از برون سپاری کلاسیک گرفته تا موج جدید برون سپاری ها - «ارائه دهندگان ابری». نگهداری و پیکربندی سیستم‌ها و عناصر زیرساخت بسیار آسان‌تر می‌شود. کیفیت نرم افزار هر سال در حال افزایش است و وظایف یکپارچه ساز در حال تغییر است.
چگونه با ایده ها کار می کنیم
جهت راه اندازی محصول در بیش از یک سال است که وجود دارد. هدف اصلی ما ایجاد محصولات جدید و عرضه آنها به بازار است. اولین چیزی که با آن شروع کردیم، سازماندهی فرآیند تولید محصولات بود. ما روش های بسیاری را، از کلاسیک گرفته تا هیپ، مطالعه کرده ایم. با این حال، هیچ یک از آنها پاسخگوی نیازهای ما نبودند. سپس تصمیم گرفتیم متدولوژی Lean Startup را به عنوان مبنا قرار دهیم و آن را با وظایف خود تطبیق دهیم. استارتاپ ناب یک نظریه کارآفرینی است که توسط اریک ریس ایجاد شده است. این بر اساس اصول، رویکردها و شیوه های مفاهیمی مانند تولید ناب، توسعه مشتری و روش توسعه انعطاف پذیر است.
در مورد رویکرد مستقیم به مدیریت توسعه محصول: ما چرخ را دوباره اختراع نکردیم، بلکه از یک روش توسعه موجود استفاده کردیم ، خلاقیت را اضافه کرد و اکنون با خیال راحت می توان آن را SCRUM-WATERFALL-BAN نامید. SCRUM، علیرغم انعطاف پذیری، یک سیستم بسیار سفت و سخت است و برای مدیریت تیمی که تنها مسئول یک محصول/پروژه است، مناسب است. همانطور که می دانید، تجارت کلاسیک "ادغام" شامل اختصاص متخصصان فنی تمام وقت برای کار بر روی یک پروژه نیست (استثناهایی وجود دارد، اما بسیار به ندرت)، زیرا علاوه بر کار بر روی محصولات، همه مشغول پروژه های فعلی هستند. از SCRUM ما تقسیم کار را به دوی سرعت، گزارش روزانه، گذشته نگر و نقش ها در نظر گرفتیم. ما Kanban را برای جریان کار خود انتخاب کردیم و به خوبی با سیستم ردیابی کار موجود ما ادغام شد. ما کار خود را با ادغام یکپارچه در نظم موجود ساختاربندی کردیم.
یک محصول قبل از ورود به بازار 5 مرحله ایده، انتخاب، مفهوم، MVP (توضیحات بیشتر در زیر) و تولید را طی می کند.
فکر
در این مرحله چیزی زودگذر وجود دارد - یک ایده. در حالت ایده آل، ایده ای برای حل یک مشکل موجود یا مشکل مشتری. ما هیچ کمبودی در ایده نداریم. طبق برنامه اولیه، آنها باید توسط کارکنان بخش های فنی تولید شوند. برای اینکه یک ایده برای توسعه بیشتر پذیرفته شود، نویسنده باید "الگوی طراحی ایده" را پر کند. فقط چهار سوال وجود دارد: چیست؟ برای چی؟ چه کسی به این نیاز دارد؟ و اگر محصول ما نیست، پس چیست؟
انتخاب
به محض اینکه الگوی تکمیل شده به دست ما می رسد، مراحل پردازش و انتخاب آغاز می شود. مرحله انتخاب پرکارترین مرحله است. در این مرحله، فرضیه‌های مشکلات شکل می‌گیرد (بیهوده در پاراگراف قبل ذکر کردم که ایده‌آل باید مشکل مشتری را حل کند) و ارزش محصول. یک فرضیه مقیاس شکل می گیرد، یعنی. چگونه کسب و کار ما قرار است رشد کند و رونق بگیرد. مشکلات و مصاحبه های تخصصی با مشتریان بالقوه انجام می شود تا تأیید اولیه ای را ارائه دهیم که ما قصد داریم چیزی مورد نیاز را تولید کنیم. حداقل 10-15 مصاحبه برای نتیجه گیری در مورد نیاز محصول لازم است.
در صورت تایید فرضیه ها، تحلیل مالی اولیه انجام می شود، حجم تقریبی سرمایه گذاری و سود احتمالی سرمایه گذار ارزیابی می شود. در نتیجه این مرحله سندی به نام Lean Canvas متولد و به مدیریت ارائه می شود.
مفهوم
در این مرحله حدود 70 درصد ایده ها حذف می شوند. اگر مفهوم مورد تایید قرار گیرد، مرحله توسعه ایده آغاز می شود. عملکرد محصول آینده شکل می گیرد، مسیرهای اجرا و راه حل های فنی بهینه تعیین می شود و طرح کسب و کار به روز می شود. نتیجه این مرحله یک مشخصات فنی برای توسعه و یک مورد تجاری دقیق است. در صورت موفقیت به مرحله MVP یا MVP می رویم.
MVP یا MVP
MVP یک محصول حداقل قابل دوام است. آن ها محصولی که به طور کامل توسعه نیافته است، اما در حال حاضر می تواند ارزش داشته باشد و عملکرد خود را انجام دهد. ضروری است که در این مرحله از توسعه، بازخورد کاربران واقعی را جمع آوری کرده و تغییراتی ایجاد کنیم.
تولید
و آخرین مرحله تولید است. بیش از 5 درصد محصولات به این مرحله نمی رسند. این 5 درصد فقط شامل مهمترین، ضروری ترین، ماندگارترین و کاربردی ترین محصولات می شود.
ما ایده های زیادی داریم و قبلاً یک نمونه کار بزرگ جمع آوری کرده ایم. ما هر ایده را تجزیه و تحلیل می کنیم و هر کاری انجام می دهیم تا مطمئن شویم که به مرحله نهایی می رسد. بسیار خوشحال کننده است که همکاران ما نسبت به مسیر تحقیق و توسعه ما بی تفاوت نماندند و در توسعه و اجرای محصولات و راه حل ها مشارکت فعال داشته باشند.
چگونه ما LANBIX را ساختیم
بیایید به ایجاد یک محصول با استفاده از یک مثال واقعی نگاه کنیم - محصول LANBIX. این یک نرم‌افزار و سیستم سخت‌افزاری «جعبه‌ای» است که برای نظارت بر زیرساخت‌های کوچک فناوری اطلاعات و هشدار سریع تصمیم‌گیرندگان و کاربران تجاری در مورد نقص‌های کنترل شده از طریق ربات چت طراحی شده است. علاوه بر عملکرد نظارت، LANBIX دارای قابلیت Help Desk نیز می باشد. این محصول منحصر به بخش بازار مورد نظر ما است. این هم مزیت ماست و هم درد ما. اما اول از همه. من فوراً می گویم که LANBIX یک محصول زنده است (یعنی در توسعه آن نهایی نیست و در دور بعدی MVP قرار دارد).
بنابراین، مرحله اول ایده است. برای اینکه یک ایده متولد شود، به مشکلاتی نیاز دارید، و ما آنها را داشتیم، یا بهتر است بگوییم نه ما، بلکه دوستانمان. در زیر به چندین موقعیت واقعی که در حوزه های مختلف کسب و کار رخ داده است نگاه خواهیم کرد.
یک شرکت مدیریت کوچک دو خانه را در منطقه مسکو نگهداری می کند. پرسنل با رایانه شخصی حدود 15 نفر است. مدیر سیستم یک فریلنسر بازدیدکننده (پسر باهوش یکی از ساکنان دلسوز) است. به نظر می رسد که فعالیت های شرکت مدیریت ضعیف به IT وابسته است، اما ویژگی این تجارت گزارش ماهانه به بسیاری از مقامات است. دیسک سیستم رئیس شرکت (که طبق معمول نقش های زیادی را ترکیب می کند) فضای خالی تمام شده است. طبیعتاً این اتفاق ناگهانی نیفتاد؛ اخطار حدود 2 ماه معلق بود و مدام نادیده گرفته می شد. اما یک به‌روزرسانی رسید، سیستم‌عامل به‌روزرسانی شد و، خوشبختانه، در اواسط به‌روزرسانی متوقف شد و قبل از مرگ از یک دیسک مشغول شکایت کرد. کامپیوتر وارد یک راه اندازی مجدد چرخه ای شد. در حالی که در حال حل مشکل و دریافت گزارش بودیم، مهلت گزارش را از دست دادیم. به نظر می رسد که یک نقص پیش پا افتاده مشکلات مختلفی را ایجاد کرده است: از ضرر تا دعوی قضایی و مسئولیت اداری.
حادثه مشابهی در یک هلدینگ بزرگ رخ داد که بسیاری از شرکت های کوچک را با یک سرویس پشتیبانی فنی واحد برای کل دفتر متحد کرد. در یکی از بخش ها، کامپیوتر حسابدار ارشد خراب شد. مدت‌ها بود که می‌دانستند ممکن است خراب شود (کامپیوتر به شدت کاهش می‌یابد و داغ می‌شود)، اما حسابدار ارشد هرگز نتوانست درخواستی برای پشتیبانی فنی ارسال کند. طبیعتاً دقیقاً در روز پرداخت خراب شد و کارمندان بخش چندین روز بدون پول بودند.
یک تجارت کوچک در تجارت عمده فروشی کوچک دارای یک وب سایت فروش بود که بر روی یک پلت فرم خارجی میزبانی می شد. از در دسترس نبودن آن به صورت تلفنی از یک مشتری معمولی مطلع شدیم. در زمان تماس، سایت حدود سه ساعت از کار افتاده بود. یکی دو ساعت دیگر برای یافتن مسئول سایت و دو ساعت دیگر طول کشید تا مشکل برطرف شود. بر این اساس، سایت تقریباً در تمام روز کاری در دسترس نبود. به گفته مدیر بازرگانی شرکت، این خرابی حدود 1 میلیون روبل برای آنها هزینه داشت.
من خودم زمانی که به یک قرار ملاقات در کلینیک آمدم و مجبور شدم به ثبت نام VHI بروم با وضعیت مشابهی روبرو شدم. آنها نتوانستند من را به دلیل بی اهمیتی به دکتر بفرستند - صبح یک افزایش برق رخ داد و پس از حادثه خدمات پستی آنها و خدمات خاصی برای برقراری ارتباط با شرکت بیمه کار نکرد. در پاسخ به سوال من که ادمین های شما کجا هستند به من گفتند که ادمین آنها هفته ای یک بار می آید و به آنها سر می زند. و حالا (در آن زمان ساعت 16:00 بود) او تلفن را بر نمی دارد. حداقل 7 ساعت ارتباط کلینیک با دنیای بیرون قطع بود و نمی توانست خدمات پولی ارائه دهد.
وجه اشتراک همه این موارد چیست؟ قطعاً می شد از قبل از همه مشکلات جلوگیری کرد. با پاسخ به موقع از طرف افراد IT، آسیب می تواند کاهش یابد. این امر در صورتی امکان پذیر خواهد بود که علائم اولیه به درستی توسط کاربران تفسیر شود.
ما فرضیه های مشکل را شناسایی کرده ایم:
- زیان های پولی و اعتباری قابل توجه به دلیل سرعت کم پاسخ به نقص در زیرساخت فناوری اطلاعات؛
- تفسیر نادرست از علائم اولیه یک نقص توسط کاربران
مشتری چه کاری می تواند با آنها انجام دهد، و چگونه می توان از موقعیت های مشابه در آینده جلوگیری کرد؟ گزینه های زیادی وجود ندارد:
- یک مدیر سیستم با مهارت بالا را استخدام کنید و او را وادار کنید که با وجدان کار کند.
- تعمیر و نگهداری فناوری اطلاعات را به یک شرکت خدمات تخصصی برون سپاری کنید.
- به طور مستقل یک سیستم نظارت و گزارش خطا را پیاده سازی کنید.
- ارائه آموزش به کاربران/کارکنان تجاری در زمینه مبانی سواد کامپیوتری.
بیایید به گزینه سوم بسنده کنیم. بیایید یک سیستم نظارتی را به کسانی که به دلایل مختلف از آن استفاده نمی کنند ارائه دهیم.
انحراف غزلی. سیستم های مختلف برای نظارت بر خدمات فناوری اطلاعات در بازار سازمانی برای مدت طولانی مورد استفاده قرار گرفته اند و مزایای آنها مورد بحث نیست. من با نمایندگان شرکت های بزرگ صحبت کردم، به چگونگی ایجاد رابطه بین تجارت و فناوری اطلاعات نگاه کردم. مدیر فنی یک شرکت بزرگ ماشین سازی، تعمیر و نگهداری زیرساخت فناوری اطلاعات را به یک شرکت خارجی برون سپاری کرده است، اما خودش در مورد همه مسائل آگاه است. در دفتر او یک صفحه نمایش سیستم مانیتورینگ بزرگ با نشانگرهای وضعیت خدمات فناوری اطلاعات آویزان است. بحرانی ترین آنها در سیستم گنجانده شده است. مدیر فنی هر لحظه می تواند بفهمد که زیرساخت ها در چه وضعیتی است، چه اتفاقی می افتد، مشکل کجاست، آیا به مسئولین اطلاع داده شده و آیا مشکل حل می شود یا خیر.
داستان های ذکر شده در بالا باعث شد تیم ما در مورد چگونگی ایجاد یک سیستم نظارتی بهینه برای شرکت های کوچک فکر کند. در نتیجه، LANBIX متولد شد - یک سیستم نظارتی که می تواند توسط هر کسی بدون هیچ دانش IT مستقر شود. هدف اصلی سیستم ساده است، مانند همه سیستم‌هایی که با هدف افزایش تداوم و در دسترس بودن - کاهش ضررهای پولی و سایر موارد در صورت خرابی برنامه‌ریزی نشده است. این دستگاه طوری طراحی شده است که زمان بین «چیزی خراب است» و «مشکل برطرف شده است» را به حداقل کاهش دهد.
برای تایید فرضیه ها، مصاحبه های مسئله ای انجام شد. نمی‌توانستم تصور کنم که مردم چقدر حاضرند بدون تلاش برای فروش به آنها بگویند. هر مکالمه حداقل 1,5 ساعت به طول انجامید و ما اطلاعات زیادی را برای توسعه بیشتر دریافت کردیم.
بیایید نتایج این مرحله را خلاصه کنیم:
- درک مشکل وجود دارد،
- درک ارزش - وجود دارد،
- یک ایده برای راه حل وجود دارد.
مرحله دوم مفصل تر بود. بر اساس نتایج آن، ما باید به مدیریت که اساسا نقش یک سرمایه گذار را ایفا می کند، یک مورد تجاری (همان Lean Canvas) ارائه می کردیم تا در مورد سرنوشت آینده محصول تصمیم گیری کند.
ما با تحقیقات بازار و تجزیه و تحلیل رقابتی شروع کردیم تا بفهمیم چه کسی، چه کاری و از همه مهمتر در این بازار چگونه کار می کند.
به شرح زیر معلوم شد.
- هیچ سیستم مانیتورینگ جعبه ای آماده ای در بازار برای بخش ما (کسب و کار کوچک) وجود ندارد، به استثنای یک یا سه مورد، که به دلایل واضح در مورد آنها صحبت نمی کنم.
- رقبای اصلی ما، به اندازه کافی عجیب، مدیران سیستم با اسکریپت های نوشته شده خانگی و "افزونه ها" به سیستم های نظارت منبع باز هستند.
- استفاده از سیستم های مانیتورینگ منبع باز یک مشکل آشکار وجود دارد. یک سیستم وجود دارد، حجم عظیمی از اطلاعات در مورد نحوه کار و تغییر سیستم مطابق با نیازهای شما وجود دارد. از میان مدیرانی که با آنها مصاحبه کردم، بسیاری اعتراف کردند که شایستگی کافی برای اجرای ایده های خود را ندارند. اما از ترس اخراج نمی توانند این را به مدیریت بپذیرند. معلوم می شود که یک دور باطل است.
سپس به تجزیه و تحلیل نیازهای مشتریان بالقوه خود پرداختیم. ما بخشی از سازمان‌های کوچک را برای خود شناسایی کرده‌ایم که به دلایلی خدمات فناوری اطلاعات خود را ندارند، جایی که یک مدیر سیستم ورودی، یک فریلنسر یا یک شرکت خدماتی مسئول IT است. این طرف IT نبود که تصمیم گرفت وارد شود، بلکه طرف تجاری بود که به بنیانگذاران و صاحبان مشاغل ابزاری برای بهبود کیفیت خدمات زیرساخت فناوری اطلاعات ارائه می دهد. محصولی که باید به مالکان کمک کند تا کسب و کار خود را ایمن کنند، اما در عین حال به افرادی که مسئولیت IT را بر عهده دارند، کار اضافه می کند. محصولی که ابزاری برای نظارت بر کیفیت پشتیبانی فناوری اطلاعات در اختیار کسب و کارها قرار می دهد.
در نتیجه پردازش داده های دریافتی، اولین لیست الزامات (نوعی عقب ماندگی خشن) برای محصول آینده متولد شد:
- سیستم نظارت باید بر اساس یک راه حل منبع باز و در نتیجه ارزان باشد.
- نصب آسان و سریع؛
- نباید به دانش خاصی در IT نیاز داشته باشد، حتی یک حسابدار (به هیچ وجه نمی خواستم نمایندگان این حرفه را توهین کنم) باید بتواند سیستم را مستقر و پیکربندی کند.
- باید به طور خودکار اشیاء را برای نظارت در شبکه شناسایی کند.
- باید به طور خودکار (و در حالت ایده آل به صورت خودکار) عوامل نظارتی را نصب کند.
- باید قادر به نظارت بر خدمات خارجی، حداقل یک سیستم CRM و یک وب سایت فروش باشد.
- باید هم به کسب و کار و هم به مدیر سیستم از مشکلات اطلاع دهد.
- درجه عمق و "زبان" هشدارها باید برای مدیر و کسب و کار متفاوت باشد.
- سیستم باید بر روی سخت افزار خود عرضه شود.
- آهن باید تا حد امکان در دسترس باشد.
- سیستم باید تا حد امکان مستقل از عوامل خارجی باشد.
سپس، سرمایه گذاری در توسعه محصول (شامل هزینه های نیروی کار برای کارکنان بخش فنی) محاسبه شد. طرحی از مدل کسب و کار تهیه شد و اقتصاد واحد محصول محاسبه شد.
نتیجه مرحله:
- عقب ماندگی محصول در سطح بالا؛
- یک مدل کسب و کار فرموله شده یا فرضیه مقیاس که هنوز در عمل آزمایش نشده است.
بیایید به مرحله بعدی برویم - مفهوم. در اینجا ما به عنوان مهندس، خود را در عنصر بومی خود می یابیم. "لیست های آرزو" وجود دارد که به اجزا / زیرسیستم ها / ویژگی ها تجزیه می شوند، سپس به مشخصات فنی / داستان های کاربر و سپس به یک پروژه و غیره تبدیل می شوند. من به جزئیات در مورد روند آماده سازی مجموعه ای از گزینه های جایگزین نمی پردازم؛ بیایید مستقیماً به الزامات و روش های انتخاب شده برای اجرای آنها برویم.
تقاضا
تصمیم
- این باید یک سیستم نظارت باز باشد.
ما یک سیستم مانیتورینگ منبع باز داریم.
- سیستم باید ساده و سریع نصب شود.
- نباید به دانش IT خاصی نیاز داشته باشد. حتی یک حسابدار باید بتواند سیستم را مستقر و پیکربندی کند.
ما یک سیستم نصب شده را ارائه می دهیم به طوری که کاربر فقط باید دستگاه را روشن کند و کمی آن را مانند روتر پیکربندی کند.
بیایید تعامل با دستگاه را به چیزی ساده و قابل درک برای همه ببندیم.
بیایید چت بات خودمان را برای یکی از مسنجرهای معروف بنویسیم و تمام تعاملات با سیستم را به آن منتقل کنیم.
سیستم باید:
- شناسایی خودکار اشیاء مورد نیاز برای نظارت در شبکه؛
- نصب خودکار عوامل نظارت؛
- قادر به نظارت بر خدمات خارجی، حداقل یک سیستم CRM و یک وب سایت فروش باشید.
ما افزونه هایی را برای سیستم نظارت برای موارد زیر می نویسیم:
- تشخیص خودکار اشیا؛
- نصب خودکار عوامل؛
- نظارت بر در دسترس بودن خدمات خارجی
سیستم باید:
- هم به کسب و کار و هم به مدیر سیستم از مشکلات اطلاع دهید.
- قادر به نظارت بر خدمات خارجی، حداقل یک سیستم CRM و یک وب سایت فروش باشید. درجه عمق و "زبان" اعلان ها باید برای مدیر و کسب و کار متفاوت باشد.
- سیستم نباید به دانش IT خاصی نیاز داشته باشد، حتی یک حسابدار باید بتواند سیستم را مستقر و پیکربندی کند.
- بیایید انواع مختلف اعلان ها را برای انواع مختلف کاربران اضافه کنیم. آنها در زیر و بم و عمق متفاوت هستند. یک کاربر تجاری اعلان هایی مانند "همه چیز خوب است، اما کامپیوتر ایوانف به زودی می میرد" دریافت می کند. مدیر یک پیام کامل در مورد خطا دریافت می کند، چه کسی، چگونه و چه اتفاقی افتاده یا ممکن است رخ دهد.
- بیایید قابلیت استفاده از نامه یک فرد مسئول اضافی را اضافه کنیم تا در صورت خرابی پیامی دریافت کند.
- بیایید تعامل با ارائه دهندگان خدمات خارجی را بر اساس ارسال ایمیل با متن از پیش آماده شده اضافه کنیم، زیرا این ایمیل است که باعث بروز این حادثه می شود.
- تمام تعاملات با سیستم به یک ربات چت متصل می شود؛ ارتباط به سبک گفتگو انجام می شود.
موارد اضافی:
- بیایید عملکرد "چت با مدیر" را اضافه کنیم تا کاربر بتواند پیامی را برای توضیح مستقیم مشکل به مدیر ارسال کند.
- سیستم باید روی سخت افزار خودش عرضه شود.
- آهن باید در دسترس باشد.
- سیستم باید تا حد امکان مستقل از محیط باشد.
- بیایید یک کامپیوتر آماده و ارزان Raspberry PI بگیریم.
- ما یک برد منبع تغذیه بدون وقفه طراحی خواهیم کرد.
- بیایید یک مودم اضافه کنیم تا مستقل از وضعیت شبکه محلی باشد.
- ما یک ساختمان زیبا طراحی خواهیم کرد.
ما اکنون سه زیرسیستم با الزامات و چشم انداز خاص خود برای اجرای آنها داریم:
- زیر سیستم سخت افزاری؛
- زیر سیستم نظارت؛
- زیرسیستم تعامل با کاربر
ما یک طرح اولیه برای زیرسیستم سخت افزاری ایجاد کردیم. بله بله! با زیر پا گذاشتن تمام قوانین چابک، سندی را تهیه کردیم، زیرا کارخانه های تولیدی با اسناد کار می کنند. برای زیرسیستم‌های باقی‌مانده، کاربران (افراد) را شناسایی کردیم، داستان‌های کاربران را آماده کردیم و وظایفی را برای توسعه نوشتیم.
این مرحله مفهوم را به پایان می رساند و نتیجه این است:
- پروژه برای یک پلت فرم سخت افزاری؛
- چشم انداز فرموله شده در قالب داستان های کاربر برای دو زیرسیستم باقی مانده.
- یک نمونه اولیه نرم افزار پیاده سازی شده به عنوان یک ماشین مجازی.
- یک نمونه اولیه از سخت افزار، اجرا شده در قالب یک پایه، که در آن راه حل های سخت افزاری در واقع برای استحکام آزمایش شدند.
- تست انجام شده توسط مدیران ما
مشکلات این مرحله بیشتر سازمانی و مربوط به عدم آگاهی کادر مهندسی در ابعاد حقوقی و حسابداری فروش بود. آن ها این یک چیز است که بفهمیم چه چیزی و چگونه بفروشیم، و کاملاً چیز دیگری است که با یک ماشین حقوقی بی رحم روبرو شویم: ثبت اختراع، وظایف توسعه، ثبت نام، EULA و خیلی چیزهای دیگر که ما، به عنوان افراد خلاق، در ابتدا آنها را در نظر نگرفتیم.
هنوز مشکلی وجود نداشت، بلکه یک مشکل مرتبط با طراحی محفظه ها بود. تیم ما فقط از مهندسان تشکیل شده است، بنابراین اولین نسخه کیس توسط متخصص الکترونیک ما از پلکسی گلاس ساخته شده است.
بدنه، به بیان ملایم، بحث برانگیز به نظر می رسید، به خصوص برای عموم، که توسط فناوری مدرن خراب شده بود. البته در بین نسل قدیمی "کولیبین ها" خبره هایی وجود داشت - این ساختمان احساسات نوستالژیک را در آنها برانگیخت. تصمیم به ساخت و طراحی مجدد کیس گرفته شد، زیرا مورد قدیمی علاوه بر ایرادات زیبایی شناختی، ساختاری نیز داشت - پلکسی گلس مونتاژ و جداسازی دستگاه را به خوبی تحمل نمی کرد و تمایل به ترک خوردگی داشت. من در مورد تولید کیس بیشتر به شما خواهم گفت.
و اکنون به خط پایان نزدیک شده ایم - MVP. البته این محصول هنوز محصول نهایی تولید نشده است، اما در حال حاضر مفید و ارزشمند است. هدف اصلی این مرحله راه اندازی چرخه «ایجاد-ارزیابی-یادگیری» است. این دقیقا همان مرحله ای است که LANBIX در آن قرار دارد.
در مرحله "ایجاد"، دستگاهی ایجاد کردیم که عملکرد ذکر شده را انجام می دهد. بله، هنوز کامل نیست و ما به کار روی آن ادامه دادیم.
برگردیم به ساخت بدنه، یعنی. به وظیفه تبدیل دستگاه ما از نوستالژیک به مدرن. در ابتدا بازار را برای تولیدکنندگان کابینت و خدمات طراحی صنعتی جستجو کردم. اولاً، تعداد زیادی شرکت تولید کننده کیس در بازار روسیه وجود ندارد و ثانیاً، هزینه طراحی صنعتی در این مرحله بسیار زیاد است، حدود 1 میلیون روبل.
آنها برای طراحی با بخش بازاریابی ما تماس گرفتند؛ طراح جوان آماده آزمایش های خلاقانه بود. ما دیدگاه خود را از بدنه ترسیم کردیم (که قبلاً بهترین نمونه های ساخت بدنه را مطالعه کرده بودیم) و او نیز به نوبه خود آن را به یک اثر هنری تبدیل کرد. تنها چیزی که باقی می ماند تولید آن است. ما که به طراحی خود افتخار می کنیم، به شرکای خود روی آوردیم. مدیر عامل آنها فوراً با اشاره به مواردی که به روش انتخابی ما قابل تولید نبود، کاملاً رایگان، خیالات ما را در هم شکست. این کیس قابل تولید است و بدتر از اپل نخواهد بود، اما هزینه کیس سه تا چهار برابر گران‌تر از تمام قطعات الکترونیکی خواهد بود. پس از یک سری عملیات و تاییدیه ها، مسکن قابل ساختی را طراحی کرده ایم. بله، آنطور که ما برنامه ریزی کرده بودیم زیبا نیست، اما برای دستیابی به اهداف فعلی ایده آل است.
نتیجه مرحله: اولین دسته از دستگاه های آماده برای مبارزه و آزمایش.
و اکنون دشوارترین کار مرحله "ارزیابی" است و با محصول ما دقیقاً در این مرحله هستیم. ما فقط می توانیم بر اساس نتایج استفاده توسط مشتریان واقعی ارزیابی کنیم و هیچ فرضی در اینجا کار نمی کند. ما به آن «پذیرندگان اولیه» نیاز داریم تا بازخورد ارائه دهند و تغییراتی را در محصول ایجاد کنند که واقعاً مورد نیاز است. این سوال مطرح می شود: از کجا می توان مشتریان را جذب کرد و چگونه آنها را متقاعد کرد که در آزمایش شرکت کنند؟
از میان همه گزینه‌های ممکن، مجموعه‌ای از ابزارهای دیجیتال کلاسیک را انتخاب کردیم: صفحه فرود و کمپین تبلیغاتی در شبکه‌های اجتماعی.
این روند قبلاً راه اندازی شده است، اما هنوز برای صحبت در مورد نتایج زود است، اگرچه در حال حاضر پاسخ هایی وجود دارد و ما تأیید بسیاری از فرضیه های خود را دریافت کرده ایم. یک شگفتی خوشایند واکنش نمایندگان بخش های تجاری کاملاً متفاوت بود، بسیار بزرگتر از آنچه ما انتظار داشتیم. نادیده گرفتن معرفی های جدید احمقانه است و بر اساس نتایج مصاحبه ها تصمیم گرفته شد خط موازی LANBIX به نام LANBIX Enterprise راه اندازی شود. ما پشتیبانی از زیرساخت های توزیع شده، نظارت بر شبکه های Wi-Fi با عیب یابی و محلی سازی، و نظارت بر کیفیت کانال های ارتباطی را اضافه کرده ایم. شرکت های خدماتی بیشترین علاقه را به این راه حل نشان دادند. در عین حال، دستگاه هایی که قبلاً توسعه داده ایم نقش مهمی در عملکرد راه حل ها دارند.
بعد از این چه خواهد شد
آنچه در ادامه با LANBIX اصلی اتفاق خواهد افتاد بر اساس نتایج کمپین مشخص خواهد شد. اگر فرضیه های ما تأیید نشود، طبق روش ناب، بی رحمانه از شر آن خلاص می شویم یا به چیزی جدید تبدیل می شود، زیرا هیچ چیز بدتر از ساخت محصولی نیست که هیچ کس به آن نیاز ندارد. اما اکنون می توان گفت که کار انجام شده بیهوده نبوده و به لطف آن، یک شاخه کامل از محصولات موازی ظاهر شده است که ما فعالانه روی آن کار می کنیم. در صورت موفقیت، LANBIX از مرحله MVP به مرحله نهایی خواهد رفت و طبق قوانین کلاسیک قابل درک بازاریابی محصول توسعه خواهد یافت.
تکرار می کنم، اکنون می خواهیم پذیرندگان اولیه را پیدا کنیم، شرکت هایی که می توانند محصول ما را برای جمع آوری بازخورد نصب کنند. اگر علاقه مند به آزمایش LANBIX هستید، در نظرات یا پیام های خصوصی بنویسید.
منبع: www.habr.com