Фриланс. Составление ТЗ и техподдержка выполненной работы - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Но для всего остального, я считаю, составление ТЗ это задача исполнителя (техническое задание на плечах технического специалиста, а не обывателя). А вот что обычно понимается под ТЗ скорее можно назвать перечнем желаемого функционала/требований к системе. И то, не полным, требующим уточнения. Когда все пожелания и требования известны, то составляем сухое "технарское" ТЗ (для крупных проектов можно и про существование ГОСТ 34* вспомнить). В ТЗ можно попробовать впихнуть и улучшения, которые видятся исполнителю. Когда ТЗ составлено, согласовываем с клиентом. На выходе все в выигрыше: исполнитель чётко знает, что он будет делать и не сможет отклониться от согласованного технического задания. Клиент не сможет потом предъявить что якобы задача выполнена не по ТЗ. Если не косячить, то все получат то, на что подписались :)
Но всё хорошо в меру: в мелких заказах (а их большинство в фрилансе, как я понимаю) мало кто будет так заморачиваться. Однако в случае с неочевидными задачами без этого будет сложно. Но пока ты будешь составлять ТЗ, десяток-другой "исполнителей" уже набегут со своими "готов! Сделаю вчера! Денег доплачу" :)
Для фриланса, возможно, прокатило бы что-то вроде выражения готовности взяться за работу (только с ценой и сроками можно очень ошибиться), а затем на стадии согласования сформировать ТЗ.
Лично я примерно так и поступаю (не на фрилансе), особенно с новыми клиентам: если задача не очевидна и требует составления чего-то приближенного к ТЗ, то выражаю принципиальную готовность, называю примерную вилку цен и сроков, и говорю, что точно будет видно после согласования ТЗ (только часто это звучит как "после уточнения и согласования задания"). Если клиента устраивает такой подход, то идём дальше. Я расспрашиваю клиента, собираю информацию и после выдаю ТЗ на согласование, с точными ценами и более-менее точными сроками.
Ну и да, работы по составлению ТЗ оплачивает всё таки клиент. Чем лучше он составил пожелания и требования, тем меньше уходит сил и времени на их оформление, тем меньшая надбавка идёт к конечной цене.
Бонус - не все "сложные" клиенты могут пройти стадию сбора информации и отваливаются сами собой на втором-третьем письме. И к лучшему оно: иногда лучше не дойти до реальных работ.
И да, по ТЗ, составленным заказчиком, я тоже иногда работаю - но его составляют технические специалисты со стороны заказчика (в т.ч. по упомянутому ГОСТу частенько бывают, особенно если гос. организация). Но это не частные лица.
Суть моего опуса - не бросайте техническую работу на не технических специалистов. Ну или не считайте их идиотами только потому, что у них нет таланта технического писателя.
Разумеется, это всё лишь моё мнение.
Многие заказы настолько самоочевидны, что ничего уточнять и формировать ТЗ не обязательно.
.....
Суть моего опуса - не бросайте техническую работу на не технических специалистов. Ну или не считайте их идиотами только потому, что у них нет таланта технического писателя.
Разумеется, это всё лишь моё мнение.
Да вот, порой, очевидное не всегда им является. Элементарно одни и те же простые понятия понимаются по разному. Был у меня человек, который считал что стохастик и осциллятор одно и тоже, а не одно является классификацией другого. Вот и перепроверяй как заказчик понимает каждый термин.
Я и не считаю. И не требую четкого техзадания, потому что понимаю, что чаще всего описание идет в виде: "вот когда эта линия индикатора туда, а эта свечечка черная и меньше вон той белой.."
Хотя были задания - где четкий тф, критерии конкретных индикаторов. Т.е. словами рассказывали логические выражения.
Да вот, порой, очевидное не всегда им является. Элементарно одни и те же простые понятия понимаются по разному. Был у меня человек, который считал что стохастик и осциллятор одно и тоже, а не одно является классификацией другого. Вот и перепроверяй как заказчик понимает каждый термин.
Я и не считаю. И не требую четкого техзадания, потому что понимаю, что чаще всего описание идет в виде: "вот когда эта линия индикатора туда, а эта свечечка черная и меньше вон той белой.."
Хотя были задания - где четкий тф, критерии конкретных индикаторов. Т.е. словами рассказывали логические выражения.
Это некоторых клиентов раздражает, но в целом полёт нормальный. Это лучше чем сделать не то, что себе надумал клиент.
Недавний пример - клиент высылает индикаторы и скриншот со словами "сигналы показаны на картинке". А по картинке можно "подогнать" десятки возможных сигналов и их комбинаций. Я взял да и расписал такие сигналы, что у клиента волосы дыбом встали. Но зато он сразу понял к чему я клоню и довольно быстро выслал описания сигналов. При этом да, он не знает, что "тонкая зелёная линия у SuperPuperTrend" это "линия с индексом 5 пользовательского индикатора SuperPuperTrend". Конечно, во всём нужна мера. Но мне не будет слишком сложно, если уж сел писать ТЗ под согласование, сформулировать так: "линия с индексом 5 пользовательского индикатора SuperPuperTrend (тонкая зелёная линия при настройках из высланного шаблона)". Зато как потом просто самому работать с таким заданием! :)
Я искренне очень рад, что Вы так не считаете (это я без сарказма). В своё время я пробовал работать с некоторыми местными специалистами, передавая им задачи (от мелких и типовых, до не совсем тривиальных типа связки разных торговых платформ). Иногда задачи были дико неадекватные, и я это понимал. А иногда они требовали просто немножко уточнений. В обоих случаях чаще всего я выслушивал тирады на тему "ну почему клиенты такие тупые?". Причём я-то знаю что не тупые, далеко не тупые. Даже профессора, пусть и не в этой области, проскакивали. И лично знаком со многими клиентами, точно знаю, что не тупые. И как-то прям обидно становилось за клиентов. До смешного доходило - был один исполнитель, который каждый ответ на мои предложения работы начинал со слов "Этот тупой клиент не понимает, что ...", только слово "тупой" менялось на синонимы. Показательно - ни разу не отказался от работы :)
Я искренне очень рад, что Вы так не считаете (это я без сарказма). В своё время я пробовал работать с некоторыми местными специалистами, передавая им задачи (от мелких и типовых, до не совсем тривиальных типа связки разных торговых платформ). Иногда задачи были дико неадекватные, и я это понимал. А иногда они требовали просто немножко уточнений. В обоих случаях чаще всего я выслушивал тирады на тему "ну почему клиенты такие тупые?". Причём я-то знаю что не тупые, далеко не тупые. Даже профессора, пусть и не в этой области, проскакивали. И лично знаком со многими клиентами, точно знаю, что не тупые. И как-то прям обидно становилось за клиентов. До смешного доходило - был один исполнитель, который каждый ответ на мои предложения работы начинал со слов "Этот тупой клиент не понимает, что ...", только слово "тупой" менялось на синонимы. Показательно - ни разу не отказался от работы :)
Я уже высказывал мысль, что заказчика врядли интересует наше мнение об их заказе, или наши консультации по его поводу. Они хотят чтобы выполнили ТЗ и всё. Потому что мало когда заказчик интересовался сам - а что вы думаете о ТЗ?
Но банальное уважение к персоналиям и вежливость никто не отменял. Вряд ли клиент захочет вернуться к исполнителю, который считает его идиотом (если он об этом узнает) или грубит ему. Меня-то как раз удручает ситуация, когда исполнители считают себя заведомо умней заказчиков. Но мы уже отклоняемся от темы.
Возвращаюсь к теме (второй части заголовка, про техподдержку). Лично я стараюсь руководствоваться следующего подхода:
1) Любые консультации по работе с конечной системой бесплатны (настройка окружения и системы, запуск, эксплуатация);
2) Любые доработки, которые требуют не более получаса работы и при их частоте не чаще раза в неделю (условно, рамки не жёсткие) - бесплатны;
3) Любые доработки, которые требуют более получаса работы, либо которые я не могу оценить без доп. исследований (что-то, с чем я не сталкивался) - платны.
4) Любые доработки, которые поступили раньше, чем через неделю после последней - либо платны, либо "смогу не раньше, чем через неделю".
Опять же, не претендую на истину в последней инстанции.
Не говорите заказчику что Вы знаете что стратегия которая ему нужна сливает.
Исполнитель должен осознавать, что 99% заказчиков ждет от него реализации своей чудо-стратегии, которая после реализации даст ему возможность заработка до конца дней без особых усилий. Если исполнитель не осознает такой примитивной вещи, то имеются большие сомнения в его адекватности. Поэтому первое, что следует говорить после окончания обсуждения технических моментов заказа это фраза: "в полном автоматическом режиме эта стратегия не будет прибыльной на сколько-нибудь длительном периоде истории". Если исполнитель адекватен, но не говорит подобных вещей честно и прямо, то он - "голубой воришка".
Тезис о том, что заказчик сразу поверит исполнителю и уйдет к другому, который не говорит такой фразы, неверен. Никто (по крайней мере, в моей практике) не отказывается от заказа, срабатывает фактор противоречия, оправдания своей ошибки. Люди в своем большинстве не умеют или не хотят учиться на чужих ошибках, доходит только после совершения своих собственных просчетов.
Даже в тех редких случаях, когда заказчик все же уйдет от исполнителя, который не поддерживает его золотые горы, вовсе не стоит расстраиваться. Да, в текущий момент исполнитель недополучил 5 копеек, но с точки зрения человеческой жизни он сделал огромную инвестицию в свое будущее и будущее окружающих его людей.
Исполнитель должен осознавать, что 99% заказчиков ждет от него реализации своей чудо-стратегии, которая после реализации даст ему возможность заработка до конца дней без особых усилий. Если исполнитель не осознает такой примитивной вещи, то имеются большие сомнения в его адекватности. Поэтому первое, что следует говорить после окончания обсуждения технических моментов заказа это фраза: "в полном автоматическом режиме эта стратегия не будет прибыльной на сколько-нибудь длительном периоде истории". Если исполнитель адекватен, но не говорит подобных вещей честно и прямо, то он - "голубой воришка".
Извините, но полная ерунда.
Очень редкие единичные случаи -- это когда заказчик, получив советник, смотрит на убытки и думает, что причина в неправильном программировании его стратегии.
Большинство заказчиков как раз очень адекватны и всё прекрасно понимают и не перекладывают проблемы отсутствия профита на разработчика.
Поэтому разработчику вовсе не обязательно умничать насчёт профитности стратегии заказчика.
Мало того, чтобы сделать заключение о профитности -- любую стратегию надо исследовать. Чем разработчик не занимается и не занимался. Его дело маленькое, сделать по ТЗ + внести посильные функциональные улучшения.
Поэтому разработчик, который судит о профитности стратегии заказчика -- некомпетентный.
Извините, но полная ерунда.
Напишу от имени Заказчика.
Работая с разными Исполнителями, я столкнулся с тем, что некоторые просят в ТЗ описать все человеческими словами, другие просят формулы, третьи картинки. Иногда доходит до того, что я частично описываю логику программы с операторами, но и тут находятся те, кто пишет, что мой стиль неудобен или логику можно упростить. Это я пишу к тому, что и Заказчики и Исполнители привыкли воспринимать информацию по разному - это особенности психологии - особенности когнитивного восприятия информации.
Как то раз написал я ТЗ работа - 16925, потратил много сил и времени, но исполнения заказа так и не получил.
По поводу поддержки продуктов, тут я столкнулся с тем, что Исполнитель не любит возвращаться к исправлению ошибок и багов, даже с его стороны - принял работу и до свидания. Да и сами Исполнители периодически покидают этот ресурс - в этом есть нестабильность и риск потерять уже вложенные деньги в проект, так как нужно все начинать с начала - относится к советникам, которые периодически дорабатываются. Вопрос поддержке считаю необходимым прописать в правилах форума.
Работая с разными Исполнителями, я столкнулся с тем, что некоторые просят в ТЗ описать все человеческими словами, другие просят формулы, третьи картинки.
Ну считаю что восприятие информации у всех разное, цифровое, визуальное. Как у кого лучше. Всё же заказчик должен достаточно понимать свою идею, чтобы ее объяснить исполнителю, ведь нам приходиться ее четко формализовывать в коде. А иначе вылазит после подтверждения приёма работы через недельку - я чуть не то хотел и т.п. Просто выходит такая вещь - заказчик тестит абы как, принимает работу, а потом вылазят несостыковки или он понимает ошибочность тз и началось - а у меня баг, а можно исправить в тз то-то...хочется спросить - зачем во фрилансе шаг - Демонстрация?
Все же я считаю больше часть возможных косяков должно быть исправлено на шаге Демонстрация. Формально техподдержку оказывать никто не обязан. Это уже чисто человеческий момент и вопрос личной репутации.