На прошлой неделе мы рассказали о том, как дизайнерам и разработчиком научиться работать дружно. В статье были описаны методы, которые позволят обеим сторонам добиться максимальных успехов в процессе работы, а главное, повысят производительность. Согласитесь, уважение и понимание своих коллег, только поспособствует улучшению командной работы.
Однако вовсе не это стало главным посылом статьи, а тот факт, что разработчики слишком быстро дают отрицательные ответы. Сейчас, наверняка, любой из программистов пытается подавить в себе бурю возмущения, пытаясь аргументировать это тем, что дизайнеры просто не понимают причину их отказа. Вместе с этим появятся и другие аргументы в защиту, количество коих точно перевалит за миллион.
И все-таки, если хорошо подумать, то основная мысль той статьи весьма правдива. Разработчики и вправду чересчур быстро дают ответ «нет», причем не только веб-дизайнерам, но и всем остальным, кто с ними сотрудничает. Тут уж, как говорится, грех не поразмыслить над такой штукой, как психология кодеров и их истинной сутью.
РЕПУТАЦИЯ РАЗРАБОТЧИКА
Если уж говорить откровенно, то репутация у разработчиков не самая положительная. По большей части их считают горделивыми любителями спорить, у которых вечные перепады настроения. Они все время говорят «нет» и уточняют все детали до тошнотворного педантизма, пологая, что могут запросто выполнить работу любого дизайнера, причем сделать это лучше их.
____________________
Согласна, далеко не все программисты такие и среди них встречаются (довольно редко) ничего не имеющие общего с вышеописанным.
____________________
Безусловно, репутация не дается при рождении и ее нигде не раздают. Репутацию нужно заработать. Но что самое интересное, как правило, в повседневной жизни разработчики — это веселые, дружелюбные и просто хорошие парни (я даже знаю парочку), и вы можете неплохо повеселиться в их компании за кружкой пива. Но, как только дело касается работы, с ними происходит непонятная метаморфоза и они становятся абсолютно другими людьми. С чем это связано?
ТВОРЦЫ ИЛИ СТРОИТЕЛИ
На этот счет существует некая теория. Ее суть в том, что программисты видят себя иначе, чем их коллеги. Для других они простые строители – низшее звено креативной цепочки. Задача менеджера разработать уникальную идею, дизайнеру полагается нарисовать ее, наделив красотой и эстетикой, а разработчик «всего лишь» должен дать этой идее жизнь. Говоря простыми словами, к программистам относятся как к мальчикам на побегушках, чья работа выполнять только то, что им говорят.
Можете не соглашаться с этим, но большинство компаний видят программистов именно в таком амплуа. Для них они строители, которые должны кодить строго в соответствии с шаблоном, не имея при этом права, сделать хотя бы малейший шажок в сторону. Абсолютно все они уверены, что идея уже есть и нужно просто воплотить ее в жизнь. В этой уверенности и заключается корень проблемы такого поведения программистов.
Разработчики вовсе не являются послушными строителями вашего Майнкрафта – они творцы, которые жаждут стать частью увлекательного процесса создания нового продукта. Они могут привнести в любой проект что-то интересное, о чем вы даже не задумывались. А главное, для них написание кода это не исполнение четких инструкций, а самое настоящее создание произведения искусства.
В командной работе, которая состоит из различных специалистов, лишь у программистов требуют оставить «за дверью» свою креативность и заниматься банальным производством. Но кодеры вовсе не глупы и прекрасно чувствуют подобное отношение коллег. В этот момент в них начинает просыпаться недовольство из-за того, что им просто не дают возможность стать частью творческого процесса. Как раз на этом этапе милый и дружелюбный парень превращается в занудного ворчуна.
____________________
Разработчик стоит больше, чем код, написанный им. Не стоит относиться к нему, как к мальчику на побегушках, ведь он не только может дать жизнь вашему продукту, но и улучшить его.
____________________
ТАК В ЧЕМ ЖЕ ПРОБЛЕМА?
Менеджеры и дизайнеры почти всегда уверены, что их идеи являются абсолютно законченными и лишены каких-либо просчетов. Однако в реальности имеются огромные дыры, где может проехать поезд. Но их нельзя винить, ведь в этом их суть: они занимаются творческим трудом, который рождает отнюдь не идеальные идеи. Именно из-за этого разработчики меняются, становясь все более и более ворчливыми.
Вы когда-нибудь собирали мебель по инструкции? У вас все идеально получалось без включения творческого мышления? Вряд ли! Даже при наличии необходимых документов, появляются моменты, когда приходится думать самостоятельно, как собрать ту или иную часть мебели, потому что инструкция редко содержит всю нужную информацию для завершения сборки. Это всего лишь отправная точка.
Чтобы вам стало понятнее, давайте проведем аналогию с постройкой дома. Допустим, к вам приходит клиент и говорит, что ему нужен двухэтажный дом с гаражом, вручая рисунок его фасада, сделанный на простой салфетке. При этом он довольно спокойно интересуется, хватит ли вам этого для начала строительства. Так что, хватит?
Конечно, начинать стройку нереально, ведь у вас на руках нет главной информации относительно общего метража, плана комнат и какие требования к стройке предъявляет город. Да вы даже фундамент не можете выкопать. Проще всего сказать клиенту, что он законченный псих и отослать на все четыре стороны, но вы этого сделать не можете. Причина: вам назначили дедлайн и хоть об стенку разбейтесь, но нужно успеть все сделать к сроку, а все что может предложить клиент – начать стройку, пока он в процессе будет вам давать новую информацию.
Что вам остается делать? Правильно, начинать делать свои предположения относительно этого безобразия, опираясь на имеющуюся информацию. Все что вам известно, дом – двухэтажный, у него есть гараж. Но какой гараж? Допустим небольшой отдельно стоящий гараж на одну машину. Итак, вы приступаете к строительству гаража, пока вам не станет известна дополнительная информация насчет дома. Спустя неделю, появляется новая информация – дом будет трехэтажным (слава Богу, вы не начали строительство дома) и его нужно покрасить в синий. Исходя из этого, за неимением данных по гаражу вы решаете, что он так же должен быть синим.
Прошло еще пару дней и ваш гараж почти готов. Результат получился превосходным и вы довольны своей работой. Тут на вас и сваливаются новые подробности. Клиент хочет, чтобы гараж был пристоен к дому и рассчитан на две машины. Вы трудились, не покладая рук, построив классный гараж, который теперь придется сносить и строить заново. Но самое худшее – у вас в запасе осталось совсем мало времени, чтобы успеть. Это ли не повод для ворчания?
Аналогия звучит безумно, но это не что иное, как каждодневная работа программиста.
____________________
Разработчик, как может, держит на плаву проект, латая имеющиеся дыры при помощи своего творческого мышления и предположений. Но в итоге оказывается, что он просто не угадал чьи-то мысли, относительно того, что строит.
____________________
Этот процесс обременен не только действиями вслепую или наугад, но и постоянной сменой мнения дизайнера или менеджера, из-за чего разработчику приходится все менять и перестраиваться, включаясь в новую задачу.
ЧТО СПОСОБНО ВЫВЕСТИ РАЗРАБОТЧИКА ИЗ РАВНОВЕСИЯ?
Смена приоритетов
Одна из самых больших проблем, заставляющая кодера все время ворчать и походить на вампира, попавшего под лучи солнца. Сегодня вы ставите главный приоритет, а уже завтра меняете его. Такая смена контекста выбивает из колеи, снижая производительность. Как и большинство творческих людей до ужаса не терпят оставлять дело на полпути и переключаться на другую задачу. Это причина, по которой программист может всю ночь писать код, лишь бы закончить его до утра, пока ему не сменили приоритеты в работе.
Постоянная смена мнений бесит их, что вполне нормально. Если вы требуете построить вам дом, а спустя день превратить его в машину, то готовьтесь к недовольству в команде.
Я тоже кодил когда-то
Ни одна фраза в мире не может вывести кодера из себя, как надменно брошенное «Я тоже раньше писал код». И неважно кто вы – менеджер, дизайнер или даже руководство. Если вы попутаетесь использовать ее в доказательство своей правоты, не ждите восхищения со стороны программиста. Все что вы получите – презрение!
Вот несколько фраз, которые недопустимы в общение с разработчиком:
— Неужели это большая проблема? Просто допиши пару строк кода.
— Мне сказал знакомый разработчик, что решить задачу можно за несколько дней.
— А можно как-то ускорить процесс? Может нам нанять еще разработчиков?
И все же заявлять о том, что вы тоже когда-то кодили – это верх невежества.
____________________
Ваше школьное увлечение вовсе не делает вас способным разобраться в тонкостях разработки и уж тем более не дает право преподносить это как доказательство правоты.
____________________
ПОЧЕМУ РАЗРАБОТЧИК ПОСТОЯННО ВОРЧИТ
Если обобщить все вышесказанное и выделить конкретные причины бесконечного ворчания программистов, то можно выделить следующие пункты.
· Появление новых требований перед запуском, когда времени почти не остается
· Полное противоречие новых требований предыдущим
· Требования противоречат предложениям разработчика по оптимизации работы проекта
· Новые требования значительно увеличивают объем работы, а сроки остаются те же
Все эти проблемы непосредственно связаны со сроками. Разработчик всегда стремится успеть к дедлайну, но как это сделать, когда задачи постоянно меняются. В подобных ситуациях ворчание разработчика достигает своего апогея, а категоричное «нет» вы услышите раньше, чем закончите свое предложение.
ВЫВОД
Справиться с ворчанием разработчика легче, чем вы себе представляете. Главное помнить, что написание кода, а точнее его процесс, для них сродни написанию музыки, художественного произведения, картины. Все что они хотят – это творить и решать задачи. И делать это в нормальных рабочих условиях, где их работу будут ценить. А вот какие условия можно назвать нормальными, мы с вами поговорим совсем скоро.
Источник адаптации
0 комментариев