406

Консалтинг и Внедрение / Бесплатная, многофункциональная, сетевая CRM система - A-Number CRM

« : 10 Декабря 2009, 17:09:27 »

Да, мы сами используем A-Number CRM , для работы с пользователями !!

Отлично. Теперь ответьте на пару вопросов:
1) Сколько денег потерял бы бизнес за прошлый месяц, если бы ее у вас не было, а был бы, скажем MS эксченж?
2) Как вы посчитали эту цифру?

Ответ на второй вопрос и будет "Ключевыми возможностями системы ценными для бизнеса".

Цитата из жизни внедренца:

Он приехал в Georgia-Pacific (крупнейший американский, да, возможно, и мировой производитель бумаги) с презентацией и демо-системой NetApp, и провел демонстрацию, которую многократно успешно проводил в предыдущие годы. Он рассказал про терабайты в секунду, и о том, как много данных может хранить его устройство, и о том, какие протоколы поддерживаются, и прочие такие штуки технического плана, и о том, насколько дешевле их система по сравнению с конкурентами.

После презентации глава IT-департамента спросил с характерным джорджийским акцентом: “Сынок, мы рубим деревья, и делаем из них туалетную бумагу. Скажи мне, как твоя штука может помочь нам рубить деревья и делать из них туалетную бумагу?”
Ну и конечно не стоит говорить, что тот контракт они не получили.

Вы сейчас рассказываете про терабайты и секунды. Так вот. Я ваш контракт не подпишу.

Кто еще ППКС?

407

Консалтинг и Внедрение / Бесплатная, многофункциональная, сетевая CRM система - A-Number CRM

« : 09 Декабря 2009, 18:38:39 »

Мда, сразу видно что Система сделана программистами для программистов
Из всех 16 ключевых возможностей системы можно выделить только 4 ценных для Бизнеса, да и то с натяжкой:

Александр, НИ ОДНА из этих ключевых особенностей не является ценной для бизнеса. Для программиста или, в общем случае, для типичного IT-шника являются. Для бизнеса нет.

Целью автоматизации является автоматизация сама по себе. Мы займемся автоматизацией, а бизнес вполне обойдется без нее.

408

Системный Анализ и Требования / Re: Нефункциональные требования...

« : 09 Декабря 2009, 18:34:31 »

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

Отделение прочих требований от функциональных служит в частности способом уменьшения объема.

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

409

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 17 Ноября 2009, 14:51:17 »

2Salar
Вы не могли бы изьясняться более конкретно - а то одни отсылы к толстым фолиантам, а конкретики не видно

Простите, а как вы собираетесь стать профессионалом, не читая толстых фолиантов? Конкретно Деминга и Голдрата читать нужно.

2 "Посмотрите у Деминга, кто в процентном отношении виноват в браке." Тема так и не раскрыта.

На это Григорий ответил. Мне остается только добавить, что Деминг неоднократно пересматривал свою оценку, все время увеличивая долю ответственности руководства за брак.
Игра "Красные бусы" - это модель иллюстрирующая это.

1 "Бытует мнение, что создание, внедрение и использование различных шкал оценки персонала относится к "смертельным грехам менеджмента"." Тема так и не раскрыта

СМЕРТЕЛЬНЫЕ БОЛЕЗНИ
...

3. СИСТЕМЫ АТТЕСТАЦИИ И РАНЖИРОВАНИЯ ПЕРСОНАЛА

Системы аттестации и ранжирования персонала, оценка личного вклада, ранжирование по значимости, оценка качества функционирования, ежегодная аттестация, премиальные системы, плата по труду — оказывают разрушительный эффект.

"Управление по Целям" — зло того же порядка; "управление на основе страха" было бы более подходящим его названием. Результаты подобной практики следующие:

Развивается "близорукое" мышление, взращивается соперничество, интриганство и страхи, уничтожается перспективное планирование, разрушается дух команды; Одни люди испытывают чувство горечи, другие — отчаяние, некоторые работники переживают депрессию, из-за которой они неработоспособны в течение недель после получения оценки своей деятельности, причем они не в состоянии понять, в чем их вина. Эти методы несправедливы, т. к. они приписывают людям в группах такие различия, которые могут быть полностью обусловлены системой, в которой работает группа. (см. главу 30).

Может все таки найти книгу и прочитать?

410

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 16 Ноября 2009, 21:22:57 »

Да никак они у нас не используются!
Сам не знаю как их применять нужно по правильному - не дорос еще.
Я их делал исключительно для себя.

Управление рисками по модели риск-оптимувов не хотите попробовать?
Блин. И сослаться то не на кого, кроме своей статьи  и своего же семинара...

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

Круто. Посмотрите у Деминга, кто в процентном отношении виноват в браке. Результат вас неприятно удивит.

