376

Управление Проектом / Re: Тестовое задание:Снять фильм

« : 10 Февраля 2011, 13:40:25 »

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

RUP тут ни при чем.
Одна из школ управления, которой меня учили еще тогда, когда RUP-а не было и в помине, предполагала руководство проектами без обязательного знания предметной области. Вполне эффективная система управления.
Ашманов говорит то же самое: "Программистами может руководить даже гуманитарий".
Гровс добился успеха в фантастически сложном проекте, хотя в предметной области знал чуть менее, чем совсем ничего. Добился без всякого  RUP-а, которого тогда понятно не было.

Знание предметной области помогает руководить, но не является обязательным для успешного руководства. Гораздо важнее коммуникативные навыки и навыки целеполагания.

Кстати, знание RUP-а не является обязательным для успешного руководства разработкой ПО. Ведь разрабатывали же софт до появления RUP-а?

377

Тестирование / Re: Соотношение "багов" и "фич"

« : 09 Февраля 2011, 14:52:40 »

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

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

378

Управление Проектом / Re: Шпаргалка руководителю проекта

« : 04 Февраля 2011, 10:50:16 »

План не может содержать действий и/или исполнителей и/или трудоемкостей.

Если хотите академическое определение то:

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

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

379

Для всех / Re: Создание отдела реинжиниринга бизнес-процессов

« : 03 Февраля 2011, 14:36:10 »

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

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

В новой структуре наконец-то разделили  и IT-отдел,появились новые:

-разработки
-тестирования
-внедрения

и отдел реинжиниринга БП.

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

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

Сопровождающая документация - есть часть решения. Естественно, что писать ее должен тот, кто делает решение. Еслт это пишет тех.пис, то он является БА, а тот, у кого в трудовой написано БА в этой схеме просто лишнее звено.

Существуют ли стандартизированные критерии оценки БА?

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

380

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 20 Января 2011, 10:58:04 »

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

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

381

Идеи и мозговой штурм / Re: Я - заказчик, но мне нужно написать ТЗ на создание БД...

« : 14 Января 2011, 10:15:12 »

В принципе у вас может получиться составить инфологическую модель данных (http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85). В принципе этого достаточно.

Рекомендация. Не используйте ER модель. Вместо этого для каждого объекта составьте таблицу, примерно как показано здесь: http://blog.shumoos.com/archives/145

382

Управление Проектом / Трудозатраты на разработку технической документации

« : 30 Ноября 2010, 13:28:18 »

Возможно кому то пригодится.

http://www.tdocs.su/12136

383

Конференции Семинары и Тренинги / Re: Зимний Аналитический Фестиваль - какой формат выбрать?

« : 26 Ноября 2010, 12:18:22 »

