Софтуерно Инженерство
Loading...
+ Нов въпрос
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

Предложение за процеса и изискванията за отборните проекти

Инспириран от темата за записването за Javascript apps отборните проекти, искам да изложа едни свои виждания в лицето им на предложения, как би трябвало да протече работата по отборния проект, така че ясно да се открои кой е работил и кой не и да няма субективизъм. Или както Кико каза в другата тема - да не става така, че по-силните да не оставят по-слабите да работят, а после на всичкото отгоре да излязат и да кажат, че останалите не са работили.

Минава записването. Отборите се разпределят. На всеки отбор се дава 1 ден да излъчи кандидати за "Team leader". След това на отборът се дава 1 ден да гласува за тези кандидати, като гласуването за себе си не е позволено. (Естествено има го вариантът всеки да събере един глас, тук може да се измисли нещо по-хитро?). Съответно излъчва се Team leader на отбора.

Тук трябва да има строги изисквания какъв ще е процесът, който всеки отбор трябва да следва. Основната задача, освен да пише код, на тим лидера ще е да се грижи установеният процес да работи.

Процесът, който ще предложа е инспириран от съвременните методологии за проджект мениджмънт

Нека вземем за пример, че за отборния проект след установяване на кой ще е тим лидер остават 20 дни. От тук започва да тече и deadline-а на проекта.

20 дни се разделят на ПЕТ четиридневни итерации. Първата итерация задължително е установяване на останалите роли в проекта. След като учим HQC и Unit testing предлагам за задължително да има един QA в отбора.

Останалите ЧЕТИРИ итерации трябва да са изцяло development, testing && integrating насочени.

Според изискванията на отборния проект, например, всеки член е задължен да има по 5 къмита в 5 различни дни, тим лидерът се нагърбва с тежката задача, да разпредели достатъчно продуктивни задачи на съотборниците си, така че всяка задача да изисква поне един къмит, и така до поне 5тия къмит.

Всяка задача ТРЯБВА да се логва в тракинг системата която се ползва. В случая, ако е задължително използването на Github - в тракинг системата на гитхъб (Issues таба).

На представянето на екипния проект да може да се каже за някой съотборник, че не е участвал, САМО АКО не са успели да се свържат с него или след като са успели и е добавен към колабораторите на репозиторито и са му асайннати ПЕТ или повече валидни задачи, той НЕ Е резолвнал ПОНЕ ПЕТ от тях и съответно НЯМА ПЕТ къмита в 5 различни дни (или итерации най-добре).

Ако тимлидерът не се справи с тази задача, отборът може да излъчи чисто демократично друг такъв. Ако отборният проект фейлне заради лоша организация от към тим лидер, виновни са всички - за избирането на такъв тим лидер и за неуспешното избиране на нов такъв.

За цялостното оценяване на проекта да се гледа не само крайния продукт, но и процесът на работа, след като всичко ще се траква в тикети, разпределени в итерации, да се гледа дали срокът на итерациите а спазен и други неща, които говорят за успешното или съответно неуспешното сработване на отборите.

Също така може да се види какви точно са били разпределени задачите, и дали на някого не му е разпределено просто да ъпдейтва README.md с по 1 символ на таск.

Ако смятате, че идеята с подобен проектов мениджмънт ще е трудна да се реализира заради например недостатъчно опит на участващите, предлагам да се организира кратък курс по Съвременни практики за управление на проекти, с времетраенето на Javascript OOP курса.

13
Предложения и проблеми 29/11/2014 00:52:44
zontak avatar zontak 457 Точки

С всичко се съгласих.. , но това с лидера трябва да се доизмисли.. Не съм сигурен, как ще се избере човек за лидер след като не всички се знаем.. Много хора се записват с мисълта, че ще им мине номера и без участие в проекта да вземат точки от него.. А мине ли 4-5 дни.. и се установи, че този човек на е подходящ за поста тогава какво правим? Една от итерациите отпада.. ? Мхм това дали означава, че екипа няма да се справи добре и че няма да вземе пълен брой точки? :)  И дали ако някой от отбора му се дадът 5 ишута а той направи едно.. това ще се брои ли за участие? - Аз лично не бих го броил.. :) Хубаво предложение.. просто трябва да се пипнат някой тънкости :)

2
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

Принципно това с менторите може да проработи по този начин, ако се доизпипа и то.

