Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Denis Beskov

1711
См. http://www.apkit.ru/default.asp?artID=5573

Также http://ru.wikipedia.org/wiki/Системный_аналитик

1712
Boatman, семь бед - один ответ )

1713
Как вы прям легко резюмируете.

1714
=)) Потому что он скажет, что именно у него самый сложный проект... Никакой дурак себе жизнь ухудшить не захочет...
А это уже вопрос о доверии в команде. И опять же о критериях оценки сложности проекта. Пусть аналитик выдвигает свои оценки, а его начальник согласовывает, вот и всё.

1715
почему так негативно - опыт был.
Например: бывают проекты очень сложные с очень сложным заказчиком, которые не хотят общаться, не хотят работать, ничего не хотят. И бывают проекты такие, где заказчики сами идут навстречу и всячески помогают, дружелюбно настроены.
Извините, но метрики в проектах первого и второго сорта НЕ ОДИНАКОВЫ! А отсортировать проекты по сорту - нельзя, потому что не понять ситуации пока не влезешь в шкурку аналитика...
Ну какие метрики предложите - такой результат и получите. С другой стороны - почему бы не дать возможность сортировать проекты по сложности аналитику (например, на этапе выявления рисков дял каждой итерации/фазы), если ему из своей шкуры виднее?

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

1716
Sunshine, ну почему так сразу негативно? Я бы скорее наоборот рассматривал так, что хочется измеримых оснований для повышения аналитика.

Можно взять профиль специальности от АПКИТ, но там много спорного и нетестируемого.

1717
Меня самого этот вопрос интересует, но думаю ответить на него могут только практикующие начальники отделов / ПМы.

1718
Я занимался экспертизой ТЗ как архитектор. Задача поступала от моего руководителя, ему я сдавал отчёт, он с чем-то соглашался или несоглашался и добавлял своё.

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

1719
Коммьюнити AgileRussia продолжает семинары по гибким методологиям разработки

Наш следующий семинар состоится 4 октября в Люксофте и будет посвящен инженерным практикам Agile.

Test Driven Development (TDD) – практика разработки, направленная на создание качественного самотестирующегося программного кода. Согласно практике, тесты, проверяющие работоспособность кода, создаются непосредственно перед его написанием. Таким образом, TDD позволяет обеспечить качество разрабатываемого продукта одновременно с его реализацией.

Программа семинара

1. Суть практики TDD
2. Применение практики: жизненный цикл, среда тестирования, типовые случаи
3. Внедрение практики в процесс разработки
4. Преимущества и применимость практики

Ведущий: Павел Афанасенко

Посещение бесплатное, как обычно. Для регистрации укажите здесь ФИО и выберите пункт "участвую". Там же смотрите карту проезда.

1720
Другие Методологии / Re: Post-Agile
« : 25 Сентября 2007, 11:42:36 »
2. Почему "заставить"? Свойства продукта могут целенаправленно формировать поведение человека. В первые выпуски кока-колы добавлялись листья коки, вызывающие привыкание.
Вообще-то тут шла речь про деятельность и действия, выполняемые в процессе, который длится минуты-часы. При чём здесь зависимость, кока-кола? Привыкание - это желание возврата в определённое состояние. Если в качестве этого состояния выступает эффективная профессиональная деятельность, то ничего плохого в таком привыкании не вижу. Т.е. привыкание само по себе а-этично, не хорошо и не плохо. Также как и любой инструмент.

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

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

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

1721
Другие Методологии / Re: Post-Agile
« : 25 Сентября 2007, 11:16:31 »
1. ИМХО ключевое словосочетание в приведенном Вами определении - "fully immrsed". Как Вы его понимаете?
Состояние, при котором поток сознания однороден, направлен на выполняемую деятельность, сознание полностью захвачено им, периферийное зрение используется для отслеживания тех событий и объектов, которые могут помешать выполняемой деятельности или должны быть учтены в ней. Поток сознания не перескакивает с темы на темы, не прерывается.

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

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

