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

×


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

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


Сообщения - SALar

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
391
Другое:
Тетрадь (толстая, в дермантиновом переплете), стикеры, доска,... - даже более удобно, чем Visio.

392
Работа / Re: Программист->Аналитик
« : 03 Сентября 2010, 11:14:24 »
А как это программист и вдруг совсем не аналитик?! Вот если про кодера говорить, то да, кодер как аналитик работать не может. А когда сможет, то перестанет быть кодером и станет программистом.
Поэтому, если человек действительно программист, а не кодер, то он естественно может работать аналитиком. А если он разработчик, то может работать хорошим аналитиком.

393
IMHO

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

Цитировать
1.В команде должен быть порядок, взаимодоверие и прозрачная картина. Когда в команде бардак – заказчик это сразу же почувствует, даже если он с вами практически не общается
2.Выполняйте обещания. Не давайте нереальных обещаний. Лучше объясните, почему вы можете сделать что-то только к такому сроку, чем пообещаете и не сделаете
3.Про проблему стоит уведомлять, как только она возникла, а не дожидаться, что она сама собой рассосется. Если проблема возникла, нужно не только о ней сообщить, но и предложить пути решения проблемы, а не взваливать все на плечи заказчика.
4.Уважайте заказчика и будьте к нему терпеливы. Если вы мило общались с заказчиком по телефону, а потом положили трубку и вслух рассказали, что он такой-сякой нехороший, не удивляйтесь, почему члены вашей команды никогда не станут испытывать к нему уважения, а уж про доверие и говорить не приходится.
5.Отстаивайте интересы своей команды и коллег в глазах заказчика. Если что-то пошло не так, то стоит признать, что виновата вся команда, а не отдельные Петя Иванов и Вася Сидоров.
10.Будьте скептическими к себе, ищите пути постоянного улучшения, как своей работы, так и взаимоотношений с заказчиком.
11.Не стесняйтесь иногда попросить у заказчика совет.
12.Не останавливайтесь на достигнутом. Расширяйте горизонты.
13.Проявляйте инициативу.


Будем считать, что остальные советы более-менее специфические. Рассмотрим их подробнее.
Цитировать
6.Если у вас (по вашему мнению) ужасный заказчик - воспитывайте его. Как? Тут уже вам виднее, то ли своим примером, то ли примером соседних команд, то ли книгами, то ли тренингами,  ищите свое. Как говорится, кто ищет, тот всегда найдет.
Нас, на уроках педагоги учили, что людей можно воспитать только до 5 лет. Далее - только перевоспитание, но это безумно сложно, долго и дорого. У вас просто не будет 10-30 необходимых на перевоспитание лет. Проще зомбировать, льстить, запугивать и/или обманывать.
Как пели Алиса и базилио на три категории людей: хвастунов, дураков, жадин, есть свои методы воздействия, или как говорит ida, манипуляции. Кстати, говорить правду - это тоже метод манипуляции и очень, очень мощный. И если не хотите потерять уважение к самому себе, то лучше использовать именно его.

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

Цитировать
8.Нацельтесь на длительные отношения с заказчиком. Узнайте его долгосрочные планы и цели.
Здесь до определенной степени согласен. Если не представлять себе цели заказчика и интересы сторонних лиц, то проект сделать вообще очень сложно. Скорее, его можно сделать случайно. Не зря же в рекомендациях от MS один из первых шагов обследования - построение матрицы участники/интересы (отношение к проекту). Небольшой минус - долгосрочные цели, как правило, коммерческая тайна. Со всеми вытекающими.

Цитировать
9.Сделайте для него чуть-чуть больше, чем он ожидал.
Предварительно заложив бОльший бюджет. И если от бюджета что-то осталось - сделайте что-то "просто так". Ну или сначала чего-то сделайте, а потом заложите в бюджет оплату этой работы  умноженную на коэффициет, в зависимости от риска. Отличный метод. Один из известных мне четырех отлично работающих методов планирования бюджета в условиях высокой неопределенности. Т.е. так тоже можно делать. А можно по другому.

Цитировать
14.Ну и последнее – клиент всегда прав. Если клиент не прав – то все равно «клиент всегда прав», при этом здравый смысл никто не отменял.
А вот здесь все таки сильно нет. Заказчик и исполнитель - это партнеры. Если нет, то можно подумать о расставании. Причем инициация процедуры расставания, в первую очередь должна, идти со стороны заказчика.

"Нельзя опереться на того, кто всегда соглашается".
Есть даже книга с хорошим, звучным названием: "Сначала скажите нет."

