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

Это может показаться странным, но во вроде бы простой схеме Найти разработчика – Заказать робота – Оплатить работу - Использовать робота. Охренительно много нюансов. И я, с удивлением наблюдаю как заказчики и программисты из нашего сообщества ругаются на пустом месте. И в итоге все остаются не довольными. Так родился этот гайд, ибо я в этом огромный специалист. Как в разработке на заказ, так и в написании гайдов ;)

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

Нужно: уважать друг друга, не создавать друг другу проблем, подходить к работе ответственно(это касается и заказчика) и тогда всё будет хорошо.

Но давайте по порядку…

План статьи

1)      Введение

2)      Два вида разработки

3)      Водопад

4)      Гибкая система разработки

5)      Что выбрать?

6)      Заключение

1 Введение

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

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

   И факт остаётся фактом – большая часть всех разработок коммерческих для OsEngine делается кустарно, не через наш официальный канал. Не зачем с этим спорить, надо просто принять вменяемые правила игры.

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

    Заказчики не оплачивают работу. Платят за ТЗ, а думают что можно менять его в ходе работ или считают что наняли человека на оклад (хотя это два разных типа сотрудничества). Программисты сбегают от заказчиков с деньгами не доделывая проекты. ТЗ не пишется, программисты берут деньги не понимая что от них хотят. Короче – чёрнуха и порнография.

Надо с этим что-то делать…

2 Два вида разработки и оплаты

В разработке программного обеспечения приняты два типа возможного сотрудничества заказчика и исполнителя:

1)      Водопад

2)      Гибкая система разработки или AGILE

И программисту и заказчику следует понимать их различия и на берегу работать по одной из них.

* Я не буду вдаваться в технические подробности этих двух подходов. Всё как можно более понятно и словами которые все поймут. Да простят меня программисты. Нужно чтобы это все поняли.

Водопад – это найм программиста на разработку определённого кол-ва работ по техническому заданию. С заранее оговорёнными работами (по ТЗ) и размером оплаты за эти работы.

Гибкая система разработки – своего рода найм человека на оклад. Когда заказчик изначально не в состоянии предвидеть все работы которые нужно провести и итоговая цена разработки не известна.

И ВСЕ ПРОБЛЕМЫ ОТ ПУТАНИЦЫ МЕЖДУ ЭТИМИ ДВУМЯ ВИДАМИ РАБОТ

Заказчику выгодно заплатить человеку один раз, как будто бы он взял человека на выполнение Технического задания и при этом расширять ТЗ в процессе разработки до бесконечности.

Программисту выгодно попасть на оклад, при этом работая строго по ТЗ.

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

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

3 Что такое водопад?

Если по старославянски перефразировать, то это у нас проектная занятость. Нужно прокопать траншею, рисуем чертёж, ищем копателя ям, договариваемся, делаем, оплачиваем. Хотим копать дальше – опять рисуем чертёж и т.д.

Это когда до начала работ есть полное и достаточное ТЗ для того чтобы начать разработку. И ТЗ не меняется до конца итерации разработки.

Логистика при таком подходе выглядит так:

1)      Заказчиком пишется обширное и большое ТЗ на робота. В нём описываются все нюансы работы робота. Индикаторы которые нужны. Настройки. Пожелания к визуализации. Точки входа и выхода. И т.д.

2)      Программист и заказчик договариваются о цене.

3)      Программист делает ТЗ от начала до конца

4)      Все смотрят на то что получилось. Если заказчик хочет что-то поменять, идём в пункт ОДИН. Т.е. пишем новое ТЗ.

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

Заказчик в 50% случаев не знает что ему нужно НА САМОМ ДЕЛЕ

Это может быть связано с разными вещами, включая:

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

2)      Не понимания скорости реакции робота на происходящее. Большинство подключений к бирже не очень скоростные. Например скорость выставления заявок зависит от интернета и иногда от отправления заявки до её регистрации на бирже может пройти несколько секунд. А заказчик при этом хочет принимать решения о входе/выходе из позиции несколько раз в секунду. И это неизбежно приводит к проблемам.

3)      И т.д. Там на самом деле сотни различных проблем может в процессе возникнуть самых неожиданных.

Программист соглашается на работу без ТЗ, либо с частичным ТЗ.