Нет желания повторить опыт выезда в Египет на 3-7 дней в феврале?
По отзывам коллег (http://lib.custis.ru/SEG-2010_%28%D0%BE%D1%82%D1%87%D0%B5%D1%82_%D0%A1%D1%82%D0%B0%D1%81%D0%B0_%D0%A4%D0%BE%D0%BC%D0%B8%D0%BD%D0%B0%29) получилось очень, очень неплохо.

В этот раз я намерен это дело посетить, потому могу помочь с организацией. Например, организовать цену подешевле. Или отель получше

384

Обсуждение статей / Re: PM Labs 2010, Мск, 18 ноября

« : 26 Ноября 2010, 12:06:08 »

Стив Макконнелл - Как сделать эффективным процесс разработки ПО?

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

Наконец то это кто-то сказал вслух.

Подобное впечатление у меня было после посещения семинара Йордана в 2008. Ну пересказал он свою книгу, не добавив ничего. И что? Читать я умею.

385

Проектирование / Re: Постановка задачи программисту

« : 17 Ноября 2010, 10:57:23 »

Смотри: http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

Уровень аналитика - Концептуальное (инфологическое) проектирование
Уровень проектировщика (дата бейс архитектора) - Логическое (даталогическое) проектирование
Уровень администратора БД - Физическое проектирование

386

Системный Анализ и Требования / Re: Бизнес-требования и бизнес-цели

« : 13 Ноября 2010, 11:04:24 »

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

Во вторых, как вы это и указали, это две мути. Проверку делаем по союзу "и".

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


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

387

Обсуждение статей / Re: Образование будущего: Google ломает шпиль МГУ

« : 09 Ноября 2010, 11:25:59 »

Угу. А когда в начале 90-х я работал преподавателем нам рассказывали байки про  школу будущего. "Образование будущего: Apple ломает шпиль МГУ".

А когда в 80-х я учился на  преподавателя нам рассказывали про систему дистанционного образования в Австралии. "Образование будущего: телевидение ломает шпиль МГУ".

И еще через 10 лет очередной журналист не знающий историю напишет очередную статью "Образование будущего: XYZ ломает шпиль МГУ".

Будущее уже с сотню лет с нами. Только нам оно не нужно...

388

Консалтинг и Внедрение / Re: Расчет эффективности

« : 09 Ноября 2010, 11:21:25 »

Ну если есть желание и поставлена данная задача по отслеживанию эффективности выполнения работ, то можно кое-что придумать :
1. определите рамки и границы вашего проекта,
2. обозначите  результаты
3. для достижения каждого результата определите список требований (задач), которые необходимо сделать
4. рассчитайте трудоемкость для каждого результата
5. и конечно ведите фактически потраченную трудоемкость
6. составили план-факт и прикинули эффективность.

И в результате вы получите ROI=0. Т.к. ROI= профит / затраты.
Где, на каком шаге вы считали профит? Не считали? Значит проект был бесполезен немного более, чем полностью http://blog.shumoos.com/archives/212.

Дополнительные материалы:
"Критерии успешности проекта" http://blog.shumoos.com/archives/211 и
"Предпроектная гигиена" http://blog.shumoos.com/archives/191

389

Варианты Использования (Use Case) / Re: Как долго "длится" ВИ?

« : 06 Октября 2010, 11:15:46 »

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

Это один сценарий уровня уровня воздушного змея. И это несколько сценариев уровня моря.

Другой кейс. Девочки сидят на загрузке Каталогов от поставщиков. Квант работы - загрузка Каталога на следующий сезон от одного поставщика. Это Excel/Word файл условно структурированного формата, часто на несколько тысяч артикулов. "Условно" означает, что жесткой структуры нет. Конечная цель - товары и модели с необходимой атрибутикой должны появиться в Каталоге и правильно лечь по веткам, создав, где надо новые, а также - заполнив вспомогательные справочники (по необходимости). В зависимости от числа товаров, качества исходного материала и объема новых дополнительных справочников, задача занимает от некоторого количества минут на универсальной форме загрузки, до нескольких часов с последовательным преобразованием информации. Основное для нас было продумать удобную навигацию по интерфейсам и полуавтоматические кейсы заполнения справочников. А для этого - понять ход работы на типичных ветках.

Квант работы - это загрузка одной записи от одного поставщика. Это уровень пользователя (моря). 0.1 - 10 минут.
Загрузка каталога от поставщика - это обобщенный сценарий (уровня змея). Он действительно несколько дольше.

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

Квант работы - это выверка одной записи. Это уровень пользователя (моря). 0.1 - 10 минут.
Проверка всего отчета  - это обобщенный сценарий (уровня змея). Он действительно несколько дольше.


Таким образом во всех трех случаях вы рассмотрели обобщенные сценарии. И показали, что во всех трех случаях ВИ уровня пользователя длится менее 10 минут.

Что и требовалось показать.

390

Варианты Использования (Use Case) / Re: Как долго "длится" ВИ?

« : 04 Октября 2010, 16:22:13 »

Смотри книгу Коберна "Современные методы описания функциональных требований". Там все написано.

Если коротко, то для юзкейса уровня целей пользователя - до 10 минут.