Иначе съм готов да го доизшлайфаме предложението. Вместо да отпада итерацията, може някак си в движение да се преквалифицира. Просто ще е по-трудно за отбора, уж.

2
ttitto avatar ttitto 1155 Точки

RoYaL, благодаря ти за темата!

Нямам нищо против да има такъв курс, в който да ни учат как да работим в екип, но определено предпочитам в рамките на Софтуни да експериментирам върху начините, по които ще се сработвам или не с останалите съотборници. В смисъл, че вкарването на задължителна методология на сработване не е много демократично. Хора различни, нереално е да ги слагаш в един калъп и да режеш, това което стърчи навън.

Имал съм отбори, в които в дискусия по скайп се изписват по 200 реда с обяснения за парче код от 10 реда. Имал съм и такива, в които всеки влиза в репозиторито когато има време, гледа какво е написал другия и дописва самостоятелно и правилно без дори да пита нищо.

Екипът на Софтуни има механизми за идентифициране на несериозните участници. Просто остава не само да ги наказват с точки, а и да ги филтрират, за да не пречат на останалите. Или както може би някой друг би казал: "матриалът" като не е лош, ще стане работата.

4
06/11/2014 11:15:11
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

Здравей ttitto,

Благодаря ти за отделеното време. Всъщност, предложението не е само заради несериозните участници, а и заради участниците, които се нуждаят от някакво Know-how. И като цяло за подобряване на качеството при отборните проекти. По-долу съм коментирал отговора на Karlie, който може би трябваше да е отговор на твоя такъв. Какво мислиш за това да се даде свобода на избор да приемеш тази рамка или да се установиш нещо свое?

1
06/11/2014 13:42:42
ttitto avatar ttitto 1155 Точки

Мисля, че всичко това ще доведе до усложнена процедура по организацията на отборните проекти и по-голяма ангажираност на екипа на Софтуни. Което не е желателно, защото ще се пропука организацията на по-важни неща.

Определено подкрепям идеята за провеждане на ЗАДЪЛЖИТЕЛЕН курс, в който да се преподава Know-How за работа в екип и то по-скоро в частта му свързана с поведението на участниците. Защото все пак имахме курс за работа в екип през цялото първо ниво. В него ни дадоха инструментите (репозиторита, project management software, ...), но не наблегнаха на разни стратегии за успешна работа в отбора.

Дали обаче преподаденото Know How ще се ползва от съотборниците трябва да е тяхно лично право, а не задължение.

0
felix_de_suza avatar felix_de_suza 100 Точки

И аз мисля, че идеята е повече от добра и ще ни подготви много добре за истинските проекти като организация и изпълнение, но също така мисля и че това е много трудно постижимо понеже има много хора които имат и доста други занимания, като работа други университети и т.н. а самото изпълнение е много времеемко. Относно идеята за тийм лидера, мисля че задължително трябва да се направи, например в миналият ни проект ментора ни назначи ръководител на екипа, който ръководеше така да се каже нещата и следеше за изпълнението на задачите и помагаше ако имаше затруднения, но това много зависи от човека, защото едно е да натискаш някой да свърши работа за която не е квалифициран (както бяхме повечето от нас - без никакъв опит до момента), съвсем друго да седнете с него да видите какво не е ясно и да го изчистите. Моите виждания по въпроса са, че трябва да се помисли за някаква такава система понеже видяхме че системата с автоматичното "самонагаждане" между съотборниците не стработва много добре и мисля че всеки един екип е страдал от такова поведение. Браво на колегата, че се е сетил да предложи подобна организация на проектите!

1
GoShow avatar GoShow 595 Точки

Хубаво, е че се отваря подобна тема. До накъде съм съгласен и с ttitto, че не трябва хората и отборите да се вкарват в калъп. Да, така е, но в края на краищата, когато хората не знаят как да направят нещо, как то да заработи добре (говоря за отбора, не за проекта им), би трябвало да използват малко или много утвърдени практики. Всички познаваме Иван (RoYaL, за тези които все пак не го), аз имах късмета да бъда 2 пъти с него в подобни отборни проекти. Тези, които го познаваме по-добре, знаем, че макар и малък на години има доста опит като програмист зад гърба си, а също е много креативен, не само по отношение на продукта(кода) си. Предложенията му никога не остават висящи във форума, винаги са много дискутирани и винаги в тях има огромна доза рацио. Смятам, че идеята е много добра естествено има много неща за шлайфане. Лично аз мисля, че избрания тийм лийд трябва да има право да откаже. Причините са много, например, може да е човек с много познания и опит и да може да работи бързо и ефективно, но да не смее или да не знае как да раздава задачи. По отношение на итерациите също не е лоша идея, но може би всеки отбор трябва да прецени сам броя и продължителността им. Другото, което смятам е, че ако повече хора се включим креативно в тази дискусия, в края на краищата можем да доизкусурим алфа версия на СофтУни вариант за управление на проект. Призовавам всички, които имат креативно мнение по темата да го дадат и се надявам да не се влиза в безмислени полемики дали има или няма смисъл, дали е редно или не. Аз лично съм за въвеждането на правила във всичко, иначе става мазало!(както и с кода) :)

