Тер С.
45 лет, США
536 сообщений
#12 лет назад
Я уже писал о том, как исполнитель может провалить переговоры с заказчиком ( https://forum.weblancer.net/themes/2685.html ) Часть нервных ответов натолкнула меня на мысль написать и обратное, как заказчик может провалить переговоры с исполнителем.
Сразу упомяну что текст пишется для реальных заказчиков, а не для идиотов которые сами не понимают что им надо и предлагающих нереальные условия какого-то фантастического сотрудничества по построению варезников всех времен и народов. Так что в тексте будет немного больше общих мыслей и намного меньше примеров чем в предыдущем посте.
Итак, к делу.
Самое большое философское отличие ситуации исполнителя от заказчика в том, что Исполнителю надо перевалить всего один барьер - надо понравиться заказчику. А вот Заказчику надо во-первых перевалить барьер понравившись исполнителю со своим проектом и бюджетом, а во-вторых не пересечь критическую черту понравившись не тому человеку. Именно так и получаются потом слезы «а вот, мы ему проект отдали, а он, скотина, продинамил по времени и качеству...» Из этого философского рассуждения следует несколько частностей и все они имеют две противоположные границы. Вам надо пересечь одну и недолететь до второй:
1. Хороший исполнитель с опытом уже имеет какие-то заказы, какую-то работу, в общем он живет и без вас. Так что не надо хорохориться что вот мол, я ему работу даю, нехай в ножки падет. Будьте аккуратны, если исполнитель слишком к вам доброжелателен, то у вас или переоцененный бюджет, или вы нарываетесь на обманщика, или на пионера не имеющего реального опыта. Исключение составляют случаи более крупных фирм, там где выделен специальный человек лижущий зад клиентам ака клиент-менеджер. Убедитесь в какой вы ситуации прежде чем двигаться дальше.
2. У правила №1 есть и обратная сторона. Если Исполнитель общается с вами сквозь зубы, значит заказ ему не интересен. Это может быть потому, что он перегружен или он не уверен что его сделает, но помните – так или иначе он не ценит ваш заказ. Он не ценит его до старта, не будет ценить и после. Шансы дойти до финиша резко падают.
3. Не жмотьтесь! Помните что дешево хорошо не бывает. Если вы не знаете расценок на какие-то работы, то вы то, черт побери, знаете что вы их не знаете! (простите уж за каламбур). Так и пишите, что расценок не знаете, ввиду чего будете рады получить от потенциального исполнителя обоснование цены. Вменяемый исполнитель примерно знает рыночные расценки и ему не составит труда пояснить откуда он вынул именно ту цифру, которая была озвучена.
4. Не переплачивайте слишком сильно. Этим вы рискуете привлечь слишком много мусорных предложений и разгребая их пропустите хорошее.
5. Сделайте домашнюю работу. Определитесь что именно вам надо получить и изложите это заранее в документе. Не надо переговариваться с каждым в аське отдельно про детали ибо вы рискуете недопониманием и, что еще более существенно, можете разным людям сказать разное и получить предложения в общем-то на разные проекты. И прикидывайте свое расписание, не начинайте проект если вы в дороге или заняты (как я сделал это с проектом по транскрайбингу записей). Помните что больше всего откликов вы получите в течении первых дней после публикации проекта и если вы не можете осмысленно отвечать сразу, то будете выглядеть плохо для Исполнителей. Особенно для хороших. В общем твердо понимайте ЧТО вам надо получить и понимайте это в документированном виде готовым к раздаче.
6. Не делайте слишком много домашней работы. Во-первых помните что исполнитель по идее знает предмет лучше вас. Не надо учить дизайнера рисовать, кодера програмировать, архитектора пользоваться UMLем. Не накладывайте ограничений КАК люди будут работать, но не слезайте с них по поводу того, ЧТО должно получиться.
7. Минимизируйте предоплаты. Помните, что вам надо не просто создать стимул что бы Исполнитель взялся за проект, но и сохранить стимул в процессе движения. Конфетка только после окончания проекта.
8. Не переусердствуйте. Если ваш проект требует от фрилансера-одиночки три месяца, то эти три месяца ему надо что-то есть. Даже если вы уговорите его на работу без предоплаты – уж будьте уверены, на второй месяц он будет смотреть вокруг голодными глазами и искать куда ваш проект задвинуть что бы взять другой. Даже если работа идет без предоплаты, так и договорились, то для больших проектов приготовьте немного денег на подкорм в середине процесса. У меня был случай когда очень хороший человек взялся делать полугодовой проект без предоплаты. Я его уговаривал взять денег по этапам, но он решил сэкономить время на сдачу этапов мне и отказался. В общем на третий месяц он пришел со словами что даже влез в долги. Слава богу что мы давно работаем вместе и он не постеснялся ко мне прийти.
9. Не верьте ничему что вам говорят. Исходите из концепции, что ваш собеседник лжец. Если вам гворят что вам выделят менеджера который будет вести ваш проект – проверьте это. Не ответьте на существенное письмо и посмотрите: а будут ли вас доставать, напоминать? Если будут, то как? Убедитесь что вам именно выделили и именно менеджера. Если вам дают ссылку на сделаный сайт – не ленитесь, позвоните по указаным на нем контактам, проверьте что они скажут про вашего собеседника.
10. Ложь есть часть человеческой культуры. Не впадайте в истерику если поймаете Исполнителя на лжи. Вы тоже ведь не всегда говорите клиентам правду выкручивая себе заказ. Если человек преувеличивает скажем свой официальный статус выдавая себя за зарегестрированную фирму – поймите его.
11. Демонстрируйте перья. Помните что рядом с вами бегает тьма псевдоклиентов с какими-то идиотскими предложениями. И это ваша забота выделиться на их фоне. Хороший исполнитель может вас потерять в разноцветной и орущей глупости толпе.
12. Не демонстрируйте слишком много перьев. Иначе вам начнут ломить цены и условия не из размера задач, а по прниципу «а он богатый, что ж его не ободрать».

На этом общая часть кончается и начинаются сигнальные флаги: Все они в общем-то очевидны, но в черных списках раз за разом появляются люди явно их проигнорировавшие.
1. Грамотность. Не отдавайте большие проекты неграмотным людям. Во-первых мозг человека устроен так, что если человек умен, то он и грамотен. Просто точно также как он запоминает какие-то приемы програмирования он запоминает и правописание. Если ваш собеседник не в состоянии запомнить как пишется слово «извините» и пишет его «извЕните», ну каковы шансы что он помнить что-то более сложное? Однако не забывайте о людях с неродным русским. Один из лучших некода дизайнеров РБК был из Азербайджана родом. Так он в слове «х**» три ошибки делал. Но это редкость.
2. Наличие контактов. Вася Пупкин и DarkRider идут нахер если к этом не приложены реальные имя и фамилия. Аська и только аська в контактах при том что других координат вам не дают - красный флаг. Причем не в версии. «спросите и посмотрите что вам ответят», а в версии «сам дал телефон или нет?»
3. Рассказы оправдывающие отсутствие портфолио. Перед вами идиот. Да, все мы когда-то начинали, отсутствие портфолио это нормально и терпимо для простых задач. Но лепка оправданий этому - уже не нормально. Перед вами человек склонный своим проблемам искать оправдания, а не решать их.
4. Игнорирование вашего прямого вопроса. Никогда, никогда не позволяйте потенциальному исполнителю не ответить на ваш прямой вопрос. Если такое произошло и в ответном имейле пропущен один из ваших вопросов, то перезадайте его в следующем вместе с чем-то еще. Не настаивайте и не подчеркивайте что задаете его второй раз. Еси его опять проигнорируют, то сворачивайте общение. Ибо завтра будут также игнорироваться ваши вопросы о ходе проекта.
5. Покопайтесь в сети, кто есть ваш собеседник. Его мыло, аська, ну суньте ее в гугль. Найдите отзывы, другие интересы. Все хорошие прграмисты и дизайнеры люди весьма интернетные и у них у всех следы есть. Если перед вами черный ящик эдакий, то это повод для сомнений. А кто вообще с вами разговаривает?

И рекомендация:
До начала проекта тычьте исполнителя спичкой. Точно также как было сказано про проверку выделили вам клиент-менеджера надо проверять и все остальное. Уравновешен ли ваш собеседник? Задайте провокационный вопрос. Причем не обязательно впрямую, найдите его на форуме каком-то где он общается и ткните там. Грамотен ли ваш собеседник в вопросе? Не поленитесь узнать какой-то вопрос с ответом и задайте его так, невзначай. Особенно обращайте внимание на финансовую сторону вопроса. Если вам рассказывают про немеряные объемы работ, а про пятисотдолларовую работу выдвигают аргумент что не могут идти на такой большой риск сделать такой большой объем работы без предопаты – это нехорошо, это не совпадает. Но есть и обратная строна: если вам рассказывают про немеряные объемы работ, но соглашаются начать без предоплаты свсем вас не зная – это тоже не совпадает. Смотрите на факты, а не на то, что вам говорят. Помните, что самая большая ошибка у Заказчика это не переплатить за проект, а продешевить и отдать проект тем, кто его не сделает. Лучше уж переплатить, не подходите слишком близко к краю обрыва как бы выгодно это не казалось. Помните что самый большой провал у заказчика это проект, отданый в плохие руки. Помните, елси вы отдали проект в руки которые оторвать надо, то ваши надо оторвать еще раньше.
Николай М.
34 года, Украина
1895 сообщений
#12 лет назад
Хм.. прочитал с интересом, но
вот в красных флагах п.2)

