Здравствуйте, Gaperton, Вы писали:

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

ДФ>>У меня значительная часть проектов была связана с тем, что существующие процессы не устраивают заказчика, и вместе с автоматизацией меняются и алгоритмы работы. Т.е. нужно автоматизировать не то, что есть, а то, что должно быть.
ДФ>>И собственно НИР — это построение картинки того, что должно быть. Включая, возможно, всякие навороты.
G>Это реинжиниринг бизнес-процессов, который вообще-то лежит вне контекста автоматизации. Совершенно отдельная работа. Выполняется специально обученными консультантами, а не программистами. Это, если угодно, совершенно отдельный НИР.
G>Кстати, позвольте вам не поверить, что вам его обычно специально заказывают и оплачивают клиенты. Наиболее вероятно, что они его инициируют самопроизвольно, когда вы начинаете докладывать менеджменту результаты вашего обследования. Что, разумеется, сразу вызывает кипучую деятельность, и тормозит вашу работу. На моей памяти был случай, когда такое "вовлечение заказчика" привело к полному срыву контракта на автоматизацию.

По-моему, мы в разных мирах находимся. В большинстве случаев меня (на должности team-lead) ставили перед фактом заключения договора на некую работу (называемую обычно "система автоматизации {процесса|отдела|учета}) с оговоренными сроками (и суммами). Почти всегда заказчик предполагал, что в результате автоматизации будет проведен и реинжиниринг бизнес-процессов (хотя в договоре это не всегда отражалось, просто при попытке понять, а что собственно автоматизировать, из имеющегося хаоса (для внешнего наблюдателя) выявляются процессы, роли, потоки данных и т.п. — то, чего раньше вообще не было отрефлектировано. И процесс фиксации — это уже реинжиниринг).
Никаких докладов менеджменту, разумеется, не было, предполагалось (менеджментом), что каким-то образом будет построена некая система, удовлетворяющая заказчика.
Скорее всего, если иметь навыки сбора требований, аналитики, бизнес-процессов, то классический процесс будет оптимален — тут я не берусь спорить. Но в реальности этих навыков у team-lead зачастую нет и, мне кажется, то, что называют agile методологиями позволяет, за счет роста стоимости проекта, все-таки сделать хоть что-то осмысленное.
В противном случае вероятность успешного результата (проект удачно внедрен, используется и приносит пользу) очень мала.
При использовании некоторых техник agile (скорее всего неофициального использования) — есть шансы, что хоть что-то будет хорошо.

Собственно, анализируя старый опыт, я понимаю, что там, где я неофициально использовал стандартные техники agile (частые сборки, новые версии выставляемые заказчику, активную работу с заказчиком, приоритеты от заказчика) удавалось сделать хоть что-то. Там, где я делал большие части проекта, понадеявшись на "случайное" ТЗ (хотя по нему и была проведена вполне качественная работа по проектированию, планированию, кодированию) — весь результат пошел в топку.

Я не берусь сказать, насколько часто team-lead играет роль и аналитика, и бизнес-консультанта и специалиста в предметной области — но подозреваю, что ситуация, когда ему приходится это делать довольно распространена. Думаю, ситуации, когда он не умеет это делать действительно хорошо — тоже достаточно обычна. К тому же довольно нелегко team-lead признать, что он плохой аналитик и не умеет описывать бизнес-процессы. Я, например, только в процессе этого обсуждения это понял

(Да, на всякий случай, все мои примеры — с разных мест работы, с разными типами заказчиков. Объемы проектов (фактические) — единицы-десятки человеко-лет. От ERP до web-разработки).


Дальше идут мелкие примечания, вопросы и самооправдания

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

G>Алгоритм и бизнес-правила согласуются дешевле и быстрее. Для этого полнофункциональный билд излишен.
Гм. А где-нибудь описана методика согласования бизнес-правил и алгоритмов? Просто по моему опыту есть явная проблема в языках. Формальное описание бизнес-процесса или алгоритма (со всеми условиями) не готов воспринимать заказчик (специалисты в предметной области или конкретные исполнители), а приблизительное описание (которое он может предоставить) обычно дырявое и приводит к некорректным результатам. Картинки не помогают, увы (или я их не умею рисовать — что, в общем, то же самое).
Собственно, из-за подобных коллизий многие проблемы в алгоритмах и вылезают только в полнофункциональном билде и тестировании на живых данных.
(Заметим, что предоставить живые данные до запуска многие заказчики отказываются из-за соображений секретности, а сделать корректную модель — тоже не в их силах).

G>А то я не сталкивался с этой проблемой — автоматизация во время реорганизации . Надо взять паузу, чтобы заказчик устаканил свои процессы. Разработку тормознуть, выделить заказчику аналитика. Какой смысл вести разработку постоянно переделывая?

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


G>2 часа на роль — обычно хватало с избытком. Надо знать, что надо спрашивать, и главное — что спрашивать не надо. Вы с менеджерами поменьше говорите, и будет гораздо меньше 8 часов.

Угу, в следующий раз попытаюсь поднять предложенную литературу и научиться проводить обследование. Увы, раньше не умел, сейчас работа другого профиля.
Обидно, что даже не понимал, что не умею ;(

ДФ>>>>А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?

G>Кроме того, аналитик должен уметь внимательно читать документы.
Опс, не понял, что "стадия"!="фаза". Но да, читать документы нужно внимательно.
Но, прошу прощения, входящие документы я обычно читаю по три раза и с карандашом, на форум вечером сил остается меньше...


ДФ>>Обычно, впрочем, не везет и на часть вопросов по алгоритмам или нужным процессам следует ответ "сделайте, там посмотрим, подходит или нет".
G>А вы вопросы задаете по нужным процессам? Ну вы даете. Разумеется, вам так и ответят. Вы должны сами уметь процессы идентифицировать и описывать, в этом работа аналитика и состоит.

Гм, я правильно понял, что подтверждение корректности выделенных процессов пользователем не требуется? Я, почему-то, всегда считал, что нужно выделить, описать, а потом — согласовать правильность моего понимания.
По поводу "сделайте — там посмотрим": а какое правильное поведение в тех случаях, когда заказчик должен принять некоторое решение (выбор)?
(Например, в отделе закупок явно воруют. Предлагается менеджментом насильно внедрить систему автоматического выбора подрядчика, для этого возможно два "книжных" существенно различных подхода (сильно влияющих на проектирование). Я обычно считаю, что выбор должен сделать заказчик. Но часто звучит именно "сделайте, а там посмотрим".)

G>Почему не получить? Не понимаю. У меня всегда получалось. И вообще — по моей практике это редкость, по большому счету заказчику все равно, какие будут решения, лишь бы удобно было.
Уф, завидую. В моей практике есть проекты, задержанные на год, пока топ.менеджер выбирал цвет фона и дизайн отдельных элементов для ПО. Причем согласованные на первом этапе эскизы были проигнорированы (проект внутренний, понятное дело).

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

Я бы уточнил чуть-чуть: когда нельзя провести качественный анализ и обследование — то стоит вести разработку короткими итерациями.
Возможно, это хорошая оценка применимости agile техник.
Т.е. agile — от недостатка опыта/умений.

G>Мой тезис — заказчик никогда не знает, что он хочет. У него есть общие критерии, и все. Это ваша работа, выяснить, что ему на самом деле нужно.

Угу, но я долго шел до этого понимания. И, кстати, методики определения "чего ему нужно" до сих пор не знаю. Но зачастую (особенно в "авторитарных" конторах" к целям автоматизации это "что нужно" отношения не имеет...
Кстати, а действительно ли это работа аналитика? Зачастую заказчику нужно увеличить, например, обороты — и для этого он, зачем-то, заказывает веб-сайт или CRM. До заключения контракта еще можно объяснить, что для этой цели нужно нечто совсем другое. Но если заказ уже спущен — то любая деятельность не приведет к результату. Есть разумное поведение в этих случаях?