91

Обучение / Re: Дипломный проект как IT проект

« : 01 Ноября 2007, 19:25:23 »

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

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

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

92

Бизнес-анализ и Целеполагание / Re: Регламентация процесса "Бухгалтерский учет"

« : 01 Ноября 2007, 19:04:27 »

Добрый день!

Передо мной стала проблема регламентации процесса Бухгалтерского учета на моем новом предпрятии. Существует план по моделированию и регламентации процессов в рамках СМК Компании, составленный "до меня", и одним из выделенных к регламентации Бухучет и является

Целью описания "Бухгалтерского учета" является установление прозрачности функционирования процесса и работы бухгалтерии для других подразделений, с упором на описание тех моментов, в которых происходит передача информации между подразделениями (компания - энергопоставляющая со штатом в 5500 человек, разбита на 5 структурных подразделений, которые разбросаны по 15 офисным зданиям по городу). Детальное описание не предполагается - не хватит физических сил.

При первом общении с замглавбуха, выделенного в помощь для моделирования процесса, услышал от него, что "и описывать вообще то и нечего - они занимаются только регистрацией и учетом операций на счетах бухучета". То есть, понимай - "мы тупо вбиваем в компьютер, то что нам приносят и выдаём отчеты потом".

Что меня интересует в наибольшей степени сейчас - это выделение подпроцессов в рамках процесса "Бухучет". По каким критериям? Можно ли пойти таким путем:? Собрать данные о входах и выходах, сгруппировать по сходным потребителям (внутренним и внешним) и затем выделить подпроцессы.

И существует вообще надобность описывать данный процесс?

Спасибо за оставленные комментарии...

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

93

Обучение / Re: Дипломный проект как IT проект

« : 31 Октября 2007, 23:02:02 »

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

Это очень сильное утверждение. В истории любой профессиональной деятельности есть примеры большого количество технических решений, которые были не востребованы, хотя были сделаны очень талантливо и содержали интересные идеи (которые потом растащили на части другие). Даже в истории отечественной ИТ отрасли. Любое предложенное решение должно быть кому-то полезно. Критерии пользы дают требования к решению. Чем больше эти требования от жизни, а не от профессинально-технологической специфики решения - тем меньше они стесняют творческую мысль создателя решения (в ГОСТе 34 на ТЗ про это прямо написали - не ограничивать требованиями возможные решения). Хорошо бы если бы можно было оиентировать специалистов на такие подходы уже с института.

Что содержится в ТЗ - более или менее понятно. Чаще всего это текст требований иногда какие-то контекстные модели. Я видел не так много ТЗ по ГОСТ, но в них не видел структурных схем, либо они были очень иллюстративные.

Далее идет собственно проект технический и рабочий. Разница между ними довольно тонкая, и часто их объединяют в технорабочий проект.

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

В ГОСТ 34 пространство для описания модели по уровням (видам моделей) очень ограничено. ГОСТ в значительной мере исходит из функциональной модели. Функция описывается входом и выходом, причем на уровне ТЗ функциональные требования формулируются к выходам функций, а требования к множеству входов фактически описывается в следующем разделе "информационное обеспечение". Уже на уровне ТРП пишется постановка задачи (есть там такой документ), там также упор на описание входов и выходов. Тут уже вход указывается для каждой задачи (функции - по ГОСТ задача это функция или часть функции). Поэтому ГОСТ лучше всего дружит с IDEF0, IDEF3 или DFD.

Кажется очевидным что модель реализации может быть зафиксирована в технорабочем проекте (или же в рабочем?), а логическая модель в техническом? Тогда где место аналитической модели.

Может быть можно рассматривать аналитическую модель как основу для описания требований? Тогда можно её поместить в ТЗ (ГОСТ 34) в раздел Характеристика объекта автоматизации.

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

Вопрос: как следует разместить модели? и где? следует ли вообще рассматривать и публиковать аналитические модели и логические - может достаточно моделей реализации, или наоборот только логической?

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

94

Системный Анализ и Требования / Re: Сбор требования или информации для неизвестного пока решения

« : 16 Октября 2007, 12:56:28 »

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

Вряд ли формулировка проблемы в таком общем виде может дать конструктивную рамку для проектирования системы: если система, решающая такую общую проблему, могла бы быть создана, она решила бы проблемы в любой области деятельности. Поэтому она должна была бы обладать универсальностью карманного калькулятора при такой же ограниченности функционала.
Специфика контроля ВСЕГДА связана с предметной спецификой деятельности и УНИВЕРСАЛЬНЫХ решений контроля для любых видов деятельности не существует. Можно обсуждать требуемый УРОВЕНЬ ОБЩНОСТИ описания этой специфики, но без специфики предметной области (фактически - референтной модели) обойтись невозможно.

