Вчера я посетил наверное уже ставший традиционным Летний Аналитический Фестиваль-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... ЛАФ!
О ЛАФ-2010 я писал здесь и здесь.
Было приятно увидеть множество знакомых лиц с прошлого фестиваля.
Как и в прошлый раз фестиваль прошел в теплой непринужденной, я бы даже сказал дружеской, и вместе с тем, профессиональной обстановке.
Профессиональный уровень докладов в этом году, на мой взгляд, был значительно выше чем в прошлом. Было много полезной информации, полученной именно из конкретной практической деятельности.
Лично для себя я отметил следующие доклады:
1. Ирина Левенец "Управление ожиданиями в продуктовой разработке". На мой взгляд интереснейший доклад.
Ирина рассказала о том, как решать проблему поддержания удовлетворенности заказчиков при длительном сотрудничестве.
Проблема состоит в том, что при длительном взаимодействии с заказчиками их ожидания имеют свойство повышаться и то, что в начале работы они воспринимали с благодарностью, с течением времени начинают воспринимать как нечто обычное, само собой разумеющееся и требуют уже большего сервиса. При предоставлении большего сервиса эффект опять же бывает временным.
Поэтому, с течением времени уровень сервиса, который предоставляются заказчику, растет, но не смотря на это, недовольство заказчика тоже растет.
Соответственно, ценность сервиса для заказчика снижается.
Какие пути решения проблемы предлагает Ирина:
- Доносить ценность новых возможностей систем до заказчиков. Т.е. при обновлении систем им необходимо сообщать не о новых возможностях, которыми теперь обладает система, а о новых проблемах и задачах, которые она умеет решать. И расписывать в красках, как здорово она умеет это делать.
Мне кажется это довольно интересный ход. Лично мы сейчас в своей работе сейчас, когда у нас выходит новая версия системы, сообщаем клиентам именно об изменении ее функционала, а не о новых задачах, которые теперь можно решать. Надо будет учесть это.
- Поскольку ресурсы по разработке обычно ограничены, а множество клиентов генерирует поток запросов на изменение, необходимо выполнять сортировку новых требований.
Здесь Ирина привела интересный термин "Triage".
Triage - это сортировка раненых на поле боя - кому требуется помочь немедленно, кто может подождать, а кому вообще помогать уже нет смысла - за это время могут пострадать большее количество других раненых. С требованиями точно так же. Необходимо выполнять сортировку требований учитывая их ценность для всех заказчиков.
- Меньше обещать, больше делать. Т.е. если мы пообещаем заказчику сделать что-то например за неделю, и сделаем за неделю - это хорошо. А вот если мы пообещаем сделать за две недели, а сделаем за неделю - это будет просто отлично, заказчик будет счастлив.
- Если что-то не может быть сделано - так и сообщать заказчику. Не говорить, что может быть мы когда-то потом это сделаем.
- Вовлекать заказчиков в процесс сортировки требований. Это способствует повышению адекватности заказчиков.
2. Сергей Мартыненко "Варианты управления требованиями". Как и в прошлом году, у Сергей был очень интересный доклад.
Наиболее интересные мысли, которые запомнились из его доклада:
- Требований надо собрать большие, чем будет реализовано. Смысл в том, что среди требований, которые собирает аналитик присутствуют полезные, относительно полезные, бесполезные и вредные. Для того, чтобы сосредоточиться на полезных, аналитику придется сначала собрать так же бесполезные и вредный.
- Плохие способы отбора требований в релиз:
- Крик. Кто из заказчиков кричит громче, требования того реализуются быстрее.
- Занудство. Кто из заказчиков настойчивее продвигает требования, требования того реализуются быстрее.
- Зарплата. Кто из заказчиков получает большую зарплату, требования того реализуются быстрее (актуально в случае внутреннего заказчика).
- Приоритет.
Почему все эти методы плохие? Потому что в релиз попадают фичи, без учета их общей ценности, зависимостей, влияния на архитектуру и пр.
- Хороший способ распределения требований по релизам:
Как видим из диаграммы, порядок выполнения требований зависит от определенности их бюджета и критичности. Вообще говоря, это довольно понятно - идем по пути снижения рисков.
3. Денис Казика. "Внедрение ITIL/ITSM" Тоже довольно интересный доклад.
Денис рассказал о своем опыте внедрения стандартов работы IT-подразделения в инвестиционной компании. Изначально IT-подразделение не бизнес-образующим и находилось в постоянном конфликте с отделами, ведущими непосредственную работу в компании. Однако, это сказывалось на положении компании на рынке и, если не предпринять никаких действий, могло вообще привести к гибели компании.
Для решения проблем были предприняты следующие шаги:
- Была внедрена система управления инцидентами (нечто типа внутренней системы баг-трекинга.) Все запросы в IT-подразделение могли теперь поступать только через нее (до внедрения этой системы ситуация была примерно такая, как говорил Сергей Мартыненко - кто громче кричит или у кого больше зарплата, того требования и реализуются быстрее). Для того, чтобы отучить сотрудников от старых привычек работы с IT-отделом, двери отдела даже пришлось запирать на две недели, чтобы никто из других отделов не мог попасть внутрь не соблюдая регламент.
- Были внедрены внутренние регламенты работы IT-подразделения.
- Был стандартизирован парк оборудования и программного обеспечения, использующего в кампании.
- Была введена должность бизнес-аналитика.
Весь процесс занял примерно 2.5 года.
После всех преобразований:
- IT-подразделение стало бизнес-образующим.
- Исчезли конфликты между IT-подразделением и другими подразделенями.
- Бизнес компании стал более эффективным.
4. Алексей Киселев "Могут ли быть выгодны ошибки аналитика или история одного тендера".
Алексей рассказал о сложностях работы с государственными заказчиками и участия в государственных тендерах.
Наиболее интересными мне показались следующие замечания:
- Иногда в тендерах побеждает тот, кто быстрее поднимет табличку с названием конторы, а не кто предложит лучше условия.
- В конце года гос.заказчики должны израсходовать весь выделенный им бюджет, иначе не следующей год они получат бюджет меньше. В этом случае тендеры в конце года приобретают несколько неадекватный характер как по бюджету так и по срокам.
- Если после сдачи проекта в нем требуется какая-то доработка (здесь имеются в виду новые функции, а не исправление ошибок), то на них объявляется новый тендер, который может выиграть совсем другой подрядчик, нежели первый.
- Гос.заказчики не признают итеративную разработку. Только водопад.
Пожалуй, это были самые интересные для меня доклады.
К сожалению мне не удалось попасть на мастер класс Дмитрия Безуглова, но я надеюсь увидеть его как-нибудь позже.
Кроме того, не удалось побывать на интересном мастер-классе Ирины Векленко "Анализируй это: Жизнь как Проект", но я также надеюсь пообщаться с ней позже.
Еще хотелось бы отметить, что несколько раз в перерывах между докладами, аналитик Павел Сафин радовал всех собравшихся виртуозной игрой на рояле, за что ему отдельное большое спасибо!
Я надеюсь, что в следующем году состоится ЛАФ-2012 и буду очень рад присутствовать на нем.
Хотелось бы поблагодарить всех организаторов и участников фестиваля за то, что они делают!
All you need is... ЛАФ!
>Денис Казика. "Внедрение ITIL/ITSM ..... >внедрения стандартов работы IT-подразделения в >инвестиционной компании.
ОтветитьУдалить>"Весь процесс занял примерно 2.5 года."
Непростительно долго как то. Впрочем у нас в стране всегда так.
Спасибо, Михаил. Очень интересный и содержательный обзор
ОтветитьУдалитьБыстрее, чем за 1.5 это не делается. Добро пожаловать в реальную жизнь.
ОтветитьУдалитьЭдуард, всегда пожалуйста!
ОтветитьУдалитьПравда, очень замечательный фестиваль получился!
Спасибо большое за отзыв! Очень полезно прочитать мнение слушателей чтобы понять, правильно ли я расставлял акценты.
ОтветитьУдалитьБлагодарю за отчёт. К сожалению, все мероприятия посетить не удалось, но, самое интересное, не был на тех докладах, что описаны в вашем отчёте. Поэтому, большое спасибо ещё раз.
ОтветитьУдалитьПавел, вам отдельное спасибо за игру!
ОтветитьУдалитьМихаил, спасибо огромное за отзыв.
ОтветитьУдалитьПара уточняющих моментов:
1. ИТ-подразделение в компании всегда было бизнес-образующим, хотя бы в силу специфики бизнеса (интеренет-трейдинг одно из основных направлений деятельности компании)
2. В качестве профитов от внедрения я бы назвал следующие моменты:
- предсказуемость качества, доступности и стоимости услуг ИТ для бизнеса
- прозрачность процессов и высокая управляемость ими
в результате ИТ стало полноправным подразделением-партнером для бизнеса, а не просто поддержкой ИТ-инфраструктуры со всеми вытекающими последствиями, а это уже совсем другой уровень взаимодействия :)
2 Евгений:
ОтветитьУдалить2.5 года мы достигали целевых показателей по процессам, а первые ощутимые результаты были уже через полгода, на мой взгляд для динамично развивающегосчя бизнеса очень неплохо.
То, что компания достойно пережила кризис 2008 года говорит о многом :)