Як працює мислення senior-розробників

Блогер та розробник Джозеф Круз розповів, як має працювати мислення розробника, щоб він міг досягти рівня senior.

Пропонуємо вам переклад його його авторського блогу від нашої редакції. Далі — слово автору

Я працюю в сфері управління вже понад 15 років і багато разів бачив, як неправильне розуміння суті завдання призводить до значних втрат часу.

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

Розуміння суті є основою будь-якої діяльності

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

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

Розуміючи суть, ми можемо розставити пріоритети: тут я докладу більше зусиль і вкладу більше сил у якість, а решту енергії вкладу в інші завдання.

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

1. Скоротіть час на обговорення

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

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

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

2. Розумійте, чого хочуть ваші колеги та клієнти

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

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

Уявімо ситуацію. Ваш менеджер продукту надсилає розлючене повідомлення: «У нас проблема з продуктивністю, нічого не працює!» Ви можете почати разом з ним посипати себе попелом або почати задавати питання. «Чому ви вирішили, що нічого не працює?»

На перше питання виявляється, що колега подивився лише одну сторінку, яка є єдиною, що не працює. І далі: чим частіше лунає питання «чому», тим точнішим стає уявлення про реальність.

3. Використовуйте перефразування

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

4. Впливайте на якість рішень

Розуміння суті — ключова навичка компетентного розробника.

Розглянемо класичну конфронтацію між фронтендом і бекендом. Фронтенд просить змінити щось в API (DateTime на TimeSpan). Чому? Це потрібно змінити без пояснень. Бекенд, у свою чергу, не задає зайвих питань і не намагається зрозуміти суть, а просто робить те, що йому сказали.

• Які можливі наслідки? Фронтенд не має уявлення, що бекенд повинен враховувати такі речі, як версіонування та сумісність. Мобільний додаток перестав працювати, і контракти були розірвані.
• Що слід було зробити? Фронтенд пояснює проблему і розповідає про свої труднощі. Наприклад: «Я хочу вивести дані в іншому форматі. Що можна зробити?». Бекенд розуміє суть завдання і пропонує варіанти, які працюють. Всі задоволені, і проблем не виникає.

Втрачений час — це величезний демотиватор для команди. Набагато простіше уникнути помилок, розвинувши у програмістів правильний спосіб мислення, який дозволить їм з самого початку проекту визначити суть завдання.

Якщо ви не розумієте суті, задавайте питання; якщо розумієте, не соромтеся пропонувати варіанти.

Задавати змістовні питання перед початком написання коду — це фундаментальна навичка.

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

Водночас важливо враховувати не тільки думку керівників. Розробники знають всі особливості коду, про які PM, маркетологи та інші менеджери просто не мають уявлення. Це дуже важлива інформація, яка, безсумнівно, змінює весь підхід до роботи.