Примеры вопросов:
Какие именно поручения? Не могли бы Вы привести перечень поручений, которые необходимо контролировать?
В этом месте при попытке уточнить содержание выполняемых поручений Вы выходите на обсуждение деятельности Заказчика в широком смысле:
* зачем вообще нужно выполнять эти поручение - переход к обсуждению основных целей и процессов организации
* есть ли условия при которых это поручение должно быть выполнено
* насколько точно можно вообще установить (проверить) факт выполнения поручения, в чем заключается (измеряется) результат
* улучшит ли автоматизация контроль? Нельзя ли привести примеры конкретных ситуаций, когда исполнение поручений не было проконтролировано? Кем? Почему?
 
1. Действительно ли этот человек не выполнил контрольные действия, потому что в его распоряжении не было удобных (автоматизированных) средств? Отсюда вопрос - почему Заказчик вообще уверен, что автоматизация контроля решит задачу контроля как таковую? Например, если суть контрольных действий будет сводиться к вводу исполнителем и/или проверяющим необходимой информации, то не будут ли эти действия для пользователей системы обременительными? Особенно, если для пользователей ввод контрольной информации никак не облегчает выполнение их работы, а является дополнительной нагрузкой. В этой ситуации саботаж использования контролирующей системы весьма вероятен... Это так же иллюстрирует проблему возможного несоответствия заявленных проблем/целей и предполагаемых решений. Уточняя, конкретизируя проблему и уточняя, конкретизируя решения Вы получаете более отчетливую ("сфокусированную") картину

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

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

95

Системный Анализ и Требования / Re: Сбор требования или информации для неизвестного пока решения

« : 10 Октября 2007, 12:04:32 »

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

Предложение:
Если нет достаточно отчетливой (для проектирования ИС) цели и даже проблем на, так сказать, бизнес-уровне (предметной области Заказчика) то требуется выполнить работу бизнес-аналитика. На первом этапе - попытаться вывести Заказчика на формулирование его проблем (в его предметной области) в достаточно отчетливой (для проектрования ИС) форме.
Идеально, если он сам выговорит приемлемые формулировки, а не кивнет Вам в знак согласия. Это все бывает достаточно мучительно (для обоих сторон:)), но если четкое понимание болезней (проблем или целей) отсутствует то, чтобы лечить пациента, эти процедуры неизбежны. Менее болезненная, но возможно, более затратная  альтернатива пригласить стороннего опытного доктора-эксперта (не в вопросах собственно лечения, а менеджмента процессов).

Чтобы интервью привело к желаемым для Вас результатам, необходимым, но не достаточным условием является наличие у вас рамочных представлений о предметной области. Необходимо направлять интервью так, чтобы не выходить за эти рамки. Эти рамки на обсуждение могут быть наложены в виде схем (фактически, простейших референтных моделей, которые доступны уже Вам, даже если Вы врачом не являетесь). Предлагаю исходить из того, что в данной ситуации, Вы сами можете формулировать суждения о предметной области Заказчика в общем виде, но с признаваемой обеими стронами достоверностью.
Интервью - естественно, на основе заготовленных вопросов (анкеты). Но анкета обычно задает очень сильные рамки и неявно основана на некоторой референтной модели предметной области. Если модель в основе - слишком общая, а Заказчик инициативен и говорлив - возможна "потеря управления" (Вами) в ходе интервью. Если слишком жесткая (конкретная), то в неё "не ляжет" обсуждаемая проблематика и она неявно в ходе обсуждения будет отложена в сторону. Удобно представить предлагаемые референтые модели в виде схем. Они легче адаптируются (перерисовываются) в ходе разговора. Поскольку обсуждение ведется всё-таки словами, они, конечно, не заменяют, а дополняют анкету. Не уверен, что все необходимые для обсуждения бизнес-области схемы по теме "цели-проблемы" удастся упаковать сразу в стандартные нотации