3
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

На мен първоначалната ми идея беше да има кандидатури за тийм лийд, т.е. ако някой от отбора не се кандидатира за такъв, няма да участва на другия ден във вота, съответно няма и да бъде избран. Така ще се предотврати избирането на тийм лийд на човек, който не иска да е такъв :)

2
GoShow avatar GoShow 595 Точки

Ето едно умно и адекватно решение. Лошото е, ако няма такива кандидатури въобще :). Някой ще трябва да се нагърби

0
Karlie avatar Karlie 437 Точки

Абсолютно подкрепям Titto! Роял, разбирам, че твоите предложения са продиктувани от професионализма и перфекционизма ти, предполагам желанието ти е студентите да правят добри проекти, и то по правилната методология. Но и според мен основната цел на тези отборни работи е да научим работата в екип, а не как да програмираме. И то да я научим по метода проба-грешка, а не всичко да ти е предъвкано и да движиш в коловоза.

Ако си от най-добрите в отбора и имаш опит - няма какво толкова да научиш. Ако си от слабите - и да ти възложат задача, и да искаш да я направиш, няма да можеш (случвало ми се е страшно много да искам да помогна на отбора, и просто да не мога, въпреки подробните обяснения на нашия тийм лийдър по неволя). Ако си от средните ще понаучиш нещо, но това нещо може да го понаучиш и ако отделяш това така ценно време за някоя допълнителна задача или sample exam. Да не говорим, че за екипните проекти се иска да знаеш и прилагаш неща, които учиш до последния момент в програмата за курса, тоест, на практика или си с предишен опит, или нямаш идея какво правиш до последните ден-два преди срока за предаване. С други думи, средни няма.

