Защо техническите познания не са най-важното нещо за един програмист - история от практиката

11 февруари
Крис Шелдън, Senior Project Manager в DataArt
Защо техническите познания не са най-важното нещо за един програмист - история от практиката
Преди 12 години Крис Шелдън, мениджър на проекти в DataArt Лондон, е амбициозен разработчик, уверен, че уменията за програмиране са всичко, от което се нуждае, за да се развива в професията.

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

Ето и неговата история, която дава ценен отговор на въпроса “Наистина ли техническите умения са основни за един програмист и какво още е нужно?”:

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

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

Не всички разработчици и QA-инженери отделят значение на подобни детайли и рядко инвестират време и усилия в това да усъвършенстват своите комуникационни умения. Че защо възрастен, особено добър специалист в своята област, изведнъж да се научи да говори? Какво е това умение и каква е ползата от него в света на програмирането?

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

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

Ставаше въпрос за ATS - система за управление на кандидати за работа, която да направи възможно частично автоматизиране на процеса на наемане.

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

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

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

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

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

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

Изискванията на клиента отдавна се бяха променили, а през всички тези месеци ние бяхме разработвали съвсем различна система от тази, от която той се нуждаеше. Бележките на листовете хартия не интересуваха никого. И така разбрах основната си грешка: по време на развитието на системата нито веднъж не говорих с клиента – бях уверен в техническото съвършенство на моето творение. За това какви функции трябва да има системата и как точно реалните хора ще ги използват, изобщо не мислех.

Отговорът на клиента беше меко казано емоционален: "И къде в тази форма е полето за номера на разрешителното за работа? Как кандидатстват хората?!". Едва ли ще ви изненадам, че тогава за първи път чух за такова поле. Проектът изискваше много промени, а нивото на персонализиране на системата в крайна сметка се оказа много по-значимо, отколкото можех да си представя.

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

Решението - Agile: без повече листа

Липсата на опит не ми позволи да разбера защо претърпях такъв провал. Под натиска на постоянната критика останах на настоящата си работа още шест месеца. За щастие през този период ми бяха възложени още няколко проекта и постепенно възстанових увереността си. 

Преди да напусна, работодателят ми успя да ми направи истински подарък под формата на проект за разработка на нова система на модерен програмен език. Преминахме от Classic ASP към ASP.NET WebForms: нямаше нужда да копираме цели системи. Въпреки че не бях част от екипа на този проект, ми беше позволено да присъствам на ежедневни срещи, на които се обсъждаше развитието му. Там за първи път чух за методологията Agile, с която може да се раздели развитието на проекта на удобни фрагменти, като се уверите в бизнес стойността на всеки от тях.

По това време дори не подозирах, че това ще е началото на края на всичките  ми  папки със закрепени документи. Оказа се, че е възможно да се разработи софтуер без "пълна спецификация". И моят метод за работа с бъгове се оказа успешен поради приликите с подхода Kanban.

Поглеждайки назад към този период от кариерата си, ясно мога да видя колко важни са тези два компонента на Agile манифеста:

  • Взаимодействие с клиента.
  • Отговаряне на променящите се изисквания.

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

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

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

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