PM Stories » Разработка на софтуер

Краят на софтуерното инженерство?

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

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

Какво, всъщност, представлява софтуерното инженерство?

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

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

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

дали програмирането наистина е инженерна дейност?

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

За да разберете истинската роля на контрола, представете си два напълно различни проекта:

Проект А, който евентуално ще струва 1 милион долара и ще донесе печалба около 1.1 милиона долара и

Проект Б, който евентуално също ще струва към 1 милион долара, но ще донесе приходи от над 50 милиона долара

Очевидно е, че контролът е от голямо значение за Проект А, но почти не играе роля за Проект Б. Това веднага води до странното заключение, че стриктния контрол има голямо значение за относително безполезни проекти и много по-малко за истински полезните проекти. Излиза, че колкото повече се фокусирате върху контрола, толкова по-вероятно е да работите върху нещо, което носи минимална полза.

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

И още:

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

С тези си думи, Том ДеМарко направо разбива концепциите за управление на проекти, които битуват сред големите организации, но, честно да си кажа, сякаш има право. Не случайно дори и сред популярните блогъри по темата за управление на проекти и производство на софтуер се появиха разногласия и много емоционални коментари. Предлагам ви да прочетете мненията на Jeff Atwood, който подкрепя идеята на DeMarco, и на Glen Alleman, който я отрича.

Разбира се, задължително прочетете статията на Tom DeMarco (в PDF формат).

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

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

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

Софтуер за Code Reviews само за $5! 5-дневна оферта

Майк Рам — Tue, 14 Jul 2009 09:28:43 +0000

Компанията SmartBear чества излизането на версия 5.0 на техния основен продукт CodeCollaborator и предлага невероятна оферта продавайки пакет от 5 лиценза за техния олекотен продукт CodeReviewer само за $5!

Офертата е валидна само за 5 дни: от 13 до 17 юли 2009 г.

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

За $5 вие не получавате основния продукт CodeCollaborator, който е изключително богат на възможности, а неговия “по-малък братовчед” CodeReviewer, който е с малко по-ограничени възможности. Можете да видите разликите между двата продукта тук , но веднага става ясно, че възможностите на CodeReviewer са задоволителни за всеки екип, койтоиска да подобри практиките си на писане на програмен код, а цената е повече от атрактивна.

Не пропускайте тази възможност – струва си!

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

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

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

Майк Рам — 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:

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

Предимства на комерсиалния софтуер пред open source решенията

Майк Рам — Tue, 07 Apr 2009 05:10:15 +0000

Отношенията между потребителите на комерсиален и open source (OS) софтуер са като между заклетите фенове на двата най-големи футболни отбора у нас – фанатична вярност към любимия отбор и неизкоренима омраза към врага. При производителите нещата стоят малко по-разумно – една голяма част от тях търсят успешни бизнес модели както в комерсиалните, така и в OS продуктите и мое би това в най-голяма степен важи за малките производители, които на запад вече си имат собствен термин – micro ISV (mISV).

Един такъв производител е Patrick McKenzie, разработващ софтуер за печатане на карти за Bingo в помощ на учителите и автор на блога MicroISV on a Shoestring. Той е публикувал една интересна статия, в която изтъква предимствата на комерсиалния подход пред open source решенията, прилагайки аргументи, върху които си струва да се замисли човек.

За да парира всякакви недоброжелателни критики, Патрик категорично декларира почитанията си към OS идеологията, както и факта, че сам той е активен потребител и разработчик на open source продукти. Но, когато е търсил решение какъв подход да избере за своя продукт, Bingo Card Creator, той е търсел аргументи, които да противопостави на онези малки проекти, които “вършат полезни неща за хората, и за които никога не сте чували”. Не забравяйте, казва той,

Не всички open source продукти са Firefox и също така не всички комерсиални продукти са Microsoft Office.

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

Маркетинг

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

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

Тук съм склонен да се съглася с него, доколкото повечето OS продукти се правят само от програмисти и просто нямат (достатъчно) специалисти в предметната област. В този смисъл, това е нормално поведение на всеки програмист – да се интересува само от изработването на продукта, а не и от неговото практическо приложение при клиента. Т.е., такива проблеми би имало и в една комерсиално работеща компания, ако те се състои само от програмисти. Разликата е, че във фирмите, разработващи комерсиален софтуер, има и маркетинг специалисти (вкл. и бизнес анализатори), докато в повечето open source проекти няма.

Дизайн

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

Може би наистина повечето OS проекти разчитат на доброволно участие – аз лично не съм правил такова проучване, но като знам, че само в SourceForge има над 170 хиляди проекта, дори финансовата подкрепа на някои компании-гиганти като Sun и IBM е просто капка в морето на фона на общия брой проекти. В крайна сметка, моят практически опит също показва, че като резултат, на OS софтуера му липсва както usability, така и естетически вид.

Опита на потребителя

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

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

Документация и поддръжка

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

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

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

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

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

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

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

10 умения, нужни на програмистите в следващите 5 години

Майк Рам — Thu, 02 Apr 2009 08:26:36 +0000

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

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

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

Една платформа от “голямата тройка” (.NET, Java, PHP)
Богати интернет приложения
Уеб програмиране
Уеб услуги
Умения за общуване (soft skills)
Един динамичен или един функционален език за програмиране
Гъвкави методологии
Познания за предметната област
Професионална “хигиена”
Програмиране за мобилни устройства

Авторът хитро е избрал предвижданията си само за срок от 5 години, за да бъдат по-реалистични, но от друга страна, в някои от тях няма нищо радикално. Ясно е, че днес сигурно над 90% от софтуерните проекти се разработват на .NET, Java или PHP, така че никак не е трудно да се предвиди, че този пазарен монопол ще продължи поне още 5 години. Дори и да се появи някаква революционно нова платформа, тя не би могла за толкова кратко време да измести тези гиганти от пазара.

Под “богати интернет приложения” авторът разбира предимно Flash и подобните нему технологии. Тук би могло да се поспори. Тези технологии не съществуват от вчера и все още не са успели да се наложат масово. Аз лично ги намирам неудобни за ползване, а в интернет все още важи максимата, че “съдържанието е цар”. Не виждам причина това да се промени в следващите години.

“Уеб програмиране” пък означава познания по HTML и CSS. Днес в по-големите компании има доста тясна специализация и онези, които специализират в CSS не се занимават с програмиране на .NET например. Същото се отнася и за функционалните езици (т. 6). Не мисля, че е възможно всеки програмист да притежава всички изброени технически умения, а и не е нужно. Нещо повече, липсата на конкретна специализация би могла да създаде впечатлението, че човекът е разпилян и да бъде пречка за намирането на добра работа, доколкото доказаният опит в една определена област говори за постоянство и дълбочина на знанията.

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

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

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

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