Огласите плз в какой бизнес-области работаете, делаете продукт или заказная разработка, методология разработки - используется ли agile-подходы, outsourcing или внутренняя разработка? Просто интересно в каком случае такой подход работает!!!!!!

Если применять подход дословно то это презумпция виновности аналитика))))

А какая разница в какой области?

411

Системный Анализ и Требования / Re: Управление требованиями. Атрибуты

« : 16 Ноября 2009, 14:24:32 »

Это потрясающе! вы открыли мне глаза на этот огромный, разнообразный мир!  

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

412

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 16 Ноября 2009, 13:03:27 »

Бытует мнение, что создание, внедрение и использование различных шкал оценки персонала относится к "смертельным грехам менеджмента". Не верите мне, почитайте метров. Деминга почитайте (http://findbook.ru/redir/book?url=http%3A%2F%2Fwww.bolero.ru%2Fcgi-bin%2Fdsc.cgi%3F66641528%26partner%3Dfindbook%26new%3D1).
Или Генри Нива : http://findbook.ru/redir/book?url=http%3A%2F%2Fmy-shop.ru%2Fshop%2Fbooks%2F132831.html%3Fpartner%3D00519 (у него язык попроще)

413

Системный Анализ и Требования / Re: Управление требованиями. Атрибуты

« : 16 Ноября 2009, 12:55:37 »

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

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

414

Системный Анализ и Требования / Re: Управление требованиями. Атрибуты

« : 16 Ноября 2009, 12:50:44 »

* Чем можно заменить приоритет.
Например, Доброй Феей. Которая прилетела и для каждой фичи указала два параметра: общие трудозатраты и доллары, которые мы получим при реализации. Метод теоретический, на практике возможность его применения о-о-очень сомнительна.
Но есть другие методы. И их не один. Один из них указал Виталий. Есть еще.

* Тип и уровень.
Под типом в данном случае имелось в виду, какую характеристику качества по ГОСТ покрывает требование.

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

Если брать CMMI, то:
* часть атрибутов соответствует области усовершенствования "Управление требованиями" (2-й уровень)
* другая - "Разработка требований" (3-й уровень)
* третья относится к управлению проектами
И если для каждой конкретной команды набор атрибутов будет включать 3-15 атрибутов, то всего различных атрибутов вполне можно набрать с полсотни. Важен метод адаптации под конкретную задачу.

PS. Большая часть всего этого есть в записи моего вебинара http://software-testing.ru/events/836-tuning-bugtracker.

415

Системный Анализ и Требования / Re: Управление требованиями. Атрибуты

« : 14 Ноября 2009, 19:13:34 »

Для начала разделите на категории:
* описательные
* управляющие

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

Описательные:
* Тип
* Заголовок
* описание (сильно различаются в зависимости от типа)
* бинарный файл (рисунок/ диаграмма/...)
* Уровень. Можно вводить, но честно скажем, что лучше разносить по разным документам и называть по разному. В концепции будут проблемы. В более развернутом документе можно описать потребности. А в SRS (спецификация требований) уже писать требования на уровне юзкейсов или требований с метриками (для нефункциональных).

416

Конференции Семинары и Тренинги / Два новых вебинара.

« : 12 Октября 2009, 18:22:16 »

Одна тема была раскрыта на Web Architect WorkShop Day, вторая анонсирована.

Официальные анонсы:
Тюнинг багтрекера http://software-testing.ru/trainings/online/details/66--
Использование глоссария для обеспечения и контроля качества ПО http://software-testing.ru/trainings/online/details/67--------

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

417

Бизнес-анализ и Целеполагание / Re: Что такое цель?

« : 31 Августа 2009, 15:31:44 »

Немного более расширено: http://blog.shumoos.com/archives/69

Не имею никакого отношения к кафедре.

418

Бизнес-анализ и Целеполагание / Re: Что такое цель?

« : 24 Августа 2009, 15:41:43 »

Я использую понятие  цели в определении Анисимова.

Цель есть нормированное представление о достижимом результате.

Использую уже 17 лет. Пару лет назад познакомился со SMART определением. Тоже ничего, но для меня определение Анисимова лучше.

На эту тему неплохо почитать "Основы методологии" (http://mmpk2.appach.ru/?q=node/104, двенадцатая в списке). Сразу предупрежу, книга сложна.

419

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

« : 14 Августа 2009, 12:53:17 »

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

Писатели часто пишут книги по заказу. И аким то образом им удается это делать?

420

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

« : 14 Августа 2009, 12:51:06 »

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

Неверно. Он не удалил их, а сделал их меньше. Кроме того он выбрал еще с десяток пятен и увеличил их. Таким образом на картине получилось 20-30 примерно одинаково больших пятен, которые не бросались в глаза.

В принципе, так тоже можно делать. Раскрашен сайт плох, но одинаково плохо.