Информация об изменениях

Сообщение Re[2]: Сбор, систематизация и анализ требований vs кодирован от 24.08.2022 13:30

Изменено 24.08.2022 13:41 Shmj

Re[2]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, gandjustas, Вы писали:

G>Чем делают программисты 85% времени? Видимо этот самый "сбор, систематизация и анализ требований".


Нахождение оптимальных решений. К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований? Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код.

G>Потому что многие считают, что для анализа нужна более низкая квалификация, чем для написания кода. Средний ценник системного или бизнес-аналитика ниже ценника программиста.


Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?

Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.

G>По факту такой анализ требует больше знаний, умений и навыков, чем программирование.


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

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


Не по большей части — а просто нет иного пути. Вы представляете себе, чтобы до написания кода некая команда просто анализировала требования и рисовала квадратики? Я не могу такого представить.

Это все процесс кодирования — написания кода. И этот процесс включает исследования.

S>>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?

G>Этот вопрос надо задавать не сообществу, а тому кто делает утверждение.

Интересует мнение и опыт других.

G>Я, например, считаю что до начала кодирования нужно проектирование интерфейсов. С артефактами в виде интерактивных прототипов UI, для пользовательского UI, или коллекцией запросов в Postman для будущего веб-сервиса. Естественно эти прототипы должны быть не просто художеством в вакууме, а согласованы с программистами, которые их будут делать. Наличие заранее подготовленных таких артефактов, по моему опыту, помогает сократить время на написание кода до 10 раз.


Даже согласование с программистами не поможет — пока не начнешь делать — не поймешь все ли нюансы учтены в API или нет. Даже не подумаешь о том, что всплывет в процессе использования.

G>А если никто заранее этого сделать не может, то идем итерационным путем — делаем прототип, получаем фидбек, переделываем. Схемы, диаграммы и длинные текстовые описания не помогают.


Я хотел бы посмотреть в глаза человеку, который это может сделать. Узнать что он выдает по итогу — как проверяет гипотезы.
Re[2]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:

G>Чем делают программисты 85% времени? Видимо этот самый "сбор, систематизация и анализ требований".


Нахождение оптимальных решений. К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований? Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код.

G>Потому что многие считают, что для анализа нужна более низкая квалификация, чем для написания кода. Средний ценник системного или бизнес-аналитика ниже ценника программиста.


Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?

Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.

G>По факту такой анализ требует больше знаний, умений и навыков, чем программирование.


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

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


Не по большей части — а просто нет иного пути. Вы представляете себе, чтобы до написания кода некая команда МЕСЯЦАМИ на хорошем окладе просто анализировала требования и рисовала квадратики? Я не могу такого представить.

Это все процесс кодирования — написания кода. И этот процесс включает исследования.

S>>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?

G>Этот вопрос надо задавать не сообществу, а тому кто делает утверждение.

Интересует мнение и опыт других.

G>Я, например, считаю что до начала кодирования нужно проектирование интерфейсов. С артефактами в виде интерактивных прототипов UI, для пользовательского UI, или коллекцией запросов в Postman для будущего веб-сервиса. Естественно эти прототипы должны быть не просто художеством в вакууме, а согласованы с программистами, которые их будут делать. Наличие заранее подготовленных таких артефактов, по моему опыту, помогает сократить время на написание кода до 10 раз.


Даже согласование с программистами не поможет — пока не начнешь делать — не поймешь все ли нюансы учтены в API или нет. Даже не подумаешь о том, что всплывет в процессе использования.

G>А если никто заранее этого сделать не может, то идем итерационным путем — делаем прототип, получаем фидбек, переделываем. Схемы, диаграммы и длинные текстовые описания не помогают.


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