PM Stories » анкета

Проучване на в. InfoWeek за пазара на труда в ИТ сферата

Майк Рам — Tue, 16 Mar 2010 16:15:35 +0000

Вестник InfoWeek са предприели една много хубава идея – да направят проучване сред българските ИТ компании на тема “Пазарът на труда”. Въпросите са насочени към мениджърите в българските фирми и се отнасят предимно до политиките, които фирмите прилагат към задържането на настоящите си служители, набирането на нови, провеждането на обучения и механизмите на възнаграждение по време на криза.

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

Колегите от InfoWeek, а и аз, ви призоваваме да дадете своето мнение и да отговорите на въпросите от анкетата – те не са много, така че няма да ви отнеме много време. Ако не сте мениджъри – препратете я на вашите шефове.

Анкетата ще е активна още 2 седмици, след което резултатите ще се появят в хартиеното и в онлайн изданието на вестника. Нека да видим каква е ситуацията на трудовия пазар в ИТ сектора днес.

Благодаря ви за участието!

Гласувайте за тази статия в Svejo.net:

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

Вижте и тези публикации:

Добрите практики на софтуерното производство – анкета

Майк Рам — Thu, 09 Jul 2009 05:10:59 +0000

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

Аз се включих в анкетата и наистина времето за попълването е между 30 и 60 минути, но вие не сте длъжни да попълвате всички категории, особено пък ако не се занимавате с всички описани дейности. Можете да дадете мнение само за онези дейности, с които активно се занимавате и с които имате най-много опит. Тогава би трябвало да се справите за 20-ина минути.

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

Призовавам ви и аз да се включите в тази анкета. Steve McConnell е човек с голяма ерудиция и идеята да се оценят по-известните теоретични подходи според практическото им използване и ефективност, е много добра. Така ще можем да получим една по-реална представа кои техники носят реална полза в практиката.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Кой решава дали да стартира един проект?

Майк Рам — Thu, 20 Nov 2008 10:44:10 +0000

Във връзка с поредния курс по управление на проекти, който подготвяме в RammSoft, посветен на стартирането на един проект, искам да ви попитам кой е човекът или факторът, който решава дали да се започне един проект във вашата компания или не.

Дали това е главният изпълнителен директор (The Big Boss) или друг отдел във фирмата (маркетинг, финанси, счетоводство), дали проектният мениджър и екипът, който ще изпълнява поетия проект, имат право на глас във вземането на това решение или то се взема от неведоми външни сили?

Гласувайте в новата анкета на блога (горе вдясно) и подкрепете вашия глас с коментар. Имате право да изберете не повече от 3 опции.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Хиляда лева за мотивация. Резултати от анкетата

Майк Рам — Tue, 04 Nov 2008 17:49:08 +0000

Тази анкета се застоя малко по-дълго, но това беше преднамерено. Реших, че трябва да дам достатъчно време, за да могат повече хора да дадат своето мнение и така анкетата да придобие малко по-голяма тежест. Хубавото е, че този подход даде резултат – имаме цели 212 участника! Лошото е, че резултатите не ми харесват и според мен не показват мениджърско мислене.

Зададеният въпрос беше: “Ако имате 1000 лева, които трябва да използвате, за да мотивирате своя екип, какво бихте направили с тях?” А ето и вашите отговори:

Ще им ги раздам в брой като бонус (29%, 61 гласа)
Едно голямо ядене и напиване за всички (22%, 46 гласа)
Професионални книги за всички (17%, 35 гласа)
Професионален курс за някои (16%, 34 гласа)
Друго (7%, 14 гласа)
Ще ги похарча за себе си (4%, 8 гласа)
500 бири за всички (3%, 6 гласа)
Нови монитори за някои (2%, 4 гласа)
Нови столове за някои (2%, 4 гласа)

