Сообщения

Сообщения за май, 2012

ЛАФ 2012

Изображение
23-24 июня 2012-го года в славном городе Иваново, имеющем широчайшее признание в кругу тепловозников и любителей узкоколеек , состоится очередной летний аналитический фестиваль. В этом году из списка тех тем, которые будут обсуждаться, я для себя выделил следующие: Психология взаимодействия Аналитика и Заказчика Инновационные методы работы (для анализа, сбора и т.д.) Аналитика Персональный Канбан для Аналитиков Обучение аналитиков. Чему и как учим на первых порах? Анализ пользователей. Учимся у юзабилити специалистов. Эффективная оценка трудозатрат по проекту Неролевые методологии разработки ПО Аналитики в кольце врагов: отношения внутри IT-команды Надеюсь, будет интересно.

Деградация как следствие карьерного роста менеджера

Все мы знаем принцип Питера , смеемся над людьми, которые в него уперлись и сами уверенно и упорно лезем туда-же. С тем, про что говорит Питер, все понятно. Но в карьерном росте есть еще один забавный эффект, который я уже полгода замечаю на себе. И Питер на его фоне просто отдыхает. Суть упомянутого эффекта такова: чем больше круг твоей ответственности как менеджера, тем меньше ты занимаешься менеджментом и больше администрированием. Если так сложно, скажу проще: чем выше твоя менеджерская позиция, тем больше ты выступаешь в роли администратора и меньше в роли менеджера. Предпосылкой для этого эффекта является то, что управление любой системой делится на две основные функции: администрирование - поддержание жизнедеятельности системы; управление - синтез и реализация решений, заставляющих систему развиваться. Чем больше / сложнее система, тем больше усилий требуется на ее администрирование. И тем меньше ресурса остается на управление. Из всего этого можно сделать

Про антикризисные меры

Расскажу вам один случай, о котором узнал совершенно случайно от одного знакомого, с которым вместе работали в старой конторе. Команда делала проект для одного местного Заказчика. Целью проекта была миграция старого приложения на новую платформу. С точки зрения функциональности этого приложения стоит отметить два момента: оно лопатило кучу информации и генерило документы космических объемов. Ко всему этому функциональному многообразию надо было добавить передачу этих феерических объемов информации во внешнюю базу данных. Взаимодействие с внешней базой должно было строиться через ее хранимку, написанную фиг знает кем фиг знает когда. Когда дело подошло поближе к сдаче приложения в эксплуатацию, то оказалось, что производительность его настолько низкая, что использовать его в производстве попросту невозможно. В этот момент пришел Самый Главный Менеджер, сменил руководителя проекта и взял управление в личные руки. Ведущего аналитика упрекли в том, что он не уделил вним

КАБе - два года

Сегодня КАБе исполнилось два года. Это хороший момент ответить на те вопросы, которые мне никто не задал. Итак: Почему KABA? Потому, что Kill all BA! Название родилось спонтанно в результате разбора очередной ситуации с полетом, который то ли не взлетел, то ли рухнул. Как выбираются темы? Из жизни. Большинство записей увидели свет по результатам каких-нибудь разборок либо на моих проектах, либо на проектах моих аналитиков. По большему счету это все результаты рамзмышлений о том, как сделать лучше и качественнее. Зачем писать очевидные вещи? Это отличный вопрос! Понятие очевидности - весьма условное. Тебе очевидно, мне нет. Ты это уже понял, я еще нет. Я вообще заметил за собой такую штуку - если я не могу изложить мысль на "бумаге", значит это не мысль, а пока еще каша. Кто читает этот блог? Не знаю. Ну точнее предполагаю, что знаю пару человек, которые иногда заглядывают. Что будет дальше? Есть желание уйти от блог-стиля (мелкие посты с мыслями-идеями по фа

Принятие решений под воздействием негативных эмоций

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

Про контекст и "синюю доску"

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

Пример моделирования контекста

Изображение
Чтобы нагнать прозрачности к предыдущей записи , приведу пример моделирования контекста из своей вполне реальной жизни. Тем более, что мне все равно его надо продумать. Итак, постановка задачи следующая: Необходимо организовать контроль нескольких проектов, разделенных на три группы. Над каждой группой стоит выделенный менеджер, который управляет проектами своей группы. Я не лезу в техническую сторону вопроса. Мне важно лишь четко понимать, что: на текущую команду есть бюджеты текущие работы не вылетают за бюджеты и сроки команде не грозят простои У нас в настоящее время есть три системы, которые каждая по-своему закрывают вопрос планирования и управления: MS Project Система репортинга затраченного времени (назовем ее TRS) Система бюджетирования (пусть будет SBP) TRS сливает факты в SBP и посмотреть, сколько на каком бюджете осталось доступно средств, проблемы не составляет. Время в TRS репортится под таски проектного плана, импортированного из MS Project. Т.е.

Что такое контекст, как его нарисовать и как использовать

Что такое контекст В широком значении контекст - это среда, в которой существует объект. Применительно к аналитике в IT под контекстом стоит понимать модель, определяющую среду, условия функционирования и границы проектируемого приложения, а именно: ключевую функциональность приложения; ключевых пользователей (группы пользователей) приложения, смысл их работы с приложением; смежные приложения и основные идеи взаимодействия с ними; аппаратное, информационное, организационное обеспечение, создающее инфраструктуру работы приложения (если все это дело имеет явное влияние на проектируемое приложение); любые другие условия и условности, которые, на твой взгляд, влияют на проектируемое приложение. Контекст позволяет: понять функциональные границы проектируемого решения; получить представление о смежных системах и принципах взаимодействия с ними; выделить ключевых пользователей / группы пользователей и определить их основные потребности; определить ограничения, связанные

Принятие решений

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