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

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

Ілюзія надурочної роботи

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

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

Якість часу над кількістю часу

Креативність та вирішення проблем, два важливі навички, необхідні у сучасній розробці програмного забезпечення, різко обмежуються втомою. Використання інструментів відстежування часу, таких як RescueTime та Toggl, протягом років для вивчення моделей роботи моїх команд привело до деяких показових результатів: наш найвищий якість коду виробляється, коли розробники мають регулярні 4-5-годинні блоки незаваженого концентрації. Коли люди переходять до 10- або 12-годинних днів, рівень помилок часто зростає, а переробка може зайняти навіть більше годин на задньому плані. Приймаючи більш виміряні графіки, ми бачили помітне зниження кількості помилок, зростання задоволеності командою та, врешті-решт, більш передбачувані терміни поставки.

Помилка фокусу

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

Прориви поза клавіатурою

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

Переоценка метрик продуктивності

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

Більш цілісний підхід

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

1. Час виходу на ринок нових функцій
   Як швидко ми можемо доставити функцію, яка дійсно цінна для реальних користувачів? Це більш надійний спосіб вимірювання пропускної здатності, ніж сурові зміни коду, оскільки він заставляє нас розглянути, чи є функції, які ми доставляємо, дійсно корисними.
2. Кількість інцидентів у виробництві
   Низький рівень інцидентів означає кращу якість коду, більш ретельне тестування та звучні архітектурні рішення. Часті інциденти у виробництві сигналізують про приховані борги або вирізки у розробці.
3. Бали підтримки коду
   Ми використовуємо автоматизовані інструменти, такі як SonarQube, для виявлення дублікатів, складності та потенційних уразливостей. Бали, які стабільні або покращуються з часом, вказують на здоровіший код, з культурою, яка поважає довгострокову якість.
4. Обмін знаннями в команді
   Замість того, щоб зосереджуватися лише на індивідуальному виході, ми перевіряємо, скільки знань циркулює. Чи беруть пари завдання разом, виконують ретельні огляди коду та документують основні архітектурні рішення? Добре інформована команда може колективно взятися за проблеми.
5. Оцінки задоволеності клієнтів
   У кінцевому підсумку, програмне забезпечення призначено для користувачів. Позитивна відгук, низький обсяг талонів підтримки та сильна адоптація користувачів можуть бути чудовими індикаторами справжньої продуктивності.

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

Сила стратегічної ліньки

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

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

Інструменти та техніки для справжньої продуктивності

Будування середовища справжньої продуктивності – а не просто “зайнятості” – вимагає як правильного інструментарію, так і правильної організаційної думки. За роки я експериментував з різними фреймворками та відкрив кілька надійних стратегій:

1. Модифікована техніка Помодоро
   Традиційні сегменти Помодоро з 25 хвилин можуть відчуватися занадто короткими для глибоких програмних завдань. Мої команди часто використовують 45-хвилинні фокус-блоки, за якими слідують 15-хвилинні перериби. Цей ритм балансує тривалі періоди безперервної уваги з необхідним часом для відпочинку.
2. Гібрид Канбан/Скрам
   Ми поєднуємо візуальний робочий процес з Канбан з ітеративними циклами з Скрам. Використовуючи інструменти, такі як Trello та Jira, ми обмежуємо елементи роботи в процесі та плануємо завдання у спринтах. Це запобігає перевантаженню контекстом та тримає нас лазерно зосередженими на завершенні завдань, перш ніж починати нові.
3. Відстежування часу та аналіз результатів
   Залогування годин за допомогою інструментів, таких як Toggl та RescueTime, надають уявлення про природні продуктивні години розробника. Озброєні цією інформацією, критичні завдання для кожної людини плануються у їх найбільш продуктивні години та не обмежуються жорсткими дев’ятигодинними слотами.
4. Огляди коду та парне програмування
   Колаборативна культура має тенденцію створювати кращі результати, ніж поведінка відлюдника. Ми часто надаємо один одному огляди коду, паруємо з часом, що допомагає нам виявляти проблеми раніше, поширювати знання та підтримувати послідовність у нашій базі коду.
5. Неперервна інтеграція та тестування
   Автоматизоване тестування та конвеєри неперервної інтеграції захищають від поспішних, недбалих комітів, які можуть зірвати весь проект. Правильно сконфігуровані тести швидко сигналізують про регресії та заохочують ретельні, інкрементальні зміни.

Будування здорової інженерної культури

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

Психологічна безпека та сталий очікування

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

Дні без зустрічей та фокус-блоки

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

Уроки з реальних прикладів

Є багато прикладів у ширшій галузі технологій, які демонструють, як прийняття збалансованої, орієнтованої на якість моделі призводить до кращих продуктів. Компанії, такі як Basecamp (раніше 37signals), публічно говорили про концепцію спокійної, зосередженої роботи. Ограничивши робочі години та заохотивши до відмови від надурочної роботи, вони випустили стабільні продукти, такі як Basecamp і HEY, з ретельним дизайном. На відміну від високотискових стартапів, які ітерують у поспіху, випускаючи помилкові функції та вигораючи добру волю розробників на своєму шляху.

Я бачив одну команду, яка серйозно поставилася до цього. Вони переплановували всі графіки, будуючи перериби та встановлюючи твердий ліміт годин. За один квартал оцінки задоволеності розробниками стрибнули, але ще краще – кількість інкомінг-тикетів підтримки зменшилася на кілька порядків.

Переоценка значення “продуктивності”

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

Збалансоване рівняння

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

1. Ефективна робота над розширеною роботою: Що справді важливо, то те, що доставляється, а не скільки годин команда сиділа перед екраном.
2. Орієнтовані на цінність метрики: Відстежувати метрики щодо результатів, таких як підтримуваність, рівень дефектів або задоволеність користувачами.
3. Культурне неперервне покращення: Справжня продуктивність походить від інкрементних покращень у тому, як тече робота, команди співпрацюють та пишуть код. Ретроспективи, гнучке планування, обмін знаннями – це те, що робить сталий темп можливим з часом.

Висновок

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

Особиста подорож навчила мене, що “години роботи” або “закриті квитки” – такі міри можуть бути насторожливо обманливими. Справжня продуктивність походить від команд, які є енергізованими, пишуть відповідальний код та функції у відповідності з реальними потребами користувачів. Це вимагає цілісного підходу: ретельного планування, значущих метрик, стратегічної ліньки та сильної інженерної культури, яка цінує ясність, колаборацію та креативність. Якщо ми залишаємося відкритими для дослідження нових методів, відмовляємося від припущень, які втратили свою актуальність, ми можемо побудувати галузь технологій, де продуктивність сприяє не тільки кращому програмному забезпеченню.