Практичний посібник «Як вивести з себе програміста»

Розробники і неразработчики мислять зовсім по-різному. Тому те, що здається всім іншим нормальним (питання, коментарі і просто фрази для підтримки розмови), може довести спеціаліста до сказу. Менеджерам на замітку: якщо у програміста нервово засмикалася очей після вашого питання, можливо, його слід переформулювати або взагалі більше не задавати.

Такі питання, крім нервового тику, призводять і до інших наслідків: у програмістів не залишається іншого виходу, крім як збрехати. Тому що дати людині, далекій від програмування, експрес-курс «Як писати код» за кілька хвилин, завдання не з легких.

Отже, зустрічайте топ-7 фраз менеджерів, які не залишають вибору програмістам.


/ Flickr / Kenny Louie / CC

«Потрібно дещо глянути. Це швидко і нескладно»
Коли менеджер впевнено заявляє, що робити тут нічого, то, швидше за все, все виявиться зовсім навпаки. Тому іноді фахівець змушений відмовитися від виконання такого завдання, посилаючись на те, що це не в його компетенції. «Правильний» менеджер повинен спросить себе, скільки часу це займе, і скільки буде коштувати. Ще непогано поцікавитися думкою програміста про доцільність внесення будь-якої зміни, і тоді не доведеться користуватися табличкой перекладу слів програміста, тому що при такому формулюванні питання відповідь навряд чи буде: «Це неможливо зробити зараз».

Але при роботі з молодими програмістами така фраза може провести зворотний ефект, що, мабуть, ще гірше. Коли вчорашньому випускнику вузу на роботу доручають зробити що-то з таким формулюванням, він скоріше погодиться з тим, що це нікчемна справа, ніж зізнається, що поняття не має, як виконати таке завдання.

Звичайно, це не так погано, всі вчаться на своїх помилках. Наприклад, описуючи в інтерв'ю свій досвід роботи junior-розробником, Джонатан Барронвиль (Jonathan Barronville) говорит, що помилятися і не знати чого-то на початкових етапах роботи нормально. Але щоб не почути брехню у відповідь на нездійсненну прохання або некоректно поставлене завдання, менеджерам варто обговорювати умови і прислухатися до думки фахівців.

«Ти так довго писав код, в ньому більше немає помилок?»
Навіть якщо код, сайт або програма відмінно працюють, мають зручний інтерфейс (те, що бачать користувачі), за всім цим може ховатися таку кількість помилок, що залишається загадкою, як це все працює. Та й взагалі, як сказав відомий нідерландський вчений-інформатик Эдсгер Дейкстри (Edsger Dijkstra), якщо налагодження коду — це процес усунення багів, то програмування — це процес впровадження багів.

Але пояснити людині, далекій від розробки, що уникнути помилок в коді не так-то просто, завдання майже нереальне. Тому такій людині про свою роботу програміст швидше скаже: «Тут є пара недоліків» (приблизно так перекладається «У моєму коді є баги» з мови програмістів).

«Ти повинен мислити як клієнт»
Спілкування з людьми, далекими від програмування, іноді доставляють розробникам, ну ви самі розумієте, «біль». А коли менеджер просить мислити як ці люди, стає ще гірше. Тому коли розробник говорить, що зрозумів, чого хоче клієнт, це не завжди так. Розробник знає тільки те, що сказав клієнт, а що він думає, і тим більше як він мислить, часто незбагненно.

Не дарма ж існує як сам менеджер, так і відділ контролю якості, команда якого виступає в якості третьої неупередженої сторони і стежить за тим, щоб те, що робить програміст, співвідносилося з бажаннями клієнта. До того ж вони відповідальні за з'ясування того, що може накоїти користувач. І їхня робота — вести себе як найгірший користувач, якого тільки можна уявити.

Мислити як такий користувач програміст точно не зможе, так як він сам знає про коді всі, а користувач — нічого. (Детальніше про роботу відділу контролю якості читайте тут «How the QA Process Works» і «QA Teams Are Responsible For Keeping the Site From Breaking»).

Взагалі, уявлення клієнтів про роботу відмінно відображає старе, але не втрачає актуальності відео про 7 червоних перпендикулярних ліній, деякі з яких повинні бути намальовані зеленим чорнилом, а деякі — прозорим.



«Ти не повинен відволікатися — інакше нічого не вийде»
Клієнти і начальники хочуть відразу бачити, що програміст почав працювати. Точніше, що він сів перед екраном і почав писати код, впевнений всесвітньо відомий експерт в області ІТ Девід Штром (David Strom). Він склав список 10 речей, які непрограммисты люблять говорити програмістам, де в сьомому пункті пояснює, що такі люди не розуміють важливості попередньої роботи.

