PM Stories

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

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

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

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

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

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

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

Управлението на проекти е организиран здрав разум

Майк Рам — Tue, 14 Apr 2009 14:53:30 +0000

Project Management Institute (PMI), може би най-авторитетната организация в областта на проектното управление, издадоха нова, четвърта версия на основния си документ – The Guide to Project Management Body Of Knowledge (PMBOK®) – и в същото време създадоха серия от стандарти, които дефинират “правилния” начин за управление на проекти.

За съжаление, новата версия на PMBOK® се различава от предишната съществено, което повдига въпроса доколко това може да бъде стандарт, след като постоянно се променя?

Този въпрос поставя и Dr. James T. Brown в своя блог. Една от ключовите промени, която според него не само е ненужна, но и ще обърка твърде много практикуващите проектни мениджъри, е подмяната на тройката ограничения (обхват, срок, цена) с шесторка – обхват, качество, срок, бюджет, ресурси и риск. Тук наистина може да се спори дали някои от тези характеристики не са част от другите.

По този повод той казва:

PMI нарича едно нещо “стандарт” и след това го променя. По-лошото е, че така изпадат в риск да девалвира стойността на PMP сертификатите, защото сега проектните мениджъри ще се сертифицират върху нов набор от основни понятия… Един стандарт не е задължително да бъде перфектен, но той трябва наистина да бъде стандарт (т.е. установен), за да може ефективно да изпълнява целите си!

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

Управлението на проекти не е нищо друго освен структуриран и организиран здрав разум!

Толкова е просто и в същото време толкова трудно за изпълнение…

Вижте тук за повече информация относно промените в четвъртата версия на PMBOK®. Самият документ може да се купи от сайта на PMI. За съжаление, не се разпространява безплатно.

Гласувайте за тази статия в 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: