Petro123 ShooraПротивопоставлять аналитика и архитектора нельзя! Они - одна команда.
интересно, если адвоката не противопоставлять прокурору что получится?

Нужно не противопоставлять, а руководить! Если хотите, чтобы ваш продукт продавался (аналитик угадал что хотел заказчик).
ЗЫ. Архитектор это неугадает, за редким исключением.

Лживая аналогия про судопроизводство. Разные процессы.
Вы уж определитесь, что мы создаем - коммерческий продукт или автоматизацию конкретной конторы. Если коммерческий, то есть понятие Product Manager, а не аналитик. И сотрудничать с ним тоже надо и еще как. Нормальный аналитик не угадывает желания заказчика, а анализирует требования и увязывает их с техническими возможностями, о которых ему никто кроме архитектора не поведает.

AlexTheRaven
С противопоставлением согласен. Но только сколько же надо бить программиста по голове, чтобы он стал таким кодером :) ? IMHO таких кодеров физически не существует. Звание "кодера" присваивают, когда с программистом трудно спорить (далнеко не всегда потому, что он неправ, но упёрся), и проще сказать "да ты ничего не понимаешь, вот тебе укрупнённый алгоритм, вот описание фреймворка, делай как я сказал или уходи!"

Так и называйте вещи своими именами. Кодер - это кодер, устоявшейся термин. И есть схемы процессов с сильными менеджерами, проектировщиками, тестерами, интеграторами, техническими писателями и кучей кодеров, в баг-трекере которых с утра стоит задание "реализовать такой-то алгоритм в этой функции" со всеми входами - выходами а в конце кнопка - передать на тестирование. А ноги здесь растут из дешевизны таких кодеров и трудности общения с ними, поскольку когда в США день, в Индии ночь :) В России из-за проблем с мотивацией разработчиков большая текучка кадров в этой роли, поэтому и получается, что работодатель держится за проектировщика. Замкнутый круг. В некоторых конторах с этим борятся, пытаются внедрить нормальные процессы... может, через какое-то время что-то изменится.

Сергей Васкецов
Ваша позиция понятна и даже находит у меня понимание, но сформулирована недостаточно корректно.
Каюсь :)

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

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

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

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

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

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

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

Сергей Васкецов
Бывает, и не так уж и редко. Это называется "сработались". НО! Все такие случаи, которые я видел, характерны тем, что оба человека выполняют обе функции (в разной степени) и разграничить их полномочия и ответственность бывает трудно.

Значит, не все случаи видели. А разграничиваются эти роли вполне четко. Открываем тот же RUP и смотрим различия. При этом не путаем BusinessA, QA, SystemA и SystemArch.

Сергей Васкецов
Я был свидетелем очень многих ситуаций, когда аналитики пропускали (и в итоге выпускали) очевидный "бред". Было даже несколько случаев, когда этот бред пропускал архитектор всего проекта, в прошлом разработчик, по идее, хорошо знающий систему. Один случай запомнился особо, я тогда был молодым и еще только пришел. Аналитик спроектировал реализацию(!), подсунул ее для согласования архитектору, тот ее пропустил. Доработку делал не я, но мне архитектором было поручено прочитать и высказать критические комментарии. Я ответил, что в данном виде функциональность работать будет, но так никто не делает (а логика там в принципе стандартная, но задевает всю систему, и делать надо один раз и сразу правильно), потому что расширить ее будет невозможно. Это проигнорировали со словами "некоторые возможности расширения есть", "расширять шире них не потребуется" и "заказчик уже подписал". Перефразируя, это выглядело как "поучи жену щи варить". Через год после выпуска доработки встал вопрос о такой модификации, которая была уже невозможна в рамках старой концепции, на что я поставил аналитику в укор, что он меня не послушал. Если бы заказчик общался напрямую с архитектором, такой беды не возникло бы. А у аналитика не было задачи сделать сразу так, как надо.

Замечательно - не смогли убедить людей в правильности своего мнения и запомнили это на всю жизнь.

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


Использование "тупых кодеров" - экономическая целесообразность. не более того.

Сергей Васкецов
1. Если вдруг возникает ошибка, я как разработчик знаю куда идти править (я про код). Если новый человек и все задокументировано - он не знает куда идти, и хорошо если знает, где узнать, куда идти, а не трясет за рукав коллег по цеху. Время устранения неисправности, если сама по себе неисправность небольшая, увеличивается в разы. Если клиент ждет исправленный билд как на иголках, ему плевать, что у вас все суперзадокументировано и взяли нового сотрудника подешевле. Да и если рассматривать исходной код системы как источник знаний о ней, то смысла документировать все дваджы вообще никакого не вижу. Итак, документ изначально не дает исчерпывающей информации о системе.

А вот это - самая большая глупость, которую Я прочитал за сегодняшний день...

Сергей Васкецов
2. Если делается небольшая доработка, то ее нецелесообразно документировать во всех деталях. После ряда таких доработок никто кроме разработчика уже не может точно ответить, где используется та или иная функция, о существовании которой архитектор даже не знает. Где используется функция или таблица, любой разработчик найдет за секунды, и это будет единственно правильный источник знаний об этом. Итак, документ с течением времени перестает быть актуальным. Полная аналогия мануала.

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

Сергей Васкецов
3. Если надо сделать новую функциональность, то необходимо понять, что затронется. Архитектор может это понять только на основании собственных знаний о системе. В реальности это часто выглядело так: "Сережа, давай посмотрим, как там это сделано", и это еще хорошо. Потому что иногда это выглядело и как реплика с моей стороны:"Так сделать нельзя, надо по-другому, а что тут написано - вообще бред, а сделав вот так, все будет работать быстрее". Итак, документ не является источником знаний о уже сделанных и выпущенных недоработках независимо от того, отражены они в документации или нет.

Архитектору гораздо удобнее работать с моделями, а не живым кодом. Знаете, почему место преступления осматривают только днем? Лучше видно! У вас какой-то гибрид архитектора и тимлида.

Сергей Васкецов
4. Есть такое понятие, как code review. С трудом представляю, как его инициатором может быть архитектор (не лазающий в код) или аналитик.

Есть. Не входит в компетенцию архитектора. Никаким боком. За код отвечает главный разработчик. Архитектор может совмещать роль разработчика БД, но если он будет лезть еще в код, он точно ничего не успеет.

Сергей Васкецов
В смысле, не просто тупо раз в неделю или спросить соседа перед заливкой в CVS, а, например, на предмет анализа идентичных функций.

А как такие ф-ии могут появится в нормально спроектированной и задокументированной системе? Самописка разработчика? Или вездесущий архитектор тоже что-то забыл, потому что не записал?

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

Плохо. Это должно быть в голове у тимлида и в архитектурной документации. Если эта вещь трудоемкая, нестандартная и т.п. была реализована в другом проекте, она должна быть в базе знаний.

Сергей Васкецов
Частично это повторяет первый пункт, частично показывает, что изменение системы может быть таким, что оно не отражается в документации в той части, которая должна быть отражена ввиду изменения классификации этой части, так как разработчик не знает об этой классификации.
5 и далее - еще куча всяких примеров, лень разжевывать.

"Пп-переведи" (с) "Москва слезам не верит"

Сергей Васкецов
Я для себя решил, что в проекте стоит документировать, а что не стоит, но не расскажу об этом. Замечу только, что сейчас меня никто не пинает, но я сам себе пишу ТЗ. Ох неспроста это!

Ни вапрос. Храните Великую Тайну

AlexTheRaven Shoora<...>Кодер - это кодер, устоявшейся термин.<...>
Спуститесь с небес, выйдите из башни из слоновой кости в реальный мир.
Если бы всё было так просто - красивые схемки давно переводились бы в реальные системы автоматически, одной кнопкой.
Нет кодеров в природе. Есть программисты, которых считают кодерами. В качестве их кода виноваты те, кто ставит им задачи слишком подробно, наивно считая, что знают их работу лучше их самих. А они, между тем, решают сложнейшую задачу:
1) удовлетворить реальные требования клиентов;
2) удовлетворить амбиции постановщиков.

Да все понятно. Я прицепился к термину. В жизни нет "кодеров" "аналитиков" "архитекторов"... есть люди. личности. и создавая отношения и взаимодействия в конкретно взятом отделе IT вы всегда решаете уникальную задачу. Я говорил о сложившемся сейчас в большинстве российских компаний подходе к кадровой политике.

Сергей Васкецов
Я писал про конкретных людей, а не про Ваше понимание RUP (кстати, при чем тут RUP?).

RUP я взял в качестве общеизвестного примера моего нынешнего представления о разнице между аналитиком и архитектором.

Сергей Васкецов
Как пример ошибки, допущенной всеми, кроме разработчика, в качестве опровержения тезиса и немеренной полезности аналитиков.

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

Сергей Васкецов
Откуда вы сделали такие выводы? Проект основной с 92-го года живет, я еще тогда даже не работал на нем, сейчас только часть для сборки релиза из VSS по Get latest version в архиве rar занимает где-то 150 мешков. Вся история требований и изменений у меня хранится. Просто первое фиксируется по факту возникновения, а второе получается автоматически из CVS. И найти, что и когда было сделано, тоже просто. И, кстати, разработчик с опытом участия в конкретном проекте быстрее это найдет, потому что помнит хотя бы, в каком году и кем это сделано. Если Вам не приходилось разбираться в проекте, в котором разработчики и проектировщики более недоступны, я за Вас рад, а мне доводилось. И скажу, что проектная документация - последнее, куда в таких случаях надо соваться (ибо нет гарантии, что там все правильно), прежде всего это исходный код.

По-моему, проект, живущий с 92-го года и не собирающийся помирать достоин нормальной документации. Реверс-инджениринг это больно, это не сиюминутная выгода но ради живого проекта на него стоит идти. У нас есть один большой проект, выполненный сторонней организацией, тоже собираемся с духом...

Сергей Васкецов
Зачем мне отдельно архитектор и главный разработчик? Это как раз лучше в одном лице, если Вы вообще выделяете ГР-а. В конце концов, обучите архитектора читать код, если он его не умеет читать и Вы видиет проблему в том, что ему "не видно". В конечном итоге продукт создает разработчик, все остальные должны ему помогать, а не мешать в виде лишних прослоек.

Как раз потому, что в задачу архитектора не входит копание в коде, иначе он не будет выполнять своих обязанностей. Архитектора можно вырастить из программиста, можно из датабейзера, может придти суперталант после университета. Для исполнения роли архитектора не надо быть супер-алгоритмистом - у него другие задачи и скилы.

Сергей Васкецов
Вы меня удивляете. Простейший пример - поддержка уже внедренного софта. А вообще похоже, мы с Вами на разном уровне абстракции разговариваем. Я могу Вам сказать, что я как-то в одном проекте обнаружил 4 функции по обработке строки, 3 из которых делают одно и то же, а 4-я просто инвертирует некое условие в результате. Все они идентичны с точностью до переобозначений переменных и отлажены по самое небалуйся. Это не предмет заботы архитектора и еще кого-то, кроме конечного разработчика.

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

Сергей Васкецов
Не все влезет в архитектурную документацию. Тем более в голову. Тем более, что то, что похоже снаружи, не всегда похоже изнутри, и наоборот. Да и смысл документировать что-то в размере, втрое превышающем документируемую сущность, как-то неясен. Пока же у Вас прослеживается мысль, что можно все задокументировать, и это позволит набрать на работу "тупых рабоников". Но научить документировать каждый шаг можно и обезьяну, это рутинный побочный процесс. Это как в высшей математике, дифференцировать можно научить кого угодно, интегрировать - уже нет. Потому и не понятно, чем наличие документов, базы знаний и т.п. может уменьшить требование к исполнителям. А если оно не может уменьшить требование, то зачем тогда настаивать на тотальном документировании, если оно требует еще больше ресурсов?
Неверный вывод. Я не предлагаю нанимать на работу тупых. Ни в коем случае. Никогда. Но я говорю, что даже суперумник не в состоянии держать в голове код годовой давности и тем более причины, по которым было сделано так, а не иначе. Такое ощущение, что вы все время говорите про одну неизменную вечную команду всем довольных друзей хорошей квалификации. Интегрировать тоже можно научить - не аналитически, так численно :) Не надо воспринимать документацию как рутину. Она вам же поможет в анализе проблем. Попробуйте что-то сказать, а потом записать. Чувствуете разницу? Я это почувствовал например сегодня с утра, поняв, что нечетко сформулировав свои мысли на форуме теперь уже полдня пытаюсь объяснить, что я имел в виду :)

Сергей Васкецов
Я таки не пойму, по-Вашему, архитектор должен следить за конкретной реализацией? То есть, ходить и за каждым подтирать?
И еще раз для тех, кто в танке. Исходный код не может быть предметом документирования в месте, отличном от самого исходного кода.

Для тех, кто на броневике. Исходный код оставьте разработчикам и займитесь проектированием системы и взаимосвязями между модулями. Рисуйте модели, поддерживайте их актуальность, проектируйте БД, определяйте требования к серверам и клиентским тачкам. Если сами не в состоянии поддерживать актуальные спецификации, пусть это делает кто-то другой, но делает.

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