Топ-отговорът беше провокативен. Раздаването на пари е лош мотивационен подход, а когато сумата е малка, не носи почти никакъв резултат. Фактът, че този отговор е избран от най-много хора, говори, че гледната точка на гласувалите е била не тази на мениджъра на проекта, а на изпълнител в този проект. Помислете: ако екипът е от 10-ина човека, това означава всеки един да получи средно по 100 лева. На фона на сегашното равнище на заплатите на софтуерните разработчици от около 2000 лева, какъв мотивационен ефект биха имали тези 100 лева? Колко точно ще се повиши производителността на един програмист, ако му връчите бонус в размер на 5% от месечната му заплата? Не мисля, че някой ще се напъне особено много да работи в резултат на това възнаграждение.

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

Анкетата всъщност постави няколко дилеми:

Дали всички да бъдат наградени или само някои?
Дали проджект мениджъра може да реши кое е най-доброто средство за мотивация?

Резултатите показват, че на първия въпрос мнозинството категорично избира награда за всички. Друг е въпросът какво е мотивирало този “социалистически” избор – аз смятам, че това е гледната точка на член на екипа, който се страхува “да не се мине”. Може и да греша – вие имате правото да ме оборите с контра-аргументи в коментарите си.

В действителност, изборът на по-скъп “подарък” – специализиран професионален курс, който ще развие уменията на човека, или чисто нов монитор, който ще доведе до по-ефективна работа и до по-добро здраве на човека, е подход, който демонстрира най-ярко загрижеността на компанията за своя служител и в резултат укрепва неговата мотивация. Фактът, че той е един от малцината избрани (защото парите няма да стигнат за всички), му дава увереност, че е на прав път и че неговите постижения не са останали незабелязани от ръководството.

Естествено, този път на разсъждения веднага поражда въпроса: Как ще се мотивират онези, за които няма пари? Самият факт, че най-добрите получават стойностни награди показва, че има честна игра. Ако работиш добре – получаваш премия. Ако не си достатъчно активен – пропускаш. Важното е, че имаш възможност да спечелиш. Това, че трудът ти се наблюдава и оценява, е достатъчен мотиватор да се стремиш към по-добри резултати.

На втория поставен въпрос, отговорът също е ясен – проджект мениджърите не могат (или се страхуват) да вземат решението кое е най-доброто средство и затова правят най-лесния избор – пари в брой или банкет. А може би такива са очакванията на самите програмисти? Опасявам се, че наистина една голяма част от хората, работещи в областта на софтуерната разработка, нямат никакви други интереси и стремежи в работата, освен редовното получаване на пари. Това е обяснимо с масовото навлизане на чалга-културата в съзнанието на средностатистическия българин, но аз лично имах надеждата, че работещите в света на високите технологии, освен високо (висше) образование, имат и висока култура.

Дано да греша. Очаквам вашите коментари и тълкувания на резултатите.

Ето и една оферта за професионално обучение: На 12.11.2008 г. ще водя курса “Управление на риска в софтуерни проекти“, организиран от фирма RammSoft. Там не само ще се запознаете с теорията на риск мениджмънта, но и ще имате възможността веднага да приложите придобитите знания на практика.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Проучване на “soft skills” на проектните мениджъри

Майк Рам — Tue, 28 Oct 2008 04:15:47 +0000

Кои са най-важните “soft skills” за един проджект мениджър?
Кои от тях успяваме да изградим у себе си с кои се затрудняваме?
Дали жените са по-добри от мъжете по отношение на уменията за общуване и взаимодействие сдругите хора?

Това са въпросите, на които търси отговори Zuzana Botkova в интернет проучването, което е организирала. Самият израз “soft skills” много трудно се превежда на български (може би защото такива качества по принцип липсват в нашите мениджъри?). Това са уменията за общуване и въздействие върху хората (за разлика от “твърдите” (“hard”) умения, които са свързани с управление на процесите).

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

Един от начините да разберем отговорите на тези въпроси, е да участваме в проучването на Zuzana. В него могат да участват всички, които имат мнение – даже не е задължително да сте проджект мениджър, макар че е за предпочитане. Можете да отговорите както от гледната точка на мениджъра, който управлява екип от хора, така и от гледната точка на член на този екип.

Колкото повече участници се включат в проучването – толкова по-ясна представа ще придобием за важността на “гъвкавите” умения на един мениджър и доколко те влияят върху производителността и ефективността на един екип. Имам уверението, че ще получим резултатите от изследването веднага, щом приключи и бъдат обработени. Разбира се, вие можете да споделите своето мнение и като коментар към този пост.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Хиляда лева за мотивация. Нова анкета

Майк Рам — Tue, 15 Jul 2008 08:42:40 +0000

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

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

Бихте могли да организирате голям купон с ядене и пиене за целия екип (може и с половинките) и да профукате всичките пари наведнъж. Някои наричат това “тийм билдинг”.
За хора, работещи по цял ден пред компютър, всички знаем колко е важно да имаме ергономични мебели и оборудване. Бихте могли да им купите хубави и скъпи столове, за да не ги болят гърбовете или пък нови монитори, за да им е по-удобно да виждат всичко на екрана. Проблемът е, че тези неща са скъпи (особено мониторите) и парите няма да ви стигнат, за да можете да купите на всички. Бихте ли избрали решение, при което само някои хора от екипа ще бъдат облагодетелствани?
Най-демократичното решение, може би, би било да се похарчат всичките пари за бира в пластмасови бутилки и чипс. Така ще запасим офиса за дълги времена с ценната течност. Проблемът е, че някои може и да не пият бира.
Можете да вложите парите в професионалното развитие на своя екип. Тук дилемата е дали да пратите няколко човека на специализиран курс или да купите книги за всички.
Справедливо решение е може би просто да се раздадат пари на всеки като бонус за добре свършената работа. Проблемът е, че ако имате 10 човека в екипа, бонусът ще бъде средно по 100 лева, което не е кой знае колко мотивиращо.
Разбира се, можете и да задържите парите и да ги похарчите за себе си. Приемаме, че шефът няма да ви държи точна сметка, така че решението остава изцяло на вашата съвест.

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

Гласувайте за тази статия в Svejo.net:

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

Вижте и тези публикации:

Usability пример: забранени (disabled) менюта и бутони

Майк Рам — Mon, 07 Jul 2008 10:41:22 +0000

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

Поводът отново да се върна на него е един пост на Joel Spolsky, в който той категорично отстоява позицията, че менютата трябва да бъдат разрешени и при избор от страна на потребителя, трябва да се изведе съобщение, обясняващо защо тази операция не можа да бъде извършена в този момент.

Аргументът на Джоел е прост – като види едно забранено меню, потребителят има да се чуди защо е така и няма да може да си върши работата добре. Това е напълно валиден аргумент, що се отнася до хора, които още не познават системата добре и имат нужда от помощ. Но от друга страна, опитният потребител би се почувствал досадно ако избере меню или бутон и му се каже: “Сори, но това в момента не работи.”

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

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

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

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

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

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

Бих искал да знам и вашето мнение и затова съм отворил нова анкета, в която въпросът е: да забраняваме или да не забраняваме? Споделете вашите предпочитания, гласувайки.

Естествено, осъзнавам, че качественият отговор не е толкова прост, така че очаквам вашите мнения и като коментари под този пост.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Оптималният размер на екипа е ясен

Майк Рам — Fri, 04 Jul 2008 13:38:51 +0000

Като постоя достатъчно дълго време, анкетата за оптималния размер на екипа успя да събере доста гласове (цели 96) и придоби някаква представителност, макар и само в рамките на този блог.

Въпросът беше: Какъв е оптималния размер на един софтуерен екип? Ето и вашите отговори:

3-5 човека (40%, 38 гласа)
5-9 човека (32%, 31 гласа)
10-20 човека (11%, 11 гласа)
2-ма души (приятели) (10%, 10 гласа)
над 40 човека (3%, 3 гласа)
1 човек (freelancer) (2%, 2 гласа)
20-40 човека (1%, 1 гласа)

Очевидно е, че за повечето от вас малкият екип е много по-ефективен – ако обобщим първите два резултата, излиза, че цели 72% от вас подкрепят това мнение.

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

