ShooraГрамотный постановщик (в контексте этой ветки - бизнес-аналитик и архитектор в одном лице) способен организовать ПРОЦЕСС, допускающий ротацию отдельных личностей, вплоть до себя любимого, без ЗНАЧИТЕЛЬНОГО вреда для проекта.
Наверное, это самая большая глупость, которая здесь была написана за сегодняшний день.

iscrafm Сергей Васкецов ShooraГрамотный постановщик (в контексте этой ветки - бизнес-аналитик и архитектор в одном лице) способен организовать ПРОЦЕСС, допускающий ротацию отдельных личностей, вплоть до себя любимого, без ЗНАЧИТЕЛЬНОГО вреда для проекта.
Наверное, это самая большая глупость, которая здесь была написана за сегодняшний день.
можно узнать... почему?
Специально оставил всю цитату.
Почему "самая большая за сегодня" - отвечать с Вашего позволения не буду.
А глупость вот почему. Некто "бизнес-аналитик и архитектор в одном лице" (вообще, кстати, что это за зверь такой?) не несет ответственности за то, что проект в принципе будет реализован. За это отвечает руководитель проекта (собственно, для этого он и предназначен по большому счету). Аналитик по сути заказчик, архитектор - исполнитель. Потому аналитик и архитектор реализуют принципиально разные направления, и отвечать за противоположное направление им по меньшей мере неконструктивно. А обеспечить даже собственную взаимозаменяемость вообще ни у кого нет такой задачи, а как известно, если нет задачи, сделана она быть не может. Лично я вообще считаю, что постановщик (в контексте Shoora) и архитектор обязаны быть разными людьми. Самому сейчас приходится делать "все", потому, конечно, в итоге оно получается быстрее и дешевле, но не считаю это нормальным.

ShooraВ мелких проектах, когда исполнитель погружен в тематику аналитик-архитектор-разработчик в одном лице это оптимально.
Это когда один человек все делает. А если уже 2 человека, то каждый из них "аналитик-архитектор-разработчик"? В общем, Ваша позиция понятна и даже находит у меня понимание, но сформулирована недостаточно корректно. Точнее, когда есть архитектор и небольшое количество разработчиков, и все они хорошо разбираются в предметной области (для полного счастья осталось заиметь поток заказов, например, поддержка существующего продукта), им почти никто не нужен. Мне представляется это наиболее оптимальной формой сотрудничества на многих проектах. Все, что реализуется сейчас в России в IT, о чем мне известно, реально может быть сделано группой дорогих спецов в количестве менее 10 человек, включая QA. Все, что выходит за эту цифру, как правило, просто желание откормиться и отмыться. Потому утверждать, что это удел только мелких проектов, я бы не стал.

ShooraПротивопоставлять аналитика и архитектора нельзя! Они - одна команда. По сути. Если аналитик будет писать ТЗ наедине с заказчиком, ему предложат самому и реализовывать этот бред.
Аналитик изначально формулирует задачу (а не пишет ТЗ!!!) на том языке, который понимает заказчик, и заказчик соглашается именно с этим. Называть это техническим заданием я бы не стал, там по идее должны быть исходные предпосылки на языке бизнеса заказчика. Потому при реализации остается свобода маневра для архитектора и разработчиков. Я видел огромное количество ТЗ, которые писали аналитики с претензией на знание системы, в которую в соответствии с этим ТЗ необходимо было внести изменения, которые (ТЗ) были абсолютно мертворожденные, так как то, что хотели аналитики, нужно было делать совсем по-другому (почему по-другому - здесь не важно). Никто лучше архитектора и разработчиков не знает систему изнутри (если система уже существует и ее надо доработать), а писать ТЗ на разработку без этих знаний невозможно. Еще у меня в памяти очень много примеров, когда аналитик что-то просто забыл, а разработчик это находит за секунды просто обычным поиском по исходному коду системы. Поэтому аналитики в известной степени являются злом для проекта и вполне могут быть вообще исключены из него со стороны разработчика, если имеется тесное взаимодействие с внутренней службой IT заказчика.

Shoora
Начиная от средних проектов (длительность - больше 3-х месяцев, разработчиков - больше 2-х) аналитик и архитектор - разные люди. В больших проектах уже группа аналитиков и группа архитекторов и противопоставить их друг другу значит завалить проект.
Не злоупотребляйте банальностями не к месту, их сразу видно. Ни один проект еще не завалился, потому что кто-то захотел "противопоставить их друг другу".

ShooraПро обеспечение собственной взаимозаменяемости - у вас нет задачи чувствовать себя порядочным человеком и соблюдать минимальную профессиональную этику? Там денег больше дали - все бросил и побежал? Ну-ну...
На примере документирования. Документировать все невозможно, всегда есть идем, которые не задокументированы (в случае маниакального документирования все равно остается то, что только что пришло в голову и не успел задокументировать). А уход ключегого сотрудника это всегда потрясение. Уход аналитика - это самое простое, что может быть на проекте, аналитик не может быть ключевым сотрудником, ибо первичным является не конкретное желание клиента, а технические возможности исполнителя. Уход архитектора, если новая метла заметет по новому, как правило приводит к смерти проекта в первоначальном виде, если новый архитектор будет, грубо говоря, избран из разработчиков, то никакой проблемы вообще не будет (а точнее, если у нового есть знания и не меняется концепция, то с помощью разработчиков он быстро освоит все тонкие места в системе). Потому архитектор для проекта разработки ПО это ключевая фигура и никакой взаимозаменяемости тут быть не может в принципе. Уход разработчика зависит от того, сколько надо времени, чтобы найти и вырастить нового до того уровня. Если это время сильно превышает срок жизни проекта, то брать нового в принципе нецелесообразно. Скажу грубо, если разработчик отвечает хотя бы за полмиллиона строк исходного кода, его уход также может быть фатален для проекта.