Bulgarian Experience

Процес

За ролята на клиента в един софтуерен проект

Tuesday, October 30th, 2007

Tru цитата, които ми харесаха от последните два дни:

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

От поста Серые будни: продавая Rails клиентам в Less is more.

и

I’ve written previously about using an envisaging team to scout out ahead. Not to design the solution but to understand the problem space - understand what the business needs, what users need, who the users are and what the technology ecosystem looks like - and report this back in a coherent fashion to the rest of the team. This isn’t Big Design Up Front by another name. The envisaging team’s work should be limited to discovery work only. This combined with regular rounds of user testing between each iteration - the results of which are fed into the next round of development - can mean that agile software development can be highly user focused.

От поста Making Agile User Centered в Derivadow.

Още: 

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

От поста Без “мениджър” в 3atwork.com

Ако някой не се оправя с превода - да свирка.

links for 2007-04-05

Thursday, April 5th, 2007

Връзка: Garrett Dimon / Documenting Interface Design

Monday, January 29th, 2007

Garrett Dimon пише за документирането на интерфейс дизайна. Идеята му е, че стандартната документация, която познаваме и ползваме е безполезна и неизползваема. Решението му се състои в това да се проектират отделни модули (тухли) от функционалността и интерфейса, които после могат да бъдат описани на една страница. Ако описанието е по-дълго, значи са прекалено сложни и трябва да бъдат разбити на по-малки блокчета. Надявам се коментарът, който оставих под поста да бъде одобрен, защото там споделям една практика, която използвам отскоро за докумнетиране на interaction design-а.

Софтуерните разработчици са като колите

Wednesday, November 15th, 2006

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

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

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

Цялата презентация е много интересна също така, макар до известна степен да повтаря предишната, за която писах.

Данни за употребата на сайта

Monday, January 17th, 2005

Последна промяна: 25 януари 2005. Новите неща са маркирани с жълто.

Данните за употребата на един сайт са от решаващо значение, когато дойде време да се правят промени (а промени трябва да се правят непрекъснато!).

Защо са важни?

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

Пример
Проблем:
В сайта на моята фирма представяме многобройните си уникални и висококачествени продукти, които отговарят на всякакви човешки и нечовешки нужди. Самият сайт е доста добре посещаван и дори беше в „Избор на редактора” на Гювеча. Но защо имам толкова малко поръчки през сайта?Възможни причини: Може би твърде малко потребители успяват да получат достатъчно информация за продукта и съответно не могат да вземат решение за поръчка. Ако все пак продуктите са представени добре, какво е сбъркано?

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

Как се събират данни за употребата на сайта?

Данни за употребата се събират по много различни начини, но най-често не се събират изобщо .

Броячи

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

Лог файлове

Лог файловете пазят подробна информация за всяко действие на потребителя. Това обаче не е съвсем вярно, когато сайтът е с предимно динамично съдържание (примерно, всички статии се викат от базата данни от скрипта article.php посредством някаква променлива [article.php?id=21] . В този случай сървърът записва в лог файла единствено това, че потребителят е изпълнил скрипта article.php , но не и че е прочел статия с ID=21 .)

Лог файловете са трудни за анализиране тъй като представляват огромни текстови файлове с информация, неудобна за четене от нормални хора. Това налага използването на специален софтуер. Добрият софтуер за анализ на лог файове е скъпа работа ( WebTrends Log Analyzer ще ви струва близо хиляда долара).

Системи за управление на съдържанието

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

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

  • Колко души посещават сайта? (уникални и презареждания [hits] )
  • Колко души посещават отделните страници на сайта? (презареждания). Имам предвид всяка страница, а не просто product.php.
  • На кои страници най-често потребителите обикновено започват да разглеждат сайта?
  • На кои страници най-често потребителите спират да разглеждат сайта?
  • През кои страници минават потребителите, движейки се от начална към крайна страница?
  • Колко време им отнема това движение? Колко време отделят на всяка отделна страница?
  • Кои връзки върху страницата кликат най-често (понякога на една страница може да има две и повече връзки към една и съща дестинация, но да са на различи места – в навигацията и в текста)?

Това съвсем не са всички метрики. В момента се сещам за статистиките от банерните системи, които използват някои сайтове. Или пък отношението между боря посетители и броя на посетителите, които са станали клиенти на сайта (ако е комерсиален сайт)? И т.н. и т.н.

Колкото повече (като количество и разнообразие) данни, толкова по-добре.

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

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

Какво да правим с всички тези данни?

Да ги анализираме. Да видим къде силните и слаби места. Да създадем конкурентно предимство.

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

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

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

Продължението следва съвсем скоро.