איך אנחנו עובדים עם רעיונות ואיך נולדה LANBIX

ישנם עובדים יצירתיים רבים ב-LANIT-Integration. רעיונות למוצרים ופרויקטים חדשים ממש תלויים באוויר. לפעמים זה יכול להיות מאוד קשה לזהות את המעניינים ביותר. לכן, יחד פיתחנו מתודולוגיה משלנו. קרא מאמר זה כיצד לבחור את הפרויקטים הטובים ביותר וליישם אותם.

ברוסיה, ובעולם כולו, מתרחשים מספר תהליכים המובילים לטרנספורמציה של שוק ה-IT. הודות לעלייה בכוח המחשוב והופעת טכנולוגיות וירטואליזציה של שרתים, רשת ושאר, השוק כבר לא זקוק לכמות גדולה של חומרה. ספקים מעדיפים יותר ויותר לעבוד עם לקוחות ישירות. שוק ה-IT חווה פריחה במיקור חוץ על כל צורותיו, ממיקור חוץ קלאסי ועד לגל החדש של מיקור חוץ – "ספקי ענן". מערכות תשתית ואלמנטים הופכים להרבה יותר קלים לתחזוקה והגדרה. איכות התוכנה גדלה מדי שנה ומשימותיו של האינטגרטור עוברות שינוי.

איך אנחנו עובדים עם רעיונות

כיוון אתחול המוצר פנימה "LANIT-אינטגרציה" קיים כבר למעלה משנה. המטרה העיקרית שלנו היא ליצור מוצרים חדשים ולהוציא אותם לשוק. הדבר הראשון שהתחלנו איתו היה ארגון תהליך יצירת המוצרים. למדנו מתודולוגיות רבות, מקלאסי ועד הייפ. עם זאת, אף אחד מהם לא ענה על הצרכים שלנו. ואז החלטנו לקחת את מתודולוגיית ה-Lean Startup כבסיס ולהתאים אותה למשימות שלנו. The Lean Startup היא תיאוריה של יזמות שנוצרה על ידי אריק ריס. הוא מבוסס על העקרונות, הגישות והפרקטיקות של מושגים כמו ייצור רזה, פיתוח לקוחות ומתודולוגיית פיתוח גמישה.

לגבי הגישה הישירה לניהול פיתוח מוצר: לא המצאנו את הגלגל מחדש, אלא יישמנו מתודולוגיית פיתוח שכבר קיימת SCRUM, הוספת יצירתיות, ועכשיו זה יכול להיקרא בבטחה SCRUM-WATERFALL-BAN. SCRUM, למרות גמישותה, היא מערכת קשיחה מאוד ומתאימה לניהול צוות האחראי על מוצר/פרויקט אחד בלבד. כפי שאתם מבינים, עסק ה"אינטגרציה" הקלאסי אינו כרוך בהקצאת מומחים טכניים במשרה מלאה לעבודה על פרויקט אחד (יש יוצאים מן הכלל, אך לעיתים רחוקות ביותר), שכן בנוסף לעבודה על מוצרים, כולם עסוקים בפרויקטים נוכחיים. מ-SCRUM לקחנו את חלוקת העבודה לספרינטים, דיווח יומי, רטרוספקטיבות ותפקידים. בחרנו ב-Kanban עבור זרימת המשימות שלנו והוא השתלב היטב במערכת מעקב המשימות הקיימת שלנו. בנינו את העבודה שלנו על ידי שילוב חלק בסדר הדברים הקיים.
לפני כניסתו לשוק, מוצר עובר 5 שלבים: רעיון, בחירה, קונספט, MVP (פרטים נוספים בהמשך) וייצור.

רעיון

בשלב הזה יש משהו חולף - רעיון. באופן אידיאלי, רעיון לפתרון בעיה קיימת או בעיית לקוח. לא חסר לנו רעיונות. על פי התוכנית הראשונית, הם צריכים להיות מופקים על ידי עובדים של תחומים טכניים. על מנת שרעיון יתקבל להמשך פיתוח, על המחבר למלא את "תבנית עיצוב רעיון". יש רק ארבע שאלות: מה? בשביל מה? מי צריך את זה? ואם לא המוצר שלנו, אז מה?

מקור

