איך תוכנית קטנה הפכה משרד קטן לחברה פדרלית עם רווח של 100+ מיליון רובל לחודש

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


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

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

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

במבט קדימה, אני אגיד מיד. התוצאה הייתה פלטפורמה ניתנת להרחבה הפועלת על 60+ שרתים ב-12 ערים ברוסיה ו-2 בקזחסטן. הרווח הכולל של החברה היה 100+ מיליון רובל לחודש.

שלב ראשון. אב טיפוס

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

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

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

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

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

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

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

• שרת מסד נתונים: MsSQL (גרסה חינמית עם הגבלת קבצי מסד נתונים של עד 2GB);
• פיתוח שרת המשרת לקוחות ניידים בדלפי תחת Windows, מאחר שכבר היה שרת Windows שעליו יותקן מסד הנתונים, כמו כן סביבת הפיתוח עצמה מאפשרת פיתוח מהיר;
• בהתחשב במהירויות האינטרנט הנמוכות בטלפונים ניידים בשנת 2009, פרוטוקול ההחלפה בין הלקוח לשרת חייב להיות בינארי. זה יקטין את גודל מנות הנתונים המועברות וכתוצאה מכך יגדיל את יציבות העבודה של הלקוחות עם השרת;

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

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

בסוף החודש השני של העבודה על ה-MVP, הגרסה הראשונה של השרת והלקוח הייתה מוכנה.

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

מרגע זה מתחיל החלק הכי מעניין והכי קשה בפרויקט.

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

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

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

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

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

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

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

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

המשך יבוא..

מקור: www.habr.com