Вопросы к разработчикам

В большей степени относится к разработчикам прикладного ПО на заказ (вне зависимости от используемых технологий).
Какого объема и характера проекты вам чаще приходится делать - крупная система с нуля, доработка существующей системы, создание нового приложения "по типу" или "как ***" существующее, мелкое приложение и т.д.? В какой форме заказчик обычно ставит вам задачу? Как часто вам дают ТЗ в виде некого структурированного документа? Кто обычно составляет ТЗ - вы получаете готовое, его формируют вместе с вами, его нет вообще (по сути это означает, что вы сами себе его создаете в голове)? Насколько обычно вам понятна задача, которую ставит заказчик (понятна сразу, требуются некоторые пояснения, очень много пояснений, вообще ничего непонятно)? Как часто вы или заказчик использует моделирование будущего приложения, предметной области или процессов (UML, IDEF, блок-схемы и т.д.) Примерное количество успешно завершенных лично вами проектов (т.е. оплаченных и уже используемых заказчиком приложений)?

Спасибо.

С какой целью интересуемся?

Shevron, это моя работа (см. персональную информацию).

Цитата ("analit"):

Shevron, это моя работа (см. персональную информацию).

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

Одно дело делиться душевными мыслями в стиле "как я стал фрилансером", и совсем другое - предоставлять такие confidential сведения.

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

tvv, простите, я не подозревала, что эта информация конфиденциальна
И пользу приносить вам совсем не собиралась.
Видимо, вы меня неправильно поняли.

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

Спасибо.

Цитата ("analit"):

tvv, простите, я не подозревала, что эта информация конфиденциальна
И пользу приносить вам совсем не собиралась.
Видимо, вы меня неправильно поняли.

Таки да, конфиденциальна. Например, обратитесь в любую IT компанию где такая информация собрана (практически у каждой такое есть), и попросите ответить на эти же вопросы, как Вы думаете, что Вам ответят?

На Ваши вопросы можно ответить навскидку, например "100% проектов успешны и оплачены заказчиком", "работаю только по четкому ТЗ", "не работаю без предоплаты". Но фактически в жизни оно все наоборот у подавляющего большинства фрилансеров. А давать Вам подробный отчет (а как же, иначе оно будет мусором, который Вашей аналитике только помешает) никто не заинтересован, если Вы - "пользу приносить вам совсем не собиралась".

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

analit, Между нами analit'ами тут много среди заказчиков представители серьезных контор, только они шифруются (шепотом)...
Конечно на сайтах серьезных контор можно прочитать, что у них серьезная команда профессиональных программистов, но стоит одному-двум программером, которые действительно тянут лямку и бремя компании, заболеть, как руководители проектов начинают "пастись" тут...

alecad, tvv, большое спасибо за ответы
Судя по ним, мои предположения о состоянии дел в этой области достаточно близки к истине.

Но может, у кого-то есть и другие мысли.

analit, А в общем тут скучно. В смысле скучно с заказчиками. Одни выигривают тендер на аналогичных зарубежных площадках и находят здесь негров, которые сделают тоже самое только по-дешевле. Другие заказчики выставляют проекты и требуют выполнить их дурацкими способами, а все из-за того, что они не знают ту или иную технологию, которая помощет упростить или улучшить какие-то свойства ПО. Как говориться, что нам не знакомо, то нам чуждо, поэтому для них приходиться "изобретать велосипед", то есть тут подводит квалификация заказчика.

analit, Серьезные конторы болеют старой "конторской болезнью" - есть руководитель проекта, который отвечает за него, но спросить за этот проект некого...

alecad, если ты не в состоянии объяснить заказчику, что и как нужно делать, то вам не стоит работать вместе.
Получиться гадость, останетесь недовольны оба.
ЗЫ. посмотреи на цены рентакодера, шутников везде полно.
При наличии базыи опыта, можно жить с 2-х фрилансерских сайтов компании из 5 человек, проверено на себе.

SmartDesign, объясняю... но в ответ на целый "роман писанины" получаю ответ, что мне так не надо, я так не знаю и не хочу или я это не знаю и вообще я где-то что-то слышал...
вариации ответов разные на один и тот же смысл...

SmartDesign, alecad, я думаю, разница еще территориальная имеет место.
У нас есть постоянные клиенты из бывших республик и из разных городов РФ - имела возможность сравнить и подход к задаче, и постановку, и отношение заказчика, и бюджеты, и гибкость - поверьте разница ощутимая. Исключения бывают, но редки.

Предпочитаю работать по четко сформулированному ТЗ. Хотя часто приходится самому формировать, слишком много людей которые что-то хотят, но не могут объяснить это грамотно.
Когда я работаю непосредственно на основной работе, то и задачу и ТЗ разрабатываю сам. Неважно, это новая система или модернизация старой. Хотя предпочтительнее новая. Здесь естественно я сам рулю, и задача мне понятна. Остается доказать ее полезность начальству.
Если заказчик предоставляет готовый проект, описанный на каком-нить языке моделирования, и если я знаю этот язык/нотацию, то ваще ему респект. Все ясно и понятно. Но обычно это сумбурный набор требований и пожеланий + общее название системы. Такое встречается даже чреди серьёзных контор, сотрыдники которых предпочитают шифроваться (как сказал товарищ alecad).
И к словам alecad Цитата:

analit, А в общем тут скучно. В смысле скучно с заказчиками. Одни выигривают тендер на аналогичных зарубежных площадках и находят здесь негров, которые сделают тоже самое только по-дешевле. Другие заказчики выставляют проекты и требуют выполнить их дурацкими способами, а все из-за того, что они не знают ту или иную технологию, которая помощет упростить или улучшить какие-то свойства ПО. Как говориться, что нам не знакомо, то нам чуждо, поэтому для них приходиться "изобретать велосипед", то есть тут подводит квалификация заказчика.

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

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

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

keymaster, с точки зрения разделения ответственности, в том случае, когда одной из сторон является разработчик, постановка задачи - это зона ответственности стороны, выступающей в качестве заказчика. Критерием служит потребность. Если разбираться в ТЗ тяжело - так и скажите, либо переделать ТЗ, либо не беритесь за работу. Не путайте "принимать участие в постановке задачи" и "ставить задачу самому себе". Нюансы ощущаете?...

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

Больших заказов немного, но именно потому, что они большие. Когда заканчивается большой проект до того как попадается очередной большой проект делается большое количество мелких.
По ТЗ могу сказать, что чаще всего в письменной форме заказчик сфомулироваться свои желания без наводящих вопросов не может потому связь через ICQ практически круглые сутки. Это по мелким проектам.
В крупных проектах без ТЗ никак. Уточнения начинаются после предоставления первого релиза.
Моделирования будущего приложения среди русских заказчиков не встречал ещё ниразу.
Гаразда приятнее работать с забугорными заказчиками. И ТЗ сформулируют чётко и мыслей что можно кинуть нет.

Цитата ("Arkhangel"):

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

А еще они культурные и платят на порядок больше местных.