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

И вот возникает вопрос - а почему б не заняться и поиском разработчиков по этому техническому заданию.
Т.е. получается следующая модель:

заказчик -> аналитик (т.е. мы) -> разработчик (т.е. вы - кому это интересно)

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


Это сообщение отредактировал(а) ida - 1.7.2009, 18:02

Какие предполагаются технологии?

Ну и форма и порядок оплаты тоже интересуют, конечно.

пока еще ничего не предполагается, потому что заказчиков нет

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

Думаю интересная затея.
Хорошее ТЗ это половина проекта =)

Кстати IDA, там предполагается семинар для новичков в ERP, UML?
Я на 90% в этом году перееду в Питер, сможем много вопросов обсуждать лично.

Сейчас хочу заняться обучением Delphi (как 2ой язык) и ERP-системами.
Так в принципе работаю по-тихонечку на 5 проектами, но это чисто хобби пока =)

ida, 

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

аналитику все-равно какие технологии? ну да ладно...
собстно по сабжу: зависит от конкретной задачи и качества того самого ТЗ. 

ida, ТЗ (как и желания заказчика) могут меняться во времени. Интерпретация ТЗ иногда тоже тонкая весчь. Как планируете это решать?

baldina, я профессионал 

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

Это сообщение отредактировал(а) ida - 2.7.2009, 12:34

ida, самое главное что за проект: веб или программу на компьютер (application).
Также важно учесть какая платформа и готов ли вливать деньги в проект.

Допустим есть 2 заказчика:
1) Хочет веб-приложение. Исполнителю нужно сделать проект, а его поддержку и дальнейшую модернизацию будет делать человек в штате. Заказчик готов вливать деньги в проект.

Значит:
1) Область знаний программиста: Веб
2) Нужно точно уточнить на каком языке делать, т.к. программист, который будет дальше модернизировать, просто может не знать языка на котором написано веб-приложение.
3) Если клиент готов вливать много денег, то берём ASP.NET

Ps в вебе не особо разбираюсь, привёл как пример.

2) Хочет получить программу для компьютера, чтобы она работала на различных платформах (хотя бы на окнах и пигвинах).

Значит:
1) Область знаний: программы
2) Нужно подобрать программиста который знает кросс-платформенные языки


Ps Привёл просты примеры, не особо их разбирая.

Вот аналитику и нужно это знать, ИМХО.

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

Добавлено через 2 минуты и 5 секунд
вероятно это зависит и от того, где кончается аналитик и начинается архитектор 

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

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

Собственно, я пока и оцениваю разные варианты...


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

Это сообщение отредактировал(а) ida - 2.7.2009, 20:18

Одно дело если закачку нужен сайт для фана, другое дело если заказчику нужен функциональный, понятный и удобный сайт.

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

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



Копнём с другого края...а чем занимается аналитик в данном случае и как проходит общение с программистом (исполнителем)?

Этот вопрос решает только заказчик 


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


В каком случае?

Это сообщение отредактировал(а) ida - 5.7.2009, 12:47

Ну когда заказчик заказывает какой-нить продукт =)

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

ida, если это предложение удалённой работы, то я заинтересован.   

Это сообщение отредактировал(а) ILAgent - 6.7.2009, 06:39

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). 


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

Он ее обосновывает.
Первый вопрос заказчика, перед подписанием, уверен будет "во что мне это станет". Врядли он подпишет ТЗ, если ответ будет "может тыщщу, может сто". Результат же работы аналитика не просто написаное ТЗ, а подписанное обоими участниками процесса.

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

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


Как Вы, наверняка, обратили внимание, первый вопрос разработчика - 



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


Это сообщение отредактировал(а) Zloxa - 6.9.2009, 00:49

Я к этому и веду, просто, возможно, достаточно извилистой дорогой 


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


Аналитик не считает деньги (кроме своего гонорара). Для этого есть другие роли.


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


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

А я-то никак не могла понять, почему столько внимания к этому моменту.

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

Это сообщение отредактировал(а) ida - 6.9.2009, 12:35

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


Это сообщение отредактировал(а) Zloxa - 8.9.2009, 09:04

Нет, так не пойдет.
Если разработчик неправильно оценил свои возможности  - значит, он обладает недостаточным опытом.

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

Мой опыт, кстати, демонстрирует, что именно разработчики ошибаются в оценке, хотя по ТЗ у них никаких вопросов нет. Т.е. попросту (оптимизм + отсутствие дисциплины) = заваленный проект.

Это сообщение отредактировал(а) ida - 8.9.2009, 23:24

Да. В первом случае виноват, как правило, аналитик, во втором случае заказчик.  Бывают исключения, но редко. Только доказать это не возможно. Да и кому доказывать то?

То что заказчик может быть не последователен, словоохотлив не по теме, противоречив, и отказывается сегодня подписывать то, что декларировал вчера, вовсе не умоляет Ваших качеств как аналитика. Вам приходится работать с этим материалом, потому как он Вам платит деньги а не Вы ему. Ровно как и разработчик вынужден брать в работу ТЗ, в котором нет ничего технического, исключительно по той же причине. Он либо возьмет это ###, либо будет ждать золото и сосать лапу. Тоже и со сроками. Либо он пойдет на не реальные сроки, либо проект уйдет другим, не погнушавшимся слукавить, мол сроки - реальные. 

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


Через меня, кстати, не проходило ни одно ТЗ, не нуждавшееся в доработке. Если бы всякое уточнение сопровождалось бы доработкой ТЗ и переоценкой сроков, я никогда бы не срывал сроки. ;) Но кто пойдет к заказчику переподписывать ТЗ и сдвигать сроки? Аналитик? Чтобы его заказчик по мордасам да штрафами? А потом обоих нафик с проекта как некомпетентных. Это ведь придется признавать свою вину. Он ведь аналитик а не самоубийца. Потому заметенное под коврик аналитиком приходится выносить разработчику.


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

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

Я не говорю что все разрабы прям уж ангелы. Но с реальными угрозами проектам вызванными некачественной работой аналитиков я сталкивался куда чаще нежели с угрозами вызванными некачественной работой разрабов. Работа разраба куда проще работы аналитика. Хороших разрабов я знаю куда больше нежели хороших аналитиков. И если мы говорим о том, что ТЗ это 80% проекта, то и в срыв проекта как правило на 80% обусловлен ТЗ.

Zloxa, беседа отклоняется от темы, переходя в плоскость "кто виноват" и "как поссорились аналитик с разработчиком".
Это вечные темы, и ваша позиция в них мне ясна. Думаю, уже не только мне 

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

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

Если такие найдутся - поработаем.

Это сообщение отредактировал(а) ida - 9.9.2009, 21:55

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