Компютърна поддръжка от Модус 2 ООДКомпютърна поддръжка

+ Компютърна профилактика;
+ Инсталация, конфигуриране;
+ Антивирусна и спам защита;
+ Сервизно обслужване;
+ Архивиране на информацията;
+ Контрол на достъпа;
+ Мрежи - дизайн и конфигуриране;
+ Сървъри - за приложения, файлови, за ел. поща и уеб;
+ ... и много други според вашите конкретни нужди.

Осем правила за ефективно правене на софтуер

Осем правила за ефективно правене на софтуер

ОТ TIMOFEY NEVOLIN - DEVELOPER @ TOPTAL

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

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

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

За кого е това?

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

Правило 1: Разбирайте манталитета на ИТ

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

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

Никога не следвайте инстинкта си или не вярвайте сляпо на чувствата, включително и на вашите собствени.

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

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

Правило 2: Не смесвайте методите за произвеждане на софтуер и програмирането

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

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

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

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

Правило 3: Използвайте постоянно място за информацията като разширение на своята човешка памет.

Човешката памет, въпреки че е със забележителен капацитет, има своите ограничения. Вие помните неща с несравнима точност и за дълго време, а когато ги забравите, няма начин как да ги припомните, ако ви потрябват.
Именно затова използваме постоянна памет, в която запазваме информацията с предварително зададена скорост. Не става дума за формалната документация като например ръководствата за ползване, които създаваме след написването на софтуера, за да могат да ги ползват други хора. Става дума за документи, които представляват разширение на нашата памет, които ни помагат да работим.
Препоръчвам да документирате вашите мисли и планове в процеса когато се сблъскате с нетривиална задача или със задача, която замесва повече от един човек. Опитайте да го направите по-леко ако е възможно. Не създавайте формални документи с логото на компанията ви на тях. Добро средство например може да е фирменото wiki, в мястото за вашия проект. Създайте отделни страници за задачи или проблеми (30 секунди). След това обновявайте всеки път, когато имате идея или го обсъждате с другите.
Можете даже да прекъснете разговор и да обновите записа веднага, още докато мисълта още е в главата ви. Ако сте в среща си кажете “момент, задръжте за да запиша това” и за 10-30 секунди го изразете в писмен вид. Записаното не е нужно да е изчерпателно, но трябва да бъде завършено и кохерентно, като прехвърлянето на идеята напълно на хартия. По-късно, когато някой друг го прочете, трябва да може да го разбере толкова ясно, колкото вие го разбирате сега. Този номер спестява много време, като същевременно ви позволява да документирате в движение.
Тази техника има две цели:

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

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

Правило 4: Спрете да губите време за формално определяне на сроковете

Никои два проекта не са еднакви. Следващия път, когато правите нов проект, ще имате различни клиенти, различни цели, различен екип, а може би различни технологии. Даже ако използвате стандартни инструменти и компоненти, все пак ще се наложи да промените тяхната конфигурация и архитектура. Когато се занимавате със софтуерни проекти, имайте предвид, че те включват между 50% и 100% работа за персонализиране. Те се нуждаят от изследвания, дискусии, мислене, проби и много други дейности, които е трудно да предвидим. На практика може да се окаже, че има голяма разлика от това, което се показва на повърхността и е уж точно същия тип софтуерен проект, който сте правили и преди. Ако новият проект е друг тип, е почти невъзможно да оценим точно приликата и различията.
Ако е толкова непредвидимо, тогава как ръководителите на проекти могат да представят график на проекта и да се придържат към него?
Има един формален метод да го направим, който е предтсавен в литературата: именно да разделим целия проект на по-малки стъпки, да оценим времето за всяка стъпка и след това да оценим дължината на целия проект като съберем дължината на отделните парчета. Има тонове теории зад този метод, които се изучават в много курсове по MBA. Този метод е пословично неточен до степен, че е напълно неизползваем и непрактичен, без да говорим колко време отнема. Аз никога не съм виждал ръководител на проекти, който да използва формални методи за изчисление без донагласяния, даже и сред фанатиците на методологията. Не стана даже когато фирмата строго наложи използването на такъв метод. Всъщност най-резултатните мениджъри използват напълно различни алтернативни методи, които ще опиша по-долу:

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

