Рекомендации для заказчиков и исполнителей по разработке

[romanbiz]

Почему я считаю, что могу давать такие рекомендации?
Я достаточно неплохо разбираюсь в специфике BAS (на форуме с 28 МАР. 2017 Г, создал на форуме несколько полезных инициатив: каталог фрилансеров, лайфхаки итп), в организации разработки (в вебразработке с 2003, на fl.ru с 2007) много раз находился по разные стороны баррикад как заказчик и как исполнитель.

Безусловно, ряд советов, которые будут приведены в рекомендации будут в духе "капитана очевидность", для многих, а также это можно найти в google, но так как проект BAS все больше набирает популярность будет появляться все больше "непрофессиональных" заказчиков и таких же исполнителей. Также я постарался чтобы в моих рекомендациях учитывалась специфика сообщества (или можно сказать сцены) BAS.

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

Я искренне надеюсь, что мои рекомендации будут полезны как исполнителям, так и заказчикам. Буду благодарен за дополнения и советы.

Рекомендации:

1. Техническое задание должно быть подробным. Не делая подробное техническое задание заказчик отдает себя на добрую волю исполнителя. А исполнитель рискует не получить постоплату. На некоторых проектах, которыми я руководил технические задания писались месяцами, а разработка выполнялась за несколько дней. Это- нормально. Можно не доходить до таких крайностей, но понимать, что пробелы в ТЗ могут по разному трактоваться, важно и нужно. Есть хорошая поговорка, "Чем больше бумаги, тем чище пятая точка".
2. Договор и техническое задание это не одно и тоже. В договоре прописываются сроки, санкции за их невыполнение, информация о поддержке софта/лицензировании, порядок коммуникации и работы. В техническом задании расписывается информация о том, что и каким образом (технологически, например) будет реализовано. Может показаться, что в коммьюнити нет потребности в договоре, в мессенджере перепиской можно договорится, да и нет гарантии, что человек выполнит обязанности (учитывая специфику сообщества BAS). Но используя гарантов, репутационные рычаги договор может быть рабочим механизмом.
3. Обширные тесты до приемки работы жизненно необходимы. Особенно, если заказчик работает с исполнителем, который не имеет репутации в сообществе. Для исполнителя это также важно, особенно если в договоре не прописаны гарантийные обязательства и/или срок гарантии ограничен. Чтобы через энное количество времени не объявлялся заказчик с претензиями, что его софт где-то сбоит в некоторых случаях.
4. Использование третьих сторон-профессионалов. Гаранты (можно использовать гарантов с различных форумов типа zismo, migalki итп), тестеры, писатели ТЗ. Крайне рекомендуется, но безусловно, учитывая специфику разработок на BAS могут быть нежелательными из-за угрозы приватности. В таком случае рекомендовал бы разделять систему на модули и работать с предоплатой и постоплатой за создание каждого модуля. При модульных расчетах, даже если заказчик потеряет деньги потеря не будет столь существенной.
5. Профессиональный разработчик не всегда профессиональный исполнитель. Это значит, что даже самый профессиональный и умелый разработчик, с отличными навыками разработки может быть не очень хорошим руководителем и организатором проекта. Отсюда срыв сроков, неумение понять заказчика, превратное понимание задачи если ТЗ скудно составлено без деталей.
6. Дилемма предоплаты. Когда оба участника процесса не имеют репутации в сообществе (а заказчики, как правило, не имеют ее) возникает проблема риска мошенничества с обеих сторон. Лично я рекомендую заказчикам если не хотите рисковать нанимать разработчиков, которые хотя бы полгода на форуме и имеют хотя бы 30-50 сообщений (а еще лучше тех, кто больше, но у них, как правило, много заказов и высокий ценник). А исполнителям рекомендую общаться на форуме, чтобы заказчик понял что Вы специалист, а не мошенник, который хочет взять предоплату и кинуть. Также, не забываем о модульной разработке из пункта 4. Рекомендовал бы заказчикам прежде чем производить постоплату посмотреть на работу системы и пощупать ее через показ экрана в Anydesk, например.
7. "Какой у Вас бюджет?". Лично меня этот вопрос исполнителей повергает в ступор и является однозначным маркером некомпетентности или мошенничества. Профессиональный исполнитель должен, если от бюджета зависит какие варианты могут быть реализованы, не лезть в карман к заказчику, а вкратце написать о том, какие варианты возможны. И предоставить заказчику самому выбирать, что он хочет получить из этого. Поэтому, если исполнитель задает заказчику подобный вопрос, по моему мнению, заказчик должен ответить так: "огласите список вариантов на разные бюджеты, пожалуйста". Если вариант оказывается один, то исполнитель просто хотел понять сколько максимум он может получить с заказчика. Профессиональные исполнители имеют достаточно твердые расценки, как правило, имеющие в своей основе стоимость часа работы.
8. Заказчики, проверяйте портфолио. Просите разработчика показать разработки (через показ экрана прсмотреть работоспособность), которые тот делал, не являющимися приватными, свои разработки. У более-менее опытного разработчика десятки различных скриптов, в том числе не являющихся сильно приватными (в смысле их можно показать как портфолио).
9. Пропадание. Заказчики и исполнители, будьте готовы, что какая-либо из сторон просто пропадет или немотивированно откажется работать посреди предпроектного обсуждения проекта. К сожалению, непрофессиональные как заказчики, так и исполнители не ценят подготовительную работу и желают поскорее начать разработку. Что ведет к определенным проблемам и казусам в виде того, например, что заказчики получают не то, что им нужно, не в те сроки итп. В результате приводит к спорам, негативу. Иногда даже трудно или даже невозможно понять на чьей стороне правда, косяки есть и у исполнителя и у заказчика. Но не буду драматизировать, иногда ситуации с такими вводными заканчиваются без эксцессов.
10. Санкции. Лично я рекомендую в договоре прописывать штрафные санкции за срыв сроков, как исполнителем (например, за затягивание сдачи работы), так и заказчиком (непредоставление материалов, затягивание оплаты).
11. Документация. Рекомендую заказчикам настаивать на документировании разработки, добавлении описания в ключевые действия, схемы которые используются, комментариев в код, дабы если понадобится через какое-то время доработка исходный исполнитель мог вспомнить что и как он делал или новый исполнитель мог быстро войти в курс дела. Стоимость разработки выйдет немного дороже, но избавит в будущем от множества проблем.
12. Лицензирование. Рекомендую заказчикам и исполнителям заранее фиксировать вопрос лицензирования в договоре (смотри пункт 2), а именно, предоставляется ли проект в открытом коде или как программа с закрытым, может ли заказчик и/или исполнитель распространять разработку и каким образом (с открытым или закрытым исходным кодом). Может ли исполнитель использовать разработку. Безусловно, подобный механизм может работать если есть риск репутационных потерь, но также не надо забывать, что если этот вопрос не был зафиксирован, каждая из сторон может трактовать его в свою пользу.
13. Поддержка и гарантии. Не забываем в договоре прописывать информацию о поддержке и гарантии на работоспособность софта. Заказчики, если для Вас это важно, выбирайте исполнителя, который занимается фрилансом на постоянной основе, а не от случая к случаю. В идеале, чтобы работа на заказ была у него основным источником дохода. Нет ничего зазорного чтобы спросить об этом. Лучше и приватнее в долгосрочной перспективе работать с одним постоянным исполнителем, чем менять их как перчатки.

[Fox]

В целом я согласен, но есть несколько моментов:

нет гарантии, что человек выполнит обязанности (учитывая специфику сообщества BAS)

Не согласен, без договорва нет гарантии везде, даже помимо онлайна или сообщества BAS

Профессиональные исполнители имеют достаточно твердые расценки, как правило, имеющие в своей основе стоимость часа работы.

Не согласен, далеко не всегда можно чётко оценить объём работы. Зачастую приходится перед согласием на заказ изучать сайт продолжительное время, и то потом может всплыть какая нибудь защита.

Заказчики, проверяйте портфолио. Просите разработчика показать разработки (через показ экрана прсмотреть работоспособность), которые тот делал, не являющимися приватными, свои разработки. У более-менее опытного разработчика десятки различных скриптов, в том числе не являющихся сильно приватными (в смысле их можно показать как портфолио).

Во первых это может быть просто слив истока.
Во вторых без заглядывания под капот (в исходник проекта) можно запросто сделать фейк скрипт, который будет создавать видимость работы.
В третьих далеко не все скрипты долгоживущие, редко какой проект заведётся через пол года-год. Да и для каждого проекта нужны свои данные (прокси, аккаунты, сервисы рекапчи и т.д) а они не всегда есть в наличии (например прокси определённой страны, а покупать для показа бессмыслено).

Документация. Рекомендую заказчикам настаивать на документировании разработки, добавлении описания в ключевые действия, схемы которые используются, комментариев в код, дабы если понадобится через какое-то время доработка исходный исполнитель мог вспомнить что и как он делал или новый исполнитель мог быстро войти в курс дела. Стоимость разработки выйдет немного дороже, но избавит в будущем от множества проблем.

При предоставлении исходника да, возможно. Но по опыту скажу, переделывать чужой скрипт (например по просьбе чуть-чуть подправить) в разы сложнее, чем написать с нуля свой.

spoiler

А вообще я согласен, что ставить комментарии необходимо.

---

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

- Вот ваш проект, всё по тз.
- Но он не работает!
- Да, не работает, но зато всё по тз.

Совет заказчикам: Не поленитесь, пролистайте сообщения предполагаемого исполнителя, убедитесь в его компетентности.
Совет исполнителям: Набивайте руку, набирайтесь опытом, старайтесь делать качественно, даже если это не очень выгодно. Довольный клиент придёт к вам ещё не раз и будет советовать другим, а недовольный наоборот будет советовать всем с вами не работать.

[A Former User]

Все это больше похоже на рекомендации для проектов с ценником от 5к$ или даже больше. Проекты на БАС это 50-300$ ну очень редко 1-2к$. Поэтому не дай Бог встретить заказчика, который следует таким рекомендациям. А если встретил, то лучше не связываться! xD

[romanbiz]

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

[romanbiz]

@UserTrue И еще одна причина, по которой Вы снисходительно относитесь к данным рекомендациям. Вы - профессионал высокого уровня с большим опытом. Если Вы беретесь за проект, то делаете быстро, четко. Безусловно, возня с бюрократией для Вас когда Вы уже все знаете и понимаете- излишняя формальность.
С некоторыми допущениями могу сказать что в Вашем ответе проявляются признаки эффекта Даннинга-Крюгера.

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

Но таких как Вы разработчиков в сообществе единицы. Лучше я доставлю неудобства единицам топовых разработчиков пропагандируя эту парадигму, но при этом заказчики и несильно профессиональные исполнители (а это, 80-90% людей) получат хороший результат, чем топы будут довольны, а большинство будет страдать.

[A Former User]

@romanbiz said in Рекомендации для заказчиков и исполнителей по разработке:

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

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

[romanbiz]

@UserTrue Скажите, а Вам не приходила мысль, что с Вами работают не потому что Вы профессиональный исполнитель, а потому что просто некуда деваться из-за дефицита профессиональных разработчиков? И для заказчиков Вы "тяжелый" исполнитель, капризы которого приходится терпеть из-за отсутствия альтернативы?

[A Former User]

@romanbiz Нет не приходила. Мне обычно пишут такое

[romanbiz]

@UserTrue Лично мне кажется, подобные бонусы могут быть как раз таки следствием дефицита и Вашего настроя принимать самые "сладкие" предложения заказчиков, с которыми Вы играете в "БДСМ игры" по Вашим личным правилам. Ваши заказчики прекрасно понимают, что как только их условия перестанут быть наиболее "медовыми" из всех что есть на аукционе, они потеряют доступ к работе с Вами под благовидным или не очень предлогом. Я сталкивался с такими случаями, когда являешься заложником ситуации, к сожалению, приходится играть по чужим правилам полностью подчиняясь им.

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

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

[Jackson]

@romanbiz посоветуйте пожалуйста исполнителей с которыми работали (цена/качество).
Спасибо!

[A Former User]

https://www.youtube.com/watch?v=a27YCMFsob0

[Alex84]

@UserTrue said in Рекомендации для заказчиков и исполнителей по разработке:

@romanbiz Нет не приходила. Мне обычно пишут такое

Тож вот есть Люди ценят мой Труд и вот это ток один Который уважает и даж Более меня на моих Скриптах Зарабатывает ( по его Спонсорству я вижу, порой вообще может и 15 к просто так мол прислать и лиж бы я не терял Интерес кто му то или тому то ) :)
У каждого ведь свои Пользователи и вот они не ток Продлением Лиц так сказать стимулируют, но вот и кто по Умней и так сказать своего Кодера то знакомого хорошо знать и помогают и Идеями и деньгами так сказать :)
Опять же и Репутация на тех же Фриланс Биржах как Продавец.

Порой Люди вообще сами как то с того же Зисмо по 2вух Годовалой Теме находят и просят и делаешь и Другами некоторые становятся :)
Я ОФ Работу получается даж Бросил и вот живу и Ваяю ( учусь каждый день так сказать и это мне в Кайф ).

Вот и тебя и Фокса за Помощь вскоре отблагодарю, тож дельными Советами то помогаите и я это Ценю :)

[IvanM]

@Fox said in Рекомендации для заказчиков и исполнителей по разработке:

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

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