Разработка нового проекта

  • Автор темы Автор темы Cleric84
  • Дата начала Дата начала

Cleric84

Well-known member
03.01.2008
599
0
BIT
17
Всем привет !

Вопрос чисто теоретический, о том кто и как начинает работать над новым проектом. Ведь есть разные фирмы и всюду разный подход.

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

Вопрос чисто теоретический, о том кто и как начинает работать над новым проектом. Ведь есть разные фирмы и всюду разный подход.

Как организирован процес, сначала обсуждение, потом написание документации и т.д
Как поступаете в случае изминении требований?

1. Аналитика, рыба в виде документа, эскиза или базы.
2. Написание ЧТЗ, формирование план-графика.
3. Программирование, тестирование, внедрение по этапам.
4. По результатам внедрения собираешь требования и исходя из них корректируешь остаток - в итоге конечная точка очень близка ожиданиям заказчика.

Чем-то напоминает SCRUM, Agile. Риски в таком случае сильно меньше.
 
Вопрос, ИМХО, чересчур уж общ :-)
Если в двух словах, то:
- дотошно выясняем требования в GUI - расположение окон, шрифты, количество кликов мышкой (!!!). Чтоб Мариванна (а она всегда есть!), была довольна.
- дотошно выясняем права доступа к данным - отмазы "всем дать все" тупо игнорируем. Ибо через месяц у клиентов меняется тов. майор - и разрабы плачут горючими слезами. Ну и плюс логгирование действий пользователй - всегда по максимуму.
Ну дальше ТЗ, т.д. и т.п :-)
 
Тема не для раздела "Программирование". Лучше тогда уж в "Общие вопросы..." бы запостили.
 
2 savl

Фриланс. Заказчики внешние, средней руки.

2 Мыш

Абсолютно бесполезно - только время тратить.
1. Даже если выяснить дотошно - не застрахован, что на показе заказчик скажет: "Это хочу по другому" или "Я думал это будет не так", "Сделайте крупнее.. синее.. светлее" и прочее. Поэтому лучше это время заложить на правки пост фактум.

2. Аналогично и с правами доступа, только при этом заказчик еще и не всегда осведомлен кому что показывать.
 
Придумайте сами себе пару проектов для придуманных заказчиков.
В одном все гайки закручены и все логируется, в другом хороший фейс и все "просто". Да, тут надо поработать :)

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

под ключ крупную работу не зафрилансишь
а учитывая что в процессе работы клиент еще и постановку менять будет то только этапами и бить
 
и сроки, сроки, сроки. Если мелкие изменения. то они не сильно увеличиваются, а бывают когда всю архитектуру начальную в нуль убивают.
Вот это самые поганые изменения.
 
VladSh
В большинстве, но не всегда, бывает неверная постановка изначально.
Особенно когда связано с расчетами разных периодов, их разделение слияние и так далее.
Сам не сталкивался, пока что, а вот коллега столкнулся.
Сделал архитектуру под начальные требования, работало на ура, все делилось/сливалось. Выяснились подробности...
В результате 3 недели на переработку, но сделал лучше чем было.
 
savl
И недальновидность проектирования, и ошибки проектирования от работы по недостаточно полной постановке задачи, от недостатка знаний/опыта. Если человек знает предметную область, то его так легко не проведёшь неверной постановкой. У нас были случаи, что реализовывали не как в постановке, т.к. она была кривая, потом после разбирательств оказывалось, что таки да - мы правы.
В плане проектирования всё проще - что бы не задали, уже автоматом пишешь так, чтобы этот кусок можно было использовать где-нибудь ещё. Хотя, опять же, от недостатка знаний/опыта в определённой области придётся сейчас очень многое перекраивать.
 
От клиента изначально, по большому счету, меня нужны только две вещи: какие документы на входе и что нужно получить на выходе.
Все, что между - давайте оптимизировать под 1 и 2 :)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!