КаБа

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

У меня тут возникла потребность оценить эффективность работы руководителей проектов. Задача решалась долго и по-разному, но одинаково бесперспективно. А вот на днях как-то само собой придумалось. Постановка задачи Необходимо оценить эффективность работы руководителей проектов, выполняющихся по схеме time & material. Сразу оговорюсь, что на мой взгляд предлагаемая методика подходит и для схем fixed coast. Цель оценки – понять, кто успешно ведет проект самостоятельно, а за кем надо попристальнее присматривать. Критерии успешности хода проекта: • Соблюдение бюджета • Соблюдение плана выполнения проекта • Отсутствие критических проблем, способных зааффектить бюджет и календарь • Удовлетворенность Заказчика (субъективно, по отзывам) В чем идея  Идея основывается на еженедельной оценке хода проекта по трехбальной системе: красный (проект идет неуспешно), желтый (есть риск завалить проект в красную зону) и зеленый (проект идет успешно). Успешность проекта оценивается по

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

Когда-то очень давно была такая игра - Dungeon Keeper. Смысл ее заключался в том, что игрок, играя за главного демона, должен был выстроить свое подземелье. И все бы ничего, да только вот черти и демоны, которыми ты управляешь, постоянно становились несчастными и начинали депрессировать, поскольку для того, чтобы они двигали дело вперед, тебе надо их постоянно долбашить и шевелить. А депрессивный демон - это уже не то: он не страшный, руки у него опущены и он уже ничего не хочет, кроме кусочка счастья в своей мрачной жизни. А если его не долбашить и не шевелить, он перестает работать, у него кончаются деньги и он опять депрессирует, но уже от того, что ему хочется кушать, а денежков нету.

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

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

Да, нам свойственно ошибаться. Ведь мы тоже люди. И именно по той причине, что мы люди, мы уже достойны уважения. Мы работаем с тобой не потому, что у тебя красивое известное имя, а потому, что ты нам платишь за нашу работу те деньги, за которые мы готовы работать. Прежде, чем шпынять нас за низкое качество нашего продукта, посмотри на себя и ответь хотя бы себе на вопрос: а что ты сделал для того, чтобы у нас была возможность выполнить свою работу качественно? Когда у тебя чешется язык сказать “я тут все знаю, тут нечего делать, я бы сделал это за полчаса”, помни, что мы уверены: ты не знаешь, делать дофига, ты сам своими руками это за полчаса не сделаешь НИКОГДА. Прежде, чем требовать от нас ответственности за решения, заложенные в продукт, дай нам право принимать эти решения.

Недавно приходят к нам с задачей обучить аналитиков коммуницировать с Заказчиком. Причем постановка такая, что нужно ребятам накатить тренинги про организацию эффективных коммуникаций, правила общения с Бизнесом, планирование коммуникаций, ну и все такое прочее. Идея научить людей комуницировать конечно правильная и благородная, но поскольку речь шла не о юниорах, я решил осилить весь “паровоз” и в итоге уперся в пересказанную руководителем проекта претензию от Бизнеса: наши коллеги не генерят идеи (варианты реализации поставленной задачи), а всю аналитику сводят к пыткам Бизнеса. Получается, что коммуникационные проблемы на проекте были вызваны вовсе не неумением аналитиков коммуницировать, а скорее всего плохим знанием / пониманием предметной области и / или проблемами в навыке синтезировать решения на основе имеющейся информации. Выводы из всего этого просты и очевидны: В команде должен быть аналитик, хорошо знающий предметную область проекта или способный быстро в ней разобрат

Хочу поднять одну тему, которая, возможно, стала знакомой, близкой и от того мало любимой. Она порождена тем, что использование подходов создания больших систем к разработке малых задач (скажем, трудоемкостью до 500 человекочасов) приводит к тому, что стоимость конечного продукта зашкаливает за все разумные плоды воображения. Как так происходит? Все очень просто. При реализации крупных проектов жизненный цикл системы выстраивается таким образом, чтобы минимизировать риски, возникающие на ранних стадиях. Ведь если задуматься, для чего нужны все эти описания as is, потом to be, потом сценарии использования и требования, тотальные согласования и утверждения? Как раз для того, чтобы аналитики не забыли, что рассказать девелоперам и тестерам, тестеры смогли доказать, что система соответствует тому, что не забыл аналитик рассказать им и девелоперам, у ПМ-а были весомые аргументы для спора с Заказчиком относительно того, что система не соответствует исходным целям и ожиданием (обратите внима

Давайте поговорим о том, как придти к тому, чтобы выделенный центр был эффективным инструментом Заказика и источником бесперебойной прибыли Исполнителя. Выгоды от создания идеального выделенного центра получают обе стороны. Это очевидно: Исполнителю выгодно полностью продать рабочее время проектной команды, чтобы забыть про неприятные темы, связанные с простоями, недозагрузками и прочими “радостями” ресурсной жизни. Заказчику выгодно, когда выполненная для него работа стоит ровно столько, сколько стоит время, потраченное на ее выполнение. В таком варианте он не переплачивает за продукт, как это бывает в случае fixed cost. При этом знание своей выделенной команды и ее возможностей минимизирует для Заказчика риски, характерные для time&material, а именно: превышение ожидаемой стоимости продукта, срыв сроков производства и т.п.

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

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

Пример из жизни. Однажды ко мне пришли и попросили аналитика на один из проектов. Я предложил специалиста, пусть в этом тексте он будет называться Петров. Петров съездил к Заказчику, взялся за дело и за месяц успешно решил задачу. А потом ушел в отпуск. Но Заказчик не останавливал проект из-за отпуска Петрова. А поскольку надо было стартовать новую задачу, то на проект был предложен другой аналитик (скажем, Иванов), который по своим знаниям и навыкам абсолютно соответствовал Петрову и был вполне адекватной заменой.

Этот текст был написан пару или тройку лет назад. Он есть результат моего сугубо субъективного видения. Сюда я его публикую только по той причине, что в него вошли все (или почти все) базовые вещи, на которые мне потребуется ссылаться в случае изложения каких-либо мыслей относительно аналитики. Да, это примитивы, но я буду очень признателен за любые замечания и комментарии. Что такое требования Результатом аналитической стадии проекта являются требования. Требования – это условия или возможности, которым должна отвечать система, чтобы представлять ценность для ее заказчика и пользователей. Эта ценность не является абстракцией, она вполне осязаема. Ценность системы выражается в форме ожиданий Заказчика, выражающих полезность системы для бизнеса, ее способность стать инструментом достижения стоящих перед бизнесом целей и решения имеющихся проблем. Исходя из такого определения требованиями можно считать: условия или возможности, которым должна соответствовать система для достижения

Довелось мне тут на днях делать одну работенку и вот на что я обратил внимание. Оказывается, что наша прогрессивная общественность совершенно не умеет в краткой форме внятно изложить мысли. Преимущественно это связано с тем огромным многообразием слов и букв, которые заводятся в голове профессионала по мере накопления сертификатов, лицензий, дипломов и прочей макулатуры. Но я при своих натянутых в средней школе четырех баллах за Русский язык позволю себе рассказать историю из жизни. Однажды мне довелось писать годовой отчет о создании системы автоматизации управления качеством продукции промышленного предприятия в соответствии с ИСО МЭК 9000:2001. Писали в Минпромнауки, поэтому халявы мне не дали и доку попросил почитать зам. главного инженера. Я ему принес распечатанный кирпич листов на 70. Он его открыл, шуршанул так пальцами по бумаге и выдал: - Серега, ты мудак!