Серебрянные пули в общении с фрилансерами

Предложите бюджет, превышающий в два раза или более оценку исполнителя, с условием, что вы можете попросить по факту полностью переделать работу, или получить добросовестную ТП в хорошем объеме. Путь лузера — искать дешевле, торговаться, а потом возмущаться или «внезапно» обнаруживать что получили говно.

Очень популярное явление — тратить время на расчеты стоимости правок. Это отнимает безумное количество энтузиазма с обеих сторон, но как правило к позитивным результатам не приводит, «как ни удивительно». Особенно, если идет общение с творческими персонажами, например с иллюстраторами, дизайнерами, музыкантами, рекламистами, душевными прозаиками и поэтами — вы просто убиваете их морально, душите своей циничной арифметикой! Просто дайте денег больше. Хотя бы немного больше, и попросите о взаимной доброте.На памяти около двадцати случаев, в моей практике и у разных коллег, когда заказчики поступали таким образом. Интересно, что они ни разу не прогадали. Ни разу.

В тоже время, есть тысячи мегапроджектов, которые стали лузерскими, хотя изначально имели все шансы на успех. Не буду утверждать, что это панацея, просто наблюдение — их проджект-менеджеры посвящали много сил поискам «дешевле» и базарному торгу.

Серебряная пуля №2

Не стоит указывать исполнителю КАК ему нужно работать. Напротив — имеет смысл скрупулезно объяснить, ЧТО именно вы хотите получить.

ы уменьшаете диапазон выбора среди успешных кандидатов. Если понимаете математику — есть множество талантливых и покладистых исполнителей, которые владеют некоторым набором средств. Когда вы указываете свой набор средств и инструментов — вы определяете второе множество. Смысл в том, что чем больше вы указываете деталей, касаемо методологии реализации, тем меньше эти множества пересекаются, и тем меньше успешных соискателей возможно попадут в результирующую выборку.
- Когда вы тратите время на детали методологии, даже если вы — гуру, вы тратите драгоценное внимание, и упускаете аспекты, касаемые цели. Именно поэтому «заказчики-гуру» очень часто по факту обнаруживают, что получили не то, что хотели. На самом деле, ничего удивительного в этом нет — просто не надо было тратить время на «КАК», надо засунуть... свои амбиции, и детально проработать момент «ЧТО».

В первую очередь, уделите достаточное количество времени, для того, чтобы самостоятельно понять, какие цели вы преследуете. Это хороший способ избежать проблем в дальнейшем. Если времени уделить не можете — придется компенсировать деньгами.

Заказчики софта пишут ТЗ на десятки страниц. Не ленятся рисовать блок-схемы и подробно описывать алгоритмы. С некоторого момента ваш покорный слуга (программист) попросту стал игнорировать такие заказы. Дело в том, что подавляющее большинство авторов таких ТЗ не имеют ни знаний, ни опыта, ни квалификации. Но, сам факт того, что они с такой работой справились, заставляют их глаза светиться, поэтому они тратят бешеное количество усилий для того, чтобы доказать, что эта воображаемая программа РАБОТАЕТ. Как вы понимаете, в большинстве случаев это не так. Неприятно видеть, когда культурный, образованный, и иногда преуспевающий человек уверен в том, что сможет решить сложную многосоставную задачу, даром что не обладает соответствующей квалификацией. Вы удивитесь, но такие случаи очень и очень частые.

Ключевым вопросом в этом случае обычно бывает следующий: «можно-ли отходить от ТЗ?» Если получаю ответ «Нет» — заказчик уходит в игнор. Если «Да», тогда пытаюсь выявить цели, аспекты бизнес-логики — де-факто пишу второе ТЗ, и по нему уже в процессе работы делаю детализацию и разрабатываю программу.

Случай из моего фрилансерского прошлого. Зовут в команду, разрабатывать проект с нетривиальной логикой. Опыта ни у кого нет, поэтому возникает естественное желание посвятить некоторое время проектированию, или хотя бы прототипированию. Но, уже после официального старта шеф дает указание «У нас есть самописная CMS, мы должны работать, дополняя ее новыми функциями до тех пор, пока не получим искомое». После нескольких попыток пролоббировать более оптимальный механизм работы с грустью вздыхаю, и послушно делаю то, что просят.

Программа появилась на свет через четыре месяца. Она работала, но не так, как хотелось бы. По факту оказалось, что в ней недостает нескольких изначально неочевидных, но весьма необходимых функций. А для того, чтобы их внедрить без последствий — нужно перелопачивать архитектуру CMS на весьма базовом уровне. Программисты, которые читают эти строки, знают, чем это чревато.

Интереса ради, уже после окончания работы над этим проектом засел за прототип. Просто самому интересно было. Два дня работал карандашом в тетрадке, потом взял удобный фреймворк… Через неделю в одиночку получил то, что заказчик не смог получить за полгода. И владение спецификой тут ни при чем. Рецепт прост — добросовестное проектирование в режиме мозгового штурма, с карандашами, но без компьютеров, а потом — быстрое прототипирование, не выходя из зоны комфорта.

Зона комфорта

Подавляющее большинство специалистов (если вы ищете специалистов, а не учеников), имеют некоторый однозначно ограниченный набор инструментов, работать с которыми они привыкли.

Если вы доверяете исполнителю выбор средств — вы делаете ставку на его профессионализм. Разрешая специалисту работать, не выходя из личной зоны комфорта — означает, что результат вы получите скорее, и этот результат будет более качественным и релевантным.

