כיצד לכתוב הצעה לפיתוח תוכנה

כיצד לכתוב הצעה לפיתוח תוכנה מוצלחת.

קווין לנגדוק

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

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

אורך ההצעה

ראיתי תבניות ודיונים הדוגלים בהצעות שנמשכות 50 או עמודים. תאמין לי, לאחר העמוד החמישי תאבד את האינטרס של המנהל העסקי. לאחר קבלת ההצעה, מטבע הדברים מסמכי התכנון יהיו מפורטים יותר מכיוון שהם יועדו לצוות הפרויקט ויהוו את שרטוטי העבודה של המערכת. זה יחול על מרבית הלקוחות אך (כן תמיד יש אבל) אם ההצעה היא בתגובה לבקשה להצעה (RFP), עליך לעמוד בהסכם הנמ"ר. כמו כן, סביר להניח שלממשלה או סוכנות צבאית יהיו הנחיות מחמירות כיצד להכין הצעה לפיתוח תוכנה ועשויים לכלול מספר עמודים (10, 20, 30, 50 ומעלה) בהתאם למורכבות המערכת.כלל זה עדיין תקף לגבי ארגונים גדולים שעשויים לעבור תהליך הצעה רשמי במיוחד אם הם תאגיד ציבורי ועליהם לעמוד בכל תקנות או תקנים של סרבנס-אוקסלי או ISO.

תקציר מנהלים

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

התבנית

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

כותרת הפרויקט

עם כותרת משנה או מידע מסכם על ההצעה

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

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

תוכן עניינים

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

אישורים

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

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

האישורים צריכים לכלול את שם האדם, כותרתו, ואחריהם חתימתם ולבסוף התאריך שבו נחתם המסמך.



שֵׁם	כותרת / תפקיד	חֲתִימָה	תַאֲרִיך

שינויים

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



מְחַבֵּר	תאריך השינוי	תיאור או תגובה

מילון מונחים וראשי תיבות

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

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

ראשי התיבות הבאים הם מהתבנית הנוכחית. הם ניתנים כדוגמה.

RFP: בקשה להצעה
החזר על ההשקעה: החזר השקעה
CAGR: קצב צמיחה שנתי מורכב
IT: טכנולוגיית מידע
CAPEX: הוצאות הון
UoM: יחידת מידה

תְחוּם

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

ציר זמן

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

חברי הפרויקט

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

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

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



חבר צוות	תַפְקִיד	פרטי התקשרות	אחריות
	אַלוּף
	בעל עניין
	מנהל פרוייקט
	אַדְרִיכָל
	מְנַתֵחַ
	מפתח

הזדמנות עסקית

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

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



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

סקירת פתרונות

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

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

תכונות ומסירות

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

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

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



תכונה	תיאור	ניתן למסירה

תקציב והחזר על ההשקעה

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

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

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

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

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



פריט פרויקט	כמות	מחיר ליחידה	UoM	סה"כ
רישיון תוכנה
מכונות
רישיון שרת
רישיון מסד נתונים
יועץ פיתוח
ניהול פרוייקט
הדרכה (זמן + חומרים)

החזר

ה- ROI חישוב ה- ROI קל מאוד. בעיקרון הנוסחה היא רווחים - עלות חלקי עלות. הנוסחה מוצגת להלן:

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

CAGR

נוסחת CAGR היא:

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

יתרונות

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

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

אילוצים

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

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