Pull to refresh

Comments 16

аналогично, не совсем понял к чему это.. какой то невнятный крик души получился у Вас.
>>> Но добавлю одно – в целом по моим наблюдениям ситуация требований ухудшается.
Сомневаюсь что раньше было лучше. Заказчика, по-хорошему, нужно растить и обучать. Да геморно, затратно, но все же большая часть со временем вырастает и дальнейшее сотрудничество весьма сносно. Можно дать пинка и ждать толкового, но тогда конкуренты разберут всех бестолковых и сами их обучат.
Надеюсь получилось так же сумбурно, но вы поняли :)
хм. кто кого еще учить будет. Я в крупных компаниях еще не слышал слова доброго о ком то из топ20 интеграторов.
Обучать чему? Формулировать требования? Это не его работа, это работа того, кто выполняет роль аналитика.
Как правило, все проще. Когда у опонента закачиваются объективные аргументы, в ход идут фразы типа "в конце концов я заказчик!", "я лучше знаю что нужно нашим клиентам!" и т.п. На что нужно отвечать: "ок, но мы это говно делать не будем, в конце концов ваш сайт будет в нашем портфолио". Действует практически безотказно.
просто заказчику друдно по временным эскизам увидеть итог работы который вы частично держите в голове и надеетесь реализовать ... ему бы пару грамотных скринов как это всё примерно будет, желательно по срокам о которых устно договаривались а не от тех что в договре, чтобы как-то двигаться дальше
не знаю что конкретно имел ввиду автор поста (к сожалению примеров он не привел), но я говорю не в последнюю очередь об очевидных мелочах. например что не надо в списке новостей делать ссылки "подробнее", о том что на странице товара не нужно делать ссылку "назад в каталог" и т.п. тут никакие скрины не нужны.
ну он всё собрал, а я привёл пример другой стороны под ваш коммент ;) - ну например исполнитель говорит что на главной странице не надо кнопочку/домик на главную ставить тк она главная и в логотипе не надо сслыку, по мне тк надо тк эти элементы управления будут на всех остальных страницах, просто домик надо сделать неподсвеченным/пассивным но возможность ткнуть и попасть сюда же нельзя закрывать темболее убирать его вообще ... и многим захочетс ткнуть чтобы убедиться что они на главной, а не руками в адрес баре обрезать урл до домейна
Далее заказчик фигеет, борзеет и начинает требовать аванс назад :))
Для этого есть процедура анализа требований, в ходе которой можно провалидировать требования, выявить цели, установить согласованность целей с интересами заинтересованных сторон, установить трассируемость требований на цели, потыкать заказчика лицом в истинную проблему, а потом уже давать альтернативу - либо пытаться решать корень проблемы, либо раскрашивать труп.

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

Подробнее здесь: http://beskov.livejournal.com/44800.html
Это был какой-то странный архитектор. Слова типа "большие", "мгновенно" — это из области литературы, а не спецификаций.
Ребята, вы бы с вицпрезидентом какого-нть крупного банка поговорили. Вот бы удивились.
Вщё раз - вице-президент не выдаёт специфкаций. Вице-президент выдаёт информацию о видимой им проблеме и образе её решения.

Аналитик, архитектор, проектировщик - да, должны выдавать спецификации.
Красивое определение. Я скажу проще - выдает приказ.
То есть менеджер проекта - лопух, который либо допускает заказчика к разработчикам, либо не умеет формализовывать требования заказчика хотя бы в виде User Story?
Sign up to leave a comment.

Articles