КаБа

Не делать свою систему управления знаниями Во-первых, есть много систем, которые подходят под хранение знаний, например wiki. Во-вторых, пока будете делать систему управления знаниями, переругаетесь по поводу ее функционала и интерфейса. Когда система будет готова, выяснится что часть людей не хочет ей пользоваться из того принципа, что их требования не были учтены. В-третьих, пока ее будут разрабатывать, само желание что-то где-то хранить может угаснуть. Не предопределять структуру, в которую знания укладываются Нет ничего хуже чем видеть красивое, но полупустое дерево каталогов. Каждый участник должен иметь максимально простой способ скинуть знания в общий котел. Как их структурировать — разберетесь по ходу наполнения. Теги рулят, но тут тоже нужно без фанатизма — они имеют плоскую структуру и в какой-то момент начнут конкурировать между собой за внимание пользователя. Лучше начните с хорошего поиска по контенту. Не вводить ограничения по доступу на изменения Ну разве

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

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

Интересный факт: компания General Electric на обучение персонала в год тратит порядка одного миллиарда долларов. При этом годовой оборот компании в 10-м году составил около 150 миллиардов с чистым доходом около 11 миллиардов. Т.е. на повышение квалификации персонала компания тратит порядка 9% своего дохода. При этом в среднем в развитие одного человека инвестируется порядка 3000$. Причина такой щедрости по отношению к персоналу на мой взгляд кроется в том эффекте, который GE получили во второй половине 90-ых от внедрения концепции "Шести сигм" . В 1996 году в GE затраты в виде отходов, повторных работ, исправления ошибок обходились GE примерно в 7-10 млрд долларов в год. GE потратила в 1996 году на обучение персонала 200 мл. долл., а в 1997 году еще 250 млн. Все эти инвестиции вскоре полностью окупились той экономией, которая была получена в результате использования методологии «Шесть Сигм». В 1997 году дополнительный доход составил 300 млн долларов, а в 1998 году –

Пару ходов назад я тут припомнил NIST Enterprise Architecture Model , но приберег на потом одну мысль. Делюсь. Автоматизация бизнеса возможна лишь по той причине, что в ходе потока любой деятельности порождается информация, которая совершенно произвольным образом используется в дальнейшем. Сплошь и рядом в бизнесе происходят операции с информацией, порождающие новую информацию. Бизнес порождает информационное пространство, которое имеет свою структуру. А информация в свою очередь может быть представлена в электронном виде, что и дает возможность в той или иной степени автоматизировать практически любой Бизнес. Структура информации, вертящейся в бизнесе, в ходе анализа и выявления требований представляется в виде информационной модели. На этом ликбез закончен. Информационная модель не является моделью данных, которыми управляет система. Но поскольку данные, которыми манипулирует система, являются интерпретацией информации, то модель данных абсолютно точно должна отражать все зависим

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

NIST Enterprise Architecture Model - это модель, иллюстрирующая взаимосвязь, взаимодействие и взаимозависимость различных видов обеспечения информационных систем. Описание модели можно найти в википедии . Я бы посоветовал еще обратить внимание на статью про Enterprise architecture framework , поскольку в ней, по моему мнению, сделан акцент на использование этой модели на практике. Модель так же прекрасна, как и очевидна. И так же очевидна, как и логична. Поэтому, когда смотришь на нее, первая мысль, которая приходит в голову, звучит так: "А что тут такого? Это ведь ежу понятно!". Так-то оно может и да, но в жизни все иначе - множество проблем, связанных с некачественным проектированием информационных систем, связано с незнанием или непониманием проектировщиками (аналитиками и архитекторами) того посыла, который в себе несет эта модель: Бизнес имеет архитектуру, которая являет собой совокупность взаимосвязанных взаимозависимых бизнес-процессов. Ни один процесс никогд

Очень часто, где-то раз в пол-года, мои коллеги массово у меня интересуются, куда им развиваться. Вопрос при всей своей внешней простоте весьма многогранен. Причем задается он и молодежью, и теми парнями, которые успешно прошли не один десяток проектов и по идее сами для себя могли бы на него ответить. А у меня не было системного ответа, пока вот на днях не озарило. Спасибо Гартнеру и их магическому квадранту. Поясню. Как вы помните, одно время я всех одолевал картой компетенции аналитика . Так вот, если ее разбить на несколько секторов, то может получиться замечательная штука (извините, Visio дома нет, поэтому рисую в пэйнте):

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

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

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

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

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

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

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

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

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

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

Коллеги, это последний стул в КАБА. Проект не взлетел (он не стал для нас местом для общения), держать его отдельно выделенным инстансом нет ни времени, ни смысла. Мне нравится фейсбук, я буду там: https://www.facebook.com/skalinov Тем более Гриша давно мне предлагал это сделать :)

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

Честно скажу, что понятия не имею, к какому выводу и как приду в этой заметке. Но очень хочется в этом вопросе поставить точку. Грамотные люди скажут, что это холивар , а я, соглашаясь, отвечу так: ну и что? К какому-нибудь выводу, да придем. Итак... Документ пишется текстом, который можно прочитать. Никаких нотаций при этом знать не надо, любой, даже неквалифицированный в IT человек сможет понять, что автор документа хотел донести. А если не сможет понять, то документ можно переписать так, чтобы даже гномики поняли ценность изложенной в нем мысли. С моделью все иначе. Чтобы ее прочитать, нужно знать нотацию. Причем не просто знать, а уметь на ней читать - т.е. знать в совершенстве. Представьте себе девушку, работающую в кредитном отделе и в совершенстве знающую ARIS или UML. Представили? Да? Не, я серьезно. И что она, по вашему, там делает??? Выходит, документирование круче.

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

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

Есть вещи, которые мы считаем самыми обычными. И, конечно, мы считаем, что умеем ими пользоваться. Умение как бы само собой появилось — то ли с рождения, то ли вот посмотрел на вещь в первый раз, и сразу все понял. Но так хорошо думать, только когда есть возможность сделать ошибку, ибо «Опыт — сын ошибок трудных» © А.С. Пушкин — лучше и не скажешь. Аналитику возможность ошибаться дается далеко не всегда. Он не имеет права испортить первое впечатление заказчика — как о самом аналитике, так и о компании, которую аналитик представляет. Это значит, что аналитик должен не просто пользоваться инструментами и методиками, он должен УМЕТЬ делать это эффективно. Поэтому я буду делиться своим опытом, который касается повседневной работы аналитика и инструментов, которые помогают ему делать работу. Часто интервью длятся по 2 часа. Обычно к такому времени мозги аналитика превращаются в вареный пельмень. Это представителю заказчика хорошо общаться - он просто говорит что знает, да еще ему

В общих чертах целью управления качеством является обеспечение стабильного качества продукта и его последующего роста. Под качеством понимается способность продукта удовлетворять потребности и ожидания Заказчика. То, как управлять качеством, определяет международный стандарт ISO9000:2000, который в нашей стране имеет прямое заимствование (т.е. внедрен в первосданном виде с переводом на русский и минимальными незначительными корректировками). В соответствии с ИСО вопрос управления качеством решается внедрением некоторой процессной модели, предусматрвающей определенные процедуры мониторинга, анализа и принятия решений, котороые и обеспечивают стабильность и улучшение качества. Все это конечно работает и дает ощутимый эффект, но является дополнительным костом, весьма весомым, который в случае заказной разработки может весьма существенно (до 10% по моим прикидкам) утяжелять бюджет проекта. Как с этим быть? Перходить на модель управления качеством по прецедентам. Суть идеи крайне прос

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

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

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