Бих искал да подчертая две важни последствия от гореописания метод.
Първо, точността на преценката се подобрява с набирането на опит. Няма начин един човек без опит, с каквато и силна методология да е въоръжен, да е добър в това.
Второ, даже и най-добрата оценка е добра само от статистическа гледна точка. Това значи, че някой може да каже, че даден проект може да отнеме между 4 и 12 месеца. Ако това е вярно, всеки трябва да разбере, че съществува 50% шанс проекта да продължи повече от 8-те месеца средно време.
Разбирайки статистическата прогноза за реализация - има забележителен ефект. Мъдрият мениджър ще сложи оценка 12 месеца на такъв проект и ще поздрави всеки при предсрочното завършване. С други думи, никой не трябва да очаква екипа да следва разписанието на проекта ден за ден.
Общ съвет към ръководителите на проекти и техните шефове е да спрат да губят време във формални методологии за оценка. Вместо това да окуражават събирането на статистическа информация за продължителността на проектите и да споделят тази информация вътре във фирмата. Знам за фирми, където този подход е приложен на ниво цялата фирма, позволявайки чудесна точност на прогнозите.

Правило 5: Осъзнайте каква е цената на превключване на задачите и сменяне на приоритетите

Човешкият ум е забележително конструиран от природата. Въпреки че е невероятен, той има своите ограничения. С други думи, той е направен да изпъква в някой области и при определени видове задачи.
Ума на разработчика е несъмнено голямо предимство при разработването на софтуер. Вие, като ръководител на проекта, бихте ли искали да го познавате по-добре и да го накарате да работи най-добре? Нека го формулираме най-просто, като не използваме твърде много теория. Спомнете си, че теорията ви откарва твърде далеч преди да искате да се научите от опита, както вашия, така и на останалите. Човешкият ум има голям потенциал за решаване на задачи и за генериране на идеи. За съжаление не е възможно винаги да се докоснете до този потенциал, главно защото за да подкрепите генерирането на идея, трябва да съберете заедно всички парчета от задачата във вашата активна памет едновременно. Затова, именно разрешаването на сложни задачи, минава първо през етап на опростяване, където задачата се генерализира и преформулира, за да се изолират не толкова важните парчета и да се намали броя елементи, които се пазят в паметта едновременно. С други думи ние можем да разрешим една много ограничена сложна задача или няколко по-прости задачи.
Но пропорцията не е линейна. Ако увеличите броя неща, които правите едновременно, драстично ще нарушите способностите си да решавате задачи. Именно затова човечеството винаги е наемало хора за разделяне на ролите като оптимизиране на живота. Двама човека, които работят отделно върху две задачи ще ги решат много по-бързо, отколкото ако всеки работи по всяка от двете задачи едновременно.
Друга важна черта на човешкия ум е неспособността му да превключва между задачите мигновено както го правят компютрите. Наистина вие не можете волево изведнъж да спрете да мислите за нещо. Не можете също така пълноценно да започнете да мислите за една нова концепция мигновено. Този вид мисловна инерция е обяснена идеално при операторите на въздушния трафик. Въпреки че те гледат радара и виждат цялата картина, те трябва да я заредят в тяхната памет, за да реагират бързо. Новият оператор трябва да гледа екрана около 10 минути преди да може да замени стария, чиято смяна изтича. Факта че не можем да забравим нещата с волята си влошава картинката още. Всичко, което сме научили стои с нас и само бавно избледнява с времето като заема място, което бихме могли да използваме за ново знание. Още по-лошо, този ефект се усложнява от чувството за “несвършена работа” понякога. Много по-лесно е да забравим нещо, което е завършено и от което няма да се нуждаем в близкото бъдеще. Когато слагате неща настрана, за да ги свършите по-късно, вашият мозък им слага етикет “за бъдещо използване”, като не позволява на ново знание да заеме тяхното място.
Сега, когато сме очертали идеята с превключването между задачите, нека видим как тя работи в реалния живот (така да се каже) чрез експеримент. Представете си, че имате 10 програмиста, които работят по 10 задачи - по една задача на човек. Ако приемем, че може да ги сложим в една идеална среда без странични смущения, всяка задача може да бъде свършена за дадено време от един мозък. Цялото изпълнение ще отнеме времето за изпълнение на най-дългата индивидуална задача. Сега нека повторим същия експеримент. Този път ще превключваме задачите между програмистите без някаква важна причина. Всеки ден всеки програмист получава нова задача, по която да работи. Още по-добре да превключваме задачите всеки час. Колко бързо ще завърщат задачите? Какво мислите? Може би никога. Ръководителят на проекта в първия сценарий можа да направи проекта ефективно. Втория успява да го екзекутира, това е сигурно… в смисъл, че успява осигури смъртта му. Поздравления. Тази техника за убийство на проекти е изключително ефективна защото е не само губенето на време, а и също така сваля мотивацията на хората до нула. Когато хората се сблъскат с този вид “въртележка на задачите”, те губят всякакво чувство за постижение и разбират, че проекта не води до успешен край. Повечето хора ще се съгласят с горния пример, когато той е представен пред тях по чисто академичен вид както тук. Само че в реалния живот много бързо забравят всичко, когато са подложени на най-лекото натоварване. Големия бос иска отчет за напредъка или пък клиента иска някаква дата в бъдещето, когато ще се въведе в действие - почти всяка външна случка може да накара ръководителя на проекта до отиде при екипа и да изрази неговата загриженост, последвана от вълна от пренасочване на задачи и игра с приоритетите в опит да спечели време тук или там, което неминуемо води до нищо друго освен изхвърлянето на проекта окончателно извън графика. За съжаление този сценарий от релния живот се случва доста често.
Добрият мениджър седи и предпазва екипа от такива малки смущения като поема шоковата вълна и я превръща в неща, които трябва да се дискутират продуктивно в бъдеще. Това е доста трудно да се постигне емоционално, но е единствения начин да държите екипа в добър работен ритъм и да има даде възможност да произвеждат.

