Короткая ссылка: AnalystDays-2013

Вторая конференция Analyst Days. Мне понравились все доклады на которых я был. Это не значит, что все они несли ценность и новые мысли для меня - все-таки у меня достаточно высокий уровень и большой опыт работы, однако они будут интересны и полезны многим аналитикам, и не только начального уровня. И это не только мое мнение, я разговаривал с другими участниками, слушал отзывы в перерывах между докладами. А я для себя - тоже вынес определенные мысли и идеи, которые буду применять в своей деятельности. Очень хорошая, может быть даже превосходная, Модель аналитика, которая была в докладе Димы Безуглого и Ирины Суровой. Идея Контекста проекта из доклада Кристины Ерофеевой, у нас есть аналогичные артефакты, но взгляд на них под этим углом зрения дает новые грани. Хороший практический доклад о применении Impact Mapping Дмитрия Петрашева. Книга Сэм Кеймер "Руководство фасилитатора", о которой рассказывал Саша Байкин. Хорошие метафорические названия - "метод соломенных чучел" Ани Абрамовой, для ситуации, когда для вытягивания информации представляешь на растерзание заведомо неполную модель, и схема "луна за облаками" Сергея Горицкого - "Руководство тоже озабочено проектом, если мы не сможем договориться - сходим к руководству".

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

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

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

А еще надо отметить, что многие докладчики на конференции звали на ЛАФ, Летний Аналитический Фестиваль, который несколько лет проходил в Иваново, а в этом году будет проходить в Этномире. И который, по опыту прошлых лет, собирает теплую компанию аналитиков с хорошими докладами и живым общением.

Наши доклады

У нашей компании (CUSTIS) на конференции было два доклада

Наталья Григораш. Аналитик как золотоискатель: работа с требованиями при заказной разработке
Михаил Заборов. Архитектура - это что?

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

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

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

Особенно понравившиеся доклады

Дмитрий Безуглый Системный подход, Ирина Сурова Лаборатория Касперского. Идеальный аналитик и почему его не может быть

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

Основные компоненты модели.

Три слоя компетенций. Показывают, на что можно рассчитывать при обучении и за какие сроки.
Модель Адизеса, адаптированная к аналитической деятельности, раскладывающая аналитиков на 4 типа по 2 дихотомиям. При этом реально имеем смешанные, а не чистые типы, и для аналитиков важны не только большие буквы, но и наличие малой: при полном отсутствии буквы коммуникации в такой области невозможны, люди не понимают.
3-осевая модель навыков и знаний. Позволяет оценить комплиментарность аналитика проекту.

Модель построена конкретно для аналитиков, однако источники носят общий характер, она может быть построена и для других ролей. Дима и Ирина планируют ее развивать и обещали представлять на следующих конференциях. в частности. на ЛАФ.

Персонажи

Петр, 31 год. Хорошо пишет большие документы, аккуратный, глубоко понимает технические детали. Но! сложно разобраться с требованиями, непонятно объясняет (плохие коммуникации, отвечает вопросом на вопрос). И не хочет брать ответственность.
Роман, 27 лет. Активный, прекрасно общается, вырвет согласование, хорошо презентует информацию. Но! общается с бизнесом раньше, чем согласует в команде, выдает обещания, не подтвержденные технически. Упрямо увлекается неважным. Кстати, смотрите на собеседованиях: если человек не видит проблем прошлой работы, но он и у вас не увидит.
Александра. 34 года. Умеет выстроить процессы, знает весь функционал. Но! конфликты вокруг процессов, после того, как минимальный уровень достигнут. А еще - функционал знает, но он ей уже не интересен.

1. Начать - с правильных ожиданий.

Компетенция. 3 слоя: Свойства и мотивы; Я-концепция, Установки и ценности; Навыки и знания.

Свойства и мотивы меняются за 5-10 лет. 5 лет обещают хелперы "изменю жизнь".

Я-установки и ценности - 3-5 лет.

Навыки и знания 0.5-3 года. 0.5 - если есть источник зананий, 3 года - метод проб и ошибок.

Analytical Thinking + Problem Solving. База + Установки + Знания - должна быть.

Поведенческие характеристики - это второй уровень. Если халявщик - не исправишь (ну, года за три).

2. Противоречие.

Модель Адизеса. Только противоречия чуть другие - область другая.

1) Люди и Технологии. Тех, кто любит и железочки и людей в природе мало.

Модель противоречий не действует для шизофреников.

2) Тактика или Стратегия. Отношение ко времени.

Две оси, 4 квадранта.

