«Мовчання – золото»: 13 речей, які не варто говорити розробникам і тестувальникам



/ фото Sistema Bibliotecario Vimercatese CC

Практично кожна велика організація наймає в свій штат розробників програмного забезпечення. При цьому тільки треть з них зайняті безпосередньо у бізнесі, пов'язаному з ІТ. Але незалежно від того, де вони працюють: у фармацевтичній компанії, освітній або рекламній сферах, вони залишаються програмістами.

Робота в команді – відповідальне заняття, оскільки в цьому випадку люди відповідають не тільки за себе, але й за оточуючих, вони спілкуються, допомагають один одному. Як би це не було банально, ключем до продуктивного спілкування між людьми завжди є ввічливість і взаємоповага. Проте все ж є певний список фраз, які – навіть коли вони звучать ввічливо і коректно – не варто вживати в розмові з розробниками і тестерами, якщо ви їх колега, замовник, власник або керівник проекту.

1. «Можеш закінчити тестування скоріше?»

Тестування повинне проводитися вдумливо і ретельно, щоб не пропустити критичні недоробки. Гарне тестування – запорука якісного продукту. Зрозуміло, є інструменти для прискорення процесу (ось кілька туториалов по автоматизації тестів, запропоновані резидентами Stack Exchange), проте, навіть автоматизовані тести доводиться підтримувати і постійно модифікувати.

В ідеалі тестування починається ще на етапі проектування продукту і триває до самого релізу, а дизайнери і розробники щільно взаємодіють з тестерами. Якщо у вашої компанії відбувається інакше, то, вітаємо, ви дізналися рецепт затримок, помилок і браку бюджету (ось ще кілька речей, які не люблять чути тестувальники).

2. «У мене немає часу читати баг-репорт, опиши проблему в двох словах»

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

Не варто недооцінювати цей порада: одного разу я мав необережність висловити щось подібне. На той момент я був молодим фахівцем і не мав особливої ваги в колективі. Природно, я почув заповітні два слова, але не про суть багів, а про себе коханого… На те, щоб відновити нормальні відносини з тестувальником пішло не менше тижня.

3. «Обіцяй мені, що тут немає багів»

Роль тестувальника – це не «контроль якості», а «сприяння в досягненні якості». Завдання тестувальника – не перевірити, що продукт реалізований без помилок, а переконатися в тому, що він відповідає (або не відповідає) вимогам компанії.

У бізнесі є приказка: «Обіцяй менше, роби більше», тому не варто гнатися за 100% покриттям коду, необхідно зосереджуватися на як проведених тестів.

Залиште екстравагантні обіцянки відділу продажів і маркетингу – нехай вони цим займаються. Тестуйте продукти з прив'язкою до реальності. До речі, по темі QA є кілька подкастов, на які варто звернути увагу.

4. «Залиш це, я потім сам дороблю»

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

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

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

image

Важливо: намагайтеся ділитися «смачними» і цікавими завданнями з підлеглими. За це вони вас полюблять.

5. «У мене невеликий питання...»

Фраза не найвдаліша. Навіть якщо питання дійсно виявиться коротким, відповідь на нього таким може і не бути. Спробуйте поцікавитися для початку, чи є у колеги час (зараз або в майбутньому) вам докладно відповісти. Дайте співрозмовнику можливість відмовитися від негайного відповіді і виділити для вас вільний час у майбутньому.

Якщо справа термінова, то цим правилом можна знехтувати, але намагайтеся не робити так занадто часто. Ви ж не хочете стати менеджером, який кричав: «Вовки!».

6. «Я пішов додому» (відноситься до менеджера проектів)

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

Важливо бути солидарным зі своєю командою. Проводьте з ними час. Розробники затрималися, щоб скоріше закінчити важливий проект? Вам теж варто бути на місці – не деморалізуйте ваших людей. Сила команди в єдності, підтримці та повазі. Не варто кидати розробників напризволяще у важкий момент.

7. «Ось він зробить це швидше тебе»

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

Звертайте увагу не на швидкість, а на здатність «передбачати», скільки часу буде потрібно на виконання завдання. Головне – це те, наскільки об'єктивно колега оцінює свої можливості.

8. «Я дивлюся, ти вже давно не пишеш код»

image

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

9. «Що ти робиш цілий день?»

Тема, яка випливає з попереднього пункту. Хороший програміст звикає задавать собі питання «Як мені зробити X добре?» замість «Як мені зробити X?». При цьому 95% часу розробника йде на роздуми про те, як надійно впровадити рішення і узгодити його з поточною архітектурою. Інша частина робочого дня – це написання коду. Ну, іноді, ще пінг-понг і читання новинних сайтів, таких як Reddit або Хабр.

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

10. «Це завдання під силу навіть студенту, просто візьми шаблон»

Видавши «студенту» важливі завдання, ви ризикуєте заплатити в два рази більше, якщо доведеться все переробляти. По своєму досвіду ми 1cloud можемо сказати, що розробників дуже дратує, коли замовник або керівник дає оцінку складності завдання і трудовитрат на розробку, грунтуючись на своєму суб'єктивному досвіді. При цьому досить часто керівник не володіє фаховими знаннями в розробці, але намагається нав'язувати розробнику свою оцінку.

В цілому варто уникати будь-яких неакуратних фраз при оцінці строків та складності розробки. Наприклад, фраза «Це елементарне завдання, пара годин максимум...», висловлена самим розробником, говорить про те, що завдання, швидше за все, дійсно буде зроблено оперативно.

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

11. «Глянь ось це, треба терміново зробити...»

Робота програміста можна порівняти з роботою людей мистецтва. Програміст зосереджується на завданні, як художник, і тримає в голові дуже складну картину. Коли ви перериваєте його роздуми «терміновими справами, він «випадає» з потоку. Згідно з дослідженнями, щоб повернутися в стан концентрації, людині потрібно не менше 15 хвилин (почитайте статтю про те, як працювати в потоці), тому відволікання вкрай дратує.

Керівникам варто спробувати вибудувати роботу таким чином, щоб вранці видавати завдання, а ввечері – приймати готовий результат, зайвий раз не відволікаючи команду в середині дня і дозволяючи кожному працювати у власному темпі. Необхідно забезпечити колегам тишу під час робочого дня [і мова, швидше, не про гробовому мовчанні і/або заборону на прослуховування музики в навушниках, а про відсутність подразнюючих розмов] – ефективність їх праці буде набагато вище.

12. «Ніякого рефакторінгу, продукт потрібен сьогодні!»

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

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

13. «Як ти став розробником? Мені б знайти яку-небудь підробіток на літо для племінника/знайомого/і т. д.»

image

Це питання найчастіше задають люди, які мають приблизне уявлення про створення програмних продуктів. Вони вважають, що сучасні технології дозволяють написати програму буквально за пару кліків мишки. Так, допоміжні сервіси спрощують роботу програміста, але для недосвідченого людини популярний фреймворк може здатися [і неминуче здасться] темним лісом.

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

Головне – пам'ятати, що робота програміста – не стільки професія, скільки спосіб життя. Навчання в університеті, самоосвіта, хобі і, що важливо, пристрасть – ключові складові успіху в цій сфері.

У своїй трудовій діяльності ми, мабуть, зіткнулися майже з усіма перерахованими ситуаціями. І кожна з них може легко вибити розробника/тестувальника з колії. Звичайно ж, безглуздо встановлювати заборону» на якісь слова – важливо просто розуміти, що ви хочете донести до колег і до яких наслідків таке рішення або вчинок призведе.

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

0 коментарів

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