вот лично я написал свой номер аськи, имя, город проживания, и номер могильника - считаю что єтого вполне достаточно, в гости итак не приедете, к чему так утверждать что личные данные так важны комуто знать ? Мне вот напр. не интересно где живёт Бил Гейтс, и какой у него номер мобили, ни капли не интересно.

Прошу аргументировать єтот "флаг" ?
Антон Цветков
30 лет, Россия
296 сообщений
#12 лет назад
MMM_Corp, думаю, имеется ввиду абсолютно чистый профиль, в котором указан лишь номер ICQ...
Павел К.
30 лет, Россия
17 сообщений
#12 лет назад
Отлично написано. Хорошо бы все следовали этим правилам)

Только насчет номера мобильного не уверен. Лично я даю его заказчикам, с которыми предполагаю встречаться лично в процессе работы над проектом. В остальных случаях e-mail, icq, skype.
Тимур Шаммасов
42 года, Россия
1278 сообщений
#12 лет назад
Нет, если "Как провалить переговоры с заказчиком" написано на 5-ку. То эта часть на 4 с минусом.
Почти в каждом пункте есть неточности и неверно расставленные акценты.
Что и понятно, г-н Mauser, часто бывал в шкуре заказчика, но исполнителя изнутри он понимает плохо.
1.Бюджет, на который согласится хороший исполнитель будет ВСЕГДА переоцененным по общему среднестатическому мнению.
2. Я обсуждаю около 100 предложений в месяц, а беру около 10 проектов. Если я буду внимательно обсуждать каждый проект, то у меня не останется времени работать. Поэтому первые 5-10 предложений в общении обычно у меня сухие и сквозь зубы, потом, когда я сообщаю уровень цен, возможно начинается нормальное обсуждение. И когда я обращался к нормальным исполнителям то заметил то же самое
3. согласен
4. Непонятно, это вы про работу с конкретным исполнителем или про публикацию проекта. Хороший исполнитель будет лучше работать за повышенную оплату. Да и премии никогда не окажутся лишними.
5. Если заказчик не готов обсуждать со мной детали проекта в аське, или как вариант в другом мессенджере, я скорее всего откажусь от проекта, потому как уже имел опыт проекта на 850 евро с общением только по Е-маил, больше не хочу....
6-8. согласен.
9-10 Строить отношения с человеком исходя из концепции что он лжец, ну это уже разная жизненная философия у нас с вами, а не подход к работе.
11. Первая моя реакцию на эти перья будет - "Да у меня и покруче тебя заказчики были".... и начнем мы с заказчиком меряться заказами а не проект обсуждать.
12. Глупо с стороны опытного исполнителя. Раз загнуть цену можно, но для богатого клиента выгоднее сбросить цену, т.к. заказов у него обычно бывает много, да и статус заказов повыше, что влияет на портфолио.

