ILAgent, я не заказчик. И в этой роли выступать не хочу.

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

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

0000, вы правы.
Или - доверять кому-то, кто доверяет этому человеку и видел его в деле.

тогда у меня нет шансов 

0000, а зачем они вам? если вы получили новую работу, которой довольны ;)

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

Это предложение не для начинающих совершенно точно.

ida, а можно тестовое задание. Новичком себя не считаю, но и до профи очень далеко.

Добавлено через 3 минуты и 6 секунд
Win32.
Web и пингвины - не мое.

ida, 
Предложение не для начинающих вовсе не означает, что начинающим не имеет смысла даже браться за работу. Вопрос в том - сколько нужно опытного человека? Если опытный нужен на весь рабочий день - одно дело, если достаточно будет пару часов в день - совсем другое. По тому мистическому проекту, что вы предлагаете (кхе, а можно на "ты" перейти?  ) непонятно, какое вливание сил нужно...да кстати, а вообще нужен 1 разработчик или команда? Команда - это все, что больше 1 человека 

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

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

Как-то так мне это видится.

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

Поэтому если делать, то профессионально.

ida, 
ну как, предложений конкретных не появилось?

Всегда считал, что это не правильное выражение.

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

Конечно я не исключаю и обратного.

Например возьмём Joomula или ReactOS, в принципе они бесплатные, но нельзя же сказать, что они не грамотные люди.

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

Меня в университетах этому не учили, но по жизни наблюдал что практикуется следующая схема распределения ролей:

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

Системный аналитик отвечает за проекцию бизнес требований на информационные системы. Ну и собственно за выбор этих систем. Работает непосредственно с бизнес аналитиком. Коммуникативность здесь не столь важна как важна эрудированность и дотошное знание информационных систем. Результат работы - подписание исполнителем ТЗ.

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

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

Я так понимаю Вы себя позиционируете как бизнес аналитика, но от чего же Вы считаете что способны сформировать готовое ТЗ минуя фазу системного анализа? Не имеете ли вы рисков получить программку на вымерших клиппере или фокспро, которая до запятой соответствует ТЗ, но не выдержит промышленных объемов из за не верно выбранной технологии. Или же наоборот. Вместо маленькой легкой прикладухи - решение на оракле аппс+датабаз, за лицензию на которые заказчик должен будет отдать свой годовой оборот.

Если Ваше ТЗ не регламентирует технической стороны проекта, не называйте его ТЗ. Назвайте его "бизнес требованиями".




Это сообщение отредактировал(а) Zloxa - 28.8.2009, 17:19

Тут нужен не ум, а именно то, что я написала - опыт участия в живых проектах.

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


Верно.

Но вы так и не ответили на вопрос, почему они должны интересовать аналитика?
Он не определяет стоимость продукта.


ой-ой-ой. Так мы далеко не уедем.

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


Нет, вы поняли неправильно.


где я это утверждала?


Это не риски разработчика - это риски заказчика.
Возвращаясь к тому, с чего начали - о стоимости конечного продукта.

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

Разработчик рискует ресурсами. Если он правильно оценит свои возможности и масштаб задачи, то получит деньги за работу вовремя. Если нет - может получить не вовремя, или не в полном объеме. Правильность оценки зависит опять же от квалификации. См. выше.

Это сообщение отредактировал(а) ida - 5.9.2009, 16:37

В этой схеме возникает вопрос: а кто берёт на себя административные вопросы (планирование проекта, освоение бюджета и проч.). Потому как если ты подписываешься за людей, то это может быть тебе и поручено. И тогда + к своему творчеству ты становишься менеджером проекта, который, как известно, отвечает за ВСЁ. Это административный ресурс, который отнимет у тебя много времени, сил и т.д. от основного занятия - аналитики. 

Пока заказчиков нет, лучше об этом и не думать 
1. Проще позиционировать свой бизнес как чисто аналитик-консультант, тогда можно сотрудничать с коллективами, которым нужны только такие услуги.
2. На будущее подыскивать не разработчиков, а сложившиеся команды, в которых свой менеджер или хотя бы ответственный тимлид уже есть. Вполне логично в качестве таковых [команд] предлагать те, с которыми уже налажено сотрудничество (см. п.1). 


ЗЫ. Всю тему не читал