1722
Другие Методологии / Re: Post-Agile
« : 24 Сентября 2007, 22:42:10 »
...
Если проблемы всё больше будут фокусироваться на проблемах познания и обработки информации, то можно ожидать, что в этом новом мире эти потребности неизбежно будут преломляться сквозь призму ИТ. Для решения новых проблем потребуется новое ПО. Но чтобы понять требования к нему, избежать риска противопоставления приятного полезному, не потребуется ли как-то по иному упорядочить пирамиду Маслоу или вообще проклассифицировать потребности каким-то иным образом?
Да, действительно, верхние слои пирамиды Маслоу становятся всё более актуальными.

А вот про то, что конкретное расположение слоёв этой пирамиды как с точки зрения человеческих потребностей, так и с точки зрения аспектов качества ПО (продукта) меняется в зависимости от контекста, я как раз говорил выше Sunshine.

1723
Другие Методологии / Re: Учебный курс по MSF
« : 24 Сентября 2007, 22:38:05 »
Как я поняла там только дистанционный курс, самостоятельно изучать и сдавать.
А так - чтобы сидеть и слушать курс, задавать вопросы, есть такое? и в какую цену?
А вам зачем? Слушать можно, закинув текст в говорилку, задавать вопросы можно здесь, всё будет бесплатно.

За деньги - есть какие-то курсы:
* http://www.academy.ru/catalog/course.asp?courseId=883
* http://www.specialist.ru/programs/course.asp?idc=405

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

1724
Другие Методологии / Re: Post-Agile
« : 24 Сентября 2007, 22:33:12 »
Эта вовлеченность больше напоминает наркотическую зависимость. Посадить пользователя на иглу продукта - фактически ключевая концепция общества потребления: человек должен покупать, покупать, покупать, а вещи не должны служить долго и быстро ломаться, выходить из строя, выходить из моды и пр. Предлагать заставить человека постоянно пользоваться программным продуктом было бы проявлением некоторой инерции мышления (всё та же идея - подсадить потребителя..).
Какая "ЭТА вовлеченность"? Почему "заставить", почему общество потребления? Цитирую по Википедии:

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 на мой взгляд являются секс, танец и игра.

1725
Другие Методологии / Re: Post-Agile
« : 24 Сентября 2007, 22:18:09 »
Интересно, причем здесь пирамида Маслоу? Это достаточно известный термин в теории мотивации, с программами ничего общего.
У качества ПО, и продукта вообще, есть аспекты - например, традиционно это - функциональность, безопасность, производительность, надёжность, практичность, эстетичность и т.д. Можно увидеть параллели с иерархией потребностей по Маслоу. Интересно, что иерархия, пирамида подразумевает приоритезацию, упорядоченность, которую, с одной стороны, оспаривают (у Маслоу), с другой стороны - обычно не используют при рассмотрении аспектов качества ПО и продукта.

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

Каждый аспект качества для своего обеспечения требует определённых навыков и методов, а следовательно - специалистов в команде, дисциплины как таковой и её методической и инструментальной поддержки. Пример: Если вы создаёте продукт, критическим требованием и аспектом качества которого является производительность, то вам в команде проекта потребуются специалисты по производительности, знакомые с дисциплиной Performance Engineering, владеющие соответствующими знаниями, методиками и навыками. Более того, ЖЦ примет специфическую форму, где критическое место займут этапы и работы по выявлению нефункциональных требований, их согласованию, планированию, обеспечению и контролю.

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

Об этом всём я буду рассказывать с коллегой на семинаре в ближайшую субботу.

В приведённой мной ссылке речь идёт о том, что выход на осознанный уровень очередного аспекта качества продукта может сопровождаться изменением и появлением новой методики разработки продукта. Ещё 30 лет назад такой аспект, как практичность, практически не осознавался, а когда был осознан, появился UCD. FLOW по-любому присутствует в успешных играх и соответственно есть методики его обеспечения, есть понятие "гейм-дизайн", как бизнес-моделирование в игровом мире. Но осознано ли FLOW как аспект? Сомневаюсь.

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