Практическо ръководство "Как да ядосате програмист"
Такива въпроси, в допълнение към нервен тик, водят до други последствия: програмистите нямат друг избор, освен да лъжат. Защото да дадеш на човек, който е далеч от програмирането, интензивен курс „Как да кодирам“ за няколко минути, не е лесна задача.
И така, запознайте се с топ 7 на мениджърските фрази, които не оставят избор на програмистите.
„Трябва да разгледаме нещо. Бързо и лесно е"
Когато мениджърът уверено заяви, че няма какво да се прави, тогава най-вероятно всичко ще се окаже точно обратното. Следователно понякога специалистът е принуден да откаже да изпълни такава задача, като се позовава на факта, че това не е в неговата компетентност. "Правилният" мениджър трябва да се запита колко време ще отнеме и колко ще струва. Също така е добра идея да поискате мнението на програмиста относно целесъобразността на извършването на някаква промяна и тогава няма да се налага да използвате таблицата за превод на програмиста, защото при такава формулировка на въпроса отговорът едва ли ще бъде: „Не може да се направи сега“.
Но когато работите с нови програмисти, подобна фраза може да има обратен ефект, което може би е още по-лошо. Когато наскоро завършил гимназия е възложено да направи нещо с тази формулировка на работа, той е по-вероятно да се съгласи, че това е маловажен въпрос, отколкото да признае, че няма представа как да изпълни подобна задача.
Разбира се, това не е толкова лошо, всеки се учи от грешките си. Например, описвайки опита си като младши разработчик в интервю, Джонатан Барънвил казва, че е нормално да се правят грешки и да не се знае нещо в началните етапи на работа. Но за да не чуете лъжа в отговор на невъзможна заявка или неправилно поставена задача, мениджърите трябва да обсъдят условията и да изслушат мненията на специалистите.
„Ти пишеш код толкова дълго,Няма ли повече грешки?
Дори ако кодът, сайтът или програмата работят чудесно, имат удобен за потребителя интерфейс (това, което потребителите виждат), може да има толкова много грешки зад всичко това, че да остане загадка как работи всичко. И като цяло, както каза известният холандски компютърен учен Edsger Dijkstra, ако отстраняването на грешки в кода е процесът на премахване на грешки, тогава програмирането е процесът на въвеждане на грешки.
Но за да обясните на човек, далеч от развитието, че избягването на грешки в кода не е толкова лесно, задачата е почти нереалистична. Следователно програмистът по-скоро би казал на такъв човек за работата си: „Тук има няколко недостатъка“ (нещо подобно се превежда „Има грешки в моя код“ от езика на програмистите).
„Трябва да мислиш като клиент“
Комуникацията с хора, които са далеч от програмирането, понякога доставя на разработчиците, добре, вие сами разбирате, „болка“. И когато мениджърът ви помоли да мислите като тези хора, става още по-лошо. Следователно, когато разработчикът каже, че е разбрал какво иска клиентът, това не винаги е така. Разработчикът знае само какво е казал клиентът и какво мисли, и още повече как мисли, често е неразбираемо.
Не напразно има както самия мениджър, така и отдела за контрол на качеството, чийто екип действа като безпристрастна трета страна и следи това, което програмистът прави, да е съобразено с желанията на клиента. В допълнение, те са отговорни да открият какво може да направи потребителят. И тяхната работа е да се държат като най-лошия потребител, който можете да си представите.
"Не трябва да се разсейвате - иначе нищо няма да работи"
Клиентите и шефовете искат веднага да видят, че програмистът е започнал работа. По-точно, че седна пред екрана и започна да пише код, световноизвестният експерт поИТ област Дейвид Стром. Той състави списък от 10 неща, които непрограмистите обичат да казват на програмистите, където в седмия параграф обяснява, че такива хора не разбират важността на предварителната работа.
Писането на код обикновено е последният етап от работата, подготвителната част преди това се състои от напълно различни неща, които могат да изглеждат като безделие за външни лица, обяснява Маклеод Сойер в параграф 4 от статията си. За да обмислите определени задачи и изисквания, понякога трябва да се отпуснете, да погледнете през прозореца, да се мотаете наоколо, да спите или дори да играете Halo - никога не знаете кога ще дойде решението.
Харлан Милс, основател на Software Engineering Technology, веднъж каза: „Програмирането е като да играеш голф. Целта не е да забиете топката в дупката, а да го направите с най-малък брой удари. За да постигнете целта по-бързо, е необходимо да обмислите всички стъпки и „удари“ възможно най-добре. Остава само да обясните това на управителя.
"Кажи ми точно кога си готов"
Фраза, която може да вбеси почти всеки разработчик. Просто е невъзможно да се обясни на мениджъра, че е просто невъзможно предварително да се изчислят всички възможни грешки и проблеми. От тук например се раждат митовете, че двете най-велики приказки са Властелинът на пръстените на Толкин и графикът на всеки програмист (такъв пример дава потребителят на Quora Скот Гарднър (Scott Gardner)). Може би понякога подценяването е типично за разработчиците. В този случай шведският програмист е подготвил специална табела за преобразуване на програмното време в реално време.
„Спрете тестването, време е за стартиране“
Много е трудно да се обясни на обикновените смъртни, че тестването на всякакви промени (още по-добре стъпка по стъпка) е показател за професионализъм и ще спести много време, когатооткриване на грешки. Но мениджърите много често са сигурни, че искат незначителна промяна, която ще отнеме няколко минути. Но няма малки промени, казва Дес Трейнър, съосновател на услугата за съобщения Intercom. В статията си той дава пример за такава "малка" промяна: от клиента се иска да ограничи писането на рецензия за продукт до 140 знака.
Специалист веднага ще види, че всичко не е толкова лесно и просто и тази промяна ще доведе до десетки други: например, трябва да решите какво ще се случи, ако бъде надвишен лимитът от 140 знака? Текстът ще бъде ли отрязан или потребителят ще види съобщение за грешка? Какво ще бъде в това съобщение? Как ще изглежда? Кой ще го проектира? Въпросите, а с тях и новите малки промени се търкалят като снежна топка. И всеки от тях изисква тестване.
И така, основното нещо, когато общувате с програмисти, е да имате представа за тяхната работа и мислене. Разбира се, безсмислено е да изисквате това от всички хора (колкото и да ви се иска). Но от тези, с които разработчиците работят рамо до рамо, бих искал разбиране на спецификата на работата, което ще помогне да се избегнат недоразумения и понякога конфликти, да направи работната среда по-удобна и да укрепи взаимоотношенията в екипа.
Ние от 1cloud се стремим към това, когато организираме работата в екипа и говорим за тези и други подобрения в нашия блог на Хабре: