Lazy Bastard’s Blog

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

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

За този конкретен пост бях провокиран от скоро�?ните мисли Кхой Вин – дизайнер, който понастоящем е нещо като уеб арт директор за NYTimes.com, а доскоро работе�?е в едно от любимите ми дизайнерски студиа – Behaviour. В The Elements of Style Manuals, Part One и The Elements of Style Manuals, Part Two Кхой разказва основно за ръководствата за стил (от англ. style gudes – документи, които придружават крайния продукт от работата на графичния дизайнер и обясняват как трябва да се използва той в различен контекст. Примерно, ако продуктът е корпоративна идентичност ръководството за стил ще обяснява как да бъде използвана тази идентичност в различни медии – печат, телевизия, интернет).

Тези ми ти ръководства имат редица проблеми, които са добре описани от Кхой, а ето какви са те и според мен:

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

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

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

За толкова голям проект като системата, която правим за УМГ обаче дори толкова полезен инструмент като на�?ите прототипи не може да свър�?и цялата работа. Все пак ще�?е да ни се наложи да документираме по-подробно както насъбраните изисквания, така и спецификациите за проекта. � то в продължение на целия проект (ще приключи към пролетта на 2007 година). � то при непрекъснато настъпващи изменения – все пак никой не е в състояние да проектира толкова голяма система още в началото, предвиждайки всички случаи на употреба, проблеми, ограничения и нови възможности.

Само че, горчивият ми опит с поддържaнето на подобен род спецификации ме накара да се замисля за по-добър начин за опсиване на нещата. Word, Excel и Visio са прекрасни продукти, но когато един документ трябва да се обновява непрекъснато за по-дълъг период от време и от повече хора настава едно тотално мазало. �мейлът пък има свойството да е прекалено обвързан с времето – в смисъл новите неща изместват старите на заден план, независимо от това, че старите могат да са доста важни.

� така, имахме нужда от средства, чрез което:

• Да документираме всичко, което става в проекта
• Да държим описанията на едно място
• Описанията да са достъпни от всички участници
• Всички да могат да допринасят за описанието
• Да можем лесно да следим развитието на един документ
• Ако се наложи да отменим някои нововъведения и да върнем стара версия
• Евентуално да навържем всички описания в една стройна и цялостна картина

Ако този списък те е навел на мисълта за Wiki (Wiki, като във Wikipedia), то значи сме на една вълна.

�нсталирах за около 15 минути вики на един от сървърите ни. Трябва�?е ми още около половин час, за да разуча как се работи с него. � започнах да нахвърлям първите си записки по проекта (мисля, че бяха основните случаи на употреба – a.k.a. use cases).

Това се случва и досега. Основната част от документацията към проекта е във викито. Освен това разбира се имаме и доста подробен прототип, схема на базата данни (която скоро едва ли ще се побира на чар�?аф А3/А2) и спецификации на сървърите, на който ще работи системата.

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

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

Както казва Кхой Вин:

But in another sense, wiki-driven style manuals are truer to the often touted idea that the best design solutions are in fact living systems that can grow and adapt with changing needs. It’s the 21st Century, after all, and we should be documenting our design in a 21st Century fashion.

This entry was posted on Thursday, March 9th, 2006 at 11:17 pm and is filed under В работата, Основното. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.