Про те, що вбиває продуктивність розробників



У світлі того, що Мегамозок знову возз'єднався з Хабром, тепер можна очікувати, що аудиторія обох порталів також об'єдналася. Логічно буде припустити, що Хабр буде залучати більшу увагу менеджерів, яким не чужий світ сучасних технологій. Тому наша команда SmartProgress вирішила підготувати статтю на роздоріжжі розробки та управління проектами.

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

«Виміри продуктивності»

Не можна керувати тим, що неможливо виміряти — так звучить одна з улюблених аксіом гільдії менеджерів. Тільки от як не крути, але продуктивність розробників адекватно оцінити ще нікому не вдалося. Над цим питанням билися найсвітліші уми IBM, Microsoft, Intel і багатьох інших титанів IT-світу, і поки що та метрика, якою можна було б виміряти продуктивність програмістів, знайдена не була. Якщо вам це здається абсурдом, то запропонуйте свої роздуми — а раптом ви опинитеся праві? Тоді ви станете справжньою зіркою в IT-всесвіту, а про вас і вашої геніальності будуть писати книги.

Отже, проблема — немає метрик, якими можна вимірювати продуктивність розробників. Який же вихід знаходять менеджери? Вони старанно намагаються вимірювати хоч що-небудь — ведуть облік щодня написаного кількості ліній коду або свежеотлаженных багів, кількість зданих в строк проектів та інших не менш важливих речей. Найгірший сценарій в даному випадку — це спроби мотивувати розробників і впроваджувати покарання за «невиконання п'ятирічки» або затягування зі здачею проекту. Адже програмісти не ликом шиті. Хочете побільше коду? Це можна зробити. Баги — будемо фиксить у дві зміни, особливо якщо за це дають премію. Тільки на продуктивність під призмою якості самого коду такий підхід впливає вкрай негативно.



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

Мислення в дусі «Я виправлю це потім»

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



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

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

Занадто мало документації

Документація забирає час, а девелоперам платять за написання коду, оцінюють їх роботу за кількістю написаних ліній і налагоджених багів (коли інакше оцінити не вміють). Менеджери хочуть результату — розробники і працюють на результат. «А як же документація?», — запитаєте ви. «А ми і так всі пам'ятаємо, і обов'язково напишемо, коли буде на це час. Чесслово!» — незворушно дадуть відповідь вам програмісти.

Занадто багато документації

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

Любов до антикваріату

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

Цирк на робочому місці

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

Горезвісні зборів

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

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

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

image

Отже, ми сподіваємося, що вам сподобався пост. Може бути, у вас є що сказати про фактори, які вбивають продуктивність розробників? Також будемо раді побачити в коментарях лайфхаки щодо підвищення цієї продуктивності.
Джерело: Хабрахабр

0 коментарів

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