воскресенье, 26 июня 2011 г. - www.msmirnov.ru

Летний Аналитический Фестиваль-2011 (ЛАФ-2011)

Вчера я посетил наверное уже ставший традиционным Летний Аналитический Фестиваль-2011 (ЛАФ-2011), который как и в прошлом году проходил в Иваново и был посвящен системному анализу.

О ЛАФ-2010 я писал здесь и здесь.


Было приятно увидеть множество знакомых лиц с прошлого фестиваля.

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

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


Лично для себя я отметил следующие доклады:


1. Ирина Левенец "Управление ожиданиями в продуктовой разработке". На мой взгляд интереснейший доклад.

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

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

Поэтому, с течением времени уровень сервиса, который предоставляются заказчику, растет, но не смотря на это, недовольство заказчика тоже растет.

Соответственно, ценность сервиса для заказчика снижается.

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

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

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

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

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

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

- Вовлекать заказчиков в процесс сортировки требований. Это способствует повышению адекватности заказчиков.


2. Сергей Мартыненко "Варианты управления требованиями". Как и в прошлом году, у Сергей был очень интересный доклад.

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

- Плохие способы отбора требований в релиз:
    - Крик. Кто из заказчиков кричит громче, требования того реализуются быстрее.
    - Занудство. Кто из заказчиков настойчивее продвигает требования, требования того реализуются быстрее.
    - Зарплата. Кто из заказчиков получает большую зарплату, требования того реализуются быстрее (актуально в случае внутреннего заказчика).
    - Приоритет.

 Почему все эти методы плохие? Потому что в релиз попадают фичи, без учета их общей ценности, зависимостей, влияния на архитектуру и пр.

- Хороший способ распределения требований по релизам:

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


3. Денис Казика. "Внедрение ITIL/ITSM" Тоже довольно интересный доклад.

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

Для решения проблем были предприняты следующие шаги:

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

- Были внедрены внутренние регламенты работы IT-подразделения.

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

- Была введена должность бизнес-аналитика.

Весь процесс занял примерно 2.5 года.


После всех преобразований:
- IT-подразделение стало бизнес-образующим.

- Исчезли конфликты между IT-подразделением и другими подразделенями.

- Бизнес компании стал более эффективным.


4. Алексей Киселев "Могут ли быть выгодны ошибки аналитика или история одного тендера".

Алексей рассказал о сложностях работы с государственными заказчиками и участия в государственных тендерах.

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

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

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

- Гос.заказчики не признают итеративную разработку. Только водопад.


Пожалуй, это были самые интересные для меня доклады.


К сожалению мне не удалось попасть на мастер класс Дмитрия Безуглова, но я надеюсь увидеть его как-нибудь позже.

Кроме того, не удалось побывать на интересном мастер-классе Ирины Векленко "Анализируй это: Жизнь как Проект", но я также надеюсь пообщаться с ней позже.

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


Я надеюсь, что в следующем году состоится ЛАФ-2012 и буду очень рад присутствовать на нем.

Хотелось бы поблагодарить всех организаторов и участников фестиваля за то, что они делают!


All you need is... ЛАФ!
Мой сайт - www.msmirnov.ru

9 комментариев:

  1. >Денис Казика. "Внедрение ITIL/ITSM ..... >внедрения стандартов работы IT-подразделения в >инвестиционной компании.
    >"Весь процесс занял примерно 2.5 года."
    Непростительно долго как то. Впрочем у нас в стране всегда так.

    ОтветитьУдалить
  2. Спасибо, Михаил. Очень интересный и содержательный обзор

    ОтветитьУдалить
  3. Быстрее, чем за 1.5 это не делается. Добро пожаловать в реальную жизнь.

    ОтветитьУдалить
  4. Эдуард, всегда пожалуйста!

    Правда, очень замечательный фестиваль получился!

    ОтветитьУдалить
  5. Спасибо большое за отзыв! Очень полезно прочитать мнение слушателей чтобы понять, правильно ли я расставлял акценты.

    ОтветитьУдалить
  6. Благодарю за отчёт. К сожалению, все мероприятия посетить не удалось, но, самое интересное, не был на тех докладах, что описаны в вашем отчёте. Поэтому, большое спасибо ещё раз.

    ОтветитьУдалить
  7. Павел, вам отдельное спасибо за игру!

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

    ОтветитьУдалить
  9. 2 Евгений:
    2.5 года мы достигали целевых показателей по процессам, а первые ощутимые результаты были уже через полгода, на мой взгляд для динамично развивающегосчя бизнеса очень неплохо.
    То, что компания достойно пережила кризис 2008 года говорит о многом :)

    ОтветитьУдалить