בחירה

ברגע שהתבנית המלאה מגיעה אלינו, מתחיל הליך העיבוד והבחירה. שלב הבחירה הוא המאמץ הרב ביותר. בשלב זה נוצרות השערות של בעיות (לא בכדי ציינתי בפסקה הקודמת שבאופן אידיאלי רעיון אמור לפתור בעיה של לקוח) וערך המוצר. נוצרת השערת קנה מידה, כלומר. כיצד העסק שלנו הולך לגדול ולשגשג. ראיונות בעיות ומומחים נערכים עם לקוחות פוטנציאליים כדי לספק אישור ראשוני שאנחנו הולכים לייצר משהו נחוץ. נדרשים לפחות 10-15 ראיונות כדי להסיק מסקנה לגבי הצורך במוצר.

אם ההשערות מאוששות, מתבצע ניתוח פיננסי ראשוני, היקף ההשקעה המשוער והרווחים האפשריים של המשקיע מוערכים. כתוצאה משלב זה, נולד מסמך בשם Lean Canvas ומוצג להנהלה.

מושג

בשלב זה מתבטלים כ-70% מהרעיונות. אם הקונספט יאושר, אז מתחיל שלב פיתוח הרעיון. מתגבשת הפונקציונליות של המוצר העתידי, נקבעים נתיבי יישום ופתרונות טכניים אופטימליים, ומתעדכנת התוכנית העסקית. התוצאה של שלב זה היא מפרט טכני לפיתוח וקייס עסקי מפורט. אם זה מצליח, נעבור לשלב ה-MVP או ה-MVP.

MVP או MVP

MVP הוא מוצר מינימלי בר-קיימא. הָהֵן. מוצר שאינו מפותח במלואו, אך כבר יכול להביא ערך ומבצע את הפונקציונליות שלו. זה הכרחי שבשלב זה של הפיתוח נאסוף משוב ממשתמשים אמיתיים ונבצע שינויים.

הפקה

והשלב האחרון הוא ההפקה. לא יותר מ-5% מהמוצרים מגיעים לשלב זה. 5% אלה כוללים רק את המוצרים החשובים, ההכרחיים, הקיימא והפונקציונליים ביותר.

יש לנו הרבה רעיונות וכבר הרכבנו תיק עצום. אנו מנתחים כל רעיון ועושים הכל כדי שהוא יגיע לשלב הסופי. נעים מאוד שהקולגות שלנו לא נשארו אדישים לכיוון המו"פ שלנו ולקחו חלק פעיל בפיתוח והטמעה של מוצרים ופתרונות.

איך יצרנו את LANBIX

בואו נסתכל על יצירת מוצר באמצעות דוגמה אמיתית - מוצר LANBIX. זוהי מערכת תוכנה וחומרה "ארגזת" המיועדת לניטור תשתיות IT קטנות ולהתריע מיידית של מקבלי החלטות ומשתמשים עסקיים על תקלות הנשלטות באמצעות צ'טבוט. בנוסף לפונקציית הניטור, LANBIX כולל פונקציונליות של Help Desk. מוצר זה בלעדי לפלח השוק שאליו אנו מכוונים. זה גם היתרון שלנו וגם הכאב שלנו. אבל דבר ראשון. אני אגיד מיד ש-LANBIX הוא מוצר חי (כלומר, הוא לא סופי בפיתוח שלו ונמצא בסיבוב הבא של ה-MVP).

אז, השלב הראשון הוא הרעיון. כדי שרעיון ייוולד צריך בעיות, והיו לנו, או יותר נכון לא לנו, אלא החברים שלנו. להלן נבחן מספר מצבים אמיתיים שהתרחשו בתחומי עסקים שונים.

חברת ניהול קטנה מתחזקת שני בתים באזור מוסקבה. הצוות עם מחשבים אישיים הוא כ-15 אנשים. מנהל המערכת הוא פרילנסר מבקר (בנו החכם של אחד הדיירים האכפתיים). נראה כי הפעילות של חברת הניהול תלויה במידה חלשה ב-IT, אך המוזרות של העסק הזה היא דיווח חודשי לרשויות רבות. בדיסק המערכת של ראש החברה (שכרגיל משלב תפקידים רבים) אזל המקום הפנוי. מטבע הדברים, זה לא קרה פתאום, האזהרה הייתה תלויה במשך כחודשיים והתעלמה כל הזמן. אבל הגיע עדכון, מערכת ההפעלה עודכנה, וכמו המזל, היא קפאה באמצע העדכון, והתלוננה לפני "מוות" על דיסק תפוס. המחשב נכנס לאתחול מחזורי. בזמן שסידרנו את הבעיה וקיבלנו דוחות, החמצנו את מועד הדיווח. נראה כי תקלה סתמית גרמה לצרות שונות: מהפסדים ועד ליטיגציה ואחריות מנהלית.

מקור   

אירוע דומה אירע בחברת אחזקות גדולה, המאגדת חברות קטנות רבות, עם שירות תמיכה טכנית אחת לכל המשרד. באחת המחלקות התקלקל המחשב של רואה החשבון הראשי. זה היה ידוע מזה זמן רב שהוא עלול להישבר (המחשב האט נואשות והתחמם), אבל רואה החשבון הראשי לא הספיק לשלוח בקשה לתמיכה הטכנית. באופן טבעי, זה התקלקל בדיוק ביום המשכורת, ועובדי המחלקה היו ללא כסף במשך כמה ימים.

לעסק קטן במסחר סיטונאי קטן היה אתר מכירות, שהתארח באתר חיצוני. למדנו על חוסר הזמינות שלו בטלפון מלקוח קבוע. בזמן השיחה האתר היה מושבת כשלוש שעות. לקח עוד שעתיים למצוא את האחראי לאתר, ועוד שעתיים לתקן את הבעיה. לפיכך, האתר לא היה זמין כמעט במשך כל יום העבודה. לדברי המנהל המסחרי של החברה, זמן ההשבתה הזה עלה להם כמיליון רובל.

אני עצמי נתקלתי במצב דומה כשהגעתי לתור במרפאה ונאלצתי לגשת לרישום VHI. הם לא יכלו לשלוח אותי לרופא מסיבה של מה בכך - היה נחשול מתח בבוקר, ואחרי התאונה שירות הדואר שלהם ושירות מסוים לתקשורת עם חברת הביטוח לא עבדו. בתשובה לשאלתי, איפה המנהלים שלך, נאמר לי שהמנהל שלהם מגיע ומבקר אותם פעם בשבוע. ועכשיו (באותו זמן השעה כבר הייתה 16:00) הוא לא מרים טלפון. במשך 7 שעות לפחות הייתה המרפאה מנותקת מהעולם החיצון ולא יכלה לספק שירותים בתשלום.

מה משותף לכל המקרים הללו? ניתן היה למנוע מראש את כל הבעיות. עם תגובה בזמן של אנשי ה-IT, ניתן היה לצמצם את הנזק. זה יהיה אפשרי אם התסמינים המוקדמים יתפרשו נכון על ידי המשתמשים.

זיהינו השערות בעיה:

• הפסדים כספיים ומוניטין משמעותיים עקב מהירות התגובה הנמוכה לתקלות בתשתית ה-IT;
• פרשנות שגויה של סימפטומים מוקדמים של תקלה על ידי משתמשים.

מה הלקוח יכול לעשות איתם, וכיצד להימנע ממצבים דומים בעתיד? אין הרבה אפשרויות:

1. לשכור מנהל מערכת מוסמך ביותר ולגרום לו לעבוד בצורה מצפונית;
2. מיקור חוץ של תחזוקת IT לחברת שירותים מיוחדת;
3. ליישם באופן עצמאי מערכת ניטור ודיווח תקלות;
4. לספק הדרכה למשתמשים/אנשי עסקים ביסודות אוריינות המחשב.

בואו נסתפק באפשרות השלישית. בואו להציע מערכת ניטור למי שלא משתמש בה מסיבות שונות.

