לא כולם מבינים עד כמה חשוב לפתח נכון את המפרט הטכני, אך למעשה זו שאלה כה רחבה שהיא לא תעבוד על קצה המזלג. מסיבה זו, לפני שתמשיך בהליך זה, עליך להבין את כל הדקויות הרלוונטיות.
לשם מה נועד?
לפני שנדון כיצד לפתח נכון את המפרט הטכני, עליכם להבין מדוע הדבר נעשה ועל ידי מי הוא ישמש לאחר מכן, מכיוון שהגישה הנחוצה לביצוע נוהל זה תלויה די בכך. ראוי לציין כמה אפשרויות בסיסיות:
- ארגון מסחרי מתכוון להציג מערכת אוטומטית לחלוטין, אך אין לו שירות IT משלו, כתוצאה ממנו החליט לעשות את הדברים הבאים: אדם מעוניין מסוים מפתח משימות טכניות, ואז נותן אותם לארגוני צד ג 'להמשך פיתוח.
- חברה מסחרית הולכת להשתמש במערכת אוטומטית, ויש לה שירות IT עובד. במצב זה, TK מפותחת, שלאחריה משא ומתן בפירוט עם שירות ה- IT ואז נשלח לגורמים המעוניינים, ובסופו של דבר הוא נמכר בכוחות עצמו.
- הממשלה עומדת לסיים פרויקט IT ספציפי. המון דקויות ומלכודות, כולל כל מיני פורמליות, כבר מגלים כאן, כך שלא כדאי אפילו לשקול אפשרות זו, מכיוון שכל מקרה פרטני לרוב דורש גישה אינדיבידואלית לחלוטין.
מקרים מורכבים יותר
המקרה הקשה ביותר הוא כאשר מפתחים מפרט טכני על ידי חברת IT לצורך פיתוח והטמעה של מערכות אוטומטיות לאחר מכן. במצבים כאלה עליכם לעבוד במגוון רחב של תנאים, כגון:
- נוכחות הלקוח של מומחים משלו וחזון משלו לתהליך זה, המטיל דרישות מסוימות על ה- TOR שנערך.
- מפרטים טכניים נוצרים אך ורק עבור המפתחים שלהם, והלקוח, באופן עקרוני, לא כל כך חשוב מה תהיה התוצאה.
- TK יועבר לקבלן, כלומר לקבוצה מסוימת של מומחים שנמצאים מחוץ לצוות החברה.
- בין החברה ללקוח יש אי הבנה לגבי התוצאה, כך שהחברה לא יודעת כיצד לפתח נכון את המפרט הטכני לתחזוקה.
ישנם מצבים רבים אחרים שצריכים לקחת בחשבון גם הם, אך רק התדירים הנפוצים ביותר מציינים לעיל.
מה זה TK?
יש מספר גדול למדי של GOST וסטנדרטים מסוימים שנועדו להסדיר כל תחום פעילות. בפרט, יש לקחת בחשבון תקנים כאלה בעת פיתוח מפרט טכני לתחזוקה. יחד עם זאת יתכן ויכוח פעיל לגבי עד כמה רלוונטיים למסמכים אלה, אך בכל מקרה, בתהליך פיתוח פרויקט משלך, אתה צריך לעמוד בהם באופן מלא. למעשה, יש להבין נכון כי GOSTs לרוב אינם חושפים את הבעיות המעשיות של ההתפתחות המודרנית, אך יחד עם זאת הם לא תמיד מציעים אלטרנטיבה ספציפית ומערכתית.
TK כשלעצמו הוא מסמך מקור השולט בתכנון מתקן טכני.היא קובעת את המטרה העיקרית של פיתוח זה, כמו גם מאפיינים טקטיים וטכניים שונים, מדדי איכות וכל מיני דרישות טכניות וכלכליות, וכן מציינת דרישות מיוחדות שיש לקחת בחשבון במהלך העבודה. המשימה כמסמך מקור ליצירת כמה דברים חדשים קיימת בכל תחום פעילות מודרני, אך היא יכולה להשתנות, תלוי בתוכן, בסדר העיצוב ובמספר פרמטרים אחרים.
תכונות השימוש
זה די טבעי כי הדרישות ב- GOST אינן מספיקות, כך שבסופו של דבר כל אחד יכול ליצור דוגמא אפקטיבית למשימה טכנית, וזה נורמלי למדי, מכיוון שלא כל אחד יכול לבצע את העבודה בהתאמה מלאה לסטנדרטים. בנוסף ל- GOST עצמה, יש לקחת בחשבון גם שיטות ונהלים מסוימים, ועובדה זו עומדת בבסיס הבעיה.
מומחים רבים, מסיבה כלשהי, מפתחים מפרט טכני לעיצוב אובייקט או ביצוע עבודות מסוימות, מבוססים אך ורק על הדרישות של GOST, אך במציאות זוהי בגישה מיסודה שגויה.
אתגר עיקרי
כדלקמן מההגדרה עצמה, המטרה העיקרית של TK היא לנסח את הדרישות הבסיסיות עבור האובייקט המפותח. במקרה זה, יש להבין נכון שאנו מדברים על הדרישות הבסיסיות, אך לא על היחידות.
כיצד לקבוע את הדרישות?
ראשית עליכם לזכור שתנאי ההתייחסות לעיצוב או פיתוח צריכים לכלול דרישות המחולקות לפי מאפיינים וסוגים. בכך למעשה GOST עוזר לנו ביותר. הרשימה שניתן למצוא שם היא דוגמה מצוינת לאילו סוגים יהיה צורך לקחת בחשבון, כלומר:
- פונקציונליות
- זכויות אבטחה וגישה;
- כישורי צוות.
למה לשים לב?
כמובן שזו לא רשימה שלמה. עם זאת, גורם המפתח שיש להבחין בדוגמה מוצלחת של המשימה הטכנית הוא הדרישות שגובש נכון לפונקציונליות, ודרישות אלה מקדישות אנשי המקצוע לרוב המכריע של השיטות והעבודות. מומחים רבים אומרים כי הדרישות לפונקציונליות כוללות כ -90% מכלל המורכבות של העבודה הקשורה לפיתוח מפרט טכני, וכל השאר הוא סוג של "הסוואה", אשר לאחר מכן יילבש על פי דרישות אלה.
אם הדרישות נוצרות בצורה לא נכונה, אז לא משנה כמה יפה תשימו עליהן הסוואה, בסופו של דבר זה לא יעבוד לעשות פרויקט ממש מוצלח. כמובן שלדברי GOST, כל הדרישות מתקיימות במלואן, תנאי ההתייחסות (המדגם להלן) מפותחים, חתומים ואושרו והמומחה קיבל תשלום עבור זה, אבל אז אתה צריך להבין מה לעשות עם מסמך זה. אם אנחנו מדברים על פרויקט למתן צו ממלכתי, לעיתים קרובות לא מתעוררות בעיות, מכיוון שיש אילוצי תקציב קטנים בהרבה, והפרטים העיקריים כבר יזוהו בתהליך היישום. אבל אם אנו מדברים על ארגונים מסחריים, שבהם הם רואים כסף ביתר פירוט ודורשים תוצאה אחרת, אז הכל כבר מורכב יותר.
פיתוח שימושי ויעיל
אם סוגי הדרישות יכולים להיות שונים מאוד, וכאן הכל תלוי אך ורק ביעדי הפרויקט, ישנם רק שלושה מאפיינים:
- הבנות;
- ספציפיות;
- בדיקות.
יחד עם זאת, יש להבין נכון שכאשר מפתחים משימה טכנית, יש לבדוק מדגם נכון, וזה כבר תלוי בשני המאפיינים הראשונים.אם לא ניתן לבחון את התוצאה של מילוי דרישה כזו או אחרת, זה מעיד כי דרישה זו אינה מובנת לחלוטין או איננה ספציפית, ועליכם לחשוב על כך, מכיוון שהיא בבעלות על המאפיינים הללו של הדרישות אשר טמונה המקצועיות והמיומנות של היזם, וכן לכן, מומחים מנוסים מבצעים עבודות כאלה הרבה יותר מהר וטוב יותר.
ניואנסים נוספים
יש גם כמה נקודות חשובות שיש לקחת בחשבון בעת פיתוח משימה טכנית. מערכת הדרישות היא כדלקמן:
- איזו שפה (מבחינת מורכבות התפיסה) צריך לכתוב?
- האם יש צורך לתאר בו תכונות ספציפיות של פונקציות שונות, אלגוריתמים, סוגים של מידע נחוץ ועוד דקויות טכניות?
- מהו תכנון טכני, שדרך אגב מצוין במפרט התקני הקיים של המדינה, וכיצד הוא קשור למפרט הטכני שנערך?
התשובות לכל השאלות הללו חשובות למדי, ובדיוק מסיבה זו, רבים מתחילים להתווכח עד כמה מספקת ה- TOR שנוסחה והאם היא מכילה את כל הפרטים הנדרשים בדרישות. בין היתר, חשוב גם עד כמה מסמך זה יהיה מובן מבחינת הלקוח והקבלן, עד כמה הוא מיותר ומה מתכונת המצגת.
משימה ופרויקט
TK הוא מסמך הכולל דרישות שונות המנוסחות בשפה המובנת ביותר עבור הלקוח וגם עבור הקבלן. יתרה מזו, אם בעל מקצוע מפתח משימה טכנית, השירותים שלו עשויים לכלול גם שימוש בטכנולוגיית התעשייה, שנועדה לספק את הניסוח המובן ביותר לקבלן הסופי. חשוב לזכור כאן כי יש צורך להימנע מכל כריכה לפרטים היישום הטכני, כלומר בתהליך פיתוח TK, באופן עקרוני, לא משנה באיזו פלטפורמה ספציפית ייושם יישום כל הדרישות הללו. כמובן שישנם חריגים מסוימים, אך מדובר במקרים מיוחדים.
ההבהרה והניסוח הנוסף של הדרישות השונות, כמו גם הפיתוח הסופי של ה- ToR, צריכים להיעשות כבר על ידי אנליסט עסקי המתמחה ולא על ידי המוציא לפועל (אלא אם כן, כמובן, הוא משלב את התפקידים הללו בעצמו, וזה קורה מעת לעת). במילים אחרות, על המומחה לתקשר עם הלקוח בשפת העסק שהוא מנהל.
הבדלים של הפרויקט מהמשימה
יצירת משימה טכנית מפרוייקט שונה בכך שהאחרון הוא מסמך הכולל את הדרישות הבסיסיות כיצד ליישם את הדרישות שצוינו ב- ToR. מסמך זה כולל את הדקויות העיקריות של המוצר המיושם ואת האלמנטים הדרושים שישמשו בעבודה על ידי מומחים טכניים בעבודה.
אין צורך שהלקוח יתעמק בעבודה כזו, מכיוון שהרוב המכריע של הדרישות אולי אפילו לא ברור לו. לעתים קרובות, יישום פרויקט טכני מתבצע על ידי מומחה ספציפי, לכן, ניתן בהחלט לשלב תפקיד זה עם המבצע. יחד עם זאת עליכם להבין שככל שהפרויקט גדול יותר כך אנשים מפתחים את המפרט הטכני.
מה הנוהג?
לעיתים קרובות קורה שהבמאי מובא לתיאום של TK הכולל המון מונחים טכניים, כתוצאה מהם הוא מנסה להתעמק בזה, מנסה לתפוס מילים מוכרות ולא לאבד את השרשרת העיקרית של הדרישות העסקיות. ככלל, במצבים כאלה המשימה הטכנית לעבודה עדיין מאושרת, מיושמת, וברוב המקרים מתברר כי התוצאה אינה תואמת את עובדת העבודה שבוצעה, מכיוון שהוחלט על שינוי רב של ניואנסים, לבצע מחדש,וכמה גורמים לא הובנו בצורה לא נכונה, ושלל בעיות אחרות עלו.
זו הסיבה שחשוב להבין את ההבדל בין TK לעיצוב הטכני, שקשור בחלקו לכשירותם של המומחים הרלוונטיים, ובחלקם לרצון לצמצם את התקציב והזמן, מכיוון שתיעוד כזה לוקח זמן רב.