Последният път (C# OOP)  нашият отбор беше уникален случай - първите 5 дена обсъждахме как да започнем играта, то бяха едни амбициозни идеи за 3д, за Unity, за не знам си какво. После се оказа, че времето ни притиска и никой нямаше опит с ООП, Unity или нещо подобно. Дискусията в скайп полека заглъхна и изчезна, един вид, във въздуха висеше негласното споразумение да не правим проект, защото не ни се занимава. Предпоследният ден обаче едно от момчетата се включи в чата, каза "Извинявайте, че ме нямаше няколко дена, какво правим?" и след като му обяснихме, че проект няма да има, той реши да започне да пише сам, последната вечер. Понаправи нещо, някои от останалите се включихме в неговия проект, някои и не разбраха. Естествено, за една вечер и то без опит, не направихме кой знае какво, даже и в портфолиото си не бих го качила. И за ООП-то ми никак не помогна, но определено научих много от този проект за работата с колеги, които не познаваш и дори не си виждал. А не е като да не съм работила 10 години с хора, пък макар и в друга сфера.

5
06/11/2014 13:18:56
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

Здравей Karlie,

Благодаря ти за отговора.

Експериментите наистина много помагат. Бил съм в отбори, в които всички сме участвали и е вървяло перфектно, бил съм в отбори, в които въпреки, че сме участвали не е вървяло толкова добре, бил съм в отбори в които почти не съм участвал и в такива, в които почти само аз съм участвал. От всичките ситуации успях да извлека положителни неща и да научи нещо ново.

Налагайки се рамка, може би до някаква степен ще се ограничат експериментите. От друга страна вече минаха доста отборни проекти и фрапантните грешки, които можехме да допуснем - ги допуснахме. Сега ни остава или само да ги повторим или да сме се научили от тях.

Т.е. от тук нататък рамката, може е повече полезна от колкото вредна. Едновременно ще помогне на хората, които не са се научили от грешките си и ще помогне за това да не остават хора в сянка и такива, които нищо не правят безнаказано.

Разбира се, тази рамка може да бъде опционална. Ако примерно, твоят отбор смятате, че може да се справите с управлението и постигането на проекта без предварително наложена методология - може например, да мейлнете това на софтуни, или да бъде предоставено като някакъв "чекбокс". Тогава никой в отбора не трябва да се сърди, че е останал в сянка, а тези които не са участвали, ще отнесат същите последици, както и ако е имало наложена методология. И както титто каза - по възможност по-сурови.

Идеята ми е всичко да е демократично. Но и от друга страна, хората които се нуждаят от "побутване" да го получат. Да има обучение за управление на проекти. Да има и предложена схема за това. А който не иска да се възползва и да експериментира, да се чувства свободен да го прави.

Апелът ми е, ако посоката на такова мислене ви се струва правилна, да помогнете за еволюцията на предложението. Например за това да бъде незадължителна подобна рамка, да има такъв курс и пр.

 

1
06/11/2014 13:34:09
milen8204 avatar milen8204 302 Точки

Ще си позволя да споделя и моето мнение. Наистина отборните проекти не се реализират по начина, на който на повечето ни се иска. Определено теем лидера ще внесе някаква по-добра организация в нещатата. Възможен вариант е да не се избира от групата (защото в 80% от случаите не се познаваме), а да се назначава служебно, примерно от топ 100 студентите, заявили участие в екипния проект. Защо да не е възможно и да се раздват и други роли като sinior devеloper и junior devеloper.

Може и при заявяване на участие в екипния проект да си избираш като какъв ще се изявяваш в него... тоест да си избереш роля, в зависимост от познанията ти (тeam lеаder, sinior devеloper и junior devеloper).

Незнам дали стана много ясно, но с две думи имаш предварителни познания в тази обаласт, в която е теам проекта и си избираш роля на team lеаder или sinior developer, за пръв път се сблъскваш избираш junior. И най накрая Системата изплюва един отбор в следния състав: Пешо - team leader, Гошо - sinior devеloper, Мариа - sinior devеloper, Станка - junior devеloper, Милен - junior devеloper и Ставри - junior devеloper.

 

0
29/11/2014 14:41:27
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

Това не съм сигурен, че би проработило. Например ако само 3ма човека изберат да са тимлидери, след това системата ще състави само 3ма отбора, в които има тимлидер. По-лошо - ако всички решат, че имат качествата за тимлидери - системата ще изплюе отбори само от тимлидери. :D Предложението е хубаво, но се разчита прекалено много на съзнанието на хората и тяхната самооценка. Което в повечето случаи съм забелязал - не работи :(

1
milen8204 avatar milen8204 302 Точки

Не е съвсем така... Може да се имплементира по много начина, примерно ако са само 3 да направи три групи с теам лидера, а останалите на рандом признак да се назначат служебно. Ако всички изберат теам лидер пак в отбор ще има на по един и другите няма да са това, че си заявил, че искаш да си теам лидер, няма да ти гарантира получаването на такава роля...

1
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

Аз съм за този експеримент, но за съжаление съм на доста голям процент убеден, че ще фейлне. Разчита се прекалено много на случайността и шанса. Демократичният принцип някак си повече ми харесва. Така се случва и във фирмите. Избират някого, който има такова желание, за Тим лидер. Не винаги избират правилния, понякога си мислят, че познават човека, но се оказва, че не е така.

1
ibakyrdjiev avatar ibakyrdjiev 172 Точки

RoYaL, Ти си посления човек, който трябва да говори за дипломация в тази тема. 

Имаш адски много опит, за което ти се възхищавам, но хейта, който пръскаш в форума и начина по който се онасяш към "по - слабите" си в екипа В КАФЕТО викайки не ти правя чест ...

8
28/11/2014 20:08:55
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

@ibakyrdjiev, това е така, далеч съм от перфектния профил, въпреки че по темата, която зачекна има доста какво да се каже и с радост бих дискутирал, не са обект на конкретната тема във форума.

Дали аз ще предлагам подобно предложение, или някой друг, не би трябвало да се взима предвид. По-важно е самото предложение.

1
iliev72 avatar iliev72 143 Точки

Още преди година е бях зачекнал тази тема директно с екипа на СофтУни.

И предложението ми беше TeamLeader и тези които презентират да са на случаен принцип.

Също така всеки студент да влезе в тези роли.Защото рано или късно щом се озовеш на работа може да се наложи да бъдеш team leader или да се наложи да презентираш продукт.В фирмите няма демокрация и там team leader го избира шефа и мисля , че ако този избор го правят СофтУни ще доближи нещата максимално до релаността.

0
kiko144 avatar kiko144 SoftUni Team 793 Точки

Ами не съм много съгласен.

Аз се записвам за екипните проекти, защото ми се коди и ми се правят реални (или поне близо до реалните) проекти и ако се окаже, да се падна "презентатор"... ами.... не знам какво ще направя, ама не исакм да става.

А колкото до това, че всеки ще бъде това което му кажат, пак не съм съгласен.

Няма как да ме накарат да работя нещо което не искам.

Трябва да има някви "роли", но не и на случаен принцип.

 

2
iliev72 avatar iliev72 143 Точки

Работиш във фирма по проект и екипа решава , че ти ще представиш проекта на една конференция какво ще правиш а ?!

Така е решил team leader.Ще напуснеш работа ли ?!

П.С. Поздравление за "-"джията , но като ти сложи "-" шефа дали и ти ли ще му сложиш "-" а ?!

0
29/11/2014 11:12:37
kiko144 avatar kiko144 SoftUni Team 793 Точки

На конкретният въпрос съм съгласен, че ще го направя.

Но има хора, които няма как да са Team Leader-и и има хора които просто не им се получава говоренето пред хора. И аз отказвам те да се учат и другите да берат последствията. 

Ако съм напълно наясно с кода ще ми е супер лесно да го представя, но съгласен ли си, че някой друг би го направил толкова добре.

И все пак зависи от ситуацията. Ако не искам да представям нещо на конференция и някои ми постави въпроса "Или го правиш, или си уволнен" ами по-скоро ще напусна.

Може и проблемът да е в мен. Факт е, че не обичам да ми казват какво да правя, но според мен малко се губи демокрацията.

2
29/11/2014 00:28:46
kiko144 avatar kiko144 SoftUni Team 793 Точки

Здравейте и от мен! 
Много се радвам, че има такива теми и подобни предложения, защото смятам, че така все пак ще се стигне до една "идеална" система. А начина това да стане е точно ние - студентите - да даваме feedback и идеи.

Колкото до конкреното предложение - доста ми допада, но наистина има някои кусури.

  1. Какво става, ако няма кандидати за team leader? Мисля, че това ще е доста често срещано нещо. Средно има по 30 отбора на курс. Мислите ли, че има 30 човека с опит на лидери, които да могат да преценят възможностите на даден човек, да му дават задачи, които хем да го мотивират, хем да има полза за проекта? И ако да, дали те са достатъчно отговорни да го правят? Аз лично, не мисля, че бих успял, и не съм сигурен, че съм бил в отбор с човек, който би.
  2. Това с итерациите е добро, но от моят опит забелязвам, че масово всички се сещат да пишат по екипните в последната една седмица и дори и Наков да дойде да ги моли, няма да се навият.

Плюсовете според мен са:

  • Попадаш в много близка до реалната среда и добиваш някаква представа как трябва да стават нещата, което е най-ценното. 
  • Хора, които са нерешителни и не знаят какво да направят по проекта все пак допринасят за него.

Ако стигнем до един идеален SoftUni то би трябвало менторите да правят това, но ми се струва мноооого нереално, освен ако не са хора без работа :D

Въпрос до  Karlie : Според теб, ако на отборния ви проект по OOП имаше човек, който да ви натиска и ви дава задачки през цялото време, които можете да накодите, бихте ли направили по-добра игра? 

Мнение относно поста на milen8204 : Идеята е яка, но ако има точно определени роли и се знае всеки какво трябва да направи, няма ли да се изгуби Тиймуърка? Според мен проектът ще стане просто като някаква по-сложна задача от домашните.

0
Karlie avatar Karlie 437 Точки

Кико, мисля, че да, ако имахме team leader щяхме да се хванем по-рано за работа и да направим нещо по-завършено. НО, според мен, този вариант е:

- доста теоретичен. Както много хора казаха преди мен, не винаги има доброволци да са тийм лийдъри и всъщност точно това се случи при нас - нямаше някой желаещ да загуби страшно много време в разпределяне на задачи и помагане на по-слабите (ако предположим, че TL е с опит).

- по-скоро вреден за успеха. Работата по проектите никога не ми е носила толкова знания, колкото домашните. Не за първи път казвам ,че се записвам на отборна работа не за да си науча материала от курса, а за да се ориентирам как се работи по по-голям проект (да дълбаеш чуждия код, да недоумяваш какво са правили нинджите и да се научиш да не се панираш и комплексираш като се сравняваш с тях). За мен, тъй като съм начинаеща и всеки курс ми носи абсолютна нова информация, отборните проекти са нещо второстепенно. Не в смисъла на по-маловажни, а в смисъла на нещо, което идва второ. Както покрива е безспорно важен за една къща, но ако няма основи - ходи слагай покрива! Ако имаше някой, който да ме насилва да работя през целия срок на курса основно по проекта, научила-недонаучила, на изпита щях да имам по-нисък резултат. То и затова според мен хората бачкат по проекта основно в последните дни. Така е по-добре, струва ми се, всеки да си преценява силите, кога е готов и може с нещо да помогне.

(В тази връзка, браво на колегите, които са предложили на Наков за настоящия курс по JS Aps да изнесе същественото (BaaS-a) като второ домашно!)

С други думи, аз не искам да имаме назначени тийм лийдъри, още по-малко пък искам мен да ме назначат за такъв! Просто нямам време за това, а и не мисля, че е от полза. Е, ако съм на работа, няма не искам и друг решава, кое е полезно за фирмата :)

Хайде и от мен един въпрос: нали правите нещо подобно на TL  в присъствените отбори с менторите, как е там?

0
RoYaL avatar RoYaL SoftUni Team Trainer 6795 Точки

Менторите са само теоретични тим лидери. Много от нещата, които един тим лидер трябва да изпълнява на тях по правило са им забранени. А останалите пожелателни неща, някои от тях не ги и вършат. Например първият ни ментор се отнесе много несериозно.

P.S.: Дори мешаницата по кода, в която ти се налага да се ориентираш (което смяташ за полезно, всъщност, и безспорно е, де...) може да се менажира и да е по-малко, ако тим лидерът се постарае да разпредели така задачите, че да няма някакви огромни колизии или gap-ове.

 

@Кико, всъщност огромният проблем е това сещане да се работи последните дни. Някак си ми се иска да се избегне и да се отдаде повече важност на екипните проекти. Честно казано нямам конкретно теоретическо решение как да стане. До колкото до това дали има хора с такива качества и то достатъчно много - ами може би наистина няма, но това нез начи, че няма да се развият впоследствие.

0
Anita avatar Anita 363 Точки

Отборните проекти са направени със следната цел да накарат колегите да работят в екип. Целта не е само да се направи един общ проект защото всеки един от отбора би могъл да си направи индивидуален такъв ... едни по-бързо и по-лесно а други по-трудно и дълго.

Целта е една да се симулира реална работна среда при, която ще попадане всеки един в реален проект.

Качествата, които трябва да се развият при работа в екип:
- Креативност
- Инициатива  
- Презентационни умения
- Oтговорност и Изпълнителност: Сроковете трябва да се спазват както и обещанията. Много хора никога не се научават да спазват сроковете. А това е наистина ВАЖНО при реалната работа.
- Лидерски умения: Всеки поне веднъж трябва да има шанс за това
- Правилна комуникация с колегите: Всеки един от екипа може да е полезен.
- Търпимост: Не трябва да се крещи,вика и обижда в един екип защото това не помага
- Толерантност: Всеки трябва да разбере,че не трябва да налага собственото си мнение на всяка цена, защото не винаги е прав
- Реална преценка на собствените сили и тези на съотборниците
- Гъвкавост и справене с извънредни ситуации: Примерно някои е обещал нещо и не го е направил и всички от отбора трябва да направят така, че проекта да не се провали.
- Физическа и емоционална издръжливост: При някой отборни проекти и екипи се работи денонощно в последния момент и не всеки издържа на напрежението ... някои се отказват от поставените им задачи и по-този начин прецакват още повече екипа.
- Планиране на времето: Всеки трябва да се научи да планира времето, да си разделя задачата на под-задачи и да си поставя междинни срокове за всякака една задача така, че да може да свърши в срок.

- Взаимопомощ и споделяне на знания

- Взимане на решения:

- Личностно развитие:


 

4
29/11/2014 23:11:52