Предлагаемая цель обследования, которое Вам необходимо провести: "Выявление целей и проблем Заказчика".
1. Предлагаете Заказчику сформулировать проблемы
2. Сформулированные проблемы подразумевают, что они возникают в ходе деятельности Заказчика. Предложите Заказчику уточнить, при достижении каких целей у него эти проблемы возникли. Попробуйте выяснить историю их возникновения.
3. Дальше самое интересное - заявленные цели могут с Вашей точки зрения не соответствовать заявленным проблемам. Обсуждение этой неувязки может заставить пересмотреть список проблем и целей и связи между ними. Важно держать фокус на деятельности именно Заказчика, при попытке обсуждать профессиональные проблемы в широком смысле фиксировать их, но аккуратно возвращать собеседника к тому, как они связаны с конкретной деятельностью (процессами) его организации.
4. В принципе, переключение между целями и проблемами может происходить бесконечно долго, важно, чтобы в ходе обсуждения происходила "фокусировка", конкретизация, сужение, уточнение рамок до достижения "разрешающей способности" (или исчерпания терпения сторон.

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

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

96

Другие Методологии / Re: Post-Agile

« : 08 Октября 2007, 18:55:15 »

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

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

97

Системный Анализ и Требования / Re: Проверка качества требований в проекте

« : 29 Сентября 2007, 13:38:46 »

Ну, в общем, да. Я полагаю, что трудно, но принципиально это возможно.

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

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

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

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

Мое утверждение, с которым Вы не согласились, не случайно начиналось словами "если Вы формулируете требования, которые должны быть качественными с точки зрения Заказчика". Можно попытаться сконструировать "групповой критерий" правильности: "Правильно то, с чем согласны и Заказчик и Исполнитель". Но надо быть готовым, что при таком критерии "правильное ТЗ" достижимо не всегда. Не достигли консенсуса - проект прекращается, Заказчик и Исполнитель разбегаются в разные стороны.
Кроме того, Вы ранее писали - "Все-таки правильнее, на мой взгляд, сначала самим убедиться, что требования, которые мы сделали, - качественные". Если исходить из "группового критерия", не могли бы Вы уточнить - проблема в том, что
1. Вы затрудняетесь сформулировать (в части "...убедиться") , что является правильным с Вашей (Исполнителя) точки зрения для данного проекта?
2. Или в том, что Вы выдвигаете требования (строго соответствия законодательству), с которыми Заказчик заведомо не согласится?

А если требования, которые выдвигает "конкретный заказчик 1" противоречат требованиям, которые выдвигает "конкретный заказчик 2", то что? Соответствие чьим словам будет тогда критерием качества?..

Это большая беда. У проекта должен быть один Заказчик. Процесс "приведения к общему знаменателю" подчиненных Заказчика происходит в любом проекте и не всегда с привлечением Большого Начальника Заказчика. Но если Вы хотите иметь гарантированный результат в проекте, в который Вы вкладываете деньги, у Заказчика должен быть один Большой Начальник. Он нужен, по крайней мере, для принятия решений, когда возможности компромисса между его подчиненными исчерпаны.  Принцип единоначалия, сформулированный Файолем еще в 19 веке, никому отменить пока не удалось.

98

Системный Анализ и Требования / Re: Проверка качества требований в проекте

« : 28 Сентября 2007, 11:18:27 »

Как говорил один наш заказчик, "ну и что, что я подписал ТЗ?! моя подпись на документе не означает, что мы теперь не можем ничего изменить".

Это я к тому, что вы можете, конечно, считать, что Заказчик "целиком несет ответственность за то, под чем он подписался".

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

Но я ставил вопрос немного по-другому, как проверить качество требований? Если мы написали плохие требования, и каким-то образом добыли подпись заказчика под этими требованиями, то они от этого не станут качественными.

Тут вопрос - с чьей точки зрения требования "плохие". Для Заказчика они могут быть очень даже хорошие а для Исполнителя просто нереалистичные. И наоборот. И по жизни потом можно услышать: "Мы сделали Заказчику такую суперсистему, такие передовые решения применили, а они (Заказчики) такие тупые, ну никак не научатся на ней правильно работать. Требования элементарные, в ТЗ записанные, не соблюдают...." . А Заказчик жалуется: "Тут мне ребята систему сделали. Умные ребята, но в нашем деле ничего не понимают. Наш опыт и знания ни во что не ставят. Простые вещи сделали сложно, требования наши просто, похоже, не понимают...  Вот поработали бы с мое лет 20 в нашей отрасли, а потому уже учили всех, что требуется".

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

Если Вы формулируете требования, которые должны быть качественными с точки зрения Заказчика, то то, что конкретный Заказчик считает правильным, то и будет качественными требованиями. Без итерационного уточнения позиции Заказчика по этому вопросу как правило, обойтись не удается. Вы полагаете, что можно сделать хорошую систему в рамках конкретного проекта для конкретного Заказчика вопреки его косноязычию и изменчивости его позиции? Или ставится цель выполняя конкретный проект фактически реализовать систему "не для этого Заказчика", а для тех, кто сможет её по настоящему оценить (для рынка)?

99

Системный Анализ и Требования / Re: Проверка качества требований в проекте

« : 27 Сентября 2007, 13:40:16 »

Насчет ответственности - да, в нашей практике именно так.

Насчет субъективизма, поясню вопрос. Человек, который согласует документ требований, может сказать, что "как же вы не учли то-то и то-то, это очень важно!", и настоит, чтобы эти требования, которые он считает важными, были добавлены. Однако, где гарантия, что это действительно важные требования для всех пользователей, а не только его личные пристрастия? Тут, по опыту, не принципиально, будет ли данный "эксперт" со стороны заказчика или со стороны исполнителя. Такие сюрпризы могут быть и в том, и в другом случае. Есть ли у вас silver bullet для таких случаев?

Ситуацию, при которой Исполнитель вынужден отгадывать желания пользователя и нести ответственность за правильность такого отгадывания нельзя признать нормальной. Если система нужна Заказчику то он по крайней мере должен нести ответственность за то, что он постарался быть правильно понятым Исполнителем.

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

С точки зрения Исполнителя важно, чтобы в ТЗ не появлялись требования, которые:
1. взаимно противоречат друг другу или не могут быть реализованы по чисто техническим (физическим) причинам и в  требуемые сроки, с прибылью.
2. были настолько расплывчаты, что под них на приемочных испытаниях может быть подведено все, что угодно. Требования (функции) должны быть "проверябельны". Например, важно, чтобы результат работы функции можно было продемонстрарировать средствами штатного интерфейса, без "выковыривания" результата хитрыми запросами средствами нештатного ПО, установленного на компьютере на время испытаний.

Если Заказчик "навертел" в ТЗ "бантиков", которые пользователям не нужны, то пытаться помешать этому важно, если это создает перечисленные ваше риски для Вас:
1. "бантики" делают для Вас проект убыточным (при уже согласованной сумме договора)
2. на стороне Заказчика есть пользователи прямо незаинтересованные в реализации некоторых функций ("бантиков"). В результате внутренних раздоров у Заказчика Вам устраивают проблемы при испытаниях по приведенному выше п.2
3....

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

100

Системный Анализ и Требования / Re: Проверка качества требований в проекте

« : 27 Сентября 2007, 11:33:45 »

....Вот приходит некий аналитик и говорит: "Я провел обследование заказчика и написал ТЗ". Как вы на практике решаете вопрос, как понять, это хорошее ТЗ или не очень?
....
....ответственность-то все равно на аналитике)?