סטייה לירית. מערכות שונות לניטור שירותי IT בשוק הארגוני נמצאות בשימוש זה זמן רב, והיתרונות שלהן אינם שנויים במחלוקת. שוחחתי עם נציגים של חברות גדולות, בדקתי איך נבנה הקשר בין עסקים ל-IT. המנהל הטכני של מיזם אחד גדול לבניית מכונות העביר את התחזוקה של תשתית ה-IT לחברה חיצונית, אבל הוא עצמו נשאר בקיא בכל הנושאים. במשרדו תלוי מסך מערכת ניטור גדול ובו מדדים של מצב שירותי ה-IT. הקריטיים ביותר נכללים במערכת. בכל רגע יכול המנהל הטכני לברר מה מצב התשתית, מה קורה, היכן הבעיה, האם קיבלו הודעה לגורמים האחראים והאם הבעיה נפתרת.

הסיפורים המפורטים לעיל גרמו לצוות שלנו לחשוב כיצד ליצור מערכת ניטור אופטימלית עבור חברות קטנות. כתוצאה מכך, נולדה LANBIX - מערכת ניטור שניתן לפרוס על ידי כל אדם ללא כל ידע ב-IT. המטרה העיקרית של המערכת פשוטה, כמו כל המערכות שמטרתן להגביר את ההמשכיות והזמינות - צמצום הפסדים כספיים ואחרים במקרה של השבתה לא מתוכננת. המכשיר נועד לצמצם למינימום את הזמן בין "משהו נשבר" ל"הבעיה תוקנה".

כדי לאשש את ההשערות, נערכו ראיונות בעיה. לא יכולתי לדמיין כמה אנשים יהיו מוכנים לספר בלי לנסות למכור להם. כל שיחה נמשכה לפחות 1,5 שעות, וקיבלנו מידע רב שימושי להמשך הפיתוח.

בואו נסכם את התוצאות של שלב זה:

1. יש הבנה של הבעיה,
2. הבנת ערך - יש,
3. יש רעיון לפתרון.

השלב השני היה מפורט יותר. על סמך תוצאותיו, היינו צריכים להציג בפני ההנהלה, הממלאת בעצם תפקיד של משקיע, מקרה עסקי (אותו Lean Canvas) כדי לקבל החלטה לגבי גורלו העתידי של המוצר.

התחלנו במחקר שוק ובניתוח תחרותי על מנת לגלות מי, מה והכי חשוב, איך הם מסתדרים בשוק הזה.

התברר כדלקמן.

1. אין בשוק מערכות ניטור מוכנות בקופסאות עבור הפלח שלנו (עסק קטן), למעט זוג או שלושה, עליהם לא אדבר מסיבות מובנות.
2. המתחרים העיקריים שלנו, באופן מוזר, הם מנהלי מערכות עם סקריפטים בכתב בית ו"תוספות" למערכות ניטור בקוד פתוח.
3. ישנה בעיה ברורה בשימוש במערכות ניטור בקוד פתוח. יש מערכת, יש כמות עצומה של מידע על איך לעבוד ולשנות את המערכת כך שתתאים לצרכים שלך. מבין המנהלים שראיינתי, רבים הודו שאין להם מספיק כישורים ליישם את הרעיונות שלהם בעצמם. אבל הם לא יכולים להודות בכך בפני ההנהלה מחשש לפיטורים. מסתבר שזה מעגל קסמים.

לאחר מכן עברנו לניתוח הצרכים של הלקוחות הפוטנציאליים שלנו. זיהינו לעצמנו פלח של ארגונים קטנים שמשום מה אין להם שירות IT משלהם, כאשר מנהל מערכת נכנסת, פרילנסר או חברת שירות אחראים ל-IT. לא צד ה-IT החליט להיכנס, אלא הצד העסקי, המציע למייסדים ולבעלי עסקים כלי לשיפור איכות שירות תשתית ה-IT. מוצר שאמור לעזור לבעלים לאבטח את העסק שלהם, אך יחד עם זאת יוסיף עבודה לאנשים שאחראים על ה-IT. מוצר המספק לעסקים כלי לניטור איכות תמיכת ה-IT.

כתוצאה מעיבוד הנתונים שהתקבלו, נולדה רשימת הדרישות הראשונה (סוג של צבר גס) למוצר העתידי:

• מערכת הניטור חייבת להתבסס על פתרון קוד פתוח וכתוצאה מכך זולה;
• קל ומהיר להתקנה;
• לא צריך לדרוש ידע ספציפי ב-IT, אפילו רואה חשבון (בשום אופן לא רציתי לפגוע בנציגים של המקצוע הזה) צריך להיות מסוגל לפרוס ולהגדיר את המערכת;
• אמור לזהות באופן אוטומטי אובייקטים לניטור ברשת;
• צריך להתקין באופן אוטומטי (ובאופן אידיאלי אוטומטי) סוכני ניטור;
• חייב להיות מסוגל לנטר שירותים חיצוניים, לפחות מערכת CRM ואתר מוכר;
• צריך להודיע ​​הן לעסק והן למנהל המערכת על בעיות;
• מידת העומק וה"שפה" של ההתראות צריכים להיות שונים עבור המנהל והעסק;
• המערכת חייבת להיות מסופקת על חומרה משלה;
• ברזל צריך להיות נגיש ככל האפשר;
• המערכת צריכה להיות עצמאית ככל האפשר מגורמים חיצוניים.

לאחר מכן חושבו ההשקעות בפיתוח מוצרים (כולל עלויות העבודה לעובדי המחלקה הטכנית). הוכנה שרטוט של המודל העסקי וחושבה כלכלת היחידה של המוצר.

תוצאת שלב:

• צבר מוצרים ברמה גבוהה;
• מודל עסקי מנוסח או השערת קנה מידה שטרם נבדקה בפועל.

נעבור לשלב הבא – קונספט. כאן אנחנו, כמהנדסים, מוצאים את עצמנו באלמנט המקומי שלנו. יש "רשימות משאלות" שמפורקות לרכיבים/תתי מערכות/פיצ'רים, אחר כך הופכים למפרטים טכניים/סיפורי משתמשים, ואז לפרויקט וכו'. לא אתעכב בפירוט על תהליך הכנת מערך אפשרויות חלופיות, נעבור ישר לדרישות ולשיטות שנבחרו ליישומן.

דרש
החלטה

• זו צריכה להיות מערכת ניטור פתוחה;

אנחנו לוקחים מערכת ניטור בקוד פתוח.

• המערכת צריכה להיות פשוטה ומהירה להתקנה;
• לא צריך לדרוש ידע ספציפי ב-IT. אפילו רואה חשבון אמור להיות מסוגל לפרוס ולהגדיר את המערכת.

אנו מציעים מערכת מותקנת כך שהמשתמש רק צריך להפעיל את המכשיר ולהגדיר אותו מעט, בדומה לנתב.

בואו נסגור את האינטראקציה עם המכשיר למשהו פשוט ומובן לכולם.

בואו נכתוב צ'אט בוט משלנו עבור אחד מהמסרים המיידיים הידועים ונעביר אליו את כל האינטראקציות עם המערכת.

המערכת צריכה:

• זיהוי אוטומטי של אובייקטים הנדרשים לניטור ברשת;
• התקנה אוטומטית של סוכני ניטור;
• להיות מסוגל לנטר שירותים חיצוניים, לפחות מערכת CRM ואתר מוכר.

אנו כותבים תוספות למערכת הניטור עבור:

• זיהוי אובייקטים אוטומטי;
• התקנה אוטומטית של סוכנים;
• ניטור זמינות שירותים חיצוניים.

המערכת צריכה:

• להודיע ​​הן לעסק והן למנהל המערכת על בעיות;
• להיות מסוגל לפקח על שירותים חיצוניים, לפחות מערכת CRM ואתר מוכר. מידת העומק וה"שפה" של ההתראות צריכים להיות שונים עבור המנהל והעסק.
• המערכת לא צריכה לדרוש ידע IT ספציפי; אפילו רואה חשבון צריך להיות מסוגל לפרוס ולהגדיר את המערכת.

• בואו נוסיף סוגים שונים של התראות עבור סוגים שונים של משתמשים. הם שונים בגובה ובעומק. משתמש עסקי יקבל התראות כמו "הכל בסדר, אבל המחשב של איבנוב ימות בקרוב". המנהל יקבל הודעה מלאה על השגיאה, מי, איך ומה קרה או יכול לקרות.
• בואו נוסיף אפשרות להשתמש בדואר של אחראי נוסף, כדי שבמקרה של תקלה הוא יקבל הודעה.
• בואו נוסיף אינטראקציה עם ספקי שירות חיצוניים על סמך שליחת מיילים עם טקסט מוכן מראש, כי המייל הוא זה שגורם לאירוע.
• כל האינטראקציה עם המערכת תהיה מחוברת לצ'אטבוט; התקשורת מתנהלת בסגנון דיאלוג.

תוספת:

• בואו נוסיף את הפונקציונליות של "צ'אט עם המנהל" כך שהמשתמש יוכל לשלוח למנהל הודעה המתארת ​​את הבעיה ישירות.

• המערכת חייבת להיות מסופקת על חומרה משלה.
• ברזל חייב להיות זמין.
• המערכת צריכה להיות עצמאית ככל האפשר מהסביבה.

• ניקח מחשב Raspberry PI מוכן וזול.
• אנו נתכנן לוח אל פסק.
• בואו נוסיף מודם כדי להיות בלתי תלוי במצב הרשת המקומית.
• נתכנן בניין יפהפה.

כעת יש לנו שלוש תת-מערכות עם דרישות משלהן וחזון ליישום שלהן:

• תת-מערכת חומרה;
• תת מערכת ניטור;
• תת מערכת אינטראקציה עם משתמשים.

פיתחנו תכנון ראשוני עבור תת-מערכת החומרה. כן כן! לאחר שהפרנו את כל כללי הזריזות, פיתחנו מסמך, כי מפעלי ייצור עובדים עם מסמכים. עבור תת-המערכות הנותרות, זיהינו משתמשים (אנשים), הכנו סיפורי משתמשים וכתבנו משימות לפיתוח.

בכך מסתיים שלב הרעיון, והתוצאה היא:

• פרויקט עבור פלטפורמת חומרה;
• גיבש חזון בצורה של סיפורי משתמשים לשתי תתי המערכות הנותרות;
• אב טיפוס תוכנה המיושם כמכונה וירטואלית;
• אב טיפוס של החומרה, מיושם בצורה של מעמד, שבו פתרונות החומרה נבדקו למעשה עבור חוזק;
• בדיקות שבוצעו על ידי המנהלים שלנו.

הבעיות בשלב זה היו בעיקרן ארגוניות וקשורות לחוסר ידע של צוות ההנדסה בהיבטים המשפטיים והחשבונאיים של המכירות. הָהֵן. זה דבר אחד להבין מה ואיך למכור, ודבר אחר לגמרי לעמוד מול מכונה משפטית חסרת רחמים: פטנטים, משימות פיתוח, רישום, EULA ועוד הרבה שאנחנו, כאנשים יצירתיים, לא לקחנו בחשבון מלכתחילה.

עדיין לא הייתה בעיה, אלא קושי הקשור בתכנון המתחמים. הצוות שלנו מורכב ממהנדסים בלבד, כך שהגרסה הראשונה של המארז "נבנתה" מפרספקס על ידי מומחה האלקטרוניקה שלנו.

הגוף נראה, בלשון המעטה, שנוי במחלוקת, במיוחד עבור הציבור, מפונק בטכנולוגיה מודרנית. היו, כמובן, אניני טעם בקרב הדור הוותיק של "קוליבינים" - הבניין עורר בהם רגשות נוסטלגיים. הוחלט לייצר ולעצב את המארז מחדש, שכן לישן, בנוסף לפגמים אסתטיים, היו גם פגמים מבניים - הפרספקס לא סבל היטב הרכבה ופירוק של המכשיר ונטתה להיסדק. אני אספר לך עוד על הפקת התיק.

ועכשיו אנחנו קרובים לקו הסיום - MVP. כמובן שזה עדיין לא מוצר ייצור סופי, אבל הוא כבר שימושי ובעל ערך. המטרה העיקרית של שלב זה היא להשיק את מחזור "צור-העריך-למד". זה בדיוק השלב שבו נמצאת LANBIX.

בשלב ה"יצירה" יצרנו מכשיר שמבצע את הפונקציונליות המוצהרת. כן, זה עדיין לא מושלם, והמשכנו לעבוד על זה.

נחזור לייצור הגוף, כלומר. למשימה להפוך את המכשיר שלנו מנוסטלגי למודרני. בהתחלה, סרקתי את השוק עבור יצרני ארונות ושירותי עיצוב תעשייתי. ראשית, אין הרבה חברות המייצרות תיקים בשוק הרוסי, ושנית, עלות העיצוב התעשייתי בשלב זה היא גבוהה באופן בלתי רגיל, כמיליון רובל.

הם יצרו קשר עם מחלקת השיווק שלנו לצורך העיצוב; המעצב הצעיר היה מוכן לניסויים יצירתיים. תיארנו את החזון שלנו לגבי הספינה (לאחר שלמדנו בעבר את הדוגמאות הטובות ביותר לבניית גוף), והוא, בתורו, הפך אותו ליצירת אמנות. כל מה שנשאר זה לייצר אותו. אנחנו, גאים בעיצוב שלנו, פנינו לשותפים שלנו. המנכ"ל שלהם מיד ריסק את הפנטזיות שלנו כשהצביע, לגמרי בחינם, על דברים שלא ניתן היה לייצר בדרך שבחרנו. ניתן לייצר את המארז, והוא לא יהיה גרוע מזה של אפל, אבל עלות המארז תהיה יקרה פי שלושה עד ארבעה מכל הרכיבים האלקטרוניים. לאחר סדרת פעולות ואישורים, תכננו בית שניתן לייצר. כן, זה לא יפה כמו שתכננו, אבל זה אידיאלי להשגת יעדים נוכחיים.

תוצאת השלב: אצווה ראשונה של מכשירים מוכנים ללחימה ולבדיקה.

ועכשיו הדבר הקשה ביותר הוא שלב "העריך", ועם המוצר שלנו אנחנו בדיוק בנקודה הזו. אנו יכולים להעריך רק על סמך תוצאות השימוש של לקוחות אמיתיים ואין כאן הנחות שפועלות. אנחנו צריכים את אותם "מאמצים מוקדמים" שיספקו משוב ויבצעו את השינויים במוצר שבאמת נחוצים. נשאלת השאלה: איפה משיגים לקוחות ואיך משכנעים אותם לקחת חלק בניסוי?

מבין כל האפשרויות האפשריות, בחרנו בסט קלאסי של כלים דיגיטליים: דף נחיתה וקמפיין פרסומי ברשתות חברתיות.

התהליך כבר יצא לדרך, אבל מוקדם מדי לדבר על תוצאות, למרות שכבר יש תגובות וקיבלנו אישור לרבות מההשערות שלנו. הפתעה נעימה הייתה תגובתם של נציגי מגזרים עסקיים שונים לחלוטין, גדולים בהרבה מאלה שציפינו. יהיה זה טיפשי להתעלם מההקדמות החדשות, ועל סמך תוצאות הראיונות הוחלט להשיק קו LANBIX מקביל בשם LANBIX Enterprise. הוספנו תמיכה בתשתיות מבוזרות, ניטור רשתות Wi-Fi עם פתרון תקלות ולוקליזציה, וניטור איכות ערוצי התקשורת. חברות השירות הביעו את העניין הגדול ביותר בפתרון. יחד עם זאת, למכשירים שכבר פיתחנו תפקיד חשוב בתפעול הפתרונות.

מה יקרה אחר כך

מה יקרה בהמשך עם ה-LANBIX המקורי יתברר על סמך תוצאות הקמפיין. אם ההשערות שלנו לא יאוששו, על פי מתודולוגיית ה-Lean, ניפטר ממנה ללא רחמים או שהיא תהפוך למשהו חדש, כי אין דבר גרוע יותר מליצור מוצר שאף אחד לא צריך. אך כעת אנו יכולים לומר שהעבודה שנעשתה לא הייתה לשווא ובזכותה הופיע ענף שלם של מוצרים מקבילים, עליהם אנו עובדים באופן פעיל. אם יצליח, LANBIX תעבור משלב ה-MVP לשלב הסופי ותתפתח לפי החוקים הקלאסיים המובנים של שיווק מוצרים.

אני חוזר, עכשיו אנחנו רוצים למצוא מאמצים מוקדמים, חברות שיכולות להתקין את המוצר שלנו כדי לאסוף משוב. אם אתם מעוניינים לבדוק את LANBIX, כתבו בתגובות או בהודעות פרטיות.

מקור

מקור: www.habr.com