Визионеры. Люди + Стратегии. Продажник.
Архитектура. Техника + Стратегии. Мистер Идеальное решение.
Sale и Support. Тактика + Люди. Свой среди чужих - полностью на стороне пользователей, не просто адвокат пользователя, а прокурор разработчика.
Разработчик. Тактика + Техника. Мистер Сейчас напишу - код.

Большой проект.

Vas - Визионер
vAs - Архитектор
vaS - Внедренец

Чтобы люди могли договариваться, у них должны быть хотя бы маленькие буковки, а не пусто. Иначе нет основы понимания.

Петр. -А-d. Не любит людей.
Роман. --Sd. Не видит общей картины. Но картины целиком - не видит и не может. Проблемы были в том, что из-за коммуникаций от него ожидали видение общей картины
Александра VAsd. Вроде буковки все, но проблемы остаются.

3. Глубина и соответствие знаний.

Специальные знания - бизнес и системный анализ
Предметная область
Решение - технологии

Специализации

Методист - только анализ
Эксперт - только предметка
ИТ-аналитик - только технологии

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

Александра - именно методист. Ей не хватает Предметки и Технологий. Она свою работу сделала, дальше для нее оверскил, не интересно.

Три модели. Позволяют осознанно подходить к подбору аналитиков на проекте.

Да, несоответствие проекту - не повод уволить. Есть много других проектов. Да, в докладе были только проблемные персоны без хеппи-энда.

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

Junior аналитик - подмастерье. Идет совместно на встречи и учится и так далее.

А еще Junior-аналитик - вещь относительно проекта. Не комплиментарный проекту аналитик попадает в область junior. И если у него другая самооценка, основанная на прошлом опыте, то получается большой диссонанс.

Анна Абрамова. Аналитик-первопроходец - проблемы и решения

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

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

Поймите зачем лично вам это нужно. Выстраивание ситуации - 6-9 месяцев. И оно - на самомотивации. Поэтому надо заранее задать вопросы - хочешь ли ты в нее попасть?

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

Признаки проблем с моделью

нелогичный GUI
разная терминология внутри и с Заказчиком
на разработанную модель не ложатся новые требования

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

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

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

Разобраны заинтересованные лица проекта в контексте выстраивания работы аналитика, а не проекта в целом:

Согласовать ожидания работы аналитика
Сделать работу прозрачной
Получить доступ к информации