Правило 6: Използвайте архитектурни обзори като начин за подобряване на дизайна

ИТ ундустрията работи с понятия като над и под - инженерство.(или недонаправено и твърде добре направено) Когато е на интервю, всеки казва, че над-инженерството е лошо. Това е лесен отговор, защото въпросът сам по себе си носи “над”, което означава твърде много. Реалното практическо ноу-хау е да разпознаеш кога твоята архитектура е станала над-инженерна и да го предотвратиш на ранен етап.
Нека ви дам няколко от моите изстрадани аргументи за това.
Първо, решението може да се смята за над-инженерно ако съществува друго по-лесно решение, което носи исканата функционалност. Това означава, ако не знаете по-лесно решение, тогава най-лесното, което може да предложите е най-доброто във вашите очи, освен ако някой не докаже, че грешите.
Ако нашият измислен архитект се бори за перфектното решение, обичайният обзор на архитектурата гарантира, че е достатъчно оптимална. За съжаление обаче архитектурният обзор изисква поне няколко други квалифицирани архитекти. Има опасност да не е наличен или да не е практичен в много от случаите. Ако липсва проверка от партньори, архитектите са склонни да допускат често срещани грешки. Нека ги изброим една по една и да отбележим как могат да се избегнат. Една от най-популярните грешки е да конструираме без да отчитаме целта на бизнеса. Изглежда очевидно, че всяка работна дейност трябва да е обвързана с удовлетвореността на клиента накрая, с успеха на фирмата или друга подобна цел на бизнеса. И все пак често можем да видим една архитектура, която е конструирана цялостно или частично без да се отчитат такива цели. Или липсва причина за това или се търси използването на колкото се може повече модерни хватки и прийоми. Архитекта в този случай не прави това, за което е заплатил клиентът. По-скоро те си играят с готини играчки за тяхна собствена наслада и забавление. Това по никакъв начин не е допустимо във формалната индустрия. И все пак това се случва въпреки всичко.
Понякога проблемът е в характера на архитекта и неговата обсебеност от дадени средства и технологии. Той просто обича да ги използва и не може смислено да обясни какви нужди на бизнеса се опитва да задоволи. Близко до този случай е друга ситуация, при която хората не знаят нищо друго, освен да изграждат нещо от малки парчета. Със сигурност всяка външна случка провокира желанието им да се потопят в света на дизайна и никога да не се върнат обратно при реалния клиент. Въпреки че началното въздействие може да е рално бизнес мотивирано, продължителното им откъсване от реалността, намалява полезността на тяхното творение. Лекарството за това е много просто, но изиква самодисциплина. Добрият архитект не трябва да докосва писалото и хартията докато не си е изяснил честно и да си е отговорил защо е нужно това. Такава нужда може да има в различна форма. Може да бъде общо изискване, важна нужда от подобрение на продукта или появата на нови технологии, които правят предишния дизайн по-малко ефективен. Във всеки случай това не трябва да е формалното основание, ако архитектите осъзнават каква е причината за промяната. Тогава те могат да използват тази причина като крайна проверка за качеството на техния дизайн.
Друг трудно откриваем проблем е свързан с мисленето за блокова архитектура. Хората с такъв манталитет вярват че има решение за всяко нещо и решението винаги се прилага като строежа на блок. С други думи, те прехвърлят функционалността към компонентите директно без да оценяват архитектурата като цяло. Те например могат да присъединят компонент, който постига дадена искана функционалност към системата, когато се появи нуждата от такава функционалност. В повечето случаи това задоволява формалните изисквания, но оставя системата в непоследователно състояние. Новият блок не е избран с оглед съвместимостта му с наличната система или с поддръжката му или даже с лицензния модел на фирмата. Така екипът се опитва да промени текущата конфигурация или да добави тази функционалност към капацитета на наличната система. В резултат, поддръжката на системата постепенно се превръща в заплетен кошмар, който е последван до намаляване на ефективността.
Няма лесно решение за този проблем, тъй като конструирането на системата е изкуство и никога не е възможно да предвидите дали един нов компонент трябва да бъде добавен или може да бъде изпуснат. Може би най-добрата практика трябва да е да си пазим архив на проблемите в архитектурата и поддръжката, които са се появявали във времето, които да са последвани от периодични прегледи на цялостната архитектура на системата. Тези периодични прегледи могат да извадят на показ нови технологии, които междувременно са се появили, които да се вземат в предвид. Така главната причина на архитектурните прегледи трябва да е не да се решават проблеми, а да се оцени потенциалната приложимост на някои желани подобрения и на системата като цяло, за да се предпази тя от заплахата да стане старомодна и отживяла.