Про флаги:
1. Очень часто допускаю не ошибки даже, а описки, Из-за элементарной нехватки времени.
2. Телефон у меня опубликован, но всеми силами отговариваю заказчика мне звонить, за исключением единственного звонка для знакомства и то желательно не сразу (время отнимает , см п2). Просто потому, что телефонные разговоры не записываются, а аська записывается.
3. Опубликовал свое портфолио 3 месяца назад. Доэтого просто не было времени заняться, и без того заказов хватало. И знаю ещё многих хороших исполнителей, которые так и не опубликовали портфолио.
4-5 в принципе согласен.
Сергей Колесник
40 лет, Россия
18 сообщений
#12 лет назад
Про опечатки очень жестоко, у меня да и многих есть техника печатания одной рукой .
плюс я всегда не слежу за грамматикой если изливаю мысли потоком и в онлайн в аске.
Это не фактор безграмотности и тп, а не достаток возможности мгновенно переносить мысли путем печатания без проблем. Проше было бы говорить по телефону. думаю что излишне вы слишком критичны в этом. нельзя этим оценивать человека,только делать выводы что он специфичен в общении, по аска и тп и просить быть внимательней.
Бюджет безусловно привлекает всех особенно и профессионалов как и орды новичков.
Меня всегда убивает факт экономии на работе людей кто живет в этой области, и желание заказчика сорвать экономию себе. в результате вы часто получает работы просто тупо ниже уровнем от третьих лиц. Это как в магазине, где вы хотите вкусно есть купить, вы проходите мимо витрин с лучшим и вкусным, в отдел уцененных товаров.
Во первых это опасно для здоровья, а во вторых люди со стажем и фанатики всегда, могут дать вам ,лишь двигаясь фактором увлечения иногда умноженного на оплату за профессиональность огромный и вкусный вам результат.
Это вызывает отношения как к дешевому рынку в котором не нужны хорошие и лучшие веши, а к чему вы тогда стремитесь господа. поэтому у нас до сих пор проблемы у всех.
Я застал эпоху фрланса в начале и был рад 2001 и тп тогда было много европейских заказчиков кто стремился просто сложить в вас средства чтоб получить лучший результат.
Затем как-то выбыл в связи с работай реалии и тп сейчас опять вошел в этот мир, а тут все изленилось не в ту сторону. Это неправильно и не будет приносить вам высоких планок если для их достижения увас вдвинуты минимумы. чисто на практике и в примерах ни один специалист в области 3д видео и сложного дизайна не будет сам собрать модели машины в отношений 1 в 1,делать вам заставку или ролик аля Голливуд.
Или верстать сложный дизайн где на работу нужно минимум 2-5 человека дней интенсивных и плотных по часов 18 рабочих.
Поэтому правильная оценка труда ,приоритет поставленных планок качества и их достижения должен быть. плюс для достижения лучших результатов увас всегда должен быть адекватный выбор и желание умноженное на стремлие не только экономить , а на лучший результат получить от заказа и этим вы должны двигаться к тем кто может его вам дать и осуществить. иногда не забывать о общении и того что вы должны быть от части психологу к исполнителю, для стимулирования и попытки понять его, чтоб он лучше работал. если вы безусловно заинтересованы в качестве.
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
Отвечать "сквозь в зубы". Тут я согласен с FlaPS_Team. Например мне ежедневно по 10-15 предложений в день поступает. Скорее всего, благодаря тщательно проработанному резюме и позиции в TOP 10 (хотя наверное меня из TOP 10 скоро вытеснят). Но из этих предложений 95% - мусор. То есть проекты, которые нужно делать месяц, и за которые платят 80 USD. Главная проблема для меня в том, что "заказчики" сразу это не говорят, просят детально оценить, составить эстимейт, рассказать о себе побольше, посмотреть на мои работы в действии, собеседуют по техническим вопросам... То есть тратятся часы времени, и потом оп-па, оказывается что бюджет проекта меньше, чем стоимость уже потраченных на общение с заказчиком человеко-часов.

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

