1

Обсуждение статей / Re: О профессиональных стандартах в области ИТ

« : 07 Августа 2013, 12:46:14 »

К чему катимся, а главное зачем?

На самом деле данные стандарты нужны учебному сообществу (РГГУ в частности и связанному с ним ВНИИДАД) для понимания того что и как преподавать. Стандарты, как ориентир знаний и навыков будущего выпускника.
По сути решение частной задачи за государственное финансирование (кстати 15 млн. хорошая цена).

Как будут писать эти стандарты?
Т.к. скорее всего реально практического опыта работы в IT-проектах у будущих авторов нет (поверхностное участие в проектах опытом не считаю), то писать будут "списывая" теорию с других источников (стандартов АП КИТ, иностранных стандартов, ГОСТов, ИСО и пр.).

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

2

Примеры / Re: Как на диаграмме Последовательности описать независимый от основного процесс?

« : 05 Августа 2013, 10:28:59 »

1. Зачем мешать все в одну корзину?
Цель диаграмм облегчить понимание, выделив суть. Запихнув все на одну диаграмму вы снижаете ее понимание. Удалите зеленое вообще и опишите только словами. Если уж удалять не хотите, то сделайте две диаграммы (зеленое отдельно).

2. Для такого процесса я бы использовал диаграмму деятельности. Или вообще нотацию BPMN 2.0

3

Для всех / Re: Вопрос по разработке спецификаций!

« : 05 Августа 2013, 10:14:05 »

Добрый день!
Во-первых, ответе на два вопроса:
1. Кто будет основным потребителем подготовленной вами спецификации на разработку и какие управленческие решения или действия должны последовать с его стороны после прочтения вашей спецификации? Например, потребителем может быть технический специалист, который на основе вашего документа должен будет написать код будущей функциональности, или системный аналитик, который будет писать документ для разработчика, или управленец, который должен будет принять решения о начале поиска решений на рынке и объявления конкурса.

2. Где работает этот потребитель? В вашей организации или нет?

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

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

4

Для всех / Re: Мир-системный анализ - кто-нибудь слышал про такое?

« : 24 Июля 2013, 12:34:03 »

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

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

5

Вакансии / Re: Требуется аналитик (Москва)

« : 08 Июля 2013, 12:39:05 »

- Грамтоный русский язык, знание ГОСТ 19,34.

Порадовало =)

6

Обучение / Re: Цели, задачи учебного центра и стратегии и тактики их реализации

« : 09 Ноября 2012, 11:32:40 »

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

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

7

Для всех / Re: обратная связь по документации с помощью опросника

« : 08 Ноября 2012, 12:38:30 »

А что у вас не так? Где работала - везде аналитик виноват.

Нет не так. У каждой специализации есть своя зона ответственности. Есть формальные признаки качества выполняемой работы. В частности свои требования к формату постановки задачи на разработку выдают разработчики. Аналитики готовят документы в соответствии с согласованными форматами. И никто ни на кого "бочки" не катит 

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

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

В общем, печальное зрелище.

Глаза бояться, а руки делают.
И все будет хорошо. 

8

Для всех / Re: обратная связь по документации с помощью опросника

« : 07 Ноября 2012, 12:13:45 »

Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.

Своим подходом вы сразу определяете в аналитике "козла отпущения" за провал любого проекта.

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

Программисты, вообще говоря, en masse люди довольно образованные.

Аналитики, вообще говоря, тоже бывают с мозгами 

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

Где-то, что-то подобное я уже читал, типа "каждая кухарка может управлять государством". В задачи аналитика не входит управление ресурсами проекта и тем более увольнение и прием нового персонала.

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

9

Управление Проектом / Re: Обмен опытом завершенных проектов. Поделитесь опытом.

« : 17 Октября 2012, 13:03:34 »

Сергей, а разве в компании нет внутренних шаблонов?

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

Например:

классически время + деньги + область охвата = качество

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

10

Управление Проектом / Обмен опытом завершенных проектов. Поделитесь опытом.

« : 17 Октября 2012, 10:00:50 »

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

Ведете ли вы краткое описание (отчет, справки) по завершенным проектам?
Если да, то какие сведения вы туда вносите?

11

Для всех / Re: обратная связь по документации с помощью опросника

« : 01 Октября 2012, 19:41:56 »

разработка, тестирование, аналитики со стороны заказчика, эксперты предметной области

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

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

А вот для меня, если прогер не обращался с вопросами - это очень плохо. Либо не читал, либо прочитал и ничего не понял. В любом случае сделал по своему, потом придется переделывать.

Эта должна быть не ваша проблема, а проблема РП. Не вы выдаете задачу разработчикам, а РП, вот пусть и "учить" разработчиков читать документы.

12

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

« : 01 Октября 2012, 19:13:06 »

А за что в вашем процессе получают штраф менеджер и руководитель проекта?

13

Для всех / Re: Типовая информационная система, что это?

« : 15 Августа 2012, 16:28:37 »

http://ru.wikipedia.org/wiki/%C8%ED%F4%EE%F0%EC%E0%F6%E8%EE%ED%ED%E0%FF_%F1%E8%F1%F2%E5%EC%E0
ссылки на документы там есть.

14

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 03 Августа 2012, 18:22:21 »

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

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

Дает неправильную задачу, запросите под ее выполнение информацию. Говорит нужно выполнить за 1 день, говорите конечно, но для этого нужно и далее по пунктам говорите, что вам конкретно нужно, чтобы выполнить за 1 день. Может быть жизнь окажется сказкой и он сразу предоставит все по вашему списку. А если не предоставит, то укажите точное время за сколько вы успеете выполнить каждый пункт списка. Вы же не отказываетесь выполнить работу за поставленный срок, просто еще нужно подготовиться к работе...

15

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 03 Августа 2012, 17:00:45 »

Управленцем в данной ситуации был Витте, а Александр 3 только заказчиком.

Александр 3 управлял государством, а дальше по нисходящей Витте управлял той зоной которую ему выделили.

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

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