Правило 7: Оценявайте екипните играчи

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

Комуникативността

Първото и най-важно качество разбира се е способността да общува.
Представете си човек с нула способност за комуникация. Със сигурност ако не получават обратна връзка от останалите от екипа, те са напълно безполезни. Очевидно никой не е измерил това умение по време на интервюто, смятайки че това качество е на достатъчно добро ниво, щом човекът може да говори добре.
Комуникирането не бинарно да/не качество - то е повече прозорец за трансфер на информация. Колкото е по-широк прозореца, толкова по-бърз и точен е обменът на информация. Умението да комуникира умножава всички останали качества на човека.
Тъй като размера на този прозорец варира в големи граници, измерването на ширината му е важна характеристика на екипния играч. Имайте предвид, че говорим за прехвърляне на информацията в този смисъл, а не в смисъла на гладко говорене, или за окуражаване на хората, или за мотивирането им, или за организирането им чрез говорене.
Стилът на комуникирането също няма значение в този смисъл. Информацията може да се доставя орално, текстово, чрез картинки или смесено. Човекът може да говори бързо или бавно. Той може да е приятелски настроен, като ви гледа в очите и се усмихва през цялото време, а може да гледа встрани и да говори монотонно. Стилът може да повлияе на вашето възприемане на колега ви, но докато вие ясно разбирате какво има в предвид, стила не е важен. Нека преминем към практически случаи на откриване и измерване на способностите за комуникация.
Има два важни аспекта на комуникационните способности като цяло. Първо е желанието да се споделя информацията. Някои хора с удоволсвие споделят информацията, а други предпочитат да я запазват за себе си. Това предпочитание е повече или по-малко природно, но може да се променя бавно с персонална мотивация и тренировки. Можем да приемем, че един човек който показва едно ниво на желание за споделяне на информация, ще го демонстрира в бъдеще по същия начин. Затова по този начин може да предвидим бъдещия успех на кандидата в екипа. В реалният живот хората, които се опитват да крият информацията се забелязват лесно. Те обикновено се опитват да пускат нарочно ненужна информация, вместо нещо, което наистина е нужно. Или питат предварително неща, за да обърнат информационния поток към тях и да минимизират техните отговори. Каквито и да са техните тактики, вие ще почувствате накрая, че не сте получили исканата информация от тях, или че се изискват твърде много усилия, за да се доберете до нея. Важно е да разберете намерението, тъй като от друга страна някой открит човек може да ви задава предварителни въпроси с цел да си изясни по-точно какво го питате и после да ви даде отговора по най-удобния начин. Човекът, който иска да скрие информацията ще зададе допълнителни въпроси, само за да разводни разговора, като не отговори вместо това на първоначалния въпрос.
Друга част от комуникационните умения е да се настроиш на вълната на събеседника си. Различните хора имат различно ниво на разбиране на дадена тема, различен стил на комуникация и даже различен интерес в някои специфични детайли. Някой комуникативни умни хора ще нагодят потока на общуването си според способността на слушателя да я възприема и ще си подготвят техния отговор, за да предоставят дадена информация. При такава подготовка, може да се зададат някои предварителни въпроси, за да се стесни отговора според интереса на слушателя. Способността да “тренираме”/откриваме разликите в комуникацията е наистина страхотно умение, тъй като ни позволява да постигаме разбиране в почти всички случаи. Гъвкавите говорители от друга страна, могат понякога да попаднат в задънени улици от неразбиране.

