Здравствуйте, Дельгядо Филипп, Вы писали:

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

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

У вас продвинутый заказчик — он понимает, что внедряемая система всегда так или иначе меняет бизнес-процессы. Это хорошо. Лет 7 назад это было в большинстве случаев не так.

ДФ>Никаких докладов менеджменту, разумеется, не было, предполагалось (менеджментом), что каким-то образом будет построена некая система, удовлетворяющая заказчика.

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

Один сорвался вообще фееричным образом — директор увидев первый прототип (я в 1998 году решил собрать ранний прототип системы управления производством, чтобы продемонстрировать директору заказчика с целью "появления аппетита" и увеличения бюджетов — он был умный и продвинутый, МИФИ закончил), дико протащился от заложенных решений, в том числе и интерфейсных, и налабал за неделю на Excel новую версию системы планирования производства сам (старая была тоже на Экселе). А ведь это была не простая торговая конторка с типовыми бизнес-процессами — это фабрика спортивных изделий "Леко" была, там довольно нетривиальное производство. Я вообще не предполагал, что на Экселе можно такие штуки вытворять, блин.

К счастью — если заказчик не понимает таких умных вещей, что типа обследование там и бизнес-процессы, то и схемы бизнес-процессов он от вас не потребует. Поэтому, вы можете ее в явном виде топам заказчика и не предъявлять, исключая риск начала кипучей деятельности. Линейным менеджерам же схему показывать можно и нужно — они крупную реорганизацию затеять не в состоянии.

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

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

Случайное ТЗ — понятное дело отстой.

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

SADT. В книге есть и методика анализа и разработки моделей, и туториал с упражнениями. Эти диаграммы понятны любому идиоту, механическим образом переводятся в связный рассказ на русском языке, но чрезвычайно сложны в составлении с непривычки. Зато если научиться — вы будете нереально круты.

Во-вторых — очень так ничего для описания бизнес-процессов UML Activity диаграмма. Она однозначно проще в составлении, и в чем-то более наглядна, однако с методикой SADT ознакомиться все равно надо, так как там учат не только и не столько нотации, а анализу как таковому. К примеру, вы знаете, что аналитикам запрещено задавать клиенту вопросы, на которые можно ответить "да" или "нет"? Знаете почему? Думаете вы одно, говорите второе, клиент слишыт и понимает третье, и отвечает на вопрос "да". Внимание — на какой вопрос он ответил "да"? Вы не знаете, вы лишены возможности проверить, как он вас понял. А услышав его развернутый ответ, у вас есть шансы это узнать.

Третья вещь, которая поможет в проведении интервью — это мета-модель и милтон-модель НЛП. Раздел, где они учат анализировать и понимать текст, и говорить самому — понятно и непонятно. Пройдя этот тренинг — вы сможете механически, рефлекторно ставить уточняющие вопросы, и устранять ситуации разного толкования одних и тех же слов вами и клиентом. Дополнительный плюс — вас невозможно будет "загрузить" — вы будете прекрасно отличать, когда вам сообщают знание, а когда вешают лапшу. Плюс — вы нужное вам знание по любому вытянете из кого угодно.

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

Модель всегда делает аналитик, т.е. вы. Доверять в этом деле нельзя никому, даже себе. Живые документы увидеть весьма желательно, это очень много неясностей с пониманием смысла полей устраняет. Подпишите с заказчиком NDA, вам нужно по одному печатному документу каждого вида. Не так страшно. Или в крайнем случае — работаейте с ними на територии заказчика. Вам надо руками пересчитать значения полей, чтобы совпали цифры — таким образом вы проверяете как вы поняли смысл полей. Фиксируете ваше понимание на бумаге.

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

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

Добивайтесь частой поэтапной оплаты — и тогда нет проблем, можно вести разработку и так. Собственно, предварительный анализ важен только на fixed cost контрактах, если вы будете добиваться оплаты каждой итерации (фактически — почти повеременка получается) — то можно работать как угодно, за бюджет вы вряд ли вылетите.

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

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

Ок. Почему два часа на роль. Вот приходите вы к тетке, которая, допустим, кассир. Берете у нее ее печатные формы всех документов. Каждый документ фиксирует бизнес-операцию, в которой завязан кассир. Ваша цель на интервью — вычислить scope работы кассира, понять перечень операций, которые она выполняет, из каких действий складывается каждая операция, и записать это на бумаге. Думать в момент интервью не надо — думать в оффлайне будете. В момент интервью вы должны ловить противоречия и недосказанности в речи кассира.

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

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

ДФ>Гм, я правильно понял, что подтверждение корректности выделенных процессов пользователем не требуется? Я, почему-то, всегда считал, что нужно выделить, описать, а потом — согласовать правильность моего понимания.

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

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

Если бизнес-процссы меняются — то лучше ИМХО иметь дело с линейными менеджерами, пусть они проверяют вашу модель бизнес-процессов, и говорят "да". Хотя, тут у каждого свои рецепты. Вообще — даже в случае реогранизации вам все равно нужна модель "как оно есть сейчас". Оптимизацию можно проводить на ее основании с участием линейного менеджмента.

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

Либо попросить их утвердить ТЗ (приложением к которому изложить схему), если случай тяжелый — то утвердить легкий прототип ГУЯ, либо договориться на повременную оплату (или ее варианты — скажем, оплата каждой итерации). Любой из вариантов для вас хорош.

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

Внутренний проект — иногда бывает просто игрушкой для топов. Со всеми вытекающими.

ДФ>Угу, но я долго шел до этого понимания. И, кстати, методики определения "чего ему нужно" до сих пор не знаю. Но зачастую (особенно в "авторитарных" конторах" к целям автоматизации это "что нужно" отношения не имеет...

Дело в том, что система автоматизации вообще слабо зависит от желаний менедмента заказчика. Ее суть в основном определяется фактическими бизнес-процессами. Это костяк системы — подсистема сбора информации и оперативного учета. А вот блок отчетности и аналитики напротив — определяется не столько потебностями сколько пожеланиями. Хорошая новость в том, что его можно хорошо развязать с блоком оперативного учета, чтобы модификации в аналитике и отчетах слабо затрагивали оперативный учет. Другими словами, оперативный учет хорошо делать классикой, а вот отчетность и аналитику — экстремальщиной, постоянно показывая.

Так что на мой взгляд оперативный учет — это всегда "нужно", и ТЗ определяется обследованием. А остальное — по желанию

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

Есть. Если ваша работа — разработка сайта, то вы должны делать ему сайт, а не решать глобальные проблемы. Если заказчик думает, что это увеличит ему оборот — то это его проблемы. Он над ними подумал, и пришел к неверному выводу, но вам платит за сайт. Зачем ему объяснять, что сайт ему не нужен? Вам деньги и работа не нужна? Не пойму. Ваше разумное поведение — сделать заказчику хороший сайт, и ненавязчиво прорекламировать услуги смежников (за откаты или каким другим разумным образом) или свои собственные по его раскрутке.