Метод - декомпозиция и оценки, не как самоцель, а как средство прозрачности. Предлагать разные уровни решения (минимум три) с разной трудоемкости (включая "а давайте просто опишем workaround).

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

Кристина Ерофеева Devexperts. Контекст, в котором мы создаем

Сначала пугаем

Работа в конструкции быстрого изменения хотелок заказчика.
А еще - когда в команду пришло куча неспециалистов предметной области

Я: Нас пугают, а нам не страшно. Потому что конструкция со странным аналитиком, который "все знает, только сказать не может".

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

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

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

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

Александр Байкин UML2.RU. Инсайды совещаний

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

Переходя к существу. Речь шла о проведении совещаний и опиралась на книгу Сэма Кейнера "Руководство фасилитатора". Книга на русском вышла совсем недавно, в 2013 году, я ее не читал, а теперь, наверное, прочту. Потому что эффективное проведение совещаний - очень типичная задача для аналитика. Особенно совещание с разнородными участниками.

Кусочек из тезисов, записанных по ходу доклада - просто чтоб представляли, о чем речь.

Принятие или эмпатия.
Время на подумать. Работа по одному, в парах-тройках - не только большие совещания.
- Варианты. 2-4-2 парами, вместе, опять парами меняясь, 2-4-8.
- Декомпозиция на подгруппы
Очередность - сериализация высказываний. Трекинг - деление на треки по темам дискуссий, это доп. форматирование.
Перефокусировка (идея понятна, хотя пример не слишком)
Напоминание цели
Линкование. Когда один вроде ушел в сторону - вопрос - он или вернется, или объяснит связь
Пауза, Другой формат
Регистрация = представление участников, напоминание цели. Вброс от каждого на минутку, чтобы переключились на тему.
Подведение итогов. Фиксация договоренностей, вброс на следующее совещание.

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

И еще вопрос: Что делать, если люди уклоняются от решения? Ответ - зависит от ситуации, может помочь метод заведомо плохого. Но надо вывести на поверхность причины - что смущает.

Дмитрий Петрашев Dell. Impact mapping. Как dev команде перестать делать то, что требуют, и начать делать то, что нужно

Блиц-доклад по книге Гойко Аджича "Impact mapping", которой они вдохновились и попробовали применить в своей разработке. Успешно, хотя состояние промежуточное: они взяли уже достаточно сформированный по задачам релиз, и применили impact mapping к нему. Получили понимание бизнеса, получили определенный профит при обсуждении скоупа с бизнесом. Но пока это инструмент со стороны аналитиков команды разработки, а хотелось бы поднять его до уровня инструмента постановки задачи бизнесом. Это - в планах на будущее, на очередные релизы. Автор рассказывал как о самом процессе, так и об опыте применения, совместно. Показывал средства визуализации и диаграммы, правда, из книжки, а не реальные. Но в примерах был и их опыт восстановления бизнес-целей по конкретным задачам. Доклад был признан лучшим на конференции.

Остальные доклады

На многих из них я слушал кусочек - потому что они шли параллельно с другими интересными. Так что описание фрагментарно.

Мария Бондаренко GP Software.Travel, Сергей Бондаренко Itransition. Полезные навыки аналитиков - как стать профессионалом

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

Содержание доклада я повторять не буду, надо сначала брать презентацию и смотреть, а если заинтересует - то смотреть запись доклада.

Ирина Крючкова Айкюжн. Анализ первопричин (мастер-класс)

Забежал в перерыве. Реальный мастер-класс на большую аудиторию, с делением на пары и четверки, заданиями и обсуждением. Можно было прокачать свои скилы. В темах - мозговые штурмы, диаграммы Исикавы и многое другое. Наверное, можно так и использовать, когда будет запись: если интересует прокачаться в какой-то теме, смотришь группой, выполняя задания.

Юрий Орлов SmartArchitects. Система управления архитектурой предприятия (enterprise architecture)

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

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

Ольга Юрковская rost-biznesa.ru. Эффективные презентации (мастер-класс)

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

Вот и в презентациях так. Многие ли дают ответ на вопрос "Зачем вы выступаете" в форме "Что должен сделать слушатель после презентации"?

И еще пара моментов.

Структура Проблема-Решение. ставим цель-проблему. И предлагаем решение. Давать возможность выбора, 3 варианта. Больше 3 - плохо. Первый вариант - самый (сверх)дорогой, потому что для части - проходит. Второй - примерно то, что хотели продать. Третье - урезанная версия, на попробовать: для бедных или для осторожных. Если выбора нет, то возникает ощущение, что вы давите, вариант "дать-не дать" - не выбор, правильный выбор - дать 10К, 5К или 4К.

Мотивации. Кнут и пряник. В постсоветскоим пространстве кнут делает лучше - пугать 70%, 30% блага. Перед американскими - обратная зависимость. И перед топами - их не запугаешь.

Марина Ефремова Ноамедиа. Особенности аналитики сервисных компаний

Рассказ аналитика-практика о проблемах, возникающих при построении модели и выявлении требований при автоматизации сервисных компаний. Связанных с достаточно малой четкостью документооборота и разнообразием, вариативностью процессов.

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

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

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

Евгений Виноградов Яндекс.Деньги. Аналитика в аналитике

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

Вадим Мустяца Deeplace. Agile Suprematism, или Жизнь разноцветных квадратов

Докладчику сильно не повезло, на первых минутах сломалось оборудование и выступать пришлось без презентации, рисуя на флип-чарте, что для большого зала - очень плохо. Энтропия бушует. Доклад был фейерверком образов и метафор. Правда, на мой взгляд, местами слишком поверхностных для руководства к действию - я для себя понимал, где тут натяжка и как-то быстро решал, что лучше будет без такой аналогии. Целью автора было раскачать сознание слушателей, дать им неожиданный взгляд. А предмет - работа с карточками, "разноцветными квадратами", по конструкции по работе с user story от Майкла Кона Card Conversation Confirmation.

Сергей Горицкий ОАО Воткинский завод. О роли информационной службы при реорганизации процессов

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

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

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

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

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

Илья Корнипаев. Человек на воздушном шаре

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

Что делать.

Соответствие позитивным ожиданиям - Знания и умения, Понимание, Уважение (начиная с уважения к времени)
Формирование реалистичных ожиданий - Где мы сейчас, Что собираемся сделать, Зачем это нужно, Что дальше. Интервью - лучший способ формирования ожиданий, не упускайте это.
Борьба с завышенными ожиданиями - Информировать, Проверять, Демонстрировать. Все записывать и кивать на интервью - значит вы все понимаете, и вообще знаете предметную область, и расскажет об исключениях, пропустив все что считает общим. Поэтому надо стандартные вещи тоже проговаривать.

Были ссылки на книжки.

А еще автор сделал презентацию собственной книги "Требования для программного обеспечения: Рекомендации по сбору и документированию". У него была задача - сделать короткую книгу, в которой собрать основной материал и дать ссылки для начинающих. Коротко - получилось.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 14:46, 27 мая 2013 • нет комментариев

2013-05-27: AnalystDays-2013