Варианты вроде «нам надо сайт на X, потому что секретарша освоила админку X» — ущербные. Во-первых, вы теряете возможность контакта со специалистами, которые владеют другими средствами, но вполне могут критично устроить вас по десятку других, более важных критериев. Во-вторых, секретарша может освоить и другую админку. Обычно там менее десятка кнопочек, вроде «Добавить», «Редактировать» и «Удалить». Если секретарша не может сориентироваться в нескольких кнопках — имеет смысл отдать эту работу другому человеку. А заодно проверить, нет ли скрепок в ксероксе.

Еще случай. Есть гений пиксельарта, работающий в GIMP. Угадайте, что он думает про заказчиков, которые требуют, чтобы он работал в фотошопе? Правильно, чихал он. К слову, GIMP может читать и сохранять в PSD, но этот момент недальновидно упускается.

Еще случай. Человек когда-то имел опыт с PHP Nuke, но последние годы трудится в ином качестве, и его нынешняя работа с IT не связана. Возникла задача — открыть новый сайт через неделю. Человек пошел искать фрилансеров. Основное требование — опыт написания модулей для PHP Nuke. Своего студента он нашел. Стоит-ли говорить, что сайт получился только через месяц, а на второй месяц встал вопрос о том, что нужен вообще другой сайт?

Амбиции vs. доверие

В позапрошлом году получил заказ от очень интересного человека. Прогуглил — биография замечательная. На протяжении 15 лет — руководящие посты в организациях с популярными названиями. Эффектно так, просто на слуху! Стало интересно, между делом подумал, что стоит попросить автограф.

У него была замечательная идея. Создать сервис в интернете, который позволит конкретному кругу пользователей более чем эффективно удовлетворять конкретную потребность. Красиво было все, от идеи до концепции, и даже в подробностях.

Оговорили детали соглашения и хлопнули по рукам. Меня наняли в качестве программиста — сделать CMSку, обслуживающую логику проекта. Первичные задачи — чтобы все работало, чтобы всем было удобно. Следующая задача — чтобы один дедик справлялся с нагрузкой, не причиняя кому-либо дискомфорта.

Через месяц показываю результат. Первый вопрос «А что так скромно-то?» Ну, допускаю, что человек занятой, может быть просто позабыл, что и где. Напоминаю, что я — всего-лишь программист, и он никогда не просил у меня пакетное решение, напротив — заказал только софт, а дизайнера мы планировали нанять позже. Говорит «Ой, да», нанимает дизайнера, который должен нарисовать сайту симпатевые шкурки.

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

Встречаемся. Показываю результаты, демонстрирую достижения. Вновь спрашивает про дизайн. Честно говорю, что (его) дизайнер с момента знакомства на связь не выходил ни разу, о чем я еженедельно сигналил, предполагая, что он лично контактирует с ним. Но следующий вопрос просто добил…

В нормальном функционировании этого сервиса предусматривается некоторая работа, которую нужно делать руками. Только руками, и никак иначе. Автоматизировать и облегчить управление этой работой возможно, и я это, разумеется, сделал. Но вопрос «А как у нас с этим?» поверг в шок. Пытаюсь напомнить, что моя задача вроде бы заключается в разработке программы, и ни разу — в управлении этим проектом. Даже более того — находясь в другом городе, у меня ни разу не было ни мысли, ни задачи такой, ни возможности учредить организацию, арендовать офис, посадить в него людей, заключив с ними трудовые договора, руководить их работой на протяжении нескольких лет.

Как бы между ролями «программист» и «директор фирмы» есть некоторая разница, да? В бюджетах, кстати, тоже. Учитывая единственную существовавшую концепцию постановки моей задачи — сомнений в ее содержании никогда не возникало.

Конечно, добросовестно объяснил эти моменты регалийному заказчику. Но оказалось, что только разозлил его. Он обиделся, ругался, и не стал предпринимать никаких действий. Вообще никаких — красивый проект умер, не родившись.

Момент присутствия ручного труда в этом сервисе, естественно, обговаривался. Естественно, он также и подразумевался — эту операцию роботизировать нельзя. И даже более того, именно автоматизированная продажа результатов труда сотрудников и является сутью бизнес-модели этого проекта. А изюминка — именно в автоматизации продаж и процессинга, что дает отличнейшие эффективные конкурентные преимущества, и позволят позиционировать этому проекту. Аналогов в рунете нет до сих пор.

Человеку помешали амбиции. Как я понял, он настолько крут, что просто не считает необходимым уделять внимания рутинным вещам. К таким «мелочам» он отнес и работу по управлению открытием собственного проекта.

Конечно, этот пример гиперболичен по сути, но он из жизни.

Мораль банальна — амбиции не должны мешать работе. Амбиции и доверие — разные поля, поэтому разумно ставить на что-то одно. А проиграв — не жаловаться.

При сотрудничестве с удаленными работниками это особо стоит учитывать, так как любой удаленной работник относится к всякой дури естественно циничнее.

Если местный стафф добропорядочен и воспитан, внешний вид, выражения лиц и позы соответствуют завету царя Петра — удаленные работники, напротив, чувствуют себя свободными по определению. Поэтому, если вам постоянно поддакивают ваши подчиненные — не ждите, что фрилансеры будут также потакать и работать по избыточному принципу без дополнительной оплаты. Конечно понятно, что перевоспитывать себя не хочется, но выход есть — смотрите выше, про серебряную пулю №1.

08/09/2011