394
Мои наблюдения показывают, что смешанный формат - это плохой формат. Поэтому для себя я решил:
1) Если я работаю на живую аудиторию, то работаю только на нее. Я не буду ждать установления канала передачи и начну говорить, даже если в инете меня не слышат. Я не буду останавливаться, если передача прервалась. Если мне удобно работать с живой аудиторией на флипчарте, я буду работать на флипчарте. Что при этом увидят в трансляции - не важно. Почему так? Потому что нужно уважать людей, которые пришли вживую. У них преимущество. Я заранее предупреждаю, что качество сервиса, для слушающих по трансляции - хуже.

2) Верно и обратное. Если, это онлайн, то это чистый онлайн. Я готов идти на ухудшение сервиса, ради тех, кто пришел вживую.

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

Я собственно к тому, что веб - это очень неплохо, надо будет попробовать, но это будет именно веб. И еще. Те инструменты, которые я использовал, не позволяли нормально вести дискурсию нескольких человек одновременно. 2-4 человека и микрофоны начинают фонить, фразы сливаются.

395
BTS — это что?
система отслеживания ошибок (багтрекинга)

Файл получилось прикрепить.

396
Это начальный вариант документа. На его создание было потрачено порядка 2 часов + время на перевод в ворд. Для такого короткого времени это очень неплохо.

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


Не нашел, как прикрепить файл. поэтому: http://it4business.ru/forum/topic17401.html

397
Проблема есть у меня - не успеваю )

Задачи следующие (если говорить о ТЗ):
* Проверить на непротиворечивость требований
* Проверить на полноту (все ли требования Бизнеса учтены)
* Проверить на понятность и однозначность формулировок
Может это не у тебя проблема? Может проблема проявится, если ты перестанешь вычитывать ТЗ? И тогда формулировка проблемы будет совсем другая. И решений у нее будет несколько.

Я могу предложить тебе очень эффективный метод проверки неполноты ТЗ. Берешь ТЗ листов на 500 и через 10 минут возвращаешь с пометкой "неполнота". Но вот конкретно в твоей организации это может несработать.

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

400
Примеры / Re: Выделение ВИ и ДЛ
« : 20 Января 2010, 15:19:18 »
Ну, к примеру, информационная система экстренной службы, которая должна включать в себя подсистемы обработки обращений граждан, управления силами и средствами, формирования информационной модели события в условиях ЧС и в особый период. Система должна иметь сопряжение с существующими каналами связи, интегрироваться с ГИС, системами хранения информации о потенциально опасных объектах и навигационным аппаратным обеспечением, исользуемым силами и средствами, находящимися в подчинении экстренной службы.
Не буду утверждать, что таких систем не существует, однако я был бы очень благодарен вам, если вы назовете мне на вскидку хотя бы пару прототипов в открытом доступе, с которыми я бы мог ознакомиться.
Что значит прототип?!?! Данная система (первая очередь) была сдана заказчику (МЧС РФ) почти два года назад.
Берите и знакомтесь. Или привлеките тех, кто ее анализировал и проектировал. Меня например.
Или посмотрите готовую и работающуя в нескольких странах голландскую систему.
Или...

401
"Цель-3" Э. Голдратт. Читается очень легко.

402
Допустим, что некто говорит, что число "Пи" равно 11,6. В этом случае бессмысленно пенять на недостаточную точность. Важнее то, что число неправильно.

403
Сергей, а уменьшение стоимости операций, трудозатрат и трудоемкости операций не имеет никакого значения?
Я понимаю ты фанат теории ограничений - ну и что?
В некоторых случаях снижение трудоемкости имеет значение. Зависит от видов деятельности. В данном случае это скорее 0. Для особо продвинутых CRM, использующих эффект масштаба трудоемкость может даже вырасти и это будет вполне нормально.

404


Буду проводить 24 декабря.

Как правило, группа тестирования выдает «на гора» только два артефакта. Это заключение о качестве программного продукта, также называемого «Отчет о тестировании» и список расхождений между ожидаемым поведением и действительностью, также называемых описанием дефектов.
В отличие, от документации, которую как известно можно и не читать, описание дефекта будет прочитано как минимум еще одним человеком. Тем, кто будет исправлять дефект. Дефект это болезнь программы, исправление – лечение. И чем точнее диагноз, тем проще провести лечение.
В смоем вебинаре по выбору и настройке BTS, я коротко рассмотрел группу описательных атрибутов. В этом семинаре я рассмотрю их подробно.

Основные темы:
• Как составить текст заголовка. Очень сложная тема, заинтересовавшая слушателей предыдущего семинара.
• Варианты описания воспроизведения бага
• Выбор грани между описанием симптомов и причины
• Тескт, скринкаст, видео. Что лучше?
• Борьба с лишними атрибутами бага.
• Одно описание или несколько? Одинаковые симптомы в разных местах.
• Когда нужно отказаться от BTS?

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

Кому адресован тренинг?
В первую очередь тестировшикам (примерно до 5 лет опыта). Во вторую очередь людям, занимающимся подбором тестировщиков.


Условия участия в семинаре: http://software-testing.ru/news/706-online-seminars

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »