הימנע מהלקוח כבני ערובה על ידי המפתחים שלך

ערובה100107בסוף השבוע התחלתי שיחה עם אמנית מקומית שסייעה לבוס שלה בניהול כמה יישומי רשת שבבעלותה.

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

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

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

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

כמה טיפים אם אתה הולך להשיג צוות פיתוח במיקור חוץ:

  1. רישום דומיין

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

  2. אירוח האפליקציה או האתר שלך

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

  3. בבעלות הקוד

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

  4. קבל חוות דעת שנייה!

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

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

תגובות 6

  1. 1

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

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

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

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

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

    • 2

      לא באמת,

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

      דאג

  2. 3

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

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

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

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

    4. תמיד. תמיד. תמיד.

  3. 4

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

    "זה נהדר שהמפתח שלך יכול להיות חברת אירוח והוא יכול לארח את האתר שלך עבורך, אבל אל תעשה את זה."

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

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

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

    שוב, פוסט טוב ומידע מאוד שימושי.

    תודה!
    מייקל ריינולדס

    • 5

      היי מיכאל,

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

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

      אני תומך בכך שאתה שולט ואחראי על האירוח שלך כדי שתוכל להיות תלוי במפתח שלך במה שהוא מצליח - לפתח!

      אני מעריך את הדחיפה, מייקל.

  4. 6

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

    אני חושב שרוב כולם יסכימו (והתבססו על ההערות למטה) מספר 1 הוא מוחלט. לעולם אל תעשה זאת לעולם. אֵיִ פַּעַם. בשום מצב שהוא.

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

    עבור מספר 3 הלקוחות שלנו מקבלים את כל קוד המקור של המוצר הסופי עם אזהרה אחת: עבור מוצרים של צד שלישי המשמשים בפתרון (כגון פקדי אינטרנט מטלריק או Component One), אנו יכולים לתת ללקוח את ה- dll המהולל עבור שליטת הצד השלישי (נניח רשת). הסכמי הרישוי שלנו עם אותן חברות צד ג '(שאנו מספקים ללקוח) אוסרים עלינו להפיץ מחדש את קוד המקור לאותו סוג של בקרות, מכיוון שהוא הקניין הרוחני של הצדדים השלישי, ולא שלנו. השימוש בסוגים אלה של מוצרים חוסך זמן פיתוח עבור הלקוח וזול בהרבה מבניית אותה פונקציונליות מאפס. אנו מקדימים את המדיניות הזו לפני שעבודה כלשהי. כמובן שאם הלקוח מעוניין לשלם עבור פיתוח בקרה מותאמת אישית (במקום להשתמש במוצר שנבנה מראש מהצד השלישי) אנו מספקים את קוד המקור לאותו בקרה מותאמת אישית יחד עם כל השאר.

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

    כפי שאחרים אמרו, מס '4 מומלץ תמיד. תמיד!

    בברכה,
    טים יאנג

מה אתה חושב?

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