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

[ynigun]

אגב היום שיש AI הרבה יותר קל לכתוב טסטים
לרוב רק צריך לתת קונטקסט נכון וקצת עריכות להוסיף ולדייק use cases

 

[חגית קרמר]

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

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

 

[ברבור1]

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

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

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

דייקת את מה שכתבתי...

 

[ברוך!]

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

בnextjs שוב חיברו את זה בגלל אופטימיזציה.
By default, Next.js includes its own server with next start

 

[ברוך!]

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

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

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

שיהיה לכם בהצלחה.

 

[חורף מטריה בענן]

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

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

שיהיה לכם בהצלחה.

אכן.
כבר קיבלתי את המידע מכל הזויות האפשריות.
תודה רבה לכל מי שהשתתף ועזר.

 

[ynigun]

ביקשתי מהAI לכתוב "מדריך לבית תוכנה מצליח" בהשארת המדריך לנוכל, כך תקימו מיזם נוכלות בתחום ההייטק של @אלי אלימלך
יצא נחמד אבל צריך לשפץ פה ושם

ספוילר: מדריך לבית תוכנה מצליח

מדריך שיווק מנצח לבתי תוכנה חזקים וגדלים!
1. כאשר לקוח פוטנציאלי פונה אליכם עם רעיון ליצור מוצר תוכנה חדשני, אל תבזבזו זמן על בחינת הרעיון לעומק. הזמן הוא כמובן כסף, וכסף הוא המטרה העיקרית. הרשימו את הלקוח מיד לפני שיחליט ללכת למתחרים.
2. ההצעה שלכם צריכה להיות מנצחת - הצעת מחיר אטרקטיבית במיוחד ולוחות זמנים קצרים שיגרמו ללקוח לסגור עסקה מהר. זכרו, לקוח שמתלבט הוא לקוח שעלול להחליף ספק.
3. אל תבזבזו זמן על בירורים מפורטים של דרישות הלקוח. הכירו בקצרה את הרעיון הכללי וצאו לדרך! "כלים חדשניים לפיתוח מהיר" יאפשרו לכם לדלג על שלבי תכנון מיותרים ולהתחיל לפתח קוד מיד.
4. אם הלקוח מציג חששות לגבי איכות התוכנה, הרגיעו אותו עם סיסמאות מרשימות כמו "קוד איכותי וידידותי למשתמש", "ניהול פרויקטים מקצועי" ו"תשתיות עבודה מתקדמות". אין צורך לפרט יותר.
5. ברגע שהלקוח שילם, הוא שלכם. מכאן והלאה התמקדו במוצר הבא ואל תבזבזו משאבים יקרים על טסטים או תיעוד לפרויקט הנוכחי.
6. אם הלקוח מתלונן על איחורים או בעיות, הפנו אותו לסעיפים הקטנים בהסכם שאיש לא קרא. חשוב להישאר אדיבים ומקצועיים - "מחויבות לשירות צמוד ללקוח".
7. במקרים קיצוניים שהלקוח לא מרוצה, הציעו לו "שדרוג מהיר לגרסה חדשה ומשופרת" או "מעבר קל לשרתי ענן מתקדמים". כך תוכלו להמשיך לגבות כספים.
8. אל תחששו להדגיש את "ניסיון העשור" של חברתכם ואת "הצלחות הענק" שצברתם עם לקוחות אחרים. קצת הגזמה פה ושם לא תזיק, כל עוד זה ימכר. הציגו תהליכי פיתוח "מוכחים ומנוסים" שיגרמו ללקוח להרגיש בטוח.
9. הציגו בגאווה את "הצוות המקצועי והוותיק" של מפתחים, מנהלי פרויקטים ומומחי איכות. אין צורך לפרט דרגות והשכלה - הדגשים הכלליים על "מיומנות" ו"התמחות" יספיקו.
10. הראו ללקוח דוגמאות של "פרויקטים מצליחים קודמים" עם ממשקים מרשימים. אל תתרכזו בפרטים הטכנולוגיים המשעממים - התמקדו בצד הוויזואלי והחיצוני. רוב הלקוחות מחפשים מראה יפה יותר מתוכן איכותי.
11. כשתדונו בתהליכי הפיתוח, השתמשו במונחים כבדי משקל כמו "מתודולוגיות מהפכניות", "גישות חדשניות" ו"כלים חלוציים". הלקוח לא באמת יבין במה מדובר, אבל זה ישמע מרשים.
12. אם הלקוח דורש התחייבויות איכות, הציעו לו "תהליכי בקרת איכות קפדניים" ו"בדיקות חוזרות ונשנות". אין צורך להזכיר שאלו יעלו לכם כסף רב.
13. הבטיחו ללקוח "שקיפות מלאה" ו"יכולת מעקב" על התקדמות הפרויקט. כמה סטטוסים לועזיים ודוחות התקדמות ריקים יספיקו לשמור על החזית.
חברים יקרים, זוהי השיטה המנצחת להפוך את חברת הפיתוח שלכם לאימפריה גדולה ומצליחה. כסף ועוד כסף צריך להיות המוטו שלכם, והכל סביב הצגת חזית מרשימה של "מקצוענות ויוקרה". בהצלחה!

 

[אלי אלימלך]

ביקשתי מהAI לכתוב "מדריך לבית תוכנה מצליח" בהשארת המדריך לנוכל, כך תקימו מיזם נוכלות בתחום ההייטק של @אלי אלימלך
יצא נחמד אבל צריך לשפץ פה ושם

ספוילר: מדריך לבית תוכנה מצליח

מדריך שיווק מנצח לבתי תוכנה חזקים וגדלים!
1. כאשר לקוח פוטנציאלי פונה אליכם עם רעיון ליצור מוצר תוכנה חדשני, אל תבזבזו זמן על בחינת הרעיון לעומק. הזמן הוא כמובן כסף, וכסף הוא המטרה העיקרית. הרשימו את הלקוח מיד לפני שיחליט ללכת למתחרים.
2. ההצעה שלכם צריכה להיות מנצחת - הצעת מחיר אטרקטיבית במיוחד ולוחות זמנים קצרים שיגרמו ללקוח לסגור עסקה מהר. זכרו, לקוח שמתלבט הוא לקוח שעלול להחליף ספק.
3. אל תבזבזו זמן על בירורים מפורטים של דרישות הלקוח. הכירו בקצרה את הרעיון הכללי וצאו לדרך! "כלים חדשניים לפיתוח מהיר" יאפשרו לכם לדלג על שלבי תכנון מיותרים ולהתחיל לפתח קוד מיד.
4. אם הלקוח מציג חששות לגבי איכות התוכנה, הרגיעו אותו עם סיסמאות מרשימות כמו "קוד איכותי וידידותי למשתמש", "ניהול פרויקטים מקצועי" ו"תשתיות עבודה מתקדמות". אין צורך לפרט יותר.
5. ברגע שהלקוח שילם, הוא שלכם. מכאן והלאה התמקדו במוצר הבא ואל תבזבזו משאבים יקרים על טסטים או תיעוד לפרויקט הנוכחי.
6. אם הלקוח מתלונן על איחורים או בעיות, הפנו אותו לסעיפים הקטנים בהסכם שאיש לא קרא. חשוב להישאר אדיבים ומקצועיים - "מחויבות לשירות צמוד ללקוח".
7. במקרים קיצוניים שהלקוח לא מרוצה, הציעו לו "שדרוג מהיר לגרסה חדשה ומשופרת" או "מעבר קל לשרתי ענן מתקדמים". כך תוכלו להמשיך לגבות כספים.
8. אל תחששו להדגיש את "ניסיון העשור" של חברתכם ואת "הצלחות הענק" שצברתם עם לקוחות אחרים. קצת הגזמה פה ושם לא תזיק, כל עוד זה ימכר. הציגו תהליכי פיתוח "מוכחים ומנוסים" שיגרמו ללקוח להרגיש בטוח.
9. הציגו בגאווה את "הצוות המקצועי והוותיק" של מפתחים, מנהלי פרויקטים ומומחי איכות. אין צורך לפרט דרגות והשכלה - הדגשים הכלליים על "מיומנות" ו"התמחות" יספיקו.
10. הראו ללקוח דוגמאות של "פרויקטים מצליחים קודמים" עם ממשקים מרשימים. אל תתרכזו בפרטים הטכנולוגיים המשעממים - התמקדו בצד הוויזואלי והחיצוני. רוב הלקוחות מחפשים מראה יפה יותר מתוכן איכותי.
11. כשתדונו בתהליכי הפיתוח, השתמשו במונחים כבדי משקל כמו "מתודולוגיות מהפכניות", "גישות חדשניות" ו"כלים חלוציים". הלקוח לא באמת יבין במה מדובר, אבל זה ישמע מרשים.
12. אם הלקוח דורש התחייבויות איכות, הציעו לו "תהליכי בקרת איכות קפדניים" ו"בדיקות חוזרות ונשנות". אין צורך להזכיר שאלו יעלו לכם כסף רב.
13. הבטיחו ללקוח "שקיפות מלאה" ו"יכולת מעקב" על התקדמות הפרויקט. כמה סטטוסים לועזיים ודוחות התקדמות ריקים יספיקו לשמור על החזית.
חברים יקרים, זוהי השיטה המנצחת להפוך את חברת הפיתוח שלכם לאימפריה גדולה ומצליחה. כסף ועוד כסף צריך להיות המוטו שלכם, והכל סביב הצגת חזית מרשימה של "מקצוענות ויוקרה". בהצלחה!

כל מילה מדוייק

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

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

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

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

 

[ynigun]

בנושא הטסטים
התחלתי שרשור חדש בנושא

למה TDD לא שולט בעולם?

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

www.prog.co.il

 

[~dasi~]

ניסיון טוב או רע מעבודה עם פרילנסר? תודה

נסיון טוב מאוד
אם את רוצה יותר פרטים תפני אלי באישי

 

[java]

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

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

לאורך השרשור נתת לנו להבין שאת שייכת לאופצייה הראשונה

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

 

[E L]

יש אחד חרדי
0556771785 - n-b-solutions
אפשר לבקש ממנו המלצות

 

[ynigun]

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

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

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

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

 

[יוסייוסייוס]

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

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

 

[יוסייוסייוס]

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

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

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

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

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

 

[חורף מטריה בענן]

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

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

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

 

[ynigun]

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

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

 

[ynigun]

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

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

 

[חורף מטריה בענן]

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

תודה, אני אכן מתכוונת להתמקד בלקוחות יותר קטנים, גם כיוון שאני רוצה לבצע התאמה אישית (התוכנה שאני רוצה שיבנו לי כן תהיה גנרית, מה שאני בניתי ב no cod אני יכולה תמיד לשנות.. ) בניגוד למתחרים שמשווקים מוצר מדף.

 

[יוסייוסייוס]

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

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