Пожалуйста, не могли бы Вы уточнить:
Насколько я понял - Аналитик (который писал ТЗ) - специалист Исполнителя.
Согласующий (с субъективизмом которого нужно разобраться) - специалист Заказчика или Исполнителя?

В Вашей практике ответственность за содержание (написание) технического задания в большей степени лежит на Исполнителе, а не на Заказчике системы?

101

Другие Методологии / Re: Post-Agile

« : 25 Сентября 2007, 12:26:19 »

Какая-то кривая трихотомия - "действия либо осознаваемы, либо бездумны, либо внушаемы". Как будто вам неведомо, что большая часть профессионально или, точнее, эффективно выполняемых действий находится на границе между бессознательными действиями и сознательными. Может ли профессиональный боксёр в процессе атаки думать "Какой бы шарфик подарить Маше", "А хорошо ли я выгляжу в свете софитов, не сбилась ли причёска", "Давно я не брал корень от логарифма", "Встречу Костяна - убью"?

Если вы будете рефлексировать все свои действия, то застынете на месте, как та сороконожка. Поэтому во FLOW-деятельности часть действий высокоавтоматизирована бессознательным, а часть - высококонтролируема единым потоком сознания, в идеале они образуют сплав. Также см. Mind Like Water.

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

102

Другие Методологии / Re: Post-Agile

« : 25 Сентября 2007, 10:27:50 »

Какая "ЭТА вовлеченность"? Почему "заставить", почему общество потребления? Цитирую по Википедии:

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing, characterized by a feeling of energized focus, full involvement, and success in the process of the activity.

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

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

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

