Бурчання розробника або як приручити комп`ютерного звіра?
Минулого тижня ми розповіли про те, як дизайнерам і розробником навчитися працювати дружно. У статті були описані методи, які дозволять обом сторонам досягти максимальних успіхів у процесі роботи, а головне, підвищать продуктивність. Погодьтеся, повагу і розуміння своїх колег, тільки посприяє поліпшенню командної роботи.
Однак зовсім не це стало головним посилом статті, а той факт, що розробники дуже швидко дають негативні відповіді. Зараз, напевно, будь-який з програмістів намагається придушити в собі бурю обурення, намагаючись аргументувати це тим, що дизайнери просто не розуміють причину їх відмови. Разом з цим з`являться й інші аргументи на захист, кількість яких точно перевалить за мільйон.
І все-таки, якщо добре подумати, то основна думка тієї статті вельми правдива. Розробники і справді надто швидко дають відповідь «ні», причому не тільки веб-дизайнерам, але і всім іншим, хто з ними співпрацює. Тут вже, як то кажуть, гріх не подумати над такою штукою, як психологія кодеров і їх істинної суттю.
РЕПУТАЦІЯ РОЗРОБНИКА
Якщо вже говорити відверто, то репутація у розробників не найпозитивніша. Здебільшого їх вважають гордовитими любителями сперечатися, у яких вічні перепади настрою. Вони весь час говорять «ні» і уточнюють всі деталі до нудотного педантизму, полога, що можуть запросто виконати роботу будь-якого дизайнера, причому зробити це краще за них.
____________________
Згодна, далеко не всі програмісти такі і серед них зустрічаються (досить рідко) нічого не мають спільного з вищеописаним.
____________________
Безумовно, репутація не дається при народженні і її ніде не роздають. Репутацію потрібно заробити. Але що найцікавіше, як правило, в повсякденному житті розробники - це веселі, доброзичливі і просто хороші хлопці (я навіть знаю парочку), і ви можете непогано повеселитися в їх компанії за кухлем пива. Але, як тільки справа стосується роботи, з ними відбувається незрозуміла метаморфоза і вони стають абсолютно іншими людьми. З чим це пов`язано?
ТВОРЦІ АБО БУДІВЕЛЬНИКИ
На цей рахунок існує якась теорія. Її суть в тому, що програмісти бачать себе інакше, ніж їхні колеги. Для інших вони прості будівельники - нижча ланка креативної ланцюжка. Завдання менеджера розробити унікальну ідею, дизайнеру покладається намалювати її, наділивши красою і естетикою, а розробник «всього лише» повинен дати цій ідеї життя. Говорячи простими словами, до програмістам відносяться як до хлопчиків на побігеньках, чия робота виконувати тільки те, що їм кажуть.
Можете не погоджуватися з цим, але більшість компаній бачать програмістів саме в такому амплуа. Для них вони будівельники, які повинні кодувати строго відповідно до шаблону, не маючи при цьому права, зробити хоча б найменший крок в сторону. Абсолютно всі вони впевнені, що ідея вже є і потрібно просто втілити її в життя. У цій впевненості і полягає корінь проблеми такої поведінки програмістів.
Розробники зовсім не є слухняними будівельниками вашого майнкрафт - вони творці, які хочуть стати частиною захоплюючого процесу створення нового продукту. Вони можуть привнести в будь-який проект щось цікаве, про що ви навіть не замислювалися. А головне, для них написання коду це не виконання чітких інструкцій, а справжнісіньке створення твору мистецтва.
У командній роботі, яка складається з різних фахівців, лише у програмістів вимагають залишити «за дверима» свою креативність і займатися банальним виробництвом. Але кодери зовсім не дурні і чудово відчувають подібне ставлення колег. У цей момент в них починає прокидатися невдоволення через те, що їм просто не дають можливість стати частиною творчого процесу. Якраз на цьому етапі милий і доброзичливий хлопець перетворюється в занудного буркотун.
____________________
Розробник варто більше, ніж код, написаний ним. Не варто ставитися до нього, як до хлопчика на побігеньках, адже він не тільки може дати життя вашого продукту, але і поліпшити його.
____________________
ТАК В ЧОМУ Ж ПРОБЛЕМА?
Менеджери і дизайнери майже завжди впевнені, що їхні ідеї є абсолютно закінченими і позбавлені будь-яких прорахунків. Однак в реальності є величезні діри, де може проїхати поїзд. Але їх не можна звинувачувати, адже в цьому їх суть: вони займаються творчою працею, який народжує аж ніяк не ідеальні ідеї. Саме через це розробники змінюються, стаючи все більш і більш буркотливими.
Ви коли-небудь збирали меблі за інструкцією? У вас все ідеально виходило без включення творчого мислення? Навряд чи! Навіть при наявності необхідних документів, з`являються моменти, коли доводиться думати самостійно, як зібрати ту чи іншу частину меблів, тому що інструкція рідко містить всю потрібну інформацію для завершення збирання. Це всього лише відправна точка.
Щоб вам стало зрозуміліше, давайте проведемо аналогію з будівництвом будинку. Припустимо, до вас приходить клієнт і говорить, що йому потрібен двоповерховий будинок з гаражем, вручаючи малюнок його фасаду, зроблений на простий серветці. При цьому він досить спокійно цікавиться, чи вистачить вам цього для початку будівництва. Так що, вистачить?
Звичайно, починати будівництво нереально, адже у вас на руках немає головної інформації щодо загального метражу, плану кімнат і які вимоги до будівництва пред`являє місто. Так ви навіть фундамент не можете викопати. Найпростіше сказати клієнту, що він закінчений псих і відіслати на всі чотири сторони, але ви цього зробити не можете. Причина: вам призначили дедлайн і хоч об стінку розбийтеся, але потрібно встигнути все зробити до терміну, а все що може запропонувати клієнт - почати будівництво, поки він в процесі буде вам давати нову інформацію.
Що вам залишається робити? Правильно, починати робити свої припущення щодо цього неподобства, спираючись на наявну інформацію. Все що вам відомо, будинок - двоповерховий, у нього є гараж. Але який гараж? Допустимий невеликий окремий гараж на одну машину.
Отже, ви приступаєте до будівництва гаража, поки вам не стане відома додаткова інформація щодо будинку. Через тиждень, з`являється нова інформація - будинок буде триповерховим (слава Богу, ви не почали будівництво будинку) і його потрібно пофарбувати в синій. Виходячи з цього, за браком даних по гаражу ви вирішуєте, що він так само повинен бути синім.
Минуло ще пару днів і ваш гараж майже готовий. Результат вийшов чудовим і ви задоволені своєю роботою. Тут на вас і звалюються нові подробиці. Клієнт хоче, щоб гараж був Пристоїть до дому і розрахований на дві машини. Ви працювали, не покладаючи рук, побудувавши класний гараж, який тепер доведеться зносити і будувати заново. Але найгірше - у вас в запасі залишилося зовсім мало часу, щоб встигнути. Чи це не привід для бурчання?
Аналогія звучить шалено, але це не що інше, як щоденна робота програміста.
____________________
Розробник, як може, тримає на плаву проект, латаючи наявні діри за допомогою свого творчого мислення і припущень. Але в підсумку виявляється, що він просто не вгадав чиїсь думки, щодо того, що будує.
____________________
Цей процес обтяжений не лише діями наосліп або навмання, а й постійною зміною думки дизайнера або менеджера, через що розробнику доводиться все міняти і перебудовуватися, включаючись в нову задачу.
ЩО здатні вивести РОЗРОБНИКА З РІВНОВАГИ?
зміна пріоритетів
Одна з найбільших проблем, що змушує кодера весь час бурчати і походити на вампіра, який потрапив під промені сонця. Сьогодні ви ставите головний пріоритет, а вже завтра міняєте його. Така зміна контексту вибиває з колії, знижуючи продуктивність. Як і більшість творчих людей до жаху не терплять залишати справу на півдорозі і перемикатися на іншу задачу. Це причина, по якій програміст може всю ніч писати код, аби закінчити його до ранку, поки йому не змінили пріоритети в роботі.
Постійна зміна думок бісить їх, що цілком нормально. Якщо ви вимагаєте побудувати вам будинок, а через день перетворити його в машину, то готуйтеся до невдоволення в команді.
Я теж коділ колись
Жодна фраза в світі не може вивести кодера з себе, як гордовито кинуте «Я теж раніше писав код». І неважливо хто ви - менеджер, дизайнер або навіть керівництво. Якщо ви поплутав використовувати її на доказ своєї правоти, не чекайте захоплення з боку програміста. Все що ви отримаєте - презирство!
Ось кілька фраз, які неприпустимі в спілкування з розробником:
- Невже це велика проблема? Просто допиши пару рядків коду.
- Мені сказав знайомий розробник, що вирішити завдання можна за кілька днів.
- А можна якось прискорити процес? Може нам найняти ще розробників?
Та все ж заявляти про те, що ви теж колись коділі - це верх невігластва.
____________________
Ваше шкільне захоплення зовсім не робить вас здатним розібратися в тонкощах розробки і вже тим більше не дає право подавати це як доказ правоти.
____________________
ЧОМУ РОЗРОБНИК ПОСТІЙНО бурчить
Якщо узагальнити все вищесказане і виділити конкретні причини нескінченного бурчання програмістів, то можна виділити наступні пункти.
