Как поссорились системный аналитик с прикладным разработчиком
Недавно на uml2.ru зашла речь о том, полезен или вреден аналитику опыт программиста. Борода этой дискуссии теряется за горизонтом, но все же, попробую субъективно высказаться.
В действительности, вопрос не в наличии или отсутствии какого-либо опыта – опыт лишним не бывает, – а в том, как человек им пользуется, и в профессиональной ориентации. Хотя трудно себе представить, чтобы кто-то мог долго заниматься делом, которое ему не слишком нравится – программированием в-частности, – но есть же мазохисты… :)
Определить постановку, написанную программистом, я могу с первого прочтения – она отличается высокой детализацией и почти полным отсутствием трассируемости требований. Иначе говоря, из этой постановки почти невозможно понять, какую пользовательскую задачу решает тот или иной алгоритм или функция. Преимущество ее в том, что на уровне реализации она оставляет минимум свободы для творчества – т.е. предположений, догадок и фантазий. И это хорошо, если с ней работает только программист и если существует некий другой документ, описывающий функциональность на более высоком уровне абстракции, и эти документы согласованы между собой :) В общем же и целом, заниматься анализом требований программистам, мягко говоря, не надо… Проектированием – да, при условии, что оно выполняется на основе уже собранных требований. Собственно говоря, это такие очевидные вещи, что вообще непонятно, почему они до сих пор еще где-то обсуждаются.
Генетически, аналитики ориентированы на работу с людьми, поэтому разбираются в человеческой психологии гораздо лучше, чем в объектной модели. Это помогает получать информацию и расставлять приоритеты. Хороший программист имеет другую профессиональную ориентацию (иначе ему не надо заниматья программированием :)), собственно которую он и реализует в своей работе. Есть гармоничные варианты, но я сейчас о традициях, а не об исключениях. Незатейливая (как всегда) истина заключается в том, чтобы дать каждому возможность заниматься своим делом, обозначив ту зону ответственности, которая соответствует его профессиональным склонностям, и доверять ему в этой зоне.