Написання коду — взагалі останній етап роботи, підготовча частина до цього складається із зовсім інших речей, які стороннім можуть здаватися неробством, объясняет Маклауд Сойєр в 4 пункті своєї статті. Щоб продумати виконання певних завдань і вимог, іноді потрібно розслабитися, подивитися у вікно, потинятися навколо, поспати або навіть пограти в Halo — ніколи не знаєш, в який саме момент прийде рішення.

Харлан Міллс (Harlan Mills), засновник Software Engineering Technology якось сказав: «Програмування нагадує гру в гольф. Мета не загнати кульку в лунку, а зробити це за найменшу кількість ударів». Щоб досягти мети швидше, необхідно якомога краще продумати всі кроки і «удари». Залишилося тільки пояснити це менеджера.

«Я плачу за код, а не за коментарі»
Звичайно, у вашого боса є право вважати так, але йому не доводилося працювати з кодом без коментарів. В той час як їх наявність сильно економить час, якщо з цим кодом доведеться працювати комусь іншому і навіть вам самим через кілька місяців або років, пише блогер Джейк Рошело (Jake Rocheleau) (див. пункти 20 та 25). Іноді програміста змушують погодитися працювати без коментарів (у вигляді, наприклад, стислих термінів), що ускладнює і подальше усунення помилок в коді.

Коли програміст сам заявляє про те, що код не потребує коментарів чи є самодокументирующимся, на даний момент він відмінно розуміє, як все працює. Але на якихось важливих моментах зупинитися все одно варто: наприклад, показати, що незвичний порядок виконання певної операції не є помилковим, а був перероблений навмисно з-за будь-яких помилок.

Інша проблема коментарів полягає в тому, що вони рідко оновлюються разом з виправленням коду. У цьому випадку вони навіть можуть стати небезпечними і завести розробника зовсім не туди, пояснює автор книг і засновник Simple Programmer Джон Сонмнез (John Sonmez) в правилі 4 програмістів (з 11 існуючих). Але писати або не писати коментарі повинен вирішувати програміст, а не менеджер або клієнт.

«Скажи точно, коли закінчиш»
Фраза, яка здатна вивести з себе майже будь-якого розробника. Пояснити продавцеві, що прорахувати всі можливі помилки і проблеми заздалегідь просто неможливо. Звідси, наприклад, народжуються міфи про те, що дві самі великі казки — це «Володар кілець» Толкієна і розклад будь-якого програміста (такий приклад приводит користувач Quora Скотт Гарднер (Scott Gardner)). Можливо, іноді применшення буває властиво розробникам. На цей випадок шведський програміст підготував спеціальну табличку перекладу программерского часу в реальне.

Однак якщо відкинути жарти в сторону, справа зовсім не в тому, що програмісти зовсім не дружать з часом або живуть у паралельній реальності. Відмінне пояснення цьому явищу дав експерт Electronic Auction Services Бред Лендерс (Brad Landers), який впевнений (перший коментар в джерелі), що головна проблема — у формулюванні поставленої задачі. Чим більш розпливчасто менеджер або клієнт складає вимоги до проекту, тим більше непередбачених обставин може виникнути. Тому зовсім нечесно перекладати всю відповідальність за недотримання термінів на плечі програміста.

«Вистачить тестувати, пора запускати»
Дуже складно пояснити простим смертним, що тестування будь-яких змін (ще краще поетапне) — показник професіоналізму і зекономить купу часу при виявленні багів. Але менеджери дуже часто впевнені, що вони просять внести незначна зміна, яке займе кілька хвилин. Але невеликих змін не буває, вважає Дес Трейнор (Des Traynor), співзасновник служби передачі повідомлень Intercom. У своїй статті він наводить приклад такого «маленького» зміни: клієнт просити обмежити написання відгуку про продукті 140 символами.

Фахівець відразу побачить, що все не так легко і просто, і це зміна потягне за собою ще десятки інших: наприклад, потрібно вирішити, що буде при перевищенні ліміту у 140 знаків? Текст обріже, або користувач побачить повідомлення про помилку? Що буде написано в цьому повідомленні? Як воно буде виглядати? Хто займеться його дизайном? Питання, а разом з ними і нові невеликі зміни, накочуються, наче сніжний ком. І кожне з них вимагає тестування.

Отже, головне при спілкуванні з програмістами — мати уявлення про їх роботи і мисленні. Звичайно, вимагати цього від усіх людей (як би ні хотілося) безглуздо. Але от від тих, з ким розробники працюють пліч-о-пліч, хотілося б розуміння про специфіку роботи, що допоможе уникнути непорозумінь, а іноді і конфліктів, зробить робочу обстановку більш комфортною і зміцнить стосунки в колективі.

Ми в 1cloud прагнемо до цього при організації роботи всередині колективу і розповідаємо про цих та інших поліпшень в нашому блозі на Хабре:


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.