Подобна е и логиката за екипи между 10 и 20 човек, за които са гласували 11% от вас. Такъв екип е необходим при по-големи проекти, където се налага и по-голяма специализация на различните членове, но ако се налага да направим един простичък уеб сайт, едва ли е необходимо да стреляме с топ по врабчета, т. е. по-големите екипи са по-трудно управляеми и са по-неефективни за по-малки задачи.

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

Радвам се, че проявявате все по-голям интерес и по-голяма активност в анкетите, които публикувам в този блог. Надявам се, че въпросите са смислени и интересни за вас. Благодаря на всички за участието! Очаквайте следващите анкети!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Кой тества вашия продукт? Резултати от анкетата

Майк Рам — Wed, 02 Apr 2008 13:32:37 +0000

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

Въпросът беше: Кой тества вашия продукт? Общо гласувалите в анкетата са 66 човека, като разпределението на отговорите е следното:

Тестери – членове на проектния екип (36%, 24 гласа)
Отдел по качеството във фирмата (23%, 15 гласа)
Програмистите (23%, 15 гласа)
Клиентът (18%, 12 гласа)

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

Това, което ме плаши, е, че 41% от отговорите показват, че в тези фирми на практика няма тестване. Съвременните практики в контрола на качеството изискват на този процес да се посвети много време, знания и усилия, за да се предотврати издаването на софтуер със сериозни бъгове в него. Да оставиш тази дейност в ръцете на програмистите е дълбоко погрешно. Първо, те нямат възможността да погледнат на своята работа отстрани, за да открият дълбоко заровените бъгове. Второ, нямат и времето да се занимават сериозно с това, тъй като обикновено са натоварени над 100% с разработка.

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

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

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Кой тества вашия продукт?

Майк Рам — Sun, 20 Jan 2008 16:14:45 +0000

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

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

По-интересен е случаят, в който тестването е неотменна част от жизнения цикъл на продукта и с това се занимават нарочно определени хора. Тук отново съществува едно принципно разделение: в някои фирми тестерите са част от проектния екип – те участват в тестването на всички документи – още в най-ранната фаза на проекта – и остават в екипа до окончателното предаване на продукта на клиента, че даже и малко след това – по време на процеса на поддръжка.

В други фирми пък за тестването отговаря специален отдел по качеството, който не се числи към нито един проект, а извършва оценка на качеството на всички продукти, които се разработват в компанията. Обикновено този отдел се ръководи от Quality Manager – човек, който има последната дума по отношение на това дали продуктът покрива критериите за качество, зададени при самото стартиране на проекта. На този тип организация му казват Testing as service или тестването като услуга.

Въпросът е: кой е по-ефективният метод и кой е по-подходящ за нашия проект?

Напоследък се налага организация от типа “тестване като услуга”, може би поради това, че тестерите от отдела по качеството могат да бъдат по-ефективно натоварени. От друга страна, тестването като услуга има и своите недостатъци, един от които е изискването за предварително подготвена детайлна документация, което на практика е рядко срещано явление – най-вече поради постоянно променящите се изисквания от страна на възложителя.

В подкрепа на организацията, при която тестерите са равноправни членове на проектния екип, Johanna Rothman е публикувала един пост в блога PM Hut, озаглавен Тестването не е услуга. В него тя аргументира своята позиция със следното:

Когато работят като услуга, тестерите превключват постоянно между различни продукти, без да могат да изучат който и да е от тях в детайли и поради това тестването на всеки един от тях е доста повърхностно, което означава некачествено.
Не е ясно какъв е приоритетът на различните проекти и на кой от тях ще бъдат отделени повече внимание и ресурси.
Тестерите не работят заедно с разработчиците и списъците с открити бъгове се тълкуват повече като обвинение към програмистите, отколкото като конструктивна обратна връзка.
Вместо работа в екип се създават отношения “ние срещу тях”. Разработчиците загубват интерес сами да тестват кода си, прехвърляйки всичко в ръцете на тестерите, като по този начин се губи значително време на тестерите да се занимават с елементарни и очевидни грешки, които биха могли да бъдат отстранени от програмистите още преди кодът да бъде предаден за тестване.

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

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

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

Гласувайте за тази статия в Svejo.net: