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

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

Ілюзія надгодин

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

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

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

Креативність та вирішення проблем, два важливі навички, необхідні у сучасній розробці програмного забезпечення, різко обмежуються втомою. Використання інструментів відстеження часу, таких як 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. Культурне неперервне покращення: Справжня продуктивність походить від інкрементальних покращень у тому, як тече робота, команди співпрацюють та пишуть код. Ретроспективи, гнучкий графік, обмін знаннями – це те, що робить можливим сталий темп з часом.

Висновок

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

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