singalen: (humpty-dumpty)
[personal profile] singalen
Вот почему программисты считают, что требования должен писать кто-то другой?

Ну, то есть, я знаю, почему. Потому что мы хотим колбасить код и больше ничего.

Требования вырабатывают ВМЕСТЕ.
А то сваливаем их на нетехнического специалиста, у которого есть ещё и совсем другие обязанности, а потом сами же на них косим стрелки - мол, неполны, противоречивы и реализуются через место, не именуемое головой.

Бывает, что лучше всех написать требования можешь именно ты.

Если вы, ребята, профессионалы, то сотрудничайте с людями, с которыми работаете.

(no subject)

3/6/11 11:31 (UTC)
Posted by [identity profile] klizardin.livejournal.com
ну да, мне когда очень "нравилось" когда приходилось через абзац возражать бизнес-аналитику, с которым согласился уже PM, и я вот оказывалось, что почему-то ни с чем не согласен. бизнес аналитик был весьма далек от принципов как разработки архитектуры, так и разработки пользовательских интерфейсов. т.е. бизнес-аналитик мог сказать "а вот здесь будет месседжбокс" и делай что хош, но т.к. с этим согласился PM, то даже если это приводит к существенным ошибкам. все равно, "можно ведь просто вывести месседжбокс". еще приходилось и PM-у возражать, что мол замечания имеют смысл.

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

в общем, наилучшее решение для меня оказалось уйти и больше не встревать в решения безнес-аналитика.

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

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