PM Stories

Петък – ден на майстора. Забавни компютърни цитати

Майк Рам — Fri, 10 Jul 2009 05:10:33 +0000

В края на работната седмица ви предлагам една развеселяваща доза цитати и оригинални мисли за компютри, програмиране и програмисти. Насладете им се!

- Колко хардуерни инженери са необходими, за да се смени една крушка?
- Николко. Ще го оправим в софтуера.

- Колко програмиста са необходими, за да се смени една крушка?
- Николко. Ще го документираме в ръководството.

- Колко инженери от Microsoft са необходими, за да се смени една крушка?
- Николко. Ще дефинираме тъмнината като индустриален стандарт.

- Колко документатори са необходими, за да се смени една крушка?
- Николко. Потребителят ще се оправи и сам.

Анонимен

—

Непрекъснатата принтерна хартия е най-здрава в перфорациите.

Закон на Мърфи за принтерната хартия

—

Целта на компютърната наука е да създаде нещо, което ще просъществува поне докато го създаваме.

Анонимен

—

Всяка програма е част от друга програма, но рядко си пасват.

Пълно издание на вътрешните майтапи в Microsoft, том III

—

Когато една програма отказва да работи според спецификацията, сменете спецификацията. По-лесно е, отколкото обратното.

Брифинг пред новопостъпилите програмисти в Microsoft, 1995

—

Информационен център: Зала, пълна с компютърни специалисти, чиято работа е да ти обяснят защо не можеш да получиш информацията, която ти трябва.

Дяволския речник на компютърните науки

—

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

Норм Шрайър

—

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

Анонимен

—

Бог създаде машинния език. Всичко останало е дело на човека.

Анонимен

—

Истинските програмисти на пишат на PL/I. PL/I е за онези програмисти, които не могат да решат дали да пишат на COBOL или на FORTRAN.

Programmers’ World

—

Език за програмиране C: Един нов език, който комбинира гъвкавостта на Асемблер с мощта на Асемблер.

Въведение в С на Мърфи

—

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

Алекс Лу за програмирането на Java

—

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

Анонимен

—

Очаквам всеки момент някой да изобрети едно кръгло нещо, което да се търкаля по земята и да намали триенето, но за това ще му трябва поне 233-мегахерцов Pentium процесор.

Гари Харант, Австралия

—

Краят на света дойде. Моля излезте от системата.

Съобщение при изход от системата Posix 2.1.1

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

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

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

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

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

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

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

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

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

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

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

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

Почти перфектно

Майк Рам — Mon, 29 Jun 2009 05:10:45 +0000

“Almost Perfect” или “Почти перфектно” се казва книгата на W. E. Pete Peterson, бивш изпълнителен директор на WordPerfect Corporation, в която той разказва историята на създаването на един от най-успешните софтуерни продукти в света, на възхода и падението на фирмата, на ентусиазма и главозамайването на нейните създатели, както и собствената си личностна драма.

Книгата е много интересна, поне за онези, които се интересуват от софтуерния бизнес. Издадена е още в 1993 г. за първи път и е продала само 10 000 копия, след което е спряна от печат. За наше щастие, авторът я е публикувал онлайн и можете да я прочетете от тук. Освен това, се предлага и в PDF вариант, за онези, които предпочитат да я четат офлайн. (Специални благодарности на Jeff Atwood за линковете.)

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

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

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

Ето няколко цитата, които ще ви заинтригуват:

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

***

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

***

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

***

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

***

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

През май 1990 Microsoft пуснаха Windows 3.0 и нашите най-големи страхове се превърнаха в реалност. Точно, когато убедително печелехме пазара на текстови редактори за DOS, светът на персоналните компютри искаше Windows, бъгове и всичко останало. За да бъдат нещата още по-зле, Microsoft Word for Windows вече беше на рафтовете на дилърите и получаваше много добри отзиви. Този малък облак на хоризонта, който изглеждаше съвсем безобидно през 1986, беше вече навсякъде около нас, изглеждащ зловещо и заплашително. Силата и големината на IBM вече не можеха да ни предпазят. Дори и слон не можеше да игнорира приближаващата буря.

***

Следващите няколко месеца бяха много трудни. Аз преживях всички емоции, типични за хората, загубили работа. Преминах през периоди на отричане, тъга, депресия, яд и примирение. Беше ми много трудно да загубя своята WordPerfect идентичност с нейния статус на полу-звезда. Липсваха ми обедите и тенис мачовете в късния следобед, когато работехме върху всички важни проблеми. Липсваха ми битките с Microsoft. Открих, че да се пенсионираш на 43 години не е чак толкова привлекателно, както повечето хора си представят.

***

WordPerfect Corporation вече не съществува. Когато опитите да я направят публична се провалиха, Alan и Bruce продадоха своите дялове на на Novell. Когато продажбите на WordPerfect спаднаха, Novell продаде повечето от продуктите на WordPerfect на Corel на много ниска цена. Въпреки, че WordPerfect все още се ползва от милиони потребители по света, Corel има големи проблеми да изкарва пари от този продукт. Microsoft е много як конкурент.

***

WPCorp се похарчи до смърт. Последната пълна година, когато аз бях там (1991), продажбите бяха приблизително $600 милиона, а счетоводната печалба беше $200 милиона. През 1992, продажбите паднаха до близо $570 милиона, но разходите нараснаха толкова, че достигнаха приходите. През 1993 продажбите бяха около $700 милиона (ако може да се вярва на това число), но разходите нараснаха над $700 милиона. Броят на служителите от началото на 1992 до края на 1993 нарасна от 3300 на 5500 човека и фирмата кървеше пари.

***

Novell пострада най-много. Вместо златна крава, обещаваща продажби от $880 милиона и печалба от $100 милиона, WordPerfect беше дупка, в която парите потъваха, с много по-малко реални продажби и загуби от $100 милиона. Novell купиха потъващ кораб и никога не са имали реален шанс да оправят нещата. Самите Novell бяха здраво загазили (и все още са) и не можеха да оправят собствения си кораб, камо ли нечий друг.

Историята прилича на сапунен сериал, но е много ценна като урок по бизнес. Освен това, книгата е написана много увлекателно и се чете много бързо. А като добавим, че в ролята на Големия Лош Вълк играят Microsoft, предполагам, че всички ще се заинтересуват от нея

Струва си! Препоръчвам ви я горещо!

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

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

Петък – ден на майстора. Най-добрият начин да мотивираш един програмист

Майк Рам — Fri, 05 Jun 2009 05:10:17 +0000

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

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

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

Един колега каза, че може да напише твоя код по-добре и той да заработи два пъти по-бързо!

Вижте тук цялата история. Благодарности на Jeff Atwood за линка.

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

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

Що за програмист сте?

Майк Рам — Wed, 03 Jun 2009 05:10:02 +0000

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

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

Ето какво излезе за мен:

Your programmer personality type is: PHTB

You’re a Planner.
You may be slow, but you’ll usually find the best solution. If something’s worth doing, it’s worth doing right.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Team.
A good group is better than the sum of it’s parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We’re not writing on paper anymore so we can take up as much room as we need.

Искате ли и вие да разберете дали сте Истински програмист или екипен играч като мен – тествайте се! Минава бързо и не боли.

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

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

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

В търсене на теория за софтуерното производство

Майк Рам — Mon, 01 Jun 2009 05:10:12 +0000

Ivar Jacobson е забележителна личност в областта на софтуерното производство. Един от създателите на езика за моделиране на процеси и изисквания UML, на Rational Unified Process – една от класическите методологии за управление на софтуерни проекти, Ivar Jacobson не спира да търси най-добрия начин за правене на ефективен и полезен за потребителя софтуер. Той има и собствен блог (който аз наскоро открих благодарение на моя приятел Дани), в който споделя своите търсения и открития в областта на разработката на софтуерни продукти.

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

Ние в инженерната индустрия ли работим или в модната?

- възкликва той. И продължава:

Не ви ли се струва, че следването на последната мода в софтуерната индустрия е станало по-важно от производството на качествен софтуер?

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

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

Какво трябва да се направи?

Имаме нужда от теория на софтуерното производство. Но тя не трябва да е нещо сложно и неразбираемо, а нещо просто и конкретно, за да има практическа полза от нея.

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

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

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

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

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

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

Open Agile Румъния

Майк Рам — Tue, 19 May 2009 07:58:46 +0000

Open Agile е първото голямо събитие в Румъния, посветено на управлението на софтуерното производство с гъвкави (Agile) методи. То ще се проведе на 22 и 23 май 2009 г. в University Politehnica в Букурещ.

Конференцията обещава да бъде интересна, като се има предвид, че сред лекторите са Ken Schwaber (на снимката) – един от създателите на най-успешния и най-популярен Agile метод – Scrum и Jurgen Appelo – един от най-популярните блогъри в света в областта на управлението на софтуерни проекти.

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

У нас активността е насочена предимно в технически конференции, фокусирани върху новости в програмирането. Събития като Microsoft Days и DevReach вече са се превърнали в успешна традиция. Но разработването на софтуерни продукти отдавна не е само програмиране, а една цяла индустрия, която има всички характеристики на всеки друг бизнес. За съжаление, у нас все още мисленето на хората, работещи в тази индустрия, е насочено предимно в производството, т. е. в програмирането, а области като управлението и маркетинга на софтуерни продукти все още остават на заден план.

Конференцията Open Agile Romania обещава да бъде интересна и полезна. Не е много далеч, а и участието не е много скъпо. За съжаление, аз няма да мога да присъствам, но ще се радвам онези, които успеят да отидат, да споделят своите впечатления на страниците на PM Stories.

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

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

Внимавайте с изискванията на клиента!

Майк Рам — Thu, 14 May 2009 13:42:14 +0000

Всеки от нас вероятно се е сблъсквал с така нареченото “пропълзяване на изискванията” (scope creep), когато в процеса на работа клиентът се сеща, че към вече договорените изисквания трябва да се добавят нови, иначе продуктът, който изработваме за него, няма да му свърши добра работа.

Това, на което попаднах, обаче, направо ме изуми. Graig Brown от блога Better Projects представи една статистика от доклада Chaos на Standish Group от 2002 г., в която се вижда, че цели 45% от изискванията, които клиентът е включил в проекта и са били реализирани, в крайна сметка въобще не се ползват. (Цъкнете върху картинката за по-голямо изображение.)

Като добавим и 19-те процента на много рядко използвани изисквания, положението придобива трагични размери. На практика, едва 20% от изискванията на клиента влизат в активна употреба, което означава, че огромно количество труд и енергия на проектиния екип са отишли на вятъра.

Какъв е изводът?

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

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

Така че – внимавайте с изискванията! Анализирайте ги детайлно и ги обсъдете неколкократно с възложителя, преди да ги включите в заданието. Иначе, в края на проекта ще бъдете затрупани с работа, клиентът ще недоволства, че закъснявате и няма да иска да си плати, а в крайна сметка, дори няма да ползва всички глезотии, които си е поискал.

Трябва да бъдем малко по-критични към техните изисквания. Това, в крайна сметка е за доброто и на двете страни.

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

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

Кой е отговорен за проекта?

Майк Рам — Mon, 11 May 2009 16:15:23 +0000

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

В английския език е малко по-различно. Там се употребяват думите “responsible” и “accountable”, и на двете се придава различен смислов оттенък. Доскоро си мислех, че това никак не е маловажно дори и за нас, тъй като повечето професионална литература по темата се пише на английски и разликите са съществени. Липсата на разбиране за тези разлики би могла съществено да обърка управленския ни подход.

Затова, когато Jurgen Appelo постави в своя блог въпроса какво разбираме под тези две думи и каква е разликата между тях, аз се включи с голям интерес, тъй като много исках да изясня този въпрос и за себе си. Юрген, който е холандец и в техния език също разполагат само с една дума за “отговорност”, също не беше сигурен в значението на тези две думи и предложи своята лична трактовка:

Responsibility е отговорност, която поемаш сам. Accountability е онова, което другите изискват от теб.

С други думи, управниците разчитат на accountability. Те възлагат на хората задачи, за резултатите от които ги държат отговорни (accountable). Лидерите разчитат на responsibility. Те създават култура, в която хората доброволно поемат отговорност за неща, които може и да не са част от техните формални задължения.

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

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

Казано по друг начин – ако висшия мениджмънт си търси някой, който да “опере пешкира”, това е “отговорния” човек.

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

Responsible е онзи, който е назначен да върши определена работа, а accountable е онзи, който взема окончателното решение и е отговорен за изпълнението на задачата.

Казано на прост език, responsible е този, който изпълнява задачата, а accountable е неговия шеф.

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

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

Това е то.

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

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

Тонове полезна информация за freelancers

Майк Рам — Wed, 22 Apr 2009 05:10:51 +0000

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

Първият списък е ориентиран към обяви за работа и свързване на търсещите и предлагащите услуги. Той идва от блога FreelanceSwitch и е тяхна редовна рубрика, която се обновява всяка година. Сайтовете са разделени по категории, като едни са само дъски за обяви, в които само се осъществява контакт между двете страни, а други са един вид борси, в които може да се наддава и да се сключват сделки.

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

Свободният труд е не само начин да си увеличите приходите – при някои хора това е единственият доход – но и начин да реализирате своите идеи и мечти, да изразите себе си и да покажете собствената си визия и подход. Дори и да не практикувате freelance работа, можете да научите много полезни и интересни неща за нея, а и за себе си.

Успех!

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