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

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

SMS>> — при интервью сотрудник всегда Вас воспринимает как чужеродного субъекта и потому разные мелкие хитрости, на которые ему приходится часто пускаться, чтобы выполнять свои обязанности (известно, что редко когда должностные инструкции составлены так, чтобы их можно было выполнять как написано), он от Вас невольно скроет. Вам это грозит тем, что получив сделанный Вами софт, он будет продолжать пользоваться для решения текущих проблем, например, Excel, а Ваш софт отставит в сторону как неудобный.

S>Хм. Интервью с непосредственным исполнителем врядли стоит начинать до того, как свое видение по существующему workflow выскажет руководитель.

Разумеется. Ведь инициатива по workflow исходит то руководства. Но следует иметь в виду, что руководитеьл всегда очень хорошо знает, что ему нужно получить и в какие сроки. Вопрос "как ?" его обычно не очень волнует. А ведь именно от ответа на этот вопрос зависит удобство софта и то, что при работе с ним не понадобится, например Excel.

S>А хорошо бы еще и с должностной инструкцией познакомиться.
Должностные инструкции составляют руководители. Они обычно очень хорошо отвечают на вопрос "что ?". Но на вопрос "как ?" ответ формируется часто из неких теоретических представлений руководства, которые реальным исполнителям приходится в жизни дополнять и развивать.

S>Тогда исполнителю хитрить будет намного сложнее.
Я не очень понимаю, зачем нужно разгадывать какие-то хитрости исполнителя, устраивать ему различные допросы, когда можно всего этого избежать всего лишь внимательным наблюдением со стороны. Мне кажется, что так намного проще и надежнее.

S>Кстати, если должностная инструкция не отражает реального положения дел, имеет смысл заставить заказчика сперва инструкции в порядок привести, а уж потом за автоматизацию браться.
К сожалению, должностные инструкции и вообще делопроизводство — вещь крайне инерционная. Должностные инструкции всегда на чем-нибудь да основаны, к ним привыкли, "приработались" сотрудники — и к их изменение руководители относятся с очень большой осторожностью — и это правильно. Поэтому чтобы "заставить заказчика инструкции в порядок привести" нужно однозначно показать ему прямую выгоду то этого. Часто бывает так, что выгода наступает только в случае внедрения автоматизированной системы, а в случае если система построена и внедрена не будет — то изменение инструкций приведет только к большему бардаку и неудобству. Поэтому изменение инструкций (если конечно, в них не вообще полная ерунда) нормальный Заказчик начинает серьезно рассматривать только тогда, когда он увидит (хотя бы на макете софта) картину
будущей работы в целом и у него появится абсолютно твердая уверенность, что софт будет сделан и внедрен в те сроки, которые ему необходимы.
Так что, в реальной жизни почти всегда за автоматизацию приходится браться ДО упорядочивания инструкций (пусть даже и согласовав с на словах Заказчиком их будущее изменение). Часто все эти орг вопросы приходится дополнительно описывать в ТЗ.

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

S>>>Например, при описании счет-фактуры, описываете ли вы все поля, какие там должны быть, их примерные размерности и типы?

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

S>Ох уже мне эта фразочка "ничего меняться не будет"... Категорически заявляю: ничего не меняется только в мертвом бизнесе. То есть вероятность, что что-то изменится уже в ходе проектирования/разработки есть всегда. Согласен, многие вещи можно предусмотреть (тот же случай с НДС). Но чтобы предусмотреть все... В такое я не верю. Вот такой я, блин, пессимист

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

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

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

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

SMS>>Я все поля прописываю исключительно по функциональному назначению.
SMS>>Примерные размерности и типы (если это необходимо для оценки трудозатрат и/или объемов базы, и/или форматов документов) появляются в самом финале постановочной работы. А лучше всего, чтобы решения на эту тему (также как и по вопросам организации базы данных) принимал лидер — программист проекта.

S>Если ТЗ не содержит деталей по атрибутам сущностей, которые предстоит реализовать, то этого ТЗ вполне может хватить для рассчета сроков/стоимости, но не хватит для начала проектирования. То есть уточннение деталей вы делегируете программистам, так?

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

S>Поясняю: я не аналитик, хотя кое-какой опыт в этой области имею, а ПМ. Меня в нашей беседе интересует, скажем так, место аналитика в технологическом процессе произвудства ПО.

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

Роль — разработка (определение и контроль реализации) функциональной модели софта. В том числе: обследование Заказчика, согласование с Заказчиком ТЗ и постановок, согласование функциональной части с программистами (по возможности реализации и по срокам), мониторинг разработки с точки зрения функциональной части, раннее выявление "непредвиденных обстоятельств" и согласование с ПМ и Заказчиком способов их устранения, первичная приемка софта от программистов, первичное внутреннее тестирование (или организация такового группой тестировщиков),
пользовательская документация (или организация разработки документации специальной группой),передача софта Заказчику совместно с программистами, организация совместно с программистами поддержки и т.д.

S>>>Вопрос2: доводилось ли вам делать аналитику для удаленных заказчиков, когда просто невозможно изучить бизнесс-процессы на месте и в полном объеме?

SMS>>Доводилось. В этом случае я стараюсь работать по аналогии с теми предприятиями, задачами, компаниями, с которыми я знаком, либо могу до них дотянуться.

S>Ох, что-то слабо я верю в ценность такого подхода. Ну про коммерческую тайну тут уже говорили, я приведу другой пример. Когда-то я работал в одной очень крупной торговой кампании с очень неплохим уровнем автоматизации бизнес-процессов. Однажды привез я из другого филиала программный комплекс по приему поставок с применением терминалов сбора данных. Систему это я в деталях изучил, беседуя с авторами, с практическими примерами, и с ходу заявил своему директору, что мы сможем внедрить её as is.

S>Общаясь в процессе установки системы с её будущими пользователями, узнал много интересного, а после того как несколько раз понаблюдал, а потом и сам поучаствовал в процессе приема поставок, с терминалом сбора данных в руке, то понял, что без существенных изменений её внедрять нельзя. Итак, два филиала одной компании при выполнении одной и той же не очень мудрёной операции, используют для её выполнения существенно отличающийся в деталях подход.

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

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

Разумеется, отличаются. Но это вовсе не значит, что таких форм бесконечно много. Я еще раз повторяю, что нужно просто грамотно искать аналогии, не только по внешним признакам. Нет, кстати, ничего плохого в том, чтобы Заказчику задать ряд предварительных вопросов, ответы на которые облегчат Вам эту работу.

Здравствуйте, Андрей Галюзин, Вы писали:


АГ>Есть изменения и ИЗМЕНЕНИЯ и как показывает практика первых много больше, чем вторых. Хотя если указать в ТЗ расположение всех элементов на формах, цвет иконок и пр, тогда, возможно, их станет меньше, но полностью от них избавиться невозможно. Очень сложно (а на мой взгляд невозможно) создать хороший продукт без мнения пользователей, а оно может появиться только, когда продукт выходит в альфы. Так что изменения будут всегда и надо с этим смириться. А вот переписывания всего проекта можно избежать, для этого есть шаблоны, проектирование и достаточное количество литературы (а также форумов .

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