Внимание към детайла - отговорност на екипа?
Фраза, която чуваме всеки ден. Германците правели бирата с внимание към детайла. Новата toyota била изработена с внимание към детайла. Четем го и в изискванията за работа на много IT работодатели. Нееднократно съм го чувал - “ако работиш за нас, очакваме от теб да се отнасяш към детайлите с внимание.”
Какво обаче значи да правиш софтуерен продукт с внимание към детайла? Можем ли въобще да го третираме и изискваме като индивидуално качество? Възможно ли е даден член на екипа да бъде “човека, дето внимава и за другите”? Могат ли останалите преспокойно да се оставят на творчески полет, оставяйки довършителната дейност на другия човек?
Според мен - не. Преспокойно можем да приложим правилото - “Една тълпа е толкова тъпа, колкото е тъп най-тъпия човек в нея”. В нашия случай - един продукт ще бъде изпълнен с такова внимание към детайла, колкото му е отделил най-мърлявия член от нашия екип. Или колкото внимание е вложено в най-незначителната и претупана част от него. Дейностите и производните произведенията (опит да преведа “deliverables”) взаимодействат толкова тясно помежду си, че на практика е невъзможно да направиш една част добра и изпипана сама по себе си. И дори това да стане, кофти изпълнението в останалите я обезсмисля.
Примери за това много - уеб решения с добър визуален дизайн, но кофти код, или обратното. Добре направени такива, лишени от качествено съдържание. Или пък самоцелни разработки, направени без всякаква идея за тяхното прилагане и внедряване.
При нас е така, кой е виновен?
Подобно на образователните филмчета в demotivation.dom говорим конкретно и поименно - всеки един от нас. Както вече споменах - нещата са навързани. Ако считате, че дадена (не вашата разбира се, ние сме най-добрите) част от продукта е направо срам за работата ви, или че колегата си върши работата през пръсти - замислете се. Дали неговата работа не зависи от това как вие сте си свършили вашата? И дали той не се нуждае от вашата помощ? Дали наистина парчето от работата ви е изпълнено достатъчно качествено? Дали неговата “липса на внимание” не е заради това, че някой друг е “изял” цялото време и бюджет с някой “шидьов’р”? Без да навлизам във вечните теми за вредата от егото и ограничения мироглед, искам да отбележа колко несъстоятелна е фразата “аз си върша моето добре, другите са виновни”. Която, признавам си, нееднократно съм си мислел и казвал.
- Добре, но ние сме в България.
- И сроковете са кратки.
- И пари няма.
Хубаво де. Тогава нека да правим по-малки неща. Нека да не направим тоя feature въобще. Никой няма да умре, ако апликацията ни не се предлага и с розов десен на цветенца. И с вградено пони. Но да не претупваме нищо. Рано или късно претупаното ще се върне с все сила. Освен ако не сме се специализирали да произвеждаме неща, който не се ползват. Ако това важи за вас - просто игнорирайте всичко писано по-горе.
Януари 28th, 2006 at 1:05 pm
Доста добре казано. “Една тълпа е толкова тъпа, колкото е тъп най-тъпия човек в нея”.
Аз бих го казал “Един екип и толкова добър колкото е добър най-слабия от него”. И като говориме за екипи, всичко което казваш е в резултат на липсата на екипен принцип на работа в България.
Хайде да помислим кой ни учи на екипна работа в България, като започнем от децката градина та доживот.
Да правим по малки неща, още по добре казано. Обаче българите сме родени за велики дела и това да си продавачка или чистач е унизително. Но виж програмист, “това звучи гордо…” и от там се почва, това не е за мен това е под моето достойнство. Не е специфично за професията но е доста разпространено и за съжаление всъщност опира до човека в теб и до колко те мързи и до колко те дразнят грозните(разбирай неизпипани) неща.
“Претупаното ще се върне със все сила”, само който не му се е налагало да си разширява собствените бози не знае за какво става дума. И в този смисъл пожелавам на всички разработчици да им се наложи да си променят собствения код, много е назидателно и няма нужда втори път да ти казват защо трябва да пишеш така че да може да се раширява и поддържа код-а ти. Е естествено освен ако не си тъпоумен, небрежен мазохист с засилваща се деменция тогава и господ да слезе и да те държи за ръката докато правиш софтуер най много да то питаш защо не е използвал Унгарската конвенция като си е кръщавал Ангелите.
Е хайде стига толкова работна философия за събота сутрин
Януари 28th, 2006 at 7:40 pm
Да - и затова е много полезно хората да си довършват нещата, които почват, да не бързат моментално да се “изнесат” от кофтия проект, който те самите са натворили и да ходят да инженерстват поредният булшит, без да са изпитали гнева на клиентите и колегите, които трябва да правят фиксовете и следващите версии.
Сменянето на проекти / дейности е нещо полезно едва след като хората са минали майндсета и този проблем, който описвам горе.
Януари 29th, 2006 at 11:57 am
Quality is never an accident
Февруари 2nd, 2006 at 2:35 am
Аз съм тъпо кучи и нищо не разбрах…
Февруари 2nd, 2006 at 2:39 am
Скоро в книгата на Джоел Сполски за потребителския интерфейс видях цитат от Талмуда, в който се обясняваше, че малките неща са важни, защото се натрупват и водят до големи промени.
Знам и един цитат от Кент Бек в подобен стил: “I am not a great programmer — I am just a mediocre programmer with great habits.” Точно навиците са тези, които ни учат да оправяме подробностите без да мислим и така да доближаваме качеството. Променяме навиците си, подобряваме качеството, служим за пример, други хора променят навиците си, проектът отива към хармония.
Февруари 2nd, 2006 at 2:52 am
Добър пост!
Наистина един екип е добър колкото най-слабото си звено. В България, за нещастие, “екип” в софтуерната индустрия е почти винаги оксиморон. Случва се един човек да се “раздава”, за да стане проекта изобщо… Дори и да има хора, които си бъркат в носа, чат-пат има някой, който се опитва да свърши тяхната работа - the hero… Дали е правилно - не е; дали се случва - о, да. Остава въпросът “Искам ли аз да съм този герой?”.
Февруари 19th, 2006 at 8:32 pm
чудесен пост!
Още на есенцията “Възможно ли е даден член на екипа да бъде ‘човека, дето внимава и за другите’?” вече почти ръкоплясках. За мен вниманието към детайла е част от културата. Една идея по-развито съзнание за детайл, една идея по-зрял човек, една идея по-лесно се работи с него, една идея по-добър екип.
Оообаче, къде ни ги казват тия неща от рано? Учудвам се колко неща ей така откриваме по трудния начин!?
Февруари 19th, 2006 at 11:34 pm
малко късно коментирам обаче бавно чета
Таа според мен целта не е всеки да свърши по нещо & после частите магически да станат едно цяло. Отделните елементи придобиват завършен вид когато всички имат идея какво искат да направят & са готови да критикуват и бъдат критикувани, респективно да се хвалят. В този ред на мисли при тестването е много полезно всички да разглеждат продукта - всеки го вижда по различен начин и съответно всеки хваща разнообразните, неизбежни грешки. Bugfix-ването е забавно - поне когато се прави преди старта, след това е изнервящо, ерго тествайте много преди да обявите ‘нещото’ за готово.
Май 1st, 2006 at 3:10 pm
Ха кво яко писане:)))
Ми аз съм малък и много не разбирам, цъкам картинки и мисла интерфейси и си комуникирам с програмисти и нема драма. Опитах точно този подход с обмислянето на детайла с разпределението на задачите без изолация от общата работна схема на продукта, всичко беше ок докато по средата на процеса клиента обърна всичко наобратно и за мен от цел качество задачата се превърна цел работещо приложение в срок ( е пак спасихме нещо ма нее тва дето тряше да стане). Та според мен в идеална среда ( техническо задание по което се върви без изненадващата намеса на клиента) е възможно да има поглед върху детайла при условие че екипа е 100% мотивиран и отдаден на целта, което означава, че личното мнение на отделния човек в отбор Черешка няма особена стойност преди да се чекне от всички ъгли. И въпреки приказките по-горе резултата от задачката беше че съм на загуба защото срока на работа се увеличи с месец и половина И печалбата отиде в изънредни хонорари. Та едно е да искаш, другое да можеш и трето е да стане:))))