Разбиране на силните и слабите страни

Нека се фокусираме на друго персонално качество, което е жизнено важно за екипния играч.
Повечето хора ще се съгласят, че обстановката в екипа трябва да е по-приятелска отколкото средната в окръжаващия ни свят, за да подпомага сътрудничеството и да увеличава продуктивността. Затова е важно за екипа да разбира силните и слабите страни на своите членове, да разпределя задачите правилно, за да покрива слабостите и силните страни. Първата стъпка за това е всички членове честно да премерят своите способности спрямо останалите. Психологически това може да е трудно, тъй като по природа ние се стремим да скрием нашите слаби страни, за да се предпазим.
Именно тук приятелската атмостфера в екипа би помогнала.
Изграждането на доверие е работа за двама човека. Tака новият член се очаква да играе по правилата на екипа. За съжаление някои хора не могат да свалят гарда даже и в приятелска обстановка. Те се държат като вълци единаци през целия си живот. Това е по-силно от тях. За съжаление такова отношение не допринася за усилията на екипа. Има лесен начин да разпознаем тези вълци-единаци на интервюто. Те никога не признават, че не знаят нещо. Разбира се хората се стремят да покажат най-доброто от себе си, като впрягат всичките си способности докато се опитват да разрешат всеки сложен проблем. Все пак съществува граница на знанията за всеки. Нашите ограничения формират нашите умения. Ако не си признава ограниченията, това означава че кандидата се представя като “Вале на всички бои” - еднакво добър на всичко и същевременно в нищо.
Когато наемате специалист, вероятно бихте искали да се предпазите от такива хора. В допълнение на това, такова арогантно отношение обикновено идва с друго качесто за червен картон - нежеланието да помолят за помощ. Способността да помолиш за помощ е абсолютно важна за екипната работа. Без това, ние не можем да напредваме и да програмираме толкова бързо. Такъв инатлив човек ще хаби ресурсите и времето на фирмата като безкрайно се бори с някоя задача без да се обърне към своите съекипници за помощ. Има лесен начин да открием такива кандидати на интервюто. Задайте им въпрос, който е безмислен или споменете някой измислен термин. Нормалният, любопитен човек просто ще каже че не знае и ще попита какво е това. Един отбраняващ се човек никога няма да го направи даже ако кажете че няма правилен или грешен отговор и “не го знам” няма да навреди на резултат от интервюто.

