Программисты. Кто-то считает их белыми рыцарями на единорогах, которые взмахом волшебного меча решают все проблемы, даже если проблемы не относятся к программированию. Кто-то видит их злом во плоти, с которым неизбежно приходится заключать сделки, безусловно проигрышные. А кто-то относит их к отдельному биологическому виду, с которым общий язык могут найти только кремниевые формы жизни.
Давайте разберемся, в чем же тут дело, и что нужно учесть заказчикам, чтобы сотрудничество с программистом прошло продуктивно и позитивно.
Почему с программистами так сложно?
Программисты пишут код, который либо автоматически обрабатывает данные, либо отображает интерфейс, либо обеспечивает взаимодействие пользователей с программой или сайтом. Для того, чтобы код работал исправно, от программиста требуется точность в определениях и соблюдение правил логики. Кстати, программисты не единственные в своем роде: это требуется от любого вида занятости, который предполагает работу с формулами и числами, сюда же можно приписать и юристов.
Влияние работы накладывается на человека, совершенствование навыков программирования неизбежно перестраивает процесс мышления. Ведь программист не может 8 часов в день мыслить упорядоченно, а остальное время абстрактно, если только специально не ставит себе цель научиться такому трюку. Это и рождает основные проблемы в коммуникации, не только в плане интерпретации программистами формулировки фразы, а и вложенного в нее смысла. Давайте разберемся, что именно может вызвать конфликт, и как его предотвратить.
Непрофильные задачи
Когда компьютеры были большими, а мониторы маленькими, в сфере веб- и программного обеспечения существовало четкое разделение труда. Первопроходцы веб-мастера писали html код, сисадмины в свитерах вязали сетевые кабели, а бородатые программисты писали программы на древних языках. Все они периодически собирались и танцевали с бубнами, но это единственное, что их объединяло. Со временем база требуемых для работы знаний начала сильно расширяться, и инструментарий был автоматизирован. Например, сейчас не обязательно знать html, чтобы поправить текст на странице, ведь есть визуальный редактор, а Windows сам установит все нужные драйвера.
Примерно то же произошло и со всеми аспектами работы. Специализации начали смешиваться, простые задачи, вроде html верстки, превратились из основного профиля в сопутствующие знания. Но все же сохранилось основное разделение — творческие задачи и технические. Любой разработчик может поправить цвет кнопки на сайте на более-менее сочетающийся, но если вам нужно изменить цветовую палитру сайта полностью — это задача для дизайнера. Разработчик может придумать текст для блока на сайте, но бесполезно требовать от него, чтобы текст был продающим, это работа, скорее, для копирайтеров. При этом задачи для разработчика варьируются по уровню знаний.
Опытный программист, который взял задачу настроить на сайте api интеграцию, может быть недоволен дополнительной просьбой загрузить фото на сайт из админки и просто проигнорирует просьбу, хотя с основной задачей справился отлично, и ничего не предвещало беду. Чтобы понять, чем руководствуется в этом случае программист, можете представить, что вы сантехник, и вас попросили помыть посуду после того, как вы подключили душевую кабинку. Конечно, не знакомому с IT клиенту будет сложно определить, к чему лежит душа программиста, а к чему не лежит, поэтому не стесняйтесь спрашивать, входят ли сопутствующие задачи в профильную область исполнителя.
Формулировка задач
Представьте, что вы говорите программисту: «Купи два пакета молока, если будут яйца — возьми десяток». Он приносит вам десять пакетов молока и сообщает что яйца были. Вы в гневе требуете вернуть восемь пакетов молока обратно и принести яйца, а ведь с точки зрения логики программист сделал в точности то, о чем его попросили. В постановке задачи яйца выступают не отдельной операцией, а условием, модифицирующим основную операцию. Чтобы избежать конфликта, следовало сказать: «Возьми два пакета молока и десяток яиц». Внимательно следите за построением предложений, на скорую руку написанный текст, скорее всего, приведет к путанице.
Программисты любят читать, вернее, даже не любят, а это для них необходимость. Текст позволяет несколько раз прокрутить в голове детали и спланировать оптимальный путь превращения задачи в код. В процессе работы программист также периодически сверяется с задачей, так как держать все аспекты в голове сложно. Поэтому, настаивая на общении голосом, вы не только повышаете вероятность недопонимания, но лишаете программиста возможности хорошенько вникнуть в детали. Дело не в том, что программисты медленно соображают, наоборот, каждое ваше слово для них несет не только общую описательную информацию, но и встраивается в проектируемую систему. Например, программист работает над фильтром на сайте. Вам лень писать, и вы звоните чтобы описать как нужно его переделать с точки зрения пользователя.
Каждая модификация внешне простая, но для ее внедрения разработчику нужно подумать о запросах к базе данных, устройстве товарных характеристик, механизме фильтра во фронтэнде, html верстке и css стилях. Учитывая еще и то, что вы можете общаться с программистом на разных диалектах логики, для него испытание телефоном становится очень суровым. Лучше не устраивать ему такую пытку, и все же потратить 5 минут на написание. К тому же, описывая задачу текстом, вы лучше организуете мысли в голове и сможете точней донести идею. В задачах, требующих визуализации, лучше всего общаться скриншотами и видеозаписями экрана, так как даже текстом не всегда понятно что имеется в виду.
Неполная информация о задаче
Например, нужно добавить слайдер на главную страницу сайта. Вы, не желая особо разбираться, создаете задачу с текстом «Нужно добавить слайдер с акциями на главную страницу магазина». При просьбе выбранного исполнителя указать дополнительные требования, вы высылаете несколько картинок для слайдера, и говорите, что все остальное на его усмотрение. Разработчик добавляет слайдер за 20 минут, и просит проверить, чтобы задачу можно было закрыть. При проверке:
- Вы не в восторге от стрелок переключения слайдов и хотите точки.
- Ваш SEO-специалист трубит тревогу что слайдер снизил скорость загрузки страницы, и позиции сайта упадут.
- Контент-менеджер не видит, чтобы в админке можно было изменять и добавлять слайды.
- Таргетолог жалуется, что слайдер слишком высокий на мобильном, и часть продающего текста уехала вниз из первого экрана.
- Из отдела продаж заметили, что при размере окна браузера 1565х400 картинки не вписываются по ширине.
- Ваш партнер сообщил, что на айфоне не работает свайп, а скорость автопереключения слишком низкая.
- Ваш бывший программист написал, что библиотека, которую использовал исполнитель устаревшая, и много весит, ею уже никто не пользуется, надо поставить другую.
Вы, скорее всего, почувствуете раздражение, ведь такая простая задача, а допущено столько ошибок. В итоге разработчик левой ногой выполнит все требования, ведь он планировал, исходя из технического задания, потратить 30 минут, а не 3 часа. Вы потратите не меньше из-за длинных споров, а после завершения проекта, скорее всего, оставите обоюдный негативный отзыв. Сложно оценивать, кто прав в данном случае. Вы не предоставили изначально все требования, а разработчик поленился сделать «как для себя».
Представьте, во что бы вылилась подобная ситуация, если бы задача была сделать не слайдер, а целый сайт. Всегда максимально детально описывайте то, что хотите получить. Если у вас не хватает знаний для детального технического задания, вы можете показать разработчику готовые аналоги, которые вам понравились, либо попросить программиста проконсультировать по поводу вариантов реализации перед началом работы. Чем точней прописана задача, тем быстрей и качественней она будет реализована.
Дистанция
Если вы спросите программиста, не против ли он перейти «на ты», он, вероятней всего, ответит согласием, чтобы не отвлекаться на неудобную ситуацию. Но учтите, что это станет началом разрушения деловых отношений. Программисты любят правила и стандарты, и ваше пренебрежение к основному правилу деловой этики, скорее всего, приведет к пренебрежению программиста к вашим задачам.
Стоит отметить также общение на посторонние темы. Программист может отнестись к вашему рассказу о любимой собаке как к бесполезному флуду, который тратит его рабочее время, хотя у вас была прекрасная задумка построить мост доверия. Это не значит, что программисты бездушные социопаты, просто они работают с большими объемами данных и им необходимо концентрироваться на конкретной задаче, не отвлекаясь на посторонний информационный шум. После выполнения проекта будет уместно обсудить нечто отвлеченное, но в процессе работы лучше позволить программисту сосредоточиться.
Завышенные требования
20% усилий дают 80% результата. Идеальный результат редко достижим, и чем ближе результат к идеальному, тем больше будет стоить выполнение задачи. Достижение 99 баллов Page Speed для мобильной версии сайта может стоить $1000, а 80 баллов для того же сайта — $100. Ставя завышенную планку для вашего бюджета, вы отсеиваете опытных специалистов, которые могли бы выполнить задачу качественно, и заранее повышаете вероятность конфликтной ситуации, так как у менее опытных, но отважных специалистов меньше шансов справиться с задачей, независимо от срока и бюджета. Разумней будет спросить вилку цен, и выбрать оптимальный для вас уровень качества после обсуждения проекта.
Выгорание
Бывает, что вы работаете с программистом в отличных отношениях на постоянной основе несколько лет. А потом либо отношения портятся, либо программист «уходит в запой». Это распространенная проблема и она совсем не связана с алкоголем, и не является отличительной чертой именно программистов. Это усталость от проекта, она проявляется в IT, так как от однообразных задач устают даже самые воодушевленные и стойкие. Специалист может уйти на условия хуже, чем предлагали вы, лишь бы сменить утомивший их проект. Можно пробовать удержать программиста повышением оплаты, но это временное решение. Можно попробовать дать ему новые интересные и сложные задачи, можно попробовать дать отдохнуть некоторое время. Но если у вас все же не выйдет, то лучше всего понять его и отпустить. Лучше оставаться друзьями, ведь в будущем судьба опять может вас свести вместе.
Добросовестность
Делая предоплату программисту напрямую до завершения работы, вы должны учитывать, что вероятность потерять деньги очень высокая, но точно такая же, как и в других специальностях. Поэтому относиться предвзято к программистам заранее нет причин. Доверять или проверять — это вопрос философский, но перед началом работы вы можете посмотреть:
- Оценку стоимости работы от других программистов, и если сумма значительно отличается в обе стороны, то задать уточняющие вопросы о причине.
- Проекты в портфолио. Обратите внимание на описание работ, так как загрузить скриншоты может каждый, а грамотное описание требует опыта.
- Активность профиля на github.com. История вовлечения в разработку проектов покажет опыт фрилансера, а если это еще и Open Source проекты, то это подскажет что программист в первую очередь любит свою работу и участвует в развитии сферы.
Чтобы обезопасить ваш проект в процессе работы, вы можете сделать резервную копию, создать тестовую версию сайта или настроить систему контроля версий. Опытный программист сам поинтересуется о перечисленных средствах страховки, так как внесение правок на живом сайте и без резервной копии — это плохая практика. Использование системы контроля версий на первый взгляд может вам показаться чем-то жутко сложным, но настройка делается один раз, и после этого вы сможете спать спокойно, потому что все изменения в файлах вашего проекта можно будет увидеть, перед тем как запускать в релиз. Ну а если все же после релиза ошибки нашлись, то можно будет быстро откатить состояние сайта обратно. Еще одно важное преимущество контроля версий — не возникнет ситуация, когда несколько программистов, одновременно работающих над проектом, случайно перезаписывают правки друг друга.
Результат
Проверка выполнения работы, это самый стрессовый этап сотрудничества и для программиста, и для заказчика. Но тут как на экзамене. Если подготовка к этому этапу шла заранее — подробно согласовывалось ТЗ, обсуждались прототипы и решались всплывающие в ходе работы вопросы, то экзамен станет приятным праздником. Если же сотрудничество происходит без достаточной коммуникации, то при сдаче работы может возникнуть неприятная ситуация, и не всегда мирно разрешаемая. Выработанная привычка сообщать сразу о проблемах и недопонимании, и не стесняться переспрашивать, убережет вас от конфликтов.
Автор, кстати программист, часто попадался на описанные моменты, выступая и исполнителем, и заказчиком. В каких-то моментах сам совершал ошибки, в каких-то не понимал, что ошибки совершают другие, и потому не пресекал вовремя недопонимание. Самое важное — предполагать где может поджидать проблема, тогда можно будет ее легко избежать, либо превратить в шутку, которая поднимет настроение, и будет способствовать продуктивной работе.
Михаил Бычков