Далее, за годы фриланса я заметил, что заказчики часто задают одни и те же вопросы. Слово в слово. На такие вопросы я в блокнотике заготовил ответы-"рыбы", подробно отвечающие на эти вопросы. Например, почему я не делаю бесплатных эстимейтов. Или почему я не хочу ехать в страну/город заказчика и работать над его проектом в его офисе. Или почему ТЗ недостаточно, чтобы сразу начать работу над проектом. И копи-пастом вставляю в переписку. Это тоже очень помогает экономить время, если заранее представляю что меня спросит заказчик, и заранее знаю что ему отвечать.

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

Опечатки. Понятно что опечатки это плохо, и их количество нужно минимизировать, но... Я в ICQ часто пишу с опечатками. Прошу не обижаться. Причина в том, что писать без опечаток не проблема, просто это раз в 10 дольше, так как приходится перепроверять то что пишется. А я считаю, что заставлять собеседника ждать минуту после каждого его сообщения это большее неуважение, чем изредка допускать опечатки. Ведь я при этом экономлю время не только свое, но и время моего собеседника.

А если идет одновременная переписка в 5 окнах ICQ? Где же столько свободного времени найти, чтобы перепроверять каждое сообщение... IMHO пусть уж лучше будет одна опечатка на несколько предложений, чем растягивать пятиминутный разговор на час. Или я не прав? Вот где не допускаются опечатки, так это в офлайновой переписке, в предложениях к проектам, в документации, и т.д.

Портфолио. Можете мне поверить, что за более чем 15 лет ежедневного программизма у меня за плечами сотни успешных проектов. Если я в свое портфолио добавил лишь несколько работ, то основная причина только одна - экономия времени. На добавление одной работы в портфолио нужно потратить минимум полчаса своего времени. Если нужно добавить например 20 работ, это фактически убивает целый рабочий день. Несколько напрягает, да и не очень-то и нужно, и так заказов полно.

Другая причина, это невозможность добавления работ, которые делались под NDA. Поверьте, большая часть заказчиков требует соблюдения полной конфиденциальности. Тем более, учитывая, что большинство заказчиков, которые сливают работу фрилансерам, это на самом деле посредники, и не хотят светить перед их заказчиками тот факт, что работу делали не их штатные программисты, которых возможно и в природе не существует, а фрилансеры. И чем серьезнее проект, тем меньше шансов что заказчик или посредник разрешит даже упомянуть, что фрилансер хоть как-то касался его проекта.
Тер С.
45 лет, США
536 сообщений
#12 лет назад
Эта... не надо путать опечатки и ошибки. У меня самого полно опечаток. Но когда человек пишет вот так Цитата:
вы меня не правельно понели. я всегда сразу говорю свои условия заказчику чтобы не зря я трател время на: осмотр ТЗ, консультацию, на разговор, на материалы, на трафик. если вы согласны с моими условиями так и скажите дальше я расмотрю точное задание и материалы и буду старатся вам угоднить, так как у еня опыт работы не мальекий и я давно для себя решил что это самый то вариант общение с клиентами. я принощу извенение если что не правельно сказал.
это не опечатки.
Игорь Грицишин
37 лет, Украина
519 сообщений
#12 лет назад
Цитата ("Mauser"):
В общем твердо понимайте ЧТО вам надо получить и понимайте это в документированном виде готовым к раздаче.
6.Не делайте слишком много домашней работы. Во-первых помните что исполнитель по идее знает предмет лучше вас. Не надо учить дизайнера рисовать, кодера програмировать, архитектора пользоваться UMLем. Не накладывайте ограничений КАК люди будут работать, но не слезайте с них по поводу того, ЧТО должно получиться.

Готов подписаться под каждым словом. Вы наверно единственный Заказчик который мог такое написать.
Андрей Щ.
32 года, Россия
190 сообщений
#12 лет назад
Давно преклоняюсь перед такой фразой - "заказчик/менеджер/тимлидер должен говорить ЧТО и КОГДА. Но ни в коем случае не определять КАК"
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
Цитата ("magemerlin"):
давно преклоняюсь перед такой фразой - "заказчик/менеджер/тимлидер должен говорить ЧТО и КОГДА. Но ни в коем случае не определять КАК"

Категорически не согласен. Если заказчик знает КАК нужно делать работу, то пусть и требует это. Всем от этого будет лучше. Тут же у нас чуть ли не половина заказчиков - сами технари.

Приведу пример. Заказываю верстку. Не определяю КАК, просто заказываю сверстать макет. Получаю отстойный избыточный HTML, мешанина из таблиц, и т.д. Это нормально? А вот если я укажу в задании что хочу "дивную" верстку, которая должна делаться таким-то образом, с учетом тех-то требований, такого-то стиля, похожее на то-то, то я и получу именно то, что я хочу.

Или заказываю PHP скрипт. Не говорю КАК он будет делаться, а просто определяю что он должен делать. Получаю гнилой ламерский код, без единого коммента, мешанина PHP кода и HTML, и т.д. Это нормально?

Все-таки, IMHO, если заказчик/менеджер/тимлидер способен поставить задачу, и сказать КАК должен делаться проект, он должен это делать обязательно, если не хочет вместо проекта получить каку. Процесс разработки, методология, внутренние стандарты - все это не менее важно чем результат, так как это гарантирует достижение этого самого результата. И чем крупнее проект, тем более это явно видно.

Именно поэтому на крупных проектах часто нанимают внешних экспертов для ревьюинга кода и документов. Это намного эффективнее и дешевле, чем поступает Mauser, поручая проект нескольким командам одновременно (как я понял, он, по сути, изобретает велосипед, учится на своих ошибках, это тоже неплохо, IMHO, он на данный момент лучший заказчик на Weblancer.net). А так что толку, если дать двум-трем командам один и тот же проект, если эти команды слабы технически, или же не слабы, но процесс разработки которых не поставлен...

Более прогрессивный подход - взять стабильную команду-исполнителя, и взять эксперта на стороне, вне этой команды, который будет пасти процесс разработки, исходники, документацию, etc., отправляя ежедневные отчеты заказчику и менеджеру команды разработчиков. Хоть такой эксперт - и несколько дорогая персона для многих заказчиков, но такая работа занимает обычно у него 1-2 часа в день, так что и выходит его задействование недорого.
Николай М.
34 года, Украина
1895 сообщений
#12 лет назад
tvv, в десятку!
И то правда, даже сам иногда за собой замечаю, что своей работой нужно кому то похвалиться, чтоб послушать критику, так и делаю, то есть оценивают все, вплоть до исходников, а критика всегда будет порождать качество. Если говорить про большие и мегабольшие проекты, то посмотрите вокруг, для єтого создаются целые команды наблюдения за качеством. Quality Center

Но давайте немного отойдём от фантастики и посмотрим как оно есть:
менеджеры/посредники и т.д.:
здесь можно увидеть многих менеджеров, иногда даже до идиотизма доходит, стучит ко мне чел. и предлагает мне проект который я только что смотрел здесь, за пол сумми :shok: єто что менеджер ? Єто пиявка ! Конечно с такими и говорит нету о чем! А как тогда отличить менеджера от пиявки ? Я вот например не знаю, и просто с ними не работаю вообще!

Всегда приятно работать с чел. который понимает о чем едет речь, что ему чётко нужно, и как єто сделать, но таких здесь крайне мало, но єсть, именно заказчики которым нужен качественный и быстрый результат, перед тем как написать тендер, сто раз подумают, подготовят все материалы, проведут исследования и только тогда будут писать тендер. С такими просто приятно работать, потому что уже будет ориентир, и думаю со мной согласятся, что бюджет проекта особого значения не имеет и не есть показателем "крутизны". Вот напр. гдето пол года назад здесь висел тендер на 1 лимон баков (написание банковской системы), сума впечатляет, но объем работ колоссально большой, и тянет на 5-10 лимонов (30-50 чел. * 5 лет упорной работы), но как только могло прийти в голову писать такие вещи в две строчки :shok: ? Здесь без смеха не обойтись

Многие заказчики наверное забивают, что как заплатят, как пообщаются, так и будет проходит работа, и конечный результат. Но если заказчик загоняет смешные цени, то результат будет таким же. Напр. можно написать программу-аналог блокнота, за 5 у.е., а можно и за 50 у.е. + получить точный клон её секрета (про который я конечно не сказал, но знал) и за 50 у.е. потрудился и дописал, и мне хорошо, и заказчику приятно (как бонус), щас уже мало кто практикует систему премий, то есть если проект выполнен на 100%, ни шага влево, ни в право, и от исполнителя не било намёка на продолжение работы или расширения проекта, то конечно ему надо просто заплатить, а вот если предложить улучшения, путь развития и т.д., но думаю заказчик обязан как минимум задуматься над словами исполнителя, и конечно прибавить какую не будь премию. Скажете фантазёр? А вот и нет, бил проект на тест веб-сайта, конечно здесь били важны результаты теста, заказчик бил рад когда я его завалил идеями, багами и т.д., и мой гонорар вырос в 5 раз! Я про єто даже и не говорил, просто понравилась работа, а оценили как надо. Вот что означает заинтересовать в перспективности тендера заказчика, а когда все всем нравиться то и заплатить можно и нужно больше, и заказчик сам потом будет знать кого звать, на очередной тендер, а исполнитель не будет задавать глупых вопрос, а будет работать на все 200%!
Уважаемые заказчики, разве не єто Вам нужно ?

У меня всегда такое сравнение в голове:
Заказчик - должен смастерить лодку, в которую он должен забрать с собой только исполнителя, река - єто проект, который вам нужно прогрести, отчалили... вот теперь исполнитель и заказчик на одной лодке, если утонут так только двое, если доберутся то как после рыбалки будут делиться впечатлениями от плавания. Но руководить как грести должен заказчик, если плохо скомандует, утонут двое! А если хорошо скомандует, то и шторм не страшен. Но не перестарайтесь, помните, в исполнителя весло в руках

Даже песня такая есть:
Машина времени - "За тех, кто в море".

П.С. Предлагаю сделать гимном сервиса
Как рекламу не воспринимать !
Виктор Брылев
37 лет, Украина
226 сообщений
#12 лет назад
Цитата ("magemerlin"):
давно преклоняюсь перед такой фразой - "заказчик/менеджер/тимлидер должен говорить ЧТО и КОГДА. Но ни в коем случае не определять КАК"

+1. В общем случае заказчик не разбирается в программировании/дизайне/SEO-раскрутке. Бывают исключения, но на них опасно ориентироваться. За годы работы я ни разу не встречал заказчика который бы читал "банду четырех", знал бы, что такое нормализированная форма или понимал бы где и когда нужно применять Ajax. Именно поэтому ориентироваться на подобные технические подробности со стороны заказчика значит сделать проект хуже чем можно было бы.
Контакты. Я никогда не даю клиентам контакты которые не хранят свою историю потому, что все решения во время переговоров должны быть задокументированы ("чтоб не было 3.14здежу делай все по чертежу" (с)). Любая деталь оговоренная по телефону но забытая - идеальный способ поссорится с заказчиком. Если деталь касается ключевых вопросов, то ругань с исполнителем вам обеспечена. В случае переписки по аське/скайпу/email такие проблемы исключены по определению т.к. в любой момент можно указать конкретные дату/время/место в письме где было договорено делать так, а не иначе.
Андрей Щ.
32 года, Россия
190 сообщений
#12 лет назад
Цитата:
Категорически не согласен. Если заказчик знает КАК нужно делать работу, то пусть и требует это.

Нет-нет, мы не поняли друг друга! Если заказчик говорит "верстка дивами", то он говорит именно "что" а не "как", он задает критерии результата, а не вмешивается в процесс. Точно так же - программирование с применением технологий/стандартов - это критерии результата (скрипт использующий аякс и написанный по вот таким стандартам кода да еще и прогнанный через ПХПдок и т.д.), а не вмешивание в процесс (ты вот сначала мне эту функцию разработай, потом вот тут прикрутку поставь, и смотри же, тут ты должен предусмотреть, что через два дня после дедлайна тебе убить 50% кода нужно!).
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
Цитата ("magemerlin"):
Точно так же - программирование с применением технологий/стандартов - это критерии результата (скрипт использующий аякс и написанный по вот таким стандартам кода да еще и прогнанный через ПХПдок и т.д.), а не вмешивание в процесс (ты вот сначала мне эту функцию разработай, потом вот тут прикрутку поставь, и смотри же, тут ты должен предусмотреть, что через два дня после дедлайна тебе убить 50% кода нужно!).

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

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

Я например, если кому-то отдаю проект (иногда длюсь своими проектами), стараюсь всегда иметь доступ с SVN или CVS, и нещадно критикую код который разрабатывается, и советы даю как улучшить. Проект от этого только выигрывает. Да, возможно разработчикам некоторым это некомфортно, но для проекта это лучше, если я чувствую что мой опыт не меньше, чем опыт исполнителей.

И когда я сам делаю проекты для кого-то, то только приветствую подобного рода "встревания" со стороны заказчика, по сути дела, получаю в команду бесплатного эксперта-ревьюера-тестера в его лице.
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
Но на самом деле процесс - это не только "ты вот сначала мне эту функцию разработай, потом вот тут прикрутку поставь". Скажу своими словами. Процесс в IT - это прежде всего задеклариванный способ разработки проектов, основанный на определенной методологии, основывающийся на некоторых заданных принципах. В определения понятия процесса входит документооборот, последовательность действий, итерации, стратегии работ при наличии тех или иных условий, и много еще чего.

Пусть заказчик вмешивается, это хорошо. Скажу большее IMHO. Некоторые методологии даже требуют, чтобы заказчик вмешивался во все что происходит в проекте на всех этапах. Например XP (хотя лично я не сторонник XP).
Богданович Александр
58 лет, Россия
42 сообщения
#12 лет назад
Mauser

Цитата:
ну каковы шансы что он помнить что-то более сложное?


Слово помнить - в данном случае употребляется с мягким знаком или нет?

а как это?

Цитата:
какие-то приемы програмирования он запоминает и правописание.


в слове програмирования я что-то не заметил вторую букву "М"

Цитата:
Один из лучших некода дизайнеров РБК был из Азербайджана родом

А вот в этом случае нужно быть повнимательнее, при написании слова "некогда" буквы пропускать не надо.

Цитата:
Все хорошие прграмисты и


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

Судить о правильности написания программного кода по грамматике русского языка не верно. Я знаю много высококлассных программистов, которые сами не могут и письма написать, а коды набивают так, что они соответствуют стандарту с первого раза. Но есть такие, например, "программистки", которые письма как раз и пишут очень красивые и грамотные, а вот с кодом не дружат.
Андрей Щ.
32 года, Россия
190 сообщений
#12 лет назад
TVV, да, наши мнения не совпадают. В отдельно взятых проектах может быть все, что угодно, и тыкание пальцем, и контроль кода... Я же хочу сказать, что в целом, рассматривая абстрактную универсальную структуру организации работы, менеджер (вобщем, тот, кто контролирует процесс, назовем его менеджером), не должен влезать внутрь разработки. Почему? Я считаю, что при этом происходит неоправданное дублирование полномочий. Думаю, вы согласитесь, что при реализации конкретного алгоритма один человек даст больше продуктивности, чем два. Конечно, две головы лучше, но тогда происходит уменьшение эффективности работы.

Вы настаиваете на процессе контролирования работы (тоесть мы берем специалиста из мешка, а потом, смотря на результаты его работы, им руководим, по сути превращая двух людей с двумя головами и 4 руками в монстра с одной головой и 4 руками). Я же считаю, что нужно использовать несколько другой подход - обучать специалиста методикам (на рабочих проектах или нет - не будем затрагивать этот вопрос), а потом давать ему право самому в них ориентироваться, ограничивая лишь постановкой цели. Так мы не теряем голову программиста.

По сути, это проблема стиля руководства. Есть понятие авторитарный стиль (это вы, интересуетесь всем), а есть - делегативный, когда мы рассеиваем по структуре право принимать решение.

Может я сумбурно выразился, я готов перефразировать свои мысли. Приглашаю к обсуждению
Андрей Щ.
32 года, Россия
190 сообщений
#12 лет назад
И поожалуйста, огромная просьба, давайте не будем тут меряться. Старайтесь не прикопаться к словам, а постичь суть того, что вам пытается рассказать автор. Была уже тема о трасте, ее засорили мерянием пиписьками. Пожалуйста, убедительная просьба, не нужно начинать все с начала!
Екатерина Пешехонова
37 лет, Россия
15 сообщений
#12 лет назад
Оффтопик
Цитата:
Судить о правильности написания программного кода по грамматике русского языка не верно. Я знаю много высококлассных программистов, которые сами не могут и письма написать, а коды набивают так, что они соответствуют стандарту с первого раза. Но есть такие, например, "программистки", которые письма как раз и пишут очень красивые и грамотные, а вот с кодом не дружат.
судить о правильности написания программного кода по полу тоже не совсем правильно