2. Почему "заставить"? Свойства продукта могут целенаправленно формировать поведение человека. В первые выпуски кока-колы добавлялись листья коки, вызывающие привыкание. Требование проработки аспектов вовлеченности, о которых Вы писали применительно к разработке ПО, подразумевает необходимость избежания создания продуктов, вызывающих избыточную "вовлеченноть" (привыкание?)?

103

Другие Методологии / Re: Post-Agile

« : 24 Сентября 2007, 14:06:09 »

Эта вовлеченность больше напоминает наркотическую зависимость. Посадить пользователя на иглу продукта - фактически ключевая концепция общества потребления: человек должен покупать, покупать, покупать, а вещи не должны служить долго и быстро ломаться, выходить из строя, выходить из моды и пр. Предлагать заставить человека постоянно пользоваться программным продуктом было бы проявлением некоторой инерции мышления (всё та же идея - подсадить потребителя..).
Возможно стоило бы поставить проблему шире?
Гипотеза:
1. Современные развитые общества научились удовлетворять материальные (физиологические) потребности, сформировавшиеся тысячелетиями и которые тысячелетиями до нас не удавалось удовлетворить до такой степени, чтобы не считать вопросы удовлетворения этих потребностей центральными.
2. Автоматизация деятельности, в том числе с использованием ПО, в значительной степени ориентировалась на облегчение процесса  производства или расширения его возможностей.

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

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

Если проблемы всё больше будут фокусироваться на проблемах познания и обработки информации, то можно ожидать, что в этом новом мире эти потребности неизбежно будут преломляться сквозь призму ИТ. Для решения новых проблем потребуется новое ПО. Но чтобы понять требования к нему, избежать риска противопоставления приятного полезному, не потребуется ли как-то по иному упорядочить пирамиду Маслоу или вообще проклассифицировать потребности каким-то иным образом?

104

Бизнес-анализ и Целеполагание / Re: Модель потребностей в малых проектах по созданию публичных веб-систем

« : 20 Сентября 2007, 00:08:48 »

Опять же, несмотря на все эти мантры "вы не можете знать, чего хочет пользователь, пользователь сам не знает, чего он хочет", тем не менее, мы всё равно при системном проектировании по крайней мере в технической части оперируем моделями и мысленными экспериментами - что есть UML-модель будущей системы, как не экспериментальная умозрительная конструкция, которую можно протестировать другими людьми?

Возможно, интересно было бы попытаться:
1. сформулировать (проклассифицировать, протипизировать) хотя бы возможные рамки пользовательских практик ("в жизни", не в виртуале), в которых полезно использование веб-систем. Какие классификационные признаки могут быть значимы для Вашей системы (чтобы не пытаться разрабатывать совсем глобальную классификацию)? Как позиционируется предлагаемая Вами идея в рамках такой классификации?
2. Каждой рамке (типу практик) соотнести типичного пользователя (профиль).
3. Для Вашей системы попытаться определить (профиль) пользователя "конструированием" пользователя Вашей системы из групп типичных пользователей других систем (по степени сходства и различия с Вашей системой).
3. Определить рамки "эксперимента на людях...".

105

Бизнес-анализ и Целеполагание / Re: Модель потребностей в малых проектах по созданию публичных веб-систем

« : 19 Сентября 2007, 15:37:41 »

Но как быть в ситуации с созданием массовых продуктов, когда нет чёткого понимания, на какую аудиторию ориентироваться и какие именно потребности закрывать? Причём делать обширные маркетинговые исследования не позволяют ресурсы (деньги и время).

Под "массовым продуктом" понимается ПО, рассчитанное на большой тираж, но с каждой инсталляцией работает небольшое количество пользователей с узкоспециализированными  потребностями или "публичные" системы (небольшое количество инсталляций, но большое количество - "масса" пользователей)?

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

Наиболее актуальна эта задача для стартапов, ну и для любых персональных проектов.

Т.е. вопрос вот в чём - есть ли какие-то нотации помимо MindMap, Excel для модели потребностей, методы её формирования и трансформации в пользовательские требования?

Нотация - это только знаки, которыми описывается модель. Задача соотнесения  потребностей и идеи проекта часто упирается в модель автоматизируемой деятельности (пользователя системы). Т.е. проблема обычно в содержательном развертывнии идеи в модель, особенно для систем, которые не подпадают под традиционные модели типа "промышленное производство" или даже "предприятие". У Вас не так?