ход разработки проекта - как есть и видимо будет)

Я не сомневался в том , что кто-то ещё заинтересуется - собственно именно поэтому я говорил ,что начиная работать со мной ты в определённой мере рискуешь - так как есть люди куда более опытные (или там умные или красивые))))
Ты в праве решать - как и с кем работать.
"заказчик" - ты
"исполнитель" - я
(просто хочу сформулировать в более общей форме)

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

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

Даже если сотрудничество не состоится в твоём лице "заказчик" имеет плюсы:

  1. проработанный план действий и нормальное тех. задание - всё так сказать задокументировано.
  2. возможность стартовать без лишних слов с новыми исполнителями (хотя не всем хочется чтобы они были)
  3. сам заказчик (то есть ты ) лучше понимает чего он вообще хочет - так как программирование вещь довольно конкретная - аналогично и оформление.

Теперь о команде.
Если предприятие доживает до этапа "запуска" , с точки зрения реализации , оно уже будет иметь:

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

О генерации идей:

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

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

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

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

Кстати - эта вербовка , сделает твоё время (как человека управляющего проектом) на этапе планирования ещё более эффективным.

Comments

vedro-compota's picture

оформляй все в форме .doc файла (ворд) - это удобнее .

_____________
матфак вгу и остальная классика =)