Правило 8: Фокусирайте се върху организацията на екипа

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

Знания за изграждането

Всеки ИТ проект е уникален. За да сте успешни в осъществяването му, трябва да се научите и да усъвършенствате спецификите на проекта. Те могат да включват както технически, така и не-технически знания. Пример за не-технически знания може да е персонална мрежа за управление, клиенти, техническа поддръжка, екипи и др. Специалните технически знания са допълнителните детайли в добавка към общите ИТ умения.
Например, може да трябва да знаете Maven за да направите проект. Обаче точната структура, мястото на характеристиките и филтрите ще варират за всеки проект. Както с всеки тип знания, усъвършенстването на тези детайли изисква време, колкото повече време се инвестира в него, толкова по-добре могат да действат. Времето е най-ценния ресурс, който имате. Вие искате всеки член на екипа да е фокусиран върху същата функционална област колкото се може по-дълго, за да се възползвате от тяхната експертиза, за да се развият и постоянно да подобряват продуктивността на екипа.
За съжаление една дейност не е възможно да се прави за неопределено време. От една страна хората може просто да се отегчат. От друга страна, вие рискувате от това те да изгубят своите умения и така рискувате целия проект.
Нека видим дали има начин да се справим с недостатъците без да спъваме продуктивността на екипа твърде много.
Повечето интелектуални работници са природно пригодени да учат. Те биха искали да се учат в дадена област, докато не станат много добри в нея.
Разпределете областите на фокус между членовете на екипа и ги оставете да изградят знанията си във всяка една. В даден момент те стигат достатъчно високо ниво, което е релевантно по отношение на този проект. След тази етап всяко допълнително усилие да научат повече няма да увеличи знанието съществено. Без мотивация и предизвикателство, умните хора се отегчават и започват да мразят работата си. Не позволявайте това да се случи като им отворите възможности да учат в други области. Дръжте ги информирани за проектите и фирмените, технологични знания и отварящите се нови предизвикателства. Ако техният интерес е на ниво вътре в самия текущ проект, тогава получавате двойна награда като държите вашия екип с предизвикателсва напред и увеличавате полезните умения на екипа в същото време. Винаги е добре някой да направи саморазработка, за да няма отегчение, даже ако не съвпада с непосредствените нужди на проекта. Докато експертните мозъци на екипа са заети, те продължават подсъзнателно да поддържат вече научените области от проекта.
Когато напускат фирмата, експертите от екипа взимат с тях голяма порция от експертизата. Едно от средствата за противопоставяне на това, е да имате широко използвана документация, която се обновява в движение. Помислете за “постоянното хранилище памет”, за което говорихме по-рано.
Ръководителят на проекта би се радвал, ако може да дублира знанията в главите на членовете на екипа, ако е възможно. Ако имахме по двама от всеки експерт, това ще е просто решение, но ще е и двойно по-скъпо. Има обаче и по-лесен начин за това. Номера е да оставите вашите разработчици да изградят експертни знания в повече от една област, така че всяка област от вашия проект е покрита от поне един експерт със задълбочени знания. В същото време изберете няколко старши членове да изградят и хоризонтални връзки, наред със задълбочените знания. Обикновено тази роля се играе от ръководителя на екипа разработчици или от архитекта. Тийм лидера си взаимодейства с всички членове на екипа и участва в работата по всички задачи. Той може да се намеси във всеки аспект на проекта, като разбира същността му. По този начин, ако изгубите някой от експертите си, ръководителя може да поеме и да продължи развитието напред докато вие успеете да наемете и да обучите някой за смяна.
Друга разновидност на същата идея е да тренирате програмисти в съседни на колегата им области, като им позволите да наблюдават, да се учат и от време на време да опитват работата на колегите си. Имайте предвид, че това кръстосано обучение не трябва да е много подробно, за да не пречи на концентрацията на програмистите върху основната им задача и да не намалява продуктивността им. Развивайки екпертизата през ръководителите на екипа и с кръстосано обучение на програмистите ви, дава предпазен щит срещу непредвидени проблеми и ви дава по-голяма маневреност с ресурсите на проекта.

Минимизиране на разсейването

Софтуерното програмиране е верига от сложни и креативни решения на задачи. Работата не се улеснява въпреки развитието на индустрията и въпреки, че се автоматизира повече. Тя все още включва в голяма степен изкуство и индивидуален подход, който е много трудно да се предвиди и понякога още по-трудно да се въведе.
Програмистите са върха на оръжието. Тяхната концентрация е еквивалента на твърдостта на острието. Ако увеличите тяхната концентация, може да се справяте с проблемите лесно като горещ нож минава през масло. Ако ги разсейвате, те все едно ще бучат маслото със затъпена пръчка.
Не може да не подчертаем: Работа която не е свързана с решаването на задачи може да се интензифицира с мотивация и допълнителни усилия. За работата, свързана с решаването на задачи, трябва максимално да се откъснете от земния свят. Трудно е да оставите всички ежедневни проблеми зад себе си. Добрият ръководител на проекти ще изгради една тиха работна среда за физическите и умствените сетива. Работното място на програмиста трябва да е аналогично на изолационна камера.
Физически то би трябвало да се направи като затворено работно пространство. Всеки член на екипа трябва да си има своя куб, където да се потопи самотно. Препоръчително е да се избягват високи шумове и разговори на висок глас. Бързите разговори между хората ако може нека да стават чрез ел. поща или чат. Големи групи трябва да използват отделни помещения за срещи, за да не пречат на останалите. Това е обичайната картина на офисния живот. За съжаление платформата с отворените офиси се прилага все повече, даже и за големи фирми. Аз съм против тази прищявка. Още по-лошо, заедно с отворените пространства, топ мениджмънта окуражава разговорите между екипите на място. По същество това представлява да крещиш към някого от друг ред през главата на някой колега, който е зает с друго в момента.Един програмист, който е прекъсван от разговори на висок глас по 20 пъти на ден няма да има достатъчна концентрация. Със сигурност тази схема е убиец на продуктивността.

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

Знанието само по себе си е сила. Това особено важи за сложна индустрия като ИТ. Всяка задача тук си има нейния цикъл: учи, изследвай, приложи. Фазата на ученето е незаменима. Не само защото по-доброто разбиране позволява по-добро и по-бързо прилагане, има и няколко прага на знанията, които трябва да са преминат, за да се постигне изобщо нещо. Разбира се няма смисъл и от пре-учване. Всяко умение трябва да е адекватно на нуждата на продукта, а не да я надхвърля.
Все пак често програмистите са тласкани в противоположната посока; да спрат да се учат и да не правят нищо друго освен да произвеждат. Ученето се смята за изгубено усилие, което не придвижва напред показалеца за напредък на задачата. Това изглежда като много лесен проблем за разрешаване, когато седите в къщи и четете тази статия. В реалния живот обаче, най-лекия натиск върху ръководителя на проекти, го превръща в изискващ идиот, който настоява всички да спрат да учат и вече да започват да правят нещо. Кълна се че съм чувал точно тези думи много пъти през кариерата си…. Добрият мениджър и шеф на екип трябва да разбира, че ученето е важна част от процеса, даже ако не увеличава директно показалеца за напредъка на работата.

Изграждане на конкурентна програмистка работилница

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

Източник: Eight Rules for Effective Software Production