1)      Программист соглашается на работу без ТЗ совсем. По устным каким-то описаниям робота или по видео. Может делать это как по неопытности, так и после многодневных уговоров заказчика в том что это «не нужно», так и со злым умыслом (ибо он в этой связке более квалифицирован и должен важность этого дела понимать, если хватает опыта). Но оплату за проект рассчитывают как фиксированную. И в этот момент оба, как заказчик, так и программист оказываются в заложниках друг друга. Заказчик расширяет задание по ходу работ, а программист в любой момент может сказать – «извини бро, мы на это не договаривались», и общая депрессия и недоверие начинают расти.

2)      До начала работ не было обговорено либо заказчик недопонял что делаться будет только то что написано в техническом задании. И соответственно заказчик где-то ближе к завершению работ начинает скидывать какие-то переписки в мессенджерах с вопросами: «А это где?».

Оба не понимают границ возможных изменений в ТЗ во время разработки

Также бывает и такое что программист и заказчик в процессе составления ТЗ приходят к выводу о том что в какой-то степени всё же ТЗ изменять придётся. Ибо чудес не бывает.

Но в такой момент важно указать, в какой степени это можно делать. Например что это можно делать два раза и не более чем на 10% ТЗ или чтобы работа по новым штукам не превышала два дня. Если это не сделано – это прямой путь в ад и ссоре.

4 AGILE. Что такое гибкая система разработки?

Для больших проектов на много месяцев это единственно возможный путь. Также это оправдано когда заказчик не может по каким-то причинам написать обширное и достаточное ТЗ для разработки и хочет по ходу работ вносить изменения в задание.

Со стороны заказчика, это взять программиста на оклад, принимая во внимание то что я (как заказчик) не знаю на самом деле когда и где завершится разработка. И то что я буду доделывать ТЗ прямо по ходу разработки.

Но тут возникают множество проблем. Несколько из них:

1)      Программист может расслабится на этом пути и начать работать абы как.

2)      Если коммуникация между заказчиком и программистом плохая, то в итоге всё равно может получится не то что хочет заказчик.

3)      Заказчик может решить вообще не писать ТЗ даже на короткий период, ибо это сложная работа, и процесс разработки усложниться и растянется из-за этого.

5  Что лучше и что в итоге выбрать?

Разработка торгового робота ОБЫЧНО не очень большая по времени процедура. Недели две – четыре. На этот период вполне возможно написать нормальное ТЗ.

Поэтом при самом хорошем раскладе нужно обезопасить обе стороны максимально.

Как заказчику защитить свои интересы

1)      Написать ТЗ.

2)      Программист должен помочь человеку с этим. Написать блокСхему. Заказчик даже может оплатить небольшие консультации если чувствует что плавает в теме. Это поможет получить в итоге то что нужно.

3)      Не соглашаться стартовать без чёткого задания. И ни в коем случае самому это не предлагать.

4)      Понимать что без ТЗ программист в любой момент может сказать «уважаемый, это не было в начальном документе и не обсуждалось, поэтому я всё!»

5)      Обговорите понятие поддержка. Что в неё включено.

Если разработка идёт через Agile и человек у Вас на окладе:

1)      Пользуйтесь системой совместной работы, вроде Trello. Чтобы программист отчитывался о том что он делает хотя бы через день.

2)      Сократите ввод нового функционала до одной недели. Что-то хотите доделать – пишите коротенькие ТЗ, отправляйте в разработку – получайте результат. Это поможет как можно чаще контролировать то что разработка идёт в нужном Вам направлении и корректировать его.

Как программисту защитить свои интересы

1)      Настаивать на написании ТЗ.

2)      Если человек не способен совсем к написанию документа – помочь ему с этим, предложить AGILE или совсем не браться за работу.

3)      Понимать, что если не будет задания чёткого – заказчик может и обязательно в какой-то момент начнёт предлагать доделать что-то что вообще не обсуждалось.

4)      Обговорите понятие поддержка. Что в неё включено.

Для обоих

1)      Интересы у всех разные. Презумкция добросовестности работает только в чётко поставленном поле. Либо вы делаете всё через ТЗ по водопаду. Либо по AGILE с небольшими итерациями. Всё остальное – приведёт к краху и никакой проект никогда не сдастся.

2)      Если Вы пришли к выводу что какие-то доработки потом потребуются. Чётко ограничьте кол-во дополнительной работы которая возможна в дальнейшем.

6 Заключение

Такие дела комрады.

Уважайте друг друга. Не надо никому